I really liked these designs, and have a consitent look and feel with the rest of the shell. Having a notification system right in the lock screen is a useful feature.
However, my concern regarding this is ergonomical. Currently, i just press any random key, and type in my password to unlock my system (which locks every so often). Now, ill be expected to not only arrive at lock screen on any action, but use a mouse, drag it, and then move back to the keyboard for the password. This will require using mouse and shifting back to keyboard. IMO, this is slightly inconvenient. And a solution for this IMO could be binding arrow keys, super key, and such keys which when pressed from the keyboard, perform the sliding of the lock screen away function (in addition to the mouse action, which does this). On Thu, Apr 26, 2012 at 4:08 AM, <[email protected]>wrote: > Send desktop-devel-list mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of desktop-devel-list digest..." > > > Today's Topics: > > 1. Re: Design in the open (Allan Day) > 2. Re: Module Proposal: Zeitgeist (Philip Withnall) > 3. Re: Design in the open (Allan Day) > 4. Re: Design in the open (Felipe Erias Morandeira) > 5. Re: Module Proposal: Zeitgeist (Shaun McCance) > 6. Feature Unproposal: Dynamic Help Menus (Shaun McCance) > 7. 3.6 Feature: Lock Screen (Marina Zhurakhinskaya) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Apr 2012 17:21:37 -0400 > From: Allan Day <[email protected]> > To: [email protected] > Cc: desktop-devel-list <[email protected]> > Subject: Re: Design in the open > Message-ID: > <cac_wn4vtvaedcdos95abf5s+j7hbdwmv5ix18sdq818wrmb...@mail.gmail.com > > > Content-Type: text/plain; charset=windows-1252 > > On Wed, Apr 25, 2012 at 6:45 PM, Karen Sandler <[email protected]> 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 > > > ------------------------------ > > Message: 2 > Date: Wed, 25 Apr 2012 22:21:47 +0100 > From: Philip Withnall <[email protected]> > To: [email protected] > Subject: Re: Module Proposal: Zeitgeist > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > On Wed, 2012-04-25 at 22:36 +0200, Frederic Peters wrote: > > Seif Lotfy wrote: > > > > > So I would still like to have my question answered. How is the policy > > > on using Zeitgeist for non-feature and non-UX related optimization and > > > maintenance distribution? > > > > Do note this was not discussed by the release team, we'll have a > > meeting soon and we can add that to the agenda if you want an official > > answer, but in my opinion there is no problem if a maintainer wants to > > use zeitgeist because it helps in whatever s/he is coding. > > As an example, Seif has asked me to clarify that libfolks is happy to > have Zeitgeist as a hard dependency if other core modules also have > Zeitgeist as a hard dependency. > > In the meantime, we plan to have Zeitgeist as a soft dependency (just > like most of our other dependencies) since it isn't used for too much in > folks at the moment, and it's another thing which people would otherwise > be forced to build before they could build folks for themselves. > > See https://bugzilla.gnome.org/show_bug.cgi?id=672709 for details on > Zeitgeist + folks. > > Philip > > > Fred > > _______________________________________________ > > desktop-devel-list mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 230 bytes > Desc: This is a digitally signed message part > URL: < > http://mail.gnome.org/archives/desktop-devel-list/attachments/20120425/0a842a97/attachment.bin > > > > ------------------------------ > > Message: 3 > Date: Wed, 25 Apr 2012 22:36:23 +0100 > From: Allan Day <[email protected]> > To: desktop-devel-list <[email protected]> > Subject: Re: Design in the open > Message-ID: > <cac_wn4t8h3jawrhdz+3xuf0lkvufm1i+vyhktzmc+n9v5tq...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Apr 25, 2012 at 10:21 PM, Allan Day <[email protected]> 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 > > > ------------------------------ > > Message: 4 > Date: Thu, 26 Apr 2012 00:12:48 +0200 > From: Felipe Erias Morandeira <[email protected]> > To: [email protected] > Subject: Re: Design in the open > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 25/04/12 15:27, Allan Day wrote: > > * 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) > > > Caused by this, the design process in GNOME might be often shallow, > based on static mockups, sparsely documented, and lacking enough > justification and evaluation *before* the proposed changes get > committed to code. > > Mistakes in design happen. This is just a natural part of the work and > not bad in itself ("fail early and fail often"). However, in GNOME > some of those problems in the original designs might take a long time > to be detected, acknowledged and fixed. By the time an alternative > proposal can be implemented, it has to go against the existing > (published) behaviour and deal with a code base that was written to > enable the old solution ("scar tissue", as Cooper calls it). > > GNOME has very ambitious goals: to create an environment that works on > tablets and desktops, along with ~20 core applications. This is not an > easy task at all, and we only have a very small group of professional > designers to work on it. > > There might be a mismatch between our current resources and goals. > Maybe we need to scale either, or both, so that GNOME designers can > focus much more in solving each problem better. > > > Felipe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iEYEARECAAYFAk+YdtAACgkQ3e5RNKzod9ft3ACfVAUusg0BFBRolyncoagrtXji > wmMAn2eoPb1tT9JmS2/3XYTSy3qBz3YX > =T4NI > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 5 > Date: Wed, 25 Apr 2012 18:18:40 -0400 > From: Shaun McCance <[email protected]> > To: [email protected] > Subject: Re: Module Proposal: Zeitgeist > Message-ID: <1335392320.2136.885.camel@recto> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2012-04-25 at 22:36 +0200, Frederic Peters wrote: > > Seif Lotfy wrote: > > > > > So I would still like to have my question answered. How is the policy > > > on using Zeitgeist for non-feature and non-UX related optimization and > > > maintenance distribution? > > > > Do note this was not discussed by the release team, we'll have a > > meeting soon and we can add that to the agenda if you want an official > > answer, but in my opinion there is no problem if a maintainer wants to > > use zeitgeist because it helps in whatever s/he is coding. > > As a data point, I have a branch in Yelp where I'm using Zeitgeist. > I want to use it to reorder search results based on frequency. of > access. At the moment, the branch is reporting to Zeitgeist, and > it's adding links to "often viewed with" pages alongside the more > about and see also links. (That bit is sort of an experiment. Time > will tell how useful it is.) > > It's not entirely clear to me what the process would be for me to > propose merging this to master, especially given that there's an > existing module proposal for Zeitgeist. Though I wasn't going to > worry about that anyway until I had the search result reordering > working. (I'd rather discuss code than ideas.) > > I also have a long-term, "wishful thinking" goal of being able to > collect usage data for Yelp. I still have to figure out how I can > do this without violating privacy, but Zeitgeist already collects > exactly the information I would want reported. > > -- > Shaun > > > > > > > ------------------------------ > > Message: 6 > Date: Wed, 25 Apr 2012 18:24:45 -0400 > From: Shaun McCance <[email protected]> > To: desktop-devel-list <[email protected]> > Subject: Feature Unproposal: Dynamic Help Menus > Message-ID: <1335392685.2136.889.camel@recto> > Content-Type: text/plain; charset="UTF-8" > > I notice the feature page for dynamic help menus in 3.4 has been > migrated to the 3.6 features: > > https://live.gnome.org/ThreePointFive/Features/HelpMenus > > I'm officially unproposing this for 3.6. It would take a lot of > time to redo my implementation for changes in our platform and > in our application designs, and I'm just not going to have very > much time to devote to GNOME development this cycle. > > -- > Shaun > > > > > ------------------------------ > > Message: 7 > Date: Wed, 25 Apr 2012 18:38:09 -0400 (EDT) > From: Marina Zhurakhinskaya <[email protected]> > To: desktop-devel-list <[email protected]> > Subject: 3.6 Feature: Lock Screen > Message-ID: > < > 7aa93ee0-35e0-48d1-93b5-653f678ae...@zmail12.collab.prod.int.phx2.redhat.com > > > > Content-Type: text/plain; charset=utf-8 > > Hi! > > I'd like to propose a new lock screen as a 3.6 feature. The new lock > screen will > > - be styled to have a uniform look and feel as the rest of GNOME Shell > - be visually consistent with the look of the authentication components on > the login screen > - have a limited number of status icons displayed > - show an indication that there are notifications or show the > notifications themselves depending on the user?s preferences > - allow user authentication with a password, pin, fingerprint, or smartcard > > The designs for the lock screen are available here: > https://live.gnome.org/GnomeOS/Design/Whiteboards/ScreenLock > > A notification settings panel will need to be added to System Settings to > allow the user to specify if either an indication that there are > notification or the notifications themselves should be displayed in the > lock screen mode. The design for the panel is available here: > https://live.gnome.org/Design/SystemSettings/Notifications > > Technically, the code for fading out the screen and displaying the lock > screen when the user becomes active again will be added to GNOME Shell, and > the gnome-screensaver will no longer be used. The lock screen will be > displayed within the same user session to enable the display of > notifications. The lock screen will communicate with GDM via DBus to get > authentication results. > > The look of the login screen will be changed too to have both look the > same. The login screen is already implemented as part of the GNOME Shell > code, and the common components will be shared, where possible. > > The feature page is here: > https://live.gnome.org/ThreePointFive/Features/ScreenLock > > Giovanni Campagna, who will be working on this as his GSoC project, and I > will be the main developers. Ray Strode will be helping us along by lending > his GDM expertise. > > Thanks, > Marina > > > ------------------------------ > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > End of desktop-devel-list Digest, Vol 96, Issue 51 > ************************************************** > -- Bhaavan Merchant
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
