Hi Björn, On Wed, Jun 6, 2012 at 8:45 PM, Björn Balazs <b...@lazs.de> wrote:
> 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 the contrary. These are simple principles that should guide all designs, whether they come from developers or designers, and would be the basis under which all designs would be judged. (Much like basic arithmetic is applicable for both first-graders and adult mathematicians.) On top of these principles, though, we'd have a HIG for specific situations, such as desktop integration (e.g. requiring a "Close" button on dialogs, as Gnome 3 and Mac OS feature modal dialogs without title bars). > > > 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) > Easy. The "Save" icon should be active if there is anything to save and inactive if there is nothing to save. As we have determined that it is useful to be able to save view settings, the "Save" icon should become active even if only the view settings change. (I don't think it makes sense to disable the icon if we think saving view settings is genuinely useful.) And, in that respect, the Save icon would indicate saved status, as it is meant to. If we also want to indicate whether the document's contents were edited (above the dialog that asks the user whether he'd like to save the edits he made to the document, which doesn't apply to view options), we could have a special "Save view edits" icon for when only view options were edited and contents were left intact. (I'll post this to that thread now.) > > 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. > I agree that the wording of this one is confusing. As I understand it, the UI shouldn't be based on the underlying code in a way that's illogical to the user. You can see the relevant bugs at https://mevootserv.appspot.com/bugzilla.mozilla.org/buglist.cgi?keywords=ux-implementation-level For example, if you take https://mevootserv.appspot.com/bugzilla.mozilla.org/show_bug.cgi?id=615306, the behavior of the back button is based on some code that tells the browser to go back to the previous site, which isn't always friendly to the user, as it doesn't take into account redirects which take the user right back to the site he was at -- something the user didn't want if he clicked the back button. > > 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. It, of course, doesn't apply to UIs meant exclusively for experts that are familiar with this jargon (so it is OK to have medical jargon in an extension meant exclusively for doctors). As I understood it, the main purpose of the principles was to avoid showing pieces of the software's code in the interface (such as with those stereotypical unhelpful error messages), though the interpretation has been clearly extended to use of language in general ( https://mevootserv.appspot.com/bugzilla.mozilla.org/buglist.cgi?keywords=ux-jargon ). 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. What would this research look like? To be honest, when it comes to generic language, I believe that if a user cares enough to report a bug about it, then it should probably be fixed. Perhaps we should have a more user-friendly front-end for submitting terminology bugs? (bugzilla may be too complex for the general population) > > 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? > I agree that this principle needs some tweaking. My interpretation: the software should not make decisions for the user unless it is obvious that the user wants the software to make that decision. For example, LibreOffice should not automatically set itself as the default office suite -- it should ask the user first. On the other hand, it should go with memory defaults, as the user is unlikely to want to set those first. > > 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". > We should define "minimalism" as reducing complexity. Using animations or adding color to a UI can reduce its complexity. "No shadows" and "no gradients" sounds good to me -- it works quite well for Microsoft's Metro UI and, to a lesser extent, Android's Holo. In these matters, though, the platform's HIG takes precedence. (That doesn't go against the principle -- the most simple representation of a button is the one used by the platform; otherwise it's not immediately apparent that it is a button and takes longer for the user to interpret, thereby adding to the UI's complexity.) Yes, the interpretation of this principle can be a bit subjective, but it's not as dire as it sounds. By simply presenting reasons for why a UI element is necessary/unnecessary, you can easily reach a logical conclusion. > > => 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? > I beg to differ -- I believe most of our subjectivity issues can be solved by simple logic. We'll adjust our principles as we find issues. > > 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. > This is something that we need to address with the principles. An equal weight has to be given to all of them and they shouldn't go against each other. > > 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. I'll quote Einstein here: "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." > Will > take on the ball about user research (and the rest of your mail) next days. > Great! I'm looking forward to it. -- 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