Hi Christoph, On Sun, Jun 10, 2012 at 2:38 PM, Christoph Noack <christ...@dogmatux.com>wrote:
> Hi Björn, hi Mirek! > > I had to make up my mind concerning this thread and also the article > that was originally referred to. So here is what I'm thinking about ... > > Am Mittwoch, den 06.06.2012, 20:45 +0200 schrieb Björn Balazs: > > Am Mittwoch, 6. Juni 2012, 19:46:09 schrieb Mirek M.: > [...] > > "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? > > I understand it the same way - and I found another thing a bit strange. > The article is called "Quantifying Usability" although it deals with > "heuristic evaluations". The aim of those evaluations is usually to > detect interaction design issues - but not to let users rate / quantify > those issues (having statistically relevant information). So, where is > the "quantification"? > > In the given case, interaction experts (not users) do tag the issues > using their level of experience and (domain) knowledge. So finally, you > can generate a nice statistic of known issues within your system - maybe > that also helps within the project to address the most important (here: > highest number) of issues in advance. > > But that doesn't solve the issue what it really means if a dialog > violates e.g. "ux-minimalism" - you need to know the users > characteristics and their tasks. So for a complex product like > LibreOffice (assuming that its okay that it supports a variety of > tasks), some users may find a dialog overwhelming whilst other users may > miss lots of information. The question is - which main target group will > make use of this dialog ... > The minimalism principle states that "interfaces should be as simple as possible", where "simple" is meant as not complicated, not as "as featureless as possible". As an example, compare Firefox's separate search box and address bar and Chrome's omnibox. In Firefox, you can search using both the address bar and the omnibox, which is unnecessary redundancy. In this case, Chrome is more minimalistic, yet it doesn't skimp on any features found within Firefox. > > So yes, these characteristics might guide us - but you cannot apply > these to serve as strict rules. I take a scientific approach to this issue. Just like with any branch of science, it must be possible to define clear, logical principles for UI design, and it's certainly worth the effort to try. Yes, different users have different needs, but with good principles, that can be taken into account as well. We also need to separate "needs" from "wishes"/"preferences" -- a feature is needed in a piece of software when its lack would significantly impair the usability of the software. The usability of the software should be measured according to its primary purpose. For example, giving the user the option to choose Writer's Splash screen is a preference, since the lack of this option would not impair the user's ability to create documents, which is Writer's primary purpose. Wishes are best handled by extensions. You may see this in other places as > well, e.g.: > a) Ten Usability Heuristics > http://www.useit.com/papers/heuristic/heuristic_list.html > > b) ISO 9241-110 Dialogue Principles > http://en.wikipedia.org/wiki/ISO_9241#ISO_9241-110 > > By the way, the linked descriptions fit a bit better from my > point-of-view. > These are more vague than Mozilla's (especially the latter), and therefore more subjective and less useful. Mozilla's principles are based on the former. > > > > 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? > > I'm keeping the text above, since it fits quite well to my answer ... > > [...] > > But since we talked about principles - there are some other open > questions. Answering these questions might (at the very moment) help a > lot to provide a consistent experience to our users. > > Some examples: > * Given equal tasks - do we aim for consistency within the > different LibreOffice applications, or do we want to optimize it > for each application (affects: suitability for learning and self > descriptiveness VS. suitability for the task) > Example: drawing behavior > I don't quite understand this example. Doesn't drawing behavior concern the same task, have the same purpose, no matter what LibreOffice module the user is in? I can't think of a specific situation in which having a UI suited to the task would neccessarily be at odds with suitability for learning and self descriptiveness. > * Given the fact of different platforms - do we want to have > consistency across the platforms or do we want to comply to the > platform (e.g. Human Interaction Guidelines). The former makes > LibreOffice very predictable, although it might not fit to the > platform. The latter heavily affects "suitability for learning" > and - of course - design and development effort. > Example: When (re-)designing, do we address: Linux (most > developers), or Windows (major user base when looking at > OOo/AOO/LibO), or Android (emerging market), or ... > This isn't a simple question of following the HIG, given that HIGs for some desktop environments are less than ideal (and sometimes a bit outdated), which is evidenced by Microsoft and increasingly even Apple not following its own guidelines. This is something we need to address with our own HIG. > > * Given the fact of major competitors - do we want to adapt the > LibreOffice behavior with regard to competitors? Today, many > users / organizations want to switch to a free (costless) > alternative without having (much) learning effort. > Example: Some of Calc's good and consistent behavior is > currently changed to conform to Excel's behavior (e.g. > copy-and-paste behavior). That makes new users happy, but is > problematic for today's users. > > It's preferential to design for the best usability. If there are two options that we determine are the most usable, both conform equally perfectly to our principles and are equally logical, then it is preferential to have consistent behavior with the competitor. Otherwise, no, we shouldn't impair usability because a competitor impairs usability. If we choose the more usable option, it is likely that the competitor will copy us. Just look at how all the browsers have aped Chrome since it came out. * ... > > To me, these are the more urgent issues - although none of the questions > can answered "black or white". But answering those (and some answers > might need real user or marketing involvement) would shape the > (currently unnecessary huge) design space... > > By the way, some similar questions documented here: > > http://wiki.documentfoundation.org/Design/Kick-Off/WhatWeNeed#Knowledge_and_Requirements > > > What do you think - where to start? > I'd still like to start with design principles, work from there. :) -- 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
