Archive for the 'User experience' Category

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’

Best practices for speeding up your site

Published by Francois Jordaan on April 16, 2008 in Javascript, Patterns, User experience and XHTML/CSS. 1 Comment

Best Practices for Speeding Up Your Web Site — part of an excellent series of articles on the Yahoo Developer Network.

They mainly focus on the front end, as that is where you’ll get most bang for your buck. They make frequent reference to YSlow, a Firebug extension that looks extremely useful.

The presentation here is also strongly recommended, as it makes succinct arguments for all the techniques. (View on Slideshare to see it full-screen.)

Some things were familiar to me (and most are already standard practice for my colleagues), many weren’t (e.g. avoid @import for CSS), and some I know of but haven’t been convinced of before (e.g. CSS sprites). I was quite intrigued by this example of CSS sprites in use on Google. (When using CSS sprites, remember to consider their accessibility to screen readers, and don’t use if you want them to print.)

Reflections of a Windows-Mac switcher

Published by Francois Jordaan on March 3, 2008 in User experience. 1 Comment

10 months ago, starting a new job and needing a new laptop, I had a choice of platforms. Since I work in user experience design, knowing multiple operating systems is valuable in keeping my frame of reference as broad as possible. I haven’t used Macs after 1999. I certainly preferred Win2000 and WinXP over Mac OS 7-9, but have become frustrated with Windows with increasing regularity. So I opted for a Mac (Powerbook 2.33 GHz Core 2 Duo with 2GB RAM).

Since then, I’ve kept a list of the pros and cons of OS X (Tiger) compared with WinXP. Naturally, there were many annoyances in the beginning, but I didn’t want to blog about it until I’ve become settled on the new platform. I’ve not strictly switched either, since my home computer still runs WinXP, and I simply couldn’t use OS X without also having WinXP on Parallels.

Short version: Took me about 3 months before I preferred working on the Mac, and am now likely to stick to the platform for work. Read on for my list of OS X annoyances, and likes.

Continue reading ‘Reflections of a Windows-Mac switcher’

In praise of invisible text

Published by Francois Jordaan on March 3, 2008 in User experience. Closed

As a website accessibility feature, invisible text has long been accepted as one of the most helpful things you can do. This is text that is invisible on screen, but read out in screen readers, using CSS like the off-left technique. So far, as in those articles, we’ve primarily used it to add skiplinks and invisible headings.

Yesterday, while peeking under the hood of the new BBC homepage (very impressive HTML/CSS), I noticed another very handy use of invisible text: replacing the oft-overused title attribute. Under the Radio section, a link that looks like “Listen Live” will actually be coded as <a href="/radio/aod/radio1.shtml" class="radiopop">Listen<span class="hide"> To Radio 1</span> Live</a>. For a sighted user, the visual context makes the extra text superfluous, but for screen readers users, it’s indispensable.
This is akin to “Read more” links, for which we’d usually add the associated page title in a title attribute (still a popular recommendation). But you can’t actually count on all screen reader users hearing the title attribute. (The fault of assistive technologies, but nonetheless…)