Re: [Sugar-devel] Sugar UI Dictator
On Wed, Nov 24, 2010 at 10:43 AM, C. Scott Ananian csc...@laptop.org wrote: I'm suggesting that you work on reducing the time commitment, rather than dilute the responsibility. (Christoph's suggestion seems a useful step in that direction.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Wed, Nov 24, 2010 at 1:37 AM, Michael Stone mich...@laptop.org wrote: A committee-of-three with people like Gary, Martin, and Walter on it [...] [Another orthogonal issue:] I like and respect Gary, Martin, and Walter, and I think I'd have no trouble convincing them of any UI change I'd wish to make. AFAICT that's part of the *problem*, not the solution. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
[more thoughts, again apologies for not making these shorter] Failing a good candidate, I think do no harm should be the motto -- concentrate on the (many!) design-related tasks which *don't* involve making design decisions. Briefly: organizing/maintaining the specs, collecting/collating issues that need design review or redesign, and facilitating outside review for these. (For example, if a design class at a university were to make Sugar their term project, what documents would you give them, what opinions would you want them to hear, what tasks would you want them to consider? In what form would you want their report? Which outside voices would you want to guide them/review their results? There's a lot of facilitation work to be done there, meetings to organize, documents to write, patches to summarize, etc.) I think a self-appointed Design Dictator Committee composed entirely of developers, some who may well have written portions of the patches under review, can easily do more harm than good. I'd rather see an all-developer Designer Enablement Committee whose job was to maintain design docs, collect issues for review, and generally make it possible to have a productive one-hour once-a-month design review meeting with the best *designers* we could get to do it. (Or once-a-release-cycle, as Christoph would have it.) If the problem is that the good designers don't have enough time, I don't think the solution is to use whoever we can find who has the time. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Wed, 24 Nov 2010 at 10:43:24 -0500, C. Scott wrote: On Wed, Nov 24, 2010 at 1:37 AM, Michael Stone mich...@laptop.org wrote: That reduces time commitment without diluting buck-stopping responsibility. A committee-of-three with people like Gary, Martin, and Walter on it will have adequate buck-stopping capacity, no? I think that it is possible that a committee of three will actually get less accomplished (and less coherently) than one person-who-really-doesn't-have-time. You're right that it's a risk... but isn't it a lesser risk than the risk of failing to find an appropriate rock star? (...unless you've got someone in mind who I've overlooked?) I'm suggesting that you work on reducing the time commitment And I have been, by doing what I can to prune the responsibilities of the job and by making sure to leave the committee members free to decide their own ways and means. (That is, if they decide that the right way to do the job is to try a merge window for HIG changes, to delegate to lieutenants, or to _, then they Decide to do it and we'll find out whether or not it works.) rather than dilute the responsibility. Relative to the current situation, my proposal greatly concentrates the responsibility *and* lays the groundwork for a proper dispute-resolution mechanism. I like and respect Gary, Martin, and Walter, and I think I'd have no trouble convincing them of any UI change I'd wish to make. I know a simple way to test. :) More seriously though, it seems that several of your concerns revolve around ways in which the system I'm proposing might fail to make good decisions due to inefficiency, overload, suasion, or other environmental factors. Would it help if we built some kind of big red button into the process like the ones famously installed by Toyota to permit their workers to halt the assembly line when they find defects? Failing a good candidate, I think do no harm should be the motto -- concentrate on the (many!) design-related tasks which *don't* involve making design decisions. Unfortunately, failing to make the decisions that need to be made *is* doing harm. That's why Bernie asked for a dictator. I think a self-appointed Design Dictator Committee Not self-appointed -- appointed by the Oversight Board. (You and I are just discussing candidates who we like, trying to convince ourselves that success is possible.) composed entirely of developers Gary and Walter are not primarily developers. Nor are Eben and Christian, who I would expect to provide regular expert testimony. some who may well have written portions of the patches under review, can easily do more harm than good. See above about the big red button idea. Would it help here? I'd rather see an all-developer Designer Enablement Committee whose job was to maintain design docs, collect issues for review, and generally make it possible to have a productive one-hour once-a-month design review meeting with the best *designers* we could get to do it. (Or once-a-release-cycle, as Christoph would have it.) The two ideas aren't necessarily mutually exclusive. Do you know people who want to do the job? If the problem is that the good designers don't have enough time, I don't think the solution is to use whoever we can find who has the time. Agreed -- but Gary, Martin, and Walter aren't whoever and they're aren't being suggested because they're rolling in free time -- they haven't got it either. What they do have (I think!) is the *collective* design skills, the good-will, and *enough* free time to get the community unstuck and to do more good than harm in the process. Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
I've said all I need to say, time to hear from other people. We'll know we've been successful when the new updated version of the Sugar HIG comes out. Until then, I guess just keep on pounding that big red button at 6 month intervals. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
Scott, Thanks for your thoughts! 3) I see a little bit of buck-passing going on, as a third-party observer. It seems like the real reason for a 3-person committee is that no one wants to actually step up and take on the responsibility of UX lead. Here's the chain of reasoning that leads me to the 3-person committee design: 0. We want help getting UX decisions made and reviving the HIG. We think that the benevolent dictator model might work well. However, we're having trouble finding the right person to be dictator. 1. To be a good UX dictator, you need competence, time, and trust. 2. None of the people who have adequate competence and trust to be dictator (i.e., Eben) have the time to do the job. 3. However, we have a small number of people (Gary, Martin, Walter, Eben, and Christian) all of whom have a few quanta of time, are well-regarded, are able to work together, and have relevant skills and aptitudes. 4. Since none of the available people can do the whole job alone, we have to find some way to divide the job up among them. 5. A three-person group seems like the smallest, most lightweight, most agile arrangement of people that could work. Thus, what you call buck-passing, I call recognition of the human and political realities of the moment. Unfortunately, lack of clearly defined responsibility is the crux of the problem you're trying to solve, so I'm not certain that splitting the horcrux is part of the solution. As above, committee-of-three just seems (to me, anyway) like the most likely-to-succeed way to implement the clearly defined authority part. (Again, I'd vote for single dictator too if I could think of someone appropriate to elect.) Maybe it would be help to identify a single dictator and lieutenants Lieutenants are a good idea regardless. (rather than the committee-of-3) with hat-passing as necessary -- so, for example, we can have 4 (!) design leads, but each one is ultimate dictator for one week a month. Do remember that continuity of design is also a goal. :) That reduces time commitment without diluting buck-stopping responsibility. A committee-of-three with people like Gary, Martin, and Walter on it will have adequate buck-stopping capacity, no? Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
Random thoughts, not terribly connected: 1) agree with developers != designers. It's like developers != release managers. We developers can often play at being a designer (or a release manager), but we've got bad tendencies that sneak in, just because we know too much or know what's hard or just start thinking about how to code something instead of how to *use* something. It's fine to use developers as short-term stand-ins for an empty slot, but we should keep in mind the dangers and compromises involved. 2) That's not to say that a lot of the basic HIG work can't be done by a developer -- or a teacher, or *anyone*, really. There's a lot of don't want to touch that paralysis that we should try to get over. Step 1 of a HIG update could be to import the HIG into a more appropriate non-wiki tool, or to radically restructure how it is kept on the wiki to make it more of a living document, and/or to figure out how versioning should work. Step 2 is probably to go through and red-line the existing document to describe how (and why) the existing implementation doesn't currently match the design -- with maybe a rough idea of whether its the design or the implementation that's at fault. Both of these things don't actually need a designer, they really need *time*. A large design team composed mostly of folks without design training can still be of great ongoing assistance with these paperwork tasks. Progress can/should be made independent of finding the one perfect dictator. 3) I see a little bit of buck-passing going on, as a third-party observer. It seems like the real reason for a 3-person committee is that no one wants to actually step up and take on the responsibility of UX lead. Unfortunately, lack of clearly defined responsibility is the crux of the problem you're trying to solve, so I'm not certain that splitting the horcrux is part of the solution. Maybe it would be help to identify a single dictator and lieutenants (rather than the committee-of-3) with hat-passing as necessary -- so, for example, we can have 4 (!) design leads, but each one is ultimate dictator for one week a month. That reduces time commitment without diluting buck-stopping responsibility. 4) Agreed with the general sentiment that the best shouldn't obstruct the good. Even with the concerns I stated above about designers!=developers, having someone step up and actually start cleaning up the UX docs (and/or organizing the UX patch queue) is probably the most important thing. Dictatorship may (or may not) naturally evolve from this; if Walter and/or OLPC are going to find the perfect UX Design Dictator candidate in 2 months (say) then consider what you can do in the meantime to pave the way for the Messiah's arrival. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
(apologies for not having the time to make these messages shorter) Another way of thinking of this problem might be as civics-style separation of powers. Given that the problem is (simplified) UX design compromised by developers (wrong target users, implementing the easiest thing, whatever) -- how are we to guard against this? Any solution will necessarily slow development. That needs to be acknowledged as a cost. One solution might be to have a monthly UX oversight board meeting. For proper separation of powers, no member of the board may have a patch up for review by the board (or they must recuse themselves). Board candidates should also be chosen based on their resumes, not just because we think they could be convinced to serve. I suggest that it would be easier to fill the board if you keep the workload as light as possible. Therefore you could have a (large?) design team group whose job was *not* to make design decisions, but rather to facilitate the work of the oversight board. The board's work would be easy if it had a nice agenda for their meeting (which they didn't have to prepare themselves!) listing each patch/bug up for review, summarizing discussion pro/con, with relevant screenshots/video. The board could meet at a scheduled time each month (on IRC, or Skype, or videoconference) and (if necessary) voices pro/con the various proposals could show up and argue their case. The design team facilitators could then summarize the meeting, prepare minutes, guide the development of revised patches as necessary, etc. Timing/frequency/size of the board could be varied as time goes on based on workload, etc. Regardless of the strawman proposal above, my main point here is to suggest thinking about the role of design as a deliberate frustration of developers -- in the same way that the legislature and courts are a deliberate frustration of the power of the executive. I think this mindset would lead to a very different idea of Design Dictator that the one proposed early in this thread -- whose function seemed to be to rubber-stamp/expedite patches, not preserve UX. --scott ps. ...and preserving UX seems orthogonal to the task of maintaining design documents, which is a separate job description at litl, at least. -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Mon, 2010-11-22 at 08:25 -0500, C. Scott Ananian wrote: Random thoughts, not terribly connected: 1) agree with developers != designers. It's like developers != release managers. We developers can often play at being a designer (or a release manager), but we've got bad tendencies that sneak in, just because we know too much or know what's hard or just start thinking about how to code something instead of how to *use* something. It's fine to use developers as short-term stand-ins for an empty slot, but we should keep in mind the dangers and compromises involved. 2) That's not to say that a lot of the basic HIG work can't be done by a developer -- or a teacher, or *anyone*, really. There's a lot of don't want to touch that paralysis that we should try to get over. Step 1 of a HIG update could be to import the HIG into a more appropriate non-wiki tool, or to radically restructure how it is kept on the wiki to make it more of a living document, and/or to figure out how versioning should work. Step 2 is probably to go through and red-line the existing document to describe how (and why) the existing implementation doesn't currently match the design -- with maybe a rough idea of whether its the design or the implementation that's at fault. Both of these things don't actually need a designer, they really need *time*. A large design team composed mostly of folks without design training can still be of great ongoing assistance with these paperwork tasks. Progress can/should be made independent of finding the one perfect dictator. 3) I see a little bit of buck-passing going on, as a third-party observer. It seems like the real reason for a 3-person committee is that no one wants to actually step up and take on the responsibility of UX lead. Unfortunately, lack of clearly defined responsibility is the crux of the problem you're trying to solve, so I'm not certain that splitting the horcrux is part of the solution. Maybe it would be help to identify a single dictator and lieutenants (rather than the committee-of-3) with hat-passing as necessary -- so, for example, we can have 4 (!) design leads, but each one is ultimate dictator for one week a month. That reduces time commitment without diluting buck-stopping responsibility. 4) Agreed with the general sentiment that the best shouldn't obstruct the good. Even with the concerns I stated above about designers!=developers, having someone step up and actually start cleaning up the UX docs (and/or organizing the UX patch queue) is probably the most important thing. Dictatorship may (or may not) naturally evolve from this; if Walter and/or OLPC are going to find the perfect UX Design Dictator candidate in 2 months (say) then consider what you can do in the meantime to pave the way for the Messiah's arrival. --scott I basically agree with everything you wrote. Sorry for posting just for stating this, but I couldn't think of anything else to add. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Sat, Nov 20, 2010 at 05:55:14PM -0500, Michael Stone wrote: On Sat, 20 Nov 2010 at 09:32:53 +, Martin Dengler wrote: On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. @Martin -- Choosing both seems like a bad idea to me because it: a) balloons the scope of the problem to be solved, b) shrinks the population of qualified participants, and c) seems likely to cause turf wars. Instead, I would prefer to stay focused on the need for UI-decision-making that Bernie identified in his initial email. I see your point. Can we get Bernie to confirm the distinction? Perhaps you or he could provide an example of a UI-related decision that is not HIG-related[1]? It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. Re-invented is a rather ambiguous term. If you mean defined the scope of, winnowed the membership of, empowered, and sought concrete commitments from... then perhaps we agree. If you mean something else, then perhaps you should be more explicit. Sorry for being (in retrospect) a bit flippant. I did not mean to be dismissive of the additional clarity (and empowerment and seeking-concrete-committments-ness) of your proposal. By re-invented I meant (keeping in mind I saw the committee as both UI maintainer and UI arbiter, as well as HIG maintainer) constructed a group with similar goals and responsibilities. I see now how your proposal does indeed narrow the scope, membership, and committments vis-a-vis the Design Team. Do you think there is space for two groups? Would an active Design Team vitiate the need for an organised group like the UI committee?[2] With that in mind, I think we should just have more people actively participate in the design team. [...] Michael, is there anything I've misunderstood/misremembered about your proposal? Would you want the Design Team to adopt your what does the committee do[1] responsibilities? I care about the substance, not the name: the UI committee that I'm describing has a fixed membership, offers a service-level agreement, and is answerable to the Oversight Board. In short, it is *designed* to meet Bernie's need for competent, respected, decisive, and dependable UI decision-making. Does the Design Team that you, Gary, and Bernie are thinking of share these properties? I think it does. Michael Martin Footnotes: [1] Am I oversimplifying to see a continuum of code --- UI --- HIG decision-making here, and your committee as designed to stay out of the code (UI maintainer) and HIG areas, and focus on the middle ground of UI? If so, I'm trying to get a better understanding of the boundary between not-UI and UI as you see it. [2] An academic point, I hear you saying, as we don't have one. Just trying to understand. pgpCOGgsPsxN2.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Sat, Nov 20, 2010 at 08:42:42AM -0500, Walter Bender wrote: But adding a bunch of developers to the design team will not help it accomplish its design goals. It might not. But it will a) help the lack of designers from impeding development progress; and b) help do no harm to the HIG / design goals already espoused (assuming the non-designer members keep an eye on their limitations). And we need to stay focused on Sugar's core design principles. Completely agree. One thing I do remember from your IRC discussion with Gary (I was on the edge of the conversation) is the need to bring the HIG up to date. While this may be considered tactical, I think it is strategic, in that sets the tone for all further actions. I couldn't agree more - which is why I'm scared to touch the HIG, since I know it's best left to designers with Sugar's core design principles squarely in the fore. -walter Martin pgpqfQqAB8bMg.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Sat, Nov 20, 2010 at 06:33:52PM -0500, Walter Bender wrote: On Sat, Nov 20, 2010 at 5:55 PM, Michael Stone mich...@laptop.org wrote: On Sat, 20 Nov 2010 at 08:42:42 -0500, Walter Bender wrote: But adding a bunch of developers to the design team will not help it accomplish its design goals. Two comments: 1. I don't see a bunch of developers; I see specific people (Gary, Martin, Eben, Christian, Bernie, ...) with specific talents, predispositions, and availabilities. Even on your short list, I see people who are not designers... there is a call to add more non-designers. I'm not sure if you thought I was calling for non-designers to join, but I don't see such a call. I just see a call for people that can contribute to the design team. I'd be hesitant to say the non-designers on that list can add nothing to a design discussion. I think in the absence of real designers, as long as we try not to overreach ourselves (perhaps you or just our good sense keeping us from this), there is something that can be accomplished... I don't want to divert non-designers into making design decisions I hope we don't have to get into an is no decision better than decision that might be sub-optimal, because I'm not sure where I stand on that. I think that Gary and you can keep anyone from overstepping themselves well enough to risk it until you/we get more proper designers. I am also actively recruiting [for the Design Team] Good to know. If this is going to get in the way of that (I'm not saying you said that), please let us know and I'll move on to other things. -walter Martin pgphhtRL8bAqr.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Sun, 2010-11-21 at 17:49 +, Martin Dengler wrote: I see your point. Can we get Bernie to confirm the distinction? Perhaps you or he could provide an example of a UI-related decision that is not HIG-related[1]? Splitting authority on UI changes and code changes is probably necessary because experts in both fields are very rare. The downside is that now each patch that touches the UI needs to go through two distinct stages of approval. In theory this is as simple as waiting for an email reply, but in practice almost all the UI changes we've pushed form Paraguay and Uruguay required extenuating discussions. Some proposed changes got stalled because the submitter eventually gave up trying. There was a time in which Eben was the UI dictator, Marco was the code dictator, and minor changes to the UI could happen in one day. So, splitting authority is probably ok, as long as there's a very tight communication loop between decision makers. On the other hand, establishing a UI committee and a code committee seems dangerous to me. Even high-profile committees are slow and indecisive. See for example C++ and XHTML. This doesn't mean we can't have multiple people participate in UI discussions or reviewing patches on the mailing list. Leadership is something that happens very naturally and informally in healthy projects much bigger than us. Over the last year, the Xbox Media Center (http://xbmc.org) merged about 20 patches per day. That's about 20 times the commit rate on the sugar repository! If we come up with *committees* to manage this, we'd better give up now. == On the true meaning of Dictator == Sugar Labs is fundamentally a democratic organization, because we elect an Oversight Board to represent the community. However, like in all democracies, executive powers are delegated to a certain number of ministers, officials and directors. If every decision had to go through some parliament or committee, democracies wouldn't function. My metaphor of a dictator is mostly a joke, because what I'm really advocating for is ordinary managers with the autonomy to make decisions. These managers could be appointed by the Board, if necessary, but is it really necessary? There are probably 2-3 possible candidates for the Design Team and 2-3 people for the Development Team. Why can't these people simply have a little talk on IRC and come up with a name to put in the wiki? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: Martin and I talked for bit this evening and I believe that I managed to persuade him to support my [UI Dictator team] proposal. I do, for the reasons mentioned in Michael's key arguments. P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. With that in mind, I think we should just have more people actively participate in the design team. I'm interested, so have put my name down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members . I hope anyone else interested in being active, will do the same. Michael Stone, Bernie Innocenti, I'm looking at you. Gary, can you add / correct anything from our conversation? Michael, is there anything I've misunderstood/misremembered about your proposal? Would you want the Design Team to adopt your what does the committee do[1] responsibilities? Martin [1] http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html pgpjqwF0R3RbA.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Sat, Nov 20, 2010 at 4:32 AM, Martin Dengler mar...@martindengler.com wrote: On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: Martin and I talked for bit this evening and I believe that I managed to persuade him to support my [UI Dictator team] proposal. I do, for the reasons mentioned in Michael's key arguments. P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. With that in mind, I think we should just have more people actively participate in the design team. I'm interested, so have put my name down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members . I hope anyone else interested in being active, will do the same. Michael Stone, Bernie Innocenti, I'm looking at you. Gary, can you add / correct anything from our conversation? Michael, is there anything I've misunderstood/misremembered about your proposal? Would you want the Design Team to adopt your what does the committee do[1] responsibilities? Martin [1] http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I mostly kind of agree with this. But adding a bunch of developers to the design team will not help it accomplish its design goals. We need more designers involved. And we need to stay focused on Sugar's core design principles. One thing I do remember from your IRC discussion with Gary (I was on the edge of the conversation) is the need to bring the HIG up to date. While this may be considered tactical, I think it is strategic, in that sets the tone for all further actions. (For the same reason, I have been advocating for an architectural document from the Engineering perspective.) -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
As an advocate for Sugar in the field in my work, I'm chiming in to support Walter's point. What might help Sugar is a designer who can articulate a strong design point of view by understanding the needs of the users and translating them, guided by the Sugar core design principles, into a plan for development. Design is not a set of isolated decisions about what features to add or take away but how to move consistently toward a goal, in Sugar's case an OS and computing environment that can help children as they learn. Designers have particular skills that are not obvious. Good ones are masters at modeling the needs of users in astonishing detail and accuracy, and it is their job to negotiate the terrain between the stated design goals of an organization, the user experience, and the implementation by developers. It's not only Apple that has a distinct design point of view but really any company that makes a product that works and grows. So Bernie, I think what you were asking for is not a Dictator, who suggests, approves or denies features, but someone to lead by articulating the user model and helping the community develop it in a coordinated effort. Barbara ~ Barbara Barry, PhD Director of Learning One Laptop per Child Foundation OLPC Middle East On Sat, Nov 20, 2010 at 8:42 AM, Walter Bender walter.ben...@gmail.comwrote: On Sat, Nov 20, 2010 at 4:32 AM, Martin Dengler mar...@martindengler.com wrote: On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: Martin and I talked for bit this evening and I believe that I managed to persuade him to support my [UI Dictator team] proposal. I do, for the reasons mentioned in Michael's key arguments. P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. With that in mind, I think we should just have more people actively participate in the design team. I'm interested, so have put my name down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members . I hope anyone else interested in being active, will do the same. Michael Stone, Bernie Innocenti, I'm looking at you. Gary, can you add / correct anything from our conversation? Michael, is there anything I've misunderstood/misremembered about your proposal? Would you want the Design Team to adopt your what does the committee do[1] responsibilities? Martin [1] http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I mostly kind of agree with this. But adding a bunch of developers to the design team will not help it accomplish its design goals. We need more designers involved. And we need to stay focused on Sugar's core design principles. One thing I do remember from your IRC discussion with Gary (I was on the edge of the conversation) is the need to bring the HIG up to date. While this may be considered tactical, I think it is strategic, in that sets the tone for all further actions. (For the same reason, I have been advocating for an architectural document from the Engineering perspective.) -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
Hi Martin, On 20 Nov 2010, at 09:32, Martin Dengler wrote: On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: Martin and I talked for bit this evening and I believe that I managed to persuade him to support my [UI Dictator team] proposal. I do, for the reasons mentioned in Michael's key arguments. P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. With that in mind, I think we should just have more people actively participate in the design team. I'm interested, so have put my name down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members . I hope anyone else interested in being active, will do the same. Michael Stone, Bernie Innocenti, I'm looking at you. Gary, can you add / correct anything from our conversation? Summary: A two prong attack. 1) HIG cleanup and polishing effort (one ring to rule them all) 2) Focus on keeping a core of HIG compliant quality activities to act as our ambassadors Hope you don't mind me posting, here's the irc log for those that want to skim: [03:45] mtd: garycmartin: I was wondering if you had any thoughts about the UI dictator proposal [03:45] mtd: garycmartin: given you're one of the victims m_stone named [03:45] garycmartin: mtd: yea... :) [03:46] garycmartin: mtd: I see two main prongs of attack. [03:46] garycmartin: mtd: HIG (one ring to rule them all) [03:47] garycmartin: mtd: Quality activities (make sure we have a handful of excellent HIG compliant examples) [03:48] mtd: garycmartin: ok, good to remember what we're after :) [03:49] garycmartin: mtd: Unfortunately most ports or new contributors don't seem to either read the first, or look at any of the second. Many can't even provide a basic HIG compliant icon :-( [03:50] garycmartin: mtd: as to how we get there... [03:51] garycmartin: mtd: I've been threatening to edit the HIG, there's plenty of obviously dud history in there now that can go with close to zero discussion. [03:52] garycmartin: mtd: I was thinking of initially striking thru the out of date text, but leaving it there for some weeks/months. [03:53] mtd: garycmartin: cool [03:53] mtd: garycmartin: I think a new HIG version makes plenty of sense [03:53] mtd: garycmartin: and wow, you want to do it :) [03:53] garycmartin: mtd: With perhaps a new text colour for any additions I make, again for a month or so to give those with an interest the time to scan through. [03:54] mtd: garycmartin: cool [03:55] garycmartin: mtd: I'm pretty fed up with pinging folks on the list and replying to random email. It never seems to end and often seems to go silent. Would be quicker just to point folks to the HIG. [03:56] mtd: garycmartin: yeah, I don't think that'd be too contentious [03:56] mtd: garycmartin: (to take that approach) [03:56] garycmartin: mtd: As to landing specific patches, I'd have to go with If it's not HIG compliant, it gets an instant NAK, with a pointer to the HIG. [03:57] mtd: garycmartin: understood and agreed [03:57] mtd: garycmartin: so when you're done, I have a few questions. But please continue. [03:59] garycmartin: mtd: The patcher can then request a HIG update if they feel strongly about their proposed HIG design. Argument, as per usual, one the dev list by interested parties. If there's no agreement, it must default to a NAK. [04:00] garycmartin: (s/one/on/) [04:01] mtd: garycmartin: sounds good [04:01] garycmartin: mtd: Go on, fire some questions. [04:03] mtd: garycmartin: two points to consider, more than questions: the actions you've set out imply, to me, that the committee / dictator is acting as the UI maintainer; is that intentional? [04:03] mtd: garycmartin: second, it also seems to imply that it owns the HIG; intentional as well? [04:04] mtd: garycmartin: one minor one is: for patch acceptance, do we require HIG update sometimes / always if the HIG is silent / ambiguous on something affected / influencing the patch? [04:04] • mtd finishes. [04:04] garycmartin: mtd: yes I didn't completely follow that end argument from Michael. [04:06] mtd: garycmartin: do my questions make it clearer? or shall I clarify? [04:06] garycmartin: mtd: I don't think the HIG should often change, any edits should be minimal, but we do need a good parse through it just now to get back in sync. Obviously there are also some totally new areas such as touch support. [04:08] garycmartin: mtd: HIG grey (or blank) area cases you mean? [04:10]
Re: [Sugar-devel] Sugar UI Dictator
On Sat, 20 Nov 2010 at 09:32:53 +, Martin Dengler wrote: On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. @Martin -- Choosing both seems like a bad idea to me because it: a) balloons the scope of the problem to be solved, b) shrinks the population of qualified participants, and c) seems likely to cause turf wars. Instead, I would prefer to stay focused on the need for UI-decision-making that Bernie identified in his initial email. It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. Re-invented is a rather ambiguous term. If you mean defined the scope of, winnowed the membership of, empowered, and sought concrete commitments from... then perhaps we agree. If you mean something else, then perhaps you should be more explicit. With that in mind, I think we should just have more people actively participate in the design team. I'm interested, so have put my name down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members I hope anyone else interested in being active, will do the same. Michael Stone, Bernie Innocenti, I'm looking at you. Gary, can you add / correct anything from our conversation? Michael, is there anything I've misunderstood/misremembered about your proposal? Would you want the Design Team to adopt your what does the committee do[1] responsibilities? I care about the substance, not the name: the UI committee that I'm describing has a fixed membership, offers a service-level agreement, and is answerable to the Oversight Board. In short, it is *designed* to meet Bernie's need for competent, respected, decisive, and dependable UI decision-making. Does the Design Team that you, Gary, and Bernie are thinking of share these properties? --- On Sat, 20 Nov 2010 at 08:42:42 -0500, Walter Bender wrote: I mostly kind of agree with this. @Walter -- I'm not sure what this refers to. But adding a bunch of developers to the design team will not help it accomplish its design goals. Two comments: 1. I don't see a bunch of developers; I see specific people (Gary, Martin, Eben, Christian, Bernie, ...) with specific talents, predispositions, and availabilities. 2. Of the available choices, who would you be most comfortable empowering? We need more designers involved. What is your plan for getting them involved? (My plan, such as it is, is: a) to make a place where they will want to come and b) to develop the pre-existing skills and sensibilities of the people we already have) And we need to stay focused on Sugar's core design principles. One thing I do remember from your IRC discussion with Gary (I was on the edge of the conversation) is the need to bring the HIG up to date. While this may be considered tactical, I think it is strategic, in that sets the tone for all further actions. (For the same reason, I have been advocating for an architectural document from the Engineering perspective.) First, I completely agree with you that these are important tasks. However, I don't see anyone willing to work on them at this time. Do you? If so, who did I miss? If not, why is no one willing to do the work that many people agree is important? Might they be unwilling because they don't see how the work can be completed successfully in the prevailing organizational conditions? --- On Sat, 20 Nov 2010 at 09:38:57 -0500, Barbara Barry wrote: As an advocate for Sugar in the field in my work, I'm chiming in to support Walter's point. What might help Sugar is a designer who can articulate a strong design point of view by understanding the needs of the users and translating them, guided by the Sugar core design principles, into a plan for development. Design is not a set of isolated decisions about what features to add or take away but how to move consistently toward a goal, in Sugar's case an OS and computing environment that can help children as they learn. Designers have particular skills that are not obvious. Good ones are masters at modeling the needs of users in astonishing detail and accuracy, and it is their job to negotiate the terrain between the stated design goals of an organization, the user experience, and the implementation by developers. It's not only Apple that has a distinct design point of view but really any
Re: [Sugar-devel] Sugar UI Dictator
On Sat, Nov 20, 2010 at 5:55 PM, Michael Stone mich...@laptop.org wrote: On Sat, 20 Nov 2010 at 09:32:53 +, Martin Dengler wrote: On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. @Martin -- Choosing both seems like a bad idea to me because it: a) balloons the scope of the problem to be solved, b) shrinks the population of qualified participants, and c) seems likely to cause turf wars. Instead, I would prefer to stay focused on the need for UI-decision-making that Bernie identified in his initial email. It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. Re-invented is a rather ambiguous term. If you mean defined the scope of, winnowed the membership of, empowered, and sought concrete commitments from... then perhaps we agree. If you mean something else, then perhaps you should be more explicit. With that in mind, I think we should just have more people actively participate in the design team. I'm interested, so have put my name down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members I hope anyone else interested in being active, will do the same. Michael Stone, Bernie Innocenti, I'm looking at you. Gary, can you add / correct anything from our conversation? Michael, is there anything I've misunderstood/misremembered about your proposal? Would you want the Design Team to adopt your what does the committee do[1] responsibilities? I care about the substance, not the name: the UI committee that I'm describing has a fixed membership, offers a service-level agreement, and is answerable to the Oversight Board. In short, it is *designed* to meet Bernie's need for competent, respected, decisive, and dependable UI decision-making. Does the Design Team that you, Gary, and Bernie are thinking of share these properties? --- On Sat, 20 Nov 2010 at 08:42:42 -0500, Walter Bender wrote: I mostly kind of agree with this. @Walter -- I'm not sure what this refers to. Martin's post that was directly above my comment. But adding a bunch of developers to the design team will not help it accomplish its design goals. Two comments: 1. I don't see a bunch of developers; I see specific people (Gary, Martin, Eben, Christian, Bernie, ...) with specific talents, predispositions, and availabilities. Even on your short list, I see people who are not designers... there is a call to add more non-designers. Names are accumulating on http://wiki.sugarlabs.org/go/Design_Team/Contacts 2. Of the available choices, who would you be most comfortable empowering? The people on the list who have demonstrated that they have a deep understanding of the design goals of Sugar and who have the time to make a sustained commitment to this task. Probably that would be Gary, Martin, and me at this point. We need more designers involved. What is your plan for getting them involved? I've been trying to recruit at universities. But also, I think great design attracts great designers. Another reason to keep our standards high. (My plan, such as it is, is: a) to make a place where they will want to come and Not sure how any suggestions in the above thread does that, but I may have overlooked something. b) to develop the pre-existing skills and sensibilities of the people we already have) No argument from me except that I don't want to divert non-designers into making design decisions, which seems to have been the direction we were heading. And we need to stay focused on Sugar's core design principles. One thing I do remember from your IRC discussion with Gary (I was on the edge of the conversation) is the need to bring the HIG up to date. While this may be considered tactical, I think it is strategic, in that sets the tone for all further actions. (For the same reason, I have been advocating for an architectural document from the Engineering perspective.) First, I completely agree with you that these are important tasks. However, I don't see anyone willing to work on them at this time. Do you? No. But I am also actively recruiting in this area and trying to remove distractions from some people whom I think could contribute to this area. If so, who did I miss? If not, why is no one willing to do the work that many people agree is important? I think it is easy to get sucked into the world
Re: [Sugar-devel] Sugar UI Dictator
On Wed, 10 Nov 2010 at 09:16:41 +, Martin Dengler wrote: On Tue, Nov 09, 2010 at 12:27:18PM -0500, Michael Stone wrote: On Tue, 9 Nov 2010 at 03:12:41 +, Martin Dengler wrote: On Mon, Nov 08, 2010 at 07:49:19PM -0500, Bernie Innocenti wrote: [UX design might be better] if we agreed to delegate all design decisions to one clever dictator Great idea. [...] [if noone steps forward], perhaps we could just agree on some group of people who will be the dictators, and not revisit that for a while. Agreeing on small group of people seems easy to arrange. Here's a strawman proposal[1] Your proposal seems like a good way to do it. I propose another decent way as an appendix[2]. I welcome someone else implementing either. Gentlefolks, Martin and I talked for bit this evening and I believe that I managed to persuade him to support my proposal. Here were the key arguments: 1. We're currently very vulnerable to diffusion of responsibility. Concentrating responsibility in three specific people will help to address this problem. 2. We don't really have a dispute resolution mechanism other than drop it. The Oversight Board is ideally positioned to help resolve disputes generated by its committees' decisions and procedures. 3. It's not okay to block patches on feedback or decisions from an absent Design Team. As with diffusion of responsibility, being explicit about the time frame on which decisions will be made will help prevent these patches from languishing. 4. We need to be able to work smoothly with OLPC if and when they succeed in hiring a Sugar UX Designer [1]. Being able to elect said designer to a seat on a previously established design committee seems like a potentially good way to involve this person in our decision-making while still preserving fairness, transparency, and appropriate continuity with the past. Regards, Michael P.S. - Later, after finding our common ground, we spoke further about the issues that we each hoped the committee might be able to address. In the course of the conversation, we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? [1]: http://laptop.org/en/utility/people/opportunities.shtml#Sugar%20UI%20Designer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Tue, Nov 09, 2010 at 12:27:18PM -0500, Michael Stone wrote: On Tue, 9 Nov 2010 at 03:12:41 +, Martin Dengler wrote: On Mon, Nov 08, 2010 at 07:49:19PM -0500, Bernie Innocenti wrote: [UX design might be better] if we agreed to delegate all design decisions to one clever dictator Great idea. [...] [if noone steps forward], perhaps we could just agree on some group of people who will be the dictators, and not revisit that for a while. Agreeing on small group of people seems easy to arrange. Here's a strawman proposal[1] Your proposal seems like a good way to do it. I propose another decent way as an appendix[2]. I welcome someone else implementing either. I think both, however, require more administration than we're liable to get :(. I think the implicit, current situation is: 1. All patches have to satisfy any committer that notices... 2. unless overruled by the Design Team And that's not too bad, given there are a large number of sugar committers and not too many members of the Design Team and neither group changes very often. The bad part is that it was implicit, and that we could do better (like what you proposed). Martin 1. http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html 2. Proposal #2, Concerning UX patches: 0 - any patch is a UX patch if a committer says it is 1 - The UX patch acceptance criteria will be as follows: 1a - UX patches have to be accompanied by HIG change patches (in any reviewable form), or a statement as to why none is required 1b - UX patches with non-trivial HIG changes should be accompanied by appropriate supporting material (non-anecdotal user feedback, for example) 2 - accepting UX patches will be done by the following people: 2a - any committer can commit a UX patch as long as it complies with the criteria above 2b - any committer can revert a UX patch 2c - the Design Team will adjudicate any disagreements amongst committers Issues: a) my intent is that the main difference between Michael's proposal[1] and mine be the degree of formality of the acceptance committee. b) social considerations will be used keep any disagreements to a minimum; amicable differences of opinion may persist. c) it is intentional that anyone who can commit code can affect the UX as long as the design team isn't sufficiently angered: the bias is towards people willing to do the work, as that selects for the momentum and contributors that Sugar needs. d) I haven't thought about this enough, but this will have to do. pgp5JPIGrBwrt.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
On Tue, 9 Nov 2010 at 03:12:41 +, Martin Dengler wrote: On Mon, Nov 08, 2010 at 07:49:19PM -0500, Bernie Innocenti wrote: On Fri, 2010-10-29 at 10:02 +0100, Martin Dengler wrote: IMO a decent justification and a willingness to update the affected wiki pages - including the HIG - to a similar or better standard as what existed before should almost be enough for me. What I'm worried about is the HIG that exists - incomplete as it is - is being chipped away and we're left with UI that's justified by nothing but a patchwork of ad-hoc decisions made by very different people with very different users in mind. While I strongly believe in the power of loosely-managed volunteer-driven development, distributed authority doesn't seem to work equally well when it comes to human interface design. Good design implies one consistent vision, which is hard to obtain collaboratively. A case-by-case decision process results in either inconclusive discussions or UI inconsistency. It might work better if we agreed to delegate all design decisions to one clever dictator Great idea. Sebastian is calling for a HIG update as part of his SLOBs platform - perhaps the new HIG Dictator should commit to doing that in some fixed period of time? Failing one Dictator, erm, seizing power, perhaps we could just agree on some group of people who will be the dictators, and not revisit that for a while. Agreeing on small group of people seems easy to arrange. Here's a strawman proposal for how that might look: 1. Per [1], the Oversight Board creates an ad-hoc 3-person UI Committee. 2. The initial voting members will be mtd, garycmartin, and (a third person to be determined). 3. The initial term will be for six months. Next, there are details that we need to agree upon. For example, what does the committee do and at what rate does it do it? Another strawman: 4. The committee will meet as needed in order to address Queries received by any of its voting members. 5. The committee will meet within 2 weeks of receiving a Query. 6. Proposed Responses will be accepted by the committee by majority vote. 7. Minutes, received Queries, proposed Responses, and related discussion will be archived and organized by the Committee Secretary on the wiki. Finally, there some harder questions that I don't have easy answers for: a) Who do we expect to do the work of formulating responses to Queries? b) How will we make the committee successful and fun? In particular, how do we expect to organize the performance of the work that is necessary to prepare for and to follow through on the committee's decisions? (i.e., who's actually going to go out to collect experience reports, to perform user testing, or to develop prototypes when the Committee determines that these actions are necessary in order to properly respond to a Query?) c) What kinds of disputes and/or grievances do we anticipate and how do we expect to resolve them? Thoughts? Regards, Michael [1]: http://wiki.sugarlabs.org/go/Sugar_Labs/Governance#Committees ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar UI Dictator
Whoever ends up as dictator: I'd still love to stay involved as an advisor. I'd volunteer to throw my name into the hat for election if not for lack of time. In any case, I agree that it would be great (and necessary) to have a dedicated UX person who could keep the design up-to-date and consistent with our experiential goals. Christian On Tue, Nov 9, 2010 at 12:27 PM, Michael Stone mich...@laptop.org wrote: On Tue, 9 Nov 2010 at 03:12:41 +, Martin Dengler wrote: On Mon, Nov 08, 2010 at 07:49:19PM -0500, Bernie Innocenti wrote: On Fri, 2010-10-29 at 10:02 +0100, Martin Dengler wrote: IMO a decent justification and a willingness to update the affected wiki pages - including the HIG - to a similar or better standard as what existed before should almost be enough for me. What I'm worried about is the HIG that exists - incomplete as it is - is being chipped away and we're left with UI that's justified by nothing but a patchwork of ad-hoc decisions made by very different people with very different users in mind. While I strongly believe in the power of loosely-managed volunteer-driven development, distributed authority doesn't seem to work equally well when it comes to human interface design. Good design implies one consistent vision, which is hard to obtain collaboratively. A case-by-case decision process results in either inconclusive discussions or UI inconsistency. It might work better if we agreed to delegate all design decisions to one clever dictator Great idea. Sebastian is calling for a HIG update as part of his SLOBs platform - perhaps the new HIG Dictator should commit to doing that in some fixed period of time? Failing one Dictator, erm, seizing power, perhaps we could just agree on some group of people who will be the dictators, and not revisit that for a while. Agreeing on small group of people seems easy to arrange. Here's a strawman proposal for how that might look: 1. Per [1], the Oversight Board creates an ad-hoc 3-person UI Committee. 2. The initial voting members will be mtd, garycmartin, and (a third person to be determined). 3. The initial term will be for six months. Next, there are details that we need to agree upon. For example, what does the committee do and at what rate does it do it? Another strawman: 4. The committee will meet as needed in order to address Queries received by any of its voting members. 5. The committee will meet within 2 weeks of receiving a Query. 6. Proposed Responses will be accepted by the committee by majority vote. 7. Minutes, received Queries, proposed Responses, and related discussion will be archived and organized by the Committee Secretary on the wiki. Finally, there some harder questions that I don't have easy answers for: a) Who do we expect to do the work of formulating responses to Queries? b) How will we make the committee successful and fun? In particular, how do we expect to organize the performance of the work that is necessary to prepare for and to follow through on the committee's decisions? (i.e., who's actually going to go out to collect experience reports, to perform user testing, or to develop prototypes when the Committee determines that these actions are necessary in order to properly respond to a Query?) c) What kinds of disputes and/or grievances do we anticipate and how do we expect to resolve them? Thoughts? Regards, Michael [1]: http://wiki.sugarlabs.org/go/Sugar_Labs/Governance#Committees -- anyth...@christianmarcschmidt.com 917/ 575 0013 http://www.christianmarcschmidt.com http://www.linkedin.com/in/christianmarcschmidt http://twitter.com/cms_ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar UI Dictator
[cc += eben, cms] On Fri, 2010-10-29 at 10:02 +0100, Martin Dengler wrote: IMO a decent justification and a willingness to update the affected wiki pages - including the HIG - to a similar or better standard as what existed before should almost be enough for me. What I'm worried about is the HIG that exists - incomplete as it is - is being chipped away and we're left with UI that's justified by nothing but a patchwork of ad-hoc decisions made by very different people with very different users in mind. While I strongly believe in the power of loosely-managed volunteer-driven development, distributed authority doesn't seem to work equally well when it comes to human interface design. Good design implies one consistent vision, which is hard to obtain collaboratively. A case-by-case decision process results in either inconclusive discussions or UI inconsistency. It might work better if we agreed to delegate all design decisions to one clever dictator, in the style of Steve Jobs. In the early days of Sugar, Eben used to cover this role and many would probably agree that it worked very well. It's tempting to say that we already have a Design Team with a Coordinator, but today people proposing changes are supposed to follow a vague process which involves defending the proposal against a variety of alternatives, compromising with some of them in the hope to reach consensus soon or later. What I'm asking for is fundamentally different: there can still be a good public discussion, but in the end only one person would give a clear ACK or NAK within a finite amount of time and effort. At worse you could get a change this part and I will approve. Who should become the dictator could be decided by the currently active members of the design team. A truly great UI Dictator wouldn't undergo the annoying delay of democratic elections ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
