Wordpress isn’t really designed to be used as a CMS. It’s designed for blogging - nonetheless, it’s a surprisingly powerful little content management system, and with a little bit of tweaking you can pretty easily turn it into a nicely flexible system.

One of the challenges that needs to be dealt with is the use of Pages. A “Page,” in Wordpress parlance, is a document which sits outside the blog chronology. For the purpose of a CMS, you don’t really want all of your posts to be chronologically organized. You could rewrite the Post templates and the permalink format to eliminate all date information, which would provide you with a nice CMS-like organization - but would also eliminate the blog function. Realistically, you probably want both.

It’s very easy to create a large number of WordPress pages and sort them into a hierarchy. For presentation, the default WordPress function wp_list_pages creates a very nice nested group of unordered lists. This can be styled using CSS to create either a long list of pages with inset sub pages, or a fancy CSS-driven set of drop down or flyout menus.

So far, so good. If you’ve got 10 pages, a single list is fine. But for larger sites, you’re running into other challenges. A straight list of your 150 pages is ugly, difficult to use, and difficult to navigate.

But the classic drop down or flyout menu has some usability issues. For people with mobility impairments, for example, the ability to use a mouse may be limited - and it takes a fair amount of core source hacking in order to attach the javascript needed to make these menus completely keyboard navigable. It’s easy to make certain that the top level link in each category is usable from the keyboard - so your responsibility is to make certain that the top level category link will provide access to all sub pages.

Again, there’s an easy solution: write links to all your further pages into your document content.

Ick. This solution sucks. First of all, if you’re creating this site for a client, you can’t necessarily rely on them to retain the content you’ve carefully created. Second, it’s very awkward to have to hand-maintain links to every page on the site. Why are you using a CMS if you’re going to have to do this anyhow?

Thankfully, although it’s not immediately obvious, Wordpress does provide a way to access the children of pages programmatically. Using this code, you can simply create a secondary navigation section which provides easily keyboard-navigable links to all pages below those top level documents.

The Code

<h3>
<?php echo get_post_meta($wp_query->post->ID, 'category', true); ?>
</h3>
<?php 
if(get_the_title($post->post_parent) != the_title('' ,'',false)) {
echo "<ul>";
wp_list_pages("child_of=".$post->post_parent."&title_li=");
echo "</ul>";
}  
if(wp_list_pages("child_of=".$post->ID."&echo=0")) {
echo "<ul>";
wp_list_pages("title_li=&child_of=".$post->ID."&sort_column=menu_order"); 
echo "</ul>;";
} ?>

What’s going on here?

First up has really nothing to do with the navigation menu itself. This is a header for the category navigation menu, arbitrarily placed in a level 3 heading element. It’s a little oddly phrased - this is because WordPress doesn’t provide access to Category labels for Pages the same way they do for Posts. Therefore, this is actually sourcing a Custom Field - a feature available in WordPress which gives you the ability to attahc any custom information to a document. In this case, I’ve created a custom field named “category” which contains the phrase I wish to be considered the category for this item. Generally, it’s the link text of the top level link, although you could set it to be anything you wish.

We’re trying to talk about usability, however, so I’m inclined to suggest sticking to something appropriate.

The second block of code is a tricky bit. This if query is checking to see whether the current page is a subpage of any other page. In general, Wordpress has great built-in conditional functions - you can very easily check whether something is a page (is_page() or whether it’s a category page (is_category(). There isn’t, however, an is_subpage() condition. So, this is the workaround - checking whether the current page is not it’s own parent. In Wordpress, pages at the top level of the hierarchy are their own parents. (Let’s not get into genetics, here…I’m concerned.)

Next we’ll use the normal wp_list_pages() function. Again, we’re using the information about the post’s parent in order to determine what pages to list, using the child_of argument to retrieve only the Pages which are children of the current page.

Whoa, there! I see a problem!

Yep, you sure do. At this point, we’re only retrieving child navigation if we’re not on the top level page itself. Well, that’s great. You can get between child pages if you can find your way there!

So that second block of code comes into play. Same idea, except this time we’re fetching children of the current page, without checking whether the page is top level. If it’s got children, great - we’ll display ‘em. If it doesn’t - also great - we won’t.

This sytem does also work for multiple hierarchy levels, although it’s a bit awkward. Here’s what you’ll get with three levels in the hierarchy:

• Top level page, no children: displays category heading, no children. (The category heading could be removed using another conditional statement; I just haven’t done it.)
• Top level page, with children: displays all descendants (children and grandchildren.) Grandchildren will be in a nested unordered list inside the list item for their parent.
• Second level page, no children: displays all sibling pages (pages with the same parent).
• Second level page, with children: displays all sibling pages AND displays the children of the current page, in a nested unordered list inside the list item for that page.
• Third level page, no children: display all sibling pages at the grandchild level.

And so on. This code functions in Wordpress versions 2.01 and above.

Following an article by Larry Constantine, I began a thread at Cre8asite Forums discussing the usability of open source software. The subject of the original article is the advantages (and disadvantages) of open source software - one of the chief weaknesses cited by Constantine is poor usability.

Now, I don’t have the kind of knowledge of open source software to be able to make that kind of judgement. Some open source software I know is quite difficult to use, but some is very easy. Some closed source software is very difficult, some is not. I’m not capable of drawing that line. Regardless of the reality, the impression that open source software is more difficult to use than its closed source counterparts is rampant.

I’m inclined to believe that people involved in the open source usability movement are those who are knowledgeable about the problems in open source projects. After all, it’s probably quite true that most open source projects are developed by engineers and code geeks - not usability experts. Some of these engineers are undoubtedly thinking about usability: but certainly not all. Establishing a movement to improve usability can hardly be a bad thing!

But is this usability challenge an illusion?

Ruud, at Cre8asite, states:

My guess is that poor usability isn’t always recognized as such in closed source though. The difficulty a company has to use that $75,000 CMS is expected: of course such an expensive system is “complex”…

But the strange clickthrough path in a freebie open source project? Bad usability, cloaked functionality…

To what degree do our expectations cloud our judgement? Is open source more difficult to use, or is it just that training and thorough documentation is less available? After all, the thousand hours of training required to install, administer, and use some complex software packages is simply not available for an open source equivalent: there isn’t necessarily a company established behind the product to provide these services.

On the other hand, Rashmi Sinha states:

Open source software projects are often feature driven. People join a project, they want to contribute. How can they contribute - by adding a feature. The user experience becomes more and more complex over time, as more and more features get added.

So open source projects are subject to feature bloat. Well…I’d argue this is equally true of many closed source projects. Many, many software packages add features in order to be able to ship a new version: in order to sell again, they need to offer something more. Perhaps this is less a division between open source and closed source and more a division between good project planning and oversight and bad.

Hat tip to John Rhodes of WebWord.

Sitepoint has recently released their Usability Kit, first edition: a binder containing 400 pages of documentation (usability evaluation and design techniques, forms, templates, blueprints, etc.), a CD-ROM containing digital versions of the contents, and a complete set of “Magnetic Web Widgets” (while stocks last.)

At $197, this isn’t precisely a “cheap” guide to usability: but hey — you get magnets.

Actually, if you’re going to buy this, I’d suggest buying it soon. The free magnetic web widgets could be a great tool for playing with different layout concepts and ideas. Certainly for myself, as a non-artist, being able to throw together alternate layouts very quickly would be nice. You can design your new sites on the fridge!

Judging from the sample download, I’d agree that it’s well-written and worthwhile. Granted, there are dozens of freely available resources for usability out there: but this compilation of documents might make for a great reference. If you’ve got $197 to burn, buy it (at least for the magnets).

On a day to day basis, I deal with W3C standards. However, there are certainly sets of standards (or guidelines) outside of the W3C which are good to be aware of. Thanks to Kim Krause Berg, I’m now aware of another document: Research-Based Web Design and Usability Guidelines, courtesy of the United States Government.

One of the keys which makes this worth noting is those two first little words: “Research-Based”. There’s nothing better than research (and user testing) to provide you with a better idea of how your ideas will go together.

From the foreword, by Dr. Ben Shneiderman:

Guidelines should be more than one person’s lightly-considered opinion, but they are not rigid standards that can form the basis of a contract or a lawsuit. Guidelines are not a comprehensive academic theory that has strong predictive value, rather they should be prescriptive, in the sense that they prescribe practice with useful sets of DOs and DON’Ts. Guidelines should be presented with justifications and examples.

Download it, read it, and absorb it.

Part of building an accessible website is making meaningful choices in the code you use to markup your content. In some cases, this is a very easy decision: <p> descrbes a paragraph, <blockquote> describes a blocked quote, and <acronym> describes an acronym. No problems.

But some issues are more complex: take the calendar. What is the logical structure of a calendar? Is it tabular data? Is it an ordered list? Is it a definition list? All of these are completely reasonable and logically justifiable structures for a calendar: how do you pick?

Tabular Calendar Structure

In a table structure, the columns represent days of the week, rows represent the week number of the month or year. In practical use, weeks of the year are rarely applied. The Vienna (Austria) transit system uses them: buying a weekly pass gives you transit access for that specific week of the year, but I’ve rarely seen them in other applications. Weeks of the month, however, are in frequent use: Thanksgiving is always the fourth Thursday in November, Election Day is the second Tuesday in November.

So, the tabular structure is reasonably well justified. Colloquial language does actually use those data references for the information, so, if appropriately marked up, this seems reasonable. It’s not perfect, however: the layout inevitably means that either the table will inevitably contain data for a previous month, or will contain empty cells. Not the end of the world; but imperfect.

Ordered List Structure

Time is, for most people, a pretty linear experience. As such, dates can very reasonably be structured sequentially. Again, only really usable for single month length calendars, as the numbering must repeat otherwise, but reasonable. This is certainly a data structure in normal use: the 22nd day of October, etc. The list itself could be labeled with the month, each day would be a list item. In addition, the days of the month would be automatically numerically labeled appropriately. Additional data for the day could conceivably be contained in a nested list.

This layout is a less common look for print calendars; so users are likely to be less familiar with it. However, it’s certainly a reasonable approach.

Definition List Structure

The days of a month can be described as the definition of that month: February is a month containing these 28 days. Each day, furthermore, can be defined by the events of the day. From a structural perspective, this is significantly similar to the ordered list approach. Definition lists do have one advantage, however: each list item has an independent definition. Although not necessary for a basic calendar, these could be useful for an events calendar.

I tend to feel that a definition list stretches the semantic association a bit too far: although a <dl> can be applied for a calendar, and with some justification, it seems to stretch a bit beyond the fundamental meaning of a list of definitions.

Conclusion?

Ultimately, there is no one structure which is perfectly suited for a calendar. Dates are referenced and used in a significant number of ways: the visual layout should generally be that of a table, because this is what most users are familiar with. Usability would certainly suggest that familiarity should carry some weight.

My own tendency is to use tables. That is the visual layout I want; and I see a very reasonable justification for the semantics. I don’t believe there are any major hurdles to accessibility, as long as the table has been appropriately designed.

Numerous articles in the last few days have suggested serious problems in either defining web accessibility or in the way it’s handled. Trenton Moss considers the future of accessibility. Alastair Campbell follows up with his own opinions. Gez Lemon and Mike Cherim co-published an article outlining two supposedly opposing views of accessibility at Accessites. Roger Johansson chimed in with his reasoning for universality. And, to cap if off, Mike Davies wrote an excellent (if possibly inflammatory) four-part series declaring Accessibility in Trouble.

All of these articles seem to revolve around two central points: whether web accessibility is about people with disabilities or whether it’s about universal access, and whether more advanced technologies (such as AJAX or Flash) are acceptable for use in accessible web design. These aren’t entirely separate issues: the whole universe of web accessibility is tightly entwined with the use of technology.

Who is Web Accessibility For?

First and foremost, web accessibility is about users with disabilities. It’s my firm opinion that the first goal of an accessible website is to ensure that users who, for whatever reason, are unable to make use of a website using standard user agents and settings, are able to use the website. This includes, amongst many other techniques:

• Providing for screen readers through alt texts, image long descriptions, and appropriate labels
• Using an acceptable default color contrast
• Using acceptable typography and providing the ability to alter text size (through browser settings or website settings)
• Providing appropriate link texts and explanatory information for acronyms and abbreviations.
• Avoid the creation of any access barriers requiring specific knowledge or abilities.

These are the first priorities: they make a website usable (in the sense of “possible to use”) by disabled visitors. A second priority is in making the site easy to use. Is this accessibility? Web accessibility is commonly defined according to the principles espoused in the WCAG. However, this debate seems to reach out more broadly. From a policy perspective, web accessibility means following the WCAG guidelines. But from a logical perspective, some of these guidelines are actually about making a website easier to use for visitors with disabilities. Usability is not identical to accessibility: it supplements accessibility.

Take, for example, the provision of WCAG 2.0 calling for skiplinks:

Blocks of repeated material, such as navigation menus and document headers, are marked up so that they can be bypassed by people who use assistive technology or who navigate via keyboard or keyboard interface. [V]

WCAG 2.0 Guideline 2.4

Bypassing a menu is not precisely an issue of accessibility: it’s an issue of ease of use. I’d say that this is the challenge of making the experience of a disabled user better, rather than possible. Is it any less important? Absolutely not. On the same grounds, I’d argue that any use of technology which improves the user experience is an acceptable part of accessibility.

One key with accessibility is to add features without ever subtracting from the overall accessibility. Many, many accessibility experts will recommend consistently against the use of AJAX, JavaScript, and Flash because these technologies have accessibility problems. I won’t argue against this: these technologies DO have accessibility problems. Are they inherent? Not really. It’s entirely possible to construct highly usable, accessible websites using these technologies: it does, however, take a very high level of knowledge to do it. I won’t do it. It’s not because I am fundamentally opposed to the use of advanced technologies, I’m just opposed to my own use of them. It would be a massive disservice for me to build anybody a Flash or JavaScript heavy website. I don’t yet have the breadth of experience to work effectively with these technologies.

For me, I will continue to recommend against them while consulting, unless the client is also willing to support extensive user testing: the only truly effective way to guarantee accessibility.

Universal or Accessible?

In Part 3 of his article series, Mike Davies states:

The position of disallowing technologies such as Flash stands quite contrary to providing accessible content. Here the goals of universality are conflicting with web accessibility.

Web accessibility has always been about reaching out to disabled people - using what we have at our disposal: technology and technique. Starting with an accessible website, and ripping out the Flash (because there’s no Flash plugin for Lynx) is a step backwards for web accessibility. And yet, this is what zealots want you to do.

Its very reminiscent of the tools that create a text-only version of a website - by stripping out the images and multimedia. Both the concept and the process do more to hinder the accessibility of a website.

He’s got a great point: universality and accessibility are NOT the same thing. Universality, though an acceptable goal, is measurable only in device specific terms. Accessibility is only measurable in human specific terms. The challenge for an accessible web developer, however, is in finding an appropriate balance. Let’s be honest: how many of us really do extensive user testing? I don’t. My clients usually can’t afford it, or won’t spring for it if they can. I would love to be able to, but for now, it’s not a practical approach for me. That simple fact renders Flash an unsupportable candidate for my own development. And, I’ll opine brashly, it should also leave it unacceptable for anybody else who isn’t doing user testing.

I’m not speaking against Flash explicitly: I’m simply saying that accessible Flash is a relatively untested field. It’s not impossible, and for the knowledgeable it’s probably not even all that difficult. (For more about accessibility recommendations for Flash, you may want to read Bob Regan’s 2005 white paper on the subject.)

What Does Accessibility Need?

Well, obviously, more user testing is always called for. What I’d love to see, although I’m not capable of putting it together myself, would be a full scale accessibility study of Flash and AJAX websites which have been specifically designed with accessibility in mind. User testing, limitations, the whole banana. Accessibility needs better awareness of using Flash. AJAX has received a fair amount of attention: articles from Standards-Schmandards, WebAIM, WebStandards.org, and many others have given developers a fair shot at addressing the limitations and possibilities in AJAX accessibility. Flash has been almost entirely disregarded by the web standards and accessibility community. I’d like to see it given an equal chance.

Accessibility does not, however, need a particular agreement on who accessibility needs to serve. At least, not an agreement which refines between “disabled” and “everybody”. In my opinion, a lot of this trouble in defining web accessibility comes from petty bickering on terminology. Fine, some people define accessibility as providing for users with disabilities. Others call it providing for all users, regardless of abilities. Perhaps the second group is better defined as providing universal websites; but I can’t bring myself to be too concerned. Both camps agree without hesitation that they need to provide access for users with disabilities.

Universal web designers won’t use Flash under any circumstances, because it isn’t supportable in some rare browsers (Lynx, for example.). Fine. Does this reduce the accessibility (for disabled users) of their work? I don’t think so: it merely limits the tools they’ll work in. I find it hard to support Mike Davies’ claim that:

If zealots have their way, websites would only use HTML, with an optional CSS for presentation. And yet, this combination of technologies is inaccessible to certain groups of disabled people - certain groups that can be reached with Flash and JavaScript.

I can’t help but be curious exactly what groups of disabled people can be reached with Flash and JavaScript, but not with HTML and CSS. I’ve sat here and tried to imagine that situation; but have had only limited success. I’m imagining individuals with ADD not being capable of sitting still long enough to read a text document; but that’s a problem correctable through content changes. I would love to know what user group cannot be reached using standards-based HTML.

Just in the last few days I’ve been struggling with a design which just wouldn’t quite work the way I wanted. A somewhat unusual layout - four columns, fluid. The problem has been in finding proportions which are successful across the whole spectrum of widths - from 800 pixels to my own 1600 pixel monster. Imagine my good cheer when Cameron Moll writes up two successive posts which directly relate to my problem! Thanks, Cameron!

In fact, believe it or not, this wasn’t a personal favor - just a coincidence. Funny, but I guess the fact that I don’t know Cameron actually reduces the likelihood he was reading my mind.

The first post was on a fairly straightforward question about optimizing design width for 1024px resolution. Now, this doesn’t directly bear on my struggle, since I’m not creating a fixed width design. However, it does raise one important question: do we need to use the entire width of the screen?

That was one of the biggest problems I had: at extremes, the layout just looked crummy. It worked; you couldn’t say that it fell apart, but it didn’t look right. But why use those extremes? Oh, yes…because IE6 doesn’t support min-width and max-width. (IE7 may not be perfect, but it sure is an improvement.)

So I picked a max-width: it may not be relevant in every browser right now, but it should age well.

The second article was also quite interesting: Should all sites be fluid?. Ah…tough one. "Should" is a difficult question. How to address it? The original article and comments attached to it are largely considering the question from a designer or publisher’s perspective: but I want to think about the user’s experience. Are there actually sites which can benefit the user by using a fixed layout?

So…that’s a question I can’t answer.

I’m trying to think of a concrete reason that a fixed width would be advantageous for a site. I can see how a poorly-designed fluid site would be a problem; but I’m going to operate on the assumption that we’re only talking about fluid designs which don’t have obnoxious problems such as text being covered at very small widths, etc.

Neither Cameron’s original post nor any of the comments name a specific reason that a fixed layout is better. There are plenty of reasons why one might choose to develop a fixed layout inside of fluid - and I’m certainly not disputing that there are perfectly good reasons to develop fixed layouts. Faster development and testing is pretty clearly advantageous where budgets are concerned. But these are advantages to the development team and to the company paying for the work: not for the user.

John Dilworth makes an interesting comment:

Do I want and need the user to control that part of the experience? Or, does the designer need to control that part of the experience?

Are there situations where designer control trumps the user’s choice? John’s point is that there are content-oriented sites which may benefit from designer control of the text. But I don’t see how this plays to the advantage of the user. The designer can’t determine that he will automatically provide short line lengths to users who prefer it and long lines to others. Only the user can actually make this decision.

Mark Boulton talks about how proportion is a key element of a design, and one of the big problems designers have in creating flexible designs is the loss of control on proportion. Your design ceases to be a unit and becomes a spectrum. What he would like to see (and I don’t argue) is the ability to expand the proportions along with the canvas. This is a problem with em based designs - although the view expands effectively when the text size is increased, the size of the viewport is ignored. Finding an effective way to combine text-based sizing with viewport would be highly valuable, and perhaps would encourage designers to pursue fluid designs.

Regardless, there’s nothing conclusive which indicates that a fixed design has user benefits. It appears to have significant advantages from the perspective of designers, but less certain from the user perspective.

If anybody can suggest a good reason - for users - that a website design should be fixed, I’m very curious to hear it.

And no neutering jokes, please.