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?
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.
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:
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.
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation
"Design" mailing list
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
|
