Re: Design in the open
On Fri, May 4, 2012 at 12:19 AM, Federico Mena Quintero feder...@gnome.org wrote: ... As a way to solve these issues, I'd like to follow up on an idea which I sketched during last year's Desktop Summit - namely, about constructing a pattern language for Gnome's design based on the good things that what we have and what other systems have done well. ... Better documentation would definitely help people to get involved and understand what's happening. I was working on a new version of the HIG [1] for a while (that is structured around design patterns) and Jimmac has even written a new site for it, but we just haven't had the time to finish it. Allan [1] https://live.gnome.org/Design/HIG -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Sat, May 5, 2012 at 4:09 AM, Federico Mena Quintero feder...@gnome.orgwrote: On Fri, 2012-05-04 at 00:03 -0500, Diego Escalante Urrelo wrote: A common language of patterns is an awesome idea. I'd encourage Federico to expand on the subject. Calum, Allan, and generally the people around the London UX Hackfest have already done a ton of work in this area: https://live.gnome.org/UsabilityProject/HIG3 The work done for Nokia N9 could be another good source of inspiration too, both in content and presentation: http://harmattan-dev.nokia.com/docs/ux/ There is a set of prototypal patterns there. I've just added my two favorite references for designing pattern languages: http://zeta.math.utsa.edu/~yxk833/StructurePattern.html - by Nikos Salingaros. He explains how a hierarchy or graph of patterns works, how to validate pattern languages, and how to ensure that patterns have the right connections among them. Consider it as how to write a good pattern language. http://www.dreamsongs.com/Files/FinePointsOfPatternWriting.pdf - by Richard Gabriel. It's a presentation on the quality of writing in pattern descriptions, and about the story-like qualities that a pattern language should have. Consider it as how to make a pattern language pleasant to read. I think we can just start with the work on the HIG3 page and start polishing it based on those guidelines. I also want to bring in patterns from other UX-centered pattern languages that could be useful to Gnome. Also, Emily said: Another idea would be to begin giving users a simple way to provide feedback on what they prefer in design. This could be done via a GNOME Design Blog or similar, where posts focus on upcoming features along with examples to be voted on – do users prefer buttons/menus/etc that look like X, Y, or Z? Should we remove minimize/maximize/close buttons? Do users want a journal? How important is privacy to you? Etc. Require users to register, and when they do so ask if they'd like [snip] This would be a very good way to start hunting for good things in Gnome that can be turned into patterns: this is exactly what Tom Erickson describes in his paper, about what was done in the town of Manteo to figure out the sacred places that should be preserved. We had good success with an informal poll like the one for Gnome Deployments, and the replies weren't hard to analyze... maybe another informal poll, What do you like about gnome2 / gnome3?, with answers of limited length and a no bitching and moaning, please guideline... :) Federico ___ 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: Design in the open
As someone who is just starting to become involved in design development after many years of using open source free software, I find these discussions fascinating on multiple levels. For whatever reason I have always found communities in free/open source software to be rather intimidating, which is probably why its taken me so long to become involved. I suspect this is true for many people, and I fully support anything and everything that makes it easier for people to become involved and thereby feel connected to the project. The article was definitely interesting and as I think about it more and more, I can certainly see how developing a 'planning language' would be helpful to GNOME. With that in mind, I suspect a first step would be to start a wiki page of GNOME Design Terms, with a list of terms and their (community-defined) definitions in relation to GNOME Design. Examples can be added as development proceeds, until we end up with a wiki page explaining our 'planning language' which we can point new people to when they are becoming involved. Such a page/language would certainly streamline and simplify the design process, and allow new (potential) contributors to write proposals and suggestions in a way that makes it easier for everyone to understand and critique them. Another idea would be to begin giving users a simple way to provide feedback on what they prefer in design. This could be done via a GNOME Design Blog or similar, where posts focus on upcoming features along with examples to be voted on – do users prefer buttons/menus/etc that look like X, Y, or Z? Should we remove minimize/maximize/close buttons? Do users want a journal? How important is privacy to you? Etc. Require users to register, and when they do so ask if they'd like to sign up for a (weekly? monthly?) news letter regarding the ongoing development of GNOME and related technologies/applications, as well as new polls, blog posts, etc. Essentially, create a new level of GNOME membership, below the Foundation level, with a much lower bar for inclusion – require only a name and a (verified) email address – and allow almost anyone to participate in the ongoing discussions and development of GNOME. Emily On Fri, May 4, 2012 at 1:03 AM, Diego Escalante Urrelo die...@gnome.orgwrote: On Thu, May 3, 2012 at 5:19 PM, Federico Mena Quintero feder...@gnome.org wrote: As a way to solve these issues, I'd like to follow up on an idea which I sketched during last year's Desktop Summit - namely, about constructing a pattern language for Gnome's design based on the good things that what we have and what other systems have done well. This. +1. From my experience on film stuff, having a way to refer to those things that look good or bad is essential to have collaboration between different specialists. Framing shots would be impossible if there wasn't an abstract way of describing them (flat/deep, warm/cold, lenses, etc). Sound designers/editors, photography directors, even actors, need to be aware of this language for efficient communication during production. I have been thinking lately that film making has many similarities with Free Software development. Being both abstract things with an audiovisual result that involves many different specialists. A common language of patterns is an awesome idea. I'd encourage Federico to expand on the subject. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Whatever you can do, or dream you can, begin it. Boldness has genius, power and magic in it. - Goethe Be who you are and say what you feel because those who mind don't matter and those who matter don't mind. - Dr.Seuss Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Il giorno 30/apr/2012 17:36, Bastien Nocera had...@hadess.net ha scritto: * will be developed inside totem source tree (replacing?) Yes. I think both the feature page and the mail to this list made it pretty clear, even if glibly. To be honest not so clear, at least to me. And to be honest it's your duty, as the one proposing the new feature, to provide all relevant info. It was just an example of incomplete explanations, from both designer and/or developers. I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Not wishing to diminish the role of the release-team, but if you expect being able to block Totem/Videos from 3.6 when both the developers and the designers agree it's the way forward, I think you're very mistaken. Sorry, bad phrase from me. It was: the GNOME community should agree on proposed feature and r-t will have to check if new code will be ready or not before .0 release. However, sorry if I'm going to be rude, maybe you are the one that mistook the proposal phase. Reading your words it seems you was just informing us about your future plan about Totem: no objections, no questions, no further explanations, no discussions. As Shaun pointed out in him reply, you can do whatever you want with your code, but in order to be part of GNOME you need community consesus on proposed feature and techinical agreement on code maturity. Do we all want Videos in GNOME? I think yes, it's a nice UI. Do we all want to remove the standard multimedia player (video files, audio files, DVD, CD...) from desktop? I'm not so sure I can agree we have to do here and now. ___ 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, 2012-05-04 at 00:03 -0500, Diego Escalante Urrelo wrote: A common language of patterns is an awesome idea. I'd encourage Federico to expand on the subject. Calum, Allan, and generally the people around the London UX Hackfest have already done a ton of work in this area: https://live.gnome.org/UsabilityProject/HIG3 There is a set of prototypal patterns there. I've just added my two favorite references for designing pattern languages: http://zeta.math.utsa.edu/~yxk833/StructurePattern.html - by Nikos Salingaros. He explains how a hierarchy or graph of patterns works, how to validate pattern languages, and how to ensure that patterns have the right connections among them. Consider it as how to write a good pattern language. http://www.dreamsongs.com/Files/FinePointsOfPatternWriting.pdf - by Richard Gabriel. It's a presentation on the quality of writing in pattern descriptions, and about the story-like qualities that a pattern language should have. Consider it as how to make a pattern language pleasant to read. I think we can just start with the work on the HIG3 page and start polishing it based on those guidelines. I also want to bring in patterns from other UX-centered pattern languages that could be useful to Gnome. Also, Emily said: Another idea would be to begin giving users a simple way to provide feedback on what they prefer in design. This could be done via a GNOME Design Blog or similar, where posts focus on upcoming features along with examples to be voted on – do users prefer buttons/menus/etc that look like X, Y, or Z? Should we remove minimize/maximize/close buttons? Do users want a journal? How important is privacy to you? Etc. Require users to register, and when they do so ask if they'd like [snip] This would be a very good way to start hunting for good things in Gnome that can be turned into patterns: this is exactly what Tom Erickson describes in his paper, about what was done in the town of Manteo to figure out the sacred places that should be preserved. We had good success with an informal poll like the one for Gnome Deployments, and the replies weren't hard to analyze... maybe another informal poll, What do you like about gnome2 / gnome3?, with answers of limited length and a no bitching and moaning, please guideline... :) Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
I'm completely and utterly against this idea, you might push away the noise, but you are pushing away all new contributors as well... how are you supposed to become a design contributor if you're not a programmer and you cannot contribute designs because you cannot join the mailing list since you can't become a foundation member? Maybe we should think about moderating the design mailing list in a smarter way... or maybe we should have a more formal design proposal process (some sort of wiki section/template or something) and ask people to write down and discuss their crazy proposals there instead of the mailing list, I'm sure there are better ideas in this regard. Asking people to become contributors (and then foundation members) first so that they can contribute seems like a really bad idea to me. 2012/5/2 Sriram Ramkrishna s...@ramkrishna.me On Apr 25, 2012 8:43 AM, Allan Day allanp...@gmail.com wrote: On Wed, Apr 25, 2012 at 9:55 AM, John Stowers john.stowers.li...@gmail.com wrote: So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Many of your suggestions seem designed to address or avoid conflict, or to convey design team decisions in a better manner. This is not the source of my confusion nor my uncertainty in how to interact with the design team. In order to piece together the rationale or even the process for design team decisions I currently browse commit logs on the gnome-design github repo, and look at comments made when changing live.gnome.org pages. Some of you tweet stuff, others scatter it on google+. You suggest even using $some_new_webapp to better collaborate on designs. While I cannot see the discussion and the evolution of design team thought (even if I have the time to piece together all these sources of information) all I see is a decision by decree when a live.gnome.org page is created which describes the final design. My suggestion is thus the same as it was the last time this thread was raised - if the design team does not want to archive discussions on a mailing list, may they please allow IRC logging on the gnome-design channel. I'm not sure how useful logging the channel will be (lots of noise, etc), but I'd be happy to give it a go. The main thing is that we shouldn't stop there. IRC logs aren't going to fix the whole gamut of challenges that we face in relation to community design. You can even be proactive and send email updates to ddl or something. What about a mailing list of which only foundation members can subscribe to? I made this suggestion earlier. Sri 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? u 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz ___ 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, 2012-04-25 at 14:27 +0100, Allan Day wrote: 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 Fully agreed on all counts. 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. If you have an hour or two, I heartily recommend that you read this paper: http://www.visi.com/~snowfall/LinguaFranca_DIS2000.html It's by Thomas Erickson, Lingua Francas for Design: Sacred Places and Pattern Languages. The tl;dr version (even shorter than the abstract) is this: * He gives an example of how people managed to construct a common vocabulary of the things that work well in their town (even with people not being fully aware of them), and use that knowledge to know *what* to replace and what to leave as-is. Then, he exposes Pattern Languages in general, as a form of vocabulary to embody knowledge gained through experience. Then he explores a possible pattern language for (social) interaction design. In particular, in section 5.2.2 he summarizes a pattern language for a design consultancy - something from which I think we could borrow ideas. His point is that having a pattern language gives you a way to communicate between people of different backgrounds and interests: designers, developers, users. They can all take part in the design and construction of their (software) environment, all in their best capacity, and be assured that the result will be good, usable, and that it will be able to evolve well as needs change. As for how Gnome's pattern language would help with the issues you mentioned: * Lack of design resources. Learning any kind of design is a big effort. By starting with a common vocabulary, which embodies a lot of concrete experience from past designs, we can get people up to speed. A pattern language takes the mystery out of design and lets you talk in concrete terms. It *will* take time for a newcomer to learn all the intricacies of the design, but at least he has a guide and a method of reasoning about it. * Improving the quality of the design. A pattern language gives you a way to measure things, at least on a qualitative basis. For example, This proposal for workspace thumbnails does well on the EASE OF NAVIGATION and EXPLORABLE INTERFACE patterns, but it is lacking in the PRINCIPLE OF LEAST SURPRISE one because... * Getting the project behind a common vision. As Erickson mentions in his paper, a pattern language often has a definite set of values put in it. Gnome strives for certain values - software freedom, ease of use, functionality, accessibility. Our patterns can embody these values and let us evaluate things more clearly rather than only through abstract wishes. * Giving people a stake in the project. Patterns are defined recursively; a pattern language has rather a fractal structure with big patterns composed of smaller patterns. The EXPLORABLE INTERFACE could embody patterns like UNDO/REDO, INSTANT FEEDBACK, etc. In turn, those smaller patterns can be implemented in a number of ways, aided by even smaller patterns. If you set the big picture, people can implement the sub-parts to their liking, but always based on the desired patterns. This gives them a stake in the project - they can agree on *what* is needed to make a good design, even if they don't know exactly what the final parts will look like, and they can own the implementation of their own little parts. * Resolving disagreements. This is about ensuring that one design can be compared against another one and be evaluated with respect to desirable patterns. Or it can be about disassembling both competing designs into their smaller patterns, and seeing if a combination of them would be even better. * Letting people understand design activities. With a pattern language, new designs become easy to explain. We moved notifications to the corner because we want the PERIPHERAL AWARENESS pattern in concord with the FOCUSED WORK pattern. * Helping
Re: Design in the open
On Thu, May 3, 2012 at 5:19 PM, Federico Mena Quintero feder...@gnome.org wrote: As a way to solve these issues, I'd like to follow up on an idea which I sketched during last year's Desktop Summit - namely, about constructing a pattern language for Gnome's design based on the good things that what we have and what other systems have done well. This. +1. From my experience on film stuff, having a way to refer to those things that look good or bad is essential to have collaboration between different specialists. Framing shots would be impossible if there wasn't an abstract way of describing them (flat/deep, warm/cold, lenses, etc). Sound designers/editors, photography directors, even actors, need to be aware of this language for efficient communication during production. I have been thinking lately that film making has many similarities with Free Software development. Being both abstract things with an audiovisual result that involves many different specialists. A common language of patterns is an awesome idea. I'd encourage Federico to expand on the subject. ___ 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 Apr 25, 2012 8:43 AM, Allan Day allanp...@gmail.com wrote: On Wed, Apr 25, 2012 at 9:55 AM, John Stowers john.stowers.li...@gmail.com wrote: So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Many of your suggestions seem designed to address or avoid conflict, or to convey design team decisions in a better manner. This is not the source of my confusion nor my uncertainty in how to interact with the design team. In order to piece together the rationale or even the process for design team decisions I currently browse commit logs on the gnome-design github repo, and look at comments made when changing live.gnome.org pages. Some of you tweet stuff, others scatter it on google+. You suggest even using $some_new_webapp to better collaborate on designs. While I cannot see the discussion and the evolution of design team thought (even if I have the time to piece together all these sources of information) all I see is a decision by decree when a live.gnome.org page is created which describes the final design. My suggestion is thus the same as it was the last time this thread was raised - if the design team does not want to archive discussions on a mailing list, may they please allow IRC logging on the gnome-design channel. I'm not sure how useful logging the channel will be (lots of noise, etc), but I'd be happy to give it a go. The main thing is that we shouldn't stop there. IRC logs aren't going to fix the whole gamut of challenges that we face in relation to community design. You can even be proactive and send email updates to ddl or something. What about a mailing list of which only foundation members can subscribe to? I made this suggestion earlier. Sri 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? u 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
2012/4/27 Allan Day allanp...@gmail.com: On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: ... So, IMHO a design driven GNOME needs good desing documents. The design document is a written contract[4] between designers and other teams, more time you spend writing it, less time you'll spend explaing here on desktop devel list :) ... For me, design in the open is about developers and designers working together as partners, not hyper-specified design documents. Wait. I never said to keep apart designers and developers. As communty we have the great advantage and opportunity to work together. But while some developers and some designers could need or like to be closer in order to produce a better software or experience, I believe it's also fair to let other contributors and community members to be well informed about what's happening and why. That might not give observers as much to see, but it provides contributors with a real opportunity to shape our project. So, for example, as release team member, all I currently know about new Videos app proposal, based on availabe info on mailing list and wiki, is: * will resemble similar existing apps for tablets, but GNOME style * will use clutter APIs * will be developed inside totem source tree (replacing?) If I'm right there is no code yet available on git to check. I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Now, do I have to ping people involved or simply I've to trust them? Can we be helpful each other writing more informations (neither final in stone, nor iperdetailed, just more) somewhere? Or a different proposal path (the one suggested by Rodrigo, for instace) could be more effective? Cheers, Luca [1] https://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00135.html ___ 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 Mon, 2012-04-30 at 16:52 +0200, Luca Ferretti wrote: 2012/4/27 Allan Day allanp...@gmail.com: On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: ... So, IMHO a design driven GNOME needs good desing documents. The design document is a written contract[4] between designers and other teams, more time you spend writing it, less time you'll spend explaing here on desktop devel list :) ... For me, design in the open is about developers and designers working together as partners, not hyper-specified design documents. Wait. I never said to keep apart designers and developers. As communty we have the great advantage and opportunity to work together. But while some developers and some designers could need or like to be closer in order to produce a better software or experience, I believe it's also fair to let other contributors and community members to be well informed about what's happening and why. That might not give observers as much to see, but it provides contributors with a real opportunity to shape our project. So, for example, as release team member, all I currently know about new Videos app proposal, based on availabe info on mailing list and wiki, is: * will resemble similar existing apps for tablets, but GNOME style * will use clutter APIs Totem already uses Clutter. * will be developed inside totem source tree (replacing?) Yes. I think both the feature page and the mail to this list made it pretty clear, even if glibly. If I'm right there is no code yet available on git to check. All the code that's been written is available in master. The new optical media plugin for grilo is in grilo-plugins master, the merge into the video widget of the OSD is done is in totem master, etc. I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Not wishing to diminish the role of the release-team, but if you expect being able to block Totem/Videos from 3.6 when both the developers and the designers agree it's the way forward, I think you're very mistaken. And the reason why I did not answer your mail is because the questions were already answered in my original mail. Now, do I have to ping people involved or simply I've to trust them? Can we be helpful each other writing more informations (neither final in stone, nor iperdetailed, just more) somewhere? Or a different proposal path (the one suggested by Rodrigo, for instace) could be more effective? Cheers, Luca [1] https://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00135.html ___ 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: Design in the open
On Mon, 2012-04-30 at 16:36 +0100, Bastien Nocera wrote: On Mon, 2012-04-30 at 16:52 +0200, Luca Ferretti wrote: I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Not wishing to diminish the role of the release-team, but if you expect being able to block Totem/Videos from 3.6 when both the developers and the designers agree it's the way forward, I think you're very mistaken. I don't think it's a matter of blocking the will of the designers or developers. The release team should, of course, follow the consensus of the community. But we do need to be able to judge whether the implementation is up to standards for inclusion. It's not a matter of saying We won't include this feature. It's a matter of saying This feature is not ready yet. The problem with the feature proposal process is that we're approving wiki pages. But implementation matters. We have something like three months before we start hitting freezes. That's not a lot of time, and sometimes we just can't do everything we'd like. I'm not opposed to feature proposals, but I think they need to come with a detailed proposal for implementation, including all necessary new dependencies, and a deadline by which the release team can judge the implementation, not the design. -- Shaun ___ 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 Mon, 2012-04-30 at 12:05 -0400, Shaun McCance wrote: On Mon, 2012-04-30 at 16:36 +0100, Bastien Nocera wrote: On Mon, 2012-04-30 at 16:52 +0200, Luca Ferretti wrote: I don't want and I don't have time and resources to help you with design or code writing. But I'm involved in this change and I feel I need more info[1]. And developers will need r-t approval before proceding with this change. Not wishing to diminish the role of the release-team, but if you expect being able to block Totem/Videos from 3.6 when both the developers and the designers agree it's the way forward, I think you're very mistaken. I don't think it's a matter of blocking the will of the designers or developers. The release team should, of course, follow the consensus of the community. But we do need to be able to judge whether the implementation is up to standards for inclusion. It's not a matter of saying We won't include this feature. It's a matter of saying This feature is not ready yet. That's fair. Fedora already has a tick for that particular part of the process. It's the Contingency plan section: http://fedoraproject.org/wiki/Features/Policy/Proposals In Videos' case, if it looks like a finished version won't make it in time, we'll fork a 3.6 branch from 3.4, cherry-pick the most interesting and tested changes, and ship that as 3.6. The problem with the feature proposal process is that we're approving wiki pages. But implementation matters. We have something like three months before we start hitting freezes. That's not a lot of time, and sometimes we just can't do everything we'd like. I'm not opposed to feature proposals, but I think they need to come with a detailed proposal for implementation, including all necessary new dependencies, and a deadline by which the release team can judge the implementation, not the design. If we wanted to be able to judge the implementations when the feature proposals are made, then we'd need to push them all back 6 months. I'm not sure how we get to a discussion about the feature process in a thread called design in the open though... Cheers ___ 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, 2012-04-27 at 11:23 +0100, Allan Day wrote: On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: ... So, IMHO a design driven GNOME needs good desing documents. The design document is a written contract[4] between designers and other teams, more time you spend writing it, less time you'll spend explaing here on desktop devel list :) ... For me, design in the open is about developers and designers working together as partners, not hyper-specified design documents. That might not give observers as much to see, but it provides contributors with a real opportunity to shape our project. That's not something I would want to take away. GNOME design is often misunderstood as creating specifications that are handed down on tablets of stone. That's not the way it works - each design is typically the outcome of a process of iteration, and we keep on iterating right through the development process. then, why not do the proposals for new designs here in d-d-l? That way you might get initial feedback before starting on the design, and people that feel ignored get info on what's going on. Then, you can just keep working as you do right now, but an initial proposal on this list, as we do for features, might be a good idea to get everyone interested involved ___ 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 Sat, Apr 28, 2012 at 2:02 PM, Rodrigo Moya rodr...@gnome-db.org wrote: then, why not do the proposals for new designs here in d-d-l? That way you might get initial feedback before starting on the design, and people that feel ignored get info on what's going on. Then, you can just keep working as you do right now, but an initial proposal on this list, as we do for features, might be a good idea to get everyone interested involved My fear here is that there would be a high signal to noise ratio. If you saw how much traffic we had in gnome-shell on the 3.0 designs, it was quite painful. That's why I had proposed that we have a list where only gnome-foundation members could post. While anybody can see the designs itself. We finally got DDL down to a relatively high signal to noise ratio. Of course some of that is because a large number of developers no longer subscribe to DDL. In any case, I don't know if designers will get the feedback they are looking for. BTW I hope we look at how we do mail next! sri ___ 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: Design in the open
On Thu, Apr 26, 2012 at 5:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: ... So, IMHO a design driven GNOME needs good desing documents. The design document is a written contract[4] between designers and other teams, more time you spend writing it, less time you'll spend explaing here on desktop devel list :) ... For me, design in the open is about developers and designers working together as partners, not hyper-specified design documents. That might not give observers as much to see, but it provides contributors with a real opportunity to shape our project. That's not something I would want to take away. GNOME design is often misunderstood as creating specifications that are handed down on tablets of stone. That's not the way it works - each design is typically the outcome of a process of iteration, and we keep on iterating right through the development process. PS * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? hmm disagreement between ... ? designers and maintainers? designers and contributors? designers and i18n/doc/a11y team? designers and users? designers and release team itself? Whoever and whoever. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Hi Allan On Wed, 2012-04-25 at 14:27 +0100, Allan Day wrote: 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. yes, very constructive, so thanks a lot for stepping in and getting the discussion to a constructive way! 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!) I think a lot of people complain about not having an archive of what has been discussed in design land, so even though I know you are all busy, maybe it would be great to use the usability list to notify of ongoing work. Just a mail linking to the design wiki pages when something new is added/updated would be a great step. And I think it would make all the people that complain about this have a central point of information. just something that came to mind after seeing your very constructive mail, so just ignore it if it doesn't make sense :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
2012/4/25 Allan Day allanp...@gmail.com: But there are challenges and things we can do better. Among those obstacles, I see: snip * 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 From my point of view the main issue (at least perceived as issue) in current design-develop workflow is explanation. While our design/ux team is able to produce great ideas, frequently the only visible product of design work is a wiki page with poor info. Or, at least, poor compared with documents and info provided by others. You can compare, for instance, our document about proposed changes for unlock screen [1] or initial setup [2] with a similar document from Canonical about changes for multiple monitor stuff[3]. In [1] and [2] I can see only hints about how features could work. In [3] you have a fully detailed explanation of each phase or action or reaction of the system. Of course you'll have to spend more time writing and reading it, but people will be able to understand without guessing. This should be helpful to maintainers (I know what I've to do, no need to ping designers), casual contributors (this piece is not yet implemented, maybe I can work on it), other teams (I've to document this feature, and I know how it will work). And design team too, people will be able to give a quicker, more precise, and better feedback. So basically: why do I've to agree with your design and apply those changes? or say this new stuff is better? The proposed unlock screen is gorgeous, but... wait, _guessing_ from mockups is seems I've to use mouse and drag the little triangle before I can type my password... slow... boring... current unlock dialog is better, faster, stronger, harder... design team sucks, they want to break _my own_ workflow with no actual reason or gain. There are too many images and too few words in [1]. I've to scroll to the end of the page before I can read lock is removed by [...] Esc key on keyboard (BTW I usually type Ctrl to wake up monitor before starting to type my passoword, it's closer than Esc). You are still trying to change my workflow, but at least it seems I will not need to use both mouse and keyboard. 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 :) [1] https://live.gnome.org/GnomeOS/Design/Whiteboards/ScreenLock [2] https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup [3] https://docs.google.com/document/d/1aHvJ-iIw-59bXTYBmIhQqEx0za2h9jpFE_RhZ2VOvJc/edit [4] https://blog.slickedit.com/2007/05/how-to-write-an-effective-design-document/ 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? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Hi all, Sorry in advance for the long e-mail and any eventual harsher remark :) For some time now it seems that the way to create, lets say a new core GNOME application has been to get someone from the design team to publish rude mockups for a couple of screens in that App and then passing it on for developers to implement it. I think this is fundamentally wrong. Not because most developers would create better designs but because the entire process gets fragmented. Ideally, every developer and designer should have an intuitive and creative sense of design and usability, have a strong understanding of the technology and its future capabilities and be able to grasp the bigger picture. And looking at the bigger picture, quite a few things are flagrant: - First of, to create beautifully designed and intuitive user interfaces there needs to be great technology. When the iPhone was first introduced in early 2007, everyone felt a punch in their stomach with how great the user interfaces and experiences were. And even on the desktop, OSX featured applications with user interfaces that were easy to use, full of carefully crafted widgets, user interactions that responded with subtle animations and a general feel that huge amounts of dedication went into creating those. In 2007 GNOME hadn't anything compared to that, and it still doesn't. Were the iPhone to be introduced today, applications with GTK3 interfaces would look almost as antiquated as they looked back then. - In 2007 it should have become clear that in the future, a significant part of computing would become mobile, with touch input. It's now mid 2012. GNOME is galaxies away from providing a touch experience even worth advertising. As an example, the people at Palm weren't very successful from a commercial perspective, but to their credit, I think they created something really interesting and more refined than Android, all of this faster than the average time it takes to get a patch through. And the first time someone used this new era of smartphones, either from Apple or the Android vendors, it should have been obvious that all mobile devices, or actually all devices, would eventually feature really high density screens. Yet there's still nothing close to full resolution independence in GNOME as a whole. - For a couple of years netbooks sold like free beer. Everyone on this camp got excited at all those vendors that shipped some sort of Linux (to lower their costs) but eventually, it wasn't even good enough to compete against the familiarity of Windows XP and most of us didn't realize how crappy of a form factor the netbook actually was. So again, GNOME stalled on delivering innovation to the desktop or a new and creative approach to touch. - I think there are many ways to tackle the same problem, but great design is Universal. When one sees great design, the immediate reaction is of WOW. When the Shell was first publicly introduced, a face of near terror was prevalent in the eyes of most. The Shell appeared as a design decision set in concrete, yet with a guarantee that it would eventually get better. At the time, most felt GNOME needed a new face, but there wasn't any logic rationale as to why the chosen design was the Shell, but not Awn, or Docky, or Unity. Well, actually there was, and it's the same rationale that inhibits GNOME from integrating some beautiful Apps such as Lingo, Postler or Dexter, Apps that I didn't even know existed but are really beautiful and slick. And the rationale seems to be to not even consider stuff that doesn't originate from a core set of people working for a core set of companies. Well, It seems likely that no one from those projects ever proposed them for inclusion in GNOME, but would they sincerely even stand a chance due to the simple fact that someone from the design team submitted a mockup for a similar application? The lack of internal competition is astonishing. - Finally, great applications. With maybe a few rare exceptions, for every GNOME application, there is a Windows counterpart that is as good or better, and an OS X counterpart that is way, way better. From an user experience point of view (I'm not talking feature-wise), comparing Totem to QuickTime, AbiWord to Pages or any photo App for GNOME to iPhoto might even sound embarrassing. So it would be crucial that people spent effort in creating the best application in the World, but of course, the core technology to make this happen needs to be present and even small details need to be thought through, such as the default font in GNOME3, which I swear the quality should not even be regarded as a matter of taste but rather as a matter of eyesight health :) So I find it really an issue that designers and developers aren't working as one. The new mockups look like an attempt to make applications look better, but not great. Yet better isn't remotely enough. For those who haven't yet got a chance, I urge you to try the iPhoto App for the iPad. Every
Re: Design in the open
On Thu, Apr 26, 2012 at 12:16 PM, Luca Ferretti lferr...@gnome.org wrote: 2012/4/25 Allan Day allanp...@gmail.com: From my point of view the main issue (at least perceived as issue) in current design-develop workflow is explanation. While our design/ux team is able to produce great ideas, frequently the only visible product of design work is a wiki page with poor info. Or, at least, poor compared with documents and info provided by others. You can compare, for instance, our document about proposed changes for unlock screen [1] or initial setup [2] with a similar document from Canonical about changes for multiple monitor stuff[3]. But in reality there is no such workflow where the design team delivers a 'visible product' that is than taken by developers as-is and converted into code. Design is a process that involves frequent communication between the people who are doing the design and the people who are writing the code. The wiki pages you cite are merely notes that help you remember the most important points from those discussions. At least that is how all my interactions with the designers have gone. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/12 18:16, Luca Ferretti wrote: While our design/ux team is able to produce great ideas, frequently the only visible product of design work is a wiki page with poor info. Or, at least, poor compared with documents and info provided by others. You can compare, for instance, our document about proposed changes for unlock screen [1] or initial setup [2] with a similar document from Canonical about changes for multiple monitor stuff[3]. IMHO, that's mainly because Canonical, like e.g. Mozilla, have more design resources focused on a smaller set of problems. This allows them to spend time documenting in more detail, conducting user testing of design proposals before they are published, researching in detail how their solutions are actually being used, etc. Felipe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+Z2DAACgkQ3e5RNKzod9eWPQCgwi7aiIJjWdkhn35v7+tXanjY VxMAoLvlUJfYfjd35xnEKG8wSLYFUFwi =LK34 -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
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. You can even be proactive and send email updates to ddl or something. 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? John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Allan: I think it is pretty clear that the GNOME UX team is pretty amazing. As you say, though, I think we recognize that we need to improve in areas like engagement. With GUADEC around the corner, I think now is an important time to make progress on getting better engagement between the developer and usability communities within GNOME. Can we plan activities at GUADEC that could help? Aside from a BOF, I wonder if it might make sense to do some of the same sorts of activities that were done at the UX Hackfest in London. I think it would be interesting to do some usability testing while there, if it were possible to make that happen. Perhaps the next UX Hackfest could happen to coincide with GUADEC. Are plans being discussed on the usability mailing list? Are there any particular design-focused talks being planned? At the Desktop Summit in Berlin, it seemed a lot of talks were about basic design principles. Do you think we will be seeing that again, but perhaps more focused on GNOME 3? Brian On 04/25/12 08:27 AM, Allan Day wrote: 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
Re: Design in the open
On Wed, Apr 25, 2012 at 9:55 AM, John Stowers john.stowers.li...@gmail.com wrote: So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Many of your suggestions seem designed to address or avoid conflict, or to convey design team decisions in a better manner. This is not the source of my confusion nor my uncertainty in how to interact with the design team. In order to piece together the rationale or even the process for design team decisions I currently browse commit logs on the gnome-design github repo, and look at comments made when changing live.gnome.org pages. Some of you tweet stuff, others scatter it on google+. You suggest even using $some_new_webapp to better collaborate on designs. While I cannot see the discussion and the evolution of design team thought (even if I have the time to piece together all these sources of information) all I see is a decision by decree when a live.gnome.org page is created which describes the final design. My suggestion is thus the same as it was the last time this thread was raised - if the design team does not want to archive discussions on a mailing list, may they please allow IRC logging on the gnome-design channel. I'm not sure how useful logging the channel will be (lots of noise, etc), but I'd be happy to give it a go. The main thing is that we shouldn't stop there. IRC logs aren't going to fix the whole gamut of challenges that we face in relation to community design. You can even be proactive and send email updates to ddl or something. I've lapsed in my design update blog posts, but I've got a new one in the works. You think emails would be better than blogging? Of course if the canonical way to interact with the design is to show up on IRC at a specific hour then, IMO, you will lose contributors. I can hack any time of night when I have the motivation and the free time. But if I want to understand why the design team did something I have to... trust them? Trust them, or ask them, or a combination of the two. (Trust comes best once you gain experience of working with people, of course.) Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Wed, 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 is important to recognise that improving the state of design in GNOME isnt 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... * 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. * 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 dont 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. * 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. karen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
I am happy Allan drafted the problem thoroughly and and also provided initial steps that could solve it. Well done. On Wed, Apr 25, 2012 at 7:45 PM, Karen Sandler ka...@gnome.org wrote: On Wed, April 25, 2012 9:27 am, Allan Day wrote: Echoing what Brian said, I like these suggestions for improvement! Are there any that we can turn into concrete initiatives that we can organize soon and perhaps fundraise for? Or build some initiatives for GUADEC? I include a few more detailed questions below along these lines. It 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... I think Karen raises a good point here. I think there should be 2 kind of proposals. - A feature proposal: Where a feature is discussed and the technologies needed for it are decided, if the design team thinks the feature is not good then an detailed explanation would help. Also if the feature is a not accepted then there is no need to discuss the technology. - A technical proposal: Where libraries or services that could optimize performance/maintenance or prove to be beneficial in the future for existing modules can be suggested to be used. Technical proposals should not include any features, else it is a feature proposal. * 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. * 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 I would like to propose that we contact the people at KDE, since they already formed a community task force that manages and handles day to day disputes and work on improving communication in the community in a professional manner. AFAIK (I might be mistaken) they were given some negotiation seminar during DS 2011. * 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. * 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. karen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Thanks Allan for taking the time to detail the problem as much as possible. It is nice to have this discussion going in a peaceful manner. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Wed, Apr 25, 2012 at 6:45 PM, Karen Sandler ka...@gnome.org wrote: On Wed, April 25, 2012 9:27 am, Allan Day wrote: Echoing what Brian said, I like these suggestions for improvement! Are there any that we can turn into concrete initiatives that we can organize soon and perhaps fundraise for? Or build some initiatives for GUADEC? I include a few more detailed questions below along these lines. It'd be great to have a BoF on design at GUADEC. I'm not sure what availability would be like for doing a UX hackfest there, but we could certainly look into that. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process I think there's some confusion here - you're not talking about purely technical proposals here too, are you? I assume this is more focused on anything that interfaces with any elements of design... Feature proposals aren't supposed to be purely technical, if my understanding is correct - they should always have user-facing value (whether we should have separate technical feature proposals is a separate issue in my opinion). As such they are a natural channel through which the community can participate in design activities. * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? I think we should definitely explore this more, it goes hand in hand with the other suggestions below - helping to stop bad behavior, soothing ruffled feathers and communicating better. Absolutely - it would be great if someone wanted to do some work there. * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. thanks, Allan! I'm glad we're having these discussions and hope that we can find ways for the Foundation to help too. Me too. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Wed, Apr 25, 2012 at 10:21 PM, Allan Day allanp...@gmail.com wrote: ... * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. Missing footnotes: [1] https://live.gnome.org/GnomeOS/Testable [2] https://mail.gnome.org/archives/desktop-devel-list/2012-March/msg00094.html - I realise now that the timing of these live images won't actually help with testing UX changes (since we'll already be in UI freeze when they're ready) - that's maybe something to look at if and when we have the necessary tools ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
-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- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
