Tag Archives: ux

Random UX change for the sake of… change?

If you’re making a highly visible change in the operating system UI that affects every running application, it seems fair to ask that it’s done for a good reason and that there is empirical data that supports it. Or, if no empirical data is available, that the change is made to make the transition to your OS smoother for users of competing OSes.

The new placement of window controls in Ubuntu 10.4 (beta)

This is why Ubuntu’s recent change to move the window control buttons to the left side of the window in the latest beta confuses me, because it appears that a chance has been made for no real purpose whatsoever other than a vague hint that it’s preparations for “some innovative options” on the now empty right side. But those experiments won’t start until version 10.10, due out in October 2010.

There are a couple of problems I see with this redesign:

  1. The Ubuntu layout is not just about switching from right to left — it’s introducing a completely unique layout never before seen in an OS. See how the Close button is still on the right side of the button group while the buttons were moved to the left side? This means that neither Windows nor Mac OS users will benefit from the change, as both user groups will have to relearn things here.
  2. The actual icons/symbols on the maximize and minimize buttons are also completely different from both Windows and Mac OS.  While Windows uses a horizontal line to represent minimize, and a square box to represent maximize, Mac OS uses colors instead (yellow to minimize, and green to maximize/zoom). Again, this means that neither Windows nor Mac OS users will benefit from the Ubuntu change, which uses some stylish arrows instead (pointing up to maximize and down to minimize). The icons make little sense (isn’t maximizing more about changing the size of the window, rather than the direction? does minimizing a window always move it down — what if your task bar is at the top like I have it?). To make it even more bizarre, once a window is in a maximized state, the icon for restoring the window looks like the actual maximize button in Windows 95/98/Me/2000/XP/Vista/7.

Ubuntu’s design lead Ivanka Majic tries to explain why the changes were made, but fails completely. She instead lists some questions they were asking themselves without providing any answers:

- Why do Mac OS and Windows have the buttons where they do?

- What was the functional reason behind the Mac OS choice (or the Windows position for that matter)?

- Why, when most application menus are top left should the window controls go top right?

- Why, when we read left to right is the most destructive action first?

So, what are the answers? Given that I haven’t seen any, allow me to guess:

  1. Mac OS and Windows have different conventions.
  2. I don’t think there were any serious usability studies behind either of the choices.
  3. Why not?
  4. Because it’s the most common action on a window?

It’s things like this that makes me skeptical of so-called usability experts when they think they can get away with changing things for the mere sake of change, without any evidence whatsoever that it’s a change for the better.  Majic ends her blog post about the window control button placement by indicating the true reason why they went for a completely unique arrangement:

Personally, I would have the max and min on the left and close on the right.

Update: My insanely sharp colleague Jennifer Boriss writes about this topic more elegantly from a user experience expert perspective.

Some ideas for the mobile Firefox UI

This post is also available in Belarusian thanks to Marcis G. Thanks for the translation!

Following up on my post yesterday about my impressions with web browsing on the N900, I wanted to elaborate on one of the points I was making: Firefox’s UI model of showing controls (a.k.a. chrome) on two sides of the web page.

I see a few problems with it:

  • You need to swipe your finger in a specific direction in order to reveal specific chrome (e.g. swipe to the right to show tabs, and swipe to the left to show Back/Forward buttons and some other controls).
  • The split between the chrome on both sides isn’t natural. For example, both Back/Forward and tabs are types of navigation, but they’re on separate sides. This means you simply have to learn on which side specific UI is located. Not a huge problem, of course.
  • If you’re zoomed in on a page, you may have to swipe several times to reach the side of the web page and reveal the chrome (or double tap and then swipe).
  • Having controls at the bottom of the screen feels more intuitive to me. More objectively, though, it also works better in portrait layout when you’d rather not waste width on chrome.
  • The required panning of the web page itself when reaching for chrome feels rather clunky. I’m swiping to reveal toolbar buttons, not to pan around on the page, but I have to do both at the same time in Firefox.
  • The tab thumbnails are always of the same (small) size, since the chosen tab model doesn’t allow for flexibility.

My simple ideas:

Allow me to present a few ideas on how the UI could be simplified. Please excuse this poor GIMP mockup:

The mockup above shows a redesigned navigation toolbar and a different way of switching tabs. Let me explain each feature in more detail:

  • The new toolbar is overlaid on top of the web page and fades (or slides) into view when interacting on the page (e.g. when scrolling or tapping).
  • All buttons are on the same toolbar. This means that you don’t have to remember which direction to swipe to reveal the controls, because any direction works.
  • The web page itself doesn’t pan when the toolbar appears.
  • After a short while of no interaction, the toolbar fades/slides away again.
  • The left side of the toolbar shows the Back/Forward buttons, the center shows the Tab (or Web Page) Switcher button, and the right side shows a Bookmark and a Tools button.
  • This toolbar can easily fit in a portrait layout.
  • Clicking the Tab Switcher button shows the currently open tabs. The size of the thumbnails change dynamically depending on the number of open tabs. Clicking on the Tab Switcher button again or outside the tab switching “pop-up” takes you back to the current web page again.
  • Clicking the Tools button reveals a “pop-up” similar to the Tab Switcher chrome, but this one of course shows the Firefox options window. Rather than clicking a back button to come back to the web page, you click outside of the “pop-up”.

In addition to the ideas above, I would also suggest that the toolbar is made customizable. Personally, I would like a zoom button (maybe even a +/- type of button) instead of a bookmarks button, but there’s obviously a limit on how many buttons you can show at the same time. This mockup assumes approximately the same button size as in the MicroB browser, so there would be plenty of space for buttons, at least in horizontal layout.

Thoughts? Piece of crap? Just shoot me.

My impressions with web browsing on the N900

I’ve recently had the pleasure of testing Firefox on the brand new Maemo based Nokia N900 phone (which I blogged about previously), and I have to say I’m impressed. Of course, I’m biased — I love Firefox. I’ve been using it since the Phoenix days and it’s almost part of my DNA these days.

However, I have a confession to make: Firefox isn’t yet my default browser on the N900. I think it will be very soon, but right now, my browser of choice on this particular device is another Mozilla-based browser: MicroB. It’s actually the best web browsing experience I’ve ever had on a mobile device (but to be fair, Firefox is the second best experience, so it’s definitely up in the same league already).

Allow me to summarize my initial impressions with both of these Mozilla browsers:

  • The Awesome Bar in Firefox is… awesome. I never actually reflected on how convenient it was to use until I tried MicroB, which forces me to remember URLs again.
  • Weave is probably extremely useful, too, but since I’m using the latest trunk builds of Firefox (“Fennec”), I can’t actually use it.
  • I’m not completely sold on Firefox’s UI model of showing controls on a surface on the sides of the web page. I’d be curious about whether there has been any usability research that suggests it’s better than the more traditional toolbar at the bottom of the screen. Btw, I’ll follow up with some ideas about this in a future blog post.
  • I’ve fallen in love with the volume rocker zoom in MicroB — it’s smooth, fast and surprisingly accurate. Would love to see this in Firefox!
  • When double tapping to zoom in MicroB, a subtle zoom animation is used which feels intuitive and responsive. In Firefox, the zoom is instant, making it feel less fluid.
  • The default page zoom in Firefox is designed to make the full width of the page fit on the screen. This unfortunately has the side effect of making the text on almost all web pages too small to read. It seems like MicroB has chosen a different approach where the default zoom includes about 800px of the web page width, which makes it possible to read most pages without zooming in.
  • Actually zooming in on a page in Firefox is a bit tricky, because it auto-zooms on the object you double tab on, even if that object is only e.g. a small image. This means that you often zoom in too much, and since it’s not possible to adjust the zoom level in an easy way (keyboard shortcuts don’t cut it, especially not for me since I have the Scandinavian keyboard layout where [Ctrl]+[-] doesn’t work), you have to double-tap again to zoom out and then try again.
  • MicroB feels more responsive when panning around on a page. This is mostly due to the fact that the UI and panning is done in a separate process from the actual Gecko web rendering process. At FOSDEM, I was pleased to hear in the Mobile talk by Mark Finkle that Firefox will make full use of the Electrolysis technologies that are currently being baked. What this means, in simple terms, is that Firefox will be just as responsive as MicroB in the future since the web rendering process will be separate from the UI/frontend. I can’t wait to see the results of that (which of course will benefit desktop Firefox as well).
  • The checker pattern seems to show up more frequently on the screen in Firefox compared to MicroB. I don’t know if Firefox is just more conservative with how much of the web page it pre-loads off-screen, but sometimes it can cause the whole screen to remain “blank” for a few seconds, which rarely happens with MicroB.
  • The Back button history in MicroB is a good idea in theory: when clicking the Back button, small thumbnails of the previous pages are shown, making it easy to pick the page you want to get back to. However, the implementation sucks because it takes several seconds to load these thumbnails and the thumbnails are big enough that you have to pan around in order to see anything more than one page back. Would be nice to see some kind of combination of Firefox’s and MicroB’s implementation: when tapping on the Back button, Firefox would simply go back to the previous page, but when tapping and holding, it would show a pop-up with preloaded thumbnails in a similar fashion as with MicroB, except without the delay. (Maybe the actual thumbnails could be recorded when you navigate away from a page?)
  • Flash — as much as I hate it — works pretty well in MicroB out of the box. In Firefox, I have to enable it manually, and the responsiveness of the UI with Flash enabled isn’t great. Can every web site switch to open video, please?

I personally feel that both MicroB and Firefox are really good web browsers, and the fact that they’re both powered by Mozilla’s Gecko web rendering engine is a huge plus for me. So in a way, I don’t feel bad for not using Firefox primarly right now, because my current web browser of choice is still filled with Mozilla love. :)

That said, I can’t wait to use an Electrolysis-powered version of mobile Firefox later this year!

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?

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!

Nothing to see here, please move along

I regard myself as geeky enough that I should be able to solve computer problems myself, or at least with the help of some self-service online searching. However, there are times when I simply can’t figure it out. I don’t know if I’m slowly getting dumber as I’m getting older, or if I’m just getting used to the ever-improving user experience in modern software (after all, I spend about 80% of my time in front of the computer using Firefox). Or maybe certain software is just particularly unhelpful?

Whatever the reason, I obviously care a lot about user support, and use all the opportunities I can get to explore how other products/projects handle support. Also, I’m genuinely interested in user experience design, so I thought I should share this combined support/UX problem, not just as a self-centered way to ask for support, but because the subject genuinely interests me.

My morning greeting from Colloquy the last 12 months or so.

The problem I have is with the IRC client for Mac called Colloquy. Every time I start the program, it pops up a notification saying “You have 1 new memo.” Clicking on this notification does nothing (other than closing the notification itself) and I have searched through all menu items trying to find a place where I can actually read this memo. So far I have failed, and today I thought I should do some searching to find the answer online.

I started by searching in the Help menu and selected Colloquy Help, which took me to their Wiki documentation site. A search for “memo” there mostly resulted in articles about memory leaks, so I performed both generic and specific searches on Google instead.

A search for “reading memos colloquy mac” finally revealed the solution: the notification about 1 new memo is actually coming from the message server of irc.mozilla.org, not from Colloquy itself! After some experiments, I finally figured our how to read it.

To read my memo, I had to type, in irc.mozilla.org:

    /msg memoserv read 1

And to remove it, I had to type:

    /msg memoserv del 1

The conclusion? IRC is not for mainstream users.

Sorry for wasting your time by stating the obvious like this!