Hi Mimi, I do understand that Chandler will allow for automatic triaging and filing rules for InBox email. However, the current design of Dashboard does not seem to allow the user to take advantage of this folder system during the actual triage process. The model Ive tried to describe using the pull down folder tree window was mainly to allow users to be able to see triage summaries of each folder and also to be able to quickly zero in on one part of the tree at a time during triage process should the user wish to do so.
Perhaps the reason many people dont create rules when they may actually benefit from this is because they dont have the time to learn how, and in fact, many consumers may not even know that this feature is even available due to suboptimal user designs in some of the currently used PIMs. Furthermore, a basic general email InBox may be satisfactory for a novice who begins with basic email needs. However, the application needs to be able to grow with the user as their needs may also grow, and it can grow rather suddenly, for example, as soon as they begin to subscribe to any high volume list like [EMAIL PROTECTED] Also, Chandler needs to be able to adjust to all types of email users including power users. As I had mentioned recently, I think it would be well received if we made ample use of the I icon system on top right corner of many if not all Chandler screens similar to what Palm did with some of their Treo 650 screens. Clicking the I would provide further information on the screen being displayed and relevant tips and shortcuts. Once the user learns all the features of the screen after repeated use, they can then select remove this button from this window. If for any reason they need to access the I button again, the user might be advised to choose Help -> Help about this screen. Im going to discuss further the creation and management of email folder tree in a separate thread next as this may involve a lot of explanation in itself and I dont want this email to get too long than it already is. However, I will mention here some comments regarding the current layout of Dashboard that you provided a link for. (BTW, thanks again for the links, especially in PDF format as I dont have PPT and I would encourage you to continue to cite links to other aspects of Chandler that you may be discussing as some of us on this list, like myself, may not have the time to go over the latest wiki diagrams regularly on our own). It seems the current three frame (actually two + one sidebar) layout presented in your PDF link is actually a variation of a model that I also supported in the past for Chandler sub-applications a couple of years ago. I think I had done an email back then discussing how easy it was to look up addresses in the original two-frame Palm Desktop Addressbook app where there was a list of addresses provided on the left frame and the contact details of the selected contact provided on the right frame. Additionally, one could choose to display different categories of Addressbook contact lists using pull down category list on top of the left hand panel as per the original Palm Desktop. The current Dashboard layout seems to resemble this layout with the addition of a third frame (a sidebar) to depict collections that a selected item on the list frame may be a member of. This type of layout I think works very well for looking up things within Chandlers sub-applications. Hence, it may be well suited for Addressbook, Memo, ToDo, and email subapps. However, its not the best environment if your main purpose is not just to look up an item but to actually do something with it such as the case with the Dashboard subapp. A two or three frame model such as the one I discussed recently is probably a more user friendly interface to start from for Dashboard since email, Memo / ToDo, (and in future possibly OOo files) are all kept within their own frames and this presents a more intuitive way to stamp items into different Kinds by quickly dragging and dropping an item from one frame to another as required. Furthermore, it also keeps email from drowning out roughly captured memos of users thoughts so that the latter can be easily located when needed later for composition into larger pieces in the form of an email message or, in the future, perhaps a Writer document. Another issue I see with the current layout of Dashboard is whether a sidebar is really the best approach to depicting collections in this window. <aside> BTW, these collections depicted on the sidebar of Dashboard as it currently stands appear to be very similar to what I might be considered as specific branches within a possible future Cactus / Tree subapplication that I discussed previously on this list except that the Cactus branch also depicts triage status (or due dates) of each item on the branch with a time axis overlay). </aside> Given that the majority of PIM items that will be passed through Chandlers triage flow will likely be unattached to any other items in Chandler, I wonder if reserving screen space for a sidebar just for showing collections is the best approach for Dashboard. An alternative model that may be more appropriate may be to use Tabs for this purpose. To demonstrate this, Im going to refer again to a three frame model for Dashboard I had discussed previously with Frame 1 for email InBox list view, Frame 2 for Memos (including memos with ToDo lists), and Frame 3 for OOo documents. (The latter frame being a possible future extension of Chandler as previously discussed). _________________________________________________ I frame 1 I I I I I I I 2 I I I I I I I I I I I I_______________I I I I I I 3 I I I I I I I I I I I_______________________________I_______________I When the user selects a specific email (by single clicking it in the Frame 1 list) then the frame could automatically become a tabbed frame if certain conditions are met. Firstly, if the email belongs to an existing thread, then a tab would be shown within Frame 1 labeled Thread. Clicking this tab could show only the selected email and the prior messages in the same thread of the email topic. Secondly, if the email has previously been classified (i.e. cactussed) by the user into a collection of Chandler items, then another tab could be shown as well when this email is selected on the list view of Frame 1. This tab might be labeled Links or Collection or Cactus for example. Clicking on this tab would then show the selected email message in the context of the user defined collection that the email belongs to. (In future, this tab might essentially be for depiction of the branch of a Cactus / Tree / Scrapbook subapplication that the selected item belongs to and depicted in 3-D fashion showing triage status of each member of the collection as previously discussed.) Hence, in sum when an email is selected from the email InBox list in Frame 1, then one may see the frame change to one with three tabs within the frame: Tab 1 - the email list window itself Tab 2 - the email thread tab Tab 3 - the linked items tab Double clicking on the title bars of any of the linked items of the collection in Tab 3 could of course open up the linked item into a separate smaller window above Dashboard. Similar tabbed approach could be used also when the user selects an item in Frames 2 & 3 of Dashboard. For example, when the user selects a Memo from Memo list in Frame 2, if the memo has been previously grouped into a collection by the user, then a Linked items tab could be included within Frame 2. Hence, one may then see the frame change to one with two tabs within the frame: Tab 1 - the memo list window Tab 2 - the linked items tab Ditto for handling of linked items in Frame 3 which in future which may possibly be used for triaging and stamping of OOo documents. The advantage of using tabs for depicting collections rather than a sidebar is that extra screen real estate is not wasted when not needed such as may be the case for the majority of routine items that are passed through daily in triage based PIM system. An additional advantage for the Dashboard window specifically is that the more crucial need for grouping of item kinds within separate windows (to allow for user friendly stamping processes) is not further complicated on screen by the addition of a sidebar which may not even be relevant for the majority of routine items encountered in day to day PIM activities. Regards, Selva --- Mimi Yin <[EMAIL PROTECTED]> wrote: > I'd like to clarify that the Dashboard design in no > way precludes > filing and organization. In fact those are very > important aspects of > the Chandler design as outlined in the Virtuality > presentation I > posted to the list two months ago: > > http://wiki.osafoundation.org/bin/view/Journal/ > VirtualityPresentationSlides > > Chandler will provide Tagging, Faceting and > Organizing affordances in > ADDITION to Triaging.** Triaging is seen as a first > step to get rid > of the 80% of material that you actually don't need > to Tag, Facet or > Organize at all, whereas currently, in order to > maintain a tidy > Inbox, many people feel the need to perform the > rather onerous task > of filing every single email they receive. > > Also, since all of our collections are rule based, > we absolutely > intend to allow users to auto-triage, auto-tag, > auto-facet and auto- > organize items with rules. However, given that the > majority of email > users never create a single rule, we must first and > foremost > restructure the information architecture of the > client itself to help > people manually manage their information more > efficiently. And that > is the motivation behind the Dashboard design. > > Mimi > > **Actually it's better to think of Triaging, > Tagging, Faceting and > Organizing as different phases of a single > affordance (as per the > Software that adapts to your changing data needs in > the "What does > Chandler mean to me" thread.) > > On Oct 1, 2005, at 11:42 AM, Seth Johnson wrote: > > > > > > > selva r wrote: > > > >> > >> Hence, with respect to a two or three frame model > for > >> Dashboard as I had recently suggested, I would > suggest > >> we allow for a mechanism to view the Email Inbox > frame > >> by folder in addition to a general email InBox > view. > >> Any one whos subscribed to a list like > >> [email protected] (- which averages 30 to 80 > >> emails per day- ) in the past would probably > >> appreciate what Im talking about. > >> > > > > > > . . . or who subscribes to hundreds of email > lists, many of which > > may be high volume . . . > > > > > > Seth > > > > -- > > > > RIAA is the RISK! Our NET is P2P! > > http://www.nyfairuse.org/action/ftc > > > > DRM is Theft! We are the Stakeholders! > > > > New Yorkers for Fair Use > > http://www.nyfairuse.org > > > > [CC] Counter-copyright: > http://realmeasures.dyndns.org/cc > > > > I reserve no rights restricting copying, > modification or > > distribution of this incidentally recorded > communication. > > Original authorship should be attributed > reasonably, but only so > > far as such an expectation might hold for usual > practice in > > ordinary social discourse to which one holds no > claim of > > exclusive rights. > > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > > > Open Source Applications Foundation "Design" > mailing list > > > http://lists.osafoundation.org/mailman/listinfo/design > > > > __________________________________________________________ Find your next car at http://autos.yahoo.ca _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
