Archive for the 'User experience' Category

Solving the real Alt-Tab problem

Published by Francois Jordaan on May 10, 2010 in Futurology and User experience. 19 Comments

In his latest blog post, Aza Raskin – interface design guru, creative lead on Firefox, and son of one of my heroes, Jef Raskin – tackles one of my oldest bugbears, Alt-Tab. Aza is a clever guy, but I was disappointed that his post addressed an issue I don’t perceive as important, while failing to address what I see as the very real problems with Alt-Tab. But let me start with some background.

(I use both Windows and Mac every day, and in this post tend to use Alt-Tab and Cmd-Tab interchangeably.)

(EDIT: I originally gave the window-switching shortcut as Cmd-\ since I use an external keyboard, but I probably confused Mac users who know it as Cmd-~ (tilde). Updated.)

History (something Windows got right)

Windows had Alt-Tab since Windows 1.0, although it was only implemented in its familiar visual form since Windows 3.1 (1992). To this day, I know many people who never use the shortcut, but I personally cannot imagine using a multi-tasking operating system without it.

I found its initial absence on Apple Macs unacceptable. In Mac-based studios during the 90s, I always relied on a third-party extension, Task Switcher, to provide the missing functionality.

When Apple finally introduced native Cmd-Tab (in OS 8.5, I think), they at first got it wrong. It cycled alphabetically through running apps, rather than switching between apps on a most-recently-used (MRU) basis like Windows1, so I had to continue using the extension. They changed it to MRU order in a later OS update. (Thank goodness Microsoft didn’t think to patent it.)

Unfortunately, Macs still suffer from another difference which I’ll come to after the following interlude.

Interlude: Why is most-recently-used (MRU) order better than cycling (and Exposé)?

The first reason is obvious: If Alt-Tab simply cycled through open windows in a fixed sequence (say, alphabetically), it would just require far too much tabbing, on average, to reach the item you wanted.

But Raskin alludes to the more powerful reason: spatial memory. If the shortcut always switches to the most-recently-used (MRU) item, this quickly teaches you to make the switch without thinking or looking at the screen. Spatial memory is awesome because it’s a background faculty, not foreground. Like reaching for your mouse, it does not interrupt your concentration, or where you’re looking on the screen.

This “toggle” behaviour, using a single shortcut key to switch back and forth between two windows only, is worth mentioning as an important feature in itself. It allows the shortcut to be used to compare the contents of two windows, not simply to switch from one to another. (The Undo/Redo shortcut in Photoshop – Cmd-Z for both – also brilliantly uses this principle.)

So, MRU order allows you to switch between two tasks pretty much subconsciously. Personally, I have learned to switch between up to 3 apps without relying on the visual aid (i.e. using spatial memory alone). For switching between more than that I need to look at the interface, but MRU ordering still reduces the number of times I need to Tab.

The trouble with Macs

Cmd-Tab on the Mac works less well than on Windows, due to the Mac’s application-centric model, as opposed to the document-centric model of Windows. In Windows, for example, you can Alt-Tab between two emails, or two browser windows; on the Mac you can’t. To switch between application windows on the Mac you have to use a different shortcut, Cmd-~, which again uses cycling rather than MRU order. On top of that Cmd-Tab on the Mac has the annoying habit of bringing all an application’s windows to the foreground, often covering up the window you were trying to compare against.

I believe window-switching is closer to the mental model of what this shortcut accomplishes. The clue is in the original feature name: “Task Switcher”. It switches between “things I am doing” – I do not care about which applications they happen to be in. So to see it as an “application switcher” is to miss the point.

It’s also my theory that the deficiencies of task-switching on the Mac spurred the development of Exposé, which I consider a sticking-plaster solution. Exposé is nice, but it does not utilise spatial memory – it forces you to look at the interface.

I admit this is debatable: some people (to my amazement) find application switching on the Mac more natural than window-switching on Windows.

The real problem

As more and more applications adopt a tabbed workspace, Alt-Tab is becoming less useful regardless of which operating system you use. And this is especially serious with browsers, because more and more of our daily tasks happen in browsers nowadays. You’re no longer just “browsing”. Just as often you’re composing documents, managing your calendar, filing bug reports, etc. I often find myself automatically attempting to Alt-Tab between two things I’m doing, but failing because they happen to be in two separate Firefox tabs. And then I have to use the mouse.

In Windows I can improve the situation slightly by opening more browser windows. That way I can use a single window, say, for Google Calendar, one for GMail, one for the blog post I’m writing, a multi-tab one with lots of things I’m reading, etc. On OS X I can’t, since application windows can only be cycled through using Cmd-(Shift)-~.

The keyboard shortcut for switching tabs is usually Ctrl-Tab (on both Mac and Windows), but again, this cycles rather than using MRU. Interestingly, there are a few applications who opted to use MRU with Ctrl-Tab, e.g. oXygen (my favourite HTML editor.) I appreciate it enormously when using the application. Weirdly, Firefox occasionally seems to do this (uses MRU rather than cycling), but this is unreliable and I cannot get it to do so now.

Aza Raskin’s proposal

I’m disappointed that Raskin – evidently a lifelong Mac user – implicitly accepts “application-switching” as the point of the shortcut. As I have tried to explain above, this is fundamentally less useful than task-switching.

In his article he attempts to come up with an improvement to the shortcomings of MRU. (He doesn’t even mention cycling so I assume he is not in favour of it.) MRU’s shortcoming, Raskin says, is that it is only useful for toggling between two things (he says apps, I’d say windows), and frustrates your tendency to form spatial memory habits for more than that. Personally I don’t experience the problem he describes with juggling 3 apps. It’s hard-wired in my spatial memory that Cmd-Tab switches to the last thing, and Cmd-Tab-Tab switches to the last-but-one. For more than this I need to shift my attention to the switcher interface, and spatial memory is no longer of help. But this is infrequent enough not to matter.

He then proposes a “habit-respecting MRU” (HRMRU) to solve this problem I don’t perceive. He ponders using heuristics or even a Markov model to detect users’ habits. Personally I see this failing for the very reasons he himself described – it would just result in a seemingly capricious interface.

But the bigger problem I have with Raskin’s article is that he doesn’t address the real erosion in the usefulness of this shortcut: The loss of MRU due to tabs, and the co-existence of both MRU-ordered switching and cycling. (And the greater problem on Mac OS by having 3 switching modes: Apps, windows and tabs, two of which don’t use MRU.)

My proposal

Tabbed interfaces are not going away. They’re a necessary way of managing the ever-increasing number of windows we have to juggle. If I had to Alt-Tab between all of them, it could number over a 100. So I think two switching modes are inevitable.

So I propose that only two shortcuts are necessary: Alt-Tab / Cmd-Tab for window-switching, and Ctrl-Tab for tab-switching inside a window. (Or document-switching in applications that don’t use tabs.) Both should work exactly the same way: MRU order, with the addition of Shift to reverse the order. There is no reason for application-switching to exist.

This would be a minor change on Windows, but a fundamental one on the Mac. Perhaps, as OS X insists on having 3 switching modes with 3 different shortcut keys, they could at least redefine the second one – Cmd-~ – to be window-switching across all apps (i.e. like Windows) rather than within the current app only. And all should use MRU.

Some people may find MRU order in a tabbed interface confusing, and crave a keyboard shortcut that cycles instead, but then a different application-specific shortcut could always be provided. E.g. Firefox already has Cmd-Alt-Left/Right arrow (Mac) or Ctrl-PgUp/PgDn (Windows). These are more appropriate shortcuts for cycling as their names imply directionality.

  1. Windows actually uses Z-Order, but in practice this generally works like MRU. The behaviour was slightly changed in Vista, but the 6 most recent windows still uses MRU order.

Just Enough Documentation: an ideal web design process

Published by Francois Jordaan on April 21, 2010 in Agile, User experience and XHTML/CSS. Closed

A recent project reminded me how much I like the “just enough documentation” approach, and how inefficiently web design is often done.

Tasked with redesigning an Agile project management web application (to improve usability but not re-brand), I used the following process:

1. Paper sketching for a day or so to get my ideas straight about page and widget layout. This is the best time to explore wildly different alternatives, and make most of the big decisions.

2. Wireframes in Omnigraffle of the key pages. Since the visual style wasn’t changing, I could do high-fidelity wireframes closely resembling the final design. I work on a large format, so there’s ample space to overlay notes and state changes, as well as alternative ideas. The wireframes were shared with the client on a continuous basis for feedback.

Lots of things weren’t wireframed, including less critical pages, and many dynamic states.

3. I did only two pages in Photoshop, in which I did just enough to give me my final measurements, and the few image elements that needed cutting out. I refined designs a little from the wireframes, but most of this I left to the next stage. The wireframes and this stage together took about 5 days.

4. HTML and CSS. Because in my design I was switching from a fixed-width layout to a liquid layout, you can only really appraise the design once you implement it, so it was imperative to get to this stage as quickly as possible. It is also far, far more efficient to fine-tune margins, typography and colours in CSS than in Photoshop. Furthermore, I could quickly mock up most dynamic interactions – of which this app has plenty – in jQuery (which I had not used before but was ridiculously easy to pick up.) How much more effective than doing so in wireframes, where you (and the client) have to imagine how it will “feel” to the user and you can never be sure whether it will work?

By far the bulk of my time – about 2 weeks – was spent working in HTML and CSS. Pages or elements that weren’t wireframed were much quicker to design directly as HTML and CSS, without the duplication of effort. New ideas inevitably arise during this stage, and are immediately incorporated. I occasionally went back to paper or Photoshop or Omnigraffle to work out small details, but there was no need to keep those design documents “up to date” – they had served their purpose. The client was able to appraise the designs exactly as it renders in the browser, and the resulting artifact was also ready to be integrated into their back-end.

Not only could the client and I be confident about how the design will actually look once implemented, I could also ensure that accessibility measures were built in, as well as the ability for it to be easily re-skinned. (As the app is sometimes white-labelled.)

Conclusion

If I reflect on the design process on many past projects, most seem ridiculously inefficient. Where UX designers had to exhaustively wireframe every single page and every possible interaction, with complex state diagrams for all the dynamic elements. And to keep the wireframes up to date throughout the course of the project. Where designers had to mock up dozens of pages in Photoshop, with everything finalised to the last pixel (but usually omitting hover effects and never considering liquid layout or browser differences). All the foregoing needing to be done before a client will sign it off and a single line of markup can be written. The front-end developer reduced to an automaton incapable of taste or decisions, who just had to implement the Photoshop mockups to the pixel, and all interactions exactly as specified in the wireframes. It was usually impossible to refine aspects of design or interaction at this stage (everything having been signed off), let alone adding new ideas, despite it being the most fluid.

Obviously this won’t suit all projects or clients. For example, I had the advantage of not starting from scratch, and a client who was prepared to work in this way. It was a relatively small project with few stakeholders. On some projects there may be good reasons for an exhaustively documented waterfall process. But very often in my experience it was simply because it was the only way the agency knew how to work, due to the excessive compartmentalisation of skills, and an inadequate understanding of the meaning of web design. And my, what a lot of time and money it wastes.

Plone Theming or: How I Learned to Stop Worrying and Love collective.xdv

Published by gwilym on April 16, 2010 in Plone, User experience and XHTML/CSS. 2 Comments

Recently I’ve been tasked with looking at how we can improve our Plone theming process.

One of the problems that most teams come across on any web project is how to spend less time doing the basics and more time solving the unique problems that each project throws up. This seems to be especially true when it comes to skinning / implementing user interfaces. No matter what framework / CMS I’ve used (and I’ve used plenty) it’s often hard to square the circle between what we want as output and what is actually produced.

Another aspect that can eat up time is having to implement user interface changes during development. Even with the best sign-off procedures, designs, and by extension HTML templates are often subject to change. With that in mind the key objectives we are looking for in a theming method are:

  • easily portable between projects.
  • full control over CSS/HTML and JS output.
  • working in parallel with the development team.

So lets look at the various theming options for Plone.

“Plone theming is getting a bit complicated”

You’re not wrong. From what I can see you have 2 options:

  1. Write a custom stylesheet. It’s amazing what you can do with CSS, but that alone won’t cut it. We need to able to specify the HTML output to meet our high standards of accessibility and design.
  2. Create a ‘vanilla’ theme product. Creating a Plone theme is not for the faint hearted and to be honest it had me stumped. You really need to have a solid understanding of Plone and Zope to create anything worthwhile and while that is not necessarily a problem it’s certainly not my area of expertise.

I could probably grab some developer time here at Isotoma to help me put together this ‘vanillla’ product, but even that doesn’t answer our needs in the level of flexibility we require. There must be an easier way….

Deliverance / Collective.xdv

The future of Plone theming lies in Deliverance / Collective.xdv and will be at the core of Plone 4 theming (so I’m told). You can start using it now though. (see this excellent tutorial to get started )

It took a little effort to get a working buildout, mainly because I couldn’t get lxml working on my mac (necessary for collective.xdv). So I installed it on an Ubuntu VM which worked just fine.

Once I’d got it working it didn’t take me long to realise the potential of this new way of theming. In a nutshell, it allows you to have whatever output you want. Not only that but it allows template development to happen separately and in tandem with the main development effort.

Let’s have a quick look at how it works. At it’s simplest level you have 2 files: theme.html and rules.xml. The theme.html file is a standard html template and you can write this however you want. It is the rules file where it gets interesting. I won’t go in to the full details (see here for a full description) but here are some examples of what you can do.

Replace content:

<replace content='//*[@id=”content”]' theme='//*[@id=”content-area”]' />

this replaces the element in the theme.html with whatever content Plone produces within #content element.

Append / prepend content:

<append content='/html/head/style' theme='/html/head' />

this adds all the styles from Plone.

Discard content:

<drop theme='/html/head/comment()' />

This removes comments form the theme.html appearing in the site.

It uses Xpath, something that I’m familiar with and very easy to learn. With deliverance it gets even easier because you can use CSS 3 selectors. All-in-all you have a very powerful way of theming Plone whilst having a fantastic level of separation and flexibility.

I’m very hopeful that collective.xdv / Deliverance will be the solution we are looking for and I’m really looking forward to using it on forth coming projects.

Javascript localization within Plone

Published by Richard Mitchell on February 10, 2010 in Javascript, Plone and User experience. Closed Tags: , , , , , , .

For a while now, I’ve been trying to think of the best way to get localized strings into Javascript under Plone. Many existing packages and parts of Plone use one Javascript file per language, containing all translations. Whilst this is effective, it doesn’t “feel right” having all your translations distributed to the user on each page load, much less having them drawn from two different sources. Worse still (in my mind) is having translations dumped out into hidden HTML elements and then recalled by Javascript using getElementById or some such.

The solution I’ve eventually settled on is one that combines AJAX and client-side caching in cookies to minimize page load time. The implementation consists of a single view, a Javascript file and a bunch of XML & ZCML to tie it all together.

The powers that be here at Isotoma, have kindly agreed to let me open source this under the Apache 2.0 license.

Full documentation can be found for the code can be found in the README.txt, however I’ve included a quickstart guide below.

Continue reading ‘Javascript localization within Plone’

LinguaPlone and redirection

Published by Richard Mitchell on September 11, 2009 in Archetypes, Plone and User experience. Closed Tags: , , .

One of our current projects working with Plone requires multilingual content using the LinguaPlone product. One of the features that has been lost since LinguaPlone was first released was the redirection to content in the user’s preferred language when given a hard link to content in another language. As mentioned in this rejected bug report from 2006, the desired functionality is that there should be no redirection however this approach doesn’t leave any room for flexibility in the name of usability.

One suggested solution in the bug report is to re-add old code from previous versions of LinguaPlone but what if one doesn’t want redirection on all translatable views?

The solution we came up with was to override the __call__ method of the view using our own base class, which could be inherited by views which we wished to redirect:

from Products.Five.browser import BrowserView
from Products.CMFCore.utils import getToolByName

class MyBaseView (BrowserView):

    def __call__(self, *args, **kwargs):

        if self.context == self.context.request.other['PARENTS'][0]:
            # Don't try to redirect if we're not in the context of the object originally called.
            # Otherwise, if child objects' views are called the whole view may be redirected
            # to that child in exceptional circumstances.

            try:
                # Import may fail if LinguaPlone not enabled.
                from Products.LinguaPlone.interfaces import ITranslatable

                redirect = self.context.request.get('i18nredirect')
                if (not redirect or redirect.lower() not in ['no','false']) \
                        and ITranslatable.providedBy(self.context):

                    language_tool = getToolByName(self.context, 'portal_languages', None)

                    # Check current selected language, language of object sought & available translations
                    if language_tool is not None:
                        preferred_lang = language_tool.getPreferredLanguage()
                        if self.context.getLanguage() != preferred_lang and self.context.hasTranslation(preferred_lang):
                            translation = self.context.getTranslation(preferred_lang)
                            return self.context.request.RESPONSE.redirect(translation.absolute_url_path())
            except ImportError:
                if 'LinguaPlone' not in e.message:
                    raise e

        # Resume normal behaviour
        return super(MyBaseView,self).__call__(args, kwargs)

This allows us add the redirect functionality arbitrarily if we wish, and also retains a method of hard-linking using the i18nredirect GET variable. This functionality could of course be reversed, leaving the redirection as the special case rather than the default.

PDF file size guidelines

Published by Francois Jordaan on September 4, 2009 in User experience. Closed

It’s a fact that many corporate sites still rely on an awful lot of content in PDF format, sometimes for the wrong reasons, sometimes for very good reasons. Usually it’s a fait accompli. So recently I was asked to provide file size guidelines for PDFs.

Thing is, providing a simple file size guide for PDFs is hard. There are so many variables to take into account.

Firstly, and most importantly, it depends on the file contents itself. File size is less important than comprehensibility. If detailed images in a PDF are downsampled or compressed too much, they may well lose meaning, and that would be unacceptable in, for example, a medical document. So: always check a PDF after compression.

Secondly, guidelines may differ between countries. You should try and ascertain rough broadband penetration amongst your target users in that country. If that user group has low broadband penetration, then a smaller guideline size should be aimed for. For the general UK online population, broadband penetration is over 95%. But whatever you do, avoid the spurious statistics on www.internetworldstats.com (deliberately not linked).

Finally, consider the likely use cases:
a) A user downloading a document in their own time
b) A user downloading a document in a hurry (e.g. a doctor during a consultation, or someone just checking if this is the information they want)
c) A user sending a downloaded document by email

The following time estimates should be considered bearing the above use cases in mind. Let’s take an arbitrary file size of 4 Megabyte (MB). Maximum* transfer times are:

Dial-up (56kbps modem) 9m18s (for downloading or emailing)
Typical broadband download (2Mbps) 32s (for downloading)
Typical broadband upload (256kbps) 2m36s (for sending email)

*In practice many factors can make it up to 50% slower than this.

A positive factor to bear in mind is that PDFs in the browser will usually start displaying before they have finished downloading (provided that the PDF was created competently, but that’s another story.)

In conclusion, I recommended aiming for file sizes of around 2MB, up to a maximum of 4MB. If the file cannot be compressed below 4MB without unacceptable quality loss, consider redesigning the source material or breaking it into separate files. This does not mean that no attempt should be made to compress PDFs already under 2MB. Remember, the smaller the file size, the more users will appreciate it, no matter how fast their connections.

As an aside: I originally recommended the use of Apture, which can display dynamic previews in the page of PDFs in iPaper format, stored on Scribd. Unfortunately, due to legal issues around storing PDFs on Scribd, this was ruled out.

UX London conference (concentrate)

Published by Francois Jordaan on June 17, 2009 in User experience. Closed

I spent the last 3 days at the UX London conference, organised by the good folks at Clearleft. Very impressive speaker lineup, and generally a well-run, successful conference. Admittedly, much of it is preaching to the converted, but a handful of eureka moments, and connecting with the UX community, makes it all worthwhile.
It’s hard to imagine conferences without Twitter now. Many talks were live-tweeted, which I never saw the point of but, judging from comments, certainly has an appreciative audience. I checked the #uxlondon search periodically to see what people were thinking. (Would’ve appreciated some controversy; all a bit polite.)
So I decided to summarise the 7 presentations and 4 workshops I attended in 11 tweets (read on):

Continue reading ‘UX London conference (concentrate)’

BBC Radio 4 redesign: some thoughts

Published by Francois Jordaan on March 31, 2009 in User experience. 5 Comments

So, I mentioned on Twitter that I am disappointed in the redesign. Don’t get me wrong, it looks attractive and contemporary, and I’m by no means nostalgic for the old site (it was terrible). But the redesign didn’t do the things that I hoped it would, and also does several things that I don’t agree with.

My usage of the Radio 4 website (almost daily) is like this: when I’m stuck in one place, like washing dishes or ironing, I go to the website and try to find, as quickly as possible, something interesting to listen to. I’m not really loyal to any programmes in particular. I am aware that there are wonderful treasures buried in the site, but it’s usually a waste of time to click around. So I usually scan the homepage, especially Choice of the Day. Often I can’t find something that seems interesting, and I listen to the latest news broadcast. (I also have a similar use case when looking for podcasts to load onto my mp3 player.)

I was hoping for 2 things from the redesign:

  1. Many more recommendations on the homepage than before
  2. Generally better discovery features

Continue reading ‘BBC Radio 4 redesign: some thoughts’

One less frustration for British rail travelers

Published by Francois Jordaan on February 11, 2009 in User experience. Closed

I travel frequently between London and Isotoma’s York offices. Every time, I’m forced to endure the frustrating mess that is Thetrainline.com. A couple of months ago, when it had the temerity to run a customer survey, I vented:

The website has been a pain to use as long as it has existed, and the only reason you haven’t made any improvements is that customers are forced to use it in the absence of any real alternative. The moment that alternative comes along you won’t see me for dust.

Subsequently, The Trainline has rolled out some welcome usability improvements (not enough to call it a “new site” as they do in the interview on Econsultancy.) The homepage search form was greatly improved, and a clear, consistent accent colour on buttons and links helped a lot on other pages. Unfortunately, this is as far as it went, leaving their confusing, cumbersome, 12-screen journey unchanged.

The real alternative has finally arrived, in the form of National Express East Coast (note: not nationalexpress.com), designed by Flow Interactive. Here’s why:

Continue reading ‘One less frustration for British rail travelers’

Last.fm redesign controversy

Published by Francois Jordaan on July 28, 2008 in User experience. 4 Comments

Last.fm launched a major redesign just over 10 days ago. It’s not gone over very well: after over 2000 (mostly negative) comments on the blog announcement, discussion moved to the feedback forum, with threads on the new interface, most missed features and how Last.fm is handling the feedback (or not), all with 100s of posts. The “Bring back the old Last.fm” group hit over 5000 members in just 2 days, and is now over 12,000 strong.

As a long-term Last.fm user myself (along with the office), my initial reaction to the redesign was “oh no”, and unfortunately that’s not changed much as I got used to it. There’s only one feature I really wished for — charts that update continuously, rather than weekly — and plenty of changes that do no good at all. The site’s speed is still as bad as ever.

Continue reading ‘Last.fm redesign controversy’