[Design] What's next for Chandler?

[Philippe Bossut]

Hi Mimi,

Great summary. I think I agree with most of this. I'm just commenting on 
some paragraphs.

Mimi Yin wrote:
> *1. FIX WHAT IS BROKEN*
> *
> *
> *There are some significant issues to revisit and work out around the 
> Addressing stamp and the Edit/Update workflow. In particular:*
> *DS* How do provide users with the ability to attach 'who-ness' to an 
> item. The Addressing stamp is our current hack, but it's overwhelming 
> email-ness discourages people from using it as such.
> *D* Sent/Received messages become drafts as soon as you edit them, 
> even if your edits are not intended for email updates. 
> *D* Do we need to further combine sharing notifications with edit/update?

I don't think we can address 'who-ness' without implementing Contacts so 
here's a case where "just" fixing what's broken requires significant new 
features implementation. IOW, it's broken because we are missing features.

On the draft issue, I feel that our whole model of "sendability" and 
"send/update" is way too complicated. I'd really like to hear from end 
users here and early adopters but my guess is that we'll have to 
simplify, simplify, simplify.

Fundamentally, an item is always sendable in Chandler wherever it comes 
from. The problem is that we use only 2 widgets to carry the sendability 
(a button in the toolbar) and the edit/history state (the byline in the 
DV). There's already a bug (bug 9213) that's hinting to having 2 widgets 
for "byline" and "send as". May be we should use the "byline" only to 
reflect who did what when (a sort of history tool) and "send as" as an 
equivalent to the email "from/reply-to" found in email clients. In that 
context, I feel that the toolbar button should only say "Send" and be 
enabled as soon as "send as" says "send as" instead of "from" (and let 
the user be able to change that state at will).

There's more to say on this I suppose but that's worthy of its own 
independent thread.

> *Cleaning up the end-user mental model around mine versus not-mine 
> collections*
> *D* We've had a number of requests to allow for individual items to be 
> 'excluded' from the Dashboard collection. This affects our 
> remove/delete mental model. There also bigger questions about how the 
> Dashboard collections is used, but I can imagine holding off on 
> tackling those issues until after 1.0.

May be making the "Appears in" widget editable would help here (being 
able to add/suppress "Dashboard" from the list). This is however a 
little bit "advanced". Note that it could also be a first foray into the 
"tagging" feature (on the cheap side).

> *Improve Usability Ramp: From the KEI test session, it's apparent that 
> there are some sharp corners to round out in order to ensure that the 
> first 10 minutes of using Chandler don't make people want to pull 
> their hair out.*
> *D* Guide users towards sending out sharing URLS as sharing invitations
> *S* Smooth out the 'Add collection to my account' workflow on Chandler 
> Server
> *D* Make migrating between versions *more* automatic
> *D* Warn new users when they're about to delete an item that belongs 
> in another user-defined collection
> *D* Improve quick entry text parsing
> *DS* Add calendar date picker and/or improve date parsing in DV 
> date/time fields

+1. Anything that makes the learning curve less steep is fair game. 
Right in line with "get more users" tenet.*


*
> *2. NEW FEATURES*
>
> *Oft-requested Dashboard Features*
> *DS* Auto-triage events to DONE when they pass in time
> *DS* Finer gradations for triage status
> *DS* A way to sort events in the Triage Table View by event start time

+1. Those could as well be considered as "Fix what's broken" category...

> *Laundry list of f**eature additions*
> *DS* Recognize links in the Notes field
> *DS* Month View
> *DS* Print
> *
> *
> ?? Do we need:
> *DS* Rich text editing
> *D* Multiple detail views
> *D *Clusters
> *DS* Tagging and/or Tagging with user-defined attributes
> *DS* Contacts
> *DS* Rule-based collections
> *D* View Selector

We really need to get the candid feedback of a couple of hundred users 
here. All of these features seem equally interesting/useful to me in a 
1.0 perspective. However, it's not like we're not going to release 
anything between now and a 1.0. If we all sign up on a "release more 
often" tenet, we should prioritize those features and work on them in 
prio order then ship them whenever they're ready in whichever timed 
release they get in. To prioritize though, we need user data (see first 
sentence in this paragraph).

Couple of ideas to get more user data faster:
- go see users and interview them, see them using the product and hear 
their requests
- allow users to vote on feature: there's a feature in Bugzilla allowing 
this, we should add records in Bugzilla for those features and encourage 
users to vote on them, may be allowing a max number of votes (say 3) so 
that they choose the really critical ones (again, all of them are 
interesting and it's tempting to go ahead and pick some right now but I 
think we should resist that urge).

Cheers,
- Philippe