[Design][Cosmo][Proposal] Subscribe/download .ics 'teaser'
twl at osafoundation.org
Tue Dec 12 14:04:56 PST 2006
Comments in line.
On Dec 12, 2006, at 12:58 PM, Brian Moseley wrote:
> On 12/12/06, Priscilla Chung <priscilla at osafoundation.org> wrote:
>> This is because you had proposed displaying more URLs:
> the collection details mockup i've seen had 3 or 4 urls in it already,
> and i don't see any difference adding a couple more. i certainly don't
> think it's warranted to replace those with a menu. one can't easily
> copy urls out of a menu to paste them into an email message or browser
> location menu or calendar application or feed reader subscription
> dialog box.
Since there is no mockup of a menu driven collection details, it's
hard to visualize this. One way of solving the copy/paste problem
is to make it so that changing the menu selection updates a text area
that actually has the URL in copyable form.
I think that the menu should include some number of applications in
an end user friendly form, e.g. Chandler,iCal 2.x, iCal 3.x, Sunbird,
Evolution. I also would like to see the menu have another section,
called "other clients". That section would include dav, atom, morse
code, webcal, and icalendar download. Again. selecting the menu
option would switch a text area and present the URL text in copyable
I believe that this would allow us to simultaneously provide
something that end users are likely to be able to decode, while also
providing for advanced users, debugging, and users of unforeseen
>> Originally 0.6 is really to just support Chandler, iCal and feed
> i don't recall any strict definitions of 0.6 one way or the other.
I don't think that there is a strict definition of what the supported
apps for 0.6 are. My own mental list includes all the apps that
Cosmo can talk to today: Chandler, iCal 2.x, Sunbird, Evolution, and
general icalendar apps.
>> I don't believe users besides
>> people who work in the calendaring software would understand the
>> between webcal and caldav. It's going to be confusing enough to
>> say if you
>> are running iCal on Leopard, go here, if you are running an older
>> version of
>> iCal go here. Most people, including myself would just be confused
>> if you
>> use those terms.
> well, tough. they are going to have to learn, and so are all of us.
> every calendar application we deal with is eventually going to support
> both mechanisms. it wouldn't surprise me if gdata started popping up
> in desktop apps in the next year as well.
> think about pop3 and imap. they've both been supported in every mail
> application for 10 years. people by and large have learned the
> difference. and for whatever reason, pop3 still hasn't gone away.
No, it's not tough. At least not on the end users. Part of what
OSAF is trying to do is to make highly usable software for ordinary
people. POP3 and IMAP might still be around, but the setup is a
disaster, and I certainly don't regard that as a situation to be
emulated. I, and many other people have wasted huge amounts of time
fooling with or helping other people fool with the settings for
mail. I don't even want to think of how many person decades of time
the designers of those protocols and the corresponding clients have
wasted because they couldn't be bothered to try to make something
that was decently easy to set up. The people that it's tough for is
*us*, the designers and the engineers, because we're going to have to
spend time time to think about these sorts of problems and find ways
to ease the pain. It means we might have to try/build 3 or 4 or 10
designs in order to get it right. And if that's what it takes,
that's what we're going to do.
More information about the Design