Send desktop-devel-list mailing list submissions to
desktop-devel-list gnome org
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
desktop-devel-list-request gnome org
You can reach the person managing the list at
desktop-devel-list-owner gnome org
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 <allanpday gmail com>
To: karen gnome org
Cc: desktop-devel-list <desktop-devel-list gnome org>
Subject: Re: Design in the open
Message-ID:
<CAC_wn4vTVAedcdoS95Abf5S+J7hbdwMv5ix18sdQ818wRmB9kw mail gmail com>
Content-Type: text/plain; charset=windows-1252
On Wed, Apr 25, 2012 at 6:45 PM, Karen Sandler <karen gnome org> wrote:
> On Wed, April 25, 2012 9:27 am, Allan Day wrote:
>
> Echoing what Brian said, I like these suggestions for improvement! Are
> there any that we can turn into concrete initiatives that we can organize
> soon and perhaps fundraise for? Or build some initiatives for GUADEC? I
> include a few more detailed questions below along these lines.
It'd be great to have a BoF on design at GUADEC. I'm not sure what
availability would be like for doing a UX hackfest there, but we could
certainly look into that.
>> It is important to recognise that improving the state of design in
>> GNOME isn?t just the responsibility of designers. There are things
>> that all of us can do to help - from the release team and maintainers,
>> to individual developers and community advocates. Here are some of my
>> ideas for things that all of us can do to make design work more
>> effectively and harmoniously as a part of GNOME:
>>
>> * a more rigorous (and better documented) feature proposal process
>
> I think there's some confusion here - you're not talking about purely
> technical proposals here too, are you? I assume this is more focused on
> anything that interfaces with any elements of design...
Feature proposals aren't supposed to be purely technical, if my
understanding is correct - they should always have user-facing value
(whether we should have separate technical feature proposals is a
separate issue in my opinion). As such they are a natural channel
through which the community can participate in design activities.
>> * new tools for displaying and discussing designs, such as something
>> like Dribble or Design Hub
>> * a process for resolving design disagreements - perhaps maintainers
>> or the release team could mediate if a dispute seems intractable?
>
> I think we should definitely explore this more, it goes hand in hand with
> the other suggestions below - helping to stop bad behavior, soothing
> ruffled feathers and communicating better.
Absolutely - it would be great if someone wanted to do some work there.
>> * better communications about where GNOME is going and what the
>> project is trying to achieve
>> * some kind of active community management role to help soothe ruffled
>> feathers
>> * advertised designer playgrounds and discussion areas (for people
>> wanting to stretch their design wings)
>> * tackle bad behaviour across the project in a more proactive manner
>> (will ensure that disagreements don?t get out of hand)
>> * micro release-cycles in which new features are advertised, completed
>> and tested
>> * better testing facilities so people can test and give feedback on UX
>> changes before release time
>
> What would this entail? This sounds like it could be incredibly helpful if
> we could find the resources for it.
There are already initiatives that are pursing this, I'm happy to say
- both in the form of a new testing framework [1] and a role for
testing within the release process [2].
>> * keep a running list of design tasks that are appropriate for newcomers
>> * work to prevent design disputes - ensure early informal contact
>> between designers and developers at the beginning of feature
>> initiatives
>>
>> So there are lots of ways that we can do design better as a community,
>> and contributors on this list can all play a part in helping to make
>> us to be even more successful in this regard. It will take actions as
>> well as words to move forward, of course - if you want to help, or
>> have your own ideas, just get in touch.
>
> thanks, Allan! I'm glad we're having these discussions and hope that we
> can find ways for the Foundation to help too.
>
Me too. :)
Allan
------------------------------
Message: 2
Date: Wed, 25 Apr 2012 22:21:47 +0100
From: Philip Withnall <philip tecnocode co uk>
To: desktop-devel-list gnome org
Subject: Re: Module Proposal: Zeitgeist
Message-ID: <4f986aed e249b40a 0415 6cd6 mx google com>
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
> desktop-devel-list gnome org
> 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 <allanpday gmail com>
To: desktop-devel-list <desktop-devel-list gnome org>
Subject: Re: Design in the open
Message-ID:
<CAC_wn4t8h3JaWRHdz+3xUf0LkvufM1i+vYHkTzmc+n9V5TQbEQ mail gmail com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Apr 25, 2012 at 10:21 PM, Allan Day <allanpday gmail com> wrote:
...
>>> * better testing facilities so people can test and give feedback on UX
>>> changes before release time
>>
>> What would this entail? This sounds like it could be incredibly helpful if
>> we could find the resources for it.
>
> There are already initiatives that are pursing this, I'm happy to say
> - both in the form of a new testing framework [1] and a role for
> testing within the release process [2].
Missing footnotes:
[1] https://live.gnome.org/GnomeOS/Testable
[2] https://mail.gnome.org/archives/desktop-devel-list/2012-March/msg00094.html
- I realise now that the timing of these live images won't actually
help with testing UX changes (since we'll already be in UI freeze when
they're ready) - that's maybe something to look at if and when we have
the necessary tools
------------------------------
Message: 4
Date: Thu, 26 Apr 2012 00:12:48 +0200
From: Felipe Erias Morandeira <femorandeira igalia com>
To: desktop-devel-list gnome org
Subject: Re: Design in the open
Message-ID: <4F9876E0 5000700 igalia com>
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 <shaunm gnome org>
To: desktop-devel-list gnome org
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 <shaunm gnome org>
To: desktop-devel-list <desktop-devel-list gnome org>
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 <marinaz redhat com>
To: desktop-devel-list <desktop-devel-list gnome org>
Subject: 3.6 Feature: Lock Screen
Message-ID:
<7aa93ee0-35e0-48d1-93b5-653f678ae510 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
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
End of desktop-devel-list Digest, Vol 96, Issue 51
**************************************************