[Design] Human Knowledge Database - Thinking Bigger

[Selva]

Hi Hamish,

Comments in line.
> 
> From: Hamish Harvey <david.harvey at bristol.ac.uk>
> Date: Mon, 12 Jan 2004 19:55:49 +0000
> To: design at osafoundation.org
> Subject: Re: [Design] Human Knowledge Database - Thinking Bigger

 Re the Palm
> Desktop: did it develop since I last saw it, when it was essentially a
> viewer for the data held on the palm? I didn't think it had any support
> for cross linking between databases, which carry over all the problems
> of unconnected data silos that our long standing fixation with
> applications has left us with everywhere.

I actually didn't mean to imply Palm Desktop 1997 edition had relational database functions but rather, I meant to try to understand what features made it so popular and to use these features as a *starting point* to develop a more modern PIM that would better meet the needs of today's users.  One example might be the systematic usage of Palm Desktop's two panel system throughout many of Chandler's sub-applications as I mentioned previously. Just to recap what I'm talking about, I'm refering to a left hand panel for listing items pertinant to the subapplication to make it easy to look up items, and a right hand panel displaying the details of the selected item. I already discussed how Palm Desktop's two panel view for Addressbook could be elaborated on by use of tabs behind the right hand contact details panel.  I'll try to extrapolate the same for the email interface even though we all know that Palm Desktop has never had email.  

As I mentioned previously, most email interfaces now have a three framed window as the main user interface.  I don't think this is the best way to design email interface.  If Hawkins wanted to, he could have easily created a three frame interface for Addressbook as well by adding a third panel for displaying the File Tree.  However, he simplified things to two panels by putting the File Tree in as a pull down menu embedded in the left hand Addressbook name list panel itself. Hence, users were able to intuitively switch between displaying different categories of contact lists easily without having to waste screen space by adding a third panel to display a File Tree.  I think the same should be done with the email interface also.  The usual left hand vertical frame for displaying the File Tree should be removed in the default view and instead, the email interface should just be two panels, one on top for the email list display, and one on bottom for the email text display.  The File Tree may be better included as an embedded pull down menu within the top email list display panel.  This would allow users to switch between different folders of email lists without wasting much screen space and complicating the picture with a third panel. This allows the two most important panels to be extended further horizontally to allow for easier readability and simplifying the overall appearance.

On a separate but related note, I indicated previously the top panel might include two tabs, one for regular email list view and another tab for showing the thread summary for the selected email message in the list view.  As well, I previously mentioned the possiblility of including tabs behind the bottom email text display panel as well so that Chandler could automatically call up relevent data in the other sub-applications that relate to the sender of the displayed email.  If such tabs are to be used on both email interface panels then the best way to do this may be abandon the usual format of displaying the two panels as frames within the same window, and instead, display them as completely separate panels that are simultaneously launched next to each other.  Otherwise, display of Tabs inside separate frames of a larger window would be kind of awkward.


> 
> Re relational databases: these work well when you have relatively large
> amounts of data, all of which fits into a relatively straightforward,
> relatively slow changing schema. Personal information is in a state of
> constant flux, as your activity, ideas, knowledge change. Something
> *much* more flexible is needed.

Yes, as David mentions, you're probably right in that a relational database may not be the best way to catalogue web clippings.  Of course, this also provides OSAF even more incentive for ripping out Writer from OpenOffice to mould it into an editable web clipping storage medium for Chandler.

Regards,
Selva