Design of Lookmarks: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
No edit summary
Line 8: Line 8:


'''What doesn't a lookmark save?'''
'''What doesn't a lookmark save?'''
Note: these won't be a priority in the first-pass implementation of lookmark, but within the lookmark framework it will be possible to save them in the future.
* multiple views
* multiple views
* plots - though it would be nice to be able to save a lookmark of plots as well
* 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. [[User:Berk|Berk]] 16:20, 29 Jan 2007 (EST)


'''Creating a Lookmark:'''
'''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.
* 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 Lookmark Inspector (see "Managing Lookmarks").
** 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.
** 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:  
* 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:  
Line 23: Line 21:
'''Invoking a Lookmark:'''
'''Invoking a Lookmark:'''
* All other sources in the view in which the lookmark is being displayed will be set invisible first
* 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.
* As a first pass, if the lookmark includes readers, it will first try to open the data file at the path it was at when the lookmark was created. If the file(s) have since been moved or deleted, the user will be asked to select a new one from a browser. But in the future we want a way for a lookmark that includes readers to be applied to a different dataset than the one it was created with.  
:: 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.
* The sources that make up the lookmark are added to the pipeline browser just like when state is loaded manually
:: --[[User:Mark|Mark Richardson]] 15:05, 25 Jan 2007 (EST)
* 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? 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.  
::: 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).
::: --[[User:Kmorel|Ken]] 17:53, 26 Jan 2007 (EST)
::: In case it matters, I agree with Ken and Mark :-) [[User:Berk|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. One exception to this is filename. There should be a way of specifying whether the lookmark should ask for a new filename when invoked. If the file does not exist, the user should get an error and the lookmark creation should abort. [[User:Berk|Berk]] 16:23, 29 Jan 2007 (EST)


'''Managing Lookmarks:'''
'''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
A Lookmark Inspector (a dockable window) can be displayed (where? laid out vertically to the right of the render windows?). Here the user will be able to import, export, and remove lookmarks. Lookmarks can be organized hierarchically and each lookmark entry will include metadata about that lookmark (a thumbnail preview, name, comments, dataset(s) if any, time of creation(?), ...).


: I am definitely against this. After spending money and effort to get professionally designed icons, we shouldn't allow random icons to show up on the toolbar. No screenshot is going to look good when resized to 22x22 unless it is post-processed. However, using bigger screenshots in the lookmark manager would work. Maybe the toolbar is not the right place for the lookmarks. Maybe the lookmark manager should be a dockable window like other inspectors. The user can then leave it on the screen if they want to. [[User:Berk|Berk]]
'''Dealing with Filter-Only Lookmarks:'''


'''Ideas for differentiating between Lookmarks that contain readers and those that don't''':
As a first pass, lookmarks will save and restore any readers that existed at the time of creation. But we also want to be able to use a lookmark on a different dataset. Currently this is an unresolved issue. Since a lookmark is just a subset of state, how do you specify inputs?
* 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:'''
'''Dealing with Multiple Views:'''


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


'''Dealing with Multiple Inputs:'''
'''Dealing with Multiple Inputs:'''
Line 57: Line 41:
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.
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:'''
'''Miscellaneous:''' Most of these features will have to wait until 3.2 if they are implemented at all.
* 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)
* 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 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)
* 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.
* 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.
* A one-click mechanism for turning on/off the visibility in a view of a lookmark that has already been created (i.e. added to the pipeline browser).
:: --[[User:Kmorel|Ken]] 17:53, 26 Jan 2007 (EST)

Revision as of 16:56, 31 January 2007

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? Note: these won't be a priority in the first-pass implementation of lookmark, but within the lookmark framework it will be possible to save them in the future.

  • multiple views
  • plots - though it would be nice to be able to save a lookmark of plots as well

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 Lookmark Inspector (see "Managing Lookmarks").
    • 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
  • As a first pass, if the lookmark includes readers, it will first try to open the data file at the path it was at when the lookmark was created. If the file(s) have since been moved or deleted, the user will be asked to select a new one from a browser. But in the future we want a way for a lookmark that includes readers to be applied to a different dataset than the one it was created with.
  • The sources that make up the lookmark are added to the pipeline browser just like when state is loaded manually
  • 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? 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.

Managing Lookmarks:

A Lookmark Inspector (a dockable window) can be displayed (where? laid out vertically to the right of the render windows?). Here the user will be able to import, export, and remove lookmarks. Lookmarks can be organized hierarchically and each lookmark entry will include metadata about that lookmark (a thumbnail preview, name, comments, dataset(s) if any, time of creation(?), ...).

Dealing with Filter-Only Lookmarks:

As a first pass, lookmarks will save and restore any readers that existed at the time of creation. But we also want to be able to use a lookmark on a different dataset. Currently this is an unresolved issue. Since a lookmark is just a subset of state, how do you specify inputs?

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: Most of these features will have to wait until 3.2 if they are implemented at all.

  • 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.
  • A one-click mechanism for turning on/off the visibility in a view of a lookmark that has already been created (i.e. added to the pipeline browser).
Retrieved from "http://www.paraview.org/ParaView/index.php?title=Design_of_Lookmarks&oldid=3186"