Re: [Ayatana] Fitts Law
- Matthew Paul Thomas m...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- It does. In the videos I watched of Charline Poirier's user test two weeks ago, of the eight out of ten people who could find the hidden menus at all, seven of them discovered the menus while mousing over the close/minimize/unmaximize buttons in a maximized window. They then concluded that the way to access menus was to hover over the close/minimize/unmaximize buttons, and then move sideways. This was very slow, and didn't work at all in unmaximized windows. People were much faster at using LibreOffice's menus, which are not yet integrated into the global menu bar by default. http://design.canonical.com/2011/04/unity-benchmark-usability-april-2011/ Is this the testing you were referring to? If so, how come there is no mention of the issues you raised above? Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Fitts Law
- Luke Benstead kaz...@gmail.com wrote: These questions really need answering, Luke. I somewhat doubt we will get any response, it's looking more and more like the time when window controls were switched to the left, after a while the opposition just gave up and later on Mr. Shuttleworth declared how he was right to do the switch as no one is raising the issue any more. It looks like their modus operandi, ignore the counter arguments long enough that the proponents give up and then declare yourself the winner. And just for the sake of clarification, I don't now and didn't then, care much about whether window controls are on the left or the right, just pointing out a similar pattern. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Fitts Law
- Matthew Paul Thomas m...@canonical.com wrote: It does. In the videos I watched of Charline Poirier's user test two weeks ago, of the eight out of ten people who could find the hidden menus at all, seven of them discovered the menus while mousing over the close/minimize/unmaximize buttons in a maximized window. They then concluded that the way to access menus was to hover over the close/minimize/unmaximize buttons, and then move sideways. This was very slow, and didn't work at all in unmaximized windows. People were much faster at using LibreOffice's menus, which are not yet integrated into the global menu bar by default. The question remains. Why, despite being a definite usability regression, is the menu still hidden? Who makes this decisions and why can't they accept the fact they are wrong in this case? Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Awesome critical review of Unity
- Luke Benstead kaz...@gmail.com wrote: Sigh, OK, I'll explain it again: 1. Displaying the title in the panel *alone* isn't a problem 2. Displaying the title in the panel AND merging the maximized window is a problem Why? Because the panel becomes the maximized window's title bar, so now you have the wrong title on the window. Add that in with menus, menu hiding and window controls and you have a total mess. Luke. You are right it's a mess. What I want to know, and that is why I posted the message that started this latest discussion, is what are the reasons for current behavior? There has been no official response, the closest that I could find was some answer by Mark Shuttleworth on askubuntu.com, but that made as much sense as wearing sunglasses at night. I find id curious that no one involved with unity/canonical has commented on this issue, it almost seems as they are ignoring it. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Dynamic menu items
Nicely put, to extend on you example, the problem Microsoft faced were not pull down menus themselves, it was rather the fact that Office applications acquired so much functionality, that pull down menus were no longer an optimal way to expose that functionality. This trend against application menus is based on generalized assumptions based on isolated examples of applications with alternative menus, mostly chrome and firefox (ironically both have application menus in OSX AFAIK) and it seems, as you mentioned, like making a change for the sake of change. Cheers, Mitja - Kevin Godby god...@gmail.com wrote: Hello, Shane. On Sat, Apr 16, 2011 at 12:15 PM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: We can do it and also learn from microsoft's mistake. Im not saying it wouldnt be a challenge to make it work but I think we should be looking to do things like this to make the interface more intelligent. Menus haven't changed for a long time we should change that. I'm all for making user interfaces more intelligent. However, we shouldn't change pull-down menus merely for the sake of changing pull-down menus. What are the problems with the existing pull-down menu design? What are some potential solutions to those problems? How can we test those solutions to see if they are improvements over the original design? Here's an example: Problem: Users must wade through menu items that they rarely use to get to the menu items they use more frequently (such as Save and Print). Proposed solution: Rearrange the menu items so that the most-frequently used menu items at the top of the menu. Further, we could hide rarely used menu items and reveal them if the user requests it or dwells on the menu for some period of time. Testing the design: Microsoft implemented this design in Office 2000 to much fanfare. The problem with the design is that the order of the menu items changed from day to day, so the desired menu item wasn't where it was before, and was therefore *more difficult* to find. Further, the hidden menu items made it much more difficult for people to discover the (less-frequently used) features they were seeking and greatly reduced the discoverability of those features. At this point, you could iterate the design to address the problems found by testing or, if the problems were inherent in the design, go back to the drawing board and come up with a new design. But you should always start with a clear problem statement—otherwise you have no way of knowing whether your 'solution' is an improvement. --Kevin ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Dynamic menu items
- Shane Fagan shanepatrickfa...@ubuntu.com wrote: This trend against application menus is based on generalized assumptions based on isolated examples of applications with alternative menus, mostly chrome and firefox (ironically both have application menus in OSX AFAIK) and it seems, as you mentioned, like making a change for the sake of change. To repeat what I said to Kevin this list is about concepts to improve and smooth out stuff. Try not to knock out ideas just because they are far fetched just put your counter argument and let people make up their minds. I wasn't saying anything against application menus themselves I was just putting out an idea to improve upon them. I don't believe in the whole change for changes sake thing at all but if it aint broke don't fix it doesnt mean you cant think about making it better. --fagan Ignore that last paragraph of mine, I mixed up the threads, it isn't related to what you wrote. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] New natty scrollbar issues
I see this scrollbars as another solution in search of a problem to solve and in the process introducing more problems than it solves. When will people realize that this is not the right approach to do things. Cheers, Mitja - Xavier Claessens xclae...@gmail.com wrote: Hello, I discovered recently natty as a new scrollbar, as exposed by Mark Shuttleworth himself: http://www.markshuttleworth.com/archives/615 Here are my issues: * I can’t middle click to jump to a position * I can’t click on the bar to make a big jump * I need a long time to find where the bar is hiding * Only empathy and gedit have that new scrollbar, all other apps still have the normal bar, does that means it is yet another per-app patch? I'm not even speaking about implementation issues that will hopefully be fixed by the time natty gets released. Are there solutions planned for those issues? Regards, Xavier Claessens. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] New natty scrollbar issues
- Martín Soto dons...@gmail.com wrote: On Mon, Apr 11, 2011 at 10:20 AM, Mitja Pagon mitja.pa...@inueni.com wrote: I see this scrollbars as another solution in search of a problem to solve and in the process introducing more problems than it solves. When will people realize that this is not the right approach to do things. The main advantage of the new scrollbars is that their real estate consumption is essentially 0. This may feel as a minor change when you're sitting in front of a 25 screen, but on my tiny notebook where every pixel counts, the improvement is significant. So yes, there are still some issues, but calling the scrollbars another solution in search of a problem appears quite unfair to me. M. S. Sorry, but every pixel counts is not a definition of a problem. Before coming up with a solution, first you have to define what the problem you are trying to solve is. This is the supposed problem as defined by Christian Giordano, the man behind this scroll bar implementation: Today’s scrollbars are optimized for cursor driven UI but they became easily unnecessary and bulky on touchable and small screen devices. In those cases, optimization of the screen’s real-estate becomes essential. Other platforms optimized for touch input like Android and iOS are already using a light-weight solution visible only while dragging the content. I don't see any definition of any problems in there, just some presumptions. I'm not saying scroll couldn't be improved, it's just the approach that I believe is wrong, hence solution in search of a problem. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] New natty scrollbar issues
- Conscious User consciousu...@gmail.com wrote: The problem *is* clear: scrollbars are optimized for cursor driven UI but they became easily unnecessary and bulky on touchable and small screen devices. Actually it's not, the definition is vague and overly generalized. Also it's based on a false assumption that you can optimize for both cursor driven an touch interfaces. Another assumption is that scrollbars are unnecessary on small screen devices. The issue is that the solution is *incomplete*: in order to improve the experience for touch screens, mouse users were forgotten and their experience that was previously optimized is not anymore. See above point and your last paragraph. Ironically, this is the *opposite* of the menu-on-hover issue, where mouse users were prioritized and touch screen users were forgotten. I was thinking of bringing up that exact same point. It seems that, in addition to John and Matthew not talking to each other, Christian and John are also not talking to each other. You call it lack of talking, I call it a lack of coherent vision, worrying nonetheless. Matthew has already acknowledged that there's no such thing as an interface optimal for both mouse and touch, so the design team should either make up their mind about what they're optimizing for, or Canonical should release an Ubuntu Touch Edition and separate the design projects accordingly. That would be hard, as it would require an investment beyond the shell (big part of the problem are applications which are not touch optimized). An interesting endeavor it would be, but one we are unlikely to see. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] why global menubar/application menu isn't such a great idea
- Conscious User consciousu...@aol.com wrote: While I disagree with Mitja's tone (as usual), That's a bit harsh, my tone is fine most of the time ;) I'll admit that people talking nonsense sometimes gets the best of me, but in most cases I try to be polite, if somewhat blunt. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] New idea of usability for Unity
Good stuff - the menu (M) button should be implemented by ages .. finally some necessary order regarding usability No it should not, it's a bad idea and a degradation of usablity and if you would have even the basic understanding of the subject of usability you would know why. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Menu hiding is one of the risky moves we are making. Initial tests on unsuspecting users have shown they find 'em quickly and easily enough. I agree with you, though, that a hint to their existence and anchor (left-of-the-File-menu) would be nice. That can come in a refinement, mockups and patches welcome. - Mark Shuttleworth, 20 hours ago. I guess there is no point in discussing this anymore, the man has decided. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
And what may those advantages be? Not every application is a web browser and not all applications are the same, so this "trend" Chrome supposedly started does not automatically apply to all and every application. Also this quest for abolishing menus is complete nonsense propagated by people who mostly know nothing about user interface design / interaction design, user experience design , and this place (ayatana list) is, despite an occasional good idea, littered with people like that. Sometimes it makes me feel like most people use Ubuntu to just to surf pr0n.Different people have stated multiple issues with this hidden menus integrated title/controls and many more issues arise when trying to tackle those issues while the benefits are almost non existent, and that is a dictionary example of bad design.Cheers,MitjaMitja PagonInueni d.o.o., Pot pod Gradiščem 4, SI 4202 NakloTel.: +386 41 521 729e-naslov: mitja.pa...@inueni.com, url: www.inueni.com- Original Message -From: "Marc Lajoie" manorap...@gmail.comTo: appi2...@gmail.comCc: Ayatana@lists.launchpad.netSent: Wednesday, March 16, 2011 3:20:51 AMSubject: Re: [Ayatana] Design problem: Menus hidden by default in UnityI, for one, love the integration of the menu and titlebars into the panel in Natty. The decluttering of the workspace, or the "chromifization" (as in Google Chrome, which started the wonderful trend of minimal interfaces and the hiding of visual clutter) of Ubuntu is the main reason I am looking forward to Natty. So while I understand the concerns about the hidden menu, I agree with the logic of not treating the menu as an indicator, and hiding it up in the panel. Yes, there are a couple of small problems with this approach (mostly discoverability for new users, people using Natty for the very first time), but my opinion is the benefits outweigh the disadvantages. My vote, for what it's worth, is to keep it the way it is!That said, I would not oppose having the menu in the panel being shown by default, instead of the title, in the case of non-maximized windows, with the title/menu overlap occurring only for maximized windows. Marc LajoieOn Wed, Mar 16, 2011 at 8:59 AM, appi2...@gmail.com appi2...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.com wrote: I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. 2. It makes some functions effectively invisible.The above two problems are important to fix. 3. The application or window title becomes ugly when the menus appear.#3 is not that big of a problem - we should avoid it when we can, but if its necessary, its better to have an eyesore than a interaction problem. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too.Although this is a problem, a title is necessary for maximized windows, so it has to be shown for them.I proposed a solution to this earlier on this list, but unfortunately, it got no replies. However, I still believe that it can solve the problems brought up here. My basic idea is: https://lists.launchpad.net/ayatana/msg04555.htmlHowever, I have a change: The Application Title should only be shown for maximized windows, where it is necessary. Otherwise, only the menu should be visible. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___Mailing list: https://launchpad.net/~ayatanaPost to : ayatana@lists.launchpad.netUnsubscribe : https://launchpad.net/~ayatanaMore help : https://help.launchpad.net/ListHelp___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Peace indeed. I'm not implying that you or anyone else is stupid, I'm stating, and as irritating as it might be to you, the fact, that most people on here (most, not all) don't understand what interaction design is about (and that implies lack of understading, not supidity), and you just proved my point, interaction design is not about personal opinions, it's a science backed by facts. Issues raised are backed by actual science your advantages are mostly a personal opinion (you are more that welcome to prove otherwise with actual facts). And this is an issues that can hardly be resolved by a community, just like nuclear plant can't be built by bakers, they simply lack the knowledge. Cheers, Mitja - Original Message - From: Marc Lajoie manorap...@gmail.com To: Mitja Pagon mitja.pa...@inueni.com Cc: Ayatana@lists.launchpad.net, appi2...@gmail.com Sent: Wednesday, March 16, 2011 10:23:48 AM Subject: Re: [Ayatana] Design problem: Menus hidden by default in Unity You can drop the ad hominem attacks. The everyone's-stupid-but-me attitude is not very productive. Advantages to current setup: Increases free vertical space; removes visual clutter; creates a disincentive to use the menu as an indicator conveying useful information for which it's not suited (more standardized and consistent menu headings across different applications is definitely something to be encouraged, taking the guesswork out of menu hunting). Disadvantages: Menu is disconnected from unmaximized windows, potentially causing confusion; Menu is not discoverable for first-time user (new user won't know where the menu is unless he/she accidentally hovers over the panel) To say there are no advantages is disingenuous. You believe the disadvantages outweigh the advantages. Fine, good. I believe the reverse. You are entitled to your opinion. So am I. The community will decide. Peace, man. Marc Lajoie On Wed, Mar 16, 2011 at 4:48 PM, Mitja Pagon mitja.pa...@inueni.com wrote: And what may those advantages be? Not every application is a web browser and not all applications are the same, so this trend Chrome supposedly started does not automatically apply to all and every application. Also this quest for abolishing menus is complete nonsense propagated by people who mostly know nothing about user interface design / interaction design, user experience design , and this place (ayatana list) is, despite an occasional good idea, littered with people like that. Sometimes it makes me feel like most people use Ubuntu to just to surf pr0n. Different people have stated multiple issues with this hidden menus integrated title/controls and many more issues arise when trying to tackle those issues while the benefits are almost non existent, and that is a dictionary example of bad design. Cheers, Mitja Mitja Pagon Inueni d.o.o., Pot pod Gradiščem 4, SI 4202 Naklo Tel.: +386 41 521 729 e-naslov: mitja.pa...@inueni.com , url: www.inueni.com - Original Message - From: Marc Lajoie manorap...@gmail.com To: appi2...@gmail.com Cc: Ayatana@lists.launchpad.net Sent: Wednesday, March 16, 2011 3:20:51 AM Subject: Re: [Ayatana] Design problem: Menus hidden by default in Unity I, for one, love the integration of the menu and titlebars into the panel in Natty. The decluttering of the workspace, or the chromifization (as in Google Chrome, which started the wonderful trend of minimal interfaces and the hiding of visual clutter) of Ubuntu is the main reason I am looking forward to Natty. So while I understand the concerns about the hidden menu, I agree with the logic of not treating the menu as an indicator, and hiding it up in the panel. Yes, there are a couple of small problems with this approach (mostly discoverability for new users, people using Natty for the very first time), but my opinion is the benefits outweigh the disadvantages. My vote, for what it's worth, is to keep it the way it is! That said, I would not oppose having the menu in the panel being shown by default, instead of the title, in the case of non-maximized windows, with the title/menu overlap occurring only for maximized windows. Marc Lajoie On Wed, Mar 16, 2011 at 8:59 AM, appi2...@gmail.com appi2...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:34 PM, Matthew Paul Thomas m...@canonical.com wrote: I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. 2. It makes some functions effectively invisible. The above two problems are important to fix. 3. The application or window title becomes ugly when the menus appear. #3 is not that big of a problem - we should avoid it when we can, but if its necessary, its better to have an eyesore than a interaction problem. 4. The application or window title and the title bar are redundant, and sometimes
Re: [Ayatana] Design problems in general
You picked the wrong example as left-aligned windows controls were not a design decision per se, but rather a decision based on Mark Shuttleworth's own personal preference, as stated by himself. Cheers, Mitja - Original Message - From: Lee Hyde anub...@gmail.com To: t w t...@freenet.de Cc: ayatana@lists.launchpad.net Sent: Wednesday, March 16, 2011 2:59:20 PM Subject: Re: [Ayatana] Design problems in general On 16/03/11 13:01, Thorsten Wilms wrote: If you are not under too tight constraints, the questionshouldn't be how something is being done, not even how users would like to do it, but rather: how should they do it? I thoroughly disagree with this assessment of UI/X design for the following reasons: 1. It flies in the face of Ubuntu's Linux for Humans motto 2. There is a risk of over-intellectualising UI/X design As I see it (and do correct me if I'm wrong) there is a lack of data to support the 'how it should be done' philosophy. How does one arrive at a conclusion of 'how it should be done'? Have there been any mouse tracking or eye tracking studies on the subject? If so did any of them cover the ease with which end-users adapted to UI changes such as the adoption of left-alignment of window controls or UI changes resulting from switching operating systems? Is there any data concerning uptake of packages and/or settings to subvert changes to the UI/X (beyond the mere existence of such packages)? Without such data I fail to see how one could arrive at a conclusive decision regards a UI/X redesign. It would be nice to have some form of opt-in anonymous data gathering package (census?) for precisely this kind of data gathering. Something similar to Mozilla's Test Pilot and LabKit add-ons which could be used to enrol users (which their prior knowledge and ultimate control) in new UI/X studies and prototype/proof-of-concept UI/X designs. Whether you'd get enough participants to make it worth the developers efforts I don't though, although I would certainly participate in any studies and many prototypes on offer. There is of course a place for artistic license, but not at the cost flexibility or at the risk of dictating how the end-user must use their computer. For example, would it really be so terrible to offer the end user options such as positioning of the Unity panel (bottom or top), or positioning of the Unity dock/springboard? Would it be terrible to consider the users upgrade path when designing (or rather setting up) the interface. A lifelong windows user might prefer a bottom-aligned panel and right-aligned window controls to smooth the transition whilst a MacOSX user might prefer precisely the opposite. On 16/03/11 13:01, Thorsten Wilms wrote: Sometimes the problem may be certain users stubbornness rather than anything else, especially if you design for the long term. So the answer may have to be wrapped up in a strategy to sell it. It's not always simply a case of user stubbornness. Speaking from personal experience, the decision to enforce left-alignment of window controls in Unity will have a negative impact on my own work flow. Due to circumstances beyond my control I have little choice but to dual-boot both Ubuntu and Windows. I work within a laboratory environment wherein many proprietary control and data analysis software is reliant on a Windows platform (often legacy). Hence I fund myself having to dual-boot or VM into Windows frequently, to translate and/or manipulate data gathered via laboratory equipment. This is a very jarring experience, and the shift to and fro left-aligned window controls certainly impacts on my efficiency. Of course the above use case is a rather nice scenario, but I am sure than numerous office worker suffer from similarly strict (although for different reasons entirely) IT provisioning that forces them to use Windows in the workplace. Some thought ought to be given to the 'forced to dual-boot' community, as I'm sure it's a sizeable one. The consistency of user experience should be a goal, not only within Ubuntu itself, but throughout the users experience. The Windows platform is unlikely to offer a left-aligned mode, and so it falls to Ubuntu/Unity to offer an (optional) right-aligned mode lest risk vexing their 'forced to dual-boot' user base. As things stand, I will have to forgo Unity in favour of gnome-panel until this particular issue is addressed (assuming it ever will be) but if push comes to shove I will have little choice but to default to Windows (laboratory equipment manufacturers are unlikely to provision Linux based software any time soon) and I can see myself using Ubuntu less and less (which is a shame, as I far prefer it to Windows). -- The second basic thesis is that intellectual freedom is essential to human society — freedom to obtain and distribute information, freedom for open-minded and unfearing debate and freedom from
Re: [Ayatana] Design problems in general
There is absolutely nothing wrong with full-screen writing software from design perspective, actually they make a lot of sense in that particular case (backed by science), it's just that that doesn't make full-screen an optimal case for every application. I suspect that you are somewhat misinterpreting what interaction/user experience (even industrial) design is, it's not about forcing designers own views upon users, that called bad design and it's sadly omnipresent, it's rather about understanding your target audiences needs and providing an optimal interface for those needs. Users existing habits and work-flow are a common obstacle to adoption of new interfaces, but that has more to do with the fear of change and the unknown and it doesn't imply that said interface is bad. MS Office ribbon interface is a good example of that, lot's existing users complained, but new users and users who got beyond that initial fear, were actually very pleased with the experience (a similar example in the field of programing languages is VB.NET at the time it was released). Cheers, Mitja - Original Message - From: Marc Lajoie manorap...@gmail.com To: Lee Hyde anub...@gmail.com Cc: ayatana@lists.launchpad.net Sent: Wednesday, March 16, 2011 3:37:11 PM Subject: Re: [Ayatana] Design problems in general I am a writer. I write fiction using my computer, which for me is a creative tool. My workflow is maybe chaotic, sometimes illogical, but it works for me. An interface that is not flexible enough to adapt to my creative workflow is a system I will not use. I am not about to change the way I create my art at the insistence of a machine. This is the sort of thing a designer can't hope to understand without some input from the end-user. Ubuntu is supposed to be for human beings, and human beings are not always logical; This is not a bug but a feature. A perfect example is the fullscreen text-editors that are popular among writers. Interface designers, I suspect, are baffled at why any user would want to hide the entire interface (including information-giving pieces of interface that in no way cover or interfere with the writing space). But to me, and to many writers, having an aesthetically pleasing writing environment is inspiring. It is not the most logical, efficient possible layout, granted. But it's pretty, and pretty makes me happy--and being happy helps me write. Marc Lajoie On Wed, Mar 16, 2011 at 9:59 PM, Lee Hyde anub...@gmail.com wrote: On 16/03/11 13:01, Thorsten Wilms wrote: If you are not under too tight constraints, the questionshouldn't be how something is being done, not even how users would like to do it, but rather: how should they do it? I thoroughly disagree with this assessment of UI/X design for the following reasons: 1. It flies in the face of Ubuntu's Linux for Humans motto 2. There is a risk of over-intellectualising UI/X design As I see it (and do correct me if I'm wrong) there is a lack of data to support the 'how it should be done' philosophy. How does one arrive at a conclusion of 'how it should be done'? Have there been any mouse tracking or eye tracking studies on the subject? If so did any of them cover the ease with which end-users adapted to UI changes such as the adoption of left-alignment of window controls or UI changes resulting from switching operating systems? Is there any data concerning uptake of packages and/or settings to subvert changes to the UI/X (beyond the mere existence of such packages)? Without such data I fail to see how one could arrive at a conclusive decision regards a UI/X redesign. It would be nice to have some form of opt-in anonymous data gathering package (census?) for precisely this kind of data gathering. Something similar to Mozilla's Test Pilot and LabKit add-ons which could be used to enrol users (which their prior knowledge and ultimate control) in new UI/X studies and prototype/proof-of-concept UI/X designs. Whether you'd get enough participants to make it worth the developers efforts I don't though, although I would certainly participate in any studies and many prototypes on offer. There is of course a place for artistic license, but not at the cost flexibility or at the risk of dictating how the end-user must use their computer. For example, would it really be so terrible to offer the end user options such as positioning of the Unity panel (bottom or top), or positioning of the Unity dock/springboard? Would it be terrible to consider the users upgrade path when designing (or rather setting up) the interface. A lifelong windows user might prefer a bottom-aligned panel and right-aligned window controls to smooth the transition whilst a MacOSX user might prefer precisely the opposite. On 16/03/11 13:01, Thorsten Wilms wrote: Sometimes the problem may be certain users stubbornness rather than anything else, especially if you design for the long
Re: [Ayatana] Design problems in general
I agree time to sign off, as this discussion is going nowhere and it's not really contributing much to anything anymore. Just remember, designers are you friends ;) Cheers, Mitja - Original Message - From: Marc Lajoie manorap...@gmail.com To: Mitja Pagon mitja.pa...@inueni.com Cc: ayatana@lists.launchpad.net, Lee Hyde anub...@gmail.com Sent: Wednesday, March 16, 2011 5:02:16 PM Subject: Re: [Ayatana] Design problems in general And you intend to understand your target audience's needs without including it in the discussion? Marc Lajoie ps. Where's your science that says that u sers resist changing their work-flow based more [on] ... fear of change and the unknown? Isn't it possible their preferences are not completely invalid? pps. I have to go to sleep, so will be abandoning this discussion soon. On Wed, Mar 16, 2011 at 11:25 PM, Mitja Pagon mitja.pa...@inueni.com wrote: There is absolutely nothing wrong with full-screen writing software from design perspective, actually they make a lot of sense in that particular case (backed by science), it's just that that doesn't make full-screen an optimal case for every application. I suspect that you are somewhat misinterpreting what interaction/user experience (even industrial) design is, it's not about forcing designers own views upon users, that called bad design and it's sadly omnipresent, it's rather about understanding your target audiences needs and providing an optimal interface for those needs. Users existing habits and work-flow are a common obstacle to adoption of new interfaces, but that has more to do with the fear of change and the unknown and it doesn't imply that said interface is bad. MS Office ribbon interface is a good example of that, lot's existing users complained, but new users and users who got beyond that initial fear, were actually very pleased with the experience (a similar example in the field of programing languages is VB.NET at the time it was released). Cheers, Mitja - Original Message - From: Marc Lajoie manorap...@gmail.com To: Lee Hyde anub...@gmail.com Cc: ayatana@lists.launchpad.net Sent: Wednesday, March 16, 2011 3:37:11 PM Subject: Re: [Ayatana] Design problems in general I am a writer. I write fiction using my computer, which for me is a creative tool. My workflow is maybe chaotic, sometimes illogical, but it works for me. An interface that is not flexible enough to adapt to my creative workflow is a system I will not use. I am not about to change the way I create my art at the insistence of a machine. This is the sort of thing a designer can't hope to understand without some input from the end-user. Ubuntu is supposed to be for human beings, and human beings are not always logical; This is not a bug but a feature. A perfect example is the fullscreen text-editors that are popular among writers. Interface designers, I suspect, are baffled at why any user would want to hide the entire interface (including information-giving pieces of interface that in no way cover or interfere with the writing space). But to me, and to many writers, having an aesthetically pleasing writing environment is inspiring. It is not the most logical, efficient possible layout, granted. But it's pretty, and pretty makes me happy--and being happy helps me write. Marc Lajoie On Wed, Mar 16, 2011 at 9:59 PM, Lee Hyde anub...@gmail.com wrote: On 16/03/11 13:01, Thorsten Wilms wrote: If you are not under too tight constraints, the questionshouldn't be how something is being done, not even how users would like to do it, but rather: how should they do it? I thoroughly disagree with this assessment of UI/X design for the following reasons: 1. It flies in the face of Ubuntu's Linux for Humans motto 2. There is a risk of over-intellectualising UI/X design As I see it (and do correct me if I'm wrong) there is a lack of data to support the 'how it should be done' philosophy. How does one arrive at a conclusion of 'how it should be done'? Have there been any mouse tracking or eye tracking studies on the subject? If so did any of them cover the ease with which end-users adapted to UI changes such as the adoption of left-alignment of window controls or UI changes resulting from switching operating systems? Is there any data concerning uptake of packages and/or settings to subvert changes to the UI/X (beyond the mere existence of such packages)? Without such data I fail to see how one could arrive at a conclusive decision regards a UI/X redesign. It would be nice to have some form of opt-in anonymous data gathering package (census?) for precisely this kind of data gathering. Something similar to Mozilla's Test Pilot and LabKit add-ons which could be used to enrol users (which their prior knowledge and ultimate control) in new UI/X studies and prototype/proof-of-concept UI/X designs. Whether you'd get enough participants
Re: [Ayatana] Design problem: Menus hidden by default in Unity
I've raised this issue before in various places, but I never got any response, so I'm really, positively surprised to see the same issues raised by someone from Canonical. Why not just keep the window title on the window, it's not really wasting that much screen space. This space efficiency as a design goal is being taken to far. Integrating window controls and title into the panel gains a bit of space, but is introduces some issues, most of which you listed. Keeping the application name in the global menu is important, as it a visual clue as to which application's menus are displayed. The inconsistencies in application naming can be filed as bugs and fixed, as names are read from desktop files. If an application has no menu, no name would need to be displayed. As for naming of entries in application menus, that sadly can't be easily resolved, as it's mostly up to application developers to sort out. Cheers, Mitja - Original Message - From: Matthew Paul Thomas m...@canonical.com To: Ayatana@lists.launchpad.net Sent: Tuesday, March 15, 2011 6:34:52 PM Subject: [Ayatana] Design problem: Menus hidden by default in Unity -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After several weeks of trying, last week I finally succeeded in installing Natty to test Unity. I was disappointed to see that in Unity, menus are invisible until you mouse over where they are supposed to be. For a window, until you mouse over it, the space reserved for its menus is taken up by an application or window title. And for the desktop, until you mouse over it, the space for its menus is completely empty. I reported a bug about this, but John Lea marked it as Invalid on the grounds that this change request contradicts the design. He requested that I discuss it here. The design John cited is not the menu bar specification https://wiki.ubuntu.com/MenuBar, but a separate The Unity Menu document that is new to me. https://docs.google.com/View?id=dfkkjjcj_1776g5ztgbc3 I see four major problems with hiding the menus and covering them with an application or window title. 1. Most importantly, it makes the menus much harder to use. The The Unity Menu document says that The top level of the menu rarely shows significant information (it is not an indicator) - it consists essentially of category headings, like 'File' and 'Edit' and 'View'. None of those add any relevant information to the task at hand, or wider awareness. Whoever wrote that is mistaken. Every time the task at hand involves using a menu, it is necessary first to be aware of, and then to move the pointer to, the desired menu. That is much harder to do if the menu is invisible until just after you finish needing to know where it is. Whether the menus collectively are an indicator is irrelevant: the first item in the rationale, for what determines whether something appears in the menu bar, has always been It's not whether it's a status indicator. https://wiki.ubuntu.com/MenuBar?action=AttachFiledo=viewtarget=whether-something-appears.jpg 2. It makes some functions effectively invisible. For example, last month Jack Wallen wrote for TechRepublic http://www.techrepublic.com/blog/opensource/x/2291: One of the most handy menu entries in GNOME (for me at least) is the Connect to Server entry in the Places menu. This allows the user to connect to nearly any type of server quickly and easily. The user can even connect to a Windows Share from here. In Unity - you won’t find that. In fact, you will be hard pressed to find any means to connect to a server in Ubuntu Unity. At the time, I didn't understand how he could have had that problem. Now I do. The Connect to Server item, which is in the Places menu on the Ubuntu 10.10 desktop, is in the File menu on the Natty desktop. But the desktop appears, incorrectly, to have no menus at all. The The Unity Menu document says Many modern applications are being designed without substantial menus. The problem with that approach was explained in my initial post introducing the menu bar: it results in gratuitous inconsistency between applications. http://design.canonical.com/2010/05/menu-bar/#history But that is beside the point. Hiding menus for windows that *do* rely on them does nobody any good. 3. The application or window title becomes ugly when the menus appear. For example, when using Nautilus's menus, the menu bar reads File Man File Edit View Go Bookmarks Help. Similarly when using Terminal's menus, the menu bar reads Termina File Edit View Search Terminal Help. And when using Calculator's menus, the menu bar gets a stutter: Calculat Calculator Mode Help. 4. The application or window title and the title bar are redundant, and sometimes inconsistent too. For example, when that Calculator window is open, its title bar says Calculator, and the menu bar pointlessly repeats Calculator. When a Banshee window is open, its title bar says
Re: [Ayatana] Windicators
Still I fail to see what actual problem(s) windicators are meant solve or in what way are they supposed to better UX. To me it seem like it's a solution in of search of a problem to solve. Mitja - Original Message - From: Mark Shuttleworth m...@ubuntu.com To: Mitja Pagon mitja.pa...@inueni.com Cc: he...@owaislone.org, ayatana@lists.launchpad.net, Carl Simpson cwd.simp...@gmail.com Sent: Monday, February 21, 2011 8:08:53 AM Subject: Re: [Ayatana] Windicators On 20/02/11 18:39, Mitja Pagon wrote: Using the example of volume control mentioned below, am I the only one who thinks windicators make little sense and are in fact bad UX. No, of course you are not the only person, there's lots of dissent, which is fine and stimulates discussion to get a better result. Follow my example. What is the added benefit of having the per-application volume control as windicator. Music players already have per application volume controls in their UIs and space gained by moving them into the window title is minimal. Are there any other benefits am missing? It would not make sense to have volume controls both inside the UI, and in the title bar as an indicator. But the suggestion of course was to let apps *move* that functionality to the indicator, not duplicate the functionality. Indicators are abstract, logical entities that are exported from the app. They can thus be useful in more general cases. For example, in the window spread views, indicators could be rendered at full size, so their semantic meaning can be scanned in the spread view. They could even be interactive in those views, allowing one to set the appropriate volume for multiple windows, quickly, in the volume example. On the other hand you are adding visual clutter to the title bar, introducing confusing behavior, as the same indicator is sometimes applications specific, other times it system wide, not to mention you are giving yourself additional technical problems to solve and thus requiring more resources. All of this are negative implications of this idea. Giving technical problems to solve is called challenging the engineers and we rather like to do that, and they rather like it too, round here ;-) As long as the work feels like it is foundational and will stick around for a long time and be used, solving hard problems is worthwhile. If you apply simple math to this you can conclude that he negatives of this idea outweigh the positives. There are some other use cases mentioned, but most of the same logic applies and as for using windicators for notifying users there is already notify-osd. Notify-OSD is purely for momentary events, not status. Indicators combine status and manipulation of the status, they are entirely different from notifications. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] I don't think global menu and the panel is good for a touch OS
I would draw a distinction between touch friendly and touch optimized, and while I agree with what MPT said about Unity and Ubuntu not being optimized for touch (mainly because of the applications), there is nothing wrong with making interfaces touch friendly (usable on, but not optimized for, touch displays). And while menus in current form are not touch optimized, mainly due to small target area, I don't get this dismissal of menus as an UI element altogether,it makes no sense. How would you propose applications rich in functionality expose that functionally, by cluttering the interface to oblivion, using arcane gestures? Cheers, Mitja - Original Message - From: Mark Shuttleworth m...@ubuntu.com To: ayatana ayatana@lists.launchpad.net Sent: Sunday, February 20, 2011 4:16:53 PM Subject: Re: [Ayatana] I don't think global menu and the panel is good for a touch OS On 18/01/11 18:09, Conscious User wrote: They are very different things, and a design that works well for one will hardly ever work well for the other. I'm a little bit confused now because Mark's blog post about Unity clearly stated that some design decisions were motivated by touch devices. Is the Unity design still taking touch into consideration or this was completely dropped once it was decided that Desktops would use it too? No. Menu's are inherently antagonistic to touch. They are not salvageable in their current form, so we're making no effort to do so. As MPT has said clearly here, if you want to make a touch friendly *app*, you need to use touch friendly styling and gestures. And not depend on menus at all. Utouch makes that easy to do, but you won't get touchiness for free in the app, you have to design for it. Similarly, we didn't get it for free in the shell, we had to design for it. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Windicators
Using the example of volume control mentioned below, am I the only one who thinks windicators make little sense and are in fact bad UX. Follow my example. What is the added benefit of having the per-application volume control as windicator. Music players already have per application volume controls in their UIs and space gained by moving them into the window title is minimal. Are there any other benefits am missing? On the other hand you are adding visual clutter to the title bar, introducing confusing behavior, as the same indicator is sometimes applications specific, other times it system wide, not to mention you are giving yourself additional technical problems to solve and thus requiring more resources. All of this are negative implications of this idea. If you apply simple math to this you can conclude that he negatives of this idea outweigh the positives. There are some other use cases mentioned, but most of the same logic applies and as for using windicators for notifying users there is already notify-osd. Cheers, Mitja - Original Message - From: Mark Shuttleworth m...@ubuntu.com To: Carl Simpson cwd.simp...@gmail.com Cc: he...@owaislone.org, ayatana@lists.launchpad.net Sent: Sunday, February 20, 2011 4:57:59 PM Subject: Re: [Ayatana] Windicators I think we should provide a standard collapsing approach for things which could be window indicators and which are commonly system indicators too, like volume. When maximised, the window indicator is embedded in the system indicator (so there's only one volume indicator, and in there you find what you probably expect to find). Needs cogent thinking, but I think it's doable. Mark On 04/01/11 20:06, Carl Simpson wrote: To clarify, I mean people tend to want that somewhere in the front-and-centre interface; I'm aware that it's there in gnome-volume-control. 2011/1/4 Carl Simpson cwd.simp...@gmail.com 2011/1/4 Mark Shuttleworth m...@ubuntu.com When maximised, they go into the panel, on the right, left of any app-indicators. Can we can assume from this that per-application functions, such as volume control and network status, wont be tenable uses of the windicator idea, since this would result in duplicates (e.g., two volume controls) or confusingly similar items in the panel when applications are maximised? If that is the case, then as a side note: I get the sense that per-application volume control is something that people generally think that they want- is there any plan for that sort of thing? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Menu bar integrated in title bar in Unity
- Original Message - From: frederik nnaji frederik.nn...@gmail.com As a rule one can say: every submenu is a workaround to a design problem. The best design is instantaneous, the best menu is a menu that doesn't exist, the best UI is a UI that doesn't exist. Once we add a layer, level or page to a UI, we know that we're adding complexity, and complexity is what makes a UI difficult to use. The only type of complexity that makes a UI easier to use is the complexity that is supported by native human intuition, and that is something we don't discuss here so much unfortunately.. - Out of curiosity, what are you basing this rule of yours on? Best UI is no UI, how is that supposed to work? What you are saying makes no sense at all. I suggest you look up the meaning of complexity, also look up oxymoron. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Menu bar integrated in title bar in Unity
- Original Message - From: frederik nnaji frederik.nn...@gmail.com yes, i give you that, taken literally it can't make sense that easily ;) The purpose of technology is not to be in our way, but to achieve goals. In that respect, the best technology or technique is one which achieves the goal with little or no action at all. In that respect, reducing the UI, up to the point where it is pure interaction, invisible, unobtrusive, is the goal especially interaction designers share, as far as my opinion goes. While I agree with most of what you say above, your understanding of interaction design is somewhat simplified, it not just about streamlining the user interface it's also about minimizing physical and mental strain of interaction. It's about finding the right balance. It's the latter two, that most people tend to ignore. The whole purpose of designing interaction is to work around the fact that it is still necessary. At the end of the day, we want to write a text without thinking about windows, icons, menus or pointers, we want to achieve the simplicity we have when e.g. using pencil and paper. The fact that we are yet to balance the flexibility of computer interfaces with the perfect simplicity of virtually modeled physical appliances reflects, that it is not so easy to simply phase out UIs entirely, they will be around as long as options exist in interaction. How can one use a computer, or any other form of technology for that matter, without interaction? The purpose of interaction design is to make interaction a positive experience for the user, not to remove the interaction altogether. Your pencil and paper analogy is also flawed. Wouldn't going back to the simplicity of pen and paper be negating all the benefits we get with computer aided writing. People moved beyond pen and paper for a reason. And using pen and paper is anything but simple, it takes lots time to master if you wish to produce anything of value (modern art excluded). How to design an interface otoh is to aim at not needing it at the end of the day. If you wish to expose any amount of functionality you need an interface. Generally speaking more functionality you have, more complex you interface will be, simple as. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Menu bar integrated in title bar in Unity
Now Unity Desktop integrates (and hide) the menu bar in the upper panel both for the maximized windows and unmaximized ones. This is the reasons according to Mark Shuttleworth: «One of the design goals of Unity is to reduce the clutter of the desktop, another is to use space more efficiently. We hide the menu by default in Unity because the menu provides no useful information to which you can refer just by looking at it, but it puts a lot of detail on the screen which is visual clutter. So, we’ve taken the view that the menu is there if you need it (by moving the mouse to it or pressing Alt) but otherwise isn’t in your view. I very much doubt that is the actual reason, as despite what you think or believe, menus actually do provide important information to the user. Also, menus won't be going away anytime soon, but more on that latter. I would speculate, that auto-hide behavior is a consequence of the decision to merge window title and controls with the top panel for maximized windows, as having all those and also the indicators in the panel at the same time would be to cluttered and against the design goals. F rankly it's a decision I really don't get. By hiding the menu they have negated one of the main benefits of a global menu, which is the fact that it can be quickly and easily accessed. If the menu is hidden it's not as easily targeted and it requires extra hand movement and also more cognitive power to accomplish, yes the Alt key can show the menu, but that is neither obvious or easily discoverable (I for one didn't know that until I read it in your email). What are the actual advantages of this decision also eludes me. The stated goal is to reduce desktop clutter, but I don't get the logic. What they are essentially doing is gaining some 24px of vertical space at the expense of visually cluttering the top panel, without any obvious benefits. I might make some sense on small screens (sub 10) where space is limited, it however makes little sense on larger screens. There are some other drawbacks, like not being touch friendly, but enough for now. Many modern applications are doing without a menu altogether, so in our view, this is a step towards the future, and it will encourage application developers to think about their interfaces and make them more usable by design rather than depending on the crutch of a menu.» While there are applications that don't have a need for a full blown menus, that doesn't mean that there is no future for menus in user interfaces. For applications rich in functionality (like GIMP, Inkscape, ...) it would be hard to present all of that functionality without using menus as it would result in a lot of visual clutter. Why not integrate (and hide) the menu bar in the title bar instead for ummaximized windows? What are the benefits of this approach and are they greater then any possible negative implications it might have on the user experience and usability as a whole. It's important to ask yourself those questions when designing any user interaction. Right now I don't see any such benefits in your proposal and at the same time you yourself listed below, some of the negative implications your proposal will have (Issues you pointed out and the added complexity needed to work around them). I'll let you draw your own conclusions. I have realized a simple mockup that shows my idea. The menu bar will be show only if the menu is over the title bar. However, there are some implementation issues: - if the menu bar is shown in the title bar, how do I use it to drag/maximize/unmaximise the window? - what about if the menu bar is bigger than the title bar? The second is not a real problem: the classic Gnome cut the menu bar if it is bigger than the windows. For the first problem there are different solutions. For example we can use the left button mouse for use the menu bar and the right button mouse for use the title bar (drag, maximize/unmaximized with double click). Or we can add another window control that allows us to drop the windows . ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
