Hi Mirek, Am Mittwoch, 6. Juni 2012, 19:46:09 schrieb Mirek M.: > Hi Björn, > The principles I put on the whiteboard was just me spitballing. The initial > idea was that the community would suggest design principles and we'd refine > them until we got something well-defined and something that we could all > agree on. > The new proposal is to take Mozilla's design principles as our basic > guidelines, as those have worked well for them, and work off of those. As I > believe that is a better approach, I'll simply address your concerns with > that.
Ok, I understand that now. It usually is a good idea to build upon proven things. We will use those to demonstrate the problems. Just as a forword - despite of what I write now, it might be ok to use these principles - it simply depends on the goal we have. Let me quote from the article: "Developers encountering these keywords likely won't have any additional interface design training, so it is important that each heuristic is very clearly defined with specific examples and detailed explanations. Additionally, allowing developers to view all of the bugs in the software marked as the same type of issue, both current and resolved, serves as an effective way for them to further learn about the heuristic." Therefor I understand these principles as guidelines for developers to become aware of UX, perhaps learn a tiny bit. Opposite I do understand something like the design ethos as rules for us - experienced designers and UX professionals. So, I think the sugested rules are good for teaching developers, but I think this is not what we want to do - ?questionmark? > On Wed, Jun 6, 2012 at 6:50 PM, Björn Balazs <b...@lazs.de> wrote: > > I think this is a general problem with general guidelines as they are > > outlined > > in the mentioned article as well. Either they are so abstract that nobody > > would reject them - but then it is also hard to derive any consequence out > > of > > them --- Or they are specific but exceptions are the rule. > > With the ideal design principles, exceptions would never be allowed. > Mozilla's principles may not be perfect, but they're quite good and we > could fix their bugs as we encounter them. > Could you point out specific points that you don't feel good about? No problem: ux-feedback Interfaces should provide feedback about their current status. Users should never wonder what state the system is in. [Source: Nielsen] -> How would you solve the save-icon discussion of the last weeks with this rule? (BTW: the rule is absolutely right, but hard to derive consequences out of it) ux-implementation-level Interfaces should not be organized around the underlying implementation and technology in ways that are illogical, or require the user to have access to additional information that is not found in the interface itself. [Source: Nielsen, Cooper] -> I do not even understand this one. ux-jargon Users should not be required to understand any form of implementation level terminology. (This principle is a special case of ux-implementation- level). [Source: Nielsen] -> This rule is true most of the times, but what about developers as users, if we are developing an application for developers? They might be interested in this kind of terminology. But you could also stretch this rule further: It should actually say, use an appropriate language, because if you use any word (not only implementation level terminology) that users do not understand, they are lost. But what is this level? Answer can only be given by research. ux-control Users should always feel like they are in control of their software. (This principle is often the nemesis of ux-interruption, especially in cases where developers assume users want more control than they actually want). [Source: Nielsen] -> How do you meassure the "feeling"? How about actually having control? Is that needed as well? ux-minimalism Interfaces should be as simple as possible, both visually and interactively. Interfaces should avoid redundancy. (This principle is often the nemesis of ux-discovery since removing or hiding items deep into the interface forces the user to rely more on memory than recognition). [Source: Nielsen] -> So no shadows? No gradients? Nothing that helps to make the app feel natural? I would agree with, do not put in unneeded clutter - but again, what is needed? What is "simple as possible". => If you consider all the "nemesises" mentioned in the rules you can easily see, that you can never apply all rules. So when do you turn to which side? An experience I have made with usability testing, esp. with expert tests and even in more detail with NIelsens heuristic evaluation which these rules are based upon is: If a customer fixes all bugs you found with the first expert testing, you can simply priotorize other heuristics higher the next time you test and he can do it all again. So my experience is: They are too general, it is too optional which rules are prioritized. They might be useful to educate developers, but they are too abstract to lead us experts. Have to go now, but I hope I made my point a bit clearer. I really appreaceate all efforts to make the design of LO consistent and good in terms of UX. But we should be aware of the trap of simplifing complicated things too much. Will take on the ball about user research (and the rest of your mail) next days. Thanks again for your efforts! Björn > > I see a possible solution - and hey, surprise - this again has to do with > > researching and understanding users: I think we should try to define > > conditions user under which certain rules apply. Conditions could be > > something > > like "If the user is likely to be in a stressful situation, prefer to the > > use > > of a wizard" > > > > As I stated before, I'm a bit hesitant about user research -- not because > > I don't believe it can't be useful, but because we have to be careful to do > it correctly, as otherwise it can be quite detrimental to our design. If > done badly, user research can be used to justify just about any design. > > I continue researching user design. Windows seems to do a lot of it [1], > but I'm not sure how much it helps them, given that they're dropping > everything they know for Metro, which firmly stands against the overcrowded > ribbons their research has gained them. Mozilla seems to first design, then > test, much like we do now, but then it has some guidelines that help it > shape its design [2]. elementary does some basic user research (if it can > be called that) on Google+ [3]. Gnome design team doesn't do any, which is > a bit surprising, as, IMHO, that's one of the best open-source design > communities out there. > > I would definitely be interested to hear about your own personal experience > with user research and how it has lead to design decisions (with concrete > examples, if possible). > > Plus every open-source project that cares about design listens to its > users, of course, and the advantage of open development is that people can > see the changes before the product is released, so design bugs can be > caught before release. We've seen this just recently, with two people > reaching out to us, one on G+ and one on the IRC, complaining about the > usability of the new About dialog, which Astron has fixed. > > This is just my experience, perhaps I did misunderstand your intention here. > > What do you think? > > I feel like Mozilla's design principles have worked for them and that they > would be a good starting point for our own principles. > As for user research, I see it as a means to an end. It's definitely > something that will help us refine our principles and form our HIG, but we > should be careful, as user research can be quite misleading. We should > ensure that our principles and our HIG can be followed under all > circumstances -- exceptions should never be the rule. > > [1] http://www.youtube.com/watch?v=532j9sfBcbQ > [2] https://www.youtube.com/watch?v=hMDBwa4huUY&feature=player_embedded > [3] https://plus.google.com/114635553671833442612/posts -- www.OpenUsability.org www.OpenSource-Usability-Labs.com -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted