On 3/15/07, Mimi Yin <[EMAIL PROTECTED]> wrote:
https://osaf.us/cosmo/browse/<USERNAME>
here you are browing your "home collection". this is the root collection for your account where all other collections and items are located. when chandler shares collections to your cosmo account, this is where they are created. dav users of course can create subcollections at any level of the hierarchy, but chandler and other morse code clients will typically just create them all in the home collection. i think we should consider making the home collection page in the account browser look somewhat different from other collection pages in order to make this distinction.
+ Not immediately clear that the Name=Cosmo, Type=Calendar was where my stuff was supposed to be, since he had lots of Notes and Tasks as well.
he had Notes and Tasks in the Cosmo collection or in the home collection? the "type" column is really only relevant for dav users, who will want to know if a collection can act as a caldav calendar collection or a carddav addressbook collection. we can certainly choose to communicate these facts in some other way. the type column is awkward for developers/troubleshooters too, because it doesn't really reflct the fact that items collections are typed with stamping, and that they can have multiple stamps. for instance, a collection could be stamped as a calendar collection and as an addressbook collection. we might consider using icons for each child item of a collection that shows what stamps the item has?
+ I would imagine though that for a Casual Collaborator who only sees Calendar data, Calendar would make more sense, than PIM.
are you talking about the pim links in the ticket list?
+ (Actually, his stuff was in Name=freebusy, Type=Folder) Why is freebusy a Folder? and not a Calendar? (That was rhetorical, just in case ;o)
this is an artifact of the partial freebusy support in chandler a4 that has subsequently been ripped out. a4 put all of the collections that would be available for freebusy queries into a "freebusy" subcollection to keep them distinct from the collections that would not participate in freebusy queries. if your CC uses a more modern build of chandler, all of his collections will be in the home collection. btw, "folder" is a legacy of the exclusive webdav orientation of early versions of cosmo. i thought it would be a more familiar term than "collection". i think it's enough to identify a collection member as a collection or an item, maybe further distinguish between content items and note items, and show the member's stamps. that would get me all of the "typing" information i want in the member list, and then i can click through to see the detail page for an individual member to get more info about it.
+ Not sure what it means to have Tickets on the <USERNAME> page. Maybe this page lists all of the tickets for all of the collections?
no, it lists whatever tickets were granted on the home collection itself. it's conceivable that somebody could want to give full access to their entire home collection to, say, their spouse. for developers/troubleshooters, it's handy to be able to inspect the full data set associated with a collection or item, even if some types of data won't be used in everyday usage, like tickets on a home collection. so maybe we have a basic collection view where we de-emphasize things like that but make them easily accessible for devs/troubleshooters.
https://osaf.us/cosmo/browse/<USERNAME>/freebusy + All 3 Collections he had were of Type=Calendar + When 'browsing' one of the Collections, it appeared that there were only 3 items...until I noticed that one was a Type=Folder called .chandler.
this is how alpha 4 and previous versions did sharing - they made a calendar collection to store all the icalendar representations of the items in a chandler collection, then they made a subcollection named .chandler inside the calendar collection to store all the cloudxml representations of the items. when chandler switches to morse code, it won't have to do any of that. when you look at a collection shared to cosmo with morse code, you'll just see one server item per client item, and there will be no .chandler subcollection.
+ Again, not sure whata it means to have Tickets on the freebusy page. But starting to get a clue ;o)
it doesn't mean anything in particular, other that any collection can have tickets granted on it.
https://osaf.us/cosmo/browse/<USERNAME>/freebusy/<COLLECTION NAME> + Okay need to get tickets. How do I construct a ticket? Which one works for Chandler Hub? Chandler Desktop? (I understand this is temporary? Eventually the [pim] ticket will work for Chandler Desktop as well?
not sure what you mean by "which one works for...". you just choose permissions and optionally a time after which the ticket expires. you understand that what is temporary? there are distinct dav, feed and pim links for each ticket that you've granted. so, if this is a collection shared by chandler, there will be two tickets (one read-only and one read-write), for a total of six links. these of course are distinct from the links at the top of the page that don't have tickets in them at all, which will cause cosmo to ask for your username and password if you click them. i understand that these distinctions are not obvious and welcome suggestions on how to better organize and explain these differences.
+ For now, [pim] doesn't work for Chandler Desktop, is that correct? I copied the Id and appended it to the end of the URL in the address bar. (Which turns out is wrong, because I was in /browse/ rather than /home/. :o)
right - you can't tell chandler to subscribe to the pim url in a4.
Are there any short-term, trivial fixes we can do to make this experience a little better? + Do we have any control over Type names? Could we have say a Type called Collection?
as i mentioned above, i don't think the type column is relevant anymore, and instead we need to describe how our data is modeled a little differently.
+ Do we need to segregate non-event items into a separate .chandler folder? Or can events and non-events appear together in the same list? Will Morse Code on Chandler Server solve this issue?
yes, morse code sharing solves that problem. a morse code- shared collection will have all member items listed together, and we should come up with a good way to display whether a member item is an event and/or a task and/or a message or none of the above.
+ Can we rename the links to the tickets? [Chandler] [DAV] [ Feeds] ?
btw, they aren't links "to tickets". in fact, only the pim link is a link "to" anything. * if you click the pim link, you get sent to the "ticket view" page for the collection; or if you right-click and copy the url, you can plug it into chandler's subscribe dialog. so this url serves double duty. * if you click the dav link, the browser will display a raw html web server style listing of the members of the collection. there's no benefit to doing that, since you can already browse the members of the collection in the account browser. this link is really only provided so that you can right click to copy it and then send it to somebody who wants to access your calendar with caldav. * if you click the feed link, the browser will download the collection feed and will do whatever the browser does with feeds; for ff2, this means asking you what feed reader you want to subscribe to the feed with. again, you could also right click to copy the url and send it to your friend who wants to subscribe to your collection feed. prior to the collection details dialog, these links were the only place to get these urls. now that we have the collection details dialog, we could get rid of these account browser links. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
