Ian Hickson wrote: > If the command is something simple like adding an event to a > calendar, the > ideal UI doesn't involve the user doing anything in the way of giving > credentials -- or indeed anything else -- to anyone. Just a click "add > this event to my calendar" or some such. We still need to know who the > user is.
I gather this means you're assuming the third party web page is coded to only add events to calendars maintained by a single web site. I can see where this is an attractive design for a company that hosts calendars, but may not be so appealing to others. In a better design, the third party web page would accept a reference to the calendar to be updated. This reference could then include the necessary authorization token. From a UI perspective, the user might have a bookmark for their calendar. To add an event to their calendar, the user would drag and drop this bookmark onto the calendar update widget provided by the third party web page. By supporting a common protocol, perhaps something like AtomPub, multiple web sites could then offer calendar services compatible with the third party web page. --Tyler
