Hi Travis,
Thanks for taking the time to review the proposal. See more in-line...
On Feb 13, 2008, at 3:07 PM, Travis Vachon wrote:
Hi Mimi
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.
I'd be pretty concerned about how confusing this would be for stand
alone users. That said, this would probably be Randy work and I
don't plan on blocking it, so I'm just -0.
Yea I have same concerns. This was simply the cheapest solution I
could think of. We could 'smarter' things like hook up the OOTB Hub
collection with the Desktop Dashboard collection, but that road feels
long and fraught with peril :)
We could also zap the user-defined collection under specific
circumstances: e.g. If an user doesn't do anything to the OOTB Hub
collection (edit items in it or create new items) then we zap it when
they set up their Hub account in Chandler Desktop.
I'm hoping that a nice big 'NEW COLLECTION' at the top will help
standalone users figure out how to get started.
+ 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
Sounds fine, though I remember vague worries from Jared about
security here, I'd rather do something along the lines of adding a
little bit of code and web ui that says "share this collection." In
the new security model this will just mean giving them a link to
the collection without a ticket, and we could add an option that
would make the client generate a ticket if they want to share read/
write.
We could:
+ Add an 'Invite...' link which would generate 2 tickets in the
'Collection Details / Sharing dialog.
+ I think we would also need to automatically generate 2 tickets if
the user invokes 'Invite' from the Desktop
I was looking for the cheapest solution possible. FWIW many if not
most Desktop users publish collections to the server, not to share
with others, but just to back it up for their own use. So I'm not
sure if this distinction between shared versus not shared is that
clear. Or if it is, we should offer it for the Desktop as well.
+ 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
I agree that this dialog is confusing. In particular I'd really
like to see the sharing instructions sanitized. Moving the save and
delete buttons around may or may not be trivial, so I'd want an
upper limit of maybe a couple hours spent on that, since I don't
see how they particularly enhance sharing.
The Save and Delete buttons simply confuse the dialog, which has a
lot going on in it already. Are the buttons hard to move generally
speaking, does porting to Dojo 1.0 improve the situation?
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
Again, moving these pieces may not be trivial (I suspect from
working in them last time that they aren't) so I really think we
should have strict time limits.
I had other ideas about adding a banner across the top of the UI. I
thought perhaps, this would be easier. So perhaps we should iterate
on the design based on what's easy, what's hard.
+ 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.)
This is basically along the same lines as (I), in that most of
these changes are focused on cleaning up the "get sharing
instructions/information" process.
I think perhaps a better idea would be to come up with a new dialog
that is specifically focused on giving users information about how
to share and subscribe to collections. This will let us really
emphasize the "sharing" idea in the web ui and leave us some room
for making the save/delete buttons a little prettier in the
collection info dialog. To minimize development time the dialog
should be pretty much the same in "ticket collection" and "regular
collection" mode, though minor things like number of ticketed links
and "share link" ui could of course be different. This will make
development faster and minimize the amount of futzing we need to do
with the current ui.
Pursuing this strategy would probably take 2-3 days of dev and
testing, while making all of the changes you suggest would probably
look more like a week at least.
Would we remove the subscribe and download stuff from the current
collection details dialog?
Do you have some ideas about how the sharing dialog might be invoked?
I'm concerned about adding more UI elements to the sidebar, but an
open to alternatives.
If creating a new dialog is much easier, could we just get rid of the
old dialog and create a new dialog along the lines of the mock-up?
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.
I have no idea how hard this would be, so I'd estimate 2 days at
least.
+ Making the Notes field Usable
- Remove 'Addressing' and 'Task' stamp from DV, give space over to
Notes field
This is probably 2 days of work and testing.
- (Optional) 4. Add 'Star' stamp to markup bar.
- (Optional) 5. Swap task stamp icon for start stamp in the table
column header.
I'm afraid I don't understand what the star stamp is doing here. If
it's literally just stamping something as a task it probably
wouldn't be too bad 2 days of work and testing.
You can think of it as replacing the task stamp with the star stamp.
So yes, it'd amount to the same thing as stamping an item as a task.
I was thinking the 'work' would be in adding the star button to the
mark-up bar at the top of the detail view.
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)
These bits should be mostly trivial, but all together will probably
be 1-2 days of work and testing. Depending on how complicated the
changes to the login and account confirmation page are it could
easily be an extra 1-2 days.
So all total we're looking at 2 weeks of work for this spruce up. I
think that devoting 2 weeks of work to a spruce up within the next
3-4 months sounds pretty reasonable and could possibly even be
broken up somewhat to make it even more palatable, with a couple
caveats:
- I'm -1 on doing any work on this before the dojo 1.0 work has
landed unless there is overwhelming opposition to that sentiment.
Is it even possible to do this work without finishing dojo 1.0 work?
I imagine it would be like working against yourself to do that.
- I'd like to get a couple of the new widgets into full scale
deployment before we start this work. We can theorize all we want
about what the pain points in the application will be once we've
deployed the widgets but we're bound to be surprised. I suspect at
least one of these items will seem less important and at least one
new task will seem much more important once we've gotten a couple
widgets deployed. Assuming the dojo 1.0 work does finish up in 4
weeks and adding 2 weeks to get a couple widgets into production
that puts this spruce-up work at the beginning of April. That
sounds just about right to me (spring cleaning!).
-Travis
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
