A couple days ago, I twittered a link about Microsoft My Phone's new release, cringing openly over the use of typography in its phone app. Now, I'm by no stretch of the imagination a type designer or someone with a strong understanding of the many fine intricacies of typography and fonts, but I know enough to be able to tell when it's the use of type that's making me distress over an interface.
As I scrolled down on that page to see the screenshots of the associated web interface for MS My Phone, I was reminded of how cognitive load-heavy Microsoft's Vista theme is, all by itself. This, in turn, brought back a memory of a friend of mine, the inimitable Rob Mientjes, who said to me after his first encounter with Vista's interface:
If the devil is in the details, why is Microsoft putting tiny little devils all over their interface?
It's something I agree with every time I see a screenshot of a Vista interface: the many little UI elements that are added to Vista's Aero interface (in particular) are bountiful, far too bountiful for my taste. There's a plethora of lines, glosses, redundancies (repeated messages as seen in this Copying Files dialog), panes, menus and buttons all occupying your mind every moment you use the interface. Even when you can adequately focus your attention to the specific interface element you're dealing with, your mind will subconsciously perceive all the others, and this adds cognitive load.
Tantek Çelik wrote, exactly two years ago, about the Three Hypotheses of Human Interface Design. A central theme in it is the cognitive load generated by User Interface elements and the interactions you have to go through with each of them to accomplish a task.
But Çelik's post limits itself to the interface elements and interactions, which, I think, is inconclusive when we're talking about the cognitive load of a UI as a whole. You may point out that there's copious amounts of discussion about design, graphic and visual interface design, and you'd be right. What's not discussed as often, or as often as I'd like, is the cognitive load generated by visual design decisions for a user interface.
We're constantly trying to create richer and richer experiences on the web, today: the plethora of Javascript libraries that add innumerable amounts of features is but one testament to this. What we need to be cautious about is in making the visual experience rich, but not too rich.
An example, one that I originally didn't plan to use but turned out to be too good an example, is my good friend Bryan Veloso's Avalonstar. Now, Bryan is one of my all-time favorite designers, an inspiration and incredibly talented in a variety of skill sets. His latest Avalonstar design, however, makes me look on in awe but it actually prevents me from navigating his site. I get on that front page and I just don't know where to go, there's so much going on (and so much beauty to behold). Despite that, I still consider it one of the most beautiful websites I've ever seen. [Update: Bryan has since redesigned; you can see the version I wrote this about on Flickr]
On the opposite end of the spectrum lies Daring Fireball: John may be the first to say he's not a designer, but he has a great design sense nonetheless. What's telling about DF, however, is that I actually prefer reading his blog on the site over reading it in a feed reader. It's extremely minimal in design, but the net result is that I know exactly where to go: the content, which is the only thing drawing attention to itself.
Aside: one thing that's particularly cognitive load-increasing and found on almost every big website out there is Flash banners. Their nauseatingly endless attempts to try and grab your attention aren't just a matter of nuisance, they heavily increase the cognitive load of the UI as your mind now has to spend brainpower in suppressing these animations constantly, just to focus your attention to the content you're there for.
Personally, I do like my flair in website design, coming from a more "graphics artist" kind of background than anything resembling a real "design" background, but it's too easy to lose oneself in adding flair and visual richness to a website design. The key is not in adding richness to the design, but allowing the richness of the content to shine while adding no more around it than absolutely necessary.
Soon, I'll have my own design finished and then FarukAt.es will finally launch for real. Once I get there, I'll talk more about this subject and how it has influenced my design process in making that new FarukAt.es design.
This morning, Tim Bray linked to an interesting discussion on HTML5 that's been taking place the past couple days on bugzilla.mozilla.org. Robert Sayre offered up a dramatically cut version of Ian Hickson's HTML5 spec as a counter-proposal for HTML5, which caused a great deal of controversy (and head-scratching).
Sayre's argument, as I understand it (which I'm not 100% sure of I do), is that the enormity of the HTML5 spec as-is makes it not work somehow, and instead we should use his version that omits much of all the new things in HTML5. It sits somewhere between being HTML4.1 (or "HTML4 done right") and a crippled HTML5, really. One of Sayre's arguments for why he did this:
"I don't have any plans for the removed items. I don't want to work on them, but I am certainly not trying to block them. In fact, there's nothing stopping Ian from continuing as he has been--his document could supersede the document I've produced, but it's going to take longer."
Sayre seems to think, by my understanding, that the HTML5 spec needs to be implemented in one fell swoop in browsers or not at all. There is no acceptable middle ground. His intent thus appears to provide a stop-gap measure of a slightly-better-than-HTML4 approach that browsers could implement sooner.
The huge omission in his rationale, and again I must stress that this is purely my limited understanding of his limited explanations, is that there is such a thing as partial or modular implementation, and that this is not an inherently bad thing.
Just look at CSS3: it may not be perfect, it may not have everything you'd want (yet), but parts of it are being implemented by various browsers and they're coming to a stage where those implementations are ready for use, now. CSS3 was admittedly pro-actively modularized because of the exact concerns that Sayre has over HTML5, but there is no reason, no reason at all, that the same approach could not be utilized by browser vendors when implementing HTML5. In fact, that's already the case right now: WebKit/Safari has initial support for some of HTML5 (like <audio> and <video>) but not all of it. Is this a problem somehow? Not at all.
Just because HTML5 as a spec in its current state is not proposed in a modular way, like CSS3 is, doesn't mean that browsers must implement the whole thing in one fell swoop. Sure, it may, as a result, mean that full conformance even for just the first browser will take many years, but I ask you, so what?
We don't need full conformance before we can start using any of the things implemented. There's nothing preventing you or me from using -webkit-border-radius and -moz-border-radius in websites right now, as long as we can live with the fact that not every browser will see that. Similarly, we can use what's available in browsers from HTML5 right now, as long as we can live with having to use workarounds in some shape or form for browsers that don't yet support them.
Robert Sayre may have a problem with that, but the Web as a platform does not. It's worked for us so far, and it'll continue to work for us going forward.
Loren Brichter explains why Twitter's consideration of going to an OAuth-only authentication system is a problem, and offers some solid solutions to fix OAuth's most glaring problem, which is that it currently at a core level requires that the user authenticate using their web browser. The heart of his proposal lies around changing that requirement from "web browser" to "authentication gateway" that each Operating System could then provide an API for:
One added bonus of implementing OS-level “blessed” authentication gateways is that the OS vendor can use every trick in the book to prevent phishing. They can use secret APIs to make sure key strokes aren’t logged and proxy settings haven’t been compromised. They can also implement a system allowing users to validate the authenticity of the authentication gateway itself.
While I hadn't given the OAuth situation much thought before, I have the exact same problem with it that Loren has: requiring a web browser as the one and only authentication mechanism basically turns each application into a designated Man-in-the-Middle. It really doesn't do anything more than add a step for any ill-meaning application to hijack your login credentials.
I've already posted this link to my Twitter, but I find this article to be so important that I'm sharing it here as well, for more posterity as well as for other people to find. This is an important quote from the piece, but you really should read the whole:
Experts have figured out that the brain has no ability to actually predict your emotional reaction to life changes that haven't happened yet. In other words, you physically do not know what you want. The act of sitting around pondering it is apparently what fucks you up.
…which I think aptly sums up why things like Youtube and LOLCat websites have become so popular: it is something that takes your focus off yourself and prevents you, if only for a series of short moments, from thinking about how happy or unhappy you are.
I've been noticing a problem more and more often, lately, in my daily habit of reading blog posts and articles while on the go. In the days prior to Internet-equipped phones (the iPhone in particular), reading feeds was perfectly manageable as every feed item would be accompanied with a date stamp for the article. And if I were reading not in my feed reader of choice at the time but simply in my browser, it usually wouldn't take much effort to quickly figure out when a post was written: either the URL contained a date, or it would appear somewhere, somewhere on the page.
Recently, this scenario changed for me. More and more, I end up reading blog posts on my iPhone, either via the mobile NetNewsWire app or via Tweetie when people post links to Twitter. In both cases, the URLs are no longer visible and hitting page up/down or home/end is not an option. This new method of exploring content has highlighted a serious usability concern for me:
The context has gone missing.
When I say context, I simply mean the date of the article that defines how relevant and current its contents are. "The new X is awesome!", "I got the latest version of Y, and it works great!" and "So yesterday I downloaded Z and it was terrible!" are all potentially useless commentaries when the reader has no idea what the time context is.
For example, you may write "I got the latest Coldplay album!" and give it a nice, full review—but unless I already know upfront that you wrote that in 2004, I may end up feeling deceived unintentionally when I discover at the very end of your review that it does not, in fact, discuss the now-latest Coldplay album.
Without this seemingly innocuous but ever-so-important context of relevance, some articles can be either fantastically important or ridiculously worthless. And if your blog design or blog template of choice doesn't list the date anywhere near the top, your reader may not know until after they've read the whole thing.
I was bitten by this myself about 6 months ago, when I came across an article (and a video clip) talking about how the Bush administration was trying to push a bill through congress that would preemptively grant them eternal protection (in advance!) against any trials related to war crimes or related responsibilities. I was pretty outraged to find out about this, but as I discovered after a couple of angry tweets and discussions with friends about it, the whole thing had taken place more than six months before I even moved to the USA.
None of the articles I read, including the ones referenced, had a clear indicator of when they were written.
That may have been a political case, but it's just as applicable in the world of technology. For instance, one of John Resig's recent posts starts with "I gave a talk last week". That's great when we encounter the article as a new feed item, but if someone encounters that post by following a hyperlink somewhere, five months from now, they won't know how relevant that post is unless they first scroll all the way to the bottom of the post to see the date.
Many blog posts and articles written today deal with a current topic in some form or another. When the context is taken out and put very oddly at the bottom of the post, after you've read it all, it creates a hit-or-miss environment: all that you've read may or may not be of any use to you, since it may or may not be completely outdated information.
If the date is listed directly at the top of the article, it allows you as a reader to go into the piece with the necessary context: "this post was written three months ago, so it may be out of date." That doesn't mean itis out of date, but it gives you an important bit of information prior to you spending time reading the article. Plenty of articles discuss topics that are timeless[1], or close to it; for those that don't, knowing the context is important and knowing it up front can be crucial.
So for all of you bloggers and blog designers out there, for all of you writing for publications, please: give us the context.
Resig's talk, for instance, will be useful if not entirely up to date for at least another year. ↵
All I'm going to say is, judging by the riveting activity (read: tumbleweeds) found daily at the Sony Playstation Store in the Metreon in San Francisco, I'm sure a company with even less of a consumer-oriented image will have a great challenge ahead of itself in making such stores draw in crowds.
Seth Godin is one of those reasons I would love to go to TED:
The internet means geography isn't so important, so if you can find the 1,000 or 5,000 or 50,000 people out there who want to make a certain kind of change and can connect them and show them a path, they want to follow you.
