r11 - 19 Oct 2004 - 15:01:08 - DonnDenmanYou are here: OSAF >  Journal Web  > DetailViewFunctionalSpec20041019

Detail View Functional Design Notes

Here's my understanding of the UI Design of the Content Detail View.

Version 0.1 - for our first implementation scheduled for Chandler 0.4 release.

Introduction

This is a working document, but its immediate purpose is to put a stake in the ground defining exactly what we'll build in the initial implementation of the Content Detail View, scheduled for the Chandler 0.4 release. I've tried to trim the design down to the most critical parts for overall functionality, in a set of parts that I understand well, which are fairly representative of the diversity we expect in the final product. Components from the design that I don't understand or will take time to implement have been pushed off to the Open Issues area. Hopefully, there will be enough coverage of components so the overall structure of the implementation won't need to be changed when we flesh out specific features or add new elements to the design.

Meanwhile the UI Design for the final Canoga implementation continues to evolve. See the UI Design for some images of what this all should look like, and the latest UI thinking for Canoga.

Overview

The Content Detail View provides a place to display and edit the selected content item from the ContentView. As the user moves from item to item in the ContentView, the details are updated in the Detail View. The format for the Detail View supports attributes that are common to every ContentItem, but also attributes that are specific to particular kinds of ContentItems. The format remains relatively unchanged as different item kinds are selected. Some attributes are user editable, and some are display-only. In general, editable attributes are edited in place. E.g. there is a "Notes" area where the body of a Note appears, which is an EditText block. It also appears when viewing mail messages so you can add notes to a message.

The Detail View only shows the details from one ContentItem at a time. If there is more than one item selected in the ContentView, only the details of the first selected item is shown in the DetailView. I'll use the term SourceItem to refer to the currently selected item whose details are shown in the DetailView. When there is no selected ContentItem, the SourceItem is None, and most fields are empty, most controls are disabled. The user cannot enter data into the DetailView or make any changes there. When there is one SourceItem, most fields are filled with the data from that item, and controls are enabled. The UI Design specifies support for multiple selected items through the DetailView, but we're not going to support that for this initial implementation.

Blocks Comprising the Detail View

The Detail View is composed of several blocks, which are collected together into the DetailView block. I'm calling the child blocks of the DetailView component blocks (although they are not true components). The component blocks are designed to be useful on their own, or in conjunction with the other component blocks in the Detail View. An example is the LabelingArea, which provides a set of links to other items. The LabelingArea can be instantiated elsewhere to provide a way to add associations to a different sort of object. The component blocks may themselves have child blocks. The CoreArea is an example of a component block that could have child blocks that could also stand on their own, e.g. the Date Time block presents a time period for editing. This will probably be a handy block for many time-related activities.

Here are the components of the Detail View. Each block is either a Bar or an Area, with Bars extending across the width of the DetailView and having a fixed vertical size, and Areas being inset on the left and right side of the DetailView and allowing resizing.

  • MarkupBar - a set of buttons that make quick small changes to an item attribute
  • FromAndToArea - area that show original sender and recipients of the item
  • CoreArea - area where the kind-specific attributes of an item area accessed
  • StampedEmailArea - shows the original mail message that generated the item
  • NotesArea -area that displays notes associated with the item
  • MessagesArea - area that provides for interactive conversations
  • SharingBar - place to allow Sending/Sharing of the item
  • LabelingArea - place which shows all the collections which this item is a member

For each component block I have tried to consider these questions:

  • What name should we use to refer to this item?
  • What are it's component blocks?
  • Where does it get and store its data?
  • What are the default values for the data or user settings?
  • When is it enabled or disabled?
  • What are the required blocks needed to implement this component?
  • How does it interact with other components?
  • How does it behave when resizing?

Blocks Associated with the Detail View

There are several blocks that interact with the Detail View:
  • SummaryView aka ContentView. (I may have these terms wrong) This is the view of multiple items whose selection is fed into the DetailView.
  • ToolBar - a set of buttons that allow you to manipulate the Detail View as a whole.

Blocks Needed to Build this Implementation

Here's a rough collection of the all the different kinds of blocks I think we'll need in order to build this view:

  • Container Blocks
  • Sizers, both horizontal-only and two-way
  • Scroller and Scroll bar blocks
  • Static text - appears all over the place
  • Edit text w/ scroll bar - for NotesArea, etc
  • Edit text w/ auto-scroll - MessageEntry block
  • Buttons:
    • single-action iconic w/ caption (appearing in ToolBar)
    • toggle-action iconic w/ caption (appearing in ToolBar)
    • single-action iconic w/o caption (MarkupBar)
    • toggle-action iconic w/o caption (MarkupBar)
    • toggle-pulldown iconic w/o caption (MarkupBar). Note - will build this later! Use popupmenu for now.
    • ??? little triangles are part of the button
  • Iconic indicator flags (EmailFlags in MarkupBar)
  • Expandable static text area (MailToField)
  • DateTime block. See DateTime block of the CoreArea
  • PopupMenu with little icon on left (Recurrence, RemindMe blocks)
  • Separator
  • Labeled Frame

Open Issues

  • How does the SharingBar work? I think Sharing is the one area that I don't understand from a functional perspective.
  • When does the MessagesArea get updated? Are the messages somehow recorded as part of that item, for future reference?
  • When changing items in the DetailView, do the various components automatically resize? Is this a user preference?
  • Are all items always editable? Junk items are not, and the body of a Mail is not, right? Are there other cases where editing is disabled?
  • Non-editable items should still have the ability to select text and copy, right?

Assumptions, to be Validated

  • There is a way to make a new ContentItem that is external to the Detail View.
  • It's OK to NOT implement the TogglePulldownBlock from Mimi's design in this initial phase. For now, we'll use a regular PulldownBlock in which the individual items toggle when selected.

External Dependencies

  • There needs to be a UI Design done for the DateTime block. Need to know how the fields are selected and edited, how the adjustment arrows are used, etc. Also important is to note how internationalization and user preferences feed into this block's display. E.g. user preference for 24 hour time, long form of day-of-the-week, etc.
  • How does internationalization work on text-based items like the popup menus in Recurrence and RemindMe blocks?

TBD

  • Enabling/disabling rules for all the different parts.
  • Interaction with Menus

-- DonnDenman - 09 Jun 2004

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r11 < r10 < r9 < r8 < r7 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.