Re: Tabbed windows in Mutter/Metacity
On Mon, 2009-07-13 at 00:29 +0200, Reinout van Schouwen wrote: Op dinsdag 07-07-2009 om 09:18 uur [tijdzone -0400], schreef Sam H: I would like to implement support for tabbed windows in Mutter, and was hoping for some helpful pointers. I envision tabbed windows working essentially the same way that tabs work in Google Chrome. However, being part of the window-manager, every application would make use of tabs without having to re-invent them specifically for that application. It has always struck me that tabs were something that belonged into the window manager, not in browsers, terminals, editors, etc. If you can pull this off, you will be my personal hero! (I would advise you to look at the current open bugs against GtkNotebook, though, to get an idea of what kind of functionality is currently missing and what UI dilemma's you will be facing.) Information on current implementations of tabs in GNOME can be found here: http://live.gnome.org/UsabilityProject/Whiteboard/TabImplementation A list of bugs relating to tabs (particularly UI issues) can be found here: http://live.gnome.org/UsabilityProject/Whiteboard/TabImplementation/TabBugs Hope that's of help. Allan -- aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tabbed windows in Mutter/Metacity
On Mon, 2009-07-13 at 12:33 +0100, Calum Benson wrote: On 7 Jul 2009, at 14:18, Sam H wrote: Hey all, I would like to implement support for tabbed windows in Mutter, and was hoping for some helpful pointers. I envision tabbed windows working essentially the same way that tabs work in Google Chrome. However, being part of the window-manager, every application would make use of tabs without having to re-invent them specifically for that application. It has always struck me that tabs were something that belonged into the window manager, not in browsers, terminals, editors, etc. There was a discussion a while back on the gnome developers list that expected gnome's window manager to have tabbed windows in the future. I believe that with the advent of compositing in Mutter/Metacity, now is a good time to finally make this happen. I'd love to see us at least investigate this possibility, even if we just get to the mockup stage and decide it's going to be too clunky to continue. I have no idea right now how it would look, or how it would integrate with gnome-shell, but I'd be happy to help out on the usability side of things however I can. Cheeri, Calum. Calum - agreed. I'd also be happy to help. You would need to figure out how this would work in relation to the window management features of GNOME Shell to do a proper job of this. I know that some of the people involved with that project have some ideas about tabbed interfaces. You might want to get on the GNOME Shell IRC channel and/or mailing list to talk it through with them. Allan -- aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
2. The much touted homogeneity and consistent quality of GNOME is (imho) largely a thing of the past. There have been no organized UI reviews of new modules in a long time, the HIG has not been updated to match the UIs we see in current applications. Something we should fix? I think so! Agreed. Quite a bit of work was done on reviewing Deja Dup's UI after it applied for module inclusion [1]. That review wasn't 'organised' as such, and it wasn't particularly integrated into the module inclusion process (my bad), but it did happen. We can work to develop that side of things if that's what people want to do. As for the HIG [2], I'm confident that we will have a substantial portion of it finished for 3.0. Allan [1] http://live.gnome.org/DejaDup/Design/Review-2010-05 [2] http://live.gnome.org/UsabilityProject/HIG/ -- GoogleTalk: allanpday AT gmail DOT com IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, 2011-01-04 at 10:36 +0100, Johannes Schmid wrote: Hi Christopher! Besides... did modularity ever enslave a GNOME developer? Never. I expected more than a statement like that. This modularity prevents to create a solid user experience in various ways because everything needs to be compatible with random components that cannot even be tested properly. It also makes high-quality, cutting-edge design extremely difficult (if not impossible). Besides if the design doesn't Just Work, then we've failed anyway: 99% of users will never customise their panel, let alone change WM. Also, remember that GNOME Shell has a bunch of design requirements that weren't made of the GNOME 2 desktop: an expanded range of target hardware (netbooks, tablets, etc), embedded messaging, more nuanced and stylish visuals. You can't fulfill all of these new requirements *and* cater to all the old ones too. The game has changed, and switching WM or a UI for panel customisation doesn't fit into that new game. There will undoubtedly be GNOME 3 users who miss the ability to switch their window manager or rearrange their panels. I'm sure that nobody involved with GNOME 3 wants to alienate them. Let's be clear to those users: we want you to use GNOME 3, and we're sorry that you'll miss some of the things you've got used to in GNOME 2. But times have changed, and we want GNOME to be a competitive mass market product. There really wasn't much of a choice. Even if you do miss some things about GNOME 2, though, we still think that GNOME 3 has enough exciting new features to make it worth the switch. Besides, GNOME Shell actually has some pretty advanced features for those who want to tinker. Theming seems to be pretty easy, and Shell plugins can do exciting things. It's just that that side of things hasn't got going yet. Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
I don't see gnome-applets as part of GNOME 3. But it doesn't mean we cannot ship gnome-applets 3.x. GNOME 3 is about gnome-shell. Gnome-applets will always be a fallback. A fallback which includes gnome-applets would be nice. But it is a still fallback. So the statement: gnome 3 is not going to include them is wrong. I already mentioned I expect a gnome-applets 3.x during GNOME 3.2 timeframe. However, officially it will stay as a fallback. Meaning: If you want to develop something for GNOME 3, it should be an extension to gnome-shell, not an applet. This is an important point, and I totally agree. To users, GNOME 3 should be GNOME Shell. Correspondingly, GNOME panel will need to be communicated as the GNOME 2 (or fallback) interface. GNOME Shell will be the thing that is most different to users, and GNOME Shell + the default GNOME 3 wallpaper will be a big part of our visual identity, which will be crucial for marketing. Though there will be 3.x releases of gnome-panel and friends, we need to be very clear that they are not part of the GNOME 3 experience. Basically, we need to distinguish between GNOME 3 as a UI and GNOME 3.x as a release series. Which is what Olav was saying originally, of course. :) As an aside: I'd just like to say that I agree with what Emmanuelle, Johannes and Olav have been saying on this list in the past few days. There's been a lot of negative energy around here recently. Change is difficult. Change in the open is even more difficult. But let's not forget everything that we've achieved, and let's look forward to what *is* going to be a great release. Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
Assume this: - Power-User - using Compiz/Sawfish/Whatever - wants to use Compiz/Sawfish/Whatever with GNOME-Shell as he likes both What now? You said that you would like them to stay at GNOMEs, but how do you want to achieve that? (that's a serious question!). By making GNOME 3 the best desktop out there, and by providing other customisation options for those who like to tinker. Especially since other WMs in other setups than the default might beat Mutter easily and therefore the latter won't be a suitable choice. Well GNOME2 did allow that, while GNOME3 doesn't. No, you can't change the WM in GNOME 3, but it will make up for that by being better than GNOME 2 in many, many ways: * beautiful visuals and animations * built-in messaging * refined, elegant interaction model * graphical window switching * visual simplicity and lack of clutter * overview search allows super fast keyboard-only app launching and switching, opening locations, etc * no horrible nested menus for application launching * snazzy tiled windows * effective use of hot-corners (muscle memory FTW!) * enhanced workspaces UI * notifications which are both subtle and persistent * compatible with touch screens and a range of form factors * simplified and easy to understand system settings * cool (still to be utilised) possibilities for customisation ... * and many really awesome enhancements as 3.x progresses So you can choose that, or you can choose to stick with GNOME 2, or you can even choose some other DE. I personally think you should choose GNOME 3, because I think it will be superior to everything else that's out there, and because I want both existing and new users to enjoy using GNOME. But it's your choice. I'm sorry if that's a tough choice for you, but I honestly think that this path is inevitable if GNOME is to have genuine mass appeal. Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Shell UX validation [Was: My thoughts on fallback mode]
Well, now that people are throwing percents at each other, it is a very interesting point as such - does anybody know anything about userbase whose experience GNOME3 is going to improve? I am not ranting/trolling here, I am really interested. Was there any research made? There is an evidence base that has been utilised and developed during the shell design process: * The shell design is a response to well documented issues with GNOME 2 and similar interfaces. (We can extrapolate a lot from what other OSs are doing here.) * Jon did a pretty extensive literature review (some of that can be found here [1])... I'm sure he can tell you more about the results of that. * The shell has been used extensively by its developers, designers and community members. Some have inevitably complained after using the shell, but there are also a lot of people who prefer it over GNOME 2 (myself included). * Previous studies and experiences which have been drawn upon by the shell designers. * Stock usability principles and knowledge have been routinely referred to. * I recently conducted a small usability study on the shell (results to be published soon). It established that the basics of the shell UI essentially work. It was a sanity check, nothing more. But the shell passed. The shell design wasn't formulated on a whim. It involved a lot of research and a lot of work. I know from working with Jon, Jimmac and others that empirical reference points have been sought whenever possible, and many options have been explored (and discarded) during the design process. I realize that my references to voting on linux.org.ru cannot be seriously considered - but perhaps someone made serious usability testing or survey, someone could say XX% are not happy, YY% are not happy with GNOME2 (of course, ZZ% do not care at all or not using gnome), the first figure is going to increase with GNOME3 to XY%, the second will drop as low as YX%? User attitudes or opinions are not the best guide for measuring the effectiveness of a user interface. We can test usability (though the resources for doing so are limited), and we can explore user experience (ditto), but it's very difficult to get a definitive answer through research. That kind of research, if properly made, is usually a conclusive argument for/against any serious visible design changes. I am personally convinced that GNOME Shell offers an improved user experience over GNOME 2. It avoids a whole bunch of mistakes from the past, adds useful features that are relevant to contemporary users, it will be more visually attractive, and it is better suited to today's screens and input devices. And we know from my study and from dog fooding that it works. Allan [1] http://live.gnome.org/GnomeShell/Design/References#Articles -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Cantarell? (Was: Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement))
Given recent discussions regarding the use of this list, I'm unsure whether I should be responding to this question here. That said, I do want to ensure that people get answers to queries like this. Andrew Cowie wrote: On Mon, 2011-01-10 at 12:33 -0500, Owen Taylor wrote: * The default font will be changing to Cantarell Cantarell? If Cantarell is this, http://abattis.org/cantarell/ which says As my very first typeface design... designed for on-screen reading; in particular, reading web pages on an HTC Dream mobile phone ... font file currently contains 391 glyphs then at first glance it seems an odd choice. DejaVu serves us well with outstanding coverage across the Unicode space and one of the only fonts with complimentary Serif, Sans, and Sans Mono families. Do we need to replace it? It's not a question of coverage; it's about style (though we need to use fonts that have good coverage, of course). The visual style that has been developed for GNOME 3 is one that aspires to be subtle and refined. Stylistically, Cantarell accords with that in a way that DejaVu does not. Another aim for GNOME 3 is to ensure that the new desktop is visually distinctive. Cantarell is a better choice than DejaVu here, too. I'm really excited that we're using this new font for GNOME 3; it has a really nice design and will give the new desktop an extra bit of sophistication. Allan -- Blog: https://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fanza Icon Set
Hi Nick, This probably isn't the best list for this discussion though, to be fair, I don't know which one would be... Nick wrote: I haven't seen any mention of a new icon set for Gnome 3 (forgive me if I'm mistaken) but could I bring attention to the Faenza Icon set[1]? Is there an opportunity here to engage people outside of the Gnome/Tango sphere and get some nice, seemingly well liked, icons included with the new theme and the new gnome shell? I'm not an expert on such matters, but I'll tell you what I know. First, though GNOME's choice of icon theme has not changed for 3.0, that theme has undergone some fairly significant changes of late. There have been some major stylistic innovations over the past couple of releases, and the icon set has also received spiffy high-res versions of its icons (examples: [1], [2]). Another new development for this release is the addition of symbolic icons [3]. Faenza is a nice icon set, and I know that several of the GNOME design crew really like it. At the same time, GNOME's icon theme integrates with the desktop in a number of ways which mean that it's unlikely that we'd want to switch. These include: * Colour palette - matches our GTK themes (both Clearlooks and Adwaita), etc. * Programmatic integration of symbolic icons - they can be scaled and coloured (which, among other things, is good for a11y) * High res is needed for GNOME Shell I'm sure I will have got some of this wrong, but I think that's roughly where we are. Please feel free to continue this discussion with me off-list, or drop by #gnome-design to have a more open discussion. Best wishes, Allan [1] http://git.gnome.org/browse/gnome-icon-theme/plain/gnome/256x256/devices/drive-harddisk.png?h=one-canvas [2] http://git.gnome.org/browse/gnome-icon-theme/plain/gnome/256x256/apps/accessories-calculator.png?h=one-canvas [3] See: http://live.gnome.org/GnomeShell/Design/Whiteboards/SymbolicIcons ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
Hi, Maciej Piechotka wrote: FLAMEThen show delyourdelinsdesign team/ins work! All I'm hearing is that research have been done and the issue have been taken into consideration during disussion but I DON'T have any references. I cannot see logs of IRC (at least google is not showing them), blogs does not disclose why the decision was made in such way exactly and why the broken workflows are bad. All I'm hearing is that I'm uninformed. The decision presented on blog is presented as final final - not as a strong proposal (even if technically it is the same there are slight differences in PR). I'm not specialist in UI design - but I cannot even get response to information why my workflow is bad and how did you invision it (say - large backups during night)./FLAME Even if you had records of every discussion, you wouldn't get the information you're looking for. Design decisions don't get made committee meeting style, and design involves a lot of specialist background knowledge which doesn't get explicitly referenced. Fact is, we'll probably never be able to give 100% of the rationale behind design decisions. It simply isn't true to say that we haven't made an effort to explain what we're doing. I explained many of the design considerations in my blog post [1] on this subject, and I did that precisely because I wanted to help people to be informed. Basically - it seems that many people have feeling that their needs are being ignored in name of Average Joe and they are asked to leave. And I've repeatedly stated that that isn't the case (and it really isn't). There are a whole bunch of things in the GNOME 3 designs which are specifically intended for 'advanced' users: * Keyboard-only application launching and switching * Fancy workspaces stuff * Shell extensions * We designed a GNOME tweak utility [2] nearly a year ago I'm sure there's more... The plan is to make GNOME 3 the best desktop out there for a whole range of users, including those who are technically engaged. Sure - I might have done research on topic. I might start reading papers or even ask about them on #gnome-shell. I might have been rational But I guess that the discussion would be much less heated if the references were given - humans are not always rational. I proposed the change to have a shift from 180xYour design *** to even 10xHave you considered XYZ? - Yes - read paper ABC or even just include reference to ABC (give future historians when GNOME will rule the world some sources ;) ). There's a long list of references for the shell design on the wiki [3]. Much of the reading which is relevant to the settings is classic usability stuff, though. We do provide some relevant information on this [4, 5], if you're interested, but I don't think it's reasonable to expect us to reference the relevant studies for every single decision that we make. PS. To sum up - I think that community thin.ks that decision are made with practically closed doors (not everybody can even observe the discussion due to time constraints) and The only reason it appears that it's happened in the dark is because nobody's been looking. This design could have be seen on the wiki or design repository months ago. the results are posted as final truths as community is considered too stupid to understand People keep saying this... _nobody_ is saying that the community is stupid. (I'm NOT saying it is true - I'm saying it is the FEELING). I'm sure it would have been beneficial to have publicised potentially controversial plans ahead of time. Being able to 'break the news' in a more controlled way would help. Problem is: we don't have anybody who's properly employed to do GNOME community management work, and we don't have enough designers. Communication, documentation and forward planning all take time and energy. Allan [1] http://afaikblog.wordpress.com/2011/02/03/on-laptop-lids-and-power-settings/ [2] http://www.hadess.net/2010/02/were-removing-settings-again.html [3] http://live.gnome.org/GnomeShell/Design/References [4] http://library.gnome.org/devel/hig-book/2.32/ [5] http://live.gnome.org/UsabilityProject/HeuristicEvaluation -- Blog: https://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Mockup for Gnome 3.XX Share section of System Settings
Gendre Sebastien wrote: So, I update it to a version 3. News: - Use the switch GTK Widget. - Remove Apply and Cancel buttons. - Add Bluetooth sharing option. - Some changes on tabulation to be OK with the present Printer panel of Control Center. - Add mochup for options window. Note about options window: - Except bluetooth, all option is splitted on two section: Access and Advanced. - On Acess section, the triangle yellow indicates that an option choose by user are not supported by the protocols choosed. What option is not supported is indicate on tooltip when user pass the mouse under the triangle. Ex: transcoding is not supported by DAAP libraries. What do you think? That that isn't an appropriate question for this mailing list. The bug has subscribers - they'll see that you've updated the mockup. I'd recommend the usability list if you feel you have to send an email about it. (Be warned though - if you ask for feedback on a design, you might well get critical responses. And you've taken on a very difficult design challenge here.) Best, Allan -- Blog: https://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
Hey Andy, Andy Wingo wrote: Hi Alan, FWIW I mostly like GNOME 3, so I don't want to pile on the flamefest. But this bothered me: On Sun 06 Feb 2011 15:27, Allan Day allanp...@gmail.com writes: Even if you had records of every discussion, you wouldn't get the information you're looking for. Design decisions don't get made committee meeting style, and design involves a lot of specialist background knowledge which doesn't get explicitly referenced. Fact is, we'll probably never be able to give 100% of the rationale behind design decisions. The thing is, we've done mostly well in the programming department. If the subtext is this is the case for design in contrast to programming, I would like to disagree; that would be unjust both to programming and to design. Often programming is just as solitary an affair, yet we manage to communicate in such a way that enables collaboration; surely programmers are not more socially competent than designers ;-) Likewise designers don't work alone. I'm sure you have been one of two or three or six designers sitting at a table hashing things out. In neither profession do things happen committee meeting style -- when things go well, of course! -- but there is collaboration. Sure, designers communicate and collaborate. And of course we need to make an effort to ensure that our communications are accessible to others. This characterization of design also neglects the great community design work that has been done recently by Máirín, for example, and done to an extent within GNOME. I'm not as familiar with Máirín's work as I should be. It's fair to say that experiments in community design have had mixed results, though: Papercuts is an obvious success, but the Ayatana list isn't a productive place and UX Advocates is dead. (I'm not sure how Mozilla's efforts have worked out...) Finally, it's rare that a programmer never does design work, or for a designer never to code at all. Totally agree: 'designer' and 'developer' aren't mutually exclusive categories. We all need pointers and records to figure out how things are done. Of course it's not always possible! That's what the HIG is for, though I do think we can do more to keep people abreast of new developments. But it would be an error not to hold transparency up as a goal, IMO. The question, I think, is what role we imagine transparency to perform. If it's to inform and to make the community feel that it's a part of GNOME design, then I am all for it. What I'm skeptical about is the idea of transparency for the purposes of accountability. It simply isn't true to say that we haven't made an effort to explain what we're doing. I explained many of the design considerations in my blog post [1] on this subject, and I did that precisely because I wanted to help people to be informed. For this, and all your awesome work, thank you! Thanks. :) Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Release Notes time!
I'm going to start writing a first draft of the release notes very soon. There are still a bunch of apps that are missing from the preparatory notes [1], however. I know for certain that there have been improvements to gedit... What about Empathy? What about games? What about Rhythmbox? What about EoG? All we need are a few bullet points and any relevant links you might have. Best, Allan [1] http://live.gnome.org/TwoPointNinetyone/ReleaseNotes On Mon, 2011-03-07 at 09:53 -0600, Paul Cutler wrote: We are now under a month from release - and we need your help! Thank you to those of you who have added content for the Release Notes, but I have a nagging suspicion we're missing some stuff. We have so far: Users: * GNOME Shell overview panel fall back * Apps: Control Center, Cheese, Evince and Nautilus Developers: * Anjuta, Cheese * Developer docs * GNOME Panel Are there more apps? What about GTK3 for developers? Accessibility? Thanks for your help! Paul On Fri, Feb 25, 2011 at 2:41 PM, Paul Cutler pcut...@gnome.org wrote: Dear developers, I heard a rumor that GNOME 3.0 has some small changes to the GNOME desktop and GNOME development platform. Assuming that rumor is true, it's time for you to tell us what those changes are! Please update the release notes page on live.gnome.org[1] - please explain the changes in the UI, apps, a11y, development and more. Link to blog posts, wiki pages or mailing list posts if they have additional detail. Please be aware that the writers of the release notes will come to you with questions if additional detail is needed. Nothing is too small and we'll do our best to get everything in. For past examples, please review the 2.31 page on the wiki as well.[2] Thanks in advance for your help. Please let me or the marketing team know if you have any questions. Paul [1] http://live.gnome.org/TwoPointNinetyone/ReleaseNotes [2] http://live.gnome.org/TwoPointThirtyone/ReleaseNotes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no way to change theme or fonts in System Settings?
On Thu, 2011-03-17 at 11:15 +0100, Dave Neary wrote: Hi, Jasper St. Pierre wrote: The story I've heard is that we haven't supported themes because we make no guarantees about CSS class stability: CSS support was a nifty thing that was added so that we could put up a couple actors and mold them like clay into our mockups very quickly and easily. With the gnome 3 release, I doubt we'll add have a theme switcher out of the box. We've accepted patches to add API to make it easier for people making third-party theme switchers: SardemFF7 has one, a random guy from deviantart (not half-left) has another, and there's also gnome-plumbing and gnome-tweak-tool. Thanks for the info, Jasper! Is there a blessed/recommended tweak tool that people should be suggesting when we get asked these questions? gnome-plumbing never existed. I would point people to John's gnome-tweak-tool. Note: I don't think we should be 'recommending' such a tool as a part of the GNOME 3 experience. GNOME 3 is great as is, and people shouldn't need to change it. If they desperately want to tweak, they can, of course; and John has provided an easy way to do it (go John!) Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
Guillaume Desmottes wrote: Le mardi 22 mars 2011 à 10:02 -0400, Matthias Clasen a écrit : - Sadly, empathy is not a great chat application; with chat being such a prominent feature in 3.0, we really should be doing much better here. I'm sorry to hear that. Empathy is great. I definitely appreciate the work that goes into it, and it works really well. Could you please be a bit more specific and explain what are currently the biggest issues? The basic design could be *much* better. This has been on the minds of some of the designer types for some time, and there are even some mockups in the design repository [1]. Let's talk! :) Allan [1] http://gitorious.org/gnome-design/gnome-design/trees/master/mockups/empathy -- Blog: https://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
Matthias Clasen wrote: With GNOME 3.0 going into code freeze any day now, it is high time that we start looking beyond 3.0 and start collecting ideas and making plans for what comes next. To that end, I have collected a list of things that have fallen off the 3.0 train at one point or another, as well as some other things that might be nice to put on the roadmap. Some of these have designs and/or working implementations, others or just ideas. I'd like to encourage everybody to chime in with their own ideas and plans for GNOME 3.2. Thanks for starting this thread, Matthias. I totally agree with the priorities you've set out. I'd also like to see us concentrate on the design quality of our core applications. There are already designs in the repository [1] for some of these, including EoG, the calculator and Empathy. There are others that still need some design love. Nautilus was a success story this last cycle. The UI roadmap [2] process that we used there seemed to work really well: perhaps designers and developers could sit down at the beginning of the cycle and draw up UI roadmaps for other applications? Software aside, we really need that new version of the HIG that we've been talking about (Calum has been taking this forward recently)! Getting that sorted will help us to improve the quality of our applications and should help us to define how we want to tackle some of the cross-desktop UI problems we have. I'm particularly keen for us to come up with a plan for full-screen controls. Finally, I'd like to be thinking about our contributor experience. This might be something that has to wait until the following cycle, but it could be possible to start the process earlier. I'm particularly keen to examine the issue in a holistic fashion: we need to trace the journey of a new contributor through from landing on gnome.org to committing a patch or providing documentation, translation, design, etc. What are the weak points and trouble spots? What are the things that are most likely to turn someone away? It might be that there are small things that we could do that would make a big difference. Allan [1] http://gitorious.org/gnome-design [2] http://live.gnome.org/Nautilus/UIRoadmap -- Blog: https://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
What are the current HIG? [Was: GNOME 3.2 ideas and plans]
Richard Hughes wrote: On 23 March 2011 11:08, Allan Day allanp...@gmail.com wrote: Software aside, we really need that new version of the HIG that we've been talking about (Calum has been taking this forward recently)! In related news, I have no idea what the HIG is supposed to be for 3.0. Some control center panels have gray labels without the colon, some have black labels with the colon. We don't specify different label colours by design, do we? The HIG specifies that labels should have colons [1]. Maybe that should change in the future, but I haven't heard about it. Some are right aligned, some are left aligned. I'm not aware of there having been any changes there. Left alignment is the default. Right alignment can be nice, but sometimes doesn't play well with the demands of an interface (it doesn't work when you need to use indentation, for example). If in doubt, just left align like the HIG recommends. In general, the HIG can be followed just fine. Updates and changes are covered by the application integration guidelines [2] and by the (rudimentary!) GtkSwitch guidelines [3]. (It is fine to ignore switches for the time being. Just ask on #gnome-design if you're unsure.) But yes, it'll be much clearer once the new HIG is done! Allan [1] http://library.gnome.org/devel/hig-book/2.32/design-text-labels.html.en [2] http://live.gnome.org/ThreePointZero/AppIntegration [3] http://live.gnome.org/Design/Whiteboards/SwitchGuidance ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
snip Frederic Peters wrote: Allan Day wrote: Matthias Clasen wrote: With GNOME 3.0 going into code freeze any day now, it is high time that we start looking beyond 3.0 and start collecting ideas and making plans for what comes next. To that end, I have collected a list of things that have fallen off the 3.0 train at one point or another, as well as some other things that might be nice to put on the roadmap. Some of these have designs and/or working implementations, others or just ideas. I'd like to encourage everybody to chime in with their own ideas and plans for GNOME 3.2. Thanks for starting this thread, Matthias. I totally agree with the priorities you've set out. Thanks Alan too. I'd also like to see us concentrate on the design quality of our core applications. There are already designs in the repository [1] for some of these, including EoG, the calculator and Empathy. There are others that still need some design love. Nautilus was a success story this last cycle. The UI roadmap [2] process that we used there seemed to work really well: perhaps designers and developers could sit down at the beginning of the cycle and draw up UI roadmaps for other applications? It would be excellent; if you don't blog about it, it didn't happen, and it has been so true with the gnome-design repository, we need to publicize the designs and this will get new contributors on board, I am really fond of the GNOME Voice Recorder design by Hylke, he blogged about it[1], and two weeks later someone had started implementing it and posted on the gnome-multimedia. Blogging is definitely part of the solution. So are conversations between designers and developers. That was what moved us forward with Nautilus: we hashed out the details, made compromises, came up with a plan. A lot of the credit for that should go to Cosimo. snip During the 3.0 cycle the marketing and design teams were fantastic, but they are only now appearing in our schedule and processes (defining the featured apps, for example) Just like we integrated older teams (e.g. the string freezes for the translators, or consulting the documentation team about new modules), there are certainly things to do here; you wrote it above, here it is again: perhaps designers and developers could sit down at the beginning of the cycle and draw up UI roadmaps for other applications? Not just because we are in the mood for 3.0, but for future versions too, having that part written down in a schedule makes it important. This is definitely something I find important, I'd like to take time to hear ideas from all teams, and shake it out. A direction is that Fedora has features, Ubuntu has blueprints, and we could do as well, thinking things up for the whole GNOME, not delimited by modules. A good example is our Sharing story, in the words of Matthias: - Sharing: We have rygel, and gnome-user-share, and vino but no finished design for how this is going to appear in a control-center panel So there's Bastien from gnome-user-share, Zeeshan from Rygel, Juan from Grilo... some initial design by Hylke (iirc), we should find a way to assemble persons and ideas, and get that created for 3.2. The idea of blueprints makes a lot of sense to me. There are several wiki pages that I have written that are close to that form. The Eye of GNOME design page [1] is a good example. Whatever process we come up with, designs need to be able to evolve and then be agreed upon. The blueprint has to be the focus of discussion between designers and developers (particularly maintainers) and, crucially, someone has to say yes, we're happy to do this, or the only way that UI will happen is over my dead body. A key part of the Nautilus process was that we had an IRC meeting and agreed on the UI bugs we wanted fixing. They became the roadmap [3]. Then Cosimo did something smart: he put a link to the roadmap page in the #nautilus topic. Everyone could see what the plan was. Having an 'official' plan also (I think) helped new contributors. We had GNOME Love bugs in there that they knew we definitely wanted fixing. In conclusion: * Designers and developers need to talk more * Blueprints are good if they are a tool for reaching consensus * Roadmaps are a good way to implement plans (and include contributors) * Everyone needs to know what the roadmap is Allan [1] http://live.gnome.org/EyeOfGnome/PlaceForNewIdeas/UIRefinements [2] http://live.gnome.org/UsabilityProject/Whiteboard/DesignHub [3] http://live.gnome.org/Nautilus/UIRoadmap/ -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
Guillaume Desmottes wrote: Le mercredi 23 mars 2011 à 11:08 +, Allan Day a écrit : I'd also like to see us concentrate on the design quality of our core applications. I'm starting planning goals for Empathy 3.2 and would like some input from the design team on some point. So I went to http://live.gnome.org/Design looking for a way to easily contact the whole team. The only way seems to be the IRC channel, which may not be the best vector for long standing discussions. Why not having des...@gnome.org mailing list? (Or maybe you are already using another mailing list, but in that case it would be good to document it on the wiki). We need a better mechanism for design discussions. Until we get that organised, we can use the usability list. And the Empathy/Telepathy list, too? I think most of us agree that we would gain from a closer cooperation between designers and developers. Let's try to improve things. :) Couldn't agree more. :) Allan -- Blog: https://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Hey Alex! This is great. I've been doing some work on this recently, and we seem to be thinking about the same problems (good thing!) Alexander Larsson wrote: I've been looking at the contact feature for Gnome 3.2 [1], trying to understand what we want from this and how it would look. The initial page talks about a standalone contacts application, and while I think that is needed its not really the full extent of what we want. Contacts are a large part of social interaction, and social interaction is a huge part of what computers are used for these days. So we want to make these an integrated part of the desktop environment, rather than some external app. This means we want (in addition to any separate app) integration into the shell and the other apps in the desktop. Historically contacts have been just the data in the address book, something you type in once to make sure you don't forget it and then rarely look up. But things have changed. With the advent of social websites, etc we get to skip much of the type in info part, and we should be able to use the available information in many new ways. So, what kind of things do we now want to do with our contacts information? Here is a pretty comprehensive list of things that you might need contact information for. * Initiate direct conversation over the internet. This is typically email or chat, but can also be voip/skype, or e.g. facebook messages. * Initiate communication via external means: snail mail, phone nr You'd look up the data in the contact and write it on a postcard or dial it into your phone (or initiate the call via bluetooth) * Open up personal web pages (facebook page, blog, etc) * Look up information about the person This can be things like birth date, pin code for house, map to house, etc * View recent conversations * Send files to a contact * Export/Import contacts, and easily send them to someone else * Allow DND of contacts to apps, like the evolution composer * Get last known (geographical) location * Get availability status for im * Get last update (facebook, twitter, etc) * Edit contact data * Merge/link contacts from different sources * Extend presentation of contacts in the UI For instance, hovering over an email address shown in an app might show more contact information, including current online status. Obviously an important part of this is a common platform that supports all these features, and we have a bunch of good technologies for this, but I want to start with the user visible side instead. So, how would this look to the user? I'd like to start with email (i.e. evolution). This is where our current address book is, and one obvious step is to remove this in favor of a shared address book dialog. Additionally we need to make sure all the places thats currently using the address book in integrated places, like the email address typeahed, etc, also support all the new data. Overall this is not a large change, the main difference is the address book dialog. I don't think the traditional address book is much used in real life though. Email addresses are almost always looked up directly from the composer (via typeahead or the add addresses dialog), so its unlikely that the changes made here affect how users work with email contacts. This is bad, because we'd like to introduce a workflow that starts from the idea that you're gonna communicate with a person, so you look up the person and then see the available communication routes and chose one. This seems more efficient than starting with selecting a communications method and only then looking up the contact, because you'll be missing a lot of potential information to chose the right method (for instance, when looking up the person you might immediately see that his status is on vacation). In order to introduce this workflow for email we need to get the users used to it for other reasons. Just adding it as a possible way to initiate communications doesn't seem enough. The natural way to do this is via IM. When sending an IM message you always start by finding the person, and then initiate the communications. In a traditional system this is done via the IM main window, and if you think about it that window is really just a contact list. So, lets merge the traditional IM ui with the address book. Resulting in an integrated IM system that is also an entry into other forms of communication (and the other usecases above). This is especially fitting given the partial IM integration we already have in the shell (ability to get notified and reply to IMs, but you have to manually start a not-quite-integrated IM app to send IMs). How would such a ui look? I'm not sure, but to be usable it has to be easy to reach, i.e. it can't be a two-step thing (first find the contacts app, then find the person) it has to be directly available in the shell. The possibilities that I
Re: GNOME Feature Proposal: Backup
Hi Michael, Michael Terry wrote: Hello! You may remember me as the bloke that proposed the Déjà Dup backup tool as a GNOME module a little back, right as modules were being reorganized. I've been encouraged to try again as a Feature. I don't fully understand the process, but I gather an email to this list starts it off. It's great that you're reapplying for inclusion, and backup would be good to have. I'm really happy that you want your software to be a part of GNOME. Here's a quick thousand foot view: * Homepage here: https://launchpad.net/deja-dup * It's a backup program aimed at non-technical users. * It's a graphical wrapper and policy manager for the backup program duplicity. * It's included by default in Fedora 13 on and will be default in Ubuntu 11.10. * It follows the GNOME schedule and best practices already. For the next major version (20.0), I've done a redesign aimed at making it more invisible and appear as part of the OS. That sounds like the right approach to me. I've made it live just as a control center panel and removed some branding to look a bit less like a separate app. See http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. This looks like an improvement on the UI that you presented the last time you proposed Deja Dup. It could still be much better though. How would you feel about paring it down to something more minimal? Ideally, the UI should be limited to switching it and on/off, selecting the backup storage location, and giving an idea of status (a little 'hey, you're backups are fine!'). I do think this should be part of system settings, provided Deja Dup behaves like it is part of the system. One question: I know that you had a discussion on the usability list about renaming Deja Dup. Would you be happy to remove the remaining references to Deja Dup in the UI and just call it Backup? I suspect GNOME might be interested in having a backup story so I'm offering this one. And I'd be happy to have increased design advice and developer eyeballs. As others have suggested, that story should roughly be 'backup that just works': you switch it on, do some very minimal configuration, and then it takes care of itself in the background. I have a few related questions: * What does being a GNOME Feature obligate me to? Basically the normal module stuff? (Since no one else has answered this question...) In this case, yes (I think!) Best wishes, Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Michael Terry wrote: Hi, Allan. Thanks for your past and continuing help with design! :) Answers below. On 11 May 2011 11:33, Allan Day allanp...@gmail.com wrote: This looks like an improvement on the UI that you presented the last time you proposed Deja Dup. It could still be much better though. How would you feel about paring it down to something more minimal? Ideally, the UI should be limited to switching it and on/off, selecting the backup storage location, and giving an idea of status (a little 'hey, you're backups are fine!'). So specifically, you're talking about dropping: * Encryption toggle * Include/exclude * How long to keep backups * How often to back up I'm happy to have a discussion about what to do for each. That's great to hear. I'll follow that up with you. One question: I know that you had a discussion on the usability list about renaming Deja Dup. Would you be happy to remove the remaining references to Deja Dup in the UI and just call it Backup? The only remaining references are the one-time welcome screen and the help documentation. I'm not fully wedded to those, though I'm hesitant to remove all instances. I can think of a at least a couple reasons at least a one-time brand is useful: * Some branding (even only once) is useful here to reassure user it will read the backup data they made elsewhere. * The user can install it on non-GNOME and they need to know what app to search for. Since the moduleset reorganisation, we make a distinction between GNOME core and GNOME applications. If a module is part of the core it's supposed to be an integrated part of the user experience (as you've said you want to aim for - yay!), and it's supposed to use GNOME infrastructure. Looking at your proposal it seems that you are proposing Deja Dup for inclusion in the GNOME core. You also seem to want it to be developed on LP and for it to simultaneously exist as a standalone app, though. This opens up some potentially tricky issues: * What do we do about the infrastructure question? Core modules are supposed to be developed as a part of the wider project; that means that they use GNOME's infrastructure. * Can you technically achieve the level of integration that we're after if Deja Dup continues to exist as a standalone app? (This is a serious question - I don't know the answer.) * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. Sorry for the potentially difficult questions! Allan -- Blog: https://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Sam Thursfield wrote: ... snip ... * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. Could you clarify this one a little? On first read it sounds like if Deja Dup becomes part of GNOME core, you aren't allowed to have it on any other platforms although I'm sure that's not at all what you meant. I'm struggling to pick up what you do mean though. I put this too strongly. All I meant was that, if we present GNOME Backup as part of GNOME 3 (ie. GNOME core), it might look strange if it can be installed on non-GNOME systems. That wouldn't be an issue if Deja Dup were applying to be an application, I might add - it's fine having cross-platform GNOME apps. The issue is that it's potentially going to be a part of the core - the system - and there's maybe a discrepancy there with how we describe GNOME 3. I'm not saying this is a definite problem. It's just something to consider. Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, 2011-05-12 at 16:44 +0200, Dave Neary wrote: Hi, Bastien Nocera wrote: On Thu, 2011-05-12 at 09:37 +0200, Ted Gould wrote: Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. For the gnome-control-center, if it's worth having, it should be worth having upstream, and in gnome-control-center directly. In the context of Ted's request, one obvious case to bear in mind would be integrating file sharing via Ubuntu One. That is a system service on Ubuntu, and should obviously have its preferences in the System preferences-Sharing panel. I don't know about the implementation, but the intent behind the design of that panel was to allow different sharing services to be added to it (just like Ubuntu One). See: http://live.gnome.org/Design/SystemSettings/PrivacyAndSharing Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Michael Terry wrote: On 11 May 2011 19:18, Allan Day allanp...@gmail.com wrote: Looking at your proposal it seems that you are proposing Deja Dup for inclusion in the GNOME core. You also seem to want it to be developed on LP and for it to simultaneously exist as a standalone app, though. This opens up some potentially tricky issues: * What do we do about the infrastructure question? Core modules are supposed to be developed as a part of the wider project; that means that they use GNOME's infrastructure. * Can you technically achieve the level of integration that we're after if Deja Dup continues to exist as a standalone app? (This is a serious question - I don't know the answer.) * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. I'm coming into this interested less in questions framed as how can Deja Dup make GNOME better than as how can Deja Dup being part of GNOME make users' backup experience better. I presume you'd be happy for Deja Dup to become a GNOME Control Center panel? For example, I think of the infrastructure question in terms of whether there's a reason to believe switching to GNOME infrastructure will result in more or less maintenance work being done. If Deja Dup is accepted, we'll need to work together and GNOME contributors (developers, designers, bug reporters and triagers, translators, documentors, etc) will want to contribute to Deja Dup. How will they do that? And the branding question less in terms of will it be better for GNOME marketing than will it be better for users. See my other message on the branding question - this isn't necessarily a problem. I'm just interested to hear your thoughts on how Deja Dup will be branding itself as a standalone application. Thanks, Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
Cosimo Cecchi wrote: Hi everyone, It's too late for feature proposal, but I've been encouraged to post this here anyway. Sushi [1] is a quick previewer application, targeting integration with file managers such as Nautilus - you can read more about it in a blog post I wrote some time ago [2], but it works in a similar way to OSX Quicklook and Gloobus-Preview [3]. The project is still very young (I've been working on and off on it in the last month or so), but it's working well already, it supports quite a lot of file formats and Nautilus 3.1.1 can already make use of it, if it's installed on the system (no strict dependencies are required, since its start-up is implemented as a DBus-activated service). I envision this could be also useful outside of Nautilus, (GtkFileChooser comes to mind, but it might be useful for Finding and Reminding/Journal too?), but I don't yet have grand integration plans for it. The project uses the GNOME infrastructure, depends on a number of libraries of our platform already (Clutter, GTK+, WebKitGTK, GStreamer) and a couple of other popular external libraries (libmusicbrainz, GtkSourceView support is in the pipeline) but it's still lacking a Bugzilla product (it could probably even use a Nautilus component for it). So, with the new moduleset arrangement, does this qualify as a OS feature? Does this need to go under some sort of approval/discussion outside of the Nautilus forums? We didn't use to propose new features for modules already in the desktop moduleset, but I've now been encouraged to write about this project as targeting a feature. This case is probably a bit borderline, as it's technically a new module (so it would map to the old new module proposal process we used to have), but it's used only by one application (Nautilus) currently...the end result is I'm a bit confused :) Sounds like it should be both a new feature and a part of GNOME core. It would be great to be able to introduce it as a feature in 3.2. I've started a feature page here [1]. Allan [1] https://live.gnome.org/ThreePointOne/Features/FilePreviewing [1] http://git.gnome.org/browse/sushi [2] http://blogs.gnome.org/cosimoc/2011/04/29/sushi/ [3] http://gloobus.net/ Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi Michael, Thanks for all of this. Let me reiterate that I *really* want to see Deja Dup in 3.2. We just need to figure out how to make it work. Michael Terry wrote: On 12 May 2011 17:05, Allan Day allanp...@gmail.com wrote: I presume you'd be happy for Deja Dup to become a GNOME Control Center panel? Depends on what you mean. I'm happy for Deja Dup to be shown as a panel in the control center. But it sounds like you're asking about actually putting it in the control center git tree? I guess I don't see the point. * I'd like to continue to support GTK-but-not-GNOME platforms (why not?) even if only as second-class citizens. So I'll probably add a preference dialog that simply wraps the deja-dup control panel for such cases. Having the panel be out-of-trunk makes that unnecessarily hard. It makes it harder, I guess. Whether it is unnecessary depends on your point of view. ;) * I assume the rest of deja-dup would be a separate module, so now it would be split across modules, losing the ability to share translations or logic. I'd have to write a library to share some of the logic bits. So that would be more work. * The only reason to be in tree that I can see is that g-c-c plans to drop the API for panels? But that is a separate thread. And what a thread it is... If Deja Dup is accepted, we'll need to work together and GNOME contributors (developers, designers, bug reporters and triagers, translators, documentors, etc) will want to contribute to Deja Dup. How will they do that? My intent is to achieve high levels of collaboration. Great to hear! GNOME has a lot to offer; we could achieve great things together! I have lots of ideas about how the GNOME community and LP projects can have tighter integration. I can defend why LP works for me, but that's not entirely the point here I feel. It could be so easy to collaborate! We could mirror bzr trunk in git, grant permissions to bzr trunk to an automatically sync'd group on LP, grant permissions to the translation web UI+trunk to the GNOME translation team. I could move my mailing list. I like to think the project already works well with GNOME designers (you and I have done a review before). Etc. Moving the mailing list would be helpful for design collaboration, I think. I'm kinda happy to follow your current LP list, but other designers might not be. So the big question to GNOME is how much do ya'll want to avoid the extra step of such collaboration for Features you consider part of your core? Is that a hard-blocker? Who gets to decide if it is? I'm theoretically open to moving infrastructure, pending a weighing of benefits. But I'm also curious if GNOME is even theoretically open to me not moving. It's the release team who decide in the final instance. (So see Fred and Olav's messages. :) ) My personal view is that we should be flexible, provided that we can find a way to effectively work together. Would you be willing to use GNOME Bugzilla? See my other message on the branding question - this isn't necessarily a problem. I'm just interested to hear your thoughts on how Deja Dup will be branding itself as a standalone application. I had envisioned the same way as a non-standalone app. It would appear as Backup to the user. Either as a standalone preference dialog or control center panel. But I've been thinking it needs to show its brand name at least once (I currently show it in the welcome screen). That way users know what they are getting. Now if your question is really about what that brand is (GNOME Backup vs Deja Dup) that's a different issue that I'm just now guessing you meant? I don't feel strongly on the name presented to users. I'm open to feedback here. It could maybe even be presented differently if deja-dup is a standalone app vs a panel? Thanks, that's really useful. This is somewhat new territory for GNOME, so it's nice to know we have the flexibility to work things out. Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Michael Terry wrote: On 13 May 2011 12:28, Allan Day allanp...@gmail.com wrote: Would you be willing to use GNOME Bugzilla? That specifically would be the hardest part of an infrastructure move. Some important downstreams (Ubuntu and flavors) and my sister project Duplicity are all in LP. So it's very easy to share bugs and triaging work there. Plus since I'm an Ubuntu developer in my day job, it's my normal workflow. So there's good technical collaboration reasons why I value LP for bugs as well as the more squishy comfort reason. There are good reasons for wanting to have Deja Dup on GNOME Bugzilla, I think. I can imagine myself wanting to CC other GNOME contributors on Deja Dup bugs. I can also imagine bugs being punted between Deja Dup and other GNOME modules. Plus there's the whole release planning and GNOME QA effort to consider. Don't forget that there's a high chance that people will fix Deja Dup bugs for you if you're on GNOME Bugzilla. :) Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Dave Neary wrote: snip Leaving aside because that's the way it is as a reason for a second, what are the potential issues we'd have using Launchpad? * Bug reporters would have to have an easy way to report bugs against Deja Dup through gnome.org * GNOME developers would need to reassign bugs to deja dup which were incorrectly assigned to another GNOME module * Deja Dup developers would presumably want to do the same thing in the other direction Are there others I'm missing? /snip * A way to subscribe/CC GNOME contributors to Deja Dup bugs * Need to be able to target bugs at specific GNOME releases * The release team needs to be able to mark and track release critical bugs (important ones, blockers, etc). I gather that this is currently done by querying Bugzilla. The latter two are essential, I guess. We also have the fragmentation issue to think about: if Deja Dup uses LP, what's to say other modules can't use it too? Or Source Forge? Or Google Code? Or Trac installations... Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Hi José, On Fri, 2011-05-20 at 09:52 -0400, José Aliste wrote: Hi, I have a simple question (hopefully ddl is the right mail list for this): how are we supposed to interact with the design team? it seems that the best way is contacting them through irc in #gnome-design, but what about Gnome bugzilla? Does setting a keyword or something makes the design team in the CC of a bug or something so we can get UX advice from them? I understand that dealing with design of new features, hanging in IRC is best as it is faster to interact this way, but there are a bunch of bugs in Evince that need a thumbs up/thumbs down from the design team and I d like to know which is the best way of interacting so we can get these fixed/or wont fixed but with a clear statement from UX point of view why we are doing so. (and having a page, that probably exists, explaining the interaction between different teams would be also great) Greetings, José #gnome-design is good; so is the usability list. The ui-review Bugzilla keyword gets used in GNOME Shell and the control center. We could try that here too. Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Hi Dave, Dave Neary wrote: Hi, Allan Day wrote: #gnome-design is good; so is the usability list. The ui-review Bugzilla keyword gets used in GNOME Shell and the control center. We could try that here too. Presumably you others are still not interested in drawing a few developers and designers into a gnome-design mailing list, separate from the usability list I think it's important that we work on being more accessible, and we need to make it easier for people to stay informed about what we're up to in GNOME design, but I don't think a mailing list is a good way for us to do that, and I'm pretty sure the others who are involved in design work feel the same way. So yes, you presume correctly. I'm open to other suggestions though. ;) Right now, design update blog posts (like the one I did last week [1]) are one of the best mechanisms at our disposal, in my opinion. Long term, we probably need specialist design tools or even a wave in a box [2]. (which is more post-processing than drawing up plans, I think)? Maybe I missed a memo, but I wasn't aware of it having a particular focus (other than usability). Allan [1] http://afaikblog.wordpress.com/2011/05/27/recent-goings-on-in-gnome-design/ [2] http://googlewavedev.blogspot.com/2010/09/wave-open-source-next-steps-wave-in-box.html -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Dave Neary wrote: By working real-time, you are preventing a relationship from being built beyond a small group of people. Those people work closely together, but have the appearance of a closed tight-knit clique from outside the group. There is no transparency about what the design team is, who has what skills, etc. Many stakeholders and developers who have design problems do not have any relationship with the design team at all. This is the problem I think we need to solve. We're a small team - we can't solve every design problem in GNOME all at once. :) (Just saying.) But relationships are hard to do online. Hard to do long distance - more difficult the farther you are from that reassuring touch. This is a pretty good problem statement for free software development in general. I think we can agree that the key challenge that most free software projects have had to overcome is how to build durable relationships online. And we haven't always done it perfectly. But we have at least 20 years of experience to fall back on when considering how we might do so. Design in the open is a new challenge, of course... Is IRC perfect for this? Certainly not. I didn't use IRC at all until just 4 years ago - and I still curse at it. However, it is still much closer to a conversation than is email. The architecture of email encourages argument not agreement. Exchanges are volleys. Too much tactics and too little strategy. It still has a place in the world, obviously, but not in the tender stages of a design process. Let me be clear: real-time communication has a role. But it fails in three key points: * There is no record of the culture for newcomers and other members of the community to consult I wrote a contribution guide which was intended to help with this issue [1]. Let me know if you think it could be improved in any way. * There is no clear way for a newcomer to contact the team, or to know who the individuals in the team are (related to the lack of a record) We have a list of which designers are involved in which projects on the wiki [2]. It's not up to date or complete, but it's something. * If you're not in the room, you completely miss out on any opportunity to influence the conversation I would expect the relevant people to be in the room or be informed afterwards if a significant decision is made. That's the way it works on the design projects that I'm involved in. We do need to create an environment where designers can feel free to brainstorm, create, and design. We also need a way to have a feedback cycle with developers. Feedback is a separate problem to enabling participation, no? Doing more in terms of community relations is something that I'd love to do more of and I have some ideas about it. Time is always the limiting factor, though. The compromise solution which I proposed last year (off-list), and which a number of people did not think was a good idea, was to have a mailing list whose membership was moderated. Archives would be public, but only designers some key developers would be members - all other email to the list would be moderated. This addresses part of your concern - the argumentative, confrontational nature of GNOME mailing lists - while also allowing an area where people outside the design team can see who is who, who does what, and get a feel for the culture of the team. A moderated list might be a good way of allowing people to make contact with our designers (not a massive problem, but it's a problem). It might also be useful for passing the odd message around. I'm not convinced that a list would provide a good way to enable people to participate more easily, however - and isn't that the most important requirement? So I'm not thoroughly opposed to your idea, but I'm not massively enthusiastic about it either. But it's not me you've got to convince - it's the others you expect to use this list. There's no point in setting up a design list if there aren't any designers subscribed to it. And really: is writing a message to ddl the best way to make this happen? We don't have the perfect solution but I think there is now sufficient proof that GNOME design is flourishing despite it. At some point, I'm sure, this want will motivate an inventor and we'll be even better off for it. I am sure that I am not alone (because others have told me, and said so right here) when I say that I don't think the current situation is sustainable. A small group of people are making profound changes to the project on an unarchived IRC channel. Well, designers don't make changes to GNOME on their own. ;) This issue is largely one of perception and the need for better community engagement, in my opinion. We need to take the time to talk to people in the community and explain what's happening. That takes time and resources, of course. Several people have brought up questions, concerns and issues here and
Re: On the Interaction with the design team
Johannes Schmid wrote: Hi Allan! Yes. *I* was annoyed by the recent Deja Dup discussion, and felt that the developer got short-changed at the end of the day. I was very annoyed at the systemd as external dependency discussion, and the message that some people following along the GNOME OS meme sent to developers on other platforms. There seems to be some confusion here. Frankly, I have no idea what the design team has to do with either the Deja Dup or systemd discussions. I only ever received positive comments about having GNOME Backup from our designers. As for GNOME OS, though members of our designers are involved in some related work (all in the open: see [1]), I wouldn't say that the team is a driving force behind that initiative (though I'm pretty sure they all think it's a good idea). It feels like our design team is being blamed for every controversial decision or discussion here. It might come as a shock to some, but we're generally just busy designing UI. :) Actually yes, it would be a bit unfair to blame the design-team (or only the design-team) here. But at least from what I remember from the discussion about Deja-Dup it was not a pleasant experience for somebody wanting to integrate with GNOME. The points I remember: * GNOME designers decide how that feature should look - not you as a maintainer We'd want to work with the maintainer to develop the design. That's the way it usually happens. * You need to give up your brand Deja Dup if you want to be part of GNOME * Deja-Dup isn't allowed to exist in parallel as a application (+ a lot of technical stuff about control-center and external capplets) I only ever raised that as a potential issue (I thought I'd been quite explicit about that). This has nothing to do with design. They were issues that I raised independently, and there was never any discussion about them within the design team. I actually felt that I was operating within a marketing role, not design. So you're doing it again - picking up on something and assuming it is coming from the design team when it's not. I am pretty sure that things were not entirely meant that way but if you read the discussion on d-d-l the impression stays pretty much. If that's the impression you got then I apologise - it was never the intent. I guess Dave used the systemd discussion as a example for a possible bad attitude in GNOME but it is clearly unrelated from design things. Right. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Frederic Crozat wrote: On Mon, Jun 6, 2011 at 2:42 PM, Allan Day allanp...@gmail.com wrote: Dave Neary wrote: Hi, Emmanuele Bassi wrote: can you please explain to me, in a short sentence, what do you want to achieve? not how, but precisely what. I have said that already: I want to enable the design team to work productively with the entire GNOME development community. Right now a small number of designers are working effectively with a small number of developers, and I've observed increasing discontent among developers not on the inside. This is something that we're all committed to improving. I honestly think it's largely a problem of perception, but it's still a problem. do you have *specific* issues related to you (sorry, no the community might feel or there have been rumors or people can misunderstand)? Yes. *I* was annoyed by the recent Deja Dup discussion, and felt that the developer got short-changed at the end of the day. I was very annoyed at the systemd as external dependency discussion, and the message that some people following along the GNOME OS meme sent to developers on other platforms. There seems to be some confusion here. Frankly, I have no idea what the design team has to do with either the Deja Dup or systemd discussions. I only ever received positive comments about having GNOME Backup from our designers. As for GNOME OS, though members of our designers are involved in some related work (all in the open: see [1]), I wouldn't say that the team is a driving force behind that initiative (though I'm pretty sure they all think it's a good idea). I'm sorry but GNOME OS is a very good example of how interaction between design team and GNOME community is failing : - there has been no communication with the community since William presentation at latest GUADEC and the associated blog post ( http://blogs.gnome.org/mccann/2010/08/01/shell-yes/ ) - it seems people working on GNOME OS have a different definition of what is an OS, a distribution, etc.., which has not been discussed nor even published somewhere publicly (and if you don't even agree on definitions, cooperation is even more difficult). You are missing my point - GNOME OS is *not* a design initiative. There is some work going on under the design banner, but GNOME OS did not originate in GNOME design. Most of the design team don't know any more about GNOME OS than you do (or if they do, they're not telling me ;) ). I agree that it would be good to have more communications about GNOME OS, but that isn't the responsibility of the design team. You'll need to complain to someone else about this one, I'm afraid. - saying design is done in the open by just giving the 7 whiteboards list is not what I call open design. Moreover, some of those pages can be extremely incomplete ( see -- https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates for instance which lacks any rationale and doesn't seem to leverage user experience from people on other OS). Fair point. We need to document more. Don't think anyone disagrees with that. As somebody who has been active for years as a GNOME packager, it is becoming impossible to monitor what design changes are coming and bring feedback based on my experience from interacting with users. You'll need to be more specific. You want to be able to participate in design work? How did you do this monitoring and feedback previously? Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Frederic Muller wrote: On 06/07/2011 04:53 PM, Rodrigo Moya wrote: Also, while I'm not a designer, yesterday I wanted to propose some new stuff, and it was easy to get the design team to find a solution for proposals (https://live.gnome.org/Design/Proposals ), so from my (short) experience they seem to be open to listen to new ideas. Hi! I don't think the discussion is about the design team not being open but more about the decision process and understanding how choices are being made. I'll take the example of the power off menu. From my discussion with some members of the design team I have been told the disappearance of the power off menu was pushed without much discussion just before a freeze. There was some discussion, but you don't always have the luxury of having extended debate about every issue when you're about to freeze a dot oh. :) The current bug has 67 comments (https://bugzilla.gnome.org/show_bug.cgi?id=643457 ) all asking for a power off menu except 2. As a foundation member and supporter of GNOME I don't even know myself how to give a feedback that matters and join the hundreds unhappy contributors with this decision (users spend hours looking at how they can power off their machine, talk about good UX...), nor can I point anyone to a method to give feedback that matters that would help to get our voice heard. I think you've got to the crux of the issue here Fred. Actually though, I don't think the problem is listening as much as speaking. The people who have made these decisions are fully aware of peoples' opinions and feelings. All the feedback gets read. What is missing is a response that communicates that that feedback has been taken seriously and which evaluates the various options that are available to us. Were there any UX testing report available that motivated this decision? This kind of statement implies that if designers don't scientifically prove the validity of their work they aren't allowed to do it at all. More user testing would be great, but that's often not an option. Was it really a minority decision? Why? The decision was made by the shell design team (which is Jon and Jimmac with Jon in charge), and then ratified (so to speak) by Owen in his role as shell maintainer. That's pretty much as things should be in my view, and it's largely in accordance with how things generally get done in GNOME. Why can't it be reverted if so? There's no principle that says a design can't be changed (though the practicality of that varies from issue to issue, of course.) What is the process? People want to feel like they are a part of GNOME and they want to know that the designers who are working on the project give a shit. I'm honestly not sure whether bureaucracy is the best way to achieve that. Again: we already know what the issues are and we know how people feel about them. The part that is missing is the response. I am also someone that would be happy to see a trackable system implemented which we could go back to, read and understand, and provide meaningful feedback to. I think I've answered what I think of that above. I've expended all the energy I have on this thread. I won't be participating any further, though I will continue to work to improve things on the design side. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing out jhbuild
Owen Taylor otay...@redhat.com wrote: To me, the criterion for success is that someone can start from scratch, without knowing much about Linux development and have a working build within an hour or so, without having to babysit it. Any sort of babysitting makes things much longer for everybody, and basically impossible for the novice. I'm really happy to see JHBuild getting some attention. These seem like noble aims indeed. :) * I'm a bit skeptical of the existence of meta-gnome-core-shell, which, as I understand it, is supposed to contain the set of things that need to be built for gnome-shell to work at runtime - so, e.g., dconf is just a run-time dependency, since the build-time depdendency is just gsettings. But what if I wanted to hack on nautilus or gnome-control-center rather than gnome-shell? Shouldn't we shoot for: jhbuild build X jhbuild run X working? meta-gnome-core-shell (or something similar) seems useful to me, since it gives you a minimal (ie. quick) version of the essential GNOME experience (the shell, control center and everything that they require). This is typically what early adopters and testers want, and we are doing ourselves a favour if we try and get everyone using and testing the core anyway. I'd actually prefer it if meta-gnome-core-shell gets built by default rather than meta-gnome-core and meta-gnome-apps-tested... I'd also like to add that our current modulesets are rather impenetrable to newcomers. Not only are their names confusing, but they're undocumented. Fewer modulesets (two per release, perhaps?) with saner names (gnome-core-3.2 and gnome-world-3.2, for example) would be an improvement. An explanation of what each moduleset is along with a list of the modules and metamodules in each one would also help. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Aug 19, 2011 at 1:20 AM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Fri, Aug 19, 2011 at 12:45 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Nothing is ever perfect, but having at least some results is better than nothing. Since you have repeated this assertion a few times, I must ask: What if the results are all wrong and we don't have any way of knowing that? Would those results still be better than nothing in your opinion? What do you mean by all wrong? Let's assume that the results show that 1000 people are not happy with GNOME. How can that be wrong? 1000 people responded that, the results were not somehow altered, or boycotted, the results are the results, and that's that. ... 'Wrong' in social research typically means that your results lack validity: that you think the data is measuring one thing (eg. 'GNOME users' happiness with GNOME 3') but is in fact measuring something else. When you do survey research, you have to be certain that one person understands the questions in the same way that another person does. Looking at your questionnaire, that won't be the case. An example: === 02. Overall, how happy are you with GNOME? === (single choice) * unhappy * not so happy * happy * very happy * completely ecstatic Different people will understand the words GNOME/happy/very happy/ecstatic in different ways. Some might think 'GNOME' is their distro (including the lower levels of the stack), some that it's their 'shell', others that it's all their GUI software [1]. Likewise, 'happy' will be thought of differently by different people (a very odd word to include in a questionnaire, if you don't mind me saying): there are a vast range of expectations and usage patterns in relation to desktop computers, all of which will affect how people respond. Someone could tick 'unhappy' but by most measures have had a perfectly satisfactory experience. You've also got the representativeness problem. Your sample will inevitably be unrepresentative, probably highly so. Even if 100% of your *unrepresentative sample* tick the unhappy box, that doesn't tell you much about your target population: you might just have sampled every 'unhappy' GNOME user that's out there. tl;dr version: your survey results will be misleading. We already have a wealth of data about peoples' experiences with GNOME 3 and are working to address the issues that are being raised. It's great that you want to help, but this survey really won't be useful. Allan [1] GNOME's place in the stack means that you can't really do satisfaction surveys on it. This is one reason why GNOME is a more difficult research topic than, say, Git. -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Aug 19, 2011 at 1:14 PM, Allan Day allanp...@gmail.com wrote: Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Aug 19, 2011 at 1:20 AM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Fri, Aug 19, 2011 at 12:45 AM, Felipe Contreras felipe.contre...@gmail.com wrote: ... Different people will understand the words GNOME/happy/very happy/ecstatic in different ways. Some might think 'GNOME' is their distro (including the lower levels of the stack), Which is why we ask more question to understand their level of geekness. That should help the make correlations; the people that use a terminal all the time more likely know that GNOME is just the DE. The people that don't have much experience might be confusing GNOME with the distribution. 'Geekness' is not the only thing that will affect people's understandings, and you haven't adequately measured that anyway. Plus that doesn't do anything to deal with the problem of what people understand by 'GNOME'. Likewise, 'happy' will be thought of differently by different people (a very odd word to include in a questionnaire, if you don't mind me saying): I think everyone understands the word happy. /ME wipes a mouthful of coffee from my monitor Then you haven't read enough of the survey research literature. ... In any case, if you have suggestions that don't have these problems, feel free to share them. My suggestion would be to give up entirely or to rethink the premise of your research. The latter is what I'd have advised when I was working as a research consultant, or what I would have told one of my students when I used to teach this stuff, for that matter. You've also got the representativeness problem. Your sample will inevitably be unrepresentative, probably highly so. Even if 100% of your *unrepresentative sample* tick the unhappy box, that doesn't tell you much about your target population: you might just have sampled every 'unhappy' GNOME user that's out there. If you can identify the bias, that's not a huge problem. So tell me - how will you accurately compensate for the effects of self-selection bias? What kinds of claims will you make about representativeness? tl;dr version: your survey results will be misleading. No, the results would not be misleading; the *analysis* of the results might. But different people can analyze them in different ways. The important thing is to get *some* results. It seems bizarre to suggest that research data is valid irrespective of how it is gathered. If your questionnaire does not provide valid measurements no amount of analysis can compensate. We already have a wealth of data about peoples' experiences with GNOME 3 and are working to address the issues that are being raised. It's great that you want to help, but this survey really won't be useful. Where? I haven't seen any. We've had incredible amounts of feedback; most (if not all) of which has been read, and which does get taken seriously. I also know that those of us who are influencing the design of GNOME 3 take a strong interest in peoples' experiences with it and ask them questions (that's certainly what I do). There's also a small series of user tests last I did Christmas, the results of which have been fed into the development process. Believe me, that is more than enough to be going on for now. (Some more user testing would be useful at some point in the future, though.) Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Where is the data?
Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Sat, Aug 20, 2011 at 6:04 PM, Allan Day allanp...@gmail.com wrote: I never found the time to do a proper write up of the user testing I did on the shell. It was brief and ad hoc; I can tell you that the five participants in my study were all able to complete the tasks that were set for them though, which included basic things like launching applications, switching windows, changing the desktop background, responding to notifications and changing the volume via the system settings area. They obviously found some things trickier than others, but they could do everything I asked them to do. While that covers feature exploration, I don't think it covers usability over a long period of time of use, once users know what gnome3 provides: given a workflow, how efficient is window switching, what is often used, for example. That's correct. My small study had a narrow scope. Have you also done such user testing? That's not exactly the kind of thing a volunteer can do in their spare time. ;) It would require non-trivial financial backing to do a study of medium to long-term usage. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Where is the data?
More selective answers... :) On Sat, Aug 20, 2011 at 2:18 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: Il giorno sab, 20/08/2011 alle 12.04 +0100, Allan Day ha scritto: This is the first time I see the amount of users tested, and the exact tasks involved. I think it should go somewhere in the wiki, especially alongside the exact results (what was trickier? why?) Thanks anyway! I really did want to write a proper report but I never found the time. Jon, Jimmac and Owen got a quick run down on the results and there's a bunch of bugs that I filed as a result of the testing. Where we developers can find hard facts proving the NOTABUG and the WONTFIX we mark in the most questioned and hot issues? You can always mark a bug with the ui-review keyword if you want a second opinion. You misunderstood me. I didn't say that I don't know when to close, I said I don't know how to explain to the users why I'm closing. You need facts to prove your points, or people won't understand and refuse to agree. Oh right, sorry. There is evidence available to back up the current design but it's not all super hard and scientific. If you want a better justification for certain decisions, just ask the designers to add to the documentation on the wiki. Maybe we'll be able to do more user testing one day too. I'm not a designer, so I may not understand all the papers you provide in your support, and I may not understand what are the rules and laws of Human Computer Interaction, as you call it. But I understand numbers, and would be convinced by seeing that 66% percent of people find this method of working more productive, or 3 out 5 tested users where able to discover the functionality without guidance, or all 8 people interviewed did not use the feature just removed. ... More user testing would be a good thing, and that might provide some of the numbers that you crave. In the mean time, we're not operating in the dark however: we can tell a lot from a combination of the UX literature, dog fooding, feed back from users and comparison with what other OSs/DEs/whatever are doing. It's not numerical data but it is data all the same. Usual example: the shutdown button. There is no UX literature proving that suspend is the right way to shutdown a system. Other systems (Windows, Mac OS, KDE) are keeping power off as the primary method. Feed back from users is far from enthusiastic. So... is there anything that proves your points? The best examples of this kind of behaviour are mobile phones and tablets, imo. As an example, it is said that the user wants to focus one specific task at time, and thus the taskbar was removed and all task switching moved to the overview. I can concede that the premise is correct, but it is hardly self evident that the overview helps with this, given that a task often involves more than one window and more than one workspace (which forces the user to alt-tab to avoid the overview distraction). I *really* don't have the time to properly discuss these issues with you right now, I'm afraid... :) I think the main thing is that launching isn't always visible, and that that changes the experience for the better. (Yay for more baseless assertion! ;) ) I thought that the responses to the top ideas on Ubuntu brainstorm were a good example of how this can be done, actually [5]. Doing that kind of thing requires time and effort, of course... I see. Well, we could ask the feedback reporters to do the work. After all, it is in their interest to have the developers focused on the problems. Or we could have voting in bugzilla. I know many people are against to this, but it would immediately show the hottest issue, that surely require reconsideration by the design team. Plus it would avoid +1 comments that spam our mailboxes. The main thing would be to visibly demonstrate serious consideration of the most popular suggestions. There are a few different ways that those suggestions could be made; it'd be interesting to evaluate the different possible approaches. Hope that helps; sorry if it doesn't. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
Hey Denis! On Thu, Sep 1, 2011 at 1:18 PM, Denis Washington den...@online.de wrote: Am 01.09.2011 11:34, schrieb Frederic Peters: Hello all, This is 3.1.90, and it's out! It's the first beta of what will be GNOME 3.2, enjoy it while it's time, the next beta (3.1.91) will arrive next week. I saw this in the release notes of gnome-control-center: Power: - Remove power and suspend buttons config (Bastien Nocera) (#652183) (#657068) I am sad. Oh dear, don't be sad! The intent behind those changes is to ensure consistency and predictability. If we know what the behaviour of the hard buttons is going to be, we can produce better designs elsewhere and it is easier to provide users with advice and guidance. Also, we really want to be able to specify separate long and short button press actions for the hard power button (like on a mobile phone). It is hard to accommodate that kind of behaviour within a set of preferences that are easy to understand. I know that the GNOME design team has its reasons to promote Suspend; it is great from a usability perspective, and I also suspend often and like it. However, I feel that the rigor with which this is pushed upon the complete user base of GNOME (minus those are knowledgeable enough to change a hidden dconf setting) is not right. While suspending is convenient, many people do want to save power when they don't use their desktop or laptop over night, or simply because they only use it one or two hours a day anyway. I don't see this as a minor use case; its a general consideration of many, enviromentally aware people, especially in European countries such as Germany where the Green party is going strong and we are already warned about the environmental impact of standby devices in elementary school. Regardless of their technical knowledge, such people will be put off by not being able to properly shut off, or having to jump trough hoops to do so. They will think that GNOME doesn't care about the environment. I don't want our wonderful community to make that impression. I don't want to start yet another flame war with this message (please, let's be sensible and respectful when discussing this). Neither do I want to denounce the design team; in fact, I greatly respect the design team for the many things it has done to make GNOME 3 the awesome piece of software that it is today, and that it will be tomorrow. I also don't want to throw everybody from the design team in the same pot: there are GNOME designers that are sympathetic towards some kind of compromise, as the discussion around bug #652183 [1] reveals. However, I feel that the current situation is not right, and that *something* has to be done to reach a solution that combines a high degree of usability with easily accessible ways to act environmentally responsible. I honestly think that the behaviour of those buttons is a separate issue from whether they should be configurable or not. Thanks for the kind words. :) Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Empty Power panel in System Settings
On Mon, Sep 12, 2011 at 3:21 AM, Jeremy Bicha jbi...@ubuntu.com wrote: I had a bug this week where the power was screwy and GNOME briefly thought my laptop was a desktop. I was awfully surprised to see that the Power panel in System Settings 3.2 has only one item Suspend when inactive for This looks really bad. I'm not certain that autoresizing the window is a great idea but a huge empty space isn't good either, but resizing from taking up half the screen on my laptop down to an All Settings button and one option just doesn't feel right. A minimum height for the panels was recently introduced. Could do with some tweaking, maybe. The resize really needs to be animated, too. GNOME's getting criticism for cutting out options and this design seems to be accenting the emptiness of what's left after possibly too much pruning. The options haven't been removed just for the sake of it. Please see the relevant design page [1]. The mockups are up to date, and there are notes on why some of the options have been removed. There are 20 items in System Settings now, which might be recreating some of the trouble with the old gnome-control-center. I still get confused on the difference between Displays, Power, and Screen and I've been using GNOME for years. Differentiating between displays and screen is a known bug [2] that has been getting attention recently. I think there is a whole lot of overlap between Power and Screen. I agree. As others have said, I wish design had its own mailing list where I could ask questions like this not spam the whole developer list. I don't think opening a bug is a good idea when the solution isn't clear and using IRC for decision making (especially without IRC logs) excludes those who can't participate in real time during the European/American workday. No comment. :) Allan [1] https://live.gnome.org/Design/SystemSettings/Power [2] https://bugzilla.gnome.org/show_bug.cgi?id=653015 -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.4 Release Notes time - Help needed!
On Tue, Mar 6, 2012 at 12:10 PM, Andre Klapper ak...@gmx.net wrote: ... time to start preparing the GNOME 3.4 release notes to tell users, developers and press what's new and great in GNOME! This means: We need YOUR help as you know best! Please take two minutes: * What new features does your application/module have? * Any usability, performance, internationalization or accessibility improvements? * Any very important bug fixes to mention? * What are the new things developers need to know? * What is on your list for 3.6? (Plans for GNOME 3.6) Add anything that comes to your mind to https://live.gnome.org/ThreePointThree/ReleaseNotes so we can tell the world! Linking to screenshots or descriptive blogposts is also welcome. And be quick as the release is already in 3 weeks. ;-) ... Time is running out, people! If you have any changes for the release notes, now is the time to get them on the wiki [1]. We have matter of days to get the notes drafted, and there are still plenty of applications that are yet to make an appearance. Allan [1] https://live.gnome.org/ThreePointThree/ReleaseNotes -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A weather app for GNOME
Hi Giovanni, On Sun, Mar 25, 2012 at 4:00 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: Hello desktop-devel, 3.4 is almost out, so it's time to start thinking about 3.5, and how to make it even more wonderful. As a quick afternoon hack, I built a Weather app, following the designs at https://live.gnome.org/Design/Apps/Weather, and I think it would make a reasonably good Core App. You can find it at https://github.com/gcampax/gnome-weather. It depends on python 3 (tested 3.2), pygobject, gtk3 and clutter (= 1.10), plus the newest version of libgweather. For best results, I recommend the branch at https://github.com/libgweather/yahoo-weather. It implements current conditions for the entire world, plus forecast for US and Milano Linate (XD). See https://bugzilla.gnome.org/show_bug.cgi?id=672804 for details. Hope you like it, you're free to use. Ah cool! Work on new apps is great! I don't see much actual design work on the page [1] for that app... did you speak to one of the other designers about this? If you didn't, I'd suggest that you do. We want the new apps to have consistent designs. Allan [1] http://live.gnome.org/Design/Apps/Weather/ -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Seif Lotfy s...@lotfy.com wrote: ... There are 3 issues in discussion or in development where Zeitgeist integration is reaching a halt due to the uncertainty of where Zeitgeist stands: Epiphany (Web): There has long been discussions on how to deploy Zeitgeist as a backend for Web. Web needed to rethink its history problem. It ended up with developing an SQLite based history backend. Right now we are discussing replacing this backend with Zeitgeist, since Zeitgeist can do everything the SQLite backend can. plus we can add new features to Web that make use of Zeitgeist's Full-Text-Search capabilities for searching via the uri bar. We don't have a design for browser history search in Web yet [1]. Folks: I added some new properties to the individuals class in folks (currently in review). Now I could give more detail and allow the Contacts app to sort individuals by recency/frequency of interaction. The telepathy backend for this feature needs Zeitgeist. The Telepathy backend can provide even more info such as Show me all files sent to X or recevied from X (same goes for URIs). This feature was requested by Garrett LeSage from the GNOME Design team. That was considered in the Contacts design process, but it was decided that it wasn't appropriate/useful. Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. As I see also there is some ideas going around for the searching via Shell. I agree that every application should be able to provide it search results to shell (aggregated search). I think Zeitgeist could fit in there nicely to sort the aggregated results globally according to recency or frequency. There are some designs in development for shell search [2], and these have implications for how we want search results to be returned within individual applications. I don't have the expertise to comment on which technologies are required to implement those. As mentioned previously in this thread, I'd expect to see a specific feature proposal for 3.6, rather than a module proposal. A new feature might require new dependencies, of course (which you might have to justify, I guess). You could certainly propose Clocks as a feature for 3.6... Allan [1] https://live.gnome.org/Design/Apps/Web#Tentative_Design [2] https://live.gnome.org/GnomeShell/Design/Whiteboards/Search ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: finding and rediscovering shared links
On Thu, Apr 19, 2012 at 3:40 PM, Seif Lotfy s...@lotfy.com wrote: ... So a possible view for this feature can be done in Web: Links received can then be automatically put in the queue of Web. And once visited can be taken out of the queue. Another possible view would be a dialog for sent/received links for the Contacts application. To sum it up: it would be appealing to have a readitlater queue without explicit managing (well allowing that, and having those prioritized) as well as having links sent through some direct mean (IM, mail) populate it. ... Something like this could be useful in Contacts, Chat or Mail (I'm not sure about Web). However, Contacts has a long way to go in terms of basic functionality and Chat and Mail don't exist yet. I don't think we're at the point where we can start to think about this feature. I realise that you're frustrated by the lack of Zeitgeist adoption in GNOME, Seif. As I explained privately, the best way for you to pursue this is to talk to maintainers who might need it for search results. The decision to use Zeitgeist is really up to them. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 6:59 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. These issues have been discussed at length on ddl in the past [1] and I believe that the relevant features have been through the process. For the 3.4 release we had emails [2, 3] and information on the wiki [4], for example. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. I think that the community has been given an opportunity to discuss these proposals. Boxes was essentially rejected last round, if memory serves me correctly. I'm not saying that the feature proposal process is perfectly clear though. ;) Allan [1] https://mail.gnome.org/archives/desktop-devel-list/2010-April/msg00085.html [2] https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg3.html [3] https://mail.gnome.org/archives/desktop-devel-list/2011-November/msg00014.html [4] https://live.gnome.org/ThreePointThree/Features ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Design in the open
Hi all, Apologies in advance for the long mail - there was no other way. There have been a few design-related threads on the list recently. I’m going to try and reboot those discussions in a slightly different and, I hope, more constructive mode. Let’s start with the big picture - design is important for GNOME. Our project’s success rests upon our ability to design and execute an outstanding user experience. It is in all our interests to make GNOME design work, therefore - to work together to produce a consistent, integrated, well-defined, high-quality, delightful user experience. So far we have made some great progress in this direction. We have a small but thriving design community. We have successfully reorganised our development processes around design - development tends to be design led, and we now have new feature proposals each release rather than module proposals. There are very few, if any, real community projects that have achieved this feat. Members of other projects have even approached me in the past to ask how they can replicate GNOME’s success in this area. But there are challenges and things we can do better. Among those obstacles, I see: * lack of design resources - we are always trailing behind where we want to be, and there are important tasks which we are unable to complete (a new HIG springs to mind) * improving the quality of design - we can always do better * getting the project behind a common vision - we sometimes lack focus * giving people a stake in the project - the danger of design-led development is that people feel that the project is no longer theirs. They want to feel they can have an impact and that they can express themselves through their activities in the community. * design disagreements can sour relationships and lead to discord * letting people stay in touch with and understand design activities, and therefore the activities of the project as a whole * helping community members to participate in design activities Now, there have been some initiatives in GNOME to try and help make design more successful within the community. Some of those are well-known, like the design wiki pages and the IRC channel, but there have been other things too, like design office hours (remember those? nobody came), UX Advocates (also suffered from a lack of take up) and Every Detail Matters. We are also working to attract more design contributors, which the Outreach Program for Women is really helping with right now (yay!) But there is more we can do. The challenge for us as a community is to make design an even more successful part of what we do. This isn’t an easy challenge and I don’t think there are any quick fixes, but we have experience and a rich community on our side. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better testing facilities so people can test and give feedback on UX changes before release time * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Allan tl;dr version GNOME design is a community-wide effort - it is not just the responsibility of designers. We’ve got a lot to be proud of in this area, but there are also challenges to overcome. There many things that can help to make GNOME design a success, but it will require people to step up and help out. -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___
Re: 3.6 Feature: IBus/XKB integration
On Wed, Apr 25, 2012 at 2:43 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: I don't think you can infer that from the answers. I'm one of the people who said they use Compose. I don't particularly care which key it is, as long as I can reach it without taking my hands away from home row. Well, a number of people say they use Compose - a number of people say they map Compose to Menu, Capslock... Apologies, that page is a little out of date (my bad). We're currently aiming to have the compose key shortcut in the keyboard preferences, at least to begin with. I'm still keen to prioritise the 3rd level chooser, but I think we should probably move one step at a time. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Wed, Apr 25, 2012 at 9:55 AM, John Stowers john.stowers.li...@gmail.com wrote: So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Many of your suggestions seem designed to address or avoid conflict, or to convey design team decisions in a better manner. This is not the source of my confusion nor my uncertainty in how to interact with the design team. In order to piece together the rationale or even the process for design team decisions I currently browse commit logs on the gnome-design github repo, and look at comments made when changing live.gnome.org pages. Some of you tweet stuff, others scatter it on google+. You suggest even using $some_new_webapp to better collaborate on designs. While I cannot see the discussion and the evolution of design team thought (even if I have the time to piece together all these sources of information) all I see is a decision by decree when a live.gnome.org page is created which describes the final design. My suggestion is thus the same as it was the last time this thread was raised - if the design team does not want to archive discussions on a mailing list, may they please allow IRC logging on the gnome-design channel. I'm not sure how useful logging the channel will be (lots of noise, etc), but I'd be happy to give it a go. The main thing is that we shouldn't stop there. IRC logs aren't going to fix the whole gamut of challenges that we face in relation to community design. You can even be proactive and send email updates to ddl or something. I've lapsed in my design update blog posts, but I've got a new one in the works. You think emails would be better than blogging? Of course if the canonical way to interact with the design is to show up on IRC at a specific hour then, IMO, you will lose contributors. I can hack any time of night when I have the motivation and the free time. But if I want to understand why the design team did something I have to... trust them? Trust them, or ask them, or a combination of the two. (Trust comes best once you gain experience of working with people, of course.) Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Wed, Apr 25, 2012 at 6:45 PM, Karen Sandler ka...@gnome.org wrote: On Wed, April 25, 2012 9:27 am, Allan Day wrote: Echoing what Brian said, I like these suggestions for improvement! Are there any that we can turn into concrete initiatives that we can organize soon and perhaps fundraise for? Or build some initiatives for GUADEC? I include a few more detailed questions below along these lines. It'd be great to have a BoF on design at GUADEC. I'm not sure what availability would be like for doing a UX hackfest there, but we could certainly look into that. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process I think there's some confusion here - you're not talking about purely technical proposals here too, are you? I assume this is more focused on anything that interfaces with any elements of design... Feature proposals aren't supposed to be purely technical, if my understanding is correct - they should always have user-facing value (whether we should have separate technical feature proposals is a separate issue in my opinion). As such they are a natural channel through which the community can participate in design activities. * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? I think we should definitely explore this more, it goes hand in hand with the other suggestions below - helping to stop bad behavior, soothing ruffled feathers and communicating better. Absolutely - it would be great if someone wanted to do some work there. * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. thanks, Allan! I'm glad we're having these discussions and hope that we can find ways for the Foundation to help too. Me too. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Wed, Apr 25, 2012 at 10:21 PM, Allan Day allanp...@gmail.com wrote: ... * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. Missing footnotes: [1] https://live.gnome.org/GnomeOS/Testable [2] https://mail.gnome.org/archives/desktop-devel-list/2012-March/msg00094.html - I realise now that the timing of these live images won't actually help with testing UX changes (since we'll already be in UI freeze when they're ready) - that's maybe something to look at if and when we have the necessary tools ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
On Wed, Apr 25, 2012 at 2:42 PM, Federico Mena Quintero feder...@gnome.org wrote: On Wed, 2012-04-25 at 15:31 +0100, Sergey Udaltsov wrote: no way to find the audience that would be unbiased? Are you just implying that the current userbase of GNOME is so geekish that fair survey among existing users would only represent the POV of geeks? It would be very instructive to see how non-geek people configure their keyboards (if they do at all!), and how they manage to survive on an everyday basis. ... It isn't so much how people configure their keyboards as how they (a) switch between different languages/alphabets and (b) insert special characters. For (a) the CJK languages are particularly complex, and I've done a lot of talking with i18n folk (who seem to have a pretty good handle on this) for that reason. (b) is varied because there are so many ways to do the same thing, from alt codes on Windows (seem to be popular, for some reason) and option codes on Mac, to the use of character maps and the web (how else can I find that snowman unicode character [1]?). To me, this feature is the first step in a wider effort to make it easier to use different languages on GNOME and to make it easy to insert special characters. Once we've established some good defaults and sanitised our configuration options, we can start to look at other ways we can improve the experience for our users [2]. Allan ☃ [1] http://unicodesnowmanforyou.com/ [2] https://live.gnome.org/GnomeOS/Design/Whiteboards/ExtraCharacters -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Goal Proposal: Port to GMenu
Hi all, Last release we introduced the ability for applications to define a GMenu (or 'application menu'). This means that applications now have a place to locate global application (as opposed to per window) menu items. Some applications have already started to use a GMenu, and while this is great, it has also introduced some inconsistency (since some app menus have several items in them and some just have Quit). It would be great if we could improve on the current situation and ensure that all our applications present an appropriate set of items in their GMenu. I've started a GNOME Goal page [1] which we can use to coordinate this work, if people think it's a good idea. Allan [1] https://live.gnome.org/GnomeGoals/PortToGMenu -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera had...@hadess.net wrote: On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: Hi all, Last release we introduced the ability for applications to define a GMenu (or 'application menu'). This means that applications now have a place to locate global application (as opposed to per window) menu items. Some applications have already started to use a GMenu, and while this is great, it has also introduced some inconsistency (since some app menus have several items in them and some just have Quit). It would be great if we could improve on the current situation and ensure that all our applications present an appropriate set of items in their GMenu. I've started a GNOME Goal page [1] which we can use to coordinate this work, if people think it's a good idea. I'm not sure how good an idea this is given that the use of the app menu means that the application itself will require redesign. It would only be really useful for smaller applications with a very limited number of menu items, without a redesign. If an app has a complex menu bar, I'm recommending that it just moves a small number of items to the app menu (eg. new window, preferences, help, about, quit). That way we can ensure at least some consistency and prevent those oh, there's nothing there moments. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 10:23 AM, Jeremy Bicha jbi...@ubuntu.com wrote: ... I believe we were talking about keeping File/Edit/View while adding a GMenu. If so, the UI would be quite confusing if some things were taken out of the normal File/Edit/View menus. If all we're talking about is how Epiphany 3.4 works, then that's fine but that's not how I read what was written. ... In some cases there will be a GMenu and a menu bar (with File/Edit/View...) for the same app, at least in the short term. I think that's less confusing than the current situation, in which: * some apps have items in their GMenu and some don't * global application options don't fit well into existing menu bar structures (eg. 'Quit' in 'File', 'Preferences' in 'Edit') We were criticised for the lack of consistency between app menus in several reviews of the 3.4 release. I would like to avoid that for 3.6. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: ... So, IMHO a design driven GNOME needs good desing documents. The design document is a written contract[4] between designers and other teams, more time you spend writing it, less time you'll spend explaing here on desktop devel list :) ... For me, design in the open is about developers and designers working together as partners, not hyper-specified design documents. That might not give observers as much to see, but it provides contributors with a real opportunity to shape our project. That's not something I would want to take away. GNOME design is often misunderstood as creating specifications that are handed down on tablets of stone. That's not the way it works - each design is typically the outcome of a process of iteration, and we keep on iterating right through the development process. PS * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? hmm disagreement between ... ? designers and maintainers? designers and contributors? designers and i18n/doc/a11y team? designers and users? designers and release team itself? Whoever and whoever. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About fast dial contacts in Overview mode
Hey Petris, pec...@gmail.com pec...@gmail.com wrote: Hi everyone! Since GNOME Shell 3.2 I love feature of overview accessing contacts database and looking up their status. However, while I understand reasoning to have default behaviour to just open entry in Contacts app, I would like to have fast access to some kind of mini menu with communication methods to choose from - like, open conversation with this contact right now, or make a call - without opening Contacts app. What core design people/Empathy people think about such posibility? ... That could be nice. We're already discussing the possibility on Bugzilla [1]. Feel free to subscribe to the bug or to chip in. Best, Allan [1] https://bugzilla.gnome.org/show_bug.cgi?id=657715 -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Fri, May 4, 2012 at 12:19 AM, Federico Mena Quintero feder...@gnome.org wrote: ... As a way to solve these issues, I'd like to follow up on an idea which I sketched during last year's Desktop Summit - namely, about constructing a pattern language for Gnome's design based on the good things that what we have and what other systems have done well. ... Better documentation would definitely help people to get involved and understand what's happening. I was working on a new version of the HIG [1] for a while (that is structured around design patterns) and Jimmac has even written a new site for it, but we just haven't had the time to finish it. Allan [1] https://live.gnome.org/Design/HIG -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 7:15 AM, Andrew Cowie and...@operationaldynamics.com wrote: On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: It would be great if we could improve on the current situation and ensure that all our applications present an appropriate set of items in their GMenu. Is there a reference application doing this right? There are two paths available to applications - (1) replace the menu bar entirely, or (2) move some items to the app menu. For (1), the calculator [1] is a good example. For (2), I'd recommend checking out Nautilus [2]. I'm happy to give design advise on any specific examples. Just file a bug and cc me. I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. ... Epiphany is a slightly unusual case, since it's in the process of transitioning to Web. (The gear button menu isn't in the Web mockups.) The best way to prevent those 'oh' moments is to be consistent in the placement of menu items like preferences (that item should always be in the app menu). The sooner we can get every application looking and behaving the same way, the better. Allan [1] https://bugzilla.gnome.org/show_bug.cgi?id=674529 [2] https://bugzilla.gnome.org/show_bug.cgi?id=674532 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 12:41 PM, Matteo Settenvini matteo...@member.fsf.org wrote: Il giorno lun, 07/05/2012 alle 16.15 +1000, Andrew Cowie ha scritto: I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. On this note, I have to say it was quite difficult for me at first to figure out there was a menu hidden under the activity title you see on the Shell bar. Back in 3.0 and 3.2 days, it contained only a Exit item for all apps I can remember of, and even then, I only discovered it by mistake - I did not think it was clickable, only a visual current-application title. Right, so this is another reason why it is important for us to ensure that the app menu is always populated. As this functionality becomes universal people will discover it more quickly and we can do more to advertise it to users. Add to this that most applications present already with a menu bar inside their window, and it really is hard for a user to figure out there is a menu *outside* the window. Maybe it's only me (I always found the Mac OS X approach counter-intuitive too), but having to search menus in two places isn't ideal. I think that all of this can be overcome with consistency. Users just need to learn the new structure. Also, if I have two apps side-by-side, I need to change the current focus to click on the GMenu. Is that so terrible? So, some consistency is needed, I'd say. Or else instead than one place for menus, we end up with two places for menus. And with apps like Evolution, that have a lot of menu items, I am not entirely sure it is feasible to move them under the upper GMenu. ... It's ok to have items in two places, provided we do it in a predictable way. Having app menus that are located in the top bar is fantastic with the new app designs. On average size displays and below, they are superb with a maximised window that has had its titlebar removed. They also mean that everything in the window can be context bound, with the toolbar adjusting to the content that is below. As more of the new apps start coming through, these advantages should start to be readily apparent, and it's encouraging to see new apps like Clocks, Photos and Videos starting to emerge. We can't redesign all our apps all at once. What we can do is concentrate on new core apps now and update existing ones to be consistent where possible. In the future I would hope that we can get all our apps to the stage where they more strongly benefit from new parts of the UX like the app menus. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 5:24 PM, Evandro Giovanini efgiovan...@gmail.com wrote: On Mon, May 7, 2012 at 12:51 PM, Xan Lopez x...@gnome.org wrote: On Mon, May 7, 2012 at 8:15 AM, Andrew Cowie and...@operationaldynamics.com wrote: Is there a reference application doing this right? I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. The way it was designed is that things related to the application as a whole go in the application menu, things related to the particular window you are in go in the gear thing. I'm not sure about what you mean exactly with Epiphany has no menu in any case. Presumably that's not quite what you're aiming for. Perhaps you can suggest a current GNOME app that *is* doing precisely what it is you want us all to do? The design we have is not exactly like what it's implemented, since there's a few things in the gear menu that should not be there. The fact that there's a global app menu and a window specific menu is implemented as designed, though. I think having two different super menus could be confusing, the distinction between application and window is not something people think about. An example of how this can be a problem is the View as List/Grid menu items in Documents. These exact same options exist in Nautilus, but they would live in the menubar or a super menu instead of the appmenu. Per-window/per-app makes sense from a technical perspective but it's not a natural to users. The menu that is currently in the Web toolbar contains a fairly broad array of items, as reflected by the cog (or gear) icon that labels it - it basically means 'do something'. If I understand them correctly, the mockups [1] call for something different - a share menu. This would have a much more focused role and its scope would be clearer. It would also only be shown when displaying web pages rather than the 'pages' view - ie. it is contextual and displayed on-demand (as opposed to the cog menu that is always shown). This distinction between app menus that are global and always available and focused options that are displayed on-demand when context requires it is a key one for the design of the new applications. So in this case, I don't think the distinction between the app menu and any other menus is ambiguous (as designed, at least). Allan [1] https://live.gnome.org/Design/Apps/Web/#Tentative_Design -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: finding and rediscovering shared links
Seif Lotfy s...@lotfy.com wrote: I created a new wiki page for this. Hylke and Garrett have been helping out on the idea and the design. https://live.gnome.org/ThreePointFive/Features/FindingAndRediscoveringSharedLinks I'm confused. Your original proposal for this feature was to add functionality to Web or Contacts. Now you are talking about a new application. What exactly are you proposing? Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Wed, May 9, 2012 at 4:21 PM, Frederic Peters fpet...@gnome.org wrote: On Fri, May 4, 2012 at 4:54 PM, Andre Klapper ak...@gmx.net wrote: Lionel proposes to consider merging the login screen and the lock screen as both are about logging in. In the end Allan wrote let's continue some place else. Did this conversation continue somewhere, and what were the results? ... We had a chat, nothing major to report though. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
Frederic Peters fpet...@gnome.org wrote: Jasper St. Pierre wrote: We only have the development resources to ship one input method. It's going to need special code to integrate with Clutter and the St toolkit. If IBus is bad right now, we need to fix it. Or use fcitx instead of IBus? I honestly do not know the topic, but I read the emails from Marguerite Su and believe she brought important points. I'd like to understand what are the plus points of IBus today. I can't provide a technical comparison. What I can say is that I have established a productive relationship with the iBus team as I've worked on this feature, and I've had some productive (and quite detailed) design conversations with them. They seem committed to making iBus work with GNOME, and are are working towards that end. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: application menu design - contributing to the wiki on live.gnome.org
Hey! Feel free to use the playground space for your ideas. That's what it's there for. :) Allan On Wed, May 9, 2012 at 5:00 AM, Pigeon Lips pigeonl...@gmail.com wrote: Hi All, a very friendly person on the gnome IRC put me on this mailing list. Long story short i wanted to add an article to your design wiki https://live.gnome.org/Design/Playground but thought it best to run it by someone first. after reading this https://live.gnome.org/Design/Whiteboards/Menus i was inspired by the mega menu. I would like to try a mock up of extending this concept further and wanted a place to post my thoughts, mock ups and suggestions on how a nice mega menu could be extended via search and context driven actions. Is this an ok thing to do, or do i need to flesh out the idea here first ? thanks. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: live image
Hey Ray, Ray Strode halfl...@gmail.com wrote: ... I put together a live image with a jhbuild built in it here: http://ftp.acc.umu.se/pub/gnome/misc/testing/GNOME-3.5.1-LiveUSB.iso ... It's a little hacked together, at the moment. I'd like to get the process I used more refined and potentially automated so we can do testing more easily and regularly through the development cycle. ... Automated builds would be fantastic; I'm sure they would improve the quality of our releases. Thanks for working on this. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: taking features away (compact view removed from Nautilus)
Adam Dingle a...@yorba.org wrote: I realized recently to my surprise and dismay that the compact view has been removed from Nautilus: Adam, if you wanted to discuss this change, you could have done so on the bug or on the Nautilus mailing list, or by asking on #gnome-design. I would have been happy to have given you some background on why the decision was made. Jon has been doing some fantastic work on Nautilus recently. It was getting very little - if any - developer attention and he has stepped up to make dramatic improvements, including addressing long-standing complaints. I'm really excited about the next release of Nautilus thanks to his work; instead of having no movement whatsoever, we are going to have lots of great improvements to talk about. There has been a bunch of discussion around these changes. Not the mailing list approach that you seem to want, but the existing Nautilus maintainers have been involved and a range of design people have been consulted. I personally agreed with removing compact view - I think it's a good change. ... I'd like to end on a constructive note. I propose that GNOME adopt the following policy. No major feature will be removed from a core GNOME application before a discussion has occurred on a public mailing list such as this one (or on a Bugzilla bug, with a prominent mailing list announcement pointing to the bug in question). I also propose that all such feature removals that have occurred in the 3.6 development cycle be reverted until such discussion has occured . I strongly disagree with that suggestion. I don't think it would be workable, and I don't think it would make GNOME a better place to work. There is still time to discuss changes that have been made; we don't need to wrap ourselves up in policies. The features in core GNOME apps are the result of years of hard work and consensus building by our community. ... There is no consensus. There are features that some people have gotten used to, and there has been a long period of adding features without considering how they fit into the whole. No one objects when you add a feature, yet features can ruin a design if you keep adding them. Nautilus has been at saturation point for a while; it's at the stage where it's actually very difficult to improve it without taking something away. Allan -- 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: taking features away (compact view removed from Nautilus)
Federico Mena Quintero feder...@gnome.org wrote: ... The anti-pattern for both removals is like, there's some peeling paint in this house - let's bulldoze the neighborhood. ... How do you know that was the reason for the decision, if the background hasn't been explained? The anti-pattern for that statement is like, assuming motivations out of ignorance. I'll let Jon speak for himself. However, I can at least give you my personal design opinion on the issue. First of all, I do think that compact view is problematic, and I don't see any why we shouldn't remove UI if it isn't of sufficiently high quality. Some issues with compact view: * Horizontal scrolling is unergonomic with mouse and touchpad input * It is hard to scan multiple columns when they scroll, and it is difficult to find a particular item in an alphabetical list if it wraps over multiple columns * Filenames have a tendency to become truncated, and filenames also disappear off the side of the screen. The other reason why I think it is good to remove compact view is that it is inelegant as a solution to users' needs. List and icon view have clear roles and are easy to communicate to users. Grid view prioritises visual representation of files. List view focuses on finding my name. With these two options we offer a clear and straightforward choice. Compact view doesn't fit neatly into our existing functionality. It overlaps with the list view (since it focuses on finding by name), yet it misses some of its advantages (such as the ability to easily reorder the list). It also overlaps with zoom, which is the standard way to display more items at once. I'd much rather offer two, clearly differentiated views that work well, rather than have three poorly distinguished options, particularly when one of them has serious usability issues. Allan -- 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: GNOME Games split
Robert Ancell robert.anc...@gmail.com wrote: I wonder: are you looking for maintainers for any of these games, or are you going to take charge of all of them? Also, are any of these deemed to be core right now? We're currently discussing the maintainership of them at the moment: https://mail.gnome.org/archives/games-list/2012-October/msg1.html Short answer, I think if anyone was looking to maintain a project (e.g. someone who is learning GNOME) then they'd be very welcome. Sounds great. Regarding which ones are core, I was waiting for you to ask that :) Well, it really depends on what we want for the default install. I agree we want a smaller set of higher quality games. ... ... this indicates to me that people like tetravex, lightsoff, mahjongg, aisleriot, chess, sudoku. In Ubuntu we ship aisleriot, mahjongg, mines and sudoku. In terms of the games that are in the best code state and thus easiest to improve the design of we should look at tetravex, lightsoff, mahjongg, chess, swell-foop, mines, iagno, quadrapassel. Sudoku and five-or-more are in progress being updated. So, I think we should decide based on the following: - A range of games that cover easy games that children can play to difficult puzzles suitable for adults. - Games that are modern and fun - A small enough set that can be effectively maintained and improved to keep standard high - A small enough set that can be effectively browsed from the shell When I looked at this last, I came up with the shortlist of aisleriot, sudoku, iagno and tetravex. These seem to cover the categories you describe above. They also have concepts that are clear and easy to pick up. While people might like mines, I don't think it makes a good default game: it seems rather archaic. One of the things that all the games need is distinctive, high quality graphics. They should all look great and have an individual visual style. If there are any budding graphical or visual designers out there, this would be a great opportunity to contribute. Allan -- 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: Icons in notification area
Hey Dulek, We don't encourage minimize to tray or similar patterns for GNOME 3. That was always a big usability problem in GNOME 2 and we're trying to make things simpler and easier to use. In general, applications should have a visible window while they are running, although there are minor exceptions to that rule. If you have a specific application in mind, just get in touch (either privately or on the list) and I'd be happy to offer some advice. You can also see the porting guidelines for apps that tended to use the system tray in the past [1]. Allan [1] https://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility On Wed, Oct 31, 2012 at 12:34 AM, Dulek michal.du...@gmail.com wrote: How to *correctly* insert application icon into notification area of Gnome 3? Is using it as tray acceptable? If not, where should I put app that should stay hidden (like IM's, Transmission or other daemon-like applications). ___ 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: GNOME Games split
Thomas H.P. Andersen pho...@gmail.com wrote: When I looked at this last, I came up with the shortlist of aisleriot, sudoku, iagno and tetravex. These seem to cover the categories you describe above. They also have concepts that are clear and easy to pick up. While people might like mines, I don't think it makes a good default game: it seems rather archaic. I guess this needs to be finished - I say since no opposition then just let the design team (i.e. Allan) here decide. I would suggest reconsidering mahjongg, imo it's one of the nicer looking games and it plays the best on touch devices. Thomas - do you want to update jhbuild? Sure I can do that this week. Allan, is the list final? The list I came up with was fairly tentative, but I'd be happy to go with it if there aren't any opposing views. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Games split
Allan Day allanp...@gmail.com wrote: Thomas H.P. Andersen pho...@gmail.com wrote: When I looked at this last, I came up with the shortlist of aisleriot, sudoku, iagno and tetravex. These seem to cover the categories you describe above. They also have concepts that are clear and easy to pick up. While people might like mines, I don't think it makes a good default game: it seems rather archaic. I guess this needs to be finished - I say since no opposition then just let the design team (i.e. Allan) here decide. I would suggest reconsidering mahjongg, imo it's one of the nicer looking games and it plays the best on touch devices. Thomas - do you want to update jhbuild? Sure I can do that this week. Allan, is the list final? The list I came up with was fairly tentative, but I'd be happy to go with it if there aren't any opposing views. Some thoughts on this... From a design point of view, a core application is one that is preinstalled and cannot be removed. It is a part of the system. In that respect, it might make sense not to have any games in the core application set - games are something that people may well want to remove, and it is hard to see them as being a part of the system. The problem with this is that we don't have a very good application installation story. If it was easy to browse what games are available and see which ones are popular and highly rated, then the idea of not preinstalling applications becomes much more appealing. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
Matthias Clasen matthias.cla...@gmail.com wrote: to be fair, I'd envision this as a completely separate session that you need to install and select, similar to what Ubuntu does — especially if we want to call it GNOME Classic. Agreed. I don't think a separate session will work very well for this - for one thing, setting this up will require a number of settings to be tweaked (e.g. the one for the minimize button), and alternative sessions don't have the right infrastructure for that. A separate user session would be the best user experience, IMO. The session chooser on the login screen is not the best designed part of the login experience either. That's a non-argument. We can improve it. The Tweak Tool is *completely* the wrong place for this. In what way is completely changing the shell a tweak? How does it make sense to be able to completely change the experience using a setting that is included in a non-core application, and which could later be removed? What kind of experience will you get when the shell transitions to classic mode right in front of the user's eyes? The Tweak Tool shouldn't have anything to do with extensions. They are something that you install and run as a part of the system, not something to be tweaked via settings. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
Florian Müllner fmuell...@gnome.org wrote: ... The Tweak Tool shouldn't have anything to do with extensions. They are something that you install and run as a part of the system, not something to be tweaked via settings. While I agree with you that gnome-tweak-tool (and package managers (*)) are not the right place for extension management, I don't think this is much of a concern with the matter at hand - as I understand it, extensions are merely an implementation detail here and not exposed to the user (except that they should also appear separately on extensions.gnome.org, so users don't have to switch their system over entirely if they only care about one or two tweaks). As mentioned briefly above, I'd still assume an implementation based on extensions even if we are going for a separate session. ... (*) not to mention an extension management extension - I wish I was kidding Yeah, we sorely need a way to locally enable/disable and uninstall extensions. This should be built into the core, somehow. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: steam games
Sriram Ramkrishna s...@ramkrishna.me wrote: ... What do people think about this? If there is agreement what would be a good way to track? Worth having a GNOME Goal to track this? Seems worthwhile to track this. How many bugs and affected modules are we talking about here? Allan -- 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: steam games
Sriram Ramkrishna s...@ramkrishna.me wrote: Certainly, the first one I filed is this one: https://bugzilla.gnome.org/show_bug.cgi?id=693551 ... I found it a surprisingly smooth experience given its early stage. I have however spotted one issue: Adjusting the master volume in-game via the corresponding multimedia keys results in green screen flickering. This is due to the speaker icon fading in and moments later out. Not sure if GNOME can play along nicely here. You should file a bug for tracking purposes. It's important that we get the games experience right and doing QA'ing is important. This is why I was so excited about the continuous test builds. Because I think we want to get new images out there for people to test so that we can improve the quality. Seems like a small enough number of bugs to warrant using a tracking bug (probably against gnome-shell) rather than a GNOME Goal... Allan -- 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
Release Notes Time!
Hi all, It's that time again! GNOME 3.8 is due for release on 27 March: that means we have about two weeks to get the release notes fully written - that's not much time at all. Enter a trance-like state. Cast your mind back over the last six months. Ask yourself: is there anything I have done that will benefit users, developers or administrators? Come back to the world and write it down on the release notes wiki page [1]. Be happy. The sooner we have this information the better, so please don't delay. Thanks in advance, Allan [1] https://live.gnome.org/ThreePointSeven/ReleaseNotes -- 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: Possible to fix glaring Gjs API issues before GNOME 4?
Javier Jardón jjar...@gnome.org wrote: On 28 February 2013 08:26, Dan Winship d...@gnome.org wrote: But it seems like it would be a good idea to start explicitly noting planned future ABI breaks in some way, somewhere, so nothing gets forgotten when it does come, and so people can see the big picture more easily. In GTK+ this is done by marking bugs with 4.0 as target milestore [1] We should also be tracking and targeting any gjs binding issues. We really need the new applications to be clearing the way for those who want to follow, rather than working around deficiencies in the platform. One issue I know of is the lack of introspection support in libcanberra [1]. I bet there are others... Allan [1] https://bugs.freedesktop.org/show_bug.cgi?id=32587 -- 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: Release Notes Time!
Some of you have been awesome and have given me nice notes on what you did over the past 6 months. The rest of you are very bad people. There is time to redeem yourselves, but the window of opportunity is closing. Allan -- 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: Release Notes Time!
This is your final call! The Release Notes are pretty much done and I'm looking to get them nailed down at the beginning of next week. If you have anything that should be included and isn't [1], please fill in the wiki page [2] asap. Allan [1] https://git.gnome.org/browse/release-notes/tree/?h=gnome-3-8 [2] https://live.gnome.org/ThreePointSeven/ReleaseNotes -- 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: Bijiben
Hi Pierre-Yves, Pierre-Yves Luyten p...@luyten.fr wrote: On Tue, 12 Mar 2013 17:31:21 +0100, Andre Klapper ak...@gmx.net wrote: (...) Still we *highly* encourage you to communicate your plans for your projects early. I'm requesting a new module inclusion : Bijiben It's another note taking application [1] - goal is to implement Notes design [2] Thanks for your work on Bijiben so far: it is coming along very nicely! Pierre-Yves has done a great job implementing the Notes [1] design, which is intended to provide a core application for note taking. There are still a few rough edges but I'm hopeful that we can work those out over the next release and have something solid ready for 3.10. Allan [1] https://live.gnome.org/Design/Apps/Notes -- 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
GSoC Internship Ideas
Hi all, Marina mentioned to me that we still need more ideas for this year's GSoC [1]. If you would like to mentor someone, please get in touch: it's really important that we have enough mentors and internship ideas. If you are willing to be a mentor but aren't sure about what you'd work on, I have a bunch of ideas that might be of interest: - A typing break app - we lost the old typing break setting in the jump to 3.x. Having a break timer app would be a nice replacement - https://live.gnome.org/Design/Apps/Potential/BreakTimer - Multimonitor bug fixing - we have lots of multimonitor bugs, and I'm sure that we could bundle some of them together to make a nice project - https://live.gnome.org/Boston2012/Multimonitor - PackageKit bug fixing. I think that Jon has a bunch of UX bugs that - could make a nice project. - Application paging in the overview - this will work better with the new folders, and will help with spatial memory. See https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/application-picker/centered-grid3/vertical-pager.png for one idea of how it could look - Implement Cheese redesign. Cheese needs a bit of love, and we have some mockups that we could work from - https://live.gnome.org/Design/Apps/Cheese - Avatar selection - this would be an avatar selection dialog that could be used by Initial Setup, Contacts, User Accounts and Chat. We could also try and pull avatars from online accounts (which might be a good project in its own right). See bug - https://bugzilla.gnome.org/show_bug.cgi?id=687871 - A new time and date panel for the control center. We have mockups for this: https://live.gnome.org/Design/SystemSettings/DateAndTime - Contacts - I could easily come up with a list of UX bugs. We've also talked about offline editing being a potential internship. - Transfers - this is intended to be a kind of integrated download and transfers manager. It would provide the UI for downloads from Web, transfers from Chat and copy/move operations for Files: https://live.gnome.org/Design/Apps/Transfers Let me know if you're interested in mentoring any of these. Allan [1] https://live.gnome.org/SummerOfCode2013/Ideas -- 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: What can you tell new about Content Selection?
Hey Dylan! Dylan McCall dylanmcc...@gmail.com wrote: I remember reading about a goal for GNOME called Content Selection. One of those new-fangled content applications like Files, Photos or Documents would be available as a Content Selector (much like a file chooser dialog) for any other application. Here's Allan Day on the subject, and a wiki page: http://afaikblog.wordpress.com/2012/05/10/gnome-design-update-part-two/ https://live.gnome.org/GnomeOS/Design/Whiteboards/ContentSelection Me and Jon were investigating this for a while, but it is dependent on us having each of the content applications (Documents, Music, Videos, Photos, Transfers) in good shape - so it is more of a long term idea at this stage. Now, first of all, I guess I'm wondering if this is on a roadmap somewhere, or if it's just an idea at this point. Either way, this is something I have been very interested in for some time, and I've been meaning to play with GNOME a lot more, so I would really love to do something to help make it happen :) It might be too early to implement it for real. That said, there's plenty of scope for exploration and prototyping. It would be great to see how the idea might perform in practice. Is somebody working on Content Selection at this point, and do you think it would make sense for a student to contribute to that as a GSoC project? (Willing mentors, etc?). Who should I talk to? Any help is greatly appreciated. Some of the content applications could make good internship projects. I know that we already have some interest around Music and Transfers, for example. Otherwise, I'd recommend speaking to Jon McCann and Cosimo Cecchi. They both have a good idea of where we are heading with regards to how content is handled, and I suspect that there will be a few different things that will need to fall into place before we can tackle content selection itself. One of them may well be interesting to you or to interns. Allan -- 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: [GSoC '13]Gnome Tweak Tool UI Refresh Project
Hi Vishrut, I came up with some wireframes for the Tweak Tool [1], which I'd be happy to discuss. You should also make contact with John Stowers, who is the Tweak Tool maintainer. Best wishes, Allan [1] https://raw.github.com/gnome-design-team/gnome-mockups/master/tweak-tool/tweak-tool-wireframes.png On Sun, Apr 14, 2013 at 4:47 PM, Vishrut Mehta vishrut.mehta...@gmail.com wrote: Hello, I am Vishrut Mehta, a second year students at International Institute of Information Technology, Hyderabad, India. I have been contributing to Opensource organizations since December, like Sahana Software Foundation and E-cidadania. You can have a look at my github profile: https://github.com/VishrutMehta and also have done several other projects related to Python. I am interested to work with GNOME and try to implement the Tweak Tool UI Project. I have much experience in UI design and Python implementation. I want to discuss with you how we can do this project and what are the prospects of the project. Eagerly waiting for your reply. Thank You!! Regards, -- Vishrut Mehta International Institute of Information Technology, Gachibowli,Hyderabad-500032 ___ 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
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
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
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
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
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
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
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
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: 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]
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: 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: GNOME throbber inconsistencies?
Hey Marco, Marco Scannadinari ma...@scannadinari.co.uk wrote: The GTK+ throbber is a dotted animation, but the one used in clutter apps / UIs use a different icon - instead of dots, it uses longer lines. Is this a design decision? If it is please consider the points made below: - It is inconsistent without an obvious reason as to why this is - The clutter-themed throbber is also used in the Adwaita cursor theme (forked from DMZ-Black(?)), and with the lines which are thicker than the dotted GTK one, it makes the cursor look excessively cluttered (pun not intended), especially in the in progress cursor (I don't know what it is called, but it is the one in between the (O) loader, in Windows it is the Hourglass, and in OSX it is the spinning beach ball, and the normal cursor. It is basically the normal cursor with the circle attatched. It takes up nearly all space in its allocated circle). See the second and third cursors from the following link for case in point: http://codzoyer.deviantart.com/art/Adwaita-Cursors-for-Windows-208885897 In my opinion, I think the throbbers should be consistent on all UIs - if this is to happen, then the GTK one should be used because of the second point outlined above. Again, is this a design desicion? ... I agree that the throbbers should be the same. The inconsistency is because of a technical issue - the use of dots was the result of using CSS and requiring scalability. A fix has been discussed in the past, apparently. Cosimo or Benjamin can tell you more about the specifics. Allan -- 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: GNOME throbber inconsistencies?
Marco Scannadinari ma...@scannadinari.co.uk wrote: Cosimo or Benjamin can tell you more about the specifics. Thanks. By Cosmio and Benjamin, do you mean Cosimo Cecchi and Benjamin Otte? I do indeed. :) (I was kinda hoping that they'd chime in.) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME throbber inconsistencies?
On Thu, May 2, 2013 at 4:44 AM, Cosimo Cecchi cosi...@gnome.org wrote: On Wed, May 1, 2013 at 5:04 PM, Marco Scannadinari ma...@scannadinari.co.uk wrote: I think using the very nice throbber by the Tango people would look a lot nicer and reduce the work (?) needed to standardise the throbber sizes in GNOME. ... I'm not sure which is the Tango throbber you're referring to... I presume we're talking about the one that is part of gnome-icon-theme [1]. That was quite nice, but it looks a little old fashioned. More than that, it assumes a grey background and wouldn't scale to larger sizes, so it's not a good choice. ... Im sure there's a lot I'm missing, but the ideal scenario (for me) is to revert to the Tango throbbers and subsequently their DMZ-* cursors as well. Not to be rude, but does anyone know why the cursors were forked from DMZ? (Apart from it needing to be black, but there is a DMZ-AA / DMZ-Black anyway...) I'd be pretty surprised if DMZ has been forked. Jakub Steiner, who designed DMZ, is one of the current gnome-themes-standard maintainers, and I'm not aware of any changes to the pointer theme. Allan [1] https://git.gnome.org/browse/gnome-icon-theme/plain/gnome/48x48/animations/process-working.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
