Nov 072010
 
Opinion

After slogging very hard the last 3 weeks I managed to get all the changes I was hoping to include in place for version 3.6.7 last night. Making use of the illusion of an extra hour from daylight savings I went ahead and tried to submit the theme to WordPress.

But as I tried to submit it I hit a snag. I kept getting a message that said:

Error 413: Request Entity Too Large

No matter what I tried and from which browser and machine, the error did not change. It is highly likely that the WP servers had a configuration change in the back-end. I did post out a message to the theme reviewers asking them as to why this is happening. After all the file is just marginally larger than the previous versions and I have never had this problem earlier. Let’s see what they say.

As I mentioned earlier, the primary features of this release were a reworking of the navigation bar code, a fundamental change to the HTML markup and a set of options for fluid/flexible width. In addition there have been a number of BuddyPress-related style changes. I will release a new version of the Suffusion BuddyPress Pack when this version of Suffusion gets approved.

I will post a detailed change log once the theme is approved.

Oct 282010
 
Opinion

This is a follow-up to my previous post. I wrote earlier that I was incorporating fluid-width options into Suffusion. Over the past couple of weeks I have managed to work a good bit on this and I am happy to say that I have managed to get the markup rearranged, and I started full-fledged work on incorporating fluid width into the theme today.

You might be wondering what I mean when I say “get the markup rearranged”. To explain, with a fixed-width setting I can define my layout this way:

<div id='sidebar-1'>…</div>
<div id='sidebar-2'>…</div>
<div id='main-content'>…</div>

This would render my page showing the first sidebar, then the second sidebar and then the main content – in other words, it represents a layout with 2 left sidebars. The code would change depending on the layout. So if I wanted a single left and a single right sidebar, my markup would become:

<div id='sidebar-1'>…</div>
<div id='main-content'>…</div>
<div id='sidebar-2'>…</div>

This works pretty easily and well with fixed-width layouts because each column has a pre-defined width. However with fluid width there are significant problems in this approach. Typically fluid width layouts would mean that the sidebars have pre-defined widths in pixels, but the main-content column takes up the remaining available space. Naturally, when you have the main-content appearing before a sidebar, the challenges become significant.

The fix for this is to use what is referred to as the CSS Holy Grail. Actually the Holy Grail is for a fluid-width central column and fixed width sidebars, but the markup and CSS for it can be extended to fixed width layouts as well. Using this approach you will really have just one markup for all layouts:

<div id='main-content'>…</div>
<div id='sidebar-1'>…</div>
<div id='sidebar-2'>…</div>

You can then use the CSS properties float, margin-left, margin-right, left and right to control where you want to show what. This approach is recommended by experts because:

  1. You can change your layout, but your content will always remain the same. So depending on your layout your CSS changes, not your HTML.
  2. This has the added benefit of being SEO-friendly, because your main content is closer to the beginning of your document. Particularly in cases where you have a long sidebar, this is a great benefit.

Porting this approach to a fixed-width setting, however was a huge challenge. Just think about it – I had to test all the following configurations for the changed markup:

  1. General layout:
    1. No sidebars
    2. Single left sidebar
    3. Single right sidebar
    4. Single left, single right sidebars
    5. Double left sidebars
    6. Double right sidebars
  2. Page templates for each of the 6 configurations above
  3. In each of the configurations above I had to factor in situations where you would have tabbed widgets, wide sidebars etc.

All in all this amounts to more than 50 different configurations. To add to the complexity, it would have been a great world if Internet Explorer was well-behaved. Instead, for each of the 50+ configurations above, I had to tear my hair out figuring out what works for IE6.

Anyway, this part of the challenge has been overcome. I am working on now putting in fluid width components into the layout. This has its own set of challenges. I had never imagined how easy fixed width has been so far. In changing the code I am now realizing how ingrained the fixed widths are into different elements of the layout. I had a lot of widths running off the main-content column’s width. Again, our favorite IE6 and Microsoft’s proprietary “expressions” are causing me a lot of grief.

Stay tuned – I will hopefully have the new release out very soon.

Oct 112010
 
Opinion

This is the longest I have gone between releases of Suffusion and unfortunately the current release is significantly more complex than the previous ones, hence version 3.6.7 is still a few weeks away from release.

A general fact of any software development cycle is that the more complex the software the longer the development cycle. As things stand today Suffusion is quite complex under the hood. As a result when I try to make a foundational change to the theme, it is a very very arduous exercise. Such changes were much easier to make when the theme was simpler. That is the difference between foundational changes and add-on changes: add-on changes are still easy to do given the theme’s modular structuring, which is why I can add new sidebars etc without breaking a sweat (actually adding sidebars is not that easy, but it still is much easier than what I am doing right now). There are two major changes I am working on at present:

  1. A revamped approach to navigation menus – I was never happy with the way WP handled its functions wp_list_pages etc. I felt that their concepts of “include” and “exclude” were slightly messy and I tried to build a fool-proof system for building menus myself. The net result:
    1. I was successful because I achieved what I had set out to do. Including and excluding items worked as advertised.
    2. I ended up introducing some rather undesirable inefficiencies in the code. The menu-bar code worked well, but to work the way I had envisioned it required to do a lot more queries in the back-end system. For users who had a large number of pages etc, the menus generated at least 100 extra database queries.
    3. Some plugins refused to cooperate with the menu code.
    4. Some features like highlighting the correct page etc were notoriously hard to implement.

    So in this release I decided to fall back on WP’s standard functions instead of my enhanced ones. The result is that menus will not work the way I think they should (which shouldn’t really concern you – I am but one individual), but they will work the way WP thinks they should.
    The change is complex because it required me to change all my menu code, test for pages, categories, links and WP 3.0 menus, fix all style-related problems and what not. Luckily though, this is a piece that I have finished implementing.

  2. An option for fluid width – This is a more cataclysmic change. It involves revamping the entire HTML markup and a humongous amount of implementation and testing. This piece is taking a lot of time to finish implementing, let alone get into full-blown testing.

Adding to the implementation complexity are some major changes on the personal front for me, like an upcoming move from the US to Canada and you can see why this release has been taking time.

The light at the end of the tunnel, though, is that once this release is done, you can do pretty much anything with the theme layout. At that point I can focus on the funky features I had promised in the birthday post of Suffusion.

Sep 272010
 
Announcement

Over the past several weeks I have been finding it very difficult to provide support for Suffusion. It is becoming increasingly difficult for me to keep up with my day job, theme development, support and most importantly, my life.

With immediate effect I am formally announcing a reduction in the support I provide for the theme. For folks familiar with the forums, there are 3 categories where you can post topics at present: Bug Reports, Support Requests and Translations. From now on, I will only respond to questions where I believe my explicit inputs are required, like a genuine bug report, or some specific support topics.

All questions of the following sort will be generally ignored by me (others might choose to offer solutions, though, and I might occasionally respond to such queries):

  1. How to integrate plugin X with the theme (which file to edit etc.).
  2. Most questions regarding why your layout is broken. I say “most” because there are times when the layout being broken is truly because of a bug, but in 90% of the cases it is due to a user putting in improper HTML.
  3. Any question on adding support for a feature will be ignored. For example, allowing Flash-based headers, ability to load images through the theme options etc.
  4. Questions asking “What will happen if I upgrade the theme? Will I lose my changes?” This question has been answered literally hundreds of times at several places.
  5. Sending me a PM asking for a solution will be ignored. And sending me an email asking for a solution will be ignored too. The forum exists so that people can share information, so sending me a PM or email defeats the purpose of the forum. As things stand today I anyway redirect users to post on the forum if they send me a PM or email, so it is not like you will lose out on any support by this official announcement.

The forum has had several thousand posts in the last one year and a lot of questions have been answered there. But what had been originally set up as a means to genuinely help people out has now become a free-for-all, with a lot of people rushing in to cut corners on development costs by piling on the free support offered here. I am finally taking a stand here – if you need a complex requirement for your site, please hire a developer and get him/her to customize the theme for you.

What you can do to speed up things on your side are the following:

  1. I encourage searching the forum and finding things out for yourself. As mentioned, several thousand posts exist in the forum and a very high likelihood exists that something has been answered.
  2. The software is released as open-source for a reason: so that you can read and modify source code if you really need to do something not offered by the theme.
  3. Without a trace of hubris I will state that the theme is extremely customizable, more than several premium themes. In addition, for people happy about writing code it offers you full support for child themes. Both of these combined let you customize the theme as per your will. Make use of these facts – they will make life a lot easier for you.

At this point I would like to extend my deepest gratitude to Connie, Dark_Fox28, Colin and other folks who have been tirelessly volunteering with support issues. If I do happen to meet any of you, lunch/dinner is on me.

I will continue to publish tutorials every now and then on how to maximize your output with Suffusion, and I will continue to put out new releases (albeit at a much slower pace), but please don’t expect anything more than that from me. It is quite depressing to receive 60+ support requests when you are on vacation for 2 days, when you know that you are already handing out software for free that would have taken people thousands of dollars to develop.

Aug 032010
 

Suffusion is celebrating its first birthday today! I am glad that I managed to slug it out for a year and come up with a decent theme that people haven’t utterly and totally slammed!

Happy Birthday, Suffusion!

As is the case with most perspectives, I wanted to spend a few paragraphs explaining my plans for the next few months. I have already got the theme where I wanted in terms of most of the key features. Barring a dedicated photo-blog template there are very few noteworthy features lacking in the theme. Mind you, photo-blogging templates have been on my agenda since quite some time, but I had always planned to have those in the 4.x.x releases. Given that I am currently developing 3.6.0, there are still several weeks to go before I get there. Of course, when I had planned to do photo-blogging in 4.x.x I used to often jump releases, like go from 2.6.6 to 3.0.0 (that was actually a milestone release with a magazine template). But since the last few months my release strategy has changed and I have bundled several milestones with minor releases. For example you have had BuddyPress support, lots of new layouts, some new skins, advanced features like custom post types etc. So for all you know, I might actually provide photo-blogging earlier than expected.

To provide you with some insights, I maintain a “parking lot” list of items that I intend to deliver. This list already has more than 40 items with varying levels of complexity, and some of the items are feature requests and some are bugs. Whenever I think of something that would be nice to deliver, I go ahead and add it to the parking lot. Then, after submitting a particular version when I start off with a new version I go through the parking lot and pull out things that I think I can deliver in a particular release. Some of those make it to the next release and some others find their way back to the parking lot. The size of the parking lot has been around 40 for quite a few weeks now, so that means I am adding items at the same rate as implementing them. In general my focus has been to implement bug-fixes first, then tackle feature requests.

So what can you expect from now on? There will be new features delivered – small and big. I will also focus on theme aesthetics a lot more. As a kid I used to be good with art, but after I grew up I don’t do very well with making things look pretty online. So you will have:

  1. Better Typography
    I have been reading up a fair bit on typography the last few weeks. While I fail to spot the nuances of sites with so-called good typography, I do understand that a lot of people have a far more discerning eye. I am planning to overhaul the theme’s typography capabilities in the next few months.
  2. Prettier Designs
    In release 3.5.6 I made a release of a minimalistic skin. I am going to add quite a few others to the mix. Mind you, this is a singularly tough task for me as a developer, not a designer. My guess is that you will see 2-3 new skins come up.
  3. Better Theme Skinning
    A lot of people have complained about the fact that the navigation bar look and feel cannot be customized through options. Methinks thou doth ask too much, because the most extensive tutorial I have written so far deals with precisely the customization of the navigation bar. However, I do have plans to provide skinning capabilities to a handful of other places. It is just that this is an extremely tedious task that doesn’t teach me anything new.
  4. Some Stunning Widget Area Concepts
    Version 3.5.0 had natively tabbed sidebars, 3.5.4 came with 10 widget areas, the unreleased 3.5.8 had 12 and the release you are hopefully going to get, 3.5.9 has 17. I have already increased the number to 19 in 3.6.0 and I can assure you that the final number will be close to 30. I basically intend to provide users with the capability to have a widget area wherever they need one. In addition, just like the tabbed sidebar, you will see a bunch of other effects added to your sidebar rendering. That is all I am going to say at this moment – you will have to wait for the feature to actually see all of this in action.

And yes, I will be focusing on documentation of the theme along with a demo site. I have often started putting these together, but found it too boring a task to continue.

That’s it for now!

Jul 282010
 

A disclaimer
I would have posted this on WP’s official site if it allowed me to post, but since it doesn’t, I am publishing it on my own blog. This is meant as an appraisal of the new theme approval process on WordPress.

On 9th June 2010 WordPress made an announcement that it was expanding the theme review process. There was a call for volunteers to support theme reviews. This was indeed good news, particularly if you were a theme developer. For a long time Joseph Scott had been the sole approver of themes on WP, and though his work was impeccable and his reviews very good and accurate, if he was traveling or unwell or on holiday theme approvals tended to get delayed. This was by no means a deal-breaker, but having more people looking at themes definitely meant that things would get better.

Soon after the announcement a few things happened that were moves in the right direction:

  1. Quite a few folks signed up in response to Joseph’s post, so there are more volunteers now.
  2. A dedicated Trac project was setup for approvals.
  3. Every time a theme got submitted the corresponding Trac ticket got emailed to the theme author so that he/she could follow what was going on with his theme.
  4. There was much better focus on the quality of code in a theme. Actually the focus was more on writing code that didn’t generate “silent errors” or PHP NOTICE messages, but nonetheless adhering to this is something that keeps down the size of logs on your server.

But that is where the goodness stopped. One of the key things which I had hoped would be addressed, speed of approvals took a nosedive. To cite an example earlier when I submitted a theme version it would take around 1-3 days to get approved. It took 1 day if I submitted it on a weekday and typically 3 days if I submitted it on a Friday. In some cases if it was vacation time then the versions took about a week to 10 days to get approved, but this was more of an exception to the rule. Normally on a day you would see 2-3 versions of different themes getting approved, and on occasion the number of approvals even ran into double digits.

However, with the new experiment somewhere something went wrong. Now you have around 1 theme being approved in 2-3 days, which doesn’t seem right. To drive my point home, version 3.5.7 of Suffusion got approved on 10th July. Today is 28th July and only nine more versions of different themes have been approved (including a version of the WP default theme Twenty Ten). This is a far cry from how things happened earlier. I normally used to wait for about a week before pinging the folks to check the status of a version, so for 3.5.4 I sent out a message asking what was up, and this is what I received:

Thanks for the note.  Unfortunately there is currently a backlog of themes in the review queue.  We are working on it.  Themes are being reviewed in the order in which they were received.  Thank you for your continued patience.

I didn’t know at that time how much the backlog was or how much longer the next version of Suffusion would take for approval. I found out later how you can estimate the potential wait time. The backlog, as I know now, is well over 100 theme versions at present. So somehow adding more people slowed down the process.

The delay also brings in a bunch of associated problems. Currently if you have a theme version in the queue and you submit a new version, the older version gets deleted and the newer version goes to the back of the queue. So as a theme developer:

  1. If I have submitted a bug-fix for the theme 3 weeks back and that hasn’t been approved, how do I ensure that my users get the bug-fix? Distribute it from my site (unapproved)? Doesn’t sound safe.
  2. If I have submitted a version 3 weeks back with some bug-fixes, then I discover some more bugs in the submitted version what do I do with them? If I resubmit a new version I go to the bottom. So I add another month or so to something that has already been in for 3 weeks? Ouch. Incidentally I have had this happen to me quite often, most recently with version 3.5.8 and 3.5.9.
  3. If I choose not to submit the bug-fix for the older version but let the bugs be approved (these are niche bugs that cannot be caught in the approval process, mind you) and then I submit the new version, I am risking users staying with a buggy version for an indeterminate number of extra weeks.

So somehow this review process discourages active theme development, which I feel is counter-productive to the whole experiment.

How can the experiment be improved? I have a few suggestions:

  1. Improve targets. Set a target saying that each approver should aim to disposition a new theme for approval every weekday (or some such figure). If you have 10 approvers, this will take care of tackling 10 themes everyday and bring down the backlog much faster.
    I can almost hear people say, “What does he know?”, or “He is speaking like a consultant”, or “He is oversimplifying”. Well, I have been doing free support for Suffusion since late last September and that is how I keep my backlog down. Every morning I go through all outstanding support requests, take a crack at answering them if they haven’t been answered by someone else, then carry on with my regular job for the rest of the day. If a request comes in during the day, if I am not doing much then I respond to it (or if I think others can respond, I skip it). This has been a largely successful way of staying on top of things. I have responded to more than 3000 posts on my support forum at around 10 posts per day.
  2. Don’t de-prioritize existing themes in the queue upon newer submissions. I love putting out new functionality in the theme, and anyone with any experience whatsoever with Suffusion will agree with me in the fact what I provide is not just cosmetic, but hard features. Sometimes a new version is required to patch a bug. Getting pushed to the back of the queue is very off-putting, because it simply adds so much more in terms of wait time for approvals.
    This simply encourages parallel avenues of theme distribution because developers know that their work will not be approved soon on WP’s official site, so they distribute it from their site. And that is where they can start putting in stuff like tracking code etc into a theme. Mind you, quicker approvals will make this a non-issue, but the current wait of a few weeks is a bit too much.

As a concluding remark, the topic of this post and the issues in the post are not mission-critical and I am sure people have more interesting things to do. However I am sure that the free theme developers would be quite happy with these modifications, particularly since some of them invest a lot of energy in building their themes.

Jul 112010
 

Earlier today Suffusion obtained its 100th rating on WordPress.org. This puts it it rather exclusive company – it is now the 5th theme to obtain this distinction. The four others to have reached this landmark before me are:

  1. Atahualpa – Really the inspiration behind Suffusion and in my opinion the gold-standard of theme customization, Atahualpa is way ahead on all statistical measures on WordPress: most downloads and most ratings. At the time of writing it has been rated a whopping 418 times on WordPress!!
  2. iNove – Another theme that has been around for quite a long time, iNove has been rated 193 times at the time of writing.
  3. Mystique – This is a really popular theme with WP users because of its catchy design. The only theme younger than Suffusion to have been rated more times than it, Mystique has 140 ratings at this point. Its current popularity will probably ensure that it will go over iNove in the near future.
  4. Thematic – It is no surprise that Thematic is the only free theme that has been in the top 15 popular themes since as long as I can remember, and that is very long! No other theme – Atahualpa, Mystique and iNove included has managed this distinction. Thematic is a very clean and well documented theme framework that most people swear by. If you are a theme developer, look at Thematic (and Hybrid) to see how to do it right. At present Thematic has been rated 111 times.

Though unlikely it is possible that I have missed a few here. So if you are aware of any other themes that should be here by all means let me know.

Thank you users, for using Suffusion and voting for it to let people know that you have liked it!

Jun 172010
 
Announcement

After months of waiting and after a series of Beta versions and Release Candidates WP 3.0 finally came out today. I encourage all of you to upgrade your installations.

Why Should You Upgrade?

Version 3.0 is a significant release that has a lot of terrific features. Here are some:

  1. Menus
    This is arguably the most awaited feature of WordPress. This is  a huge relief for developers more than users as we don’t have to code our themes to provide you with a mechanism to select pages / categories / links to build the menu. As long as the themes offer basic WP 3.0 menu support you are good to go. You can build and structure your menus as and how you want with very little restrictions.
    Suffusion has supported native menus from version 3.5.0.
    It has been brought to my notice that WP pulled a little trick here. In the release version they changed a call ever so slightly, thereby making it seem like menus don’t work in Suffusion 3.5.3 (and a bunch of other themes that claim to support menus). To fix this:
    1. Open functions.php in your theme editor
    2. Search for the line that says add_theme_support(‘nav-menus’);
    3. Change that to say add_theme_support(‘menus’);

    That’s all.

  2. Integrated Multi-User Code
    With WP 3.0 the two branches of code, WP-MU (multi-user) and WP have been merged. You need to tweak a few settings to convert your site from a regular WP site to a WP-MS (multi-site) installation. You can start by creating a network.
    Suffusion can be used for WP-MS and can be made to work with BuddyPress too for a better experience.
  3. Custom Post Types and Custom Taxonomies
    The next big feature for folks wishing to use WordPress as a full-blown CMS is the concept of Custom Post Types and Custom Taxonomies. This offers limitless possibilities. If you have a site where you do reviews of books, movies and music, you can create custom post types for each of those, then associate custom taxonomies to them, like authors for books, actors and directors for movies and artists for music albums. In a theme that supports child themes you can suitably create your own templates for each of these post types and make them appear very different from the regular “blog” look.
    Suffusion added a plugin-like feature to let you define custom post types and taxonomies in version 3.5.3. This functionality will be enhanced in the next few releases.
  4. Native Support for Custom Header and Custom Background Images
    Now theme developers don’t have to code up a bunch of stuff to handle custom header images and background images. Of course, if you are like me you might still want to code up things – coding definitely gives you a lot of flexibility.
    Suffusion doesn’t support this feature at present, but it will, very soon. I couldn’t beat the WP 3.0 deadline, to be honest :-)

Why Shouldn’t You Upgrade?

Simple answer – themes and plugins. Before you upgrade make sure that your theme is tested to work for the theme you are using. I am assuming that you are not necessarily a Suffusion user, so if you are using a theme that is not compatible and you upgrade, you will find yourself on a sticky wicket.

Another reason why you shouldn’t upgrade is if you have some indispensible plugin that is not tested on WP 3.0.

How Should You Upgrade?

If you don’t see an option on your admin Dashboard to upgrade, head over to Tools → Upgrade and then do the upgrade.

There is always the manual upgrade option, where you can download the zip file from WordPress, unzip it and overwrite everything apart from the wp-content folder.

What? No Suffusion News?

Come on! You cannot expect me to sign off without talking about the progress on Suffusion!

I have been busy the last week adding some optimization-specific stuff to Suffusion, like an ability to use GZip compression and minification on CSS and JavaScript. I have been largely successful in improving a lot of things, significantly bumping up the scores on Google Page Speed and Yahoo YSlow. Mind you, YSlow is quite hard to please – Yahoo’s own site scores a “B” grade on its performance test.

I have also been working on a ton of other stuff, small and big. Stay tuned – a new version will be submitted soon.

Apr 122010
 

Today Suffusion crossed a very significant milestone – 100,000 lifetime downloads! Frankly when I had started out I had no clue that I would reach six figures. I have all my users to thank for this.

As is customary I drop in a line every now and then saying what I plan to do for the next few weeks. I will use this opportunity to do the same:

  1. A few more widgets and widget areas. This was something I promised a few weeks back. Broadly speaking, there are a few prime areas where I could let users put in widgets.
  2. Full BuddyPress support. This is something I will actively tackle once WP 3.0 is out.
  3. Full WPML integration. The major aspects of WPML work with the theme, but some aspects are missing, like integration with featured content etc. I will get these ironed out.
  4. Full theme skinning. I recently put in some options to take the sting out of configuring certain aspects of look-and-feel. I will be providing a few more that will help users pick their own images for everything, like widget headers, navigation bars etc.
  5. Typography support for custom fonts. This will help move away from boring “browser-safe” fonts and you will be able to use a wider array of pretty fonts.
  6. Code housekeeping. I read some posts on the web commenting on the general clutter of code in the theme. While I don’t agree with most aspects of the assessments, I will look at cutting out any cruft that I can see. In addition I am going to change the options framework to use WP’s Settings API, moving away from my homegrown approach.

That’s it for now! Thanks to all of you!

Feb 132010
 

One thought I have been wrestling with since the past few weeks is a redesign of the options menu in Suffusion. While the options page is ultra-powerful in terms of what it can do, it looks rather overwhelming. I am not a big fan of the long list of options that shows up when I click on a tab in the menu and I would dearly love to make it cleaner. If only I could come up with a better solution!

When the options in Suffusion were a lot fewer (think release 2.0.x) the interface was perfect. But as the power of the theme grew, so did the list of options. And it becomes particularly taxing on the eyes of the administrators who have to change the options. There is something that is stopping me from changing the structure of the options page and that is the fact that it is incredibly easy to code it up the way I have it. I started a handful of tutorials on how to write a theme options page a few months back. In that you can see how absolutely easy it is for me to add new options, given the modular structure of my code. I simply need to figure out the option type, provide some option values for it and bingo! The processing code is very straightforward and it automatically picks the options and formats them as appropriate.

But as is the case very often, what is easy to code is not necessarily easy to look at. I did a good bit of redesigning during Christmas last year and came up with two sets of tabs, a horizontal set of tabs for high-level grouping and a vertical set of tabs within each horizontal tab. This at least made the vertical list look a lot smaller. But as I continue to add options, that page is again threatening to look daunting. So what do I do now?

I looked around to see how some other themes do this and here is what I saw in two really good themes:

Atahualpa WordPress Theme

The Options Page of Atahualpa

Constructor WordPress Theme

The Options Page of Constructor

Suffusion’s options look to a large extent like Atahualpa’s. However, given Atahualpa’s incredible number of options it too probably faces the same fate as Suffusion to a degree. Where it does gain an edge is in the fact that it uses pictures to illustrate what it is talking about and doesn’t rely on text like Suffusion does. I will be the first to admit that Suffusion’s options are verbose.

The other theme presented here is Constructor. If I were to use one word for the options page for Constructor, that word would be lovely. Its options are much fewer in number than Atahualpa’s or Suffusion’s, but the page is truly nice looking. It makes liberal use of JQuery, and is the perfect advertisement for the adage, “A picture is worth a thousand words”. But here is a catch – every option has been manually coded. This is fine with a small set of options, but it will require an effort of Herculean proportions if I were to adopt that approach for Suffusion.

My feeling is that the options page should be something in between the two styles. If I could figure out a way to automate the generation of pages like Constructor’s, that would be perfect. What do you think? How do you feel I can move to a structure more like Constructor’s?