February 9, 2007
Dear Colleague In The Design Biz...
I notice that you redesigned your website recently; I saw your old one months ago. I love the new aesthetics, but — well, not to be critical, but I’m wondering, why have you chosen to go all-Flash? You do realize that Google and other search engines can’t index your site now?
I know that maybe it’s not my place to say anything, but…I’m an Aquarian, we’re known for brutal (if friendly) honesty, and it’s my birthday on Tuesday, so….
My experience and a lot of well-founded research suggests that all-Flash sites are suitable only for fine artists or rock bands, i.e. web situations where searchability, usability or making money isn’t a prime concern.
From an end-user standpoint, it now takes anywhere from 13 to 21 seconds to go from your initial page load to being able to see content — that’s a long time, an entire TV commercial’s length almost… Most people now expect to see content immediately upon page load. To do otherwise is like opening a boutique and demanding that people who walk through the door listen to your life story before being able to shop.
Flash is also problematic because it requires a fixed pixel size, and with an aging population whose vision is collectively deteriorating, the ability to be able to zoom a website’s font sizes is critical. For some who are partially sighted but are dependent on screen-reader software, Flash is impenetrable (and before you protest that people with visual disabilities won’t be browsing your site, remember equal-opportunity hiring in government and institutions… I myself am only 36 but my vision is just bad enough that I find myself zooming websites constantly.)
On top of that, Flash pages within a site cannot be bookmarked (not in an effectively universal, cross-platform way, anyway); the Back button in the browser usually doesn’t work; and they don’t print properly.
This “impenetrability” is critical when it comes to search engines. Google and Yahoo and other search engines simply cannot parse the text and images inside Flash sites, so anyone searching for a particular case study won’t find it. As web critic Vincent Flanders has noted, Google is God, Don’t Upset Her!
So, positive suggestions time:
Because I know that it took a lot of time and effort to create the current site - one thing that you can implement now that would cut down on load time, is a cookie that remembers the language preference upon initial loading, then people can skip that screen automatically and go straight to the appropriate content area.
If I may humbly suggest this — next time you’re revamping the site, maybe months or years from now — a standards-compliant xhtml+css site will provide more utility to both end-users and search engines alike.
There are hybrid techniques such as SiFR that let you use your favourite fonts inside a standard page, still searchable, but that are dynamically replaced on-the-fly with Flash, for the best of both worlds. Embedded flash content such as slideshows (SlideShowPro is a good tool) inside an HTML page are much more user-friendly, too.
We’ve found these techniques to be a winning mix for our clientele, because a surprising amount of traffic and clients come from people finding their sites via Google, Technorati, MSN Live Search and other keyword-based search engines; it really doesn’t pay to shut them out for the sake of visual aesthetics alone.
Footnotes
Jakob Nielsen, Nielsen Norman Group, Flash 99% Bad.
Vincent Flanders, When Good Flash Goes Bad.
James Ambrosio, How Flashy Web Sites Can Turn Off Customers, Wall Street Journal
Jay Goldman, All Flash=Bad, Radiantcore.com
Posted by aj_kandy at 11:34 PM | Comments (2)
September 20, 2006
Your next user interface: Big and flat?
I never thought I’d be saying this, but I miss Windows 3.0. I don’t miss its bugginess - I miss its flatness.
Longtime Mac users miss the “snappiness” of pre-Platinum Mac OS releases, too, though not their crashiness. Back in those days, a lot of the UI was hardcoded in the Mac ROM, which accounted for a lot of the system’s illusion of speed and responsiveness - the “feel” of the Mac that made so many users die-hard fans.
Today, most desktop UIs feature pseudo-photorealistic interfaces that pretend that there is a light source, shadows, highlights. There are buttons that look pushable, bevelled edges on windows apparently carved of brushed metal or shiny plastic. Does all that help the user, or does it get in the way?
It’s an important question to answer; with Vista and Leopard all but here, the paradigms of Aqua and Aero — a desktop world of drop shadows, tabs, Spaces, translucency effects, animations, cube transitions, 3D window stacks and other gewgaws — are now the “establishment” view of how you are supposed to interact and view information on a PC.
Of course, the wheels never stop turning. Just as small-W windows replaced blinking cursors and green-screen text interfaces, single-purpose web applications offer radical simplicity. And even on the desktop, the utility of the multiple-window, multiple-palette application may be close to an end. With interfaces often taking over the whole screen, are we moving away from the idea of “windows,” altogether?
More after the jump.
From a personal perspective, I think flatness is slowly winning out.
I’m looking at Mac OS Tiger as I write this - with its stoplight buttons and blue-plastic scrollbars, the slight glassy bulge in the main menubar, the liquid-droplet look of word balloons in iChat, the brushed metal window frames, the slight gradients absolutely everywhere. And I’m starting to hate it. My eyes hit it and slide off; it’s getting in the way of perceiving information.
I’m not a fan of Windows XP either because it does that same look in an even less subtle way; the screenshots of Aero that I’ve seen resemble a Gnome theme kit designed by someone who plays Doom a lot…
Now look at that screenshot of clunky old Windows 3.0 up there. By comparison, Doesn’t it look clean, simple, friendly and inviting? Doesn’t it look a lot easier to control?
I’ve been playing around with Ableton Live, recording software that has its own interface - one that I think many apps would do well to emulate. It operates nearly entirely in its own single window that takes over the screen; it eschews glossy 3D-ness for a radical flatness - rotary knobs are represented by a circle with a line-pointer in it, for instance.
Panes for tutorials, rollover help, file browsers and more can all be shown or hidden at will, compared to the myriad toolbars, palettes, and button-rows of other programs. Its responsiveness is unsurprisingly very good. No gradients; no shiny; it just works.
Why does it work? It obeys a lot of UI rules - Tufte and Fitts and all that stuff. Important things are appropriately large and central, lesser things are small and off to the side, or hidden if desired. Nothing gets in the way of just getting in and doing stuff. It’s un-modal to a great degree, lending it the feel of a real tool rather than a central bureaucracy that demands the proper papers first.
Are there lessons we can learn, there? I’m not saying we have to throw away all our eye candy; but maybe we can learn to use it in a way that really enhances usability, instead of just marketability.
For instance, if we could have the UI speed and responsiveness of OS 8 combined with all the under-the-hood power that OS X delivers - what would that look like?
Posted by aj_kandy at 12:42 PM | Comments (2)
April 25, 2006
37signals does Patterns, too
How could I forget Ryan Singer’s article on design patterns over at Signal vs. Noise, the 37signals blog - although to be fair, he doesn’t get much into the concept of patterns themselves and why they’re useful. From the comments thread, a reader suggests the book The Design Of Sites: Patterns, Principles and Processes for Crafting a Customer-Centered Web Experience. And browsing quickly through Amazon, I note the upcoming O’Reilly book Ajax Design Patterns by Michael Mahemoff, which should be a great companion to Jennifer Tidwell’s book mentioned earlier.
Posted by aj_kandy at 10:45 AM
April 23, 2006
Pattern Languages for the Web, part III
As usual, I’m not the first to think of these things; a quick sweep of the Interweb reveals a slew of IA, HCI, design and development sites with repositories of design patterns. Here’s a few.
- The University of Italian Switzerland hosts 28 design patterns under the categories of Interface and Layout, Structure and Navigation, and Content. They also have a showcase of practical applications of patterns for diverse kinds of sites and desktop apps.
- As previously noted here, Yahoo! open-sourced a lot of their UI library, but I missed the fact that they published a series of design patterns for developers, too.
- MIT’s Jennifer Tidwell, author of the O’Reilly book Designing Interfaces, published Common Ground, a pattern language for human-computer interaction. back in 1999.
- Martijn van Welie’s patterns list.. Note there are also pattern pages here for GUI design and mobile interfaces.
And there are many, many other sites with such patterns available, far too many to link to in one post; there are, however, some great repositories of these links:
- Tom Erickson’s Interaction Design Patterns list.
- The IAWiki’s list of sites about design patterns (some of which are reproduced here).
- The CHI 2006 conference is going on right this minute here in Montreal. They have ongoing workshops and forums on design patterns. (Conference blog here.) In the past, they’ve discussed work on creating a single, unified repository to manage collections of design patterns.
Posted by aj_kandy at 11:01 AM
April 20, 2006
More About Pattern Languages
Adapted from an ongoing email exchange with Andy Rutledge, which helped clarify my thinking a bit.
What threw some people off about the initial post in this series is my use of the word “design” — which I use in the sense of industrial design: how it all works together, to solve a problem.
For example, in the history of the automobile, it’s taken 10,000 years to go from the discovery of fire to the launch of the Toyota Prius. We have an accumulated body of knowledge about all aspects of the process of building and using cars, from basics like woodworking and metallurgy to the invention of the assembly line, time-and-motion studies, robotics, ergonomics and visual perception studies, modern road-building techniques, safety studies, traffic studies, etc….Without design patterns, we’d have to reinvent everything from scratch every time we wanted to go from A to B.
To further the analogy, consider the fact that the “user interface” of most cars are surprisingly identical, including the placement of pedals and controls, even down to the little icons on those buttons and controls — while the size, power, type of engine, fuel and exterior styling may vary dramatically. Are these design patterns at work?
Christopher Alexander-style design patterns are not rigid templates, but really a kind of interactive, context-sensitive rule. It’s like an IF:THEN routine, which in turn suggests others down the branching program execution, if you want to get nerdy about it. In any case, Alexander and his team derived their urban design patterns from the observation of how people actually behave, and how they use places, things, and systems. Here’s the titles of a few of them:
- Try to have light on two sides of every room.
- In the house, make sure there is a sunny place.
- Vary the ceiling height depending on the use of the space.
- Make one room of the house be an “outdoor room”.
- Ensure that the depth of the balcony is at least six feet
The “why” of these rules are explained in his books - I invite you to read them. He and his team have literally hundreds of these patterns in his books, derived from observation and research of patterns of house, neighborhood and town building worldwide.
Obviously not every house has to use all the rules. And the rules say nothing about the choice of forms, materials, styling and decoration, I’m sure things adapt to suit their locale. Two houses that followed the exact same subset of rules could still end up completely different, according to their owner’s needs and tastes.
The thing they share is that the patterns help make them sensitive to their immediate context, internally consistent and user-friendly, a solid core from which to extend, and retaining a kind of timelessness that is immune to fashion or fad.
It’s no coincidence that the software industry has embraced the idea of design patterns as a way to stop “reinventing the wheel” every time they want to do things. In essence, certain things are “known to work” and therefore, unless they’re building some kind of Myst-like puzzle game with mystery meat navigation, a programmer ignores them at their peril.
Those of us who work in the Web biz, which is making fledgling attemtps at professional standards, have to work in a world where the tools of the Web are democratically accessible: full of self-taught designers still making their first 1000 mistakes, often in public. (I include myself in this.)
I believe it would be supremely useful to have a series of pattern languages for web design and development, as a repository of things and practices we know to work well, in order to build a more humane Web. I imagine some sort of wiki encompassing everything from abstract notions of form to specific snippets of code.
Andy Rutledge suggested that applied design fundamentals were more important than design patterns. I think it’s supremely important that people working in the field have them, but I also noted that the concepts contained within the pattern “applied design fundamentals” ARE design patterns themselves:
- figure/ground contrast
- Minimum font sizes and line lengths for optimized readability
- When to use serif fonts, and when to use sans-serif
- Concepts of colour harmony
- The use of red, yellow and green in user feedback, (combined with symbols for the colourblind, and audible warnings for the visually impaired).
..yadda yadda. Each of these concepts has a little rule of thumb or suggestion behind it…which comes from centuries of real-world use, adaptation, experimentation and experience. We don’t think of them as design patterns, we think of them as “obvious.” Well, as I noted in 2004, we wouldn’t consider it obvious for an architect to put light switches 9 feet off the ground, but Web developers who should know better do the equivalent all the time.
Posted by aj_kandy at 10:03 PM
Before we continue, let me say just this
Joe Clark and Andy Rutledge express some concern that I’m confusing “web development” with “web design.”
I respect and admire these two gentlemen’s work tremendously, but I think both of them are misunderstanding where I’m coming from, and I’m probably to blame for that for not being clearer from the outset.
So here goes…
To Joe and Andy, there’s a clear line between development, aka back-end coding, and design, aka user experience design.
Of course they’re two different things, but to me and the Great Unwashed mass of actual web users, it’s a distinction which makes no difference; they are both aspects of the process by which web sites are created, in the popular understanding, this is “web design.”
Perhaps this popular terminology is inadequate to describe what coders and UX people do; I’m sure that some hardcore back-end coders would sniff at being called mere “web designers.” But poorly-designed backend will affect the user experience and vice versa; they are two halves of a whole. To the end-user, it either works or it doesn’t; on a larger scale, either it solves their problem or it doesn’t.
If there’s a distinction that I feel needs to be drawn, it’s between best practices in visual design, i.e. layout, from issues of aesthetics, i.e. styling. UX design is not decoration! It’s a bit like confusing the field of commercial interiors or space planning with interior decoration - really not the same thing at all.
In any case, I’m far from claiming to be an expert, I’m standing on the shoulders of giants here. Really, this is an exercise in collecting a lot of dispersed information and trying to synthesize it in a clear, meaningful, objective and articulate way, in order to translate what I instinctively feel to be correct but maybe didn’t have the words to explain before. It’s as much a learning process for me as anything else, not some grand declaration of what is Right and Wrong.
I’m using the concept of design patterns as a way to present these findings in small, interrelated, modular concepts, groups of which can be applied to any particular project. Ultimately I’d like to create some sort of repository of patterns (probably as a wiki) if people think it’ll be useful.
To those who are unfamiliar with design patterns, the books A Pattern Language and The Timeless Way of Building (by the architect Christopher Alexander et al) are the best source material. There’s also an online collection of urban design patterns here if you want to get a feel for the format.
If anyone would like to contribute relevant ideas or links to the discussion, correct me where I go wrong etc, I’d welcome it.
Posted by aj_kandy at 10:48 AM | Comments (2)
April 18, 2006
Pattern Languages For Web Design & Development
Formerly titled: What is Good Web Design?
UPDATE 2. Oooh boy. I think the title is throwing people off…still. Let me change this and make some edits for clarity…to reflect the real emerging focus of what I want to talk about here. Also, if you haven’t already, please check out the post linked in Update 1, below, and there’ll be another one specifically about Pattern Languages up momentarily. Isn’t evolution fun, kids?
UPDATE 1. If you’re coming to this article from Andy Rutledge’s DesignView, welcome! And please have a look at this bit of clarification before coming back. Like life, blogs are a work in progress…please comment as much as you like, let’s keep it constructive, that’s all I ask.
Three blog posts got me thinking about the idea of “best practices” in Web design lately, from three different perspectives: process, standards and user experience design.
- D.Keith Robinson talks about differing web design processes, although the post digresses into a discussion of different working styles - how formal and informal, off-the-cuff or rigidly documented things get depending on the client.
- Joe Clark’s rant (possibly NSFW) about the general cluelessness of the Toronto web design community when it comes to even basic standards, much less accessibility. (via Boris)
- Lea Alcantara’s questioning of how we often justify our web design decisions on rather shaky empirical grounds.
In reading these essays, I feel like the Web world, as young as it is, is still grasping, making things up as it goes along, constantly reinventing the wheel. As commenter Joshua notes below, we’re still in the trial-and-error phase and the underlying technology is in constant flux. A few brave souls beat the drum for standards (Zeldman, Bowman, et al), people looking to solve their own problems invent tools and give them away, where they become widely adopted (SiFR, Textile, etc.).
But it’s still a kind of free-for-all. Unlike, say, graphic design or typography or even mechanical engineering, where hundreds of years’ worth of accumulated knowledge informs the practice, Web design has a scant decade or so behind it, and its democratic practice means that thousands of amateurs are out there, making their first 1000 mistakes at any given moment, in public.
I left a comment on Lea’s blog to the effect that it seems like we’ve moved awfully fast; the “printing press” was just invented yesterday but we’ve already leapt to David Carson-style deconstructed design without passing through the intermediate stage of defining a classical school of practice, as embodied in a pattern language.
Design patterns are essentially responses to consistently recurring problems; a very specific set of “best practices,” to invoke an overused phrase. They originated in the field of architecture and urban planning, and have since migrated to the software field.
To dispel any notions that this implies cookie-cutter design, pattern languages are collections of small, interactive, context-sensitive rules (or algorithms, if you prefer) that suggest a known, good way of doing something, without specifying form, materials, colours or other stylistic choices.
In the narrower sense of web design, design patterns exist for everything from the micro level, such as choices of style and colour, to internal mental models of how web pages are constructed: concepts like “divs,” “blockquotes,” and “ordered lists,” for example; the “expected” ways that browsers are meant to interpret these items are themselves design patterns. Pattern languages also encompass higher levels of order such as how best to prioritize headlines, columns, navigation elements, footers, graphics, and so on.
I don’t claim to be any sort of expert, but I do feel that the pattern-language concept could be useful for web designers and developers, and as time permits, I’m going to explore this further: I welcome contributions, constructive criticism and corrections.
Posted by aj_kandy at 10:24 PM | Comments (4)
March 19, 2006
Stupid login tricks and the quest for single-sign-on
Today I spent an inordinate amount of time banging my head against Hour Magazine's online registration system.
I had gone there to leave a comment on YULBlogger Dave's review of the special-edition DVD of What The ßlSSp Do We Know...?, did the usual signup ritual, only to get an email back claiming that my name was not my "true name," and that they didn't accept "pseudonyms or virtual identities.*" Wha?
I've signed up for dozens of sites using A.J. Kandy and never once encountered a problem. What's the deal with Hour.ca?
One, How does Hour's server know what my "real" name is?
Two, What programmer would code a cockamamie system like this?
I understand that newspapers need demographic information they can give advertisers. The geodemographics game is so finely targeted now that you can target subsections of single zip codes if you want; I expect with uber-personalization, one day the flyers in the newspaper will be targeted to you and you alone.
But this is ridiculous. One one hand, how do I balance my right to privacy (and to even write pseudonymically, if I choose) vs. my desire for access to closed systems. And on the larger question, how else are you to prove that you are who you say you are, short of providing credit card or social security numbers (which themselves are not foolproof?)
There has been some push towards the goal of a universal single-sign-on system, one that would ideally balance your privacy rights with the owners of sites' desire to collect aggregate demographic data; however, very few have gone beyond relatively limited spheres like Yahoo! IDs, TypeKey authorizations, or MSN Passport logins.
If such a system were to be built from scratch today, what features could it (and should it) have? I look forward to my readers' cogent insights.
*And, it must be mentioned, when trying to view their name criteria page, their IIS server threw up a VBE error and died, so no help there.
Update: After human intervention, my signup was finally approved and my comment posted. Apparently the "real name" requirement is for Hour's auctions and contests, where you need ID to pick up your winnings. I still maintain that it should have accepted my name at face value, and in any case, I wasn't signing up for a contest, was I?
Posted by aj_kandy at 7:49 PM | Comments (2)
March 1, 2006
Use and Usability: Yahoo Open-Sources UI Library, Design Patterns
Interesting news (via the Web Standards Project) - Yahoo recently open-sourced huge chunks of their UI code, lots of libraries for doing nifty in-browser DOM / Javascript / AJAX stuff.
So will drag-and-drop shopping carts become the new Flash intro? Not if you follow the eminently sensible Yahoo Design Patterns, a series of behaviour standards and interface designs intended to help improve the Web experience overall, no matter what tech lies underneath.
Also, check out the Yahoo User Interface Blog, at yuiblog.com..
Not to be confused with YULBlog. Which reminds me, it's First Wednesday. See you there!
Posted by aj_kandy at 2:37 PM
August 26, 2005
Friendstr 2
So my earlier Friendster redesign post actually garnered some interest from the company itself. One of their product managers emailed me and we had a nice little chat. Very cool people.
I can't really talk about what we discussed, but they liked our little design experiment a lot. I wish I could say they saw it on this blog; it turned out someone there found it through Flickr and passed it to the higher-ups. What's amazing is how fast it happened. It's either a case of the right information getting to the right people at the right time, or someone having a very extended sensor network on the Web.
The one question I have is, with the Flickr gallery getting nearly 400 total hits, why has nobody commented? I suppose if they're all from Friendster Inc. they're not allowed to – NDAs and all that. Too bad Flickr doesn't have referrer stats like TypePad. (Hint hint, Stewart.)
Posted by aj_kandy at 12:25 AM
July 30, 2005
Friendstr: UI Case Study
I started using Friendster a year or so ago. It was instantly addictive: at one point it was almost a game of one-upmanship to see who could have the biggest friends list and who could get linked (via a friend of a friend) to some celebrity or other. From a practical point of view, it had good basic features like messaging, message boards and a sort of tag-based search function.
In 2004 Friendster got the first of several additions and revamps to deal with its booming popularity. The underpinnings moved to a faster PHP-based dynamic system, and new features were added such as groups, horoscopes, job searches, chat functions, and photo albums. Jumping on the blogging bandwagon, Friendster brokered a deal with Six Apart to incorporate TypePad-powered weblogs into their service.
The interface design, on the other hand, was, and is, pretty haphazard. There were plenty of boxes-within-boxes with outlines and gutters, perfect examples of Edward Tufte's visual rule that 1+1=3, because the eye perceives the space between boxes as an object as well. The links and buttons are uniformly tiny. Aesthetically, it's less grey-on-grey than it used to be, but it's no beauty, either - it certainly doesn't match up to the design, and promise, of the splash page. At the time, it was a 1.0, we were forgiving, and the novelty and value from the service outweighed its shortcomings.
But a long time has passed since then. How does Friendster measure up today?
First off, the biggest complaint I have with it is the circa-2001, liquid-layout paradigm which makes the placement of user interface items random, depending on how wide your window is. It doesn't let you see more information, as with expanding a window on your desktop, it just creates more whitespace.
There is very little proper information architecture, that is to say, no prioritization of information for the user, to show them what needs attention, what is new, what has been updated. The interface isn't divided into obvious, well-defined tasks or operations, but fragmented into several blocks that have little to do with each other. These in turn are split up by intrusive advertising, sponsored links, pop-up and pop-under windows and the like.
The colour scheme is less grey than it used to be, but it's still boxy and outline-crazy. Do link targets need to be little blocks encased in other blocks?
With all that going on, as happens with a lot of PHP-based sites, the general impression when a page loads is that of a pile of Lego parts shuddering into place - CRASH! - rather than a clean, fast-loading page that presents relevant information and options.
Since Friendster launched, other social software sites have risen up, most notably Ludicorp's Flickr and 37signals' Basecamp.
While they have very different goals and purposes, they both share several common UI features.
- Purposeful simplicity. Rather than piling together buzzwordy features, they'd focus on a solid core and build out as needed.
- Good user feedback. For example, Flickr's dialog messages explain everything clearly in plain English, and many have a sense of humour.
- Opening up. Instead of trying to do it all, Flickr opens its API to let people build their own tools, or use existing APIs as 'hooks' into services that already do it better than you can. Flickr has hooks to blogging services but doesn't offer blogs themselves, and Basecamp uses your existing FTP site for file storage, for example. Both make extensive use of RSS to keep you remotely updated on changes.
- Discoverable richness. Rather than presenting the user with all possible options at all times, the UI focuses on the options you need to accomplish the current task. Similarly, you can start at a more basic level and learn the advanced features as you go.
- Prioritization by size and color. In Flickr, the most popular tags are larger, and the most important UI items are usually also larger and/or highlighted. In Basecamp, color is used to highlight priority and urgency.
I like Friendster but I think it could learn from Flickr and Basecamp - so as a UI design exercise, I created an imaginary version of Friendster, dubbed "Friendstr." The result is what you see above. I've only managed to do a version of the homepage portal for now, but I hope it communicates the ideas.
I started with the premise that Friendster users would want distinct interfaces for task-centric activities, and that the best way to page between them would be to use a tabbed interface, rather than a long bar of navigation links. It's a subtle distinction, but it does provide visual feedback that 'you are now going somewhere else' and 'you are here.'
Across the design, where Friendster has boxes in boxes in boxes, I've tried to eliminate all lines and outlines wherever possible, keeping only a few to mark the beginnings and ends of lists or tables, or to divide information (such as in the calendar views) along natural borders. I've always been a fan of the old Mac OS 9's list views, which had subtle alternate-line shading, so I've adopted that for all lists here. Following Edward Tufte's prescription, small, intense spots of colour indicate important items.
There's no advertising. This presumes they'll move to a subscription-based model with a limited-functionality free version, as Flickr and Basecamp have. After all, if it's that useful, the power users will be willing to pay a nominal fee for it and in turn subsidize some of the free users.
It's a fixed layout - you can zoom the text with your browser within reasonable limits - but it's designed this way to keep UI elements in a consistent position no matter what size screen you're using. Similarly, to help people navigate faster, link targets are a lot larger.
A big part of this design is about presenting a lot of relevant information above the fold. In Friendster's current design, many things fall off the page, and those functions aren't used as effectively as they could be. In this dashboard overview, those secondary functions are now in the sidebars. In particular, the More People (redubbed New People) view provides more detailed information. You can see at a glance if someone is single, dating or married, male or female, their age, and in a nod to Samuel Delany's short story "On the Job1 with Marq Dyeth," a superscripted 1, 2 or 3 denotes their degree of relationship to you.
Items requiring your immediate attention such as system messages, new mail, and pending alarms are directly at top in your Friendster Agenda. As in Basecamp, they're colour-coded and iconned for urgency, importance, and to denote positive/negative feedback.
Where I've diverged most significantly from Friendster's UI design is in eliminating the user's own information from the dashboard. I know what I look like and who I am; I don't need that info to be the first thing I see. That's now stored away in My Profile, which I've placed into the system tools links at top right, outside the main tabbed interface.
Now, when I log into the service, I naturally want to know what's going on with my friends, but Friendster's current design tells me almost nothing. There's just a row of photos and maybe a couple of icons, and in my experience, it's plucked alphabetically from my list, so there's no priority to who's shown there. In my version, we have the Friend-O-Scope. It's divided into tabs for 1st, 2nd and 3rd degree friends; it provides each with a large avatar, a clickable name link to their Friendster profile, and a precis of all the relevant updates since your last login. Most importantly, it shows the most active / recently updated friends at the top, much as iTunes has its "most recently played" Smart Playlist.
Using some API hooks, there are also indicators that show their online status: whether they are also logged into the system to permit chat directly through the site, or if they are logged into AIM, MSN or Yahoo IM.
Of course, what isn't shown here is that you can subscribe to the Agenda and the Friend-O-Scope via RSS...and that brings me to my next point, which is getting information into and out of Friendster via XML. There's great potential to integrate Friendster with other services - Flickr tag clouds, Technorati profiles, Odeo podcast tracking, etc, almost anything really.
Wouldn't it be great, for instance, to have chunks of code that you could embed in another site to dynamically populate it with syndicated content from Friendster itself - photos from the albums, friend lists (linked to their blogs, if any), your horoscope, your public agenda.
And what about supporting more business-networking type features - syncing your Outlook appointments or iCal calendars?
Finally, the site provides visual feedback as to the passage of time. There's a day view, as seen above, and a night view. The day view would take on different colour schemes depending on your local seasons, or maybe even depending on your local weather. Maybe it might even pluck the background from appropriately tagged Flickr galleries or webcam feeds, who knows. It might even change gradually over the course of the day.
What do you think?
Posted by aj_kandy at 2:58 PM | Comments (2)
April 12, 2005
Lickr: Flickr Without The Flash
My brother Neil wrote it. He's THAT smart.
While you're on his site, check out his other nifty programs, Tag-O-Vision, which blends 50 Flickr images with similar tags, and Google Draw, which deconstructs the overlay line-drawing API used in Google Maps.
Posted by aj_kandy at 6:39 PM | Comments (5)
January 29, 2005
Icons, Favicons, Countrymen...
Note: This post references my old TypePad site, but the instructions still apply. Note the little lion logo in your address bar ;)
Visitors to West of the Expressway may notice something new in your address bar: an orangy-red "W" favicon.
Favicons, also known as shortcut icons, are small graphics, usually less than 1k in size that usually contain a miniature logo or other graphic element, to help quickly find sites out of your Favorites list, bookmarks, and lately, RSS feeds. They were introduced with Internet Explorer 5.0 and, in a reversal of the usual, the standard was quickly embraced-and-extended by other browser makers.
For bloggers who use their sites as promotional tools, favicons are an important way to extend brand identity to their sites and their RSS feeds as well. In fact, my research into this was really about how to add favicons to RSS feeds, and I went around the Web and back before I found the extremely simple answer. There's one or two twists involved in adding a favicon, and what I learned might be of use to you. So here goes...
What's a Favicon?
Officially, a favicon is a Windows Icon format file, with the three-letter extension .ico.
The standard favicon is the same size as the smallest Windows icon: 16 x 16 pixels. However, the .ico file itself can contain multiple versions at different sizes and colour depths, ranging from 1-bit black and white to full, 24-bit colour with 8-bit alpha channel transparency.
In practice, hardly anyone uses these larger sizes for favicons, but having a larger size in the file is occasionally useful if you expect people to drag weblinks to the desktop, for instance.
The tradeoff is, of course, that the size of the .ico file increases considerably with every additional size and colour palette version . A basic 16 x 16 icon file in indexed colour (256 colours or less) is usually smaller than 1k.
Despite the limits of this teensy canvas, you can do a lot with it. Consider these three variations on the letter W:
Some online guides say that the .ico file has to be in the 16-colour, IBM PCjr-esque Uniform palette -- but feel free to ignore them. In practice, 256-colour Indexed, or 216-colour Web palette graphics are fine, and having hundreds of color gradations makes it a lot easier to create a smooth-looking icon and to match colours from a website or logo.
There's no law that says .ico files have to be square, either. They can incorporate a 1-bit alpha channel, much like GIFs, so you can mask parts of them off, but be aware that they'll be jaggy. On Windows XP and Mac OS X, your icons can have 24-bit colour and 256 levels of transparency, so edges can be smoother (anti-aliased), but this won't work on older systems that don't support it, so I advise you to avoid that for now; in any case it's a bit overkill.
Methods and Tools
You can draw your icons from scratch, or take existing graphics and resize them. In both cases, painstaking micro-editing is usually necessary to ensure the best results. To some extent it's like creating a little Pointillist painting; the adjacent colours blend a bit, so the eye sees a teeny version of, say, your corporate logo, when in fact it's a very rough approximation.
For example, here's my company's logo, the favicon created from it at actual size, and an enlarged view of the favicon with a pixel grid in place.
Sorry, the image is missing. I'll replace it soon!
As you can see, the favicon has a pretty good resemblance to the original, but when you look at it close up, you realize you're not seeing what you think you're seeing. While this favicon started as a scaled-down version of the original EPS artwork, quite a bit of pixel-level editing was necessary to bring out detail in the lion's tail, to approximate the head, and suggest the shape of the claws.
Alternately, you can decide to work with their pixelly aesthetic, like the Wired favicon above.
I usually use Adobe Photoshop as my editor, with a free plugin from the Australian developer Telegraphics that lets me save in .ico format. This is pretty much all you need to do single-size and colour-depth icons.
To make a true Windows or Mac icon, you have to be able to edit the complete icon table, for which you need a full-blown editor like Iconfactory's IconBuilder plugin. There are also several popular standalone icon editors like Microangelo on the Windows platform.
Once your .ico file is ready, all you need to do is place it in the root directory of your website and again in any subfolders with pages, for visitors who aren't coming in through your homepage's "front door."
.ICO? .ICK! Can't I use something else?
Yes. Most browsers support linking a graphic file to be your site's shortcut icon.
This lets you use any MIME-supported graphic format you like, including GIF, JPEG, and the popular and versatile PNG.
To do this, you need to add a shortcut icon pointer URL in your page header and specify the MIME type of the image you're using.
<link rel="shortcut icon" href="http://www.myfantasticsite.com/favicon.png" type="image/x-png">
For GIF, you'd substitute "image/x-gif," and so on. It's easy to add to templates in blogging or other CMS software, and you don't have to dump .ico files into every directory on the site.
A Funny Thing Happened On The Way To Redmond
The irony is that Microsoft Internet Explorer has only partial support for favicons, even though it's their own standard. Testing on both IE 5/Mac and IE6 / Windows reveals that IE doesn't display favicons in the address bar &emdash; unless you specifically bookmark the site.
Gimme All Your Cache And Make It Quick
I also discovered that RSS readers and browsers don't necessarily refresh the favicon once initially grabbed from a site, even after you clear browser cache and history. In NetNewsWire, I had to unsubscribe and then re-subscribe to a feed get it to pick up. With some browsers you may need to dig into the cache files and manually clean them out.
There's a neat tool for Apple Safari, for instance, called Safari Icon Manager that lets you visually browse cached icons and delete them as needed. (Privacy nerds will love that, too, if they're fanatical about leaving no trace of their web whereabouts on a machine.) You'd be surprised how big your favicon cache can get, too, so it's useful to clean it out every so often.
Favicons =! RSS Channel Icons
Which brings me back to my original quest. I mistakenly assumed you had to somehow embed a reference to your favicon in your XML feed: in fact most RSS readers simply pick up the same favicon your browser does. How simple is that?
My confusion stemmed from that fact that there's a standard for a different graphic, 88 x 31 in size, intended as a kind of "banner graphic" for RSS channels. This is useful for incorporating feeds in a web page or a web-based RSS aggregator, I guess. It involves adding some lines of code inside the <channel> statement in your XML feed template; however, after looking through the XML files of several weblogs' feeds, I can't find a single one that actually uses it. If you want to be 100% standards-compliant you can add this to your feed, but you can live without it.
So now you know.
Posted by aj_kandy at 9:15 PM | Comments (4)
July 13, 2004
and on the subject of iCal...
Why doesn't Via Rail offer their timetables in ical format, that could be dynamically generated and updated using off-the-shelf technology?
It would be supremely useful to be able to just subscribe to a Via Rail iCalendar and get dynamic updates...and even have travel information updated blogstyle via RSS to advise people of delays, for instance.
Right now they offer a downloadable PalmPilot application and a proprietary Windows app, and database updates for both, but nowadays that seems so slow, static and clunky.
They could really update their booking process as well. After you experience a Rich Internet Application like the Flash-based iHotelier reservation system, the idea of going through multiple screens of forms only to find out you can't travel on that day is maddening.
Another thought: do any airlines offer iCal timetables?
Posted by aj_kandy at 9:59 AM | Comments (4)
December 16, 2003
The New Old Rules: Print Usability on the Web
Print has hundreds of years of craft behind it. You never think about it, but it involves a lot of small things that really add up.
-Usable size and orientation. A 2" high, 10' wide book is hard to read...
-"Thumb space" in the margins.
-Comfortable type sizes for reading
-The design of tables of contents and indices
-Line spacing, small caps, indentations, and myriad other techniques that clarify and direct the flow of text. We don't actively "see" them while reading, but we notice their absence.
Readers - the end-users - are exposed to print almost from birth. In practical terms, this means that the user interface, usability standards and best practices of print are well-established. Any well-trained, competent typographer can lay out a book or magazine that any reader can comprehend, and it functions pretty much like every other book and magazine out there.
Of course, if you are an enfant terrible, you can throw readability out the window if you wish. But as Robert Bringhurst says, if you're going to break the rules of type, understand what they are first, so that you can break them really well!
By contrast, the Web is young. It doesn't have hundreds of years of craft behind it, although well-meaning people try to graft the old onto the new, with mixed success -- "It's electric print! It's really slow television! It's CB radio!"
Now, ten years in, we can state that there is a definite craft to the Web. It has nothing to do with clever technologies or pretty pixels, and everything to do with usability and user-centric content.
Usability comes from several disciplines: Information Architecture, visual and verbal cognition, wayfinding, Human-Computer Interaction, and even traditional architectural practice. But as always, it involves testing and retesting with the end-users.
User-centric content covers what you do with the website more than how you do it. The underlying technologies are irrelevant; user-centricity comes from knowing your audience, thinking like them, and mapping out what features, functions and activities provide them with the most value for the time they spend on your site.
Usability is, thankully, completely measurable. We can objectively test page loading speed, text readability, browser compatibility, and how long it takes for users to find information and perform tasks. For commercial websites, usability directly influences a site's ROI.
Making a site usable requires consistent interaction design patterns, in order to make the site conform to the users' expectations of how it ought to work.
If your site is unusable and your content goals aren't user-centric, your site won't provide any value to your customers or users - simple as that. Well, it might be nice to look at, in which case you have opened a look-but-don't-touch, don't-raise-your-voice environment -- a museum.
Aesthetics ≠ Good Design
To the busy user who's looking for information or trying to complete a task (say, shopping online) and to the blind god Google's net-spiders, aesthetics just doesn't enter into it. In fact, I'd say aesthetics are completely secondary to having a successful site, a successful brand, loyal users, or even making money.
Look at eBay and Amazon. And, well, Google itself. These are probably the world's most popular sites, with brand value out the wazoo, household words all. Some are even money-makers par excellence.
All are probably the least "designed-looking" sites you will ever see.
That doesn't mean they're not designed - they are extremely well-designed - in a way that's largely invisible -- but more on that later.
Flash In The Can
As someone famously said, would you make visitors to your office sit through a 3-minute film before being allowed into the building? Of course not. Mainstream web designers now know that gratuitous Flash intro pages suck.
Now, there's nothing wrong with Flash as a technology. I love it, actually. It's just that too often, companies want their sites to be full of excitement and movement and make a statement! about how cool they are...and Flash ends up being a hammer used to pound that message into your skull.
By contrast, Flash excels when it's used for things that HTML can't do. There are practical content applications like news-related infographics . With the advent of Flash MX, we can now build Rich Internet Applications* like this RoadRunner portal site.. These are things that actually bring measurable ROI to a company, because they do something useful for the client, in real time, while allowing a degree of design and branding control that's closer to print and television.
These 99% Good Flash pieces launch only when the end-user wants to see them. If the client asks to see that product video, why sure, here it is, and here's a DVD copy to take home with you. And that RoadRunner portal site above? Completely built in Flash MX, tied in to back-end content management systems and databases. Updates dynamically, all in one screen. A great improvement over old-fashioned Web forms. That's cool - and it's largely invisible, because it "just works."
That invisible good design thing
Let's take another look at Epinions, eBay and Amazon. First off, you'll notice that they present an extremely basic interface to the user. Nothing fancy; they even look a little bit cluttered, sometimes.
But what you see there is the result of constant refinement, user input, testing, surveys, and applied information architecture best practices. I can say with some certainty that these sites work exactly as their users expect. So much so, that someone who's never been to the site before can figure it out in less than a minute.
What brings people back to these sites is subtle and invisible. It's based on both technology and human connectivity.
The technical part is clever back-end coding. Both eBay and Amazon are wrapped around powerful, fast search features, content databases and dynamic content from relational databases. Search is king. Content is king. Keywords are king. When you enter "Ludlum" in the search bar in Amazon, you're 90% likely to get "The Bourne Identity" as a top result. It's because the site's engine analyzes which links people actually click on most often from the search results, and ranks that as a more successful result than, say, a cookbook by Sally Ludlum Smithers or whoever.
Google does the same thing, but also adds the layer of seeing how many sites link to a particular result - the PageRank. The more people that link to it, the more likely that page is the target for a given keyword.
Building an online auction site or bookstore isn't hard - but a bookstore that learns your preferences and suggests things you might like is pretty darn cool. That's partly personalization (which I'm not entirely sold on for sites that don't involve catalog shopping) and mostly relational DB work.
And then there's the human side. eBay and Amazon revolve around their user communities.
With eBay, it's all about the feedback ratings to ensure good behaviour - the community is self-policing and promoting, providing added assurances. It's purely Darwinian capitalism, but with reputation as a form of currency. Good feedback is as good as money.
With Amazon, it's about individuals contributing reviews and ratings. (On sister site imdb.com, it's about comments.) Dozens of small, personalized features like Gold Boxes and wishlists make it more convenient. Wishlists, in particular, get gift-givers to shop on Amazon for themselves as well.
Top 10 lists, "So you wanna be a..." lists...and more make it an interesting community of individuals. More than being a simple you-buy-from-us operation, it empowers users to use its engine to sell their stuff, too! Or make money from affiliate sales! And every small bookstore in the world is now an extension of Amazon's operation. Opening up their APIs was the best thing they ever did.
I'm only scratching the surface here, but you see how user-centric content makes a site a real destination, instead of a look-but-don't touch museum.
*(Hi to John Dowdell, if you're reading. And I know you are.)
Posted by aj_kandy at 12:05 PM
