Re: [libreoffice-design] New Whiteboard Proposal Comments Ruler Control
On Sat, Jun 9, 2012 at 8:53 PM, Christoph Noack christ...@dogmatux.comwrote: Hi Mirek, all! Am Samstag, den 09.06.2012, 00:39 +0200 schrieb Mirek M.: On Fri, Jun 8, 2012 at 11:54 PM, Christoph Noack christ...@dogmatux.com wrote: Am Freitag, den 08.06.2012, 23:33 +0200 schrieb Mirek M.: On Fri, Jun 8, 2012 at 9:10 PM, Christoph Noack christ...@dogmatux.com wrote: ... there has been some nice ruler rework recently [1], and so I got a friendly ping about what had happened to the so called Comments Ruler Control I've proposed years ago when working on the Writer notes [2]. I've started a (private) Whiteboard [...] Any further feedback? (Before moving the page?) Looks good. Mirek, thanks for having a look and thanks for the guidance! So I've ... * added a link on the Whiteboard to this discussion thread * moved the page to the Whiteboards area (see [1]) * added the Whiteboard to the Call for Proposals section * added a link to the new Whiteboard to Bug 38246 (the Easy hack bug for hacking on that issue) [1] New location for the Whiteboard Comments Ruler Control: https://wiki.documentfoundation.org/Design/Whiteboards/Comments_Ruler_Control Great. I renamed the entry on the official whiteboard page to Comments Toggle for Writer, as the submitted proposals don't have to concern the ruler. -- 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
[libreoffice-design] Re: [Libreoffice-ux-advise] Fwd: Ubuntu Templates
Hi, On Sat, Jun 09, 2012 at 04:47:26PM +0200, Alexander Wilms wrote: I tried to fix BrightBlue, to me it seems OK now. We still have some masterpages supplied by the community (cc0) and Mirek wanted to let the design list vote on them first, if there's still enough time to integrate them at all: http://ubuntuone.com/1rcQiE2v1xbJ0lWsIqWWzu Uploaded. However for me BrightBlue is still broken, could you please have a look at that again (Best: do a build from feature/masterpages and check yourself) and remove it again, if its not fixable? If there are more masterpages, please add them yourself, you have commit rights now -- no need to do cumbersome errorprona nd annoying throwing around of zipped files etc. Please just finalize feature/masterpages directly so that we can pull it into libreoffice-3-6 before beta2(*). Thanks! Best, Bjoern (*) Week 25: http://wiki.documentfoundation.org/ReleasePlan/3.6 -- 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] Re: Looking for a new splash screen
Hi Adolfo, For the in-program artwork, it's right, we just need PNG's However, there are two reasons why we want SVG: #1 License compliance: the LGPL license say that you have to be able to show the source for any given part of a covered work. It is a bit of a stretch to try to apply a software source code license to artwork, but nonetheless we'd like to be on the safe side. (If you started out with Gimp, then obviously the source would be an XCF file.) #2 The other, very practical reason is that we might want to make changes (maybe now, maybe later) – that could range from adapting the dimensions of the splash screen to having to add a version number ...; with a raster image all of that is a bit harder. Hope this helps, 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 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
