Monthly Archives: June 2009

Microsoft – Making it easier

Microsoft in 1984Remember back in 1984, when people were using Word to compose their e-mail messages that were sent around to colleagues and friends? We’ll chances are people will keep doing that in 2014 as well.

We’ve made the decision to continue to use Word for creating e-mail messages because we believe it’s the best e-mail authoring experience around, with rich tools that our Word customers have enjoyed for over 25 years. Our customers enjoy using a familiar and powerful tool for creating e-mail, just as they do for creating documents.

The Power of Word in Outlook

How do you want your e-mail experience to look like in the next five years? If you think Microsoft is on the right track, take no action. If you think they should switch to modern standards, send a tweet asking Microsoft to improve standards support and make sure you include fixoutlook.org in your tweet.

Or just switch to a better e-mail program.

Another poor website UX example: expressen.se

My blog post a couple of days ago about DI.se’s poor website UX was really just one example of websites that make use of “modern” features while failing to actually make them useful. expressen.se is another example, but for other reasons.

Similar to DI.se, they have a toolbar section for each article with functions like changing the text size, printing the article, and even fancy things like sharing the article on Facebook. The problem is that they choose to have this toolbar at the bottom of the article, not at the top! Granted, some of these functions are likely very rarely used, and only meaningful once you have actually read the article (such as sending an article link through e-mail), but changing the text size is something you will want to do before you start to read the article, not after!

Their stupid design means that in order to increase the text size of an article, you have to follow this procedure:

  1. Click on the article link you want to read.
  2. Scroll down to the end of the article (usually somewhere in the middle of the page due to the typical display of the main site content after the article.
  3. Click on the a a a toolbar buttons to select your desired text size.
  4. Scroll back up to the start of the article and start reading.

To make things even worse, expressen.se, just like DI.se, doesn’t remember the text size chosen, so you have to repeat this procedure for every article you read.

Why are these things so hard for website designers to get right? Remembering the text size is as simple as storing and reading a website cookie. Even I managed to do it on the ancient Phoenix Help website back in 2002, so why are so many modern news sites still struggling with it?

I fell in love with Geneva

It’s Midsummer Eve in Sweden and I finally got some time to reflect on the fantastic weekend I had in Geneva together with other members of the Mozilla community. I was there to lead a discussion about SUMO and community support, with a focus on sharing experiences between the five local communities represented: Denmark, France, Germany, Italy, and Spain.
Mozilla Italia on SUMO

The discussion started with Mozilla Italia sharing their experiences with community support, where they explained why they recently decided to switch entirely to SUMO. It was really insightful to hear their main reasons for using SUMO today. Among other things, they said that:

  • Outdated content is worse than lack of content
  • If your documentation isn’t easy to find or badly structured, there’s no point in having it
  • Good documentation requires consistency, quality, and precision

This is absolutely true and we are constantly working on those three points on SUMO, so I was glad to see that these values were shared with Mozilla Italia. I was very impressed that they took the time and energy to share these experiences with the other communities, who are all handling community support in different ways.

After the presentation, the floor was open for questions and discussions, after which Simone, Francesco and Giuliano passed on the torch to me to hold a discussion/presentation combo about SUMO in general. Among other things, I showed the many new features in SUMO — both implemented and still in the works. In total, the SUMO discussions went on for over an hour, and many interesting ideas came out of it.

Discussions

For example, we were discussing the best way to indicate in the search results that some of the content is only available in English. Should these English results be mixed together with the localized content, or should it be separated? Should we add labels specifying the language of the article? Should the behavior differ depending on locale? For example, in Germany, mixing English and German content isn’t as common as mixing Swedish and English content is in Sweden. Kadir pointed out that in Germany, the existence of English content on a German website can even lead to mistrust of the quality of the website.

GenevaAfter almost nine hours of discussions and presentations, it was time for us to explore Geneva and have dinner. I have to say that I fell in love with Geneva. It wasn’t just the nice weather or the beautiful buildings — there was something with the atmosphere that made walking around in the old town at night taking photos together with fellow Mozillians really, really enjoyable. I think everyone felt extra proud of being part of the Mozilla community that night.

In retrospect, I think that this inter-community meetup was one of the most successful Mozilla events I’ve attended to so far. The focus was on exchanging experiences and discussing, rather than passively watching other people’s presentations. It really worked very well to have a smaller group of people, as that made discussing various topics much easier. Also, William’s “no laptop rule” helped everyone stay focused on the purpose of the day rather than escaping into the wonderful world of bug filing, blogging, tweeting, and coding. :)

A huge thanks has to go to William for ensuring that the day was a true success. Big thumbs up from me, William! I would also like to thank Simone Lando, Giuliano Masseroni, and Francesco Lodolo from Mozilla Italia, for so openly sharing their experiences, pros, and cons about SUMO. It was incredibly helpful!

User experience and houseflies

As I mentioned previously, user experience (UX) design is one of my specific computer interests, and as the project lead for Mozilla’s Firefox support website, I obviously care a lot about website UX in particular.

One thing that keeps annoying me is how many websites are designed to make use of some “modern” features of the web like Javascript to enhance the visitors experience while still failing utterly in the common sense department.

DI.se, a Swedish financial website, is a good illustration of this. As with many other news websites today, they have a small toolbar strip at the start of each article with buttons for things like increasing the text size (something which can be really useful since most web designs tend to think that small fonts are more pretty than big fonts, and the average physical screen size of new laptops is only getting smaller).

DI.se’s article toolbar. Looks can be deceiving.

Now, the thing that makes DI.se worth pointing out as an example of particularly poor UX design is their decision to make the toolbar about as hard to hit as a housefly.

When you hover the mouse pointer over a toolbar button, the whole toolbar suddenly changes from the button-only, horizontal layout to a vertical one with text labels. This makes all toolbar buttons change place, and your first attempt to click on a button is surely going to be a miss.

When designers make decisions like this, I wonder if they really took the time to weigh the benefits against the drawbacks, or if they just didn’t have time to think in the first place. There are of course many simple changes that could be applied to improve this. For example, they could have made the toolbar wider and show the text labels at all times. Or, they could have kept the horizontal, button-only layout and just show the label of the button being hovered over using the same CSS/Javascript technique they’re using today, without changing the location of the button.

Of course, I took the time to point this out to the DI.se webmaster over a year ago, but as with so many other popular websites, the webmaster didn’t respond, and, as is obvious by visiting their website today, didn’t think the problem was important enough to fix.

Maybe it isn’t a huge problem, but it is certainly annoying; especially since the website doesn’t even remember the text size you choose, so you have to redo the procedure every time you read an article!