By and large I find these sorts of usability experiences enlightening and useful. Rather than bog myself down in the finer points of the debate about which of Windows, OS X, and Ubuntu GNU/Linux sucks the least, I prefer to focus on the flaws discovered that are very clearly flaws. In a lot of cases, the most experienced of us have simple solutions to them. The problem with these solutions is that they are mostly invisible and it's hard to find out about them without the right expert around. I will present some of my ideas on what the things that are clearly weaknesses and the solutions I'd like to see to the problem.
Second task: Watch a video on YouTube.
The problem Erin ran into really is actually a problem with YouTube!. The Firefox developers implemented a nice clean way to auto-detect and help solve the problem of no flash being installed. Even that solution fails sometimes though, with invisible errors. Here are some potential solutions I see to the problem:
Firefox and Adobe could team up to help Firefox detect when a page has invalidly redirected them to the "Install on Linux" page of Adobe's. Both sides would need to work this one out because Adobe needs better documentation and Firefox needs a good hook to realize the user has been led off the correct path, but still handle when the automatic install simply fails.
YouTube! can stop trying to automatically detect the flash player the way that it does. In addition to breaking Firefox's great automatic feature, it also causes videos to fail when using NoScript with Firefox.
Ubuntu can add to their modifications its own ways of detecting that somebody is trying to use flash and offer help. This solution would probably be very similar to any collaborative one implemented by Firefox and Adobe, so, if they get that working, it should be pushed upstream.
Fifth Task: Burn an album from my music collection.
Erin had no problems getting the burn software going, but couldn't figure out where the music files on the system were. There are two aspects of a generic complaint which I think are valid here: why didn't something point her to Tracker to try and find those music files? and why isn't Ubuntu using drive labels?
This sort of deficiency is a technical challenge that I've seen the Gnome community moving towards. The full feature set of the operating system needs to be cleanly integrated into all important points of the stack, with options so we don't trap users into one type of anything. People are already on this one and I think they have better ideas about it than myself.
The latter seems plain wrong to me. The specific cause of this problem is likely to be deep within the Gnome software stack, but it should be fixed. "498.8Gb Volume" is in general only enough information to distinguish varying connected devices, even if you know exactly what that is. In my personal case, I have two USB connected drives that are the exact same size. This transforms into "498.8Gb Volume" and "498.8Gb Volume (1)."
My preferred naming scheme would continue to include the size and the drive label. If there is no label, or it's detecting that multiple drives are connected with the same label, displaying the file-system type would be a useful fallback. That fallback display should probably be along the lines of "Windows NTFS" or "Linux ext3" so we can preface the expert-oriented information with simple-to-use for a user.
I want to focus on the suggestion previously about detecting when multiple drives have the same label. This sort of behavior is imperative because the purpose of the label is two-fold: to quickly identify a volume's purpose and to differentiate a volume from others in the list. The second purpose isn't immediately obvious until you have three or four connected devices that are essentially identical.
Screen real-estate can become a problem with these solutions, but, I think this and many other problems would be solved by using labeled separators in menus. If the grouping of "External Volumes" can say that as a heading to the group in the menu, rather than in each entry in the menu, we've saved a lot of space that was wasted before without skimping on information.
Ninth Task: Change screen resolution.
Erin screwed up and changed the screen resolution to something ridiculously tiny. The little fall-back dialog failed her and she was stuck with a screen height smaller than the dialog that was used to change the screen height.
The correct expert answer to this problem is to hold alt and click on the window. This activates a move mode where you can push the window above the top of the screen to get to the bottom of it. In addition to being entirely invisible, I recall versions of Metacity and WindowMaker that felt this use-case was always an error and wouldn't let you move windows off screen like that. They were in error and I had to kill more than a few Xsessions because of this.
The basic problem is simple: What should an application do when there isn't enough screen space for it to render all of its contents? Firstly, I don't think the application should do anything of than generally design their interface to only use the space actually required for the task. Secondly, I would actually put the onus of solving this on the window manager and X, since sizing the client rectangles is actually the job of these two things. I have two primary ideas for what they can do: Automatically add faux space for screen-scrolling when any window requests to much size, or scale the window to fit the screen properly.
Some may not know that in X you can set the physical and virtual viewport separately. What this means is that you can tell X that your monitor is 1024 by 768, set your viewport to 640x480, but your virtual desktop size to 1600x1200. When this happens, you get a 1024x768 monitor viewing into 640x480 scaled up however your monitor handles that. When you scroll to the edge of the screen it moves with a 640x480 window looking into a 1600x1200 desktop. This is a sort of free desktop zooming.
It should be somewhat obvious how this can solve our quandary of an inaccessible dialog. If X activates a version of this mode automatically, extending the desktop out in the direction the window went over, then, when the user frustratingly smacks the pointer into that side of the screen hoping it will go down, it magically does! I like the wow factor of this solution and how much it fits in with angry human behavior, instantly calming them down because the computer listened and knew what they wanted.
Much simpler, but possibly easier to implement. Render the normal contents of the window into the size it thinks it should have, then the window manager takes a snapshot and scales it. This seems like something Compiz could do fairly easily, but there would need to be an implementation for those without the fancy graphics card support.
Eleventh Task: Log onto MSN
Erin is confused by the arrangement and naming of the options when trying to set up an account using Pidgin. She's only ever used MSN, so, the non-MSN oriented naming throws her off.
This is partially a problem I don't care about. Differences in naming between these systems is fairly dumb and everybody should learn to use jabber anyway.
The actual core problem I see is observed by the author: "also, why does local alias seem like a necessary piece of information required to create an account? Seems like it confuses more than aids a new user." This observation is spot on. A separation between data required for the account, and optional settings that modify local display, would be extremely useful. More to the point, a local-only alias has absolutely bearing on account setup since that is all externally transmitted information. Why should we lump this all together?
I don't think another tab is the answer, but a spring separator with a "More Options" or "Display Options" would be useful. If the user is curious, they could check them out. The options will be labeled in such a way so they know if "Local Alias" is confusing, they don't have to care about it to get their account going. This also seems like a way that doesn't take away from power users or later account modifications.