Tag Archives: blocks

Blocks have no future

While working on my OmniCard plugin and KeyGenerator plugin for WooCommerce I suddenly had an idea for AdRotate. Those 2 plugins are designed from the ground up to be easy to use and super simple to understand with *everything* they do. Literally everything;

  • The KeyGenerator plugin has 1 button and does 1 thing. Generate license keys. No settings no technical shit. Just a button. It can’t be simpler.
  • OmniCard has just over 10 options and with that the most flexibility of any payment gateway, but it’s so simple to control even the biggest of bigger idiots can use it.

AdRotate Blocks is not like that anymore. It has bolted on fields and options. People often misunderstand the actual idea of blocks and use it in the wrong way. This means that I did something wrong with Blocks. I’m not entirely sure what. But if the feature no longer makes sense to people or to me, something is wrong.

Therefor I came to the very unsophisticated conclusion that blocks as a feature no longer has a place in the vision of AdRotate. It has to go. Be removed and destroyed! Restore the simplicity. I firmly believe it is a waste of time to further develop and fix the blocks as they are now.

Outrage!

Nope! While the Block as a feature has no place in the idea of AdRotate the idea of blocks must remain. This is a very important change for the future of AdRotate. Ultimately it will make things better and simpler for everyone.

With the introduction of blocks they worked sort of like a group but with multiple ads. Their special purpose would be to generate a grid and show ads in a special way. Awesome! Perfect for the then new and hip 125*125 ads. Now, 3 years or so later, the functionality of blocks eludes me.

The idea was a layered approach, Ads go into groups, groups go into blocks and they would all work together and everyone would be happy. It doesn’t quite work as I want it to and I generally dislike how blocks turned out overall.

Solutions!

Yep! Groups have a future. And all they need is some love and a grid option. Yes, a grid. So you can still make blocks. Except it’s a group. Less layers, less clutter. Which means less confusion and greater ease of use. Oh imagine the joy … :)

So the very top of my Todo list now looks like this;

Screen Shot 2013-03-15 at 05.04.48

 

Timeline

I want to make blocks obsolete before years end. Changes can be expected soon.

AdRotate Blocks – What needs to be done

Recent versions of AdRotate have introduced some new methods and some experiments have been conducted to see where and how Blocks can be made more open and useful.

State of blocks

People wanted a CSS approach to things so blocks as a whole are more configurable in regard of looks. This partly succeeded but introduced a few quirks and less optimal situations for some users. Side effects if you will.

I’m looking to resolve all that but at the same time want to do something cool with Blocks. Not just patch up the inconsistent experience people are having now.

So think with me here

What can I do to make blocks cool again? Any CSS tricks that would resolve the current inconsistent experience are welcome. I’ve tried a number of things but none work everywhere it seems. Fixing it for browser A while breaking browser B is not cool. And for that reason I’m leaning against ditching the CSS code entirely and go back to how it was in AdRotate 3.7. But… I kinda not want to admit defeat to CSS ;)

What would make blocks more useful to you? Feature requests here please. Useful stuff, motivations why you need it. As you may know I’m open to a lot of things – But it has to make sense!

Valuable input ofcourse will be weighed in for future versions. Changes are likely to be made but at the moment I’m not sure which direction blocks should go. A wild idea… Should AdRotate support blocks at all? It probably does… In some form or shape. But perhaps a complete rewrite of the concept is in order.

An idea that kinda keeps popping up is to ditch Blocks entirely and create a widget that allows for groups and the widget handles that in a smart way with a templated approach. And another is to just not support blocks at all. But I think many people use Blocks.

Results

The goal obviously is to make things easier for you. While providing good, easy to use features without too much headaches.

Your thoughts? Please let me know in the comments.

AdRotate 3.7.3 Now Available

A bunch of minor tweaks and optimizations to improve AdRotate.

Changelog:

[change] Variable height for ad blocks
[change] Variable height for ads in blocks
[change] New installer (New installs only)
[change] Tweaks to upgrade script (Upgrades from 3.7.2 and older only)
[change] Cleaner debug information for time schedules
[change] Time notation when creating ads now uses WordPress dictated times
[fix] Time notation for schedules, now uses only WordPress dictated times

Nothing too fancy, but important changes none the less.
The time notation should now be consistent everywhere and match up to what time WordPress thinks it is. This will make schedules and such work more reliable. Auto height for blocks obviously brings back the flexible height for blocks for those that have uneven adverts in blocks. The width can *not* use ‘auto’. If that would be allowed the block grid keeps screwing up in several browsers. So that remains fixed width.

Translation files have been updated and have several new or changed lines. So translations need updating.

Beta3 users. Some fixes and changes are not in your beta. So yes, you need to update too.

AdRotate 3.7.1

Bugfix release!

Some small fixes and tweaks:

[fix] Ambiguous schedule checking
[fix] Sortorder on banner management
[fix] Tabindex on ad creation
[fix] Minor code optimization in selecting ads (removed unused code)

A few people seem unhappy with the new blocks restricting size. Just like many people hated the original wrapper at first. It’ll pass.
I am however looking into a more flexible sizing scheme. For now there is no easy solution for it because the database needs to be changed for it to accept anything but numbers. A few suggested allowing the size “auto”. This seems useful, but the actual pixel size is used to calculate the size of the block. So it needs to time and trickery to make that work. In the larger picture it’s not a real priority but will be looked at for a future version.

The following coupon codes are available:

Use the code ‘gimmeadrotate’ to get 20% off on your order of the package ‘Install’.
Use the code ‘iwantadrotate’ to get 20% off on your order of package ‘Install XL’.
User the code ‘betteradrotate’ to get 20% off on your order package ‘Upgrade’.

Find more about what we do on the services page.

About the new blocks

There seems to be some confusion as to what to do with the new blocks. Especially if your site looks wonky after the update.
This was expected of course. Thousands of people use blocks and suddenly it changes. No amount of blog posts with warnings was gonna change this.

I did write about it a few days ago. But I didn’t quite explain what to change when you adverts show up wrong.
I’ve been on the forums today answering posts and also received some emails. Most people were confused at first but quickly figured it out after a few pointers to adjust the sizes and such on blocks. But why is this needed and how do you *really* fix the problem?

Details details details!

So what’s changed, really? Thers is a new set of wrappers adding to the ‘old’ one. That wraps around each ad and one that wraps around the entire block. This in itself doesn’t mean too much. But what is important is that Blocks used to be a set amound of ads. You defined how many columns it should have and AdRotate bluntly injected a linebreak were required to give you the impression of a block.

This is no longer the case. A block now needs to know the size of the ads. The thickness of the margins, borders and padding and the sum of it all determines the ad size. Which in turn sets the block size. All this uses a set of div tags that create an actual grid. Not unlike a spreadsheet.

How to configure?

The block needs to make a grid so it needs to know how many rows and columns it will have. Set a padding and/or border if you want.
You define the size of the banners and set a margin or padding if you want. Also here a border is possible.

One important cave-at is that if you use a border or padding on the individual ads these add to the ad size. So if you have a 125px banner a 2px border and a 3px padding. The ad-size will be 130px. A margin goes around the ad expanding to the outside and thus will not add pixels to the actual ad. But it will make the total block larger. You need to account for this when reserving space in your sidebar or page but AdRotate will calculate the size automatically for you.

Migrating existing blocks

Because AdRotate did not know what ads you showed in the old system and just went with whatever was offered there was no way for me to determine the size of ads. Assuming that many people used blocks to show button banners I set a default of 125*125 adverts with a tiny margin of 1px and no border. Obviously not everyone uses these settings and they will have to edit the blocks to suit their needs. This means defining the proper ad sizes and perhaps a border or margin.

Because there was no definition of rows in the old system I migrated over as much as I could and also for rows made an assumption based on the amount of ads you had using a simple sum. If your block was to show 10 ads in 2 columns that meant you had 5 rows. This value is used to determine the new grid size. However, the sum and resulting grid is not always correct because it’s an assumption.

This means that everyone using blocks needs to check the settings and very likely needs to alter a few things to make it work again.

Why screw up the old wrapper function?

It’s not screwed up, Nor is it a bug. It’s expanded into a better system. The old system inserted an ugly linebreak where a new row would start. The new system is more strict and uses valid CSS and HTML code to achieve a better looking result.

More on blocks can be found in the all new manual.

Important change for upcoming versions for blocks!

I know Release Candidates aren’t supposed to get extensive new features but this was, i think, too good to let go till 3.7.1 or even 3.8.

I’m rewriting the way blocks are defined. Replacing the format option and eventually the limiting wrapper too. You will have more options, giving you greater flexibility. And best of all, it’s all done in valid CSS code and some smart math in PHP to make it all fit.

However, in usage this will mean that anyone using blocks will have to make some changes when this comes available. Or your blocks will look weird and ugly, perhaps even cause errors in your theme. So take notice, try out rc5 when its ready.

Here’s a initial form. This needs polishing and proper names of course. Also the form doesn’t work yet. This will eventually replace the wrapper function entirely.