[Design] Collaborative design list management and other cross-silo workflows to consider as tenets

selva r selva11r at yahoo.ca
Sat Dec 3 13:23:54 PST 2005

Greetings Mimi,
 There are severe limitations as well as ongoing unneccessary overhead manpower demands involved in trying to triage and categorize discussion list proposals by an email only system.  
 Although some possible models for trying to develop a web based application for assisting with this ongoing task may be more graphically demanding (such as that I described previously on this thread),  I think a more rudimentary, less graphically sophisticated model for categorizing, triaging, and voting on feature suggestions brought up in email list discussions should be considered sooner rather than too much later.  JMHO.

Mimi Yin <mimiyin at gmail.com> wrote: Hi Selva,
 I think the exercise we want to focus on right now is high-level brainstorming of a variety of different user scenarios for usage. The details of HOW that usage might happen are 
 We are also looking for simple, yet useful solutions we can accomplish in 1 release. 
 Aside from implementation cost, a design process argument for starting with something fairly simple and basic is that it allows us to isolate and test the "workflow structure" and "semantic structure / information architecture" of the design without worrying about how the specifics of the UI 
 It also means we get to see if by simply restructuring the interaction workflow, we make something really useful without having to have a particularly "feature-heavy" UI.
 By restructuring interaction workflow, I mean things like: 
 1. Taking something like a mailing list and turning it into a shared set of information that is collaborative managed rather than individually parsed by each subscriber to the mailing list.
 2. Allowing people to "pick out focus issues from the list to guide the discussion" rather than leaving it up to the entire community to read and respond to every message.
 On 12/1/05, selva r <selva11r at yahoo.ca> wrote:  That's actually close to what I was thinking about as a possible aid for collaborative project planning for Chandler.  However, instead of managing it solely by email, I was wondering about the possibility of having a server based edition of the previously discussed "Cactus" or "Tree" application that's modified a bit to allow for voting of items within the Cactus by Chandler email list members. 

For example, a server based Cactus app could have features similar to the previously discussed desktop Cactus app so that 'Now' items are say Green color and furthest raised above the background with the largest drop shadow.  'Later' items might then be Yellow color with a smaller drop shadow, and finally 'Done' items might be grey color and at the level of the background.  

Again, the background might be branches of a virtual tree or cactus where title bars of proposed Chandler features & solutions are embedded onto, or we could just start with a plain background to get things rolling faster. 

If the Now-Later-Done filter is then toggle switched by way of a pull down menu to a 'Voting' filter, then this could then allow Chandler list members to vote on the various proposed Chandler features.  

Under the Voting filter, list members could then cast their assigned quota of votes per month to what ever features they deem most important to address first. 

Under the Voting filter, those title bars that get the most votes could be depicted as furthest raised off the background with the largest drop shadow and be presented in say the darkest hue of a single color such as red.  Title bars of items getting less votes might be less raised off the background with a smaller drop shadow and be presented in a less intense hue of the same color using a gradient system.  Of course a numerical voting tally of each item could also be included within the item's title bar. 

Design list management personnel would then have the responsibility to tally up the voted upon items and decide whether or not to veto some of these items due to reasons not accounted for by the general design list, and then re-classify the Cactus / Tree items each month so that items are continuously triaged through the Now / Later / Done workflow as the branches of the Cactus gradually expand. 

Similar to the previous discussions on a desktop Cactus / Tree application, we could present the server based group edition also in tabbed format so that, for example, we could group email items tree on one tab, a datebook items tree on another tab, and so on. 

One important issue to sort out here would be who has authority to add items to a server Cactus / Tree app.  Can any Design member add items on their own?  This might result in too much noise to signal ratio problem.  Perhaps items should first be discussed informally in the Design email list first and then the author could then present a final proposal for the item and the proposal should then carry at least two other list members' support before it can be promoted to the web based Cactus application for general voting and triaging. 

Functionally, this would sort of be like a wiki but more graphically organized in terms of triaged workflow to help with project planning and also allow for group voting input capabilities as well as vetoing capability by Design management staff prior to actual triaging of items. 

A quick overview of the web based Cactus / Tree app also allows Design list members to see which items are currently in the Now box to help orient their discussions.


Mimi Yin <mimi at osafoundation.org>  wrote:
   In response to some of the emails that have been flying around, particularly concerning whether we should or shouldn't do certain features, such as free-busy, email or PDA sync, I'd like to propose an alternate way to frame the conversation. 

 Rather than talking about how technically, we really need to start on email now if we want to have it in 1.0, how about throwing some ideas around for how we could have immediately usable and useful email as a part of a more horizontal or cross-silo usage scenario? That way, we would have some concrete and practical reasons to  work on multiple areas of the app at the same time while maintaining a clear end-user focus and goal? 

 Below are some examples of what I'm talking about, examples of how we might "get to more users" in 0.7 by going cross-silo and addressing some user needs that currently lack solutions. I offer them in the hopes of generating a wealth of examples through a group brainstorm. 

 The criterion for this exercise are that the scenarios are cross-application, requiring functionality in more than one traditional application area, but are simple enough that we can attain usability in 1 release. 


Could we as an organization experiment with sharing the Design list as a shared collection?
- Where Sheila and I act as mailing list shepherds, triaging mailing list topics between Done, Now and Later to help focus the conversation? 
- Where people can submit crazy ideas so that we have them recorded and stored in the Later area, but the list and community don't feel compelled to stray away from the topics that need to be discussed Now.
- Where people can look in the Done area for "closed issues".  
- Where people can tag and label emails by topic area and other people can come search through the list for their pet topic (this would require making tags shareable in some way).
- Where we can stamp certain mailing list items that are time-sensitive and put them on a Design list calendar of events or milestone dates. (ie. this brainstorm will end on Friday at 2PM, the Dashboard presentation will take place on the 22nd.) 
- Where we can stamp certain mailing list items as tasks and maintain public, task lists showing how we're responding to the list and delegating responsibility in the community as a direct result of the list. ie. Heikki to look more into short-term PDA strategies 

I think this is something we could all use that would directly help in our efforts to moderate and faciliate open-source design.

What about shared task lists for collaborative projects. ie. upcoming CSG meeting or PyCON presentation tasks
- We would want some rudimentary emails to be able to send and receive capital N-notifications. 
- We would want stamping to work so you can put tasks on the calendar.
- We would want basic ability to triage tasks

Can Chandler be a compelling way for people to share resource calendars for conference rooms and projectors and things. So that you could reserve a projector or conference room and then send an email out to ping whoever needs to be pinged, right from the app. 


 I think some attributes that are common to all of these scenarios are:
 - They solve some very serious problems that people have (ie. mailing list overload), therefore, the scenarios are compelling enough for real and serious use of the app. 
 - But the area of information we touch on is not so near and dear to them that the bar for usability is unrealistically high to attain in 1 release (ie. my personal email).  

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list


 Find your next car at Yahoo! Canada Autos  


Find your next car at Yahoo! Canada Autos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20051203/01995720/attachment.html

More information about the Design mailing list