[Design] Answers to Questions from Dashboard Spec Review
stearns at osafoundation.org
Tue Jun 20 09:09:39 PDT 2006
A couple of questions didn't really get answered...
> 2. Are we supporting spreadsheet like in-place editing and keyboard
> navigation or what?
> * As much as we can, but our goal is not to be competitive with
> products like Excel.
OK, well, we're not competitive with Excel now, so I guess we're done. :-)
I asked this question because the spec says two contradicting things,
and because the extent of required keyboard-navigation functionality
isn't obvious to me. I'm hoping the updated spec specifies what keyboard
navigation operations are supposed to be available, and if they'll need
to differ on different platforms, what those differences will be.
> 8. If multiple Items are selected in the table and the user clicks on
> a widget in the table, does the click apply to all selected Items?
> Yes. Triaging multiple items at a time will be a key feature. However,
> it is not important to have in the short-term. If and when users are
> using Chandler so heavily that they desire such a feature, it will be
> a nice problem to have :o)
This sounds like the behavior is supposed to be "clicking in a widget
affects all selected rows", but what if the row clicked in isn't
selected? Does the selection change to be that row? Does the first click
I can imagine two different but consistent mechanisms:
- Clicking in widgets is completely independent of selection; thus,
clicking in a widget only affects the row you clicked in, and doesn't
change the selection. With this scheme, you couldn't use the widgets to
change multiple rows. This is the way Thunderbird's read/unread column
- Clicking in widgets is secondary to selection; clicking in an
unselected row selects it (whether you click in a widget's cell or
elsewhere in the row), at which point the widgets start listening for
clicks. If multiple rows are selected, any rows whose value matches the
clicked one gets changed (I think this is an explainable way of dealing
with a selection whose widget states are different: if you've got three
items selected whose communications states are "unread", "unread", and
"needs reply", and you click on one of the "unreads", both "unreads"
advance to "read"'; clicking the same widget again would advance both
"reads" to "needs reply", and clicking a third time would advance all
three to "unread" (since they'd all be "needs reply" when that third
If you intend it to work one of these ways, great (it works the first
way now, and could be made to work the other way pretty easily). If you
want it to work a different way, can you please give a few examples of
how multiple selection and clicking in widgets interact to get the
behavior you want?
Mimi Yin wrote:
> Here are answers to questions from last week's Design Session,
> reviewing the Dashboard Spec.
> There are 4 questions that actually need to be answered by Engineering.
> #s 3,12,14,15
> I've separated design questions from implementation-related questions
> by tagging design questions with DQ.
> The answers on this page are being incorporated into the Spec by
> Sheila right now.
> Thx, Mimi :o)
> On Jun 16, 2006, at 12:05 PM, Priscilla Chung wrote:
>> Notes from the design session:
>> Mimi Yin wrote:
>>> We're going to walk through the Dashboard Spec tomorrow.
>>> This session is primarily to provide Engineering with an opportunity
>>> to ask questions about the 0.7 Dashboard Spec and for Engineering
>>> and Design to engage in a conversation to figure out the best way to
>>> phase features in the schedule.
>>> + Capture high-level questions about the Spec (10 minutes)
>>> + Review the Spec, capturing questions along the way (30 minutes)
>>> + Discussion questions, capture questions that need further
>>> discussion (30 minutes)
>>> + Summarize discussions with Phasing options (15 minutes)
>>> + Next actions (5 minutes)
>>> As usual, the meeting is open to everyone. However, if you plan on
>>> actively participating in the discussion, please be sure to have
>>> read through the spec beforehand:
>>> Mimi :o)
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>> Open Source Applications Foundation "Design" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design