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 ... So yes, these characteristics might guide us - but you cannot apply these to serve as strict rules. 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. > > On Wed, Jun 6, 2012 at 6:50 PM, Björn Balazs <[email protected]> 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 * 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 ... * 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. * ... 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? Cheers, Christoph -- Unsubscribe instructions: E-mail to [email protected] 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
