hi, see more questions inline :o)
On Dec 11, 2006, at 2:57 PM, Brian Moseley wrote:
On 12/11/06, Mimi Yin <[EMAIL PROTECTED]> wrote:
1. What's the success / failure rate on this? Priscilla mentioned
she had
problems getting Newsreader to do the right thing on her Mac. If
it fails,
how do we fail elegantly?
to answer that, i'd have to understand what problem priscilla
encountered.
in general, the major issue is teaching the user what to do the first
time their browser tries to handle a response from the server that it
doesn't understand. here's what it would look like:
1) the user selects "subscribe with outlook" from the menu
2) the browser sends an ajax request to the server for the calendar in
"webcal" form
3) the server sends a text/calendar response to the browser
4) the browser doesn't know what to do with that media type and so it
pops up a dialog to the user saying "handle this with an external app?
if so, which one? if not, should i save this resource to disk?"
So, correct me if I'm wrong. We could get rid of the 'Download .ics'
option completely and just have a n 'Subscribe with calendar
application' option. If Subscribe fails because the user's calendar
app doesn't support webcal, they can at least download the calendar
to their desktop?
So then all we would need is:
Subscribe with: [Pulldown]
1. Chandler
2. Calendar application
3. Feed reader
1. Chandler --> Dialog with the appropriate URL with a link to a wiki
page for instructions (instructions launch in a separate tab/window)*
2. Calendar application -->
2A. On Mac: iCal launches to subscribe; OR
2B. On Windows / Linux, or if auto-launch fails on the Mac:
browser pops up a list of apps for the user to choose from.
2C. If nothing works, user is asked if they want to save the
calendar to the desktop.
3. Feed reader --> launches feed reader to subscribe
* After speaking with Priss, we decided that a dialog with a link to
a wiki help page would be easiest...
here's where we need to educate the user to tell the browser to use
outlook to handle the resource.
it's possible, as we talked about on irc last week, that we could have
javascript autoconfigure the browser to ical or outlook at some time
before this subscription process happens, but that's something we'd
need to research.
yes, i think that would be a nice-to-have in the future.
2. Will the right thing happen with Apple iCal from both Safari
and Firefox?
i believe so - i think os x is automatically set up so that when you
click a webcal url in any browser, the browser actually lets ical
request the url. we'd have to verify that.
So, in a world where subscribe happens automagically, reliably,
the workflow
would be something like...
1. Subscribe with Chandler
2. Subscribe with Apple iCal
3. Subscribe with feed reader
4. Download calendar and tasks*
looks right.
* I'm wondering if Export data to desktop is a tad too techie and
maybe
confusing because the CC isn't actually looking at their personal
calendar
and doesn't really think of Cosmo UI as their personal calendar app.
sounds fine.
1. --> Instructions for how to Subscribe with Chandler
2. --> Launches Apple iCal to subscribe;
{If user does not have iCal, pop-up: Apple iCal cannot be found. Try
importing the calendar and tasks to your calendar application by
downloading
to the desktop. [Cancel] [Okay]}
not sure if the pop-up is technically feasible. we'll have to do some
testing. probably the default behavior of the browser would be to say
"woah i don't know what webcal:// means".
okay, the workflow you described above sounds fine.
3. --> Launches feed reader to subscribe
4. --> Downloads .ics file to Desktop
If 2 or 3 fails...then we would need to pop-up the dialog with the
URLs...
i don't know if the browsers give us the appropriate hooks to do
pop-ups in this way.
2. --> User selects from a list of apps.
* If they select an app that support webcal, we auto-launch the
app and
subscribe.
* If they select an app that doesn't support webcal, we suggest
that they
download and import.
or, if they select an app that supports caldav, we cause that app to
be auto-launched.
okay
I think even if the browser is handling the workflow for
subscribe...we want to provide CC's with access to the URLs. That
means we would want to give them access to the same Collection
Details dialog that users can see when they're logged in.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
