Re: Header Bars GNOME Goal
Jens Georg wrote: > gedit ist marked "to do" but green so either the colour is wrong or the > "to do" :) Still not done, but I'm hopeful that we can have a snazzy updated gedit for 3.12. :) I've updated the wiki page. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Header Bars GNOME Goal
Hi everyone, As you probably know, we ported a lot of apps to use header bars for 3.10. These have been working really well, and feel like a big improvement. However, not all of our apps are using header bars, which creates a consistency problem. I've started a GNOME Goal page to address this: https://wiki.gnome.org/GnomeGoals/HeaderBars It would be fantastic if we could work together to get as many apps as possible using header bars for GNOME 3.12. Please let me know if there is anything missing from the wiki page. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, "dumbing down" Slashdotted
Mathieu Stumpf wrote: > There's a pdf document somewhere about gnome design foundations (I can't > find it now, but probably I found it on [2], You're probably thinking of Jon's old GNOME Shell design doc [1]. > where you can read a quote > which states something like "be usable for new users, hackable for power > users, > but optimize for middle users". It reads: "Design a self-teaching interface for beginners, and an efficient interface for advanced users, but optimize for intermediates." Allan [1] https://people.gnome.org/~mccann/shell/design/GNOME_Shell-20091114.pdf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, "dumbing down" Slashdotted
Ray Morris wrote: >> Not be be a jerk, but can you seriously post that with a straight face? ... >> didn't turn up anything about the middle mouse button until last week >> and that bugzilla has several people begging that the behavior not be >> changed. I don't see how that can be considered a "proposal" or "discussion" > > The bugzilla commit completely disabled middle-yank, so yes that appears to > be a proposal to change the behavior. > It was temporarily reverted with the message "we'll defer this change until > the next cycle". The way that's > worded, it sounds like it's not just a proposal to do so, it's a decision to > do so. > > According to the record, what we had was a commit that actually eliminated > the functionality (by default), > followed by _discussion_ (Mathias' word) between Mathias, Allan and Jakup to > delay it. The committer certainly > considered it a "discussion", that's what he called it. You may disagree > with his wording, but I suspect he > did in fact post that with a straight face. When we discussed this, we talked about a range of things that we want to address in the 3.12 cycle, including a fleshed-out design for text selections, new text insertion functionality, and the need to have public discussion. It certainly wasn't simply a question of "should we remove it now or in 6 months time?" Hastily written one line commit message won't give you much insight, and will always be misleading if you read too much into them. So again - please don't jump to conclusions, and give us chance to publish a more detailed plan. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, "dumbing down" Slashdotted
Bill Nottingham wrote: > Large changes in terms of the interaction paradigm, such as the switch from > GNOME 2 and GNOME 3, can be problematic for users, but by presenting them > with a very different interface, it can essentially 'force' a retraining, > that can be assisted by docs, introduction videos, explanations of why the > big change, and so on - "here's the new method, learn it, and go." > > Continual iterations in terms of the feature set is a great thing for users; > things like "I upgraded and now I can add my GMail contacts", or "this new > music player is much better" are great, and add value. As they are > generally either additive in nature, learned as a new application, or > interacted with in fundamentally equivalent ways (such as the new status > menu), they don't have a lot of cost of adaptation. > > Continual iteration *in terms of the interaction paradigm*, is incredibly > user-hostile, though - it looks pretty much the same as before, so they > attempt to interact the same way as before. But scrollbars now act > differently. Or their middle mouse button might behave differently. Or the > menu for some of their applications moved entirely to someplace it wasn't > before. Etc. And if this happens with a different minor thing with each > release - they get gunshy. And they start saying "Oh what did GNOME break > now?" To quote Christina Wodtke - "User don't hate change. Users hate change > that doesn't make anything better, but makes everything have to be > relearned." And the "doesn't make anything better" is in the user's mind - > it's where the value needs to be communicated to. Sticking to the topic of text selections specifically (since general discussions on mailing lists are the road to hell) - we won't make changes in this area unless there are clear benefits to users. I think there is a compelling case to be made for improvements to text selections, and it is something that people will appreciate. I also think we can make changes without too much disruption. The devil will be in the detail of course, and we'll have to wait for the designs to be fleshed out before having a serious discussion. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, "dumbing down" Slashdotted
Tomasz Torcz wrote: >> You're making an argument about simplification in a thread about >> middle-click, but the designs for what might happen to middle-click >> have neither been finalised nor publicised. I think it would be better >> to wait until the text selection designs have been documented before >> we discuss it. :) > > I think ”have not been publicised” is the exact pain point of design > process. Wider community has no insight into design until it's > finished. And it's too late for a meaningful input at that point. The designs haven't been publicised because they are not sufficiently developed, and as such have not been documented. Once they are there will be opportunity for discussion. Just because a design is documented does not mean that it is fixed, and I fully expect that the designs will be changed as a result of public discussion. That's what happened with the system status menu last cycle, and I think that the resulting design benefited. I see no reason why the same process should not be effective in this case. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, "dumbing down" Slashdotted
Ray Morris wrote: > Allan Day said: > >> You're making a lot of assumptions here. When this story broke it was >> on the basis of two commits, and had no other background information. > > I've read some of the discussion. The news stories did pick up on context > menu, making it a non-default setting, etc. > It does appear that there is additional background I haven't located any > record of. I'm not making any assumptions > about what that may be. > I have read discussion of making things easier for new users, the key word > "discoverable" > is used more than once on the page about the proposal, etc. Which page? Which proposal? > Based on the available background, I'm pointing out a > principle that is true globally. > > For any system that will be used many times, over a period of time, it is > false economy > to make it simpler in the beginning by making it harder in the long run. > > The interface we're using right now, English, is a great example. Suppose > someone proposed simplifying English so > that it could be learned completely in six months, that we remove any words > or language constructs not used by > six-month-olds babies? That would of course be ridiculous. We want the > interface we're using to be deep, to have more and > more power we can discover over time. Just as young children learn "mama", > then later learn "maternal", new users can > use ctrl-c/ ctrl-v, until they learn more. (Though ctrl-c is of course a > _terrible_ habit on Linux. The same keystroke is used both > for copying data and for immediately killing the program with extreme > prejudice, losing all data.) You're making an argument about simplification in a thread about middle-click, but the designs for what might happen to middle-click have neither been finalised nor publicised. I think it would be better to wait until the text selection designs have been documented before we discuss it. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, "dumbing down" Slashdotted
Ray Morris wrote: > Middle click got Slashdotted. Some of the comments on Slashdot may be of > interest: > http://linux.slashdot.org/story/13/09/24/1252243/middle-click-paste-not-for-long Must be a slow news day. That story is almost a month old. > It seems to me that one should be careful of any change that may, in a few > cases, make things simpler for users while they are new, > at the expense of reducing functionality for the next 20 years, when they > aren't new anymore. If wanted SIMPLE interfaces, we'd > all use baby talk. We use English to interface with each other because we > want a POWERFUL interface, even if we spend a lifetime > discovering new ways it can be used. You're making a lot of assumptions here. When this story broke it was on the basis of two commits, and had no other background information. In fact, it was precisely because we hadn't had chance to document, discuss, and fully elaborate our plans that we reverted the change. Before you go jumping to conclusions, you might want to wait to hear what we're actually hoping to do in this area. Contrary to what is being said, we are not simply planning on removing middle click paste, but I guess that detail doesn't make for interesting news stories (no one contacted us to ask what the real story is). We'll be working on a round of designs during the next development cycle, and there will be opportunities for discussion and feedback. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Check your header bar styling
Ewgeny B wrote: > I have just tried gnome-clocks out after rebuilding gnome-themes-standard. > Iirc we have no styles set for the header bar, and the new look appeared in > clocks seems to me like a change from bad to worse:( as a general look as > well as due to height changes in all modes: standalone, selection and > standard, respectively. The height issues are separate bugs, I think [1, 2]. Allan [1] https://bugzilla.gnome.org/show_bug.cgi?id=706515 [2] https://bugzilla.gnome.org/show_bug.cgi?id=706431 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Check your header bar styling
Hi all, As many of you know, we've been making a push to use header bars for 3.10. As a part of this, we have been making a few changes to how styling works. Four changes were committed today [1, 2, 3, 4]. These remove as much hard coded styling from the header bar widget as possible, and specify the style in the theme instead. For most applications that are using header bars, there is nothing that you need to do to compensate for these changes. However, if you are using the header-bar style from Adwaita and not the header bar widget, the chances are that you will have to remove any styling that you have set yourself. You can see the required adustments on this [5] Nautilus bug. tl;dr version - if you are using the header-bar css style, please check your app with gtk+ and gnome-themes-standard master. Allan [1] https://git.gnome.org/browse/gtk+/commit/?id=889e63faedccf8b3ec0e48861be65794aac60367 [2] https://git.gnome.org/browse/gtk+/commit/?id=798c2b60eca928615e199e3ee47ff9ec71ae6185 [3] https://git.gnome.org/browse/gnome-themes-standard/commit/?id=b95a8b874ac2d3c99e28843c1309e1ca51cc6e42 [4] https://git.gnome.org/browse/gnome-themes-standard/commit/?id=69180c801fd271aee767ec2d7a7b5ee46084d58d [5] https://bugzilla.gnome.org/show_bug.cgi?id=706479 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Release Notes Time
Hey everyone, 3.10 is shaping up really nicely, and it's time to start thinking about what we want to put in the release notes. Please, please spend a bit of time to make a note of anything you have done this cycle: https://wiki.gnome.org/ThreePointNine/ReleaseNotes The earlier you can provide this information, the better job we can do of communicating all your fantastic work. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
Super Bisquit wrote: > Since when did you become a "Dr" without having an actual doctorate- > honorary ones don't mean shit? Derogatory personal comments have no place on this list. Please refrain from making posts like this again. Our moderators have been notified about this, and will act if you send mails like this again. Let's keep it civil; we're all on the same side here. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]
Shaun McCance wrote: >> There's possibly a discussion to have about whether GNOME should use >> proprietary services for outreach, but GitHub isn't really anything >> new here. In my opinion, if you feel strongly about the use of >> proprietary services for outreach, perhaps GNOME isn't the greatest >> fit for you. > > What a terrible thing to say. If you disagree with some decisions, then > you don't belong here? There's no room for diversity of opinion in our > community? That doesn't sound like the GNOME I joined ten years ago. I wouldn't take one comment on a mailing list as being representative of GNOME in general. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A first look at 3.10 blockers
I've had a quick look, and these are some of the bugs I'd like to have on the blocker list: 691316 photos - no minimum size set 700726 music - only checks for new music at start 696166 control-center - have lock screen curtain background configurable 691187 control-center - Battery life estimation over optimistic 686616 shell - Don't show resident notifications on the lock screen 703999 user-docs - drop the intro animation 705921 gtk+ - HeaderBars without a titlebar need to have rounded corners I'd also add the 3.10 whiteboard bugs for initial-setup: https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=allwordssubstr;query_format=advanced;status_whiteboard=3.10;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=gnome-initial-setup And Weather has a bunch of bugs which prevent it from being announced as a fully-fledged GNOME App: https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=allwordssubstr;query_format=advanced;status_whiteboard=3.10;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=gnome-weather Allan On Tue, Aug 13, 2013 at 3:49 PM, Matthias Clasen wrote: > Here is a first pass over bugs that are currently marked with a target > of '3.10'. The bulk of it is related to Wayland (simply because that > is where I'm focusing most, currently). If there are other bugs that > should be on this list, please let us know. > > > Matthias > > > Related to Wayland: > > > 705710 clutter evdev: fix X11 to evdev keycode translation > 695737 clutter-gtk Add wayland support > 705573 gnome-contro display: merge the wip/wayland-display branch > 705510 gnome-deskto Merge the wip/wayland-display branch > 705507 gnome-settin Merge the wip/wayland-display branch > 705497 gnome-shell make gnome-shell build two binaries > 705504 gnome-shell 3.10: make on-screen keyboard work under wayland > 672358 gtk+ Introduce a GdkClipboard abstraction to replace the > various GtkClipboard implementations > 698307 gtk+ There should be support for the Wayland input method protocol > 705670 mutter Add a DBus API for display configuration under X > > Related to geolocation: > > > 694985 gnome-contro Mould date-time settings into new designs > > Related to bluez5 transition: > -- > > 701078 NetworkManag Port NM to BlueZ 5 > > Related to system status rework: > - > > 705647 gnome-shell New System Status design lost the ability to suspend > 705733 gnome-shell Make new system status implementation respect the > always-show-universal-access-status setting > > Misc. other bugs: > > > 679438 glib Python 3 / Windows / cmake port > 696633 glib gdbus-codegen trips over unicode chars when using python 3.x > 686527 gnome-docume Pickup ownCloud accounts from GOA > 697127 gtk+ gedit context menu uses fixed-width font > 698833 gtk+ Regression in GtkGrid after baseline support > 701125 gtk+ port scrolling to GtkPixelCache > 701126 gtk+ port scrolling to GtkPixelCache > 702914 gtk+ Button, menu appearance not updated correctly > 703124 gtk+ Scrolling results in upper part of spreadsheet being obscured > 704134 gtk+ No way to disable cursor blinking > ___ > 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: Combined system status updates
Nirbheek Chauhan wrote: ... >>> I beg to differ there! On my laptop with its default setup, I would >>> see 13 items + 5 separators on the menu at all times (increasing to 14 >>> with updates). >> >> Can you explain how you came up with those numbers? Do you have >> multiple VPNs/Mobile Broadband connections? I'm not sure that 5 >> separators will even be possible... > > I miscounted the separators, sorry about that! 4 is the correct > number. My network bits look like this: > > * WiFi (displayed if device is capable) > * Mobile Broadband (USB 3G dongle, connected) > * VPN1 (Work VPN) > * Bluetooth (Switched on at boot) > > And I have a "Guest" user on my system for people who want to use my > machine, so that adds the "Switch user" and "Logout" options. That > makes it 13, by my count—unless I've misunderstood something about the > menu? This isn't the average case, but it's not an atypical case > either. In that case you should end up with 12 menu items and 4 separators. That's essentially the same as what you should have in your network menu right now (assuming you're within range of a decent number of wi-fi networks). > FWIW, I know it's a bad idea for non-designers to give design > suggestions, but it seems to me that splitting the network menu might > be a nice thing to do. You should really feel free to make suggestions; they're appreciated. Thanks for the feedback, Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Combined system status updates
Nirbheek Chauhan wrote: > On Tue, May 14, 2013 at 12:50 AM, Andreas Nilsson wrote: >> On 2013-05-13 16:02, Nirbheek Chauhan wrote: >>> These look rather nice. My only concern with these wireframes is that >>> they would make the menu far too long. Would this menu still fit on >>> 1366x768 or 1024x600 screens in landscape mode? >>> >> I too was a bit shocked to see the All Possible System Menu, but realized >> it's a very extreme case. It's actually impossible, since airplane mode cancels out some of the other items. Also, I don't think we're going to have the remote access and screen sharing integration in there in the first run, which will give us some space to assess before adding extra features. >> Usually a menu would be top ~10 items. If anyone is interested in this, check out the examples [1]. On a laptop with a single user account and VPN, I count eight menu items, for example. > I beg to differ there! On my laptop with its default setup, I would > see 13 items + 5 separators on the menu at all times (increasing to 14 > with updates). Can you explain how you came up with those numbers? Do you have multiple VPNs/Mobile Broadband connections? I'm not sure that 5 separators will even be possible... > Do we have a mechanism for "scrolling" (or its equivalent) when the > menu length exceeds the screen height? How would this interact with > scroll bars inside sub-menus? Is such a mechanism desirable? GTK+ menus can certainly scroll when they reach the limit of the available space. I'm not sure about St ones, but that should be possible. That said, scrolling a menu isn't a great thing and I'd like to think that we can avoid it. According to my rough calculations, a menu with 13 items in it (which would be pretty rare) would be about 550px tall. Allan [1] https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/combined-system-status-menu-v2-examples.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Combined system status updates
drago01 wrote: ... >> Me, Jon and Jakub have reviewed the combined system status designs in >> the attempt to address the feedback that we've got. A fresh round of >> wireframes are now on the wiki [1]. I think that they resolve the most >> serious issues that have been raised. > > I have just checked under my desk ... wired networks still exists ;) Heh. :) One case that was brought up during the discussions was knowing if your network cable has come loose or disconnected. An idea for this would be to simply show a notification. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Combined system status updates
Hi all, Me, Jon and Jakub have reviewed the combined system status designs in the attempt to address the feedback that we've got. A fresh round of wireframes are now on the wiki [1]. I think that they resolve the most serious issues that have been raised. Allan [1] https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus#Update_Proposal -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME throbber inconsistencies?
On Thu, May 2, 2013 at 4:44 AM, Cosimo Cecchi wrote: > On Wed, May 1, 2013 at 5:04 PM, Marco Scannadinari > 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
Re: GNOME throbber inconsistencies?
Marco Scannadinari 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?
Hey Marco, Marco Scannadinari 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: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Juanjo Marín wrote: ... > But also some problems has arisen in the effort of being compatible with > touch devices.For example, I think that the UI of new applications like > Documents are very touch friendly, but it's weird for keyboard + mouse users. > It is weird because the interaction is very different from other core > applications like Nautilus (Files). In Nautilus, double click opens a file, > but only one click opens it in Documents, and the way of selecting elements > and doing actions with selected elements is quite different. I think > Documents works great in touch screen devices and it is a little bit clumpsy > with mouse, and Nautilus works great in mouse and keyboard but not so good > for touchscreen devices. Right, so the selection design pattern is probably the most prominent place where touch compatibility has had an impact. It should be emphasised that it is somewhat unique in this regard. The selection pattern has been evolving a bit, and we have a round of design changes planned which we will hopefully happen this cycle. Me and Jakub literally have a list of things that can be done to the selection mode to make it better with a pointer. Once we're done I don't think it will be any worse than the selection mechanisms that we have in nautilus today. It should also be said that this pattern does have benefits when you are using a pointer. An obvious example of this is the difference between single/double click. Not only is double click not exactly ideal on a touchpad, but it is also used inconsistently and is non-discoverable (some places you need double click to open, others you need single.) In general, using single click consistently is a much better approach, especially when combined with discoverable mechanisms for selection. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Tomas Frydrych 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]
Alberto Ruiz 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: Feature proposal: combined system status menu
Matthias Clasen wrote: >> Rather, what I'd like to point out is that, in my opinion, this needs more >> thinking through before going straight to shipping. >> I mean, I trust the design team and I value your experience in the field, >> but this is another radical change, and it's quite different from our >> competitors. > > I don't think anybody will argue against doing careful design and > testing, but I don't think this particular argument holds much water. > Quite the contrary, this all-in-one status menu is quite similar to > what you find eg on the Android-based Galaxy Note. It also has similarities with ChromeOS and WebOS... Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Lennart Poettering 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
Sriram Ramkrishna 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
Hey Giovanni! Giovanni Campagna 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
Federico Mena Quintero 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 ar
Re: Feature proposal: combined system status menu
Jasper St. Pierre 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
Part two of my reply. :) Alberto Ruiz 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
Touchscreen Compatibility [was: Feature proposal: combined system status menu]
Hi Alberto, Alberto Ruiz 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
Feature proposal: combined system status menu
Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Allan [1] https://live.gnome.org/ThreePointNine/Features/SystemStatusMenu [2] https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/#Update_Proposal -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [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 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
Re: What can you tell new about Content Selection?
Hey Dylan! Dylan McCall 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
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: Bijiben
Hi Pierre-Yves, Pierre-Yves Luyten wrote: > On Tue, 12 Mar 2013 17:31:21 +0100, Andre Klapper > 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
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: 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: Possible to fix glaring Gjs API issues before GNOME 4?
Javier Jardón wrote: > On 28 February 2013 08:26, Dan Winship 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
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: steam games
Sriram Ramkrishna 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
Re: steam games
Sriram Ramkrishna 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: Fallback mode is going away - what now ?
Florian Müllner 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: Fallback mode is going away - what now ?
Matthias Clasen 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: GNOME Games split
Allan Day wrote: > Thomas H.P. Andersen 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: GNOME Games split
Thomas H.P. Andersen 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: 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 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
Robert Ancell 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: Re,keyboard bugs (Re: Touch & Mobile)
> anish patil writes: >> To expedite caribou bux fixing and future development work, as Daiki >> Ueno already written eekboard which has more i18n features. I would >> like to see Daiki Ueno as new Caribou maintainer :) Thanks for bringing this up Anish. We really need someone to take over as Caribou maintainer, and to help get the on screen keyboard moving again. If anyone is interested in helping out in this area, please get in touch. 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 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: taking features away (compact view removed from Nautilus)
Adam Dingle 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: Introducing Calendar
Erick - this is fantastic. I see that you've been in touch with Jon and Jimmac about the design; feel free to keep d-d-l updated on your progress. Jason Simanek wrote: ... >> Now, the call for help is for someone on the Design Team to step >> forwward to take care of the design parts of the development since I >> must confess I'm pretty bad at that, and I have some concerns with the >> mockups posted on the wiki. > > I've been looking for a way to contribute to Gnome. I am a graphic > designer (mostly a web designer these days). What is needed right now? > Better mockups than those on the linked page? > > Let me know if I can be of assistance. It would be awesome to have you on board, Jason, and we could do with some more detailed mockups for Calendar. We have assets and examples in Github that you can work from [1]. Let me know how you get on. :) Allan [1] https://github.com/gnome-design-team/gnome-mockups/ -- 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: live image
Hey Ray, Ray Strode 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: 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 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: 3.6 Feature: IBus/XKB integration
Frederic Peters 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: 3.6 Feature: Lock Screen
On Wed, May 9, 2012 at 4:21 PM, Frederic Peters wrote: >> On Fri, May 4, 2012 at 4:54 PM, Andre Klapper 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: Feature Proposal: finding and rediscovering shared links
Seif Lotfy wrote: > On Wed, May 9, 2012 at 11:25 AM, Allan Day wrote: >> >> Seif Lotfy 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? ... > I would like to have the feature there in any way standalone or integrated. > Hylke thought it would make sense to have it as a standalone application, so > he approached the designs as a standalone. I am ok with both. > > Can you elaborate why a standalone application might not be a good idea? > (not that you claimed it, but I am just assuming here). What is required to > consider is whether to have this integrated or stand-alone? There might be > good reasons for both. A standalone application is totally fine, in my opinion. I don't think a shared links application belongs in the core though (in which case you don't need to propose it). > I currently don't see this feature integrated into contacts or chat > honestly. If it is to be integrated in an application then it should be Web. > My reasoning behind this is that one uses "Web" to browse websites. And the > queue feature is already planned and approved by the design team. So having > something to populate the queue makes more sense since it is a central place > to look for links. Instead of going to contacts or to chat to look for > links. As I've already said, I think this could make sense in contacts (as part of a 'related stuff' feature) or in chat (perhaps as a conversation filter). Remember - people look for things in the last place they saw 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: Feature Proposal: finding and rediscovering shared links
Seif Lotfy 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: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 5:24 PM, Evandro Giovanini wrote: > On Mon, May 7, 2012 at 12:51 PM, Xan Lopez wrote: >> On Mon, May 7, 2012 at 8:15 AM, Andrew Cowie >> 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: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 12:41 PM, Matteo Settenvini 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 7:15 AM, Andrew Cowie 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: Design in the open
On Fri, May 4, 2012 at 12:19 AM, Federico Mena Quintero 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: About "fast dial" contacts in Overview mode
Hey Petris, 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 Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti wrote: > 2012/4/25 Allan Day : ... > 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: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 10:23 AM, Jeremy Bicha 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: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera 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
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: 3.6 Feature: IBus/XKB integration
On Wed, Apr 25, 2012 at 2:42 PM, Federico Mena Quintero 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
Re: Design in the open
On Wed, Apr 25, 2012 at 10:21 PM, Allan Day 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: Design in the open
On Wed, Apr 25, 2012 at 6:45 PM, Karen Sandler 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 9:55 AM, John Stowers 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: 3.6 Feature: IBus/XKB integration
On Wed, Apr 25, 2012 at 2:43 PM, Sergey Udaltsov 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
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/ ___ desktop-dev
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 6:59 PM, Shaun McCance 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 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
Re: Feature Proposal: finding and rediscovering shared links
On Thu, Apr 19, 2012 at 3:40 PM, Seif Lotfy 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
Seif Lotfy 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: A weather app for GNOME
Hi Giovanni, On Sun, Mar 25, 2012 at 4:00 PM, Giovanni Campagna 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: 3.4 Release Notes time - Help needed!
On Tue, Mar 6, 2012 at 12:10 PM, Andre Klapper 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: Empty Power panel in System Settings
On Mon, Sep 12, 2011 at 3:21 AM, Jeremy Bicha 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: GNOME 3.1.90 beta released!
Hey Denis! On Thu, Sep 1, 2011 at 1:18 PM, Denis Washington 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: Where is the data?
More selective answers... :) On Sat, Aug 20, 2011 at 2:18 PM, Giovanni Campagna 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: Where is the data?
Nguyen Thai Ngoc Duy wrote: > On Sat, Aug 20, 2011 at 6:04 PM, Allan Day 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?
Hey Giovanni, I'm being selective in my responses here... Giovanni Campagna wrote: > I'm sorry I couldn't read through the whole GNOME Survey v4 thread, but > it was just too long. What I read though is that data was collected and > extists. > Now I'd like to simply ask: where is it? > Where we developers can find real cold numbers backing out the designs > we're asked to implement? I wrote that we already have lots of data on peoples' experiences with GNOME 3. Is that what you mean? There's a brief summary of that in the final paragraph of my previous email to the list [1]. 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. > 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. > 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. > I know that what I write, following the guidelines and the mockups, is > right. But people providing feedback don't always agree with that, and > if myself cannot understand the reason, how can I explain to them? ... The basic features of the shell design are explained on the wiki [2]. It's helpful to have a more thorough explanation for more controversial design decisions though, such as the ones that Owen [3] and me [4] provided for window buttons. Just ask if you want more information on a particular issue. > I understand that some features in 3.0 were like "design experiments", > because we have the whole 3.* cycle to improve. But if the results of > those experiments (that is, people's feedback) is not analyzed > thoroughly, how can we be sure that the design is right? Feedback does get read and gets weighed up against the other evidence that is available. I think it would be great if we had a more visible process there, however. 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... Also, we have been tracking the more minor niggles that people have reported [6]. > Or on the other > hand, how can I see that the feedback is listened to, if decisions are > never reverted? The shell design has never been set in concrete. Many things were changed during the design and development process and I'm sure there will be more changes in the future. I think it's too early to expect significant changes to the 3.0 design though. Allan [1] http://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00123.html [2] https://live.gnome.org/GnomeShell/Design/ [3] http://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00192.html [4] http://afaikblog.wordpress.com/2011/03/01/where-did-the-buttons-go/ [5] http://mdzlog.alcor.net/2010/12/10/ubuntu-brainstorm-top-10-for-december-2010/ [6] https://live.gnome.org/ThreePointOne/Features/FixAnnoyingThings -- 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 wrote: > On Fri, Aug 19, 2011 at 1:14 PM, Allan Day wrote: >> Felipe Contreras wrote: >>> On Fri, Aug 19, 2011 at 1:20 AM, Zeeshan Ali (Khattak) >>> wrote: >>>> On Fri, Aug 19, 2011 at 12:45 AM, Felipe Contreras >>>> 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: GNOME user survey 2011 (v4)
Felipe Contreras wrote: > On Fri, Aug 19, 2011 at 1:20 AM, Zeeshan Ali (Khattak) > wrote: >> On Fri, Aug 19, 2011 at 12:45 AM, Felipe Contreras >> 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: Testing out jhbuild
Owen Taylor 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 > jhbuild run > > 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: 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: On the Interaction with the design team
Frederic Crozat wrote: > On Mon, Jun 6, 2011 at 2:42 PM, Allan Day 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
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
Hi Joanie, Joanmarie Diggs wrote: > Hey all. > > I was planning on staying out of this one, conflict-avoidant creature > that I tend to be. But I'm with Dave: > > > To sum it all up, I > > believe the current dynamic of the design team is doing damage to GNOME > > as a community. > > I would love to find ways for the design team and the accessibility team > to work better together. Surely we must have some common ground, and > there has to be some happy medium between ATs that are visually pleasing > and look like they belong within GNOME 3 and yet still address the needs > of users with disabilities. The designers bring the former to the table, > I think our team brings the latter. I don't think any of our design crew would disagree with that. > But past interactions have (in my > personal experience) been negative. Can you elaborate? > Part of me believes that I should just suck it up and get thicker skin. > But most of me concludes that contributing to GNOME is something I > (supposedly) do "for fun." So seeing some way to improve this situation > would be a great step forward I think. > > FWIW. > --joanie 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
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). 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. :) > I feel that the current operation of the > design team is hurting our relationship with Canonical, who also have > designers who have, I believe, failed to influence design discussions in > the same measure as the "core" members of the design team like Lapo, > Allan, Jon. The only Canonical designer that I have ever known to try and get involved in GNOME design was Calum Pringle. I spent a good deal of time bringing him up to speed, as did Jimmac, but he disappeared off the scene pretty quickly. My impression was that he was pulled away to work on Unity. > I think the lack of documentation of the core design team > makes it harder for new designers to get involved. To sum it all up, I > believe the current dynamic of the design team is doing damage to GNOME > as a community. > > And since I care about GNOME as a project and as a community, I was > hoping to help change things to address that. Again, I think this is more perception than reality (which is still a problem). There is already a pretty decent amount of documentation, though some kind of archived records of progress and decisions would certainly help. The challenges that GNOME design faces are the same as any other part of GNOME. Writing documentation and communicating your activities is always difficult when you're busy and focused on other things. This isn't to say that we don't need to do better, of course. > > do you want to manage expectations? is this some community management > > direction? > > Is this an effort to say that it's unimportant? For me, since this is a > community issue, and I would like to see us manage it, that makes it > "some community management thing", yes. > > > because I honestly don't understand what's the point of all this. > > > > if we did a pass of sed and changed gnome-design team to gnome-utils > > maintainers, would you expect the gnome-utils maintainers to use > > a mailing list and document every decisions made in the project and > > involve everyone (and yes: it's a serious question)? > > First: http://mail.gnome.org/mailman/listinfo/gnome-utils-list - so, in > short, if there's anything controversial in gnome-dictionary, I know > where to get you. > > Second: http://live.gnome.org/GnomeUtils - so I know who the right > person to talk to is/who makes final decisions. > > Third: http://git.gnome.org/browse/gnome-utils/log/ - documents every > decision that was made (in principle). > > So, in short, I would like the design team to act like the gnome-utils team. GNOME design has all the equivalent facilities [1, 2, 3] excluding the mailing list. Again, I agree (and have never disagreed) that we need to do better. The only question has been around the appropriateness of a mailing list. Allan [1] https://live.gnome.org/GnomeOS/Design/Whiteboards [2] https://live.gnome.org/Design/ [3] http://gitorious.org/gnome-design [4] http://git.gnome.org/browse/gnome-shell-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: 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
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
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: GNOME Feature Proposal: Backup
Dave Neary wrote: > 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? * 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: GNOME Feature Proposal: Backup
Michael Terry wrote: > It seems discussion died down around this, which means the status quo > of "just" a GNOME external app will prevail. > > But I'm going to go ahead and take some steps to increase potential > cooperation between Deja Dup and GNOME, for those that are interested: > > 1) I'll try to stay more on top of the jhbuild moduleset. It got > bit-rotten as Colin pointed out, but now it's up to date. > > 2) I'll move my mailing list to GNOME. That seems rather painless and > seems to make it easier for GNOME people. It's super low traffic, so > doesn't really matter. But I encourage people to make it high > traffic. > > 3) I'll experiment with moving my trunk to GNOME git. This will let > GNOME people more easily dip their toes in the Deja Dup waters. > > Ideally this will be as low-cost an experiment for me as possible, so > I'm curious about other people having done similar conversions. I'll > keep a bzr mirror in LP for existing developers. But could I move > back to bzr and not lose anything? i.e. would a round-trip > (bzr->git->bzr) imply some metadata loss? > > And also, does being in git imply that the translation team would > automatically consider the module? These changes seem like good ones. > But moving bugs out of LP is a step too far for me. As would be > carving up pieces of Deja Dup into other modules (like > gnome-control-center). So I'll just keep chugging along as a separate > app for now. But hopefully these changes will let the GNOME community > become more involved if ya'll desire. As I've said previously, it would be great to have an integrated GNOME backup feature, and it would be cool to work together on this. The two issues you mention above seem to be blocking us though. Regarding bug tracking: I was waiting to hear some arguments about how Deja Dup could continue to use LP bug tracking and be a core GNOME module... if you do think that is possible, do make the case! Likewise, let's be clear about what's in the way of keeping Deja Dup as a single module: would whitelisting gcc panels solve that issue? 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
Dave Neary wrote: > In general I'm interested in how dogmatic the "use GNOME infrastructure" > requirement is, in the case of each team what the reasons & motivations > are, and how we can integrate personal preferences of module maintainers > & translators for things like bug trackers & translation infrastructure > (in the same way that git2svn allowed developers to commit to git for > GNOME modules, even before GNOME had migrated). I agree that we shouldn't be dogmatic about this. That said, I do think that it is important for a core module to use GNOME Bugzilla. These components are supposed to be developed and presented as integrated parts of the system. That makes using a common issue tracking system important. Speaking personally, I can't imagine being able to effectively work on Deja Dup/Backup if it doesn't use GNOME Bugzilla. It would be good to have a debate about this if anyone disagrees though. It's important to be pragmatic where desirable functionality is concerned. 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 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
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 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
