Goals

What I think the site should do/could do better, and can be delivered by a theme (plus a few modules).

IA

I really like the Work/Rest/Play concept of the current site, but it's only sketchily implemented. I want to make the sections much more strongly demarcated, and clarify that LEO & DEO are part of Work. Thus the Articles/LEO/DEO links are secondary links; FAQ/Jobs aren't - they belong on the Articles menu, and no higher.

Layout: Authorbox

The authorbox position has always been a bit of a pain — it makes it very hard to have anything but paragraphs of normal text at the start of an article. So, if a wider layout is available, let's move it out of the article body.

Layout: Sidebar position and rationale

There's no strong rationale for why the sidebars are where they are, or which blocks go in which sidebar — it's all a bit arbitrary and that's the way it is. The rationale should be a hierarchy of columns, in descending order of significance. So the content is the key, and comes first. Then blocks that give significant functionality (ie all menus and admin functions). Then additional info.

Categorisation Improvement

Our current categories are too broad, particularly with the number of articles we now have. While articles may be in multiple categories, this is rarely used. The free-tagging and tag cloud used in Flickr and elsewhere is a much better way to locate significant content categories, and can be used for technologies and subjects that matter to authors. It also means we don't have to recode the site (or worse: put off potential authors) every time there's a new technology in the industry.

Code Blocks

In evolt 2.0, we re-rendered <pre> blocks to fixed height textareas. In 3.0, we expand them to full height of the script. Each has advantages and drawbacks - if you want to read the code, the 3.0 full height style is best. If you want to read the article, then long code blocks get in the way. So ideally, the choice should be the user's. Drupal4.7 has sexy draggably resizable textareas in forms, via unobtrusive Javascript. So I repurposed the script (basically, pointed it at <pre> elements, not <textarea>, and removed the class sniffing) to enable this.

Finding related content

To keep new users on the site, the expanded categorisation will help them find related content to what they came for. But I also want to enhance this further, with a Similar Entries list.

Spreading the Word

We have pretty good Google Juice, but I wanted to make it easier to submit an article to aggregator services used by our audience. So there are links in the article footer to Digg, Reddit, Delicious and Technorati.

What Is This Place?

Our front page doesn't do a great job of saying what evolt.org is about. While the idea of the typical Splash Page sends ugly shivers down my spine, I do think we can do better, particularly for new arrivals. Derek Powazek's Home Page Goals article was instructive here. This one bit the dust through lack of time.

Building a Global Community

I wanted to build a better sense of who the people are. Author avatars are all very well, but only authors use them, as they're only shown for article authors. So I've added them to comments.

Years ago, Javier suggested a map showing where people lived, and demonstrating that we're more global than you might think. Demos were built (by Dean and others), but it never actually reached production. With the advent of Google Maps, and a module to tie it into the Drupal user model, we're there (although Google's mapping of South America is woeful - sorry Javier).

Content Admin - new articles

At present, Content Admins make the newest articles Sticky to highlight them. This is a manual process, and as we don't like to have multiple articles highlighted, Admins have to un-Sticky the previous article. This is a PITA for Admins, and makes them more reluctant to actually do the work. Additionally, having only one highlight lever means we can't resurrect older articles. If new articles are automatically highlighted based on date, Admins only have to manually highlight (via Sticky) resurrected/significant articles.

Valid Code

Do I need to explain why? Anyway:

XHTML Strict because Google Maps apparently requires it.

Branding

Colours

I wanted to keep the RGB theming, and keep it tied to the major site sections. I've tweaked them to make them a wee bit sharper. I've also (quite deliberately) not specified the normal and visited link colours as a nod to Mr Nielson.

Logo and top area

Not much done to the logo. A bit of extra lightened shading, and (if you have full alpha transparency support for PNGs) a wee drop shadow is all. I've also retained a version of the top black bar which has been with us since December 2000.

Positioning Statement

On the earliest versions of the site, we said:

What evolt.org is: A world community for web developers, evolt.org promotes the mutual free exchange of ideas, skills and experiences.

What "evolt" means: "evolt" combines the best elements of evolution, revolution, with a bit of voltage thrown in for good measure. "evolt" embodies our goals and enthusiasm!

More recently, we've had the confidence to drop the What evolt meanssection. I've split this into central Who we are bit, which is now promoted to the page header, and the expansion of What we do is left in the footer.

Layout

Page Width

General web audiences may still have a large number of users browsing at 800x600. However, our audience are much less likely to do so — generally, they will be web professionals, with large and/or dual monitors, running at fairly high resolutions, or at the least, laptops running at 1024px wide.

Add to this, our audience crossover with ALA, who went widescreen almost a year ago, and you can infer that there should be no problem setting the standard page width to 1000px - just wide enough to fit in a fullscreen 1024px-wide screen without scrolling.

However, to allow some graceful, degradation, the main content of this theme is designed to fit in 640px without scrolling, and the first sidebar column fits in 800px. The rationale for sidebar choice of blocks is therefore that the essential functional sidebar blocks are in the left column, and 'additional information' is in the right.

Browser targeting

The principal browsers successfully tested and supported are the ones most widely used by web developers:

Internet Explorer 6/Windows

Our audience will almost certainly have kept up with the security updates - unless they're still on Win9x, this means IE6.

Firefox 1.5/Win, OSX, Linux

This is probably the standard browser for members of our audience with a choice.

Opera 8.54/Windows

The likely other browser of choice for our audience. Is pretty good using the small screen option (some top tabs wierdness), but likely to be perfectly usable on Opera-using mobile phones/PDAs.

Safari 2.03/OSX

The standard browser for OSX users since IE stopped being supported. The adoption rate for Tiger (and indeed Intel Macs) suggests that this is now the canonical version.

Lynx

And all screenreaders

Also tested:

IE5.2/OSX

Layout works. Javascript enhancements don't work, but have degraded gracefully. Most admin functionality inaccessible, but that's because of Drupal 4.7's forms.

FF1.07/Linux (as per Ubuntu/Kubuntu Breezy)

Layout works fine. The Javascript features all work fine.

Konqueror 3.4.3

The standard browser on KDE, and therefore most Linux desktops (including Kubuntu, Linspire & Xandros) that don't have FF as the standard browser. All seems to work fine, although lack of drivers for graphics cards mean the dropdowns aren't quite as smooth as elsewhere. There's also a ~5px horizontal scroll at 1024px, but this may be because the KDE scrollbar widgets are a bit wider.

Not Tested

IE7

Show me an RC, with a locked rendering engine, and I'll consider it. Until then, it's probably too unstable.

IE5.5/Win and lower (and browsers that use it as a rendering engine)

Anyone running this is already in a world of security pain - I have severe doubts whether anyone in our audience (which is different from users who visit our site: I'm talking about actual developers) is using as anything but a curiousity and/or testing tool

Pre-Firefox Mozilla/Netscape

Like IE5.x/4.x, any member of our audience using this as their main browser is surely doing so out of perversity.

Javascript Usage

Principles

Javascript is an enhancement to functionality, not a replacement for it.

Javascript may make the theme prettier (rounded corners), faster (form validation, Livesearch) or generally sexier (drop down LEO & DEO content), but not replace any functionality.

Javascript is delivered unobtrusively

There are no onclick handlers in the HTML. Content only shown via Javascript (those dropdowns again) is loaded via JS; non-JS users aren't bothered with the extra download. This also ensures that there is less code to potentially break HTML validation.

Wherever possible, avoid custom coding

Most of the functionality is delivered by 3rd party libraries (principally Prototype, with libraries that build on it, including script.aculo.us and WForms) to ensure better validated scripting and cross-browser support. The very small amount of WEO-custom coding is therefore easier and quicker to test, while producing sophisticated enhancements.

All code is compressed

To reduce the bandwidth requirements, all production-linked scripts will be put through the Dojo compressor. These will be linked from /themes/weo/scripts/lib directory, while copies of the original source of the scripts will be kept in the /themes/weo/scripts/src directory.

All UI enhancement scripts are brought in via a module

This is to support disabling them via the Throttle module ie when the server comes under heavy load. With a bit more thought, this approach could be applied to sections of the CSS.

How it's Done

LEO/DEO dropdowns

These are HTML fragments, loaded asynchronously by AHAH using Prototype's Ajax.Updater API. They could be produced from Drupal pages, as Prototype broadcasts its own UA — we would conditionalise all the non-content accordingly. They're shown and hidden using a scriptaculous effect - Phase. This is a nicely toggling user-submitted effect, so I've added it to effects.js.

Curved Corners

Just about always produced using Nifty Corners (the exception being the comment speech bubbles), with nary an image in sight. This means it's very easy to produce colour variants without all that tedious messing about cutting new corner images.

Resized images for Comment Avatars

Produced using PHPThumb from the original user images. This is essentially a PHP frontend to ImageMagick/GD. Either will work, but it's best with both. Should probably use this for the authorinfo box too...

Acknowledgements

Tools

using:

• skEdit text editor
• Photoshop & Illustrator CS2

Sources

Code I've borrowed, libraries and modules I've used. Most of them are mentioned above, but here's a full list

Drupal Modules

• Aggregator
• Comment
• Contact
• Drupal
• Excerpt
• Forward
• Front Page
• Gmap
• Gsitemap
• Help
• Locale
• Menu
• Page
• Path
• Ping
• Porterstemmer
• Profile
• Search
• Servicelinks
• Similar
• Statistics
• Story
• Tagadelic
• Taxonomy
• Throttle
• Upload

People

• Adrinux for PHPTemplate help, Drupal experience and design suggestions
• Morbus and others on #drupal-themes and #drupal-support for Drupal goodness
• Genghis for design suggestions, opinions, and reminding me of the power of the grid
• Tara and other #evolters for encouragement