Re: [Ayatana] 11.04 Comboboxes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan Meek wrote on 07/04/11 03:22: ... An example: Go to Power Management preferences and click the combobox for action to take on laptop lid closing, a menu will appear and you can choose an item at your leisure. Now, go run CCSM and go to the Unity plugin's settings, click on the combobox for hide behavior and it appears nothing happens. The two boxes look the same, but for one, you have to seemingly arbitrarily click and hold the combobox to select items and the other you don't. An even better example, I see THREE different comboboxes used in the Software Sources dialog: 1) In the Ubuntu Software tab, a click and hold combobox. 2)In the Updates tab a combobox that you can type in for some reason.(The Check for updates one) 3) Below that in the Updates tab as well, a combobox with the correct behavior. (The Release upgrade combobox) ... A radio menu, or option menu, lets you choose one of several choices, and displays the current choice in the closed menu. It's the menu equivalent of a set of radio buttons. A combo box is a combination of a text field and a radio menu, and displays the current choice in the text field. Windows calls a radio menu a drop-down list, while Mac OS X calls it a pop-up menu. GTK mistakenly calls it a combo box, and then calls an actual combo box a combo box entry. In both Ambiance and Radiance, I see no difference in appearance or behavior between the Power Management Preferences When laptop lid is closed menu, the CCSM Unity Hide Launcher menu, and the Software Sources Download from and Show new distribution releases menus. If you still see a difference, perhaps you could publish a screencast somewhere demonstrating it? The Check for updates menu is a combo box, and should not be. Someone has just reported this bug. http://launchpad.net/bugs/750507 - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk22l2AACgkQ6PUxNfU6ecqBugCfYdbesX467+JwOU/sXvBm2+aa 6HEAoJEmHz5KE9R/FzM5T7yDnVe/+uor =sVa5 -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 GonzO Rodrigue wrote on 23/04/11 18:43: On Sat, Apr 23, 2011 at 5:25 AM, Mitja Pagon mitja.pa...@inueni.com ... 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? I believe that's a different set of tests, there. If you want to see the restults of Charlie's test, look here: https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/032988.html ... It is the same test. Charline's post is largely about comparing Unity in Natty with Unity in Maverick, whereas my message was mainly about summarizing task completion in Natty. However, Charline does mention the menu issue briefly in her post: When participants had many windows opened, they did not understand that the bar corresponded to the selected window. And one of the quotes she includes is from one of the people who concluded that menus were available only for maximized windows: I didn’t like when I have things minimised. There are many things I can’t do without maximising the screen. (Both Charline and the test participants often used the word minimised to refer to unmaximized windows.) - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk223ToACgkQ6PUxNfU6ecro5ACgyZYyPOsUdP9ORIP+KnvjdLdm Q5IAoLz177g+3jm56xDPggq7B3Skvleo =3QFL -END PGP SIGNATURE- ___ 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] 11.04 Comboboxes
On Tue, Apr 26, 2011 at 4:58 AM, Matthew Paul Thomas m...@canonical.com wrote: In both Ambiance and Radiance, I see no difference in appearance or behavior between the Power Management Preferences When laptop lid is closed menu, the CCSM Unity Hide Launcher menu, and the Software Sources Download from and Show new distribution releases menus. If you still see a difference, perhaps you could publish a screencast somewhere demonstrating it? My best guess is this: if you click and hold for a short amount of time (maybe 1/4 second?) without moving your mouse at all, the box will stay shown, perhaps giving the impression that the box does not accept click-hold-release choices. However, moving your mouse in that time makes it accept the input, as does waiting a longer period of time before releasing the mouse. I can make any of those combo boxes behave differently by changing my behaviour subtly - and for someone who isn't intending to differ their behaviour subtly, the nature of the boxes could seem chaotic or buggy. Can you confirm or deny that theory, Johnathan? If I'm way off the mark, a screencast would help. Ryan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Remember window positions
This is regarding https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/124315 Won't Fix in papercuts , but is tagged ayatana to be overseen in Ayatana project Any update on this? I don't think it's necessary to argue why this functionality is so important and there is no point in arguing about who's job it is at this stage. Ubuntu ships with Unity (and is its upstream!) and applications such as Firefox that don't remember their position on their own. Ubuntu should do it even if no other GNOME/metacity/mutter/compiz based desktop does it. Makes for a good bullet-point in a GNOME3 comparison ;) I know about the window placement plugin in CCSM but there are two problems: It requires manual setup and can only do static coordinates and rules whereas it should be enabled by default, transparent and dynamically remember positions. Secondly, it's broken. Opening another window of the same class/role/whatever shouldn't put it exactly on top of the other one but cascaded so both titlebars are visible. See KDE, Windows and OS X for a correct implementation. Besides usability reasons, amplified by the missing taskbar, this also has aesthetic implications when shadows are used: open 3 or more windows and the shadow around them will get almost black and look really ugly. Also it seems currently the grabber doesn't really work. Just in case someone would like to point me at devilspie, it got exactly the same problems plus another one: It moves windows after they have been put by the WM and were already drawn onto the desktop, resulting in some nasty flickering. My recommendation for the near future: Extend the window placement plugin so it supports cascading (or smart placement, see below) of same windows and automatically remembers coordinates. Once it's deemed stable and functionally complete make enabled by default. A remaining questions is if all windows should remember their position by default. The smart placement currently in place has certainly benefits especially when it comes to applications with many windows which users want to have visible side by side (Terminal and Nautilus mainly). I have a new idea for such applications: Given the application centric paradigm of Unity (see my last post in the mailing list) the tiling/non-overlapping window placement could calculate free space only based within an application abstracting away windows of other applications behind it as if ever app was on its own workspace. Click on the launcher icon and all windows of a particular application go to the foreground. I'm not sure how this would work out in practice, I guess extended usability testing would be required. As I wrote in that post I'm no fan of the app-centric paradigm but in case the majority of users prefer it to the window-centric paradigm this new smart placement mode could make sense. Imagine the user-case of file management via drag and drop between multiple nautilus windows. This nicely could merge the advantages of floating and tiling WMs. This brings us to another question, how do we determine the placement of the first window of an application: Say the user opens two windows of the same application and class side by side. One she considers to be the primary, the other is just temporary. She might close either of them first so how should we know what she wants? Two solutions come to my mind: Put it at the position of the last closed window. It's simple and I think both Windows and OS X do that but from my personal experience it's not ideal. I much prefer this one: always open in the same order, if the user puts the very first window in the left upper corner, new windows will be arranged left to right, top to bottom. If the user puts it into the lower right it will go from right to left and bottom to top, after closing all windows of the application it will start again either top left or bottom right. I think this elegantly merges smart window placement and the remember position placement: The first window always opens at a predictable position, subsequent windows are either cascaded or put next to it in a non-overlapping manner depending on size of the windows and remaining free space of the screen. One thing to note, the OS X filemanager remembers position of each folder independently, the Windows filemanager remembers just one position no matter which folder you open. I much prefer OS X in this regards. With Terminals I think both always cascade. If the user doesn't manually rearrange windows it doesn't really matter which one is closed the last because the positions aren't far of from each other even when opening many windows (=number of windows times height of the title bar). In a smart window placement mode however the difference will be huge with the second window already. When using that mode my solution is much more predictable and that's what essentially this whole thing is about. Hope that makes sense, please ask if anything is unclear.
Re: [Ayatana] Improving the display of icons in the Applications window
On Tue, Apr 26, 2011 at 4:11 AM, Caio Alonso caioal...@gmail.com wrote: First of all, sorry for not knowing the right name of this window, I just know it as the one that shows up when the Ubuntu button is clicked. It's the Dash http://askubuntu.com/questions/10228/whats-the-right-terminology-for-unitys-ui-elements 1) When using the Applications lens looking for an internet application for example: if the application I'm looking for is not included in the first 6 shown, I must click again to get to it. But seeing that there is unused space, why can't the Installed section be already expanded to 12 applications when I open it? Take a look: http://i.imgur.com/4IgH8.png I'd go even further and make it a list that expands to the bottom of the screen on non-touch devices (=an option). See Spotlight in OS X. Higher information density yet it's quicker to absorb and process that information, for me at least. Also it makes more sense for keyboard navigation: ever tried using left and right to navigate the icons only to realize you are still in the search box? This can't happen in a vertical list. 2) The second point is in the way the applications are ordered. As can be seen on the previous screenshots cited, they are currently ordered alphabetically. Has ordering them by frequency of use been considered as an alternative or would changing the icon's positions over time break the muscle memory of going to the old icon position? I urge everyone who has access to Mac OS X to try out Quicksilver, they get searching and ranking right to the point of perfection. You can teach it so for example ff gives Firefox as the first result even though it doesn't contain that exact string. Here's a website that kind of demos some of this: http://static.railstips.org/orderedlist/demos/quicksilverjs/ http://orderedlist.com/blog/articles/live-search-with-quicksilver-style/ GNOME-Do or other launchers available on Ubuntu might support this too by now, haven't kept myself up-to-date on this. 3) If the user chooses to maximize this window, why isn't this choice kept for all the next times he opens it? I second this question. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
