Re: [Ayatana] Menu bar integrated in title bar in Unity
On 18/02/11 04:38, Greg K Nicholson wrote: >> Why not integrate (and hide) the menu bar in the title bar instead for >> ummaximized windows? > > This makes sense logically. I also like this idea. My top panel has always been full, the first thing I do on any install is to delete the bottom bar and put all the information I want in the top bar. So now I need to hide information I have been used to having visible to make room for menus while leaving a title bar empty. > The massive downside to all of this is Fitts's law: the effective > target area of a menu bar is vastly reduced when it isn't at the > screen's edge. For that reason alone, and despite its logical and > aesthetic elegance, I think we have to reject this idea. Have users really been having problems clicking on menus? I know we are all different but I would not have thought this affected many users. David ___ 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
On 18 February 2011 11:10, David Stevenson wrote: > On 18/02/11 04:38, Greg K Nicholson wrote: >>> Why not integrate (and hide) the menu bar in the title bar instead for >>> ummaximized windows? >> >> This makes sense logically. > > I also like this idea. My top panel has always been full, the first > thing I do on any install is to delete the bottom bar and put all the > information I want in the top bar. So now I need to hide information I > have been used to having visible to make room for menus while leaving a > title bar empty. > >> The massive downside to all of this is Fitts's law: the effective >> target area of a menu bar is vastly reduced when it isn't at the >> screen's edge. For that reason alone, and despite its logical and >> aesthetic elegance, I think we have to reject this idea. > > Have users really been having problems clicking on menus? I know we are > all different but I would not have thought this affected many users. > > David > Yeah, I don't think it's that much of a problem. Fitt's law keeps being quoted as an excuse to do stuff over and above other factors. I'm still unhappy that the global menu has been implemented despite not-working well with dual-monitors, focus follows mouse, or really large resolutions, but whenever this gets mentioned "Fitt's law" seems to be the overriding excuse. We need to stop putting so much emphasis on Fitt's law, it's only one element of good usability. My suggestion is that we shouldn't be hiding menus behind titles, it would be far more sensible (IMO) to consistently display the application name in the title bar of each window as a menu, whose submenu consists of the current menu bar (e.g. display "Firefox" next to the window controls, clicking "Firefox" would display a drop down menu containing "File", "Edit" etc.). If a window is maximized then the panel becomes the title bar. Luke. ___ 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
On 18 February 2011 12:25, Luke Benstead wrote: > On 18 February 2011 11:10, David Stevenson wrote: >> On 18/02/11 04:38, Greg K Nicholson wrote: Why not integrate (and hide) the menu bar in the title bar instead for ummaximized windows? >>> >>> This makes sense logically. >> >> I also like this idea. My top panel has always been full, the first >> thing I do on any install is to delete the bottom bar and put all the >> information I want in the top bar. So now I need to hide information I >> have been used to having visible to make room for menus while leaving a >> title bar empty. >> >>> The massive downside to all of this is Fitts's law: the effective >>> target area of a menu bar is vastly reduced when it isn't at the >>> screen's edge. For that reason alone, and despite its logical and >>> aesthetic elegance, I think we have to reject this idea. >> >> Have users really been having problems clicking on menus? I know we are >> all different but I would not have thought this affected many users. >> >> David >> > > Yeah, I don't think it's that much of a problem. Fitt's law keeps > being quoted as an excuse to do stuff over and above other factors. > I'm still unhappy that the global menu has been implemented despite > not-working well with dual-monitors, focus follows mouse, or really > large resolutions, but whenever this gets mentioned "Fitt's law" seems > to be the overriding excuse. We need to stop putting so much emphasis > on Fitt's law, it's only one element of good usability. > > My suggestion is that we shouldn't be hiding menus behind titles, it > would be far more sensible (IMO) to consistently display the > application name in the title bar of each window as a menu, whose > submenu consists of the current menu bar (e.g. display "Firefox" next > to the window controls, clicking "Firefox" would display a drop down > menu containing "File", "Edit" etc.). If a window is maximized then > the panel becomes the title bar. > > Luke. > Quick mockup of what I mean: http://i.imgur.com/a763I.png clicking the orange Firefox button would bring down a drop down menu. Luke. ___ 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
On Fri, Feb 18, 2011 at 13:25, Luke Benstead wrote: > > > Yeah, I don't think it's that much of a problem. Fitt's law keeps > being quoted as an excuse to do stuff over and above other factors. > That's one way of seeing it. > > [...] more sensible (IMO) to consistently display the > application name in the title bar of each window as a menu, whose > submenu consists of the current menu bar (e.g. display "Firefox" next > to the window controls, clicking "Firefox" would display a drop down > menu containing "File", "Edit" etc.). If a window is maximized then > the panel becomes the title bar. > thank you. Now add a11y ideas: pressing or holding ALT expands the menu(bar). On the long run, app developers will notice that it is sufficient to put the most frequently used functions into the top level menu that opens upon ALT or clicking the app name, the less frequently needed options will then still have their respective positions in submenus or gconf.. thanks for the mockup! ___ 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
> Yeah, I don't think it's that much of a problem. Fitt's law keeps > being quoted as an excuse to do stuff over and above other factors. > I'm still unhappy that the global menu has been implemented despite > not-working well with dual-monitors, focus follows mouse, or really > large resolutions, but whenever this gets mentioned "Fitt's law" seems > to be the overriding excuse. We need to stop putting so much emphasis > on Fitt's law, it's only one element of good usability. +1 > My suggestion is that we shouldn't be hiding menus behind titles, it > would be far more sensible (IMO) to consistently display the > application name in the title bar of each window as a menu, whose > submenu consists of the current menu bar (e.g. display "Firefox" next > to the window controls, clicking "Firefox" would display a drop down > menu containing "File", "Edit" etc.). If a window is maximized then > the panel becomes the title bar. It could be a solution, but i'm no fan of submenus, you just get lost. Imagine all menus items in one submenu, then these also have their own submenus, it just would be too cluttered, unless doing something like firefox did with its new titlebar button, it's much more organised.Anyway, with your proposal, wouldn't we be hiding menus under a title also? The fact is that menus just would make the titlebar ugly, and most people wouldn't want to see menus all the time, only when they are of use, and then they could be accessible just by dragging the mouse to the titlebar. I have a 1024*768 resolution, pretty small monitor, and i find really hideous to have to drag my mouse to the panel to access the menu when windows are not maximized, it's far from logical to show window controls on unmaximized windows but continue to show the menu on the panel. As to the issues proposed:1) http://lh3.googleusercontent.com/_1QSDkzYY2vc/TV1ykj9zUgI/DA4/wb3dfkvSVOg/gedit_menu.png The mockup shows how, even when the menu is shown, part of the window title is still show, this space would be used to drag and maximize apps, it would be the most logical thing to do, and what i believe most will think of when presented with this scenario.2) This is really the only problem i see, i guess the user will be obliged to enlarge the windows a bit, but what if the window is size-fixed? Anyway, the menu items that would be hidden are the last ones, and the most useless in my opinion, but it's only my opinion. Although globalmenu still has some issues to work with i approve of it and furthermore find this idea to be really useful. Sebas Ps: first contribution to ayatana, from a regular ubuntu user who wants to help. > ___ > 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
*Cough* https://wiki.mozilla.org/File:Firefox-4-Mockup-i06-%28Win7%29-%28Aero%29-%2 8TabsTop%29.png *cough* :) On 18/02/2011 12:45, "Luke Benstead" wrote: >On 18 February 2011 12:25, Luke Benstead wrote: >> On 18 February 2011 11:10, David Stevenson wrote: >>> On 18/02/11 04:38, Greg K Nicholson wrote: > Why not integrate (and hide) the menu bar in the title bar instead >for > ummaximized windows? This makes sense logically. >>> >>> I also like this idea. My top panel has always been full, the first >>> thing I do on any install is to delete the bottom bar and put all the >>> information I want in the top bar. So now I need to hide information I >>> have been used to having visible to make room for menus while leaving a >>> title bar empty. >>> The massive downside to all of this is Fitts's law: the effective target area of a menu bar is vastly reduced when it isn't at the screen's edge. For that reason alone, and despite its logical and aesthetic elegance, I think we have to reject this idea. >>> >>> Have users really been having problems clicking on menus? I know we are >>> all different but I would not have thought this affected many users. >>> >>> David >>> >> >> Yeah, I don't think it's that much of a problem. Fitt's law keeps >> being quoted as an excuse to do stuff over and above other factors. >> I'm still unhappy that the global menu has been implemented despite >> not-working well with dual-monitors, focus follows mouse, or really >> large resolutions, but whenever this gets mentioned "Fitt's law" seems >> to be the overriding excuse. We need to stop putting so much emphasis >> on Fitt's law, it's only one element of good usability. >> >> My suggestion is that we shouldn't be hiding menus behind titles, it >> would be far more sensible (IMO) to consistently display the >> application name in the title bar of each window as a menu, whose >> submenu consists of the current menu bar (e.g. display "Firefox" next >> to the window controls, clicking "Firefox" would display a drop down >> menu containing "File", "Edit" etc.). If a window is maximized then >> the panel becomes the title bar. >> >> Luke. >> > >Quick mockup of what I mean: http://i.imgur.com/a763I.png clicking the >orange Firefox button would bring down a drop down menu. > >Luke. > >___ >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
On 18 February 2011 13:23, Andrew Laignel wrote: > *Cough* > https://wiki.mozilla.org/File:Firefox-4-Mockup-i06-%28Win7%29-%28Aero%29-%2 > 8TabsTop%29.png *cough* > > :) Err... yeah, like that :) Luke. ___ 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] hiding unmounted bookmarks
On Sun, 2011-02-13 at 15:20 +0100, frederik.nn...@gmail.com wrote: > the reason for me to reconsider this in the first place, is that > somebody would be unlikely to bookmark a location, knowing that it > would become physically unavailable soon. > I wouldn't bookmark a location, if i plan not to attach that > thumbdrive or external hdd again anytime soon. This would break my primary use case for bookmarks. I don't bother bookmarking anything on my local system, as it's very easy to navigate to local resources. However, I do bookmark network file systems frequently, as it's a pain to type sftp://some.server.somewhere/long/path/to/the/files/that/I/want Clicking the bookmark opens a connection and FUSE mounts the remote filesystem automatically, saving me time and effort. Perhaps this is an indication that networked external filesystems are different enough from local external filesystems (like thumb drives) that they should be treated differently, but I'm not sure without more thought. - rm ___ 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] hiding unmounted bookmarks
On Fri, Feb 18, 2011 at 15:53, Ronald McCollam < ronald.mccol...@canonical.com> wrote: > On Sun, 2011-02-13 at 15:20 +0100, frederik.nn...@gmail.com wrote: > > > the reason for me to reconsider this in the first place, is that > > somebody would be unlikely to bookmark a location, knowing that it > > would become physically unavailable soon. > > I wouldn't bookmark a location, if i plan not to attach that > > thumbdrive or external hdd again anytime soon. > > This would break my primary use case for bookmarks. I don't bother > bookmarking anything on my local system, as it's very easy to navigate > to local resources. There's a point! > However, I do bookmark network file systems > frequently, as it's a pain to type > > sftp://some.server.somewhere/long/path/to/the/files/that/I/want > > Clicking the bookmark opens a connection and FUSE mounts the remote > filesystem automatically, saving me time and effort. > i wish FUSE would do that for a thumbdrive, an unmounted Windows partition or an external HDD, that is usually connected or close to the computer. > > Perhaps this is an indication that networked external filesystems are > different enough from local external filesystems (like thumb drives) > that they should be treated differently, but I'm not sure without more > thought. > actually, this is not about the device, location or resource. Bookmarking something is like pinning it: I want it to have a special status, i want it to be available before other things. And i want it to stay in my list, until i remove it from there (unpin). Bookmarks for removable devices such as thumbdrives or say e.g. an internal Windows partition are currently being hidden, whenever the location is unavailable. This is not good: i bookmarked the location, not only to always see it, but to also remind myself of its existence among all the clutter. So when i bookmark/pin something, it should always be visible (same goes for Contact List / Empathy - https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/667289 ). ESPECIALLY when the resource is currently not available. Empathy fixes this pin/unpin problem by making "Favourites" show, regardless if they are online or offline. What i would expect: I bookmark a folder on my Windows partition, then i unmount that ntfs. The bookmark remains, and when i click it the partition is mounted automatically. The same would ideally apply to thumbdrives, external HDDs, CDs and DVDs. Since i pinned the folder, i either intend to keep the DVD in the drive, the thumbdrive in the USB Port, the HDD in the eSATA port or IEEE1394 port or USB port. Or the SD Card in the Card Reader. The list goes on. I think it is important to solve these conceptual problems around storage, since working around these problems will continue causing regressions in other areas of design, which wouldn't need to be. Attempts at designing concepts of distributed databases or storage, as well as non-local concepts of memory will all keep bashing against the conceptual problem of accessibility posed by the current behaviour. ___ 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
On Fri, 18 Feb 2011, Luke Benstead wrote: > On 18 February 2011 13:23, Andrew Laignel wrote: > > https://wiki.mozilla.org/File:Firefox-4-Mockup-i06-%28Win7%29-%28Aero%29-%28TabsTop%29.png > > *cough* > Err... yeah, like that :) These kinds of menus are okay for very seldomly-used ones---such as those in a browser, or an instant messaging application---but I've never been particularly keen on them for menus that actually have to be *used* (word-processor, drawing application, ...). My understanding is that humans remember grids: across, then down. When that type of vertical menu is: down, down, down, ... the instant positional memory is not there. My best regular example of this is the huge right-click menu in GIMP. After a decade of near-daily use I still don't have a mental model of what that menu looks like, other than knowing that the option I want is "somewhere" in 2-3 layers of side-ways shuffling. Admittedly I quite happily used the similiarly ballooning side-ways menus in RiscOS for several years prior to that; compare: http://i.ytimg.com/vi/RLXilJdXGMo/0.jpg (RiscOS !Draw) http://math.hws.edu/eck/cs120/f02/lab4/gimp_menus.gif (GIMP) -Paul ___ 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] hiding unmounted bookmarks
On So, 2011-02-13 at 15:20 +0100, frederik.nn...@gmail.com wrote: > somebody would be unlikely to bookmark a location, knowing that it > would become physically unavailable soon. I wouldn't bookmark a > location, if i plan not to attach that thumbdrive or external hdd > again anytime soon. I'm exactly opposite, and for me the current behavior is perfect. For example, I have my mp3s on the internal HD, but my flac collection is on an external USB disk. When this is plugged in, I want the "Music Storage" bookmark to be available. If it's not plugged in, the bookmark should be hidden (as it is now) The same applies in to other external USB disks where I keep stuff. ___ 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
On Fri, Feb 18, 2011 at 18:39, Paul Sladen wrote: > On Fri, 18 Feb 2011, Luke Benstead wrote: > > On 18 February 2011 13:23, Andrew Laignel > wrote: > > > > https://wiki.mozilla.org/File:Firefox-4-Mockup-i06-%28Win7%29-%28Aero%29-%28TabsTop%29.png*cough* > > Err... yeah, like that :) > > These kinds of menus are okay for very seldomly-used ones---such as > those in a browser, or an instant messaging application---but I've > never been particularly keen on them for menus that actually have to > be *used* (word-processor, drawing application, ...). > that's a very good distinction! I wouldn't want a menu bar on a calculator, i'd just want the calculator and a button for the settings dialog. The calculator window could then morph in place into a settings dialog, or dim it's UI and overlay it with a transparent settings page.. > > My understanding is that humans remember grids: across, then down. > yes, that's an ability learnt in primary school, it's not to my knowledge that we're born with it. Some languages are not read like that, they are read vertically first, then horizontally. We're born with an abstract pattern memory: the simpler the pattern, the easier to memorize. > When that type of vertical menu is: down, down, down, ... the instant > positional memory is not there. good point. That's why i would recommend to open a horizontal menubar, when the AppMenu is evoked via ALT or via clicking the AppName button My best regular example of this is > the huge right-click menu in GIMP. After a decade of near-daily use I > still don't have a mental model of what that menu looks like, other > than knowing that the option I want is "somewhere" in 2-3 layers of > side-ways shuffling. > which is ok, if you use that option once in a while. If you use the option frequently, it should have an accessible and logical interaction path. > > Admittedly I quite happily used the similiarly ballooning side-ways > menus in RiscOS for several years prior to that; compare: > > http://i.ytimg.com/vi/RLXilJdXGMo/0.jpg (RiscOS !Draw) > http://math.hws.edu/eck/cs120/f02/lab4/gimp_menus.gif (GIMP) > thanks for the screenshots ;) 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.. ___ 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] hiding unmounted bookmarks
On Fri, Feb 18, 2011 at 11:57, Mario Vukelic wrote: > I'm exactly opposite, and for me the current behavior is perfect. For > example, I have my mp3s on the internal HD, but my flac collection is on > an external USB disk. When this is plugged in, I want the "Music > Storage" bookmark to be available. If it's not plugged in, the bookmark > should be hidden (as it is now) > So perhaps the distinction is on automatically available items? You might want to pick and choose when an remote-ssh filesystem is available (for example), in which case it should always be available. For a USB filesystem, you might want it hidden if the hardware's not present. When the hardware's there, it mounts. You could unmount it, but it would still be available from the menu (possibly with another "safe-to-remove" indicator?). On the other hand, maybe this isn't really a "bookmark" situation. -- Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =- ___ 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] hiding unmounted bookmarks
On Fri, Feb 18, 2011 at 20:46, Jeremy Nickurak wrote: > On Fri, Feb 18, 2011 at 11:57, Mario Vukelic wrote: > >> I'm exactly opposite, and for me the current behavior is perfect. For >> example, I have my mp3s on the internal HD, but my flac collection is on >> an external USB disk. When this is plugged in, I want the "Music >> Storage" bookmark to be available. If it's not plugged in, the bookmark >> should be hidden (as it is now) >> > > So perhaps the distinction is on automatically available items? > > You might want to pick and choose when an remote-ssh filesystem is > available (for example), in which case it should always be available. > > For a USB filesystem, you might want it hidden if the hardware's not > present. When the hardware's there, it mounts. You could unmount it, but it > would still be available from the menu (possibly with another > "safe-to-remove" indicator?). On the other hand, maybe this isn't really a > "bookmark" situation. > yea, a bookmark is something that stays. if it disappears, it's not a bookmark. ___ 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" 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
On Fri, Feb 18, 2011 at 23:04, Mitja Pagon wrote: > - Original Message - > From: "frederik nnaji" > > 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, > 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. 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 to design an interface otoh is to aim at not needing it at the end of the day. imo. ___ 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" 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
