Comments in line.
On Dec 12, 2006, at 12:58 PM, Brian Moseley wrote:
On 12/12/06, Priscilla Chung <[EMAIL PROTECTED]> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
