[Design] [Sum] User model for relationship b/w Hub + Desktop

[Mimi Yin]

I'd like to step back from the problem at hand and attempt to frame  
this discussion in the context of a goal: Present users with a  
coherent mental model for publishing / subscribing / inviting others  
to share.

What's currently getting in the way of this?

1. The URL publishers give subscribers to subscribe to a share is  
different from the URL subscribers give themselves from the Hub UI.

2. The URL Chandler Desktop gives publishers to invite others to  
subscribe to a share is different from the URL publishers have access  
to in Chandler Hub. There are good reasons for doing this, but today,  
they're not immediately apparent to users and the user experience is  
confusing.

3. If I add a collection to my account on Chandler Hub, shouldn't  
that subscription show up in Chandler Desktop as well? and vice  
versa? Chandler Desktop and Chandler Hub easily get out of sync with  
one another and require a lot of foreknowledge and manual labor on  
the part of the user to get 'in sync'. This is fine in the context of  
Chandler Hub as web access for Casual Collaborators, but less okay  
for remote access scenarios.

4. How come when I edit items on Chandler Hub, the name that appears  
in the 'Edited by' byline is different from when I edit items on  
Chandler Desktop? Don't both know about me through my Hub account?

How can we start to work towards addressing these issues?

URLS
The first 2 issues can either be 'easily addressed' by tweaking the  
way URLs are presented to users in the Hub UI.

1. Give subscribers and publishers the pim + ticket URL(s)* in the  
Collection Details dialog in the Hub UI as a 'Use this to share with  
others'.

2a. Give subscribers and publishers the pim + ticket URL(s)* in the  
Collection Details dialog in the Hub UI as a 'Use this to share with  
others'.
+ The con of solution 2a is that the user sharing with themselves  
across multiple machines won't be subscribing to shares they  
published with authentication.
+ The pro of solution 2a is that it's consistent with the workflow  
you would experience if you instead got your URL directly from  
Chandler Desktop.

OR

2b. Give subscribers the pim + ticket URL(s)* and give publishers  
the /mc/ without ticket URL so that they can subscribe to the
+ The pro of solution 2b is that the user sharing with themselves  
across multiple machines always does so with authentication.
+ The con is that this introduces another 'subscribe' workflow to  
users and is inconsistent with the workflow you would experience if  
you instead got your URL directly from Chandler Desktop.

3. Provide separate URLs for subscribing from Apple iCal, Feed  
Reader, etc...

* For subscribers, we can give them the same pim + ticket URL they  
used to subscribe to the collection. (It would be nice to provide  
users who subscribed with View and Edit pim + ticket URL, the View- 
only URL as well.)

For publishers, we can either give them the 1st View-only and 1st  
View and Edit pim + ticket URLs available (which is what the Desktop  
does I believe). OR as bcm suggested, we can limit each collection to  
having only 1 of each kind of ticket.

Keeping Hub and Desktop in sync.
The 3rd issue is more complicated. It essentially involves keeping  
Chandler Desktop 'in sync' whatever that means with the Hub account.  
That means that collections I subscribe to in the Hub UI should show  
up automatically in Chandler Desktop (assuming I've entered my Hub  
account in Chandler) and vice versa. However, addressing this issue  
would solve the dilemma presented in options 2a and 2b above because  
if we could figure out a way to keep Chandler Desktop and Chandler  
Hub in sync, then we also have a way to keep users in sync across  
multiple machines.

Some options include:
1. Chandler Desktop pulls down 'subscriptions' from Chandler Hub.  
This would be a 1-way solution, meaning subscriptions added to Hub  
accounts would appear in Chandler, but subscriptions added directly  
to Chandler Desktop would *not* automatically appear on Chandler Hub.

(This might work out pretty nicely as it would make it a lot easier  
to subscribe to collections. All you'd have to do is click on a pim +  
ticket URL, view it in the Hub UI and click 'Add to my account' and  
when you synced in Chandler Desktop, the subscription would show up.  
No cutting and pasting of URLs and dialogs. This of course only works  
if you have a Hub account.)

2. It sounds like it would be a bunch more work to get Chandler  
Desktop to associate a pim + ticket URL with an account to turn this  
into a two-way street. (Morgen can elaborate on this.)

3. Store an .ini settings file on the server. (Morgen can elaborate  
on this.)

Keeping 'Edited by' in the byline consistent between Desktop and Hub
The last issue is also surprisingly complicated because there are  
several randomizing factors:

1. Desktop user may not have a Hub account.
2. Item in question may also be a message.
3. User may have multiple sharing accounts.
4. Item in question may belong to multiple collections that live in  
multiple sharing accounts.

3 and 4 are just so scary that I think we should punt on them for  
now. I can see how people may want to maintain different personas and  
therefore want different names to appear in the byline for different  
people subscribing to different collections that are published to  
different accounts. People already do this today with multiple IM  
logins and email addresses. However, it seems like trying to solve  
this problem elegantly would be over-reaching for 1.0, not to mention  
very complicated and we should instead focus on getting the simple  
case right: User has 1 Hub account.

That being said, what's the best way to do this?
+ Chandler Desktop could just inherit the First Name, Last Name  
values from the server.
+ If the Desktop user has no Hub account, then we just use the email  
address from the 1st email account in the accounts dialog.
+ If the item in question is a message and the user has an Hub  
account, then we display the FN/LN from the Hub account in the byline  
when it's static text and *only* display an email address when the  
user is about to send or update a message and they need to be able to  
choose which email address they want to use from the 'send as' pulldown.
+ If the item in question is a message and the user does *not* have  
an Hub account, then we display the email address in the byline like  
we do today.

Questions
1. Is what I have above accurate?
2. Are there relevant issues that are missing? Possible solutions  
that are missing?

Mimi







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070925/60f39f61/attachment.html