[Design] [Cosmo] Collection Browser?

[Priscilla Chung]

I'm trying to finalize copy on the application, where did we leave  
off on this? Here are the suggestions I've heard so far:

+ Database browser
+ Account browser
+ Items browser
+ ???

Account browser sounds fine to me. I feel like we're grasping at  
straws until users understand the 'Collection' term. We could always  
just use 'Account browser' for now and wait to hear dogfood feedback  
on this?

Thoughts?
-Priscilla


On Jan 3, 2007, at 3:30 PM, Brian Moseley wrote:

> On 1/3/07, Mimi Yin <mimi at osafoundation.org> wrote:
>
>> What sounds smells walks and talks like a Collection, but isn't
>> actually called a Collection? Any ideas out there?
>>
>> + Account Browser?
>> + ???
>
> database browser? :) ugh!
>
> let's review what you can do in the browser:
>
> 1) list the collections you own (plus, eventually, those you're
> subscribed to with a ticket and those to which you have been directly
> given access with an acl)
>
> 2) get a broad view of the contents of a collection, including:
>
>   * of interest to "file sharers": item name, size, last modified
> date (like a typical web server directory index or desktop file
> manager)
>
>   * of interest to "pim users"/casual collaborators: event summary,
> location, start and end dates
>
> 3) quickly delete an item (eventually a bunch of items at once)
>
> 4) get a detailed view of all of the information stored about a
> collection or item, including:
>
>   * basic properties according to item type (for an item: uid, size,
> media type, character encoding, language, creation time and last
> modification time on the server, creation time on the client; for a
> collection: uid, description, language, types of calendar items that
> can be stored in the collection, creation time and last modification
> time on the server)
>
>   * all of an item's attributes (some which may come from webdav
> properties, others which come from stamps, others shared from third
> party chandler parcels)
>
>   * for events, all of the database indexes containing the event info
> (primarily diagnostic)
>
>   * for events, an html/hcalendar representation of the event info as
> well as the original icalendar representation (primarily diagnostic)
>
> (there's actually more info than this in the database - the CB only
> really knows about the data that was in cosmo as of 0.4 or so.)
>
> 5)  see all the tickets for a collection or item, create a new ticket,
> and remove a ticket
>
> 6) dav and atom urls for a collection (and eventually pim, webcal,
> davmount, atom service, gdata, etc as well)
>
> some of this stuff is redundant with the list view we'll eventually
> have in the pim. some is primarily diagnostic in nature. some are
> important features that we don't have anywhere else in the ui (the
> ticket stuff, for example).
>
> by the time we have the list view in place, with the detail view
> supporting notes, events, tasks and message, i think that what's left
> of features #1-6 above is primarily a diagnostic tool used by server
> developers, power users, and CCs involved in a customer support
> incident.
>
> the only real exception is the ticket facilities. if we added a way in
> the pim to manage a collection's tickets - say a dialog - i would be
> comfortable marginalizing the browser even more than now and
> positioning it as a debugging tool.
>
> other features, like importing calendars and tasks from external apps,
> could also be hooked into from the pim.
>
> thoughts?
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design