[Design][Cosmo][Proposal] Subscribe/download .ics 'teaser'

Ted Leung 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  
form.

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  
clients.

>
>> Originally 0.6 is really to just support Chandler, iCal and feed  
>> readers.
>
> 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  
>> difference
>> 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.

<soapbox>
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.
</soapbox>

Ted


More information about the Design mailing list