[Design] Re: implementation ideas for "sections"

Mimi Yin mimi at osafoundation.org
Fri Feb 10 14:48:17 PST 2006

Forwarding an IRC conversation with Alec and Grant about implementing  

Cast of Characters:
hamster	 	Mimi
alecf		Alec
gbaillie		Grant


What's done:
+ Sections are attached to column headers. Sorting a column =  
Sectioning by that column
+ Sections "Partition" the view which means that the Sections need to  
be defined in a way that does *not* result in one item living in  
multiple sections
+ Opening and closing sections

What isn't done: (Alec correct me if I'm wrong)
+ Sections look and feel
+ DnD between Sections
+ DnD to reorder Sections
+ Show and Hide Sections

What's going to take more work:
+ Making it so that empty Sections appear show up
+ Allowing for items to appear in multiple Sections
+ Discoverable UI to define new Sections

hamstar: gbaillie, is threading? as in email threads hard to implement?
hamstar:not taking into consideration, UI
alecf: typical UI for threading is hard, for what its worth
gbaillie: Well, given that we have a repository, it's probably not  
hard to do the back end.
alecf: yeah, I'd think the bidirectional stuff would make that part  
VERY easy
hamstar: alecf (even if we re-use sections?)
hamstar:trying to sneak clusters into plausible dashboard
hamstar:VERY easy?
alecf: we could group by thread, that's true - but that's not a  
typical threading model, at least in my experience
hamstar:how so?
alecf:backend easy - just the backend :)
alecf: so you can group by thread which just shows all messages in a  
thread together
alecf:but threads have more information in them
alecf:i.e. which message is a reply to which one
hamstar:right and mebbe allows you to add to thread?
alecf:typically you would show indenting to represent the reply-to  
alecf:so grouping by thread, that would be pretty easy
hamstar:not in most mail clients though
alecf: what do you mean?
hamstar: what about adding to that thread or changing it's members
alecf: I think outlook is the only one that still doesn't do it
hamstar: apple mail doesn't do it either
alecf: but pretty much every other one I've ever used (Thunderbird,  
Eudora, Pine, etc) all do the indenting bit
hamstar: eudora really?
alecf: I'm pretty sure
gbaillie: hamstar,  that was a very conscious decision on the part of  
apple designers[
hamstar: either way, i think not having it would be okay
gbaillie: eudora does almost anything you think of (you just have to  
find the right preference)
hamstar: don't get me started on their preferences
alecf: well anyway, so grouping by thread, easy :) full threaded  
display, hard :)
hamstar: alecf, what about the editing the thread?
gbaillie: yeah, it's kind of the archetype of prefs gone wild
hamstar: rearranging the order or adding to it
alecf: that probably wouldn't be bad - I mean if a thread is just   
another attribute on an item, we could easily group by that
alecf: though as it stands right now, if an item could be a member of  
multiple threads, that's harder to group by
gbaillie: order might require consultation with the irregularly  
shaped tofu dude
alecf: i.e. right now grouping is the "partitioning" that I mentioned  
on the design list
hamstar: i saw tofu dood on the way to 21st amendment for beer
alecf: so if something belongs in multiple sections, that's harder
hamstar: oh i see
hamstar: okay well it would be a cool first step
bluekey: if i was using a nightly build from like two weeks ago is  
their any point in using 0.6.1?
alecf: yeah, I can group by pretty much anything, as long as its a  
partition-style grouping rather than overlapping groups
hamstar: ok
alecf: In fact I'm working on date-grouping with semantic value -  
i.e. "Today" "Yesterday" etc
hamstar: oh cool
alecf: "Last week", "Last Month" etc
hamstar: i wish we had contacts so we could group who by  
relationship: family, work, etc
hamstar: alecf, do you think overlapping sections is a possibility  
under phase 4 for 0.7? ie. experimental sections?
hamstar: also, what about defining new sections
alecf: overlapping sections - yeah, a "maybe" on phase 4
alecf: how would definition of new secitons happen?
alecf: I guess right now since sections are dependent on a particular  
grouping, I'm not sure about one-off sections
hamstar: alecf, you define a new thread and add things to it
hamstar: sort of like defining new attribute values (ie. a new triage  
status value)
alecf: ah ok - makes sense. As it stands now, the display of each  
section is dependent on there actually being an item in the section -  
i.e. I look at the list of items in the display and determine the  
groups from that..
hamstar: oh i see
alecf: so anyhow, I don't think its out of the question to sort of  
force a stub section into the display, but its definitely harder than  
most of the other section work
hamstar: okay
alecf: and we may want to do that anyway if you're grouping on triage  
status and all your items are "now" - we'd certainly want a "later"  
section to drag/drop into even if you don't already have later items
alecf: i.e. right now if everything is "now" and "done" then there is  
no "later" section.. doh! :)
hamstar: ahhh
hamstar: but if you marked something as later, then it would show up
hamstar: so we could possibly define new sections via labeling
alecf: exactly
hamstar: thread: new thread title
alecf: yeah, that would work
hamstar: cool okay
alecf: ok, I gotta run

On Feb 8, 2006, at 6:00 PM, Mimi Yin wrote:

> 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
>>>> ===
>>>> + 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 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/20060210/e25f360c/attachment.htm

More information about the Design mailing list