Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Juanjo Marín juanjomari...@yahoo.es wrote: ... But also some problems has arisen in the effort of being compatible with touch devices.For example, I think that the UI of new applications like Documents are very touch friendly, but it's weird for keyboard + mouse users. It is weird because the interaction is very different from other core applications like Nautilus (Files). In Nautilus, double click opens a file, but only one click opens it in Documents, and the way of selecting elements and doing actions with selected elements is quite different. I think Documents works great in touch screen devices and it is a little bit clumpsy with mouse, and Nautilus works great in mouse and keyboard but not so good for touchscreen devices. Right, so the selection design pattern is probably the most prominent place where touch compatibility has had an impact. It should be emphasised that it is somewhat unique in this regard. The selection pattern has been evolving a bit, and we have a round of design changes planned which we will hopefully happen this cycle. Me and Jakub literally have a list of things that can be done to the selection mode to make it better with a pointer. Once we're done I don't think it will be any worse than the selection mechanisms that we have in nautilus today. It should also be said that this pattern does have benefits when you are using a pointer. An obvious example of this is the difference between single/double click. Not only is double click not exactly ideal on a touchpad, but it is also used inconsistently and is non-discoverable (some places you need double click to open, others you need single.) In general, using single click consistently is a much better approach, especially when combined with discoverable mechanisms for selection. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Hi Allan, The selection pattern has been evolving a bit, and we have a round of design changes planned which we will hopefully happen this cycle. Me and Jakub literally have a list of things that can be done to the selection mode to make it better with a pointer. Once we're done I don't think it will be any worse than the selection mechanisms that we have in nautilus today. Would you say that it will be so good that it could (would) be ported to Nautilus too, for consistency's sake? Or is dealing with file systems considered as a pointer-only task? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
The selection pattern has been evolving a bit, and we have a round of design changes planned which we will hopefully happen this cycle. Me and Jakub literally have a list of things that can be done to the selection mode to make it better with a pointer. Once we're done I don't think it will be any worse than the selection mechanisms that we have in nautilus today. Did you see that we've already brought back rubberband selection ? I hope that fits into your plans. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
On 04/30/2013 11:37 AM, Allan Day wrote: It should also be said that this pattern does have benefits when you are using a pointer. An obvious example of this is the difference between single/double click. Not only is double click not exactly ideal on a touchpad, but it is also used inconsistently and is non-discoverable (some places you need double click to open, others you need single.) In general, using single click consistently is a much better approach, especially when combined with discoverable mechanisms for selection. FWIW, the one-click/double-click discussion is a really long-discussion. In fact there are a 10 years bug still open about adding the possibility to configure the behaviour. The good news news is that it seems that there are recent activity on that bug [1]. Additionally, there is also a wiki page related with that: https://live.gnome.org/SingleClickPolicyPlan It was started with an accessibility-pov in mind, but as you are saying, there are several other reasons to discuss about that. So just pointing to avoid a disaggregated discussion. About my personal opinion: * As others said, it is needed to have a consistent behaviour on the platform. * If the consistent behaviour includes two-clicks for some situations, it should be configurable, that is what the bug tries to solve. * Probably should be also configurable if a only one-click policy is defined (but put more priority on the former). Best regards [1] https://bugzilla.gnome.org/show_bug.cgi?id=121113 -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
On Tue, Apr 30, 2013 at 12:33 PM, Tristan Van Berkom t...@gnome.org wrote: There are two paths I can see which an application can take to be touch friendly: a.) Distribute a completely separate binary designed for touch b.) Try to do what gnome-shell seems to be trying, i.e. detect whether the app is running in a touch environment, and make specific tweaks, use separate UIs for the touch environment than the app would use with a mouse driven environment. Well that assumes that touch and pointer a mutually exclusive, which they aren't. Think about laptops with touchscreen is it a pointer based device? Or a touch based? It is neither it depends on how the user currently use it. I don't know how to solve this but touch vs. pointer are (no longer) mutually exclusive. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, Apr 24, 2013 at 8:14 AM, Colin Walters walt...@verbum.org wrote: On Wed, 2013-04-24 at 12:22 +0200, Florian Müllner wrote: First: If we are actually ready to roll out ostree images, that's awesome news! Depends who the audience is...no security updates and you need to build applications from source. But if you want to see GNOME as it is a few minutes or less after commits to git master, then yes. That's good enough in my estimation. It's not meant to be a full service distro. As long as the core apps are there I think we should be fine. Combined that with bugzilla tag and we should be good to go. Personally though I don't think it's that big of a deal to push things to git master...it's not usually that hard to revert if things don't work out. Well in this case you're reverting a UI workflows, it's best not to bounce around work flows honestly. You should consider UI like you would API and ABI once it's in, you don't want to be changing them again without a good reason. So it's important that we get it right the first time. Unless of course, you want to tell people that things will be in flux till release 3.xx and they should expect changes in the design. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, 2013-04-24 at 23:24 -0700, Sriram Ramkrishna wrote: So it's important that we get it right the first time. No, it's not. It's important that we make the changes when we get details wrong, as is the case in any software. If we had to get things right the first time, we wouldn't be writing GNOME *3*. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
De: Allan Day allanp...@gmail.com Para: Alberto Ruiz ar...@gnome.org CC: desktop-devel-list desktop-devel-list@gnome.org Enviado: Miércoles 24 de abril de 2013 18:34 Asunto: Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu] Alberto Ruiz ar...@gnome.org wrote: ... we have to question ourselves if this is another trend like the netbook one that is somewhat transient and misleading. ... I'd make a distinction here between transformers (Docable tablet that turns into a laptop+trackpad) that switches between touch mode and keyboard/pointer mode. My question is, do we have data that backs up the notion that people actually want a touch screen in their laptops? Or is this just the OEMs following Windows 8 in the hope that they will sell more units? ... I don't believe there will be a single UI for both form factors. I can see value in having the ability to switch from tablet to PC with the same device as long as the application set is different and only apps shipped for each form factor are shown on each mode. ... I am just concerned about how much stuff that would make a great design for keyboard+pointer are we giving up to be touch friendly. I am afraid that if we go down that route we will end up with a not so great touch UI and a not so great keyboard+pointer UI. If it was up to me I would stick to be a great UI for what people knows and will keep using for as long as we are a keyboard+pointer desktop when it came to design criteria. But that's just me, I am just trying to have valuable conversation about this and making sure I understand what's in your mind moving forward. ... My problem with that approach is that you are somewhat giving users notion that they can use the desktop with a touch interface, and as long as you try to use a more complex app that ability goes away, that's ought to be frustrating. Sorry for the slow reply. Honestly, I don't see us sacrificing a huge amount to try and gain a degree of touchscreen compatibility. All our designs are primarily targeted at pointer and keyboard; we just try and steer clear of the biggest touchscreen issues. With touch becoming much more common, that doesn't seem like an entirely crazy thing to do. My main goal at this stage is to make sure that someone running GNOME 3 on a laptop with a touchscreen doesn't get something that is *totally* broken for their device - that's it. That said, on a personal level I find the prospect of GNOME 3 running on a laptop with a touchscreen or a transformer style hybrid to be an appealing one. A laptop with a touchscreen would make some occasional actions easier and more satisfying (think scrolling, zooming, dragging, paging, etc). A hybrid wouldn't be a fully-fledged tablet when in tablet mode, but would be a convenient hardware arrangement for certain activities, like watching a film or browsing the web. Well, I think that is not easy to add touchscreen support without compromising the keyboard + mouse experience. I've seen many changes in GNOME 3 that I think are positive, because not only by improving the experience of mouse + keyboard users, but also by improving the experience in touchscreen devices. But also some problems has arisen in the effort of being compatible with touch devices.For example, I think that the UI of new applications like Documents are very touch friendly, but it's weird for keyboard + mouse users. It is weird because the interaction is very different from other core applications like Nautilus (Files). In Nautilus, double click opens a file, but only one click opens it in Documents, and the way of selecting elements and doing actions with selected elements is quite different. I think Documents works great in touch screen devices and it is a little bit clumpsy with mouse, and Nautilus works great in mouse and keyboard but not so good for touchscreen devices. In my opinion, the current keyboard + mouse experience must be preserved and the compatibility with touchscreen devices must be pursuited through the addition of new mechanics when touchscreen devices are detected and avoid any change that can be perceived such as a regression of the keyboard + mouse interactions. Just my two cents, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On 24 April 2013 04:54, Mathieu Bridon boche...@fedoraproject.org wrote: On Wed, 2013-04-24 at 04:00 +0300, Luc Pionchon wrote: On 24 April 2013 02:14, Florian Müllner fmuell...@gnome.org wrote: On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari ma...@scannadinari.co.uk wrote: I think your suggestion of a feature branch can be a worthy compromise, though. Except that Bastien is right - while on a branch, a feature will hardly be tested by anyone than other core developers of the same module. It's unfortunate, but real users generally only get to test a new feature once it appears in their distro (read: some time after the feature appears in a stable GNOME release). A branch can be packaged as well. So one module could have two packages. Who will package them? For which distros? With how much delay? The same people who packaged the application previews? One with mature UI changes. One with controversial edge UI to be tested. Now consider the many modules forming GNOME. Do you build the edge package of, say, GNOME Shell against the mature package of GLib? Or also against the edge of GLib? glib (or gtk) are very bad examples. They never ship immature features/API. You will never see a package libglib+crap. On another hand, that's a very good example, because immature glib/gtk content has been shipped either part of other modules (for example libgd), or in a separate module/package (libegg, in the past). Unless there was no option to disable the immature features. Such a solution would quickly lead to an explosion of possible combinaisons of edge/mature packages. No... you strongly exaggerate the solution to prove it wrong (this is unfair). If something works at one scale, it does not have to necessarily work at an upper scale. Concretely we speak about one feature preview, maybe some more. There is no concrete perspective for such explosion. Unless you mean that a user must install the edge package for all modules if all they want is to test the edge of GNOME Shell? (idem) If so, how is that different from just installing the 3.9 packages in a development distro? 3.9 packages are for developers, as I understand it. Things may break. The main point is that so-called controversial features does not have to be either a hard default, either rotting in a branch. They can be shipped as default, but with a way to revert them in the case they block the user. I thought first to a downgrade-able package. Another way is to toggle it with a setting. Yet another way, for gnome-shell, is to make it as an extension. etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, Apr 24, 2013 at 1:14 AM, Florian Müllner fmuell...@gnome.org wrote: On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari ma...@scannadinari.co.uk wrote: In fact, I think that these sorts of subtle design-based decisions should be held in something like loomio (see recent loomio post in desktop-devel), to be later implemented if the response is positive. And as has been mentioned on that thread, this is design by committee, which is not how it works (or should work). Yes, sometimes controversial changes are reversed at a later point, and a user vote would almost certainly have prevented the controversial change in the first place, but it would also prevent those controversial changes that turned out right - in particular, neither GNOME 2 nor GNOME 3 would have happened in the first place. I think your suggestion of a feature branch can be a worthy compromise, though. Except that Bastien is right - while on a branch, a feature will hardly be tested by anyone than other core developers of the same module. It's unfortunate, but real users generally only get to test a new feature once it appears in their distro (read: some time after the feature appears in a stable GNOME release). Another option is to use the extension system for that. But I am not sure that will get us a lot more testers either without active promotion. So yeah I agree the only way to get real users to test it is to merge it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, Apr 24, 2013 at 9:53 AM, Luc Pionchon pionchon@gmail.com wrote: The main point is that so-called controversial features does not have to be either a hard default, either rotting in a branch. They can be shipped as default, but with a way to revert them in the case they block the user. Wait - are you suggesting to create a fork each time a controversial change is made? How does that scale? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On 24 April 2013 11:57, Florian Müllner fmuell...@gnome.org wrote: On Wed, Apr 24, 2013 at 9:53 AM, Luc Pionchon pionchon@gmail.com wrote: The main point is that so-called controversial features does not have to be either a hard default, either rotting in a branch. They can be shipped as default, but with a way to revert them in the case they block the user. Wait - are you suggesting to create a fork each time a controversial change is made? no. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Planning an ostree hackfest would be more useful I would say, instead of arguing over (another) new way of shipping code to users/developers/testers... Once ostree is usable all this will be moot: let developers code the thing and once finished let everyone know that feature X can be tested with ostree... Cheers, Gil (Sorry, sent from phone) On Apr 24, 2013 11:50 AM, Luc Pionchon pionchon@gmail.com wrote: On 24 April 2013 11:57, Florian Müllner fmuell...@gnome.org wrote: On Wed, Apr 24, 2013 at 9:53 AM, Luc Pionchon pionchon@gmail.com wrote: The main point is that so-called controversial features does not have to be either a hard default, either rotting in a branch. They can be shipped as default, but with a way to revert them in the case they block the user. Wait - are you suggesting to create a fork each time a controversial change is made? no. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, Apr 24, 2013 at 3:51 AM, Sriram Ramkrishna s...@ramkrishna.me wrote: At least until we get a better testing infrastructure in place, the only way to get at least *some* user testing is [...] to get some minimal exposure to adventurous users of unstable/experimental distributions Again treating your user base as your user test bed is going to create some backlash. They have signed on to doing things the GNOME 3 way, don't abuse them by rapidly adding new methodologies that they have to get used to after establishing use patterns already. I was explicitly referring to the part of the user base that runs/tests development versions. Is treating voluntary testers as test bed really that bad (abuse even)? real users generally only get to test a new feature once it appears in their distro I don't agree here at all. First all, we should be able to use ostree and create new images based on the next-gen features branch. [...] Our infrastructure is becoming sophisticated. Use it and stress it. We didn't get all this hardware for nothing. Andrea and I will try to help out here. First: If we are actually ready to roll out ostree images, that's awesome news! Not having to rely on other parties to get our code tested is a huge step forward. Still, the process is still new, so I'm a bit wary about overwhelming testers with too many images at once - getting early feedback on features (this proposal is not the only UI change I expect this cycle) is certainly worthy, but it should also not take away too many resources from getting as much testing as possible of the master branch (after all, that's what we *will* ship to users - catching regressions from non-UI code churn is not as shiny as evaluating UI changes, but not any less needed). Slightly off-topic, I guess that part of my problem is actually that I don't consider this a huge change - or rather, not anymore. I've first learned about the rough idea in a casual chat at fosdem, and my first reaction was certainly along the lines of whoa, big change, not so sure, ..., but after digesting it for a while, it appears much more minor. In general, stuff gets moved rather than removed - tongue-in-cheek, the only thing missing from the mockups are my neighbors' APs; I know that's not entirely true, and I don't agree on every detail of the proposal myself (not to mention some question marks), but I don't doubt that there will be sufficient clarification and refinement - in particular now when can finally leverage ostree. I'd just much prefer focusing on discussing/addressing individual quirks instead of looking for ways to block the change as a whole ... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, 2013-04-24 at 12:22 +0200, Florian Müllner wrote: First: If we are actually ready to roll out ostree images, that's awesome news! Depends who the audience is...no security updates and you need to build applications from source. But if you want to see GNOME as it is a few minutes or less after commits to git master, then yes. Personally though I don't think it's that big of a deal to push things to git master...it's not usually that hard to revert if things don't work out. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Alberto Ruiz ar...@gnome.org wrote: ... we have to question ourselves if this is another trend like the netbook one that is somewhat transient and misleading. ... I'd make a distinction here between transformers (Docable tablet that turns into a laptop+trackpad) that switches between touch mode and keyboard/pointer mode. My question is, do we have data that backs up the notion that people actually want a touch screen in their laptops? Or is this just the OEMs following Windows 8 in the hope that they will sell more units? ... I don't believe there will be a single UI for both form factors. I can see value in having the ability to switch from tablet to PC with the same device as long as the application set is different and only apps shipped for each form factor are shown on each mode. ... I am just concerned about how much stuff that would make a great design for keyboard+pointer are we giving up to be touch friendly. I am afraid that if we go down that route we will end up with a not so great touch UI and a not so great keyboard+pointer UI. If it was up to me I would stick to be a great UI for what people knows and will keep using for as long as we are a keyboard+pointer desktop when it came to design criteria. But that's just me, I am just trying to have valuable conversation about this and making sure I understand what's in your mind moving forward. ... My problem with that approach is that you are somewhat giving users notion that they can use the desktop with a touch interface, and as long as you try to use a more complex app that ability goes away, that's ought to be frustrating. Sorry for the slow reply. Honestly, I don't see us sacrificing a huge amount to try and gain a degree of touchscreen compatibility. All our designs are primarily targeted at pointer and keyboard; we just try and steer clear of the biggest touchscreen issues. With touch becoming much more common, that doesn't seem like an entirely crazy thing to do. My main goal at this stage is to make sure that someone running GNOME 3 on a laptop with a touchscreen doesn't get something that is *totally* broken for their device - that's it. That said, on a personal level I find the prospect of GNOME 3 running on a laptop with a touchscreen or a transformer style hybrid to be an appealing one. A laptop with a touchscreen would make some occasional actions easier and more satisfying (think scrolling, zooming, dragging, paging, etc). A hybrid wouldn't be a fully-fledged tablet when in tablet mode, but would be a convenient hardware arrangement for certain activities, like watching a film or browsing the web. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Hi Allan, On 22/04/13 16:26, Allan Day wrote: Alberto Ruiz ar...@gnome.org wrote: I am not sure what the criteria is with this regard and I might have miss a public discussion about it. What are we trying to accomplish with this whole trend towards touch? I haven't seen any successful single UI story that works well on both touch and mouse/keyboard form factors. Again, bear with me since I might have missed compelling discussions about this design strategy. So as an initial goal, I'm hoping that we'll be able to have a good form of touch compatibility, with a target of laptops with touchscreens. I don't think we have the resources to create several versions of GNOME for different types of devices. Resource questions aside, I want to affirm the main point Alberto made -- there has not been any successful single UX story that works well in both contexts. My main concern is that by improving touch experience we are going to end up degrading the mouse/kbd experience. As a basic, but I think pertinent, example -- if one of the reasons for the current design being touch unfriendly is that certain UI elements are too small (which is the most rudimentary problem any UI moving from pointer to touch faces), making them bigger will result in non-negligeable loss of screen realestate on small laptop screens, and deeper the touch improvements will go, the more significant this will be. It worries me :-) Tomas -- http://sleepfive.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Tomas Frydrych tf+lists.gn...@r-finger.com wrote: ... As a basic, but I think pertinent, example -- if one of the reasons for the current design being touch unfriendly is that certain UI elements are too small (which is the most rudimentary problem any UI moving from pointer to touch faces), making them bigger will result in non-negligeable loss of screen realestate on small laptop screens, and deeper the touch improvements will go, the more significant this will be. It worries me :-) Did you look at the wireframes? We're not making the top bar any taller, and it won't take space away from applications. The only change to the size of the items in the top bar is to make them wider (although the icons will stay the same size). This proposal is designed to provide a better experience when using pointer input (indeed, I listed a whole series of reasons that it will be an improvement in that context). Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
El 22/04/13 18:57, Allan Day escribió: Federico Mena Quintero feder...@gnome.org wrote: On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote: * Unsuitability of 16x16px icons on touch screens So make them larger :) And make the bar taller in the process? I don't think that people would thank us for that. Seriously, this is not just for touch screens. Those need big targets. The target is the height of the bar. Summary - maybe bigger icons, or just contrastier ones? Use a wider top bar for touch screens? * Large width of items in the System Status area (including the user's name) taking up too much space in portrait mode How much is too much space? Do you have a screenshot that shows the problem? I have a long name but fortunately a 1600 pixel-wide screen. When I used gnome-shell on a 1024 pixel netbook it felt a bit cramped, but it was not a huge problem. Maybe if the user's full name gets over a certain percentage of the screen's width, then gnome-shell should switch to showing just the Unix username? This primarily relates to portrait mode (there's a bug for this [1]), but it could potentially affect any user if they have a smallish screen and a super long name. Hi ! From my point of view, the root of the problem comes from the touch screen dimensions (both pixels and physical size) and maybe finger size :P What about a split/combine option for the status menus. I mean, we can define when a combined menu makes sense (small touch screens or portrait mode) and when splitted menus are best suitable (bigger touch screens or non touch screen screen for example). And this can be tweaked by the user someway. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 19:55 +0200, Giovanni Campagna wrote: To me, a reasonable compromise (yet to decide if technically possible) would be to have a feature branch, that is not merged in master until after it's thoroughly user tested. And that possibly gets punted to 3.12 or never, if it turns out to be a bad idea. This looks like a good way for it to get close to no testing apart from your fellow developers. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 20:56 -0700, Andrew Potter wrote: On Mon, Apr 22, 2013 at 6:36 AM, Allan Day allanp...@gmail.com wrote: It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. One click doesn't sound too bad, but if it means launching a gnome-control-center app that takes 3+ seconds to pop-up, it might become... frustrating. Help on profiling gnome-control-center's startup would be very appreciated. We've already gotten much better with 3.8, as we use GResources for UI files, and making all the plugins builtin to the main binary (which allowed us to stop parsing all the desktop files). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 11:28 -0400, Jasper St. Pierre wrote: On Mon, Apr 22, 2013 at 11:25 AM, Bastien Nocera had...@hadess.net wrote: On Mon, 2013-04-22 at 11:18 -0400, Jasper St. Pierre wrote: I'm concerned about the automatically opening dialog thing because I'm not sure we can tell when something automatically requests network or requests network on account of the user. For instance, is an AJAX request to a website a user request or not? We don't know. It could be clicking a button in Facebook, or it could just be the site polling to see if anything new has come in. There's no possible way the browser even knows, so I don't think it's a good idea to do this. That's an edge case, and I'm not sure edge cases in the implementation should be driving the design. I'm sure we'll find a way. What's the edge case? That the user has Facebook open in a browser? How is that in any way an edge case? Because we have plenty of less complicated cases that would benefit from this feature. I would expect it to require some help from the browsers, in particular the interaction with the browsers' offline mode. In any case, the feature is not necessary to implement the combined system status menu, it just enhances it. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Allan Day (allanp...@gmail.com) said: The other day she called me as she couldn't figure out how to increase the volume. It turns out that audio was muted, and what gnome-shell shows in that case is a dark gray audio icon with a tiny little X on its corner. The dark gray icon (around 25% gray) has very little contrast with respect to its surrounding black bar (0% gray). The apparent contrast is even less since often what you have directy below the icon is the very-lightly-colored titlebar of a window (... with a white content area), so the dark gray audio icon is hard to see. Seems like an obvious bug with the volume icon - did you file a report? To echo Federico, I think it's a problem with any of the icons that use the two-tone scheme, or a problem with the tone itself rather than the icon. The 'inactive/background' dark gray used in the status indicators essentially fades into the black background when used on any angle-sensitive screen (like many laptops) - move the screen just a few degrees off the proper viewing angle and even though the rest of the display is perfectly usable, that part of the status indicators is essentially invisible. (... Could we add a microphone volume slider to the volume menu? It would be nice to have for those awkward Skype moments. And about the only other time I use the Sound Preferences capplet is when I need to boost the volume past 100% - that could very well be in the slider in gnome-shell, I guess.) We already have a microphone slider when a microphone is in use. Given we have output volume even when it's not in use, I could see having the mic volume there as well in terms of a 'show-before-you-start' paradigm. Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Hello, Any plan to add a suspend menu entry, or should we still use the undiscoverable 'alt' trick? Newer GNOME version (3.6 ?) fixed the problem of not being able to shutdown with another problem of not being able to suspend, that's not an improvement... Or did I miss something? Sorry if that was already discussed in the thread, I rekon I did not read everything. Regards, Xavier Claessens. Le lundi 22 avril 2013 à 14:36 +0100, Allan Day a écrit : Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Allan [1] https://live.gnome.org/ThreePointNine/Features/SystemStatusMenu [2] https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/#Update_Proposal -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Le lundi 22 avril 2013 à 14:36 +0100, Allan Day a écrit : Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The desktop scenario does not have any network status indicator .. even in a mobile world people do still use wired networks ;) (As I tried to tell you on IRC). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Tue, Apr 23, 2013 at 11:25 AM, Bill Nottingham nott...@redhat.com wrote: To echo Federico, I think it's a problem with any of the icons that use the two-tone scheme, or a problem with the tone itself rather than the icon. The 'inactive/background' dark gray used in the status indicators essentially fades into the black background when used on any angle-sensitive screen (like many laptops) - move the screen just a few degrees off the proper viewing angle and even though the rest of the display is perfectly usable, that part of the status indicators is essentially invisible. I've filed this as https://bugzilla.gnome.org/show_bug.cgi?id=698700 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Unfortunately, we don't have the benefit of two years of betas,
so if we implement and deliver this 3.10, there is a risk of an
impendance mismatch between what's expected from the designs and
theory behind them, and how the user effectively react. Which
would bring even more negative publicity to GNOME.
This is generally a problem of every fast releasing project with
little man power, so it affected many of the features in 3.8 and
before, but at least at time we had the validation of other
systems doing the same.
To me, a reasonable compromise (yet to decide if technically
possible) would be to have a feature branch, that is not
merged in master until after it's thoroughly user tested. And
that possibly gets punted to 3.12 or never, if it turns out to
be a bad idea.
I completrely agree.
Sorry to rant, but nobody outside this list (or maype
gnome-{design,desktop}) has been notifieied of this proposal that will
probably be merged. In fact, I think that these sorts of subtle
design-based decisions should be held in something like loomio (see
recent loomio post in desktop-devel), to be later implemented if the
response is positive. I think your suggestion of a feature branch can
be a worthy compromise, though.
--
Marco Scannadinari ma...@scannadinari.co.uk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari ma...@scannadinari.co.uk wrote: In fact, I think that these sorts of subtle design-based decisions should be held in something like loomio (see recent loomio post in desktop-devel), to be later implemented if the response is positive. And as has been mentioned on that thread, this is design by committee, which is not how it works (or should work). Yes, sometimes controversial changes are reversed at a later point, and a user vote would almost certainly have prevented the controversial change in the first place, but it would also prevent those controversial changes that turned out right - in particular, neither GNOME 2 nor GNOME 3 would have happened in the first place. I think your suggestion of a feature branch can be a worthy compromise, though. Except that Bastien is right - while on a branch, a feature will hardly be tested by anyone than other core developers of the same module. It's unfortunate, but real users generally only get to test a new feature once it appears in their distro (read: some time after the feature appears in a stable GNOME release). So a branch would either - be a polite way of rejecting a feature outright - as it doesn't get any user testing, it is never considered ready and punted from release to release - land late in the cycle when the few users (read: gnome-shell hackers) that have tested it consider it good enough to let loose on unsuspecting users At least until we get a better testing infrastructure in place, the only way to get at least *some* user testing is including it in a development release as early as possible (but only after being relatively sure that it won't kill any kittens) to get some minimal exposure to adventurous users of unstable/experimental distributions (and fellow gnomies running jhbuild sessions of course). It's far from ideal, but in contrast to artificially holding back the feature, we'd get at least some feedback (and a fair chance to address issues before it hits a stable release). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On 24 April 2013 02:14, Florian Müllner fmuell...@gnome.org wrote: On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari ma...@scannadinari.co.uk wrote: I think your suggestion of a feature branch can be a worthy compromise, though. Except that Bastien is right - while on a branch, a feature will hardly be tested by anyone than other core developers of the same module. It's unfortunate, but real users generally only get to test a new feature once it appears in their distro (read: some time after the feature appears in a stable GNOME release). A branch can be packaged as well. So one module could have two packages. One with mature UI changes. One with controversial edge UI to be tested. The edge package is to be installed by default. Still the user would have the possibility to get it replaced by the other one. This is basically making sure that we can downgrade/upgrade between two module releases, which is basically not insured for a module from two GNOME releases. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Tue, Apr 23, 2013 at 4:14 PM, Florian Müllner fmuell...@gnome.orgwrote: I think your suggestion of a feature branch can be a worthy compromise, though. Except that Bastien is right - while on a branch, a feature will hardly be tested by anyone than other core developers of the same module. It's unfortunate, but real users generally only get to test a new feature once it appears in their distro (read: some time after the feature appears in a stable GNOME release). I don't agree here at all. First all, we should be able to use ostree and create new images based on the next-gen features branch. You leave the publicizing of the images to community managers. That is what we are here for. I will take care of getting the images publicized. Create a bugzilla tag for the features branch for each component you have so these people can file bugs against it. Our infrastructure is becoming sophisticated. Use it and stress it. We didn't get all this hardware for nothing. Andrea and I will try to help out here. So a branch would either - be a polite way of rejecting a feature outright - as it doesn't get any user testing, it is never considered ready and punted from release to release - land late in the cycle when the few users (read: gnome-shell hackers) that have tested it consider it good enough to let loose on unsuspecting users You just need to have a methodology from getting from a feature branch to the stable branch. The devil is in the details, but it can be done. At least until we get a better testing infrastructure in place, the only way to get at least *some* user testing is including it in a development release as early as possible (but only after being relatively sure that it won't kill any kittens) to get some minimal exposure to adventurous users of unstable/experimental distributions (and fellow gnomies running jhbuild sessions of course). It's far from ideal, but in contrast to artificially holding back the feature, we'd get at least some feedback (and a fair chance to address issues before it hits a stable release). Again treating your user base as your user test bed is going to create some backlash. They have signed on to doing things the GNOME 3 way, don't abuse them by rapidly adding new methodologies that they have to get used to after establishing use patterns already. All of this boils down to one excuse and that is the lack of resources. By that I guess you mean you don't have enough people hacking on the core components. Because we have the hardware and an amazing systems administrator who is willing to go the extra mile. We can get more people interested in hacking the platform if we lower the bar of entry and by extension get more testers. We've made some great progress with that with OSTree and buildbot. Anyways, I'm going off topic. My two cents on this. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, 2013-04-24 at 04:00 +0300, Luc Pionchon wrote: On 24 April 2013 02:14, Florian Müllner fmuell...@gnome.org wrote: On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari ma...@scannadinari.co.uk wrote: I think your suggestion of a feature branch can be a worthy compromise, though. Except that Bastien is right - while on a branch, a feature will hardly be tested by anyone than other core developers of the same module. It's unfortunate, but real users generally only get to test a new feature once it appears in their distro (read: some time after the feature appears in a stable GNOME release). A branch can be packaged as well. So one module could have two packages. Who will package them? For which distros? With how much delay? One with mature UI changes. One with controversial edge UI to be tested. Now consider the many modules forming GNOME. Do you build the edge package of, say, GNOME Shell against the mature package of GLib? Or also against the edge of GLib? Such a solution would quickly lead to an explosion of possible combinaisons of edge/mature packages. Unless you mean that a user must install the edge package for all modules if all they want is to test the edge of GNOME Shell? If so, how is that different from just installing the 3.9 packages in a development distro? -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature proposal: combined system status menu
Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Allan [1] https://live.gnome.org/ThreePointNine/Features/SystemStatusMenu [2] https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/#Update_Proposal -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
2013/4/22 Allan Day allanp...@gmail.com: Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. It looks like all the pictures from the Research on this topic ( https://live.gnome.org/GnomeShell/Design/Research/StatusIndicators ) are missing (I'm getting a forbidden icon for each image) The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. My main concern is the detection of application needs network and how it will properly integrate without modifying all applications so they interact with NetworkManager to request I need network access. -- Frederic Crozat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote: 2013/4/22 Allan Day allanp...@gmail.com: snip However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. My main concern is the detection of application needs network and how it will properly integrate without modifying all applications so they interact with NetworkManager to request I need network access. That can be implemented as a kernel feature with a user-space helper, very much in the same way that fieryfilter, a desktop-ish firewall akin to what exists on Windows, used to do it: http://0pointer.de/lennart/projects/fieryfilter/screenshots/fieryfilter-0.2-connection.png We might even get help from the original author ;) (The code there is likely not the way it would be finally implemented, the kernel infrastructure has changed quite a bit since 2008) I also think that we'll need to have more applications, and desktop daemons making use of GNetworkMonitor to check whether they have access to the Internet before trying to access resources. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Hey Allan, first of all thanks a lot for taking the time to look into these issues 2013/4/22 Allan Day allanp...@gmail.com: Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). Sorry if this goes a bit off topic, but, is the general policy now to try to optimize for touch? I am not sure what the criteria is with this regard and I might have miss a public discussion about it. What are we trying to accomplish with this whole trend towards touch? I haven't seen any successful single UI story that works well on both touch and mouse/keyboard form factors. Again, bear with me since I might have missed compelling discussions about this design strategy. I would be more than supportive if we decided to do a tablet version of GNOME but I am slightly concerned that we are just blindly following MS/W8 and the desire of hardware manufacturers to have something new to ship. I am also concerned about the message that this sends to application developers. Should they optimize their apps for touch as well? In my experience doing an app for a touch driven device and a kbd/pointer one is quite a different deal. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. My main concern while looking at the wireframes is that this would change the fundamental way a lot of extensions work right now, specifically I'm thinking about the MPRIS2 extension in the sound menu that allows a very handy change of track or pause of your music which would be a pain if done through the activities overview or the system tray. It would be nice if we could give a heads up to the extension developers, and also, take into account that this kind of customization seems reasonable and critical for a certain chunk of our user base. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Sounds areas worth exploring, keep up the good work guys and thanks for sharing your plans on ddl! -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote: snip However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. I would make it clear that Wi-Fi networks that connect automatically (known networks) wouldn't need that popup. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
2013/4/22 Bastien Nocera had...@hadess.net: On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote: 2013/4/22 Allan Day allanp...@gmail.com: snip However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. My main concern is the detection of application needs network and how it will properly integrate without modifying all applications so they interact with NetworkManager to request I need network access. That can be implemented as a kernel feature with a user-space helper, very much in the same way that fieryfilter, a desktop-ish firewall akin to what exists on Windows, used to do it: http://0pointer.de/lennart/projects/fieryfilter/screenshots/fieryfilter-0.2-connection.png We might even get help from the original author ;) (The code there is likely not the way it would be finally implemented, the kernel infrastructure has changed quite a bit since 2008) Indeed (another solution could be to use a dnsmasq redirector to detect DNS query but it would start to be really ugly). I also think that we'll need to have more applications, and desktop daemons making use of GNetworkMonitor to check whether they have access to the Internet before trying to access resources. Yes, but as always, we can't control everything users are running on their desktop. -- Frederic Crozat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 16:01 +0200, Frederic Crozat wrote: 2013/4/22 Bastien Nocera had...@hadess.net: snip I also think that we'll need to have more applications, and desktop daemons making use of GNetworkMonitor to check whether they have access to the Internet before trying to access resources. Yes, but as always, we can't control everything users are running on their desktop. Certainly, but this kernel feature should be able to tell us which application requested network access without checking for its presence, and it's a fair feature request to ensure that network resources aren't accessed if the network isn't available. This is especially important for applications that run without a UI, or access the network without user interaction. There's a few in GNOME itself, I'm not sure there's that many third-party daemons of the sort in a typical GNOME desktop. Allan, do we have recommendations for application and OS developers on how to handle network availability? This would be a great first bug fix for a number of contributors, though I doubt that a GNOME Goal would catch all the instances. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote: Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable Just as a note, this does remove one feature I kind of like, which is the ability to change the volume by scrolling on the volume icon. I know it's minor, but I've found it useful. On the other hand, I tend to use the Advanced Volume Mixer extension[1], anyway. I don't know if it's just me, but I think some of that stuff could be useful in the default sound menu as well (such as per-stream volume/mute control). Cheers, Arun [1] https://extensions.gnome.org/extension/212/advanced-volume-mixer/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
I'm concerned about the automatically opening dialog thing because I'm not sure we can tell when something automatically requests network or requests network on account of the user. For instance, is an AJAX request to a website a user request or not? We don't know. It could be clicking a button in Facebook, or it could just be the site polling to see if anything new has come in. There's no possible way the browser even knows, so I don't think it's a good idea to do this. The other thing that I've been concerned about is that users have complained about not being able to use their password managers in our password modal dialogs. I'd like to see something that acknowledges this complaint. Otherwise, the UX of the giant dialog looks good to me, and I'm already starting to implement it. (But where's the avatar?) On Mon, Apr 22, 2013 at 9:58 AM, Bastien Nocera had...@hadess.net wrote: On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote: 2013/4/22 Allan Day allanp...@gmail.com: snip However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. My main concern is the detection of application needs network and how it will properly integrate without modifying all applications so they interact with NetworkManager to request I need network access. That can be implemented as a kernel feature with a user-space helper, very much in the same way that fieryfilter, a desktop-ish firewall akin to what exists on Windows, used to do it: http://0pointer.de/lennart/projects/fieryfilter/screenshots/fieryfilter-0.2-connection.png We might even get help from the original author ;) (The code there is likely not the way it would be finally implemented, the kernel infrastructure has changed quite a bit since 2008) I also think that we'll need to have more applications, and desktop daemons making use of GNetworkMonitor to check whether they have access to the Internet before trying to access resources. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 9:59 AM, Alberto Ruiz ar...@gnome.org wrote: Hey Allan, first of all thanks a lot for taking the time to look into these issues 2013/4/22 Allan Day allanp...@gmail.com: Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). Sorry if this goes a bit off topic, but, is the general policy now to try to optimize for touch? The rationale is to at least try and think about touch, because that's where the market is going. I don't know if it's a good idea or not. There are other factors that led to the redesign. During user testing, a lot of applicants were glued to the menus in the top right and didn't really look elsewhere for features. I am not sure what the criteria is with this regard and I might have miss a public discussion about it. What are we trying to accomplish with this whole trend towards touch? I haven't seen any successful single UI story that works well on both touch and mouse/keyboard form factors. Again, bear with me since I might have missed compelling discussions about this design strategy. I would be more than supportive if we decided to do a tablet version of GNOME but I am slightly concerned that we are just blindly following MS/W8 and the desire of hardware manufacturers to have something new to ship. I am also concerned about the message that this sends to application developers. Should they optimize their apps for touch as well? In my experience doing an app for a touch driven device and a kbd/pointer one is quite a different deal. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. My main concern while looking at the wireframes is that this would change the fundamental way a lot of extensions work right now, specifically I'm thinking about the MPRIS2 extension in the sound menu that allows a very handy change of track or pause of your music which would be a pain if done through the activities overview or the system tray. It would be nice if we could give a heads up to the extension developers, and also, take into account that this kind of customization seems reasonable and critical for a certain chunk of our user base. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Sounds areas worth exploring, keep up the good work guys and thanks for sharing your plans on ddl! -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 11:18 -0400, Jasper St. Pierre wrote: I'm concerned about the automatically opening dialog thing because I'm not sure we can tell when something automatically requests network or requests network on account of the user. For instance, is an AJAX request to a website a user request or not? We don't know. It could be clicking a button in Facebook, or it could just be the site polling to see if anything new has come in. There's no possible way the browser even knows, so I don't think it's a good idea to do this. That's an edge case, and I'm not sure edge cases in the implementation should be driving the design. I'm sure we'll find a way. The other thing that I've been concerned about is that users have complained about not being able to use their password managers in our password modal dialogs. I'd like to see something that acknowledges this complaint. It's already a problem right now (that Wi-Fi passwords are desktop-modal). Why are you (as you've already done on IRC) tying this issue together with the combined system status menu? Otherwise, the UX of the giant dialog looks good to me, and I'm already starting to implement it. (But where's the avatar?) Excellent. Is there a bug to track it? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Hi Alberto, Alberto Ruiz ar...@gnome.org wrote: The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). Sorry if this goes a bit off topic, It is a bit, so I'm moving this to a new thread. Touch compatibility is only one of a host of drivers for this proposal. I'll respond to your comments regarding the system status proposal itself in the original thread. but, is the general policy now to try to optimize for touch? I am not sure what the criteria is with this regard and I might have miss a public discussion about it. What are we trying to accomplish with this whole trend towards touch? I haven't seen any successful single UI story that works well on both touch and mouse/keyboard form factors. Again, bear with me since I might have missed compelling discussions about this design strategy. There has certainly been discussion in the past. We talked about it last GUADEC during one of the BoFs, for example. I agree that it's difficult to be completely agnostic when it comes to input devices. That said, the number of devices shipping with touch screens in combination with other input devices is on the increase. I think it would be a really bad situation if people wanted to install GNOME on their laptop, would be unable to use their touchscreen with it. So as an initial goal, I'm hoping that we'll be able to have a good form of touch compatibility, with a target of laptops with touchscreens. I don't think we have the resources to create several versions of GNOME for different types of devices. I would be more than supportive if we decided to do a tablet version of GNOME but I am slightly concerned that we are just blindly following MS/W8 and the desire of hardware manufacturers to have something new to ship. To a certain extent we do have to follow hardware manufacturers - we have no control over what they ship, and there are a lot of hybid devices out there nowadays. I am also concerned about the message that this sends to application developers. Should they optimize their apps for touch as well? In my experience doing an app for a touch driven device and a kbd/pointer one is quite a different deal. This is something where the nascent design patterns and accompanying toolkit work will help - we obviously need clear guidelines for application developers. I foresee a couple of different classes of applications when it comes to input devices - simpler applications which use the standard GNOME design patterns, and which aim to have a level of touch compatibility, and more complicated applications (like image editors, office apps, etc) which are fully targeted towards pointer driven input. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 11:25 AM, Bastien Nocera had...@hadess.net wrote: On Mon, 2013-04-22 at 11:18 -0400, Jasper St. Pierre wrote: I'm concerned about the automatically opening dialog thing because I'm not sure we can tell when something automatically requests network or requests network on account of the user. For instance, is an AJAX request to a website a user request or not? We don't know. It could be clicking a button in Facebook, or it could just be the site polling to see if anything new has come in. There's no possible way the browser even knows, so I don't think it's a good idea to do this. That's an edge case, and I'm not sure edge cases in the implementation should be driving the design. I'm sure we'll find a way. What's the edge case? That the user has Facebook open in a browser? How is that in any way an edge case? The other thing that I've been concerned about is that users have complained about not being able to use their password managers in our password modal dialogs. I'd like to see something that acknowledges this complaint. It's already a problem right now (that Wi-Fi passwords are desktop-modal). Why are you (as you've already done on IRC) tying this issue together with the combined system status menu? Otherwise, the UX of the giant dialog looks good to me, and I'm already starting to implement it. (But where's the avatar?) Excellent. Is there a bug to track it? Not yet. It's in a local branch on my system, as it's nowhere near publishable quality yet. -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Part two of my reply. :) Alberto Ruiz ar...@gnome.org wrote: ... More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. My main concern while looking at the wireframes is that this would change the fundamental way a lot of extensions work right now, specifically I'm thinking about the MPRIS2 extension in the sound menu that allows a very handy change of track or pause of your music which would be a pain if done through the activities overview or the system tray. Extension authors can still add their own menus. They could even relocate the volume sliders to a standalone sound menu if they wanted. It would be nice if we could give a heads up to the extension developers, and also, take into account that this kind of customization seems reasonable and critical for a certain chunk of our user base. This is one reason why I am publicising this effort early in the release cycle. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Sounds areas worth exploring, keep up the good work guys and thanks for sharing your plans on ddl! np. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Jasper St. Pierre jstpie...@mecheye.net wrote: Otherwise, the UX of the giant dialog looks good to me, and I'm already starting to implement it. (But where's the avatar?) Avatar? Excellent. Is there a bug to track it? Not yet. It's in a local branch on my system, as it's nowhere near publishable quality yet. Bear in mind that this is one of the aspects of the design that might change a bit. One thing we might need is a mechanism to connect to mobile broadband, for example... Anyway, great to hear that you've started work on this! I'll do some more work on the design asap. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote: The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. The update proposal [1] lists the following items as problems, but it doesn't say *why* they are problems. I'll comment: * Privacy issues with having the user's name in the top bar Why is this a privacy concern? If you already have someone looking over your shoulder, they can see a lot more than your username... including you typing passwords. * Unsuitability of 16x16px icons on touch screens So make them larger :) Seriously, this is not just for touch screens. Those need big targets. But on non-touch screens, some people like my mom (whose eyesight is not so great these days) could also benefit from bigger icons, or at least *more contrasty* icons. The other day she called me as she couldn't figure out how to increase the volume. It turns out that audio was muted, and what gnome-shell shows in that case is a dark gray audio icon with a tiny little X on its corner. The dark gray icon (around 25% gray) has very little contrast with respect to its surrounding black bar (0% gray). The apparent contrast is even less since often what you have directy below the icon is the very-lightly-colored titlebar of a window (... with a white content area), so the dark gray audio icon is hard to see. Summary - maybe bigger icons, or just contrastier ones? Use a wider top bar for touch screens? * Large width of items in the System Status area (including the user's name) taking up too much space in portrait mode How much is too much space? Do you have a screenshot that shows the problem? I have a long name but fortunately a 1600 pixel-wide screen. When I used gnome-shell on a 1024 pixel netbook it felt a bit cramped, but it was not a huge problem. Maybe if the user's full name gets over a certain percentage of the screen's width, then gnome-shell should switch to showing just the Unix username? Also... just move the clock to the left and that will give you more space for the status area. Here it is, roughly centered between the app menu and the leftmost status icon. To me it looks nicer than centered on the screen - it's a local symmetry: http://people.gnome.org/~federico/misc/centered.png * Difficult to have icons in the top bar that do not have an associated menu (eg. airplane mode) If gnome-shell just assumes that all icons must have a menu, then this is just an implementation detail. * Difficult to have items in the menus that do not have an appropriate top bar icon (eg. screen brightness) Two questions: 1. Do we need absolutely every hardware-y parameter to be adjustable from the top bar? (Not trying to be confrontational here - I use the hardware keys for screen brightness because they are there and they work, but I use the volume icon in the shell because a) it works, unlike the hardware keys, and b) adjusting the volume with the scrollwheel is really nice.) 2. Instead of putting *everything* in a single menu like in the wireframes [2], wouldn't it be better to split them into hardware-y things and user-y things? (I personally think the current implementation is very clear and clean - volume things under the volume icon, user/session things under my username.) Putting everything in the same menu doesn't sound like a good idea. * Some menus essentially have one item in them (eg. battery, volume) Why is this a problem? (... Could we add a microphone volume slider to the volume menu? It would be nice to have for those awkward Skype moments. And about the only other time I use the Sound Preferences capplet is when I need to boost the volume past 100% - that could very well be in the slider in gnome-shell, I guess.) (... If the problem of not being able to have icons without menus is solved, then clicking the Battery icon could just take you to the power capplet.) * Inconsistency between lock/login screens and the session I wasn't even aware of the inconsistency. Can the lock screen simply have the username and icons on the same place as the session? Like this: http://people.gnome.org/~federico/misc/lock.png As side comments to the lock screen... I can understand having Volume there (screensaver activates while listening to something; I still want to be able to adjust the volume). The battery is for oh, the screen is locked but I guess I should plug the laptop soon. What is Network there for? Apart from all that: I like the idea of a separate dialog to choose a wifi network. The current menu is just unreliable: * More... sometimes makes the menu narrower, and the leave the top five as they are, and put the rest in a scrollable sub-menu just looks weird. * If you are looking at the menu trying to decide on which AP to use, the menu closes on you when NetworkManager refreshes the list of APs (?). (In general, those menus-that-can-expand-subsections seem to need implementation love.) I'm not sure
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
2013/4/22 Allan Day allanp...@gmail.com: Hi Alberto, Alberto Ruiz ar...@gnome.org wrote: The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). Sorry if this goes a bit off topic, It is a bit, so I'm moving this to a new thread. Touch compatibility is only one of a host of drivers for this proposal. Good call There has certainly been discussion in the past. We talked about it last GUADEC during one of the BoFs, for example. I agree that it's difficult to be completely agnostic when it comes to input devices. That said, the number of devices shipping with touch screens in combination with other input devices is on the increase. I think it would be a really bad situation if people wanted to install GNOME on their laptop, would be unable to use their touchscreen with it. Sure, loads of those being shipped. However we have to question ourselves if this is another trend like the netbook one that is somewhat transient and misleading. Loads of those are shipping with touch screens because of Windows 8, but we have to question ourselves if it does make sense to have both touchpad and touchscreens on the same device. I'd make a distinction here between transformers (Docable tablet that turns into a laptop+trackpad) that switches between touch mode and keyboard/pointer mode. My question is, do we have data that backs up the notion that people actually want a touch screen in their laptops? Or is this just the OEMs following Windows 8 in the hope that they will sell more units? So as an initial goal, I'm hoping that we'll be able to have a good form of touch compatibility, with a target of laptops with touchscreens. I don't believe there will be a single UI for both form factors. I can see value in having the ability to switch from tablet to PC with the same device as long as the application set is different and only apps shipped for each form factor are shown on each mode. I don't think we have the resources to create several versions of GNOME for different types of devices. Wasn't implying that we do, I'm just saying that I'd be supportive of such thing to make it clear that I don't have anything against touch-driven devices. To a certain extent we do have to follow hardware manufacturers - we have no control over what they ship, and there are a lot of hybid devices out there nowadays. I understand that point, I am just concerned about how much stuff that would make a great design for keyboard+pointer are we giving up to be touch friendly. I am afraid that if we go down that route we will end up with a not so great touch UI and a not so great keyboard+pointer UI. If it was up to me I would stick to be a great UI for what people knows and will keep using for as long as we are a keyboard+pointer desktop when it came to design criteria. But that's just me, I am just trying to have valuable conversation about this and making sure I understand what's in your mind moving forward. I am also concerned about the message that this sends to application developers. Should they optimize their apps for touch as well? In my experience doing an app for a touch driven device and a kbd/pointer one is quite a different deal. This is something where the nascent design patterns and accompanying toolkit work will help - we obviously need clear guidelines for application developers. I foresee a couple of different classes of applications when it comes to input devices - simpler applications which use the standard GNOME design patterns, and which aim to have a level of touch compatibility, and more complicated applications (like image editors, office apps, etc) which are fully targeted towards pointer driven input. My problem with that approach is that you are somewhat giving users notion that they can use the desktop with a touch interface, and as long as you try to use a more complex app that ability goes away, that's ought to be frustrating. -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Federico Mena Quintero feder...@gnome.org wrote: On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote: The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. The update proposal [1] lists the following items as problems, but it doesn't say *why* they are problems. I'll comment: * Privacy issues with having the user's name in the top bar Why is this a privacy concern? If you already have someone looking over your shoulder, they can see a lot more than your username... including you typing passwords. We've had direct user feedback when doing testing that this is an issue. People don't like their name being on display, particularly in public places. * Unsuitability of 16x16px icons on touch screens So make them larger :) And make the bar taller in the process? I don't think that people would thank us for that. Seriously, this is not just for touch screens. Those need big targets. The target is the height of the bar. But on non-touch screens, some people like my mom (whose eyesight is not so great these days) could also benefit from bigger icons, or at least *more contrasty* icons. Dude, they couldn't have any more contrast. The other day she called me as she couldn't figure out how to increase the volume. It turns out that audio was muted, and what gnome-shell shows in that case is a dark gray audio icon with a tiny little X on its corner. The dark gray icon (around 25% gray) has very little contrast with respect to its surrounding black bar (0% gray). The apparent contrast is even less since often what you have directy below the icon is the very-lightly-colored titlebar of a window (... with a white content area), so the dark gray audio icon is hard to see. Seems like an obvious bug with the volume icon - did you file a report? Summary - maybe bigger icons, or just contrastier ones? Use a wider top bar for touch screens? * Large width of items in the System Status area (including the user's name) taking up too much space in portrait mode How much is too much space? Do you have a screenshot that shows the problem? I have a long name but fortunately a 1600 pixel-wide screen. When I used gnome-shell on a 1024 pixel netbook it felt a bit cramped, but it was not a huge problem. Maybe if the user's full name gets over a certain percentage of the screen's width, then gnome-shell should switch to showing just the Unix username? This primarily relates to portrait mode (there's a bug for this [1]), but it could potentially affect any user if they have a smallish screen and a super long name. Also... just move the clock to the left and that will give you more space for the status area. Here it is, roughly centered between the app menu and the leftmost status icon. To me it looks nicer than centered on the screen - it's a local symmetry: http://people.gnome.org/~federico/misc/centered.png It needs to be centered - the screen will feel totally off kilter if you move it. * Difficult to have icons in the top bar that do not have an associated menu (eg. airplane mode) If gnome-shell just assumes that all icons must have a menu, then this is just an implementation detail. So we pop up yet another menu with a single item in it? Not only would yet another menu with a single item in it be sucky, but it would have an awkward (if not broken) relationship with the existing networking panel. * Difficult to have items in the menus that do not have an appropriate top bar icon (eg. screen brightness) Two questions: 1. Do we need absolutely every hardware-y parameter to be adjustable from the top bar? Obviously not, and we don't. (Not trying to be confrontational here - I use the hardware keys for screen brightness because they are there and they work, but I use the volume icon in the shell because a) it works, unlike the hardware keys, and b) adjusting the volume with the scrollwheel is really nice.) Controls for screen brightness are a nice thing to have. For many people, it is more convenient and discoverable than the keyboard. 2. Instead of putting *everything* in a single menu like in the wireframes [2], wouldn't it be better to split them into hardware-y things and user-y things? (I personally think the current implementation is very clear and clean - volume things under the volume icon, user/session things under my username.) Putting everything in the same menu doesn't sound like a good idea. Putting everything in the same menu is inaccurate. Some things are being combined. Many other things are being moved to other parts of the UI. * Some menus essentially have one item in them (eg. battery, volume) Why is this a problem? It's not a huge problem, but it's not fantastic either. General rule of thumb for menus is to only have one if you have three or more items [2]. (... Could we add a microphone volume slider to the volume menu? It would be nice to have
Re: Feature proposal: combined system status menu
On 22 April 2013 19:57, Allan Day allanp...@gmail.com wrote: Federico Mena Quintero feder...@gnome.org wrote: On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote: But on non-touch screens, some people like my mom (whose eyesight is not so great these days) could also benefit from bigger icons, or at least *more contrasty* icons. Dude, they couldn't have any more contrast. The two most contrasting colors are yellow and black ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 11:57 AM, Allan Day allanp...@gmail.com wrote: But on non-touch screens, some people like my mom (whose eyesight is not so great these days) could also benefit from bigger icons, or at least *more contrasty* icons. Dude, they couldn't have any more contrast. Well, they could. It sounds like your mom might benefit from High Contrast, Federico, although afaik it doesn't affect the icons in the shell. The magnifier's contrast settings do; maybe try that? The other day she called me as she couldn't figure out how to increase the volume. It turns out that audio was muted, and what gnome-shell shows in that case is a dark gray audio icon with a tiny little X on its corner. The dark gray icon (around 25% gray) has very little contrast with respect to its surrounding black bar (0% gray). The apparent contrast is even less since often what you have directy below the icon is the very-lightly-colored titlebar of a window (... with a white content area), so the dark gray audio icon is hard to see. Seems like an obvious bug with the volume icon - did you file a report? This isn't a bug. He's talking about the fact that the titlebars of the windows are light-colored, and therefore the icon colors seem less distinct in comparison. Meg Ford ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
2013/4/22 Allan Day allanp...@gmail.com Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Hi Allan, and thank you for letting us know of this plan. As one of the implementors of the current status icons, and current developer of gnome-shell, I can tell it's a small can of worms, but that's not what this is about. Rather, what I'd like to point out is that, in my opinion, this needs more thinking through before going straight to shipping. I mean, I trust the design team and I value your experience in the field, but this is another radical change, and it's quite different from our competitors. Unfortunately, we don't have the benefit of two years of betas, so if we implement and deliver this 3.10, there is a risk of an impendance mismatch between what's expected from the designs and theory behind them, and how the user effectively react. Which would bring even more negative publicity to GNOME. This is generally a problem of every fast releasing project with little man power, so it affected many of the features in 3.8 and before, but at least at time we had the validation of other systems doing the same. To me, a reasonable compromise (yet to decide if technically possible) would be to have a feature branch, that is not merged in master until after it's thoroughly user tested. And that possibly gets punted to 3.12 or never, if it turns out to be a bad idea. Giovanni ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Hi Allen, I appreciate the opportunity to give feeedback on this. Thank you. On Mon, Apr 22, 2013 at 6:36 AM, Allan Day allanp...@gmail.com wrote: It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that This is problematic is for those of us who use VPN or conciously switch networks a lot. it is in fact quite surprising how often I hit the network menu especially as a VPN user. If you're a person who travels a lot this might be inconvenient. Certainly, for me it would be inconvenient since I hit the VPN several times a day and that would require many clicks to get to the network dialog box and then go to the vpn screen. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 8:29 AM, Allan Day allanp...@gmail.com wrote: Part two of my reply. :) Alberto Ruiz ar...@gnome.org wrote: ... More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. My main concern while looking at the wireframes is that this would change the fundamental way a lot of extensions work right now, specifically I'm thinking about the MPRIS2 extension in the sound menu that allows a very handy change of track or pause of your music which would be a pain if done through the activities overview or the system tray. Extension authors can still add their own menus. They could even relocate the volume sliders to a standalone sound menu if they wanted. That would kind of defeat the purpose right? It should be good enough so that extension writers don't have to do a end run around on the design. Otherwise, a lot of people would just end up using this instruction and ignoring all your hard work. Per my VPN issue, I would certainly end up installing this extension because it's just too convenient. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 8:10 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: This is problematic is for those of us who use VPN The mockup[0] linked from the proposal shows VPN(s) directly in the menu when a VPN has been set up. Non-issue? [0] https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/combined-system-status-menu.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Hey Giovanni! Giovanni Campagna scampa.giova...@gmail.com wrote: As one of the implementors of the current status icons, and current developer of gnome-shell, I can tell it's a small can of worms, but that's not what this is about. Rather, what I'd like to point out is that, in my opinion, this needs more thinking through before going straight to shipping. I mean, I trust the design team and I value your experience in the field, but this is another radical change, and it's quite different from our competitors. Unfortunately, we don't have the benefit of two years of betas, so if we implement and deliver this 3.10, there is a risk of an impendance mismatch between what's expected from the designs and theory behind them, and how the user effectively react. Which would bring even more negative publicity to GNOME. This is generally a problem of every fast releasing project with little man power, so it affected many of the features in 3.8 and before, but at least at time we had the validation of other systems doing the same. To me, a reasonable compromise (yet to decide if technically possible) would be to have a feature branch, that is not merged in master until after it's thoroughly user tested. And that possibly gets punted to 3.12 or never, if it turns out to be a bad idea. Yeah, I'm aware that we need to tread carefully. I've actually spent quite a while sitting on these mockups, revisiting them and challenging them with different scenarios - you will also notice that they are pretty detailed. So yes, I'm in agreement with you about pushing this prematurely. Working in a branch seems like it could be a good solution. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 11:17 AM, Florian Müllner fmuell...@gnome.orgwrote: On Mon, Apr 22, 2013 at 8:10 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: This is problematic is for those of us who use VPN The mockup[0] linked from the proposal shows VPN(s) directly in the menu when a VPN has been set up. Non-issue? [0] https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/combined-system-status-menu.png Thanks, I must have missed it. I did peruse it and it's still an extra click and misses the convenience of going to the network menu and hitting vpn on. If you're doing a lot of it I can see it getting a little irritating. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Sriram Ramkrishna s...@ramkrishna.me wrote: Thanks, I must have missed it. I did peruse it and it's still an extra click and misses the convenience of going to the network menu and hitting vpn on. If you're doing a lot of it I can see it getting a little irritating. Yep, that's a downside of the plan. As always, it's about pros and cons. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Giovanni I second your message. There are a few things in Gnome3.8 that need to be standard and not tweaked. a) User should be able to reset Frequent, or at least purge entries therein. I do it by deleting the users .hidden files. But that is not the way. b) In testing Gnome3.8, I ignore Frequent, and only use ALL. (It saves me 1 mouse click, and come tendonitus.). I scroll once, instead of searchng FREQUENT, and then researching ALL. When we add desktop applications (say another two dozen) to the system, scrolling the ALL section means via mouse, requires a lot of activity and searching to find the program we want. C) The categories (programming, system, applications, as was in 3.6, was a great way to reduce mouse clicking. Developers have to consider how fatiguing it is to use the mouse with Gnome3.x (Yes there are tweaks, but I can;t do an install of multiple desktops if I have to manually install tweaks for each one). d) In a future release.. Please allow us to create our own tags, and use them to search against them. . e) Gnome 3.8 and the split window feature (extreme slide left or slide right) is great. Congratulations to the developer(s). Regards Leslie Mr. Leslie Satenstein 50 years in Information Technology and going strong. Yesterday was a good day, today is a better day, and tomorrow will be even better.mailto:lsatenst...@yahoo.com alternative: leslie.satenst...@gmail.com SENT FROM MY OPEN SOURCE LINUX SYSTEM. --- On Mon, 4/22/13, Allan Day allanp...@gmail.com wrote: From: Allan Day allanp...@gmail.com Subject: Re: Feature proposal: combined system status menu To: Giovanni Campagna scampa.giova...@gmail.com Cc: desktop-devel-list desktop-devel-list@gnome.org Date: Monday, April 22, 2013, 2:18 PM Hey Giovanni! Giovanni Campagna scampa.giova...@gmail.com wrote: As one of the implementors of the current status icons, and current developer of gnome-shell, I can tell it's a small can of worms, but that's not what this is about. Rather, what I'd like to point out is that, in my opinion, this needs more thinking through before going straight to shipping. I mean, I trust the design team and I value your experience in the field, but this is another radical change, and it's quite different from our competitors. Unfortunately, we don't have the benefit of two years of betas, so if we implement and deliver this 3.10, there is a risk of an impendance mismatch between what's expected from the designs and theory behind them, and how the user effectively react. Which would bring even more negative publicity to GNOME. This is generally a problem of every fast releasing project with little man power, so it affected many of the features in 3.8 and before, but at least at time we had the validation of other systems doing the same. To me, a reasonable compromise (yet to decide if technically possible) would be to have a feature branch, that is not merged in master until after it's thoroughly user tested. And that possibly gets punted to 3.12 or never, if it turns out to be a bad idea. Yeah, I'm aware that we need to tread carefully. I've actually spent quite a while sitting on these mockups, revisiting them and challenging them with different scenarios - you will also notice that they are pretty detailed. So yes, I'm in agreement with you about pushing this prematurely. Working in a branch seems like it could be a good solution. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 22.04.13 15:58, Bastien Nocera (had...@hadess.net) wrote: On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote: 2013/4/22 Allan Day allanp...@gmail.com: snip However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. My main concern is the detection of application needs network and how it will properly integrate without modifying all applications so they interact with NetworkManager to request I need network access. That can be implemented as a kernel feature with a user-space helper, very much in the same way that fieryfilter, a desktop-ish firewall akin to what exists on Windows, used to do it: http://0pointer.de/lennart/projects/fieryfilter/screenshots/fieryfilter-0.2-connection.png We might even get help from the original author ;) (The code there is likely not the way it would be finally implemented, the kernel infrastructure has changed quite a bit since 2008) Hmm, this gives me a bit of a headache... Hooking this into the firewall sounds like a questionabble place. We probably want something where we can get notifications about any unroutable, locally generated traffic, and we'd need meta data such as the PID for it, and we don't want to change the routing decision for it. I am not sure we could hack this up with the firewall... But humm, something to think about, and see whether some other place in the IP stack might provide us with what we need for this... Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 22.04.13 14:36, Allan Day (allanp...@gmail.com) wrote: Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. This all looks so ... crowded in the wireframes. So very very crowded. That can't be good? I understand that much of this is not supposed to be shown when not in use, but this does open a lot of questions to me. i.e. you have to figure out what in use means, i.e. for audio you probably have to think about some latency after each action that audio is still considered in use, and what about the usecase, where I am in a presentation at a conference and somebody sends me a video, and i want to see it, but want to turn off audio first, so that nobody notices that i watch a video rather than watch the speaker? And regarding the networking thing: if you want to show the networking bit only when traffic is required, then you create a chicken and egg problem, where the first network operation of an app will always fail, because you use it as a trigger but can't offer the network immeidately yet... So, I see tons of problems coming up when you try to be context sensitive... You need a lot of magic where you have to anticipate actions of the user before he actually does them. Because the user might want to change the volume *before* playing audio, and set up the network *before* doing something, and so on and so on... Also, if this menu shows when we are in airplane mode, and I presumably can use it to get out of airplane mode: how do i actually get into airplane mode if the option isn't shown then? But first and foremost, this all looks so crowded. Looks more like some feature-loaded KDE menu to me, rather then a minimalistic GNOME menu... Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Lennart Poettering mzta...@0pointer.de wrote: This all looks so ... crowded in the wireframes. So very very crowded. That can't be good? First of all, did you look at the example scenarios? On my current machine, the user menu has 6 items, with the avatar, user name and chat status on top. With the new design, I would have 6 items with two sliders on top - so essentially the same thing, yet without the added complexity of separate menus for volume, network and power. So actually, the result would be much less crowded and much cleaner. I understand that much of this is not supposed to be shown when not in use, but this does open a lot of questions to me. i.e. you have to figure out what in use means, i.e. for audio you probably have to think about some latency after each action that audio is still considered in use, and what about the usecase, where I am in a presentation at a conference and somebody sends me a video, and i want to see it, but want to turn off audio first, so that nobody notices that i watch a video rather than watch the speaker? Audio output is always present. For microphones, there will be no change from the current volume menu behavour. And regarding the networking thing: if you want to show the networking bit only when traffic is required, then you create a chicken and egg problem, where the first network operation of an app will always fail, because you use it as a trigger but can't offer the network immeidately yet... There's no reason why we have to do this in response to actual attempts to access the network, but I'm not the best person to discuss that. ;) So, I see tons of problems coming up when you try to be context sensitive... You need a lot of magic where you have to anticipate actions of the user before he actually does them. Because the user might want to change the volume *before* playing audio, and set up the network *before* doing something, and so on and so on... Again, output volume will always be displayed. Wi-fi will always be displayed in the menu too - you can always select the entry to reach the relevant settings panel. Also, if this menu shows when we are in airplane mode, and I presumably can use it to get out of airplane mode: how do i actually get into airplane mode if the option isn't shown then? Same as now - through the control center. But first and foremost, this all looks so crowded. Looks more like some feature-loaded KDE menu to me, rather then a minimalistic GNOME menu... Again, in most cases this will be less crowded than the current version. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 1:55 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: Rather, what I'd like to point out is that, in my opinion, this needs more thinking through before going straight to shipping. I mean, I trust the design team and I value your experience in the field, but this is another radical change, and it's quite different from our competitors. I don't think anybody will argue against doing careful design and testing, but I don't think this particular argument holds much water. Quite the contrary, this all-in-one status menu is quite similar to what you find eg on the Android-based Galaxy Note. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Matthias Clasen matthias.cla...@gmail.com wrote: Rather, what I'd like to point out is that, in my opinion, this needs more thinking through before going straight to shipping. I mean, I trust the design team and I value your experience in the field, but this is another radical change, and it's quite different from our competitors. I don't think anybody will argue against doing careful design and testing, but I don't think this particular argument holds much water. Quite the contrary, this all-in-one status menu is quite similar to what you find eg on the Android-based Galaxy Note. It also has similarities with ChromeOS and WebOS... Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, Apr 22, 2013 at 2:24 PM, Matthias Clasen matthias.cla...@gmail.comwrote: On Mon, Apr 22, 2013 at 1:55 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: Rather, what I'd like to point out is that, in my opinion, this needs more thinking through before going straight to shipping. I mean, I trust the design team and I value your experience in the field, but this is another radical change, and it's quite different from our competitors. I don't think anybody will argue against doing careful design and testing, but I don't think this particular argument holds much water. Quite the contrary, this all-in-one status menu is quite similar to what you find eg on the Android-based Galaxy Note. True. But Android Galaxy Note has a lot of different use cases than a desktop/laptop. In general, Note expects touch as opposed to a keyboard/mouse. Also the combinations of hardware both visual and input is a lot more diverse on a laptop/desktop than Android. I don't think it would be out of bounds to create a separate branch for testing before putting it out there. It is a very intrusive UI change and we are providing no way to go back to the old way to allow people to get used to the change. I don't really want to antoganize users by dropping things into their lap and ask them to adjust yet again to new flow that hasn't had more sandbox testing. Even if it is going to take longer to get it out there it's not particularly broken today, right? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
