• Questions about the design are marked as DQ
• All other questions are implementation questions.

1. DQ Is the Dashboard dependent on having a functional Email client?

No. As per the target user discussion, we are targetting users who already cobble together task management and calendaring systems outside of their Email client. The Dashboard and Triage workflows still apply to their needs.

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.

3. Is multi-selecting and dragging and dropping in the table hard?

• TBD by Engineering.

4. Can we get rid of what didn't make it into Alpha2?

• Assigned to Sheila.

5. What are we doing for Search?

• Will be spec'd out in a Search spec.

6. DQ Why is the Dashboard going to show up as a table in the Calendar?

Short answer: Because the Dashboard in the Calendar is where you process and manage invitations you send and receive, which is better supported by a table view.

The long answer can be found on the list here:

• http://lists.osafoundation.org/pipermail/design/2006-June/004818.html
• http://lists.osafoundation.org/pipermail/design/2006-May/004754.html

7. Is 'Keep out of My Items" going to be replaced by 'Keep out of the Dashboard'?

No. A write-up is coming soon to the design list. 'Keep out of My Items" will be replaced by 'Include events in my free-busy report'.

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)

9. DQ Aren't the communications status icon states confusing? Aren't there too many of them?

Short answer: No, with the ability to share email, it is more confusing for users to not be able to discern between states at all. Furthermore, only users sharing email will see so many states. Also keep in mind that there are only really a handful of base states (10). Everything else is derivative: Neither In nor Out, In, Out, Update-ness, Draft-ness, Queued-ness, Error, Unread, Read, Needs reply.

High level answer: OpenDesignProcessRulesOfEngagement

10. DQ Should we show users the communication status states at all?

See above.

11. DQ How much UI real estate should we allot for communication the communication status states?

We are already allotting 2 out of 7 columns. Unless someone can make a case for getting rid of some of the other columns: Task-ness, Reminder status, Date, Triage status, this is all we can afford for now.

12. How do we distinguish between the communication status states under the hood?

TBD by Engineering.

13. DQ Shouldn't we separate NEW items from NOW items in the Dashboard?

See old thread on design list, the last part of this email addresses this issue: http://lists.osafoundation.org/pipermail/design/2006-May/004758.html

Additional support for keeping NEW as apart of NOW coming soon to the design list.

14. Is the 'Change Triage status and then manually Purge' workflow hard to implement?

TBD by Engineering.

15. Is the 'Edit item and then re-sort after user clicks away' workflow hard to implement?

TBD by Engineering.

16. Do Ticklers also wait for a manual 'Purge' to re-set Triage status to NOW?

No

17. DQ Isn't it confusing for users that sometimes re-sorting happens automatically and other times it doesn't?

Short answer: No. It's more important for the app to do the right thing in the right context, than for it to be consistent. Users understand things in terms of context, not architectural consistency.

High level answer: OpenDesignProcessRulesOfEngagement

18. Do Ticklers replace Alarms?

Ticklers are 1 flavor of Alarm.

19. Do Ticklers result in a pop-up like Alarms?

Yes.

20. Is there a difference in the UI between custom-date Ticklers and regular event Alarms?

• Yes, the Reminder column displays a Tickler icon for custom-date Ticklers.
• Clicking in the Reminder column activates a custom-date Tickler, not a regular event Alarm.

21. Can you edit the Date column?

Editing in the Date column should only work for:

• Items with custom-date Ticklers
• Items where the user has activated the custom-date Tickler in the Reminder column.
• Items that are on the Calendar

It depends, only if deleting in the Date column works. Otherwise, we're better off not supporting in-place editing in the Date column.

22. Can you delete the date from the Date column?

Ideally yes. Deleting the date from the Date column results in the following:

• If the user has activated the custom-date Tickler in the Reminder column, leave the Date column blank. It will serve as a reminder to the user that they still need to set a custom-date Tickler for that Item.
• If the user has stamped the Item to add it to their Calendar, leave the Date column blank. It will serve as a reminder to the user that they still need to set a date for that event Item.

Otherwise, the Date column should not be editable.

23. What does deleting the date from the Date column do?

See above.

24. DQ Can't we allow users to edit the Date column and disallow users to delete dates from the Date column?

No. That's confusing. It short-circuits the editing workflow in the middle of the workflow and doesn't give users clues as to how to accomplish their task.

If a user is trying to delete a custom-date Tickler, how will they know that in order to get rid of the custom-date Tickler, they have to de-activate the custom-date Tickler in the Reminder column?

Topics we still need to discuss:

• Sorting and Sections
• Overlays: http://lists.osafoundation.org/pipermail/design/2006-June/004818.html
• Clusters

-- MimiYin - 15 Jun 2006