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