Re: [libreoffice-design] Design ethos
Hi Björn, Mirek, all! Am Dienstag, den 12.06.2012, 15:34 +0200 schrieb Björn Balazs: 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. Yes, thanks for the reminder ... and thanks for the pre-formulated proposals. 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 From my experience during the last months, this is less needed at the moment. Why? To me ... * the core developers do ping us regularly * they provide means to basically follow their development (e.g. daily builds, commit messages, ... provided for QA, Design and others) * the suggest new developers to get our feedback on their ideas So, unless we are able to handle _all_ their requests quite fast and accurately, there is no need to further promote this topic. Instead, we should try to answer all the (open) requests on e.g. the ux-advise list - or help with classifying / resolving Design related bugzilla issues. I mean ... before asking for more requests we might not be able to handle properly. (Well, I know that I've missed to invest time there as well.) 2. Provide a structure to us designers to produce consitent UIs and workflows. That is the one I'd focus on (referring to the consistent UI) ... and there is plenty to do. Any other opinions? Cheers, Christoph -- 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
Re: [libreoffice-design] Design ethos
Hi everyone, On Wed, Jun 13, 2012 at 11:40 PM, Christoph Noack christ...@dogmatux.comwrote: Hi Björn, Mirek, all! Am Dienstag, den 12.06.2012, 15:34 +0200 schrieb Björn Balazs: 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. Yes, thanks for the reminder ... and thanks for the pre-formulated proposals. 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 From my experience during the last months, this is less needed at the moment. Why? To me ... * the core developers do ping us regularly * they provide means to basically follow their development (e.g. daily builds, commit messages, ... provided for QA, Design and others) * the suggest new developers to get our feedback on their ideas So, unless we are able to handle _all_ their requests quite fast and accurately, there is no need to further promote this topic. Instead, we should try to answer all the (open) requests on e.g. the ux-advise list - or help with classifying / resolving Design related bugzilla issues. I mean ... before asking for more requests we might not be able to handle properly. (Well, I know that I've missed to invest time there as well.) 2. Provide a structure to us designers to produce consitent UIs and workflows. That is the one I'd focus on (referring to the consistent UI) ... and there is plenty to do. Any other opinions? I mostly agree with this. However, the point of the principles is not only to produce consistent UIs and workflows, but also to be able to evaluate and improve upon our designs using a standard set of guidelines. If we discover faults or unnecessary vagueness within the principles, which we no doubt will, we should adjust the principles accordingly. I hope that it's alright if I integrate the principles into our workflow (with a simple Designs will be checked against our design principles. line). -- 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
Re: [libreoffice-design] Design ethos
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.comwrote: 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,
Re: [libreoffice-design] Design ethos
Hi Christoph, On Sun, Jun 10, 2012 at 11:34 PM, Christoph Noack christ...@dogmatux.comwrote: 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#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
Re: [libreoffice-design] Design ethos
Hi all, just a quick note: the log for yesterday's meeting is now up https://wiki.documentfoundation.org/Design/Meetings/2012-06-10 we quickly touched upon the issues discussed here (see the parts from 18:59–19:05 and 19:58–pretty much the end). Also, I'm happy to announce that we might have hit another record length for our chats... Astron. -- 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
Re: [libreoffice-design] Design ethos
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 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 * 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
Re: [libreoffice-design] Design ethos
Hi Christoph, On Sun, Jun 10, 2012 at 2:38 PM, Christoph Noack christ...@dogmatux.comwrote: 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
Re: [libreoffice-design] Design ethos
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.comwrote: 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). * 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). * 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. I can provide further guesses, but the basic message is - defining whether the goal of ux-minimalism is achieved
Re: [libreoffice-design] Design ethos
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
[libreoffice-design] Design ethos
Hi everyone, Could we agree to use the Firefox UX principles [1] as the basis for our design ethos? I'd like to get this approved on the upcoming IRC chat. If you have any issues with it, please speak up. [1] http://uxmag.com/articles/quantifying-usability -- 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
Re: [libreoffice-design] Design ethos
Hi all Quick speach to say it seems me a good idea. I'm sorry I don't have time to say more these weeks but I think they are good principles. Kévin 2012/6/6 Mirek M. maz...@gmail.com Hi everyone, Could we agree to use the Firefox UX principles [1] as the basis for our design ethos? I'd like to get this approved on the upcoming IRC chat. If you have any issues with it, please speak up. [1] http://uxmag.com/articles/quantifying-usability -- 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 -- 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
Re: [libreoffice-design] Design ethos
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. 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 see a possible solution - and hey, surprise - this again has to do with researching and understanding users: I think we should try to define conditions user under which certain rules apply. Conditions could be something like If the user is likely to be in a stressful situation, prefer to the use of a wizard As I stated before, I'm a bit hesitant about user research -- not because I don't believe it can't be useful, but because we have to be careful to do it correctly, as otherwise it can be quite detrimental to our design. If done badly, user research can be used to justify just about any design. I continue researching user design. Windows seems to do a lot of it [1], but I'm not sure how much it helps them, given that they're dropping everything they know for Metro, which firmly stands against the overcrowded ribbons their research has gained them. Mozilla seems to first design, then test, much like we do now, but then it has some guidelines that help it shape its design [2]. elementary does some basic user research (if it can be called that) on Google+ [3]. Gnome design team doesn't do any, which is a bit surprising, as, IMHO, that's one of the best open-source design communities out there. I would definitely be interested to hear about your own personal experience with user research and how it has lead to design decisions (with concrete examples, if possible). Plus every open-source project that cares about design listens to its users, of course, and the advantage of open development is that people can see the changes before the product is released, so design bugs can be caught before release. We've seen this just recently, with two people reaching out to us, one on G+ and one on the IRC, complaining about the usability of the new About dialog, which Astron has fixed. This is just my experience, perhaps I did misunderstand your intention here. What do you think? I feel like Mozilla's design principles have worked for them and that they would be a good starting point for our own principles. As for user research, I see it as a means to an end. It's definitely something that will help us refine our principles and form our HIG, but we should be careful, as user research can be quite misleading. We should ensure that our principles and our HIG can be followed under all circumstances -- exceptions should never be the rule. [1] http://www.youtube.com/watch?v=532j9sfBcbQ [2] https://www.youtube.com/watch?v=hMDBwa4huUYfeature=player_embedded [3] https://plus.google.com/114635553671833442612/posts -- 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
Re: [libreoffice-design] Design ethos
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 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) 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. 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. 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. 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? 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. = 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? 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
[libreoffice-design] Design Ethos
Hi everyone, As our design team gains members and the number of projects we tackle grows, it increasingly seems like we need some basic principles to guide our designs. That's why I'm starting a wiki page for determining our design ethos [1]. The point of it is to find several key points that define great design. These principles should be generally applicable, whether we're designing something as simple as a remote control app or as complex as a social network like Diaspora. They also shouldn't be weighed against what LibreOffice currently is -- these principles will define the future of LibreOffice, and if we want its future to be excellent, we need to change what LibreOffice is about, turn it from an MS Office-wannabe to an application suite that can stand its own. Anyway, please submit your suggestions to the wiki [1]. [1] https://wiki.documentfoundation.org/Design/Ethos -- 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
