Hi all, thanks for picking up this really important discussion. Christoph I think the examples you gave are really great.
I think we really should ask ourselves: "What is the problem? What do we want to reach?" instead of generally argueing for or against the suggested (and obviously proven) approach from Mozilla. I think there have been two possible goals deriving out of this discussion so far: 1. Educate developers in terms of making them aware of the importance of Usability / UX 2. Provide a structure to us designers to produce consitent UIs and workflows. Am I right with these two possible goals? Would you like to add any? Cheers, Björn Am Montag, 11. Juni 2012, 17:55:34 schrieb Mirek M.: > Hi Christoph, > > On Sun, Jun 10, 2012 at 11:34 PM, Christoph Noack <christ...@dogmatux.com>wrote: > > Hi Mirek, all! > > > > Thanks for your quick response! It's already a bit late, but I'd like to > > answer now - tomorrow, I suppose, my day job will eat up all the given > > time ;-) > > > > Before I start: The more often I read your mail, the more I'm convinced > > that some of the potential misunderstandings are caused by differences > > in terminology (read: same terms mean different things to us) and > > procedure with regard to HMI development. So please allow me to add some > > more "my-point-of-view" ... > > > > Am Sonntag, den 10.06.2012, 19:53 +0200 schrieb Mirek M.: > > > 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". > > > > That sounds great, indeed. But when designing products one is usually > > faced to the problem that it's impossible to add (meaningful) features > > without any increase of the complexity of the product. Although one user > > group want to have these features (because it boosts their efficiency), > > other users might find the resulting user interface "not simple". > > > > So, as Bjoern already pointed out, balancing what's "simple" and what is > > "not featureless" requires a deep understanding of our users' needs. And > > these needs vary a lot ... depending on their knowledge and their tasks. > > > > I've documented a related issue some years ago (Myths about UX): > > > > http://wiki.services.openoffice.org/wiki/User_Experience/Myths_about_UX#Ad > > vanced_functionality_doesn.27t_hurt_-_newcomers_just_won.27t_use_it.21> > > > 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. > > > > It does sound like Chrome is superior to Firefox, right? > > > > But how do we know that the Chrome decision is the right one? Maybe ... > > > > * Maybe the majority of people expects to have a separate search > > > > field - like in other programs, too (Adobe Acrobat). > > User expectations should be covered by ux-affordance > and ux-discovery (relevant visual cues), ux-visual-hierarchy (visual > weight), ux-natural-mapping, and, if it doesn't hurt the usability of the > software, ux-consistency. > > * Or user tests showed that people are unable to discover the > > > search functionality - so they always enter "www.google.com" and > > then start searching. (So ux-minimalism hurts ux-discovery as > > also Mr. Nielson points out in the article you've referred to). > > ux-discovery asks for visual cues, which Chrome includes (the "Search" > spyglass symbol) and Firefox neglects to. > ux-minimalism asks to avoid unnecessary duplication, which Chrome's omnibar > follows and Firefox's address bar doesn't (as it has two UI elements that > can be used for searching the web, presented next to each other). > ux-minimalism doesn't hurt ux-discovery -- on the contrary, they work hand > in hand. > > > * Maybe the Firefox decision is an intermediate solution until > > > > they could "convert" all users to use only the Awesome Bar for > > all web related tasks. > > Wouldn't the best tactic for converting users to use only this bar for > searching be presenting this bar as the one and only place for searching? > > > > I can provide further guesses, but the basic message is - defining > > > whether the goal of "ux-minimalism" is achieved needs to consider real > > user needs. > > Yes, we should always consider user needs and test our designs. > However, the principle that UIs should not be duplicative still stands: if > there are several GUIs for accomplishing the same task, we should always > ask ourselves if we can't boil it down to one. > > > Chrome has a huge advantage here - these guys aren't market leaders, so > > doing experiments with regard to HMI design and features is much easier > > to them (I suppose a majority of users are "early adopters"). > > According to Statcounter, Chrome is the most popular browser in the world. > IE has also not been afraid to radically change its UI. > > > > > 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. > > > > Concerning the last statement - yes, but who defines the primary > > purpose? What is a document? Should Writer offer the user to add basic > > shapes, or should they insert them via Draw? Should Writer offer simple > > calculations in tables - or should these be copied from Calc? These > > features could be removed without affecting the primary purpose. But > > this wouldn't be tolerated by a large part of the user base - so their > > input tells us what they need. The statements in the original UX article > > don't help here. > > You could argue that Writer doesn't need to allow the user to type. The > user could simply type the content in a text editor and then just paste it > to the document. > If we say that the primary purpose of Writer is to create (all kinds of) > documents, then Writer should be able to handle all of the tasks associated > with it, including text entry, shape drawing, and table manipulation. > Removing shape drawing would certainly hurt the user's ability of creating > the document he wants to create. Removing the option to set the icon pack, > on the other hand, wouldn't (as long as we support an additional HC pack, > which some users really do need). The user would be able to create the > document he wants no matter what icon pack he used (as long as the pack > used symbolism that corresponded to the function, of course). > > > Looking at the full section, it seems that two things are combined that > > should (in my point-of-view) be considered separately to make > > discussions a bit easier. A most simple take ... > > > > * in the first step, the functionality of the software is defined > > * in the next step, these features are brought to live via the > > > > user interface > > > > So it is about "what" (the theoretical usefulness) and "how" (usability, > > the ease-of-use). > > > > As far as I understand, the article you've mentioned rather refers to > > the "how". Drastically said it does not mention whether a piece of > > functionality makes sense. This is the "what" - you seem to refer to by > > mentioning "features". > > Yes. > > > So, could you give me a hint, what you want to get covered? > > I'll try my best at formulating my answer, but I may amend it later on if I > think of something more fitting. > What do I want covered in Writer? > Well, everything needed for editing a document (i.e. a "DOC", "ODT", > "DOCX", or "PDF" file, containing text, tables, shapes, images, and/or > other objects, with this content separated into 2D pages with a finite > width and height) -- that means editing tools for all the supported > objects, features that allow all populations to use the software (language > support, accessibility options, various input types), grammar checking (the > quality of the document would be worse off without it), navigation/search, > import/export of as many document filetypes as possible, and the simplest > visual representation of these within the interface. > Then there are features that may significantly speed up document > creation/editing for specific purposes, such as templates and wizards. > Given that there is an infinite amount of situations these could be > tailored to, it makes no sense to bundle as many as possible, and therefore > the software should integrate with an online repository of these as well. > Templates/wizards that are useful in a variety of situations may get > bundled by default as long as there is net benefit and and it does not have > a significant toll on the software's usability. > > Almost forgot about privacy features: a piece of software should always > allow for the greatest security/privacy of the user, and, if a feature > requires private information, the user needs to be given an express choice > of whether to allow or disable the feature (that's part of "ux-control"). > > > > Wishes are best handled by extensions. > > > > Yes - with one exception. Wishes are sometimes immensely important for > > providing unique selling points (although selling sounds strange for > > FLOSS software, its about given people a reason to choose your > > product). > > If a feature is presented as an extension rather than a core part of the > product, it is still a selling point. > I also can't think of a major selling point for a document editor that > would be a "wish" rather than a need. > > > For example: One of the killer features (still) is the "One click PDF > > export". Thats just a combination of other features and not part of the > > "main purpose" - but something that helped to spread news about > > OOo/LibO. > > PDF export is part of the main purpose, PDF being one of the most popular > document formats in the world. > > > The issue: One rarely knows in advance what's considered a killer > > feature ;-) > > > > [... snip ...] > > > > > > 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? > > > > Being able to do drawings is the "what" - the realization affecting its > > behavior the "how". Writer handles drawing shapes differently from Draw. > > And Draw starts to become different to Impress. Why? Because the main > > task of Impress is creating presentations (usually based on existing > > material) - it may contain "drawing elements". Draw is primarily used > > for doing the drawings. > > > > > > So its basically the same task, but sometimes less frequently done than > > other features are used. This is reflected in the "how". > > > > Again, I don't see how this effects the behavior of a feature. An ellipse > > drawing tool should work the same way in all applications, in a way that > makes drawing the ellipse most simple, no matter how frequently the tool is > used. > Could you give me a specific example of how the drawing behavior of Draw > and Writer differ, and how it is more beneficial than if the behavior was > the same? > > > 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. > > > > Simple example? Compare the comment visualization in Writer, Calc and > > > > Impress: > > * Writer = comment anchors and boxes > > * Calc = small red dots in the upper right of each cell, notes > > > > boxes hidden > > > > * Impress = small rectangle with the author's abbreviation, notes > > > > boxes hidden > > > > Although all solutions do have their downsides, the basic design shows > > the impact by the application's main purpose. Example Calc: Few space in > > the cell, so the note content cannot be shown directly. Its also > > impossible to show the notes on one side (like in Writer), because > > showing the referenced cell (given the huge cell matrix) is not easily > > done. Its also unwanted to show the notes next to the cell, since you'll > > hide other cells. > > > > The same "what", three different "hows". > > Ok, thanks for the example. > In such cases, we should, of course, use logic to deduce the most > reasonable option. > I can't escape the feeling, though, that the comment behavior could be more > unified, but that's a whole other topic. > > > > > * 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. > > > > Although I also think that some HIGs are strange (Microsoft for example > > recently mixed all Office and Windows Desktop stuff into one), but > > sometimes you have to "mis-interpret" your own HIGs to get the best > > compromise (= the best solution). An own HIG won't change that. > > > > I disagree. You should never have to "misinterpret" your own HIG. If you > > have to resort to that, then you have a badly-written HIG and you should > rewrite it. > > > > > * 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. > > > > Here is the paradox - do it all the own way, and you might loose a lot > > of potential users before they start using the software at all. Although > > usability might be better, but lots of stuff is different - and things > > people like least are different things. > > On the contrary. > The most exciting software tends to be different from the rest of the pack, > and the key to this differentiation is increased usability. Apple's iPhone > revolutionized the smartphone market by making smartphones much more usable > -- Windows Phone smartphones were on the market for ages, but they suffered > from a poor UI. The same with the iPad -- tablet PCs existed for a long > time before it came, yet they weren't as suited to the input mechanism. > When Chrome launched, it differentiated itself from other browsers mainly > by its increased usability, and it quickly became one of the most popular > browsers in the world while its competitors scrambled to copy the > improvements. > The least exciting software just copies its competitors with all their > faults and fails to innovate on its own. > > > So maybe the option (which is just another proposal having pro's and > > con's) is to primarily decide for "best usability" for our own users, > > but provide adaptations for a smooth transition of other users / > > organizations / governments. For example, providing a shortcut switcher > > to mimic MS Office, ... > > Using keyboard shortcuts common in other software makes sense. Having our > own set of shortcuts wouldn't have any usability advantages for any user > base and would decrease usability for users coming from other software. > That doesn't conflict with putting usability first. > > Software that puts "smooth transitioning" above usability tends to be stuck > behind the competitor -- it adopts all of the competitor's usability faults > and has some faults and deficiencies of its own, which are that much > clearer when the product can so easily be compared to the competitor. > > > But whatever we do - it needs to be a sane / transparent decision that > > takes our whole (growing) user base into account. > > Of course. > > > Phew, lots of thoughts ... but I hope it helped a bit to understand my > > position. I hope that we can continue discussing the feasibility of the > > (quoting you) "clear, logical principles for UI" we're aiming for. > > Yes, I hope so. It should say "clear, logical principles for UI design", > though. > > Understand that in no way am I saying that what we have is perfect -- there > is some vagueness and unclarity in the principles at > https://wiki.documentfoundation.org/Design/Ethos , but I feel like it would > be silly to throw out the baby with the bath water, reject the notion that > UI design could ever be logically formulated if what we have now isn't > perfect. No area of science is perfect, but we're continually striving to > boil down our knowledge into the most basic logical principles we can. -- 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
