[Design] Re: implementation ideas for "sections"

Mimi Yin mimi at osafoundation.org
Wed Feb 8 18:00:04 PST 2006


On the whole, I think there are a wide variety of scenarios to  
consider and many different ways to activate, define and interact  
with "sections" in the table. The design process we're shooting for  
is to get enough of a basic table + rudimentary Triage workflow up  
and running that we can do some lightweight user exercises to help  
direct and narrow design possibilities for more advanced  
functionality. User interviews (which I'm starting this week) will  
also help.

See more comments in-line:

On Feb 6, 2006, at 4:46 PM, Alec Flett wrote:

> Mimi Yin wrote:
>> A couple more scenarios/issue related to sections. Please submit  
>> your own!
>>
>> ===
>> User would like the ability to "divvy-up" the Triage sections into  
>> more fine-grain sections:
>> ie. Now versus Today versus Tonight...
>>
> I think the above and this:
>> ===
>> Laying out your information in an organizational structure
>>
>> There is also a bigger issue related to sections which has to do  
>> with the higher-level organizational needs some users have when  
>> trying to get a grip on large quantities of data.
>>
> Are very related - it really asks: are sections yet another way of  
> grouping in chandler (I'm using grouping to mean groups with  
> potential for overlap) or is it really more about partitioning -  
> breaking large data into non-overlapping sections?

I guess I see sections and groups as more fluid. You may start out  
wanting a way to "break down" a large set of data (essentially chunk  
it down into more manageable pieces). However, how you chunk that  
information down may be very straightforward

1. ie. Who column chunked alphabetically: A-D, E-H, etc) OR

2. Personalized (ie. Who column chunked by relationship: Family,  
Friends, Co-workers, Management, Strangers) OR

3. Incredibly specific and semantically inconsistent (ie. Family,  
People I'm meeting with in the Next 2 weeks, People I've met with in  
the last 2 weeks, People I hate)
+ Family is a relationship type
+ The next 2 are defined in terms of time
+ The last is an emotion

I can see situations where all 3 would be useful. I can also see how  
you might start out with 1 and then tweak and customize them to the  
point where you end up with 2 or 3 AND/OR you decide to pull the  
"section" into the sidebar so you have easy access to it at all times.

The difficulty is that the UI affordances appropriate for 1,2 and 3  
are potentially very different (as described in my last email.

> Personally I look at Sections as the latter - partitioning. And  
> this is consistent with some of the affordances you've mentioned  
> before that sound really good - i.e. dragging something from one  
> section to another unsets the attributes that caused it to be in  
> one section, and set the attributes that cause it to be in the  
> other section. More concretely, dragging an item from the "now"  
> section to the "later" section turns the "triageStatus" from "now"  
> to "later"
>
> Just to play devil's advocate with myself though: If you try to  
> "section" by the who column, you're sometimes "sectioning" by a  
> list - try clicking on the "Who" column for some generated data -  
> you'll see sections called <DBRefList:...> and so forth- because  
> some Items' "who" attribute correspond to multiple people.
>
> If we fix this to sort out the actual items in each list, you'll  
> get non-overlapping sections. For instance I could have a mail  
> message sent to "alec and mimi" - and another one sent to "mimi and  
> david" and a third sent to "david and mimi" - so if we have  
> sections for "alec", "mimi" and "david" you'd see two messages in  
> each section for a total of 6 messages, even though there are only  
> 3 messages in total.
>
> In spite of this, I prefer some kind of partitioning rather than  
> grouping - which means "today" and "tonight" are separate sections,  
> as are subsections, and so forth. (And I'm not sure what happens to  
> lists)
>
> As an aside, I don't like the idea of sub-grouping at all because I  
> think between the nested section headers and the items appearing at  
> various "levels" as a result, its going to just clutter up the UI.  
> I know that's kind of weak reasoning, but hey.. I'm welcome to  
> alternates where subsection "headers" make up for that.

Hierarchies aren't inherently ugly, but it's hard work to make them  
visually appealing and comprehensible. But probably not something  
tackle for Plausible Dashboard?

>
>
> Alec
>
>> For many people, the process of placing items into groupings and  
>> sub-groupings and sub-sub-groupings is crucial to their ability to  
>> understand the information they have and how new information  
>> they're receiving is relevant to them.
>>
>> "Filing" essentially employs the "method of loci" technique  
>> Philippe posted an article about a couple of weeks ago...where  
>> people get a sense of the landscape of their information by  
>> arranging it or mapping it in a fixed location-based space:
>>
>> +  http://news.bbc.co.uk/2/hi/health/3152502.stm
>> +  http://www.newscientist.com/article.ns?id=dn3181
>>
>> It also allows people to "chunk things down" to a manageable  
>> number of groupings so that they can hold an "overall picture" of  
>> all of their information, in their head, in a single moment.
>>
>> Some other people have also written in about how mind-maps are  
>> better for mapping information that's in your head onto "paper".  
>> See thread: http://lists.osafoundation.org/pipermail/design/2006- 
>> January/003892.html
>>
>> These are all very real problems that are in some sense at the  
>> core of Chandler as an Information Management System and they're  
>> directly related to many of the Virtuality discussions we've had  
>> in the past.
>>
>> If Folders and Hierarchy are a good model for a location-based  
>> filed systems...what kind of metaphor does Chandler need with our  
>> "new world" data model?
>>
>> Unfortunately, I think these "Organizational Paradigm" issues need  
>> to be addressed in several *post* 0.7 planning design meetings and  
>> is a problem that is probably out of scope for this release.
>>
>> Mimi
>>
>> On Feb 2, 2006, at 10:21 AM, Mimi Yin wrote:
>>
>>> Features needed to establish a framework for the Triage workflow:  
>>> (this is stuff beyond basic table)
>>> + Ability to define focus (Now, Later, Done)
>>> + Ability for users to tweak focus (Now, Today, Tonight, Later,  
>>> Done)
>>> + Ability to "put" items on lists via Labeling (ie. @Juno,  
>>> Project: Foo, Calls list)
>>>
>>> User scenarios for Stage 2 Dashboard with "Sections":
>>> ===
>>> Jim is in a meeting with Kario and would like to see both his  
>>> @Kario list and the list of items he's been maintaining for each  
>>> of the projects he and Kario work on together:
>>> + @Kario
>>> + Project: Learn Kanji
>>> + Project: Buy a notebook
>>>
>>> Option 1 to meet this use case
>>> + Add these 3 lists to the sidebar
>>> + Overlay these 3 lists
>>> + Summary pane splits into 3 panes, 1 for each list with  
>>> independent scollbars
>>>
>>> Option 2 to meet this use case
>>> + Provide affordances to let user defined sections based on a mix  
>>> of attributes in a single summary pane. Sections would *NOT* be  
>>> tied to a single column.
>>>
>>> Some sections might be:
>>> + Triage status: Now
>>> + Project: Foo
>>> + @ Karin
>>> + @ Work
>>>
>>> ===
>>>
>>> SECTION BY COLUMN OPTION
>>> + Allow sectioning by any column displayed in the summary pane:  
>>> Who, Date, Stamping columns, and any columns the user defines
>>> + User clicks on a column to section by that column
>>>
>>> Some "Section by column" user scenarios
>>> + To aid in search and scanning
>>> + To view threads of items
>>> + To review all of your projects in a single view
>>>
>>> Mimi
>>>
>>> On Feb 2, 2006, at 10:06 AM, Mimi Yin wrote:
>>>
>>>> Forwarding an exchange about progress on Sections to the  
>>>> list...will follow-up with an email outlining the different  
>>>> "options" we're considering for sectioning the table in 0.7.
>>>>
>>>>
>>>>> On Feb 1, 2006, at 5:16 PM, Mimi Yin wrote:
>>>>>
>>>>>> Wow, that was unexpected...just to clarify...I'm not proposing  
>>>>>> "no sections". I'm proposing that we use the sidebar as a way  
>>>>>> to show and hide sections. I was trying to get at the root of  
>>>>>> Mitch's proposal and looking for some other implementation  
>>>>>> ideas at the same time.
>>>>>>
>>>>>> Maybe we can have a quick conversation about this after the  
>>>>>> staff meeting tomorrow.
>>>>>>
>>>>>> Mimi
>>>>>>
>>>>>> At 4:39 PM -0800 2/1/06, Alec Flett wrote:
>>>>>>> Thanks Mimi -
>>>>>>> From the engineering side, I've got an update: I've actually  
>>>>>>> got a really really barebones implementation of sections in  
>>>>>>> the table summary view.. here's a screen shot of it in action:
>>>>>>>
>>>>>>> This may not look like much, but this demonstrates the  
>>>>>>> plumbing required to make this happen. Specifically, the  
>>>>>>> "section header" just makes each column in the header say  
>>>>>>> "[Section: foo]" - and this is working for any arbitrary  
>>>>>>> value at the moment, so what you see is sectioning by triage,  
>>>>>>> but you can click on who/about and get sections based on them  
>>>>>>> too.
>>>>>>>
>>>>>>> What's left here:
>>>>>>> 1) drawing something better than [Section: foo] in each cell  
>>>>>>> - we can probably rig something up pretty easily with  
>>>>>>> attribute editors
>>>>>>> 2) making section rows exapandable/clickable/etc
>>>>>>> 3) lots of little odd bugs
>>>>>>>
>>>>>>> I'm still not sure I completely understand Mimi's proposal,  
>>>>>>> but I'll take that up on the design list.... but if sections  
>>>>>>> as you wanted were, say, halfway there, would the alternative  
>>>>>>> non-sectioned triage design still be relevant?
>>>>>>>
>>>>>>> Alec
>>>>>>>
>>>>>>>
>>>>>>> Attachment converted: Lamby:sections-basic.png (PNGf/ogle)  
>>>>>>> (00059C26)
>>>>>>
>>>>>
>>>>
>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>
>>>> Open Source Applications Foundation "Design" mailing list
>>>> http://lists.osafoundation.org/mailman/listinfo/design
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Design" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/design
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060208/1de05768/attachment.html


More information about the Design mailing list