GNOME.org
 

Re: [Usability] Usability meeting minutes

Some great thoughts Calum.  Just a few supporting ideas and thoughts below.


Calum Benson wrote:
The main reason, though, was that they were beginning to perpetuate the misconception that usability is something you just do at the end of a cycle to add some lipstick to the pig. We vowed to engage developers at the beginning of the development cycle instead, and work with them (and users) to help validate their plans and assist them with designs. That was about the same time that the number of active usability practitioners in the community started dropping off, though, so it never really happened.
I wasn't around for this part of history (I think) so I can't comment, but the recent furor over the GNOME user experience hackfest in recent weeks seems to be a great opportunity to get usability practitioners in early, if they're not already involved. There seems to be some serious thought going into interaction design but I haven't heard a whisper of it on this mailing list. So either I'm hanging out in the wrong forums or there's a disconnect here. And that disconnect is still an opportunity, I think.
One alternative that we haven't tried yet might be to have 'usability days' throughout the dev cycle, much as some of the larger desktop apps have their own bug days. A day where hackers and usability folks meet on #usability, and pick off bugzilla bugs that have been tagged with the usability keyword. They needn't be fixed there and then (I'd expect most of the ones that could be fixed on the spot to be of the less-useful pig and lipstick variety again, although of course they do need fixing too). Just so long as somebody agrees to work on them, and a usability person agrees to help them out.
That's a neat idea, and I'd participate. Another suggestion would be to perhaps get a better sense of who's on this mailing list and what our strengths are. I've never once been asked to prove that I can even spell usability, let alone understand it. I'm not suggesting we need an entrance quiz or some admin person who checks credentials. Rather I'm suggesting that each person on the list has their own reasons for being here: education, participation, lurking, evangelizing, whatever. If we're going to start working together more cohesively or more regularly, I think knowing who we all are would be a good thing. Maybe this is as easy as everyone updating a wiki somewhere with their bio and interests?
So immediately, we're looking at a potential pool of people who are most likely employed to work on the usability of something other than GNOME during the day, and who don't have much motivation to work on the usability of anything else in their spare time.
For those who do make the leap, as they're not usually contributing code or patches, there aren't so many things they can jump in and do straight away, nor is it as easy to prove that they're good at what they do. They can file usability issues in bugzilla, but unless they're a recognised 'name', they're somewhat less likely to be taken seriously without some backup from the other usability folks.
My suggestion of providing info on all of us may help with the "name" issue. If people come to this list for help and appreciate the info they receive, would they not appreciate the info just as much from a non-famous name who is listed as a participant on the list's wiki? We all have to start off anonymous.
Now and again people do introduce themselves on the list as studying usability or some such, and many just disappear again without trace because we didn't usefully engage them. We need to stop that happening.
This speaks again to a stronger community on the mailing list, which I wholeheartedly think would help.
We've threatened for many years to develop some personas[1] for use when developing new features. Perhaps now is the time to seriously address that. However, it's generally accepted that personas are only useful tools if they're based on actual user research and interviews, so sitting around and making them up ourselves wouldn't cut it.
Agreed that personas would be a great idea. I'm not so sure about the making it up though. I believe that you can do some quick and dirty personas if you have the right people with the right knowledge. Do we have the right knowledge? Maybe not. But the exercise of creating the personas would raise some very pivotal questions about GNOME's vision and direction. That discussion would bring in the right people. We could also very easily do some preliminary people checking. I think personas would be a great way to move GNOME forward. I'm totally interested.
That, I think, is a key point for all our usability-focused work: if we're to progress, we need to get out of the habit of designing things purely as the result of discussions among ourselves. You can't design great products without involving users.
And you can't involve users without knowing who your target users are, at least not very effectively.
In particular, we do have some insight into the type of people who use GNOME by choice-- we all fall into that category, albeit the (small?) subset who have the time/inclination/ability to actively engage with its developers and try to improve it. But there's also a growing audience of people out there who *have* to use GNOME whether they like it or not, on school or work computers, or in internet cafes, public libraries etc. How much do we really know about them? 


Not much - and it's a great place to start the personas discussion! :)
Glade could probably have been rather more helpful in the meantime, too, by shielding designers from any non-optimal gtk+ defaults. I don't know how much time I've wasted over the years left- or right-aligning text labels that always default to centre alignment, or adding the same HIG-compliant row and column spacing to tables and boxes that Glade always adds to my dialogs with a spacing of zero.
Perhaps we should step back and ask if that level of fidelity is always needed for usability feedback. If we wanted to paint a picture then pen and paper are all we need (and a scanner). Do the developers actually value us using glade for interface designs? That's a sincere question. 






Try to change as few central things as possible. Set goals for next few
years. For example, the panel might need some updates. File manager - like Federico's talk about finding documents. Do we want a timeline view? Find on 
text instead of folders? Have some broad discussions.
And ask users. And preferably observe them too, because what users say and what they do are often different :)
If we're looking for specific tasks or objectives, perhaps a central location for current "ideas" or "work" or "tasks" so that people joining know what's going on, can follow up for the latest, and can join things that interest them. Openusability.org was an interesting approach to that, but I've often found that simply saying "Anjuta needs a usability expert" was not quite bite-sized enough for me to take the bait. If I saw something like "Anjuta v3 needs a quick heurisitc analysis of their new project wizard, using heuristics of your choice" then that's much more manageable, as it were.
As an aside, have we thought about putting together a GNOME list of usability heuristics we use in our reviews by default, perhaps in the HIG? 




Usability studies. Having some sponsored would help. Dave Richards had
feedback from users on what's wrong and what works.

Sorry, I didn't see this feedback - is there a link or can it be provided?
There is, of course, little doubt that the HIG needs updating. The first step in that process is probably to decide what developers want the HIG to be:
* A book, like it is now? (If so, should we start selling hard copies via Lulu or something? I'd buy one...)
* Reduced right down to a collection of UI patterns, with accompanying code samples? 

* An online help document with hooks into Glade?

* Something else?
Agreed, a monolithic HIG may not be the most effective or useful way to capture usability guidelines. Stakeholder input is needed here. Updating it is already a daunting tasks, so if we can find ways to break it down somehow, so us evening warriors can help is small chunks, I think we'd get more done.
There is probably a need for a mobile device HIG, too, but that's likely to be a separate document (just as Apple, Microsoft and Sun have found to be necessary with theirs). The requirements for touch/tablet interfaces are just too different from desktop interfaces.
Whatever form of guidelines we provide, once again it would be good if they were more informed by user feedback. A good example of this is the current discussion on this list about tab design; we have many applications implementing different tab functionality, so what should the HIG be recommending? How do we decide what functions should be set in stone by the tab widget, and which are subjective enough to require tweakability via desktop- or application-level preferences? We're deluding ourselves if we think we can second-guess our users without asking them.
Interesting thought your comment inspired - if we're having discussions here is there a better way to capture conclusions, decisions, comments, history? A mailing list is not really the easiest thing to use to find out what people believe is true today. Can we have a location that summarizes our discussions, not necessarily the HIG?
Designers really shouldn't be "coming to try things", except perhaps some very early proof-of-concept designs. They should be driving the design of those "things" in the first place, and working with developers throughout the development cycle to refine those designs. 



Agree wholeheartedly
We need to make it easier for casual and non-technical users to submit their feedback. One idea that's been used elsewhere before now would be to add something like a 'feedback' applet to the panel. Click the smiley face icon to send positive feedback about the running application, or the sad face icon to send negative feedback. ("Feedback" could be anything: something that was easy/hard to do, something that's got quicker/slower since the last time you tried it, some peripheral working/not working). The applet could take a screenshot of the running app (or desktop) as well, if relevant, that could be included in the report with the user's consent. (Of course, we'd have to figure out where to send the feedback and what to do with it... just brainstorming here!)
Interesting idea - worth putting more thoughts into it I think - more brainstorming.
Perhaps we need a Feedback Squad, akin to a Bug Squad, who monitor all those sources (as well as liasing with user groups, and users of GNOME installations in schools/universities/offices etc.) and get it to the right places/people?
The squad needs people though, which as you've mentioned is a challenge. Maybe we should address taht problem first - a usability recruitment drive? Leverage Openusability?
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]