After going through the exercise to understand better how people will
use the web widgets (detailed in my other email), we are definitely
relying on web client users as part of the strategy. They will have to
sign up for accounts, subscribe to shares etc and we don't want this
to be a difficult or negative experience. We want to motivate them to
keep using Chandler and bring in others. This is why I was always
confused about the proposal to disable the UI (we aren't going to do).
That being said, I understand we have competing priorities so we need
to get this proposal scoped out and figure out how this work fits in
with all the other stuff on the table.
Mimi, does the proposal below reflect prioritization? Do we have to
address all of these or is there some subset that is more critical?
On Feb 12, 2008, at 2:31 PM, Mimi Yin wrote:
As I mentioned in my last email summarizing our web strategy
meetings, I am rethinking what role the current web UI plays in our
new web ecosystem. http://lists.osafoundation.org/pipermail/chandler-dev/2008-February/009606.html
We all agree that we should disable it. But I also think we can't
leave it as is. There are a handful of usability issues that need to
be addressed as soon as is practical. The rationale for addressing
these usability issues in particular is driven by marketing
strategy: To succeed, Chandler needs to be more viral.
Sharing is what makes Chandler viral. In order to be viral we need to:
1. Make it dead simple for Desktop users to get started with sharing.
2. Make it dead simple for collaborators to figure out how to
'subscribe' to shared collections with their application of choice.
3. Make the web UI attractive enough to standalone users that they
start to appreciate some of Chandler's unique offerings and to
convert some portion of standalone users to Desktop users.
Below is the proposal. It'd be good to get a high-level gut check:
+ Are the set problems addressed below the 'right' set of problems?
+ Are they hurdles you've encountered or watched others encounter?
+ Are there issues missing from this list that you think fall under
the umbrella of: Fix issues that hamper Chandler's ability to be
viral.
+ Is there anything that immediately raises a red flag?
Mimi
For mockups, see: http://chandlerproject.org/Notes/WebAppSpruceUpMockups
I. REDUCING # OF CONCEPTS DESKTOP USERS NEEDS TO UNDERSTAND TO START
SHARING
+ Remove OOTB Hub collection
- This is confusing Desktop users who have a different set of OOTB
collections and end up seeing the Hub OOTB collection when they set
up their Hub account on the Desktop. Grace thought that the OOTB Hub
collection contained all the stuff she was putting into her Chandler
Desktop Dashboard collection (which she never published) and
couldn't understand why she wasn't seeing items in the Dashboard
collection in her OOTB Hub collection and vice versa.
+ Automatically generate 2 tickets (View and Edit and View-only)
when users create new Hub collections - https://bugzilla.osafoundation.org/show_bug.cgi?id=10261
+ Fix Collection Details Dialog to distinguish between Subscribing
and Sharing (see mock-up 1)
- List out URLs for the all the different ways to subscribe + link
to instructions on wiki page (I will re-factor instructions Travis
pulled together)
- List out ticketed URLs for sharing with others
- Option to download
- Move 'Save' button for saving a name change to the bottom of the
dialog
- Move Delete button to bottom of the dialog
II. IMPROVEMENTS TO THE TICKETED VIEW (see mock-up 2)
+ Add 2 pixel divider underneath 'ADD TO MY ACCOUNT'
+ Move 'Subscribe' and Download options to the sidebar below
+ Add 'Share' option
+ Clicking on any of the links in the sidebar for subscribing /
sharing pop-sup a 'ticketed' version of the Collection Details Dialog
- Collection name is not editable
- URLs should be different for subscribing I imagine
- Only 1 ticketed URL, whichever one the user used to access the
ticketed view (Ideally, if you received a 'View and Edit' ticket,
you should have access to the 'View-only' ticket as well, but that's
a nice-to-have.)
III. MAKING WEB UI MORE USEFUL FOR STANDALONE USERS AND REMOTE
DESKTOP USERS (see mock-up 1)
+ Sort Triage Status by 'TriageStatusChangedDate' so that newly
created items appear at the top of the list, right now they
disappear to the bottom of the NOW items.
+ Making the Notes field Usable
- Remove 'Addressing' and 'Task' stamp from DV, give space over to
Notes field
- (Optional) 4. Add 'Star' stamp to markup bar.
- (Optional) 5. Swap task stamp icon for start stamp in the table
column header.
IV. SETTING EXPECTATIONS
I need to come up with explanatory text for the account confirmation
page and log-in page that highlights what you can do with the web
UI. (I need to think about this more.)
V. VISUAL CLEAN-UP + MARKETING
+ Change 'selected highlight color' to match link color: #0066ff
+ Move New collection Link to top of Sidebar
+ Move divider to top of Sidebar, make it 2 pixels (#CCCCCC)
+ Add 2 pixel divider under 'ADD TO MY ACCOUNT' in ticketed view
(#CCCCCC)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
