Closed will-moore closed 6 years ago
This proposal has some investigations of hiding controls in viewer frames: The top-left viewer has minimal controls, the bottom-left one ONLY has the timestamp label hidden, with the frame made a few pixels thinner. Other 2 viewers on the right have the current size of frame (bit thicker).
The currently active frame is a darker blue and the inactive ones are a lighter shade.
The viewers on the left are sync'd in Group 1, which syncs Z & T. The viewers on the right are sync'd in Group 2 which syncs Z & T, View (zoom, pan & rotation) and Channels. Checking/unchecking the sync checkboxes in either of the viewers on the left (group 1) will update both viewers. E.g. checking "Channels" in the top-left viewer will mean that "Channels" will also become checked in the bottom-left viewer.
This uses quite a bit of the frame space for sync'ing controls. Do we need to keep more space free for other features? The "cog" button on the right hides & shows the canvas zoom controls.
Multiple viewers opened by double-clicking on thumbnails.... I suggest we shouldn't need to toggle into "multi-viewer mode" but can always open multiple viewers by double clicking. The exact details of how this proposal works are still to be worked out / discussed but 2 principles:
In the following sequence, we start with only a single viewer open. This behaves in all ways as the current iviewer does.
Now we double-click on another thumbnail. This opens that image in a new viewer, alongside the existing viewer.
(The same would also happen if we double-clicked on the currently-selected thumbnail - in that case we'd have both viewers showing the same image)
Now, we continue & click on another thumbnail with a single click. This does open a new viewer simply because the 2 existing viewers are active / pinned.
The newest viewer is "temporary", so that subsequent clicks on other thumbnails will continue to open images in this "temporary" / "unpinned" viewer:
If we want to keep that viewer open while browsing more images in a new viewer, we could "pin" that viewer open using the pin icon in the top-right of the frame. Then it would show the X like the other viewers and subsequent single clicks on thumbnails would open a new "temporary" window.
Also it's possible that starting to browse Z/T or adjust settings etc on the "temporary" viewer would cause it to become "pinned" and would stay open. Certainly drawing ROIs would cause the "temporary" viewer to become pinned open. We'd only ever need a single "temporary" viewer.
Minor/undecided details:
@will-moore: isn't there a certain redundancy in the lock group and the checkboxes?
I have never used icy before and I make the bold claim that there are others out there that haven't used it either and the implicit group meanings in terms of locking are not really transparent. In fact, I would have only guessed at best if you hadn't mentioned it. What if we use the group as just a mere group/set that denotes the images that are to be linked and the check boxes denote the actual action to synchronize.
With both behaviors applied there is not only redundancy but override hell/ui adjustment need. Because if I use group 1 for example and then uncheck z/t and view I have essentially no sync, right?
Discussed a few issues with @bramalingam and @pwalczysko. Quite a bit of discussion was inconclusive, but a few things came out...:
Petr said that Icy is quite well used in many places we've visited, so although we can't assume users will know about it (or ever used the sync feature) it certainly could be familiar to some. So, where there's not a reason for making things look different, we might as well make it look similar. I managed to find and understand the 'lock/sync' feature in Icy without instruction or docs so I think we should be able to make a feature that is equally usable.
Balaji wanted to be able to see the image name on the frame of each viewer. I'm not sure if I convinced him that the amount of space this would take up on screen might not be worth it?
Current iviewer behaviour is nice that even when Z & T are sync'd, you can change T, T syncs with the other image(s) but Z doesn't unless you actually change it. This means that when Z/T are combined into a single sync option (as in screenshots above) you can still have 2 images at different Z, moving through T together.
Balaji seemed in general agreement about not having a different "multi-viewer mode" and the proposed double-click behaviour for opening multiple viewers seemed reasonable.
There could be a use-case for keeping timestamp visible at the bottom of each frame, for comparing event times for several viewers. So let's not hide that as suggested above.
We should probably hard-code a fixed number of sync groups, e.g. 3 since there is a use-case for possibly 2 or 3 images with multiple viewers each (one per channel), so we'd need a group for each image set. @waxenegger You are right, if you uncheck z/t and c and view then you have no sync. Probably we start of with all of these checked, so the user wouldn't enter the "all unchecked" state unless deliberately. It's nice to be able to toggle all the checkboxes as you work, so there may be times when you temporarily do uncheck them all. No reason for us to prevent this.
Any additional comments @pwalczysko @bramalingam?
The sync checkboxes (Z/T, View & Channel) currently mean that this space can't really be used for any other toolbar button we might want to add in future. Although there might be space available if we use "View", "Z/T" and "Ch" labels, it's not very nice to push other buttons to the right when we switch to a sync group. I guess we could add a small number of buttons to the right (next to the 'show toolbar' cog button).
Another area that @bramalingam and I discussed yesterday was the similarity in layout & features between iviewer and figure. We agreed that we would always need 2 separate apps (even if iviewer implements a lot of figure features) but that you could exchange data / layout between the apps, possibly in the form of a figure JSON file (maybe modified/simplified). This might allow you to create a layout of viewers in iviewer, save it as a JSON file to be opened later in iviewer or figure.
we will definitely need two apps. discussing with people and listening to talks here, more ideas for figure... improving the communication between the 2 will be/is essential
Just a small point to add, we did discuss the options for layout management in the multi-viewer feature (similar to what we have in figure)
Instead of having a lock feature, I would still be inclined to following the multi select feature like figure to manage groups of images (if its possible). We already have groups in OMERO, adding another concept of groups in this windows could be potentially confusing.
@bramalingam will having the ability to move each window around not be enough? or were you thinking of having for example a "grid" control to make sure the windows are displayed in a grid.
@jburel - @bramalingam was referring to the "grid" button in OMERO.figure that lays out the viewers in a grid. Handy to arrange viewers so that they maximise available space and don't overlap etc.
@bramalingam I think we're not going to support multi-selection of viewers in iviewer like we do in figure since the workflow is a bit different. E.g. in iviewer you can "sync" 2 viewers for a longer period of time, moving back and forth between them (changing the selected image etc) without losing the "locking" of the images together. In figure where sync depends on selection, it is much more transient. Also, supporting "merge" of multiple selected images into the right panels (as we do in figure) is not supported in iviewer and would be pretty hard to do.
I like the idea of @will-moore https://github.com/openmicroscopy/design/issues/79#issuecomment-334186297 concerinng the concept of double-click for opening images in multi-view, I think leaving the syncing and buttons on the viewing pannels as they are now and implementing this concept would be a good idea. The only point I am not sure about in https://github.com/openmicroscopy/design/issues/79#issuecomment-334186297 is the "pinning" button.
This simplification gets rid of the "pinning" behaviour, which I find is very hard to discover for the user.
Since we have dealt with most issues here, moving remaining discussion to https://github.com/openmicroscopy/design/issues/81
Current prototype is @waxenegger's https://github.com/waxenegger/omero-iviewer/tree/mdi
Main concerns:
Current screenshot....
cc @jburel