I recently led an effort at work to make our URL structure more logical. The purpose was to allow our URLs to offer more information about the linked page before users clicked and also to reflect the site structure through the URLs. In usability testing months ago I noticed that some users would click on the logo to return to the homepage—a common enough behavior—but were unsure this actually returned them to the homepage. The uncertainty was due, understandably, to the fact that the homepage URL wasn’t a simple protocol and domain (http://domain.com), but instead had a lot of unnecessary key-value gobbledygook that followed. Even typing in the simple homepage URL would redirect to this unfriendly URL. This was clearly broken, and there was no evidence as strong as watching this same uncertainty occur again and again in each users’ own idiosyncratic way.
In an effort to practice what I preach, last night I did some housecleaning on Contact Sheet. First, I changed the permalink filenames into meaningful, readable slugs. Rather than using an arbitraty number such as 0000117.html, the filename should reveal easy-to-associate clues about the content, like friendly_urls_site_maintenance.html. This is done in Movable Type by using the “dirify” option which loosely turns the entry title into the file name.
Next, I organized the article directory structure by date to make it easier to browse down a level and view entries by day or month. I’m guessing I’m not the only one that edits URLs in the address bar as a shortcut to navigation. MT doesn’t easily allow you to view by year and that’s fairly useless anyway, so it bumps you down to the complete archives if you try to view by year. Including the date in the directory structure or slug also tells the user how timely a piece of content is without having to click.
These changes likely duplicated my complete set of RSS entries in most RSS readers since it changed all entries’ permalinks. The old URLs will still work, they just won’t be updated with comments that are added after the changes were made last night. Had I known how to set these features up from the beginning I would have—changing URLs of content is never a good thing. If this were a professional revenue-generating site, I would insist on redirects. It is not, and I offer my sympathy.
What does any of this have to do with design? Well, it has little do to with graphic design and everything to do with information design. If users know any incremental information about a link, especially when obscurely referenced in an embedded fashion like so, they’ll be that much more likely to find some relevance and click. (Notice the hypocricsy in the last Jakob Neilsen link, even though he talks about domain names and not complete URLs as claimed.) In my case, users will know the date and approximate title of the linked entry in Contact Sheet.
Update
To configure Movable Type like I’ve described above, you can manipulate the directory structure by choosing Weblog Config, then Archiving, and make sure the boxes are checked next to Individual, Daily & Monthly. Then fill in the Archive File Template field like so:
Individual: <$MTArchiveDate format="%Y/%m/%d/"$><$MTEntryTitle dirify="1"$>.html
Daily: <$MTArchiveDate format="%Y/%m/%d/index.html"$>
Monthly: <$MTArchiveDate format="%Y/%m/index.html"$>
I read this Zlog interview with David Shea, and, while I respect his opinion a great deal, vehemently disagree with one point.
Which languages interest you the most and why?This is an incorrect analogy because the designers (engineers) of Photoshop did have access to the code and were in complete control of every behavior in the Photoshop environment. The end user of the design tool shouldn’t care about the underlying code for the same reason that an end user of a web site shouldn’t be exposed to its code. But those designing should care a great deal.
None of ‘em, and here’s my reason.
I spend a good chunk of my day in Photoshop or Illustrator or whichever graphic tool I’m using at the time. The common thread between the various design packages from Adobe, Macromedia, and Quark are that they all rely on underlying data structures (including PostScript in some cases) that enable me to build my imagery with WYSIWYG tools.
Not once, ever, do I even have the option of looking at the code. I’m kept as far away from it as possible, and let the control over it stay where it belongs - in the capable hands of the software.
And that’s the way it should be with the web. It makes no sense for a designer to code; they should design. The fundamental layout of a page should be completely hidden from the person building it, otherwise it stifles their creativity.
I’m making the assumption that code = HTML/markup and not logic.
When you’re designing a web site you’re also (intentionally or not) designing the behavior — the way the page behaves inside the browser and the interaction of the page to the user. How else can you accurately control the design of your product if you’re not constructing the pieces that make up the layout? Sitting behind the coder dictating every nuance just doesn’t cut it. This behavior design comes through subtly in the structure: fixed versus variable width pages greatly affect the design; or blatantly: rollover images, opening new browser sessions in hrefs, etc.
When I start adapting my layout to fit a design I know I can code, the tools are getting in the way of my creativity.
Web design is the only design discipline in which the designer can also build from start to finish. Not in print design (usually), industrial design or architecture are they so lucky. If you follow some variation of the Sketchpad -> Illustrator -> Photoshop -> HTML editor process, eliminating the last step of the design process is not suppressing design, but following it through into a realized product. This amount of design control should not be wasted. Even if it’s just the initial templates to be chopped up and reapportioned by a web programmer, those templates serve as the foundation of the site from which all coding and structure follows. Obviously one should never begin any project by coding HTML.
How would a designer know what was possible as a web design layout without knowing the code? Early in my career print designers would offer advice on specific designs that were not at all transferrable to the web, with (graphical) fonts spanning photos intersecting body copy that was impossible in 3.0 browsers and impractical in today’s updated browsers because they were ignorant to how the pages were laid out and how the code worked.
This is how its still done at design agencies all the time and is a completely foreign concept to me. Throughout jobs at large and small companies I’ve been fortunate enough to have never belonged to a creative team larger than six or seven people and have avoided assembly-line design entirely. Maybe I’m just a control freak — I don’t trust others to fully execute my design vision for a site and maintain structural integrity when the “site builders” join the game in the fourth quarter. But to me, web design is a bridge between art and science where design and code are inseparable elements of the media in which we’re communicating.
Thanks to a little help from Zeldman and liberal use of the w3c XHTML validator, this site is finally XHTML Transitional.
The most uncomfortable part of switching to XHTML (in theory as well as practice) was changing the ampersand-separators in URL HREFs from & to &, thereby changing the URL’s physical location and trusting that all browsers going forward will properly translate this. Even scarier in a Microsoft-dominated world — who knows what they’ll do with standards in coming years. Nevertheless, it was a leap of faith that made me more uncomfortable than I’d like.
The other pesky item: what to do with image alt tags that are soley for aesthetics that have no accessibility value (such as the dividers between the buttons on the top nav of this page). Why must they contain an alt tag, other than for zen-of-perfection reasons to get the designer in the good habit of including them with every image and button? I’ve left them as empty quotes, which Lynx seems to ignore. Otherwise it’s just extra noise for text-only readers.
Other than these minor points, the arguments I’ve read from web standards folks for XHTML & CSS generated sites are overwhelming — the general shift towards XML, the ability to keep content separate from markup code and the bandwidth savings that results from the cached CSS, increased accessibility, wider interoperability of browsers and web devices — there’s really no reason not to make the leap.
Today is the last day to cast votes for the Webby Awards People’s Voice. Nominees that I care about include: Moveable Type for Best Practices, Romenesko for News, and Netflix for Services (even though they could offer more features).
Not that I generally care much about awards, but the site I work for was actually invited to the first annual Webby Business Awards later this year.
After finishing a round of usability tests I was interested to read Jakob Nielsen article today, Convincing Clients to Pay for Usability. Particularly interesting was how to handle the question, if you’re a competent designer, why can’t you create a functional web site without having to test it?
Nielsen then lists these analogies, professionals who require (by law or common sense) their work to be tested before public release:- Software engineers have a test team to catch bugs
- Architects have structural engineers to test their designs, design models for review, computer generated walk-throughs
- Writer have editors to catch grammatical mistakes and structural pitfalls
These projects have a design and test phase in their life cycle. Depending on the type of product, the testing comes either before, after, or during the build phase, whichever will cause the least pain if the design needs to change. With virtually any product, a prototype is built and tested on a sample audience.
Other analogies from the top of my head:- Advertisers conduct vast market research on the client’s target audience before launching large campaigns
- Biologists go through daunting clinical trials before releasing treatments to the public
- Automobile makers conduct crash tests to reinforce safety in their brands and avoid lawsuits.
Sure, no one will die if the UI doesn’t work, but lack of sufficient testing causing a product recall (called a redesign in the web world) is just as financially devastating and can cause months of perceived online stagnation to customers.
In certain rare cases, design can be a life or death issue. I used to work with some of the original engineers of Microsoft Access. On a customer visit to a government contractor, they were shown how Access was used for the launch sequences of nuclear submarines, each advancing page of the sequence one step closer to nuclear holocaust. Who knows what bugs were lurking in the code—maybe MySQL would have been a better choice?
Today I viewed Contact Sheet on a Mac. Oops. The experience was much like noticing that my zipper was down for the last two months—the site’s broken all over the friggin’ place.
Since the company I work for builds client software largely for Windows and Linux, I’d gotten out of the habit of checking my work on a Mac. I was long overdo in firing up the G4.
My half-baked idea of swapping out stylesheets to change themes was largely the root of the problem (although no doubt it was broken before). Using the different colored nav images as backgounds worked on paper, but not on all the current browsers. So I’ll have to hardcode the nav images and if I want to swap themes, write some scripty thing to do the html swapping, or just change directories or some other fancy wizardry. But it won’t be as easy as swapping one line of the CSS.
Which, since the bandwidth issue, I’ve decided to rotate themes on a weekly or monthly basis and take advantage of that CSS and GIF caching.
Updates soon, and enough talk about this site.
One of the common pro-CSS arguments is that XHTML/CSS designed web sites save bandwidth since the designs don’t contain repeated use of tables, spacer gifs and other tricks to tweak layout.
So I thought it interesting that since I moved more in that direction* and also started rotating stylesheets on a daily basis, I’ve seen my bandwidth usage skyrocket per page view. Previously the bandwidth had been ~10KB/page. I started with a new CSS and it shot up to 14KB on Tuesday, then yesterday to 87KB!
This is what I have gathered:- Some of the increase is due to bulkier pages in general. I expanded the number of articles displayed from 10 to 15, making the index.html 8KB larger. I replaced a lightweight version of the header with the full-blown CSS c-clamp on the popular telephone pages, and the header graphic yesterday was also on the fat side at 12KB.
- Users have to load the CSS and GIF set anew each day.
- Users to most blogs, including this one, regularly only view one page each day, the homepage. The bandwidth savings of CSS/XHTML are thinner in these cases since you’re not benefitting from the .css being cached on subsequent pages per visit.
As an experiment I put the rotation on hold. Today, without changing a thing, the average is back down to 24KB (today’s index.html is 22KB), presumeably because yesterday’s .css and .gifs are cached in many users’ browsers. The bad news, to continue rotating the stylesheets will continue to eat up bandwidth until each theme is rotated back in again. But I’m ok with it if my service provider is.
*still nowhere near compliant, and fine with it.I changed the site’s clothes.
But I can easily go back to the previous getup by editing one line of one file, thanks to CSS. Now all I need to do is set up a cron job to rotate skins every day. Since digging deeper into CSS a few weeks ago, all I see are advantages. As long as you’re willing to forgo the slim slice of pie that still enjoys their Netscape 3 browsers, that is. Previously I used CSS for common font styles but rarely anything more. Now I’m taking it on the job, and everywhere else.
Although not XHTML compliant (I’ll bet) I’ll continue to experiment with this site’s layout in the coming weeks to find out exactly what can be done. I’m still fond of tables and am not ashamed to use them. But now I don’t have to go six tables deep to get the right spacing. Oh what fun.
Jeffrey Zeldman talked about art direction vs. design last week, and mentioned something that’s been on my mind for a long time. I’ll quote him at length:
Many design curricula encourage their students to develop a unique visual vocabulary (a style) that can be grafted onto any real-world project, regardless of its audience or message. Most superstars of print or web design have followed that advice. Their work is about their sensibility, not about the product or service. It communicates, at most, that the product or service is cool or edgy.
Design no longer serves the product; the product serves the design. The product is merely a vehicle allowing the designer to express his vision. Thus design becomes a commodified version of fine art (and practically the only version of fine art that pays).
Zeldman lays out an accurate analysis of the current state of web design — look at the web design award winners — the sites are usually highly attractive, stylized, unusable sites, where the potential empowerment of the target audience is usurped as a monument to the designer.
Why, then, is successful art direction hard to find on web sites while stylized self-indulgence appears everywhere?
Obviously, the web as a medium must be utilitarian — you can’t turn the physical pages with your hands, so the UI must be omnipresent. Since standard HTML UI is considered ugly (and displayed differently by each OS and browser), or blue underlined links are inconvenient for a particular design (guilty as charged), the UI is invented uniquely by every web designer out there. And as with any physical product from toothbrushes to sneakers, the design is stylized, ideally, but not commonly, as a continuation of the brand.
The UI makes up most of the visual information that a visitor sees. That’s why web designer is commonplace while web art director is not. Magazine sites can’t fill their index pages with cover images (i.e., traditional art direction) because if people can’t immediately find the table of contents on the web, they’ll go somewhere else. So the role of art direction on the web becomes subordinate — the art direction is in the subsidiary editorial artwork — there are no full spreads.
Even sites that display some degree of art direction in their content (like Salon, Slate and Jugglezine), the UI design still visually defines the site, however subtle or overpowering it may be.
But this is getting beside the point. Because the medium doesn’t allow obvious opportunities for art direction doesn’t mean web sites must be exploited agents for the designers’ commodified fine art. Art direction on the web is about matching appropriate UI style with the brand, setting tone and enforcing consistency across microsites and ad hoc digital media, working with the designer to balance usable functionality and accessibility of content for the end user (no extra plug-ins necessary).
And as with any product from toothbrushes to sneakers, everyone involved must observe the target audience using the site and make changes accordingly. If sites achieve these goals and are still nice to look at, the web will have come a long way.
I finally read through this comprehensive document detailing the BBC redesign last year.
Perhaps the most interesting part is the “digital patina” where hot areas (as defined by more click-throughs) actually get darker and “wear a path” through certain areas of the homepage over the course of the day. This is reminiscent of a sculpture I saw in Portland by Cian where each person who walked by made a small electrical etching in this metal cube. Lo-fi collaborative art. BBC could give its users bumper stickers that read I’m changing the web site! Ask me how!
This kind of real life example of what the BBC put into its redesign is more valuable than most web design how-to guides.