Hi Davor,
Your comment unearths a lot of issues that have been long-buried, but
that we really should be thinking about as Preview approaches.
(Unfortunately it also creates more work for me!)
So a few things:
1. There was a LOT of work around creating a 'Hierarchy of Kinds' or
an 'Ontology of App areas' if you will. The 'Hierarchy of Kinds' was
our best guess at an all-encompassing framework for parcels. A way to
describe the 'information architecture-laws of physics' in Chandler.
The most succinct presentation of this work is in a series of slides
I prepared for the 2006 Information Architecture Summit, where we met
in Vancouver :o) http://wiki.osafoundation.org/Journal/
InfoArchSummitSlides
In a nutshell the App areas are defined around 'what the content
means to the user' as opposed to 'file type'. e.g.:
+ Communications (as opposed to Mail versus IRC versus IM versus SMS,
etc)
+ Tasks or Projects
+ Calendar, as in Scheduling
+ Resources (e.g. Documents: Stuff you would normally file in a
filing cabinet, in olden times that is)
+ Media (e.g. Snapshots, Music, Books, Blogs, Articles...as in
Leisure Stuff)
+ Directories (e.g. Personal address book, Product catalogs, Customer
directory, Company directory, Atlas type stuff...as in Records and
Profiles of real-word entities, aka people, companies, locations,
physical objects)
Some more half-baked proposals having to do with Chandler as a
general information management platform:
+ http://wiki.osafoundation.org/Journal/AttributeManager
+ http://wiki.osafoundation.org/Journal/ChandlerAsAPlatform
I clearly have a task ahead of me to compile a comprehensive archive
of this material.
2. As for Contacts specifically, that too has had a lot of wiki-pages
written and photoshop mock-ups done. As you know, Contacts support
was cut from Preview, so the proposals before were never really
worked out in detail.
Contacts Proposal
Write-up: http://wiki.osafoundation.org/Journal/ContactsFeaturesForBeta
Screenshot: http://wiki.osafoundation.org/pub/Journal/
ContactsFeaturesForBeta/Contacts_Mockups.pdf
Random Notes that are probably not worth reading:
http://wiki.osafoundation.org/Journal/CanContactsBeProcessingItemsToo
http://wiki.osafoundation.org/Journal/ContactsTheFourthDimension
http://wiki.osafoundation.org/Journal/ZeroDotSevenContactsDesign
http://wiki.osafoundation.org/Journal/FlickrSyncing
http://wiki.osafoundation.org/Journal/ExtensibilityForIRC
As you mention below, there are reasons to have Contacts as an App
area unto itself AND as a 'complementary pane' that appears in
addition to the Summary Pane for each collection. Meaning, each
collection would have it's own Address book that either:
+ Displays all contacts mentioned by items in that collection; OR
+ Hand-selected list of contacts.
Mimi :O)
On Jan 26, 2007, at 12:29 AM, Davor Cubranic wrote:
Katie Capps Parlante wrote:
I agree that we'll likely need to be adding addressbook (contacts,
*people!*) to the mix soon after Preview. Among the many reasons:
we'll need this core for others to build plugins -- we'll want a
common model for contacts/people.
Hear, hear!
Which reminds me: how are you planning to have the address book
displayed? It doesn't fit very well into the current UI division
into app areas and collections, or its data into what's displayed
in the summary view. I'm curious because similar questions might
come up with other plugins that add new information models to
Chandler, and so the address book could really set the bar for how
those are integrated into the UI. Thunderbird keeps its address
book in a window separate from that used to display accounts,
folders and emails, but in Chandler it could perfectly well use the
summary and detail views.
Davor
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
