Il giorno sab, 20/08/2011 alle 12.04 +0100, Allan Day ha scritto: > Hey Giovanni, > > I'm being selective in my responses here... > > Giovanni Campagna <scampa giovanni gmail com> wrote: > > I'm sorry I couldn't read through the whole GNOME Survey v4 thread, but > > it was just too long. What I read though is that data was collected and > > extists. > > Now I'd like to simply ask: where is it? > > Where we developers can find real cold numbers backing out the designs > > we're asked to implement? > > I wrote that we already have lots of data on peoples' experiences with > GNOME 3. Is that what you mean? There's a brief summary of that in the > final paragraph of my previous email to the list [1]. > > I never found the time to do a proper write up of the user testing I > did on the shell. It was brief and ad hoc; I can tell you that the > five participants in my study were all able to complete the tasks that > were set for them though, which included basic things like launching > applications, switching windows, changing the desktop background, > responding to notifications and changing the volume via the system > settings area. They obviously found some things trickier than others, > but they could do everything I asked them to do. This is the first time I see the amount of users tested, and the exact tasks involved. I think it should go somewhere in the wiki, especially alongside the exact results (what was trickier? why?) Thanks anyway! > > Where we developers can find hard facts proving the NOTABUG and the > > WONTFIX we mark in the most questioned and hot issues? > > You can always mark a bug with the ui-review keyword if you want a > second opinion. You misunderstood me. I didn't say that I don't know when to close, I said I don't know how to explain to the users why I'm closing. You need facts to prove your points, or people won't understand and refuse to agree. > > I'm not a designer, so I may not understand all the papers you provide > > in your support, and I may not understand what are the rules and laws of > > Human Computer Interaction, as you call it. But I understand numbers, > > and would be convinced by seeing that 66% percent of people find this > > method of working more productive, or 3 out 5 tested users where able to > > discover the functionality without guidance, or all 8 people interviewed > > did not use the feature just removed. > ... > > More user testing would be a good thing, and that might provide some > of the numbers that you crave. In the mean time, we're not operating > in the dark however: we can tell a lot from a combination of the UX > literature, dog fooding, feed back from users and comparison with what > other OSs/DEs/whatever are doing. It's not numerical data but it is > data all the same. Usual example: the shutdown button. There is no UX literature proving that "suspend is the right way to shutdown a system". Other systems (Windows, Mac OS, KDE) are keeping power off as the primary method. Feed back from users is far from enthusiastic. So... is there anything that proves your points? (The nice feature of numerical data is that it's unquestionable. Anything else can be disagreed, which leads to discussion and hundred comments long bug reports) > > I know that what I write, following the guidelines and the mockups, is > > right. But people providing feedback don't always agree with that, and > > if myself cannot understand the reason, how can I explain to them? > ... > > The basic features of the shell design are explained on the wiki [2]. > It's helpful to have a more thorough explanation for more > controversial design decisions though, such as the ones that Owen [3] > and me [4] provided for window buttons. Just ask if you want more > information on a particular issue. The design, as explained in the wiki, is a set of assertions. I am sure that UX literature contains the explanation for why those assertions are right, but as they stand, we can place a [citation needed] tag on them. Plus there is nothing there explaining why current implementation is the best way to achieve those design goals. As an example, it is said that the user wants to focus one specific task at time, and thus the taskbar was removed and all task switching moved to the overview. I can concede that the premise is correct, but it is hardly self evident that the overview helps with this, given that a task often involves more than one window and more than one workspace (which forces the user to alt-tab to avoid the "overview distraction"). The explanation Owen gave on the minimize/maximize issue on the other hand was complete, provided real world examples and showed the problems of the previous design. For comparison, at the desktop summit I listened to a talk by the same person on the shutdown stuff, and I was not convinced at all, because I did not get the "why" of the basic premise on which it was all set. > > I understand that some features in 3.0 were like "design experiments", > > because we have the whole 3.* cycle to improve. But if the results of > > those experiments (that is, people's feedback) is not analyzed > > thoroughly, how can we be sure that the design is right? > > Feedback does get read and gets weighed up against the other evidence > that is available. I think it would be great if we had a more visible > process there, however. I thought that the responses to the top ideas > on Ubuntu brainstorm were a good example of how this can be done, > actually [5]. Doing that kind of thing requires time and effort, of > course... I see. Well, we could ask the feedback reporters to do the work. After all, it is in their interest to have the developers focused on the problems. Or we could have voting in bugzilla. I know many people are against to this, but it would immediately show the hottest issue, that surely require reconsideration by the design team. Plus it would avoid +1 comments that spam our mailboxes. Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part