Hi Christoph, On Sun, Jun 10, 2012 at 11:34 PM, Christoph Noack <[email protected]>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 <[email protected] > >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#Advanced_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. -- 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
