Desktop Shells, Usability and Trackers. Oh My.

A while back, I read with great interest Vincent’s blog entry. I also heard from my fellow Canonicalites about the progress made the GNOME hackfest. I am rather interested in the opportunities before us with the GNOME platform and a new approach to the shell, so when I read Owen’s update I may have actually drooled. Instead of grabbing a tissue, I instead grabbed jhbuild and built said shell. Instructions for the brave are here. Its actually pretty simple, so no real bravery required.

Things have changed a lot in computing in recent years. Back when GNOME 2.0 was released we were not faced with the plethora of use cases that we are confronted with today. Social networking, online services, the cloud, collaborative editing, (micro)blogging and other such buzzword compliant technologies are now a staple in not only the life of technical types like us, but regular people: even my dad has a blog. In recent years the industry has pointed its innovation-ray squarely at people and what people do. We are no longer expected to dance to the computer’s tune, but it dances to ours.

The GNOME community has been on something of roller-coaster reacting to this, and the subsequent potential changes in focus and interface concepts. Many have called for GNOME 3.0, or whatever it is codenamed this week, but for too long it might as well have been called Project Vaporware. GUADEC after GUADEC it was discussed, there were many ideas, but no design document, implementation plan or approach. I even talked to Stormy about personally taking some time off and getting some key people in the same room to discuss this. Shortly after those discussions, the hackfest happened (nothing to do with me), and I am tickled pink at the opportunities that have arisen from it.

On this topic, I would like to raise an important question, and one that I would be delighted for the GNOME community to think about, and the wider Free Software community to think about too. Your comments, as always, are welcome.

In recent years we have not only seen a change in focus in how computers are used in people’s daily lives, but we have seen an evolution in community. Years ago, if you wanted to be a part of our community, you really needed to be a hacker. You needed to be able to code in C and know what on earth a memlock or a refcount is. Beards were optional, but generally recommended. As time progressed, out community diversified – documentation writers, artists, advocates, testers and more came on board. One such role that joined our merry bandwagon has been interaction designers.

Matthew Paul Thomas, Seth Nickell, Celeste Lyn Paul, Calum Benson, to name a few. Across our community we are developing skills and expertise in how people work with interfaces. I myself have always had a keen interest in this area, but it has largely remained a hobby. Those who commit the majority of their time to this important science have read, refined, explored and questioned the nuances in how we connect human psychology to practical interfaces. This kind of input is incredibly valuable. We need to be encouraging these contributors to be involved in the design stages of our interfaces and applications, be contributing perspectives on high-level goals and significant and highly visible areas of the stack such as the gnome-shell, be involved in consistency across applications with style guides and toolkit design, and importantly, be regularly testing and evaluating existing experiences so that we can learn more about where we stand today in an effort to make tomorrow a more usable place. A good example of this is Matthew Paul Thomas’s Empathy and Pidgin usability evaluation. Those kinds of assessments are superb.

Few would disagree that these contributions are important, but we have not yet figured out how to merge these contributions into the development process. Unfortunately, all to often, these valuable contributions get lost, seemingly ignored and never implemented. The reason for this is twofold.

Firstly, when an upstream developer receives a set of interface recommendations and changes from an interaction designer, for them to be implemented it requires that he or she either (a) agrees with those recommendations or (b) has faith in the designer and their recommendations. I would like to imagine that most upstream developers would be able to put their faith in the abilities of the designer, trust their judgement, and implement designs that they may not be 100% in agreement with. I suspect not though. I suspect that in all too many situations, upstream developers receive good solid designs that they may not really agree with, and despite resounding evidence to suggest the design is a better approach, they choose not to implement them.

This though leads us to the crux of the issue. What we need to fix is how interface design recommendations are communicated and recommended to upstream projects and distributions. In software, if something goes wrong, you can file a bug in a bug tracker. If you need to communicate with an upstream, there is a mailing list. If you need to obtain source code, there is a source repository. Where though is the natural home for communicating interface design ideas, fixes and discussing and debating common problems in existing interfaces? The popularity of bug trackers has been largely due to the structured nature in which the data is stored – they are highly searchable and work well with a developer’s workflow. This has made them more suitable than general communication channels like mailing lists. Bugs appear on mailing lists, but participants almost always recommend the poster to file a bug report.

We need tracker for interaction design fixes and proposals. We need to understand how to structure, communicate, discuss and implement interaction ideas more effectively. I would love some interaction designers to sit down and hammer on this question for a little while. How can we not only structure ideas but also tie them elegantly into actual development? How can we structure and come to a conclusion on an interaction concept and then hook in the implementation of that concept? An ideas forge is not enough – an organised list of never-implemented ideas is not much more useful than a disorganised list of never-implemented ideas. We need to understand how to smooth how the interaction rubber hits the development road.

I think this is an important problem for us to solve, and if we get it right, we could reap the benefits of so many brilliant minds out there whose brains are wired to understand interactions as elegantly as possible. Just imagine what could be possible.

  • ethana2

    I think a tracker is a great idea, maybe even better than hiring experts. For example, once I tell evolution what I service I use, it should need two more pieces of information from me: user name password Goodness knows how many it actually asks for, I got confused and just gave up on it and stuck to gmail’s web interface. I didn’t remove evolution from my system ’cause I heard it would break stuff if I did.

  • ethana2

    Interesting, This comment form devours formatting. Now my comment, with its single typo, looks like a deranged rant. The idea though is that users can give you a lot of ways to improve UIs before you have to resort to user interface theorists and ergonomic experts, and a good UI improvement tracker is just the way to let them do that.

  • http://stevenbrown.ca/blog Steve

    This sounds nice, but (and these are just my thoughts)…

    Most users will fail to provide something useful. Firstly, because they think they are doing something wrong – or they’ll feel they just haven’t “learned” the system yet. They will blame themselves, not the interface. The thought of making a suggestion to improve the UI of app X will be the farthest thing from their mind. Which is fine, because they probably wouldn’t have the first clue about what to suggest. But people who do understand UIs should definitely pay attention to the problems these people are having. So how do you get people having problems to let others know what their problems were? Ask if we can collect mouse movement data? Place a “I have a problem” link in the Help menu? This link could be a decision tree kind of like WIndows XP’s help menu system, with information collected?

    Integrating it with the help menu of each application, like some are integrating launchpad could be a first step, I suppose, but this will only reach the other users. Notification bubbles about proposed UI changes, or new UI suggestions for an app the user is currently using would be a nice nudge, as well.

    I have to amend your bit about reasons upstream devs will often turn a shoulder to UI suggestions: implementation is hard. The harder the implementation, the more time it will take. The more time it will take, the less time they have to scratch THEIR itches. Implementation is made even harder when the suggestion is unclear – which is almost always. Implementation often requires painful amounts of detail and end-case consideration that most users, even the ones taking time to draw up pretty mockups (myself included), won’t want to think about.

    User: “It would be great if I could do this here.”

    Developer: “If we put your feature there, what would we do with our other feature XYZ?”

    User: “Oh, I don’t know…”

    And other times, the suggestion is 2 pages of text that don’t convey a clear message. Which I’m starting to feel this comment is becoming – I apologize for my ramblings.

    The tracker would need some kind of design tool integrated within it to produce standard recommendations/blueprints. And this tool would have to ‘encourage’ users to pay attention to details they may otherwise not. But it would help produce clean, simple, standard (common-language) mockups or suggestions that developers can comment on without feeling burdened. I think this design tool and the collecting more meaningful data (both actively and passively) from regular users (not the ones willing to make mockups) are the biggest tasks for this tracker to be successful. The rest is basically integrating them into a web app and producing pretty charts. Perfect UIs will magically follow, of course. :cool:

  • http://mpt.net.nz/ mpt

    Steve, I think you’ve misunderstood Jono’s proposal. He’s not trying to get end users to make design suggestions, but to find a better way for dedicated designers to discuss proposals with developers.

    I think having a separate tracker for design suggestions would not be a good idea, because having multiple trackers generally hides information and leads to poor prioritization. For example, ideas posted on Ubuntu Brainstorm are often unintentional duplicates of ideas already posted to Launchpad Bugs or Launchpad Blueprints (which are already awkwardly redundant with each other). Brainstorm does have benefits — inspiring enthusiasm and drawing noise away from the bug tracker — but the costs are non-trivial.

    This would be even more of a problem with a tracker devoted to interaction design, because design is often performed to solve a particular interaction problem that is already filed in the bug tracker. Sometimes design suggestions take the form “X currently needs four clicks but it could need only three if this was changed”, but more often they are proposed solutions to problems of the type “X is inconsistent with Y” or “People accidentally trigger X too often” or “X isn’t understandable to most people”.

    I suggest instead redesigning bug trackers so they can better track multiple possible design solutions suggested for a particular reported problem. This would help more than just interface designers: everyday bug reporters often confuse a problem with a suggested solution, as seen for example in most bug reports that use the word “should” in the summary.

    Launchpad’s editable bug descriptions are a very small step towards tracking suggested solutions for reported problems. Being able to sketch drawings and embed them into bug descriptions and comments would help too.

  • Tom

    Decoupling the program logic from the UI would make things much easier.

    If interface designers could easily change the UI of any app they could just send patches.

    Not easy, but IMHO the way to go. Maybe a good idea for 3.0.

  • Mark

    Contact the Gimp team. They have been experimenting with this kind of collaboration for a while.

  • http://paul.kishimoto.name Paul Kishimoto

    On the usability test by Matthew Paul Thomas, there’s a guy named Troy James Sobotka that makes some derisive but pointed comments: https://wiki.ubuntu.com/EmpathyVsPidginUsability#Comments

    Usability analysis is good, but usability testing (with fresh users) is also valuable. A university lab did Drupal a great favour in releasing some results from a usability test: http://drupal.org/usability-test-university-baltimore-community-solutions

    …this sort of thing would seem to be incredibly valuable to Ubuntu. Simply seeing the video allowed me, as a Drupal developer, to adjust the way I designed module interfaces. It would be difficult, but killer, to provide a distributed mechanism for this kind of usability testing (perhaps without eye-tracking)—e.g.: * User agrees to begin a test; by clicking an apt-url link on the Ubuntu website, usability testing packages are installed. * User fills out a short demographic survey. * Test user’s microphone. * Begin a screencast (video and audio). * Dialogs with instructions, clearly differentiated from the application being tested, appear. * User reads instructions and tries to perform tasks, narrating into microphone (“Now I’m looking in the menus for X…”). * User checks a box or indicates whether they felt they successfully completed each task. * User ends the test. * Video and audio is encoded and uploaded by a background application to Launchpad or elsewhere. * UI ninjas view the result and summarize important conclusions.

  • http://paul.kishimoto.name Paul Kishimoto

    ^ mangled comment #2 :cry:

  • http://effiejayx.velugmaracaibo.org.ve effie_jayx

    Maybe GNOME should have a Idea-storm Like site were people could vote on the features users would like to use the most.

    For a while I though reorganizing the desktop could be a great way to start. at times I believe the to panels just take up a lot of space on my screen. I though Gimmie could give it a taste of things to come, but thing is it isn’t quite as polished

  • http://jackflapb.wordpress.com Alex

    One thing that stands out in my mind, was when Firefox changed how the users closes each tab window.

    They moved the single X on the top right corner of the firefox window, which would close the current active tab, to be so that each tab had a single X next to the tab-title.

    I vaguely recall this was sometime between ff 1 and 2, and it was certainly a scary transition for myself. I remember hating the idea of moving my trustworthy X’s around, but Firefox made a statement saying that some research had been done, and the surveys suggested that for non-technical users, the X on the tab-title was more intuitive.

    They since went ahead with the change, and frankly, I much prefer the new method now.

    But the point is, they used a surveys. Perhaps, since this worked so well in FF, all usability interaction design suggestions should be backed up with usability surveys, which may turn out to be a very solid way of quantifying the usability decisions made. And also something that developers can’t ignore.

  • Jeff Hatfield

    Seems like what we need is an easy to use prototyping tool that designers can use to flesh out their idea in more detail. That way when they had it to the developer it’s a more fully formed idea that has dealt with some of the hard stuff.

  • dave

    I wanted to say how important this is and what an enormous topic this could be (easily as big again as how can developers contribute and colllobarate on code).

    But I particularly wanted to comment on how Ubuntu/Canonical is doing 2 incredibly important things: a) recruiting competent professionals to review the software, and b) making inclusion decisions based on usability. Both are clearly sending the much needed message “this is important!”.

    As you point out, developers are ‘choosing’ not to make changes. Including usability as an important factor in what gets into default setups for Ubuntu and/or Gnome gives much needed feedback.

    I’m hoping we’ll get somewhere close to the Mac situation where the ordinary user is so accustomed to good user interaction design that the basic errors are simply unacceptable, even if they can’t quite articulate what the problem is, something is seen simply as “un-Mac-like”. Unfortunately in current Linux desktops, there’s too many broken windows, but I’m looking forward to the day when poorly designed software might be described as “not Ubuntu-like”.

  • http://blog.zrmt.com andylockran

    Jono,

    I came into Open Source Computing from a Psychology, with the idea that managing interfaces & usability was key. However, I’ve found that rather than sit on my high horse and start directing programmers about, how to implement this and that .etc – I actually had to learn to program myself.

    There’s so much hidden complexity in programming, that gets hidden due to the skill of the developer. I therefore believe that we need to have en educated core of developers/designer types – rather than getting one developer and one designer to try and interact.

    I guess the main thing is creating usability guidelines that developers and designers can contribute to – but which includes the ‘freedom’ to move outside the box, but not leave it entirely. It’s an art, not a science.. but hopefully one we, as a community – as opposed to a bunch of individuals – can master.

  • Daniel Borgmann

    I like what andylockran is saying. Maybe we should in particular work on “breeding” some developers who understand both areas very well and can work both with programmers to solve difficult problems, as well as with interaction designers to get further insights. You don’t have to be infallibly competent in both areas, as long as you understand the concepts and can work well with others to benefit from their competence.

    Sometimes I get the impression that people get too quickly placed into corners. E.g. “you are a programmer, so you must suck at UI design” or “you are an interaction designer, so you must be a lousy programmer”. It’s not always like that, and I think we should encourage branching out more strongly. Then “pure” interaction designers might also feel more at home, when they find people who listen to their ideas and more importantly work on getting them implemented.

  • http://www.ndeschildre.net Nicolas Deschildre

    Indeed, such usability reports are great!

    But I have to concur with comment 3, things that looks simple to fix from a user point of view can be quite long to refactor. And time used to refactor to add small usability improvements is time lost to add some new shiny buzzy new features that everyone is waiting for. And believe me, refactoring is no fun :(

    Ideally, interface should be designed and reviewed by potential users at the very beginning, before any code being written. I’m not aware of projects having taken such a measure, but that could be an interesting experiment. Like having a website where Glade mockups could be submitted, and modification could be hierarchically submitted and voted… Right, that’s not enough, but that would be a start.

  • anonymous

    I too have to agree with the chorus above.

    The points below are to be taken on very broad terms.

    It was not too many years ago when I noticed this new trend in the general open source community. Suddently we all ought to have UI designers, web designers, PR people, and so forth.

    This was all great. This was all excellent, I thought, until I realized that our small core team was suddently “responsible” (!) of implementing these features, some of which we even disagreed with. Now even if we disagreed, there was still the implicit assumption that we were the people who would devote our time for implementing propositions of people who did not show a single line of code. This is what I call “Ubuntuism”.

    Now these projects were nothing like Gnome, but still big enough to highlight the problem when you start to introduce “designers” and “managers” for the open source community.

    Call me old-fashioned, but for me it is still the code that provides you an ability to suggest something.

    It is still a meritocracy.

  • http://thorwil.wordpress.com/ Thorsten Wilms

    Depending on the scope, interface and interaction design proposals/issues can either be filed in the bug tracker of the project in question, be discussed on the wiki or be offered as wrapped-up report on the mailing lists. All the tools and channels are basically there.

    But nothing can replace direct contact to the developers. You will often have to build up a level of trust to tackle some deeper and non-obvious issues. In working towards a solution, you need as high-bandwidth as possible communication.

  • jono

    Thanks for all the great feedback folks.

    So we have determined some fairly key points here:

    • It could be useful to modify existing bug trackers to better cater for design orientated bugs. Are there other modifications that would make a bug track more suitable? Also, how do we ensure these design bugs are not ignored and never marked with the same level of severity as code bugs?
    • Some still believe that code is the entry way to getting things done. I agree this is very much the case, and this is what I am keen to break down. Do we have suggestions of ways in which we can break down the requirements to being able to code?
  • appelflap

    How is this done within Canonical? I assume there are designers and UI experts involved with creating Launchpad for example. Maybe that way of locally organizing design and development can be ‘ported’ to the global open source community?

    I’d also be interested in an online place where designers (preferably experts) can showcase their ideas, and interested coders can join them to discuss and implement them. It seems a bit hard right now to get your ideas known if you don’t know the right people or work for the right company. It could be something like Google/Mozilla Labs. (Ubuntu Labs?) Let’s hope Launchpad will become such a place.

    Also consider the Mozilla Labs Concept Series: http://labs.mozilla.com/projects/concept-series/

  • http://www.ndeschildre.net Nicolas Deschildre

    So far, the only tools I am aware of that would allow a non-developer to design an UI while being exploitable by a developer are Qt Designer (Qt/KDE) and Glade (GTK). Qt Designer is more interesting as a design tool since it does have a preview feature and it offers basic workflow support (e.g. click button => close window), unlike Glade.

  • http://paul.kishimoto.name Paul Kishimoto

    Me again—I see my original comments were somewhat off-topic, though I still think more usability testing is important.

    Re #18, part 2, what is really needed is a “Sketchup for GUIs”. I don’t think Glade can serve as such without the ability to do all rearranging and resizing via the mouse. Perhaps some AJAX-Y web interface that pretends it’s doing GTK layouts and lets the user drag things around?

  • Don AKA seeker5528

    As a user some of this Gnome 3.0 talk has gotten a bit scary. To my way of thinking, what has made the Gnome community strong is the commitment to backward compatibility and regular predictable release schedules and within that found ways to enhance usability and add new features without causing too much breakage and without things being drastically different.

    Over time it has become clear that there can be such a thing as too much commitment to backward compatibility and obsolete stuff should be removed. Since the Gnome developers have show that they can release stuff on a regular predictable schedule and still adapt to new capabilities, enhance usability, get cool new feature in, in a controlled and evolutionary way, the focus of major new releases should not be about the new stuff, they should be about cleaning house, getting the obsolete stuff out.

    If the existing panel/applet/notification stuff is broken figure out how to enhance them/fix them. Maybe this requires writing replacements from scratch, maybe not. The KDE developers decided a re-write was necessary and have some exiting new possibilities because of it but at the same time you still have a panel with a menu, task area, and notification area. The trick is to look at the existing stuff and make it better, I’m not opposed to this single panel with optional sidebar idea, but I don’t really see a panel and a sidebar being different than having 2 panels.

    Also one of the links indicated that ideas and/or statistics from the Windows 7 blog were considered, but what about other exiting ideas.

    Windowmake for example.

    Fire up an application and you get an icon in the task area. Drag that icon from the task area to the dock, you have a persistent launcher, no muss, no fuss, when you launch the application from the dock, you don’t get a new icon in the task area because the icon on the dock shows whether the application is running or not and gives you access to all of the management functions you would expect from the icon in the task area. The drawback being the implementation was never updated to handle multiple instances of an application, and they also don’t handle notification so you still need a seperate are to indicate a notification event happened and to display it.

    Fluxbox:

    Middle button mouse drag one application window title over another. now you have a single tabbed window with 2 seperate applications that can be minimized, maximized, moved to another desktop, etc…

    OS/2:

    Had the idea of rings. It’s been a while so my memory is pretty vague on what they did or didn’t provide, but for the purpose here think of this….

    For any given task you may have multiple applications open at the same time to perform various functions within the framework of the overall task. So you add these applications to a ring, the ring gives you a single icon to launch all the related apps, a single icon in the task area where you can switch between the apps in the ring and close all the apps that are part of the ring and this could extend to a single notification identity as well so you identify the notification first with the ring, then the individual application within the ring.

    Of course I am not a developer so I can only toss words out there in the hope that, just maybe, they will make it to the right people at the right time to be taken into consideration.

    Later, Seeker

  • http://thorwil.wordpress.com/ Thorsten Wilms

    Regarding breaking down the requirements for coding, it would help to have clear engine/GUI separation to then use a Flash-like tool for design an implementation of the GUI.

    Glade is bearable at best. You can’t actually design with it, because you need to know what goes where in advance to build the proper table structure. Also it is just braindead that you have to take care about the spacing between widgets manually, every time. True not just for Glade, but GTK+ generally. Spacing belongs within themes!

    Now the Flash-like tool I have in mind would offer a set of standard widgets that you could arrange on canvas by defining relations between anchor points. It would also allow to customise the widgets with vector and bitmap graphics. Or to build ones from scratch.

    Said widgets could then be hooked up with the functions provided by the application engine. With scripting (ActionScript in Flash, Python would be cool) as glue and for controlling the GUI side.

    It would also support animations. Even producing concept animations is pretty hard currently, using only FLOSS tools.

    Ideally, the same tool could be used for GUIs, graphical work and website content. It could fit very nicely with the current plans of blurring the lines between desktop and web applications.

  • http://weblog.obso1337.org seele

    You should focus more on managing design processes and not trying to manage design. I need help getting ideas discussed, mockups approved, and finding someone to code the damn thing. I don’t need help creating wireframes or ui mockups. Design tools aren’t the problem, communication tools and hacker culture are. Developers seem to think talking without coding isn’t productive, while in the design world, understanding the problem is 80% of the solution.

  • http://www.jonobacon.org/?p=1430 The Flow Of Ideas | jonobacon@home

    [...] thinking a lot recently about the flow of ideas in and around Open Source projects. A few days ago I asked for feedback about how we can better structure interaction ideas. The blog entry gathered some great feedback: [...]

  • http://mpt.net.nz/ mpt

    Alex: It was a user test, not a survey. The difference is important!

    Jono: I don’t think there’s a technical way to solve the prioritization problem. A learnability flaw that prevents 80% of people from successfully using a feature is exactly as important as a crasher bug that prevents 80% of people from successfully using the same feature. But making those kind of judgements is really difficult for developers who understand their own software intimately.

    If user tests were done more widely and the results publicized more widely, I think developers in general would get a better feel for how bad a particular usability problem is likely to be, which would help them prioritize.

    appelflap: Canonical’s Design team is very new, but we’ll be talking about interaction design in general at UDS next month.

  • http://bloc.eurion.net/archives/2008/installing-gnome-shell-in-ubuntu-intrepid/ Bloc d’en RainCT » Blog Archive » Installing GNOME Shell in Ubuntu Intrepid

    [...] read in Jono’s blog that the development of GNOME Shell (which in turn may become a component of [...]

  • john

    Yea, I’d be interested in seeing a more central idea repo. Something like http://www.aquataskforce.com/ might be interesting too.

    I’m not a gnome developer, but recently had an maybe a decent idea, and didn’t really know how to best share it. This and other posts made me throw together a slide deck and borrow a friends blog (having no where else) to post it.

    http://dvhart.com/content/blog/dvhart/linux/filemanagementideafromjohn_stultz