Forwarding an IRC conversation with Alec and Grant about
implementing sections.
Cast of Characters:
hamster Mimi
alecf Alec
gbaillie Grant
Highlights...
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
relationship
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
===
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
