Design of Lookmarks

The following discusses how the user should interact with lookmarks and the design issues that arise.

What can you save with a lookmark?

• the state (including displays) of the sources (and all their inputs) that are visible in the current view.
• time
• camera state
• center of rotation

What doesn't a lookmark save?

• multiple views
• plots - though it would be nice to be able to save a lookmark of plots as well
• anything saved with the application state

These should be temporary limitations. I am guessing these will be feature requests in the future and the lookmark framework should not make it impossible or very hard to implement these in the future. If lookmarks are implemented on top of the state functionality, adding these in the future would be easy. Berk 16:20, 29 Jan 2007 (EST)

Creating a Lookmark:

• There will be a "Create Lookmark" wizard available from the menu just like custom filters. It will consist of a single page with a line widget for the lookmark's name followed by checkboxes (checked by default) for whether or not to save: the reader(s), camera properties, and time. A button at the bottom will create the lookmark (for the currently selected view), adding it to the toolbar.
  • Aside: Why allow the user to turn on/off saving time, camera, and reader? Consider the following use case. The user opens some data, manipulates the camera to find an area of interest, then wants to apply a set of operations but retain the current time, camera, and reader. The reason he can't use a custom filter is because he wants certain internal display properties of the lookmark's filters to be restored. When would the user want to save time? When he comes across something interesting in his data at an exact position, timestep, etc that he wants to save for later or export to a file to share with a colleague.
• There will also be a second way of creating a lookmark. Each view will have a lookmark button next to its frame-splitting icons that will display the Lookmark wizard described above. In thinking about ways for the lookmark wizard not to have to be displayed, here are some options:
  • Have the reader|camera|time options be located in the application settings so that pressing the lookmark button will simply create a lookmark based on what those values are set at. Con: may be too hidden if the user finds himself changing these options frequently.
  • Have a checkable drop-down menu next to each view's lookmark button that lists the reader|camera|time options. Con: Do we sync the state of this menu across all the views or not? Either way, its probably not going to be obvious to the user.

Invoking a Lookmark:

• All other sources in the view in which the lookmark is being displayed will be set invisible first
• A new entry in the pipeline browser will be displayed. Its label will be the name of the lookmark. It will be a collapseable/expandable entity denoted by a +/- sign in front (expanded initially) where its children are the readers and filters making up the lookmark. By making it collapseable, we provide a tool against potential cluttering of the pipeline browser after invoking several lookmarks. By grouping a lookmark's readers and filters under one root node, it becomes clear to the user which ones belong to the lookmark.

Adding a lookmark to the pipeline browser in this manner won't work. The pipeline browser shows pipeline relationships (source to sink). The only grouping allowed is the server the pipeline is on. Adding a lookmark grouping might work if the lookmark has no inputs. As soon as you add external inputs to the mix, the relationship graph may be impossible to decipher. For consistency, I think we should avoid using the pipeline browser to show anything but the pipeline relationships.

--Mark Richardson 15:05, 25 Jan 2007 (EST)

I concur with Mark, but for less technical reasons. Lookmarks simply capture and restore state. When the state is restored, it should be added to the GUI (e.g. the pipeline browser) just like any other means of creating state (such as doing it manually). Furthermore, just adding the lookmark to the pipeline browser without that grouping simplifies the GUI (such as making the following bullet a non-issue).

--Ken 17:53, 26 Jan 2007 (EST)

In case it matters, I agree with Ken and Mark :-) Berk 16:17, 29 Jan 2007 (EST)

• Turning on/off the visibility of a lookmark (via its eyeball icon) will turn on/off the visibility *only of its visible internal filters and readers*. The reason for doing this is to make it easy for a user to display in a new view a lookmark that already been invoked in a different one. The visibility of internal filters/readers can still be manually changed in the normal way.
• By allowing lookmarks (made up only of filters) to be applied to different datasets, we become susceptible to robustness issues. For example, what happens if a lookmark's filter is colored or thresholded by a variable that isn't in the new dataset? We need to gracefully detect which properties it was unable to resolve and prompt the user. Not sure how difficult this is going to be.

I am guessing very difficult. However, the user will get an error message and paraview should not crash. If we improve the error dialog some, this may not be a big issue. After seeing the error, the user can go and select another array to color by or threshold by. Berk 16:23, 29 Jan 2007 (EST)

Managing Lookmarks:

• Like custom filters, have a Lookmark Manager where you can import, export, and remove lookmarks
• Also be able to organize, annotate, ... ?

Differentiating between Lookmarks and Custom Filters:

When a lookmark is created, it will be displayed in the toolbar, in its own section, just like custom filters. But how will the user know/remember which grouping contains lookmarks and which custom filters? One possible solution is to have a lookmark's icon in the toolbar be a snapshot of the view from when it was created (like in ParaView 2). This has the added benefit of providing a visual cue before actually invoking the lookmark. Con: small size of icon won't reveal all that much detail; we lose control of the what the icons look like in the toolbar

Ideas for differentiating between Lookmarks that contain readers and those that don't:

• Icons of lookmarks with readers can have a "D" (for Data) overlayed in one of the icon's corners.
• Lookmarks that contain only filters get grouped in the custom filter toolbar.
• ???

Dealing with Multiple Views:

As a first pass, a lookmark can only be created of a single (the current) view.

Dealing with Multiple Inputs:

We eventually want to be able to create a lookmark with multiple readers or filters as inputs but as a first-pass we will only support one.

Miscellaneous:

• A right click on a lookmark's icon in the toolbar displays a menu with options to remove the lookmark, and perhaps a "Preview" option that displays a larger image of the icon (I think VolView has something similar)
• Provide an advanced option (maybe in the application settings) which, when set, displays lookmarks in a new view when they are invoked
• Provide a preview of the internal pipeline of a lookmark (similar to the one in the Input Editor)
• Lookmarks, like custom filters, from a previous ParaView session should automatically be loaded into the toolbar.

We should probably delay these features (with the exception of the last one) for now. Let's keep the implementation as simple as possible.

--Ken 17:53, 26 Jan 2007 (EST)