Sidebar View

This page is for discussing the design of the Sidebar View.

Background

There are a few different design documents that talk about the Sidebar.

0.1 Release Components

On the 0.1 Release Components page, there's a bullet point that mentions the sidebar:

• "Sidebar, shortcuts to let the user switch between parcel views"

Chandler Release 0.1

On the main web site, the Chandler Release 0.1 page says:

"For this release, we plan to have a draft of the API between the viewer parcels and other parts of the application, such as the sidebar and other surrounding UI (see the diagram)."

That page also has a nice UI sketch that shows the sidebar:

Vista Prototype

On the main web site, the Vista Prototype has a section about the Sidebar. It says:

"Vista contains an optional sidebar that presents a hierarchical list of available packages and views; you can click on a disclosure triangle associated with a package to show or hide its associated views. The views are listed in an order specified by the package, so the most important ones are usually listed first."

"Besides packages and views, the sidebar also contains a presence panel that displays the names and presence state of the users whose presence you have subscribed to. It uses the Jungle.Jabber infrastructure to send and receive presence information, which gives us the ability to communicate with users on differing instant messaging frameworks. If another user is running Vista, a disclosure triangle appears next to their entry; if clicked, it opens to display a list of links to views from that user's repository that are accessible to the requestor. Clicking on a link displays the contents of the appropriate remote view."

That page also has a screenshot of the Vista sidebar:

Design Questions

Question:

Will the Sidebar be a custom component, or will it itself just be view that displays view items? Has there been any discussion about the pros and cons of these two different approaches for implementing the Sidebar? (BrianDouglasSkinner - 26 Feb 2003)

Answer:

I believe the sidebar for the 0.1 release will provide views into data. Ultimately it may be much more, but to my knowledge it hasn't been spec'd out yet. (MitchellBaker - 11 Mar 2003)

Question:

What do you mean by 'custom component'? Do you have pros and cons in mind? (KatieCappsParlante - 04 Mar 2003)

Answer:

Here are the two different alternatives that came to mind when I was thinking about the sidebar:

• Custom Component,
  • By "Custom Component", I mean a Chandler UI widget that is specialy design and built to appear in one specific place in the UI. For example, a couple other custom components are the main menu, and Vista's web-browser style location bar.

• Just another view
  • Alternatively, the Sidebar could be a type of Chandler view designed for viewing Chandler items, just like the calendar Week View, or the generic Table View, or the e-mail Inbox View.

Here are the pros and cons that come to mind:

• "Custom Component"
  • Pros
    • Might be easier to design and build, because you can ignore all the issues that could come up in trying to make a more "general purpose" view.
    • Might have a better UI, because you can more easily custom tune the UI for the one specific role that the widget is meant to fill.
  • Cons
    • Sidebar API. The Chandler Release 0.1 page talks about drafting an API for communication between the sidebar and data views. And the UI sketch also shows this API. Does the Sidebar really need it's own API? When a user clicked on an icon in the sidebar, that API would be used to tell Chandler what view to display in another pane of the window. But isn't that already functionality that needs in some other API? When a user selects an item in a table view (like the email Inbox), that view has to somehow tell Chandler what view to display in a detail pane.
    • User can't publish their sidebar to share it with other users.

• Just another view
  • Pros
    • Might be easier to design and build, because it's just another view, and doesn't require developers to think about it as a special case.
    • Might have a better UI, because it behaves just like other views, and therefore just like the user expects it to.
    • Might be less buggy, because it re-uses standard view features and view code, so it doesn't introduce it's own new bugs.
    • Might be more feature rich, because users can do with it any of the standard things they can do with any other view (publish it, hide it, resize it, open it in it's own window, write a custom query to populate it, etc.)
  • Cons
    • Might be far harder to design and build, because of all the feature-richness.
    • Introduces new dependencies, and maybe all sorts of new corner-cases.
    • Requires Chandler views to be just another type of Chandler item.

(BrianDouglasSkinner - 14 Mar 2003)

Contributors

• BrianDouglasSkinner - 14 Mar 2003