[Design] Answers to Questions from Dashboard Spec Review

[Bryan Stearns]

Mimi,

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 
count?

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 
works, though.

- 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 
click came).

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?

...Bryan


Mimi Yin wrote:
> Here are answers to questions from last week's Design Session, 
> reviewing the Dashboard Spec.
> http://wiki.osafoundation.org/bin/view/Journal/DashboardSpecReviewQuestions 
>
>
> 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: 
>> http://wiki.osafoundation.org/bin/view/Journal/NotesDSDashboardZeroDotSeven 
>>
>>
>> -Priscilla
>>
>>
>> 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.
>>>
>>> Agenda:
>>> + 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:
>>>
>>> http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Dashboard-0.7.html 
>>>
>>>
>>> Thanks,
>>>
>>> Mimi :o)
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> 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