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