Create the UI of Multi-Z view

[RFSH]

This issue is related to the UI changes required for #57

• [x] Create a POC of how the UI would look like.
• [x] Make sure the UI is ready to be merged (it shouldn't look like a POC anymore and it should be presentable.)
• [x] Remove the buttons that were added in POC above the carrousel (next, prev, search box are not needed)
• [x] Move the text that mentions the Z_Index of currently selected image to be center aligned below the main image. It should be closer to main image instead of the carrousel.
• [x] Experiment with how we should show the current page number, and the total number of images.
• [x] Work on the pagination controls.
  • [x] Previous and next buttons.
  • [x] Ideally we might want something that is responsive. Instead of showing a scrollbar, it should change the page size (and therefore the number of visible images) to be based on available space. I think this should only be a client-based solution. We should still continue getting the images using a constant page size. This requires more thought though. For now, just experiment whether you can add a logic that given the available space, it would change the page size
  • [x] (added to another issue as improvement) (not a priority) A control to jump to specific page:
    • Users type the zIndex that they want, we show it if it exists and then change the page so that is visible as well.
  • [x] ~(not a priority) A slider type control that would allow users to choose a specific Z_Index.~ (jump to z-index will be implemented instead)

[rastogi-bhavya]

Pagination Discussion:

1. The carousel (showing the z index previews) should adapt to the width of the browser.
2. When the width of the browser is being changed wait for a certain amount of time (eg 2 sec) before changing to size of the carousel (eg from 16 -> 8, when the size of the browser is shrinked)
3. When the size of the carousel is increased say from 8 -> 12, then 4 new previews would have to be loaded. How will the UI handle loading these new previews. One possible way to do this would be to create place holders (with a loading sign) for these new previews, until they are loaded.
4. When the next or previous button is clicked, how does the UI handle the fetching the new previews. It is similar to point 3.

UI discussion

1. Need to add SASS
2. Font should be 14px
3. Try to see if the preview looks good as a square or rectangle (i.e. the aspect ratio of the image is maintaned)
4. Try to center align the carousel when there are fewer previews to display, i.e. when on the last page there might be less than the carouselSize of preview available, in this case should we shrink the carousel and center align it?

[RFSH]

About the use of whitespace in carousel and position of next/previous buttons:

• next/previous buttons should
  • be displayed after/before the images in the same line.
  • stay in the same position while users change the page.
  • be disabled/enabled depending on the displayed data.
• If next button is enabled (there are more images in the next page), the space from previous button to first image, should be the same as the last image to the next button.
• If next button is disabled (there aren't any other images), we should left align the images. So the space from previous button to first image, is the same or less than the last image to the next button.
• Position of all the controls should be adjusted to fit the screen size when the container resizes.

Based on this, there should be a JS code to deal with how we want to position the prev/next button and images. Their position should be set on load and only change when the container resizes. For the same sort of tasks in Chaise we're using this library. This library would allow you to add callbacks that would be called when the size of a container changes.

The initial position should be center aligned with enough space between the buttons and images. The previous button should be disabled and Chaise would let OSD viewer know whether next button is enabled or not.

When the page changes we don't need to move the next/previous buttons. That's because changing the page would result in the same number of images, or less. We just have to position the images in between the buttons. If there are less images than the page size (which means the last page), we would disable the next button. The fact that images are left aligned and there is more space between the images and the next button should be OK and actually an indicator that this is the end of the list.

[rastogi-bhavya]

Need Clarification

• [ ] What should be the min-width of the carousel? i.e. after the width of the parent container is reduced to such an extent we will need to add scroll into the carousel.
• [x] How to handle extremely wide images in the preview? Eg the image has an aspect ratio of 3:1, and a single image ends up occupying the entire carousel, in this case should their be a scroll bar? - Try 2 approaches:
  1. Reduce the height as well so that the image can fit, if this is difficult try
  2. Dont maintain the aspect ratio of the image
• [ ] Is there a minimum number of images needed to be displayed in the carousel?
• [x] How should the previous & next button look? Should they have a border like the prev/next buttons on https://dev.rebuildingakidney.org/chaise/record/#2/Protocol:Protocol/RID=N-H9A2 - Not like this, use icons instead
• [x] For pagination the previous/next button are usually hidden when the user is on the first/last page respectively. Is this behavior acceptable or should I disable the button? Google hide the button, whereas github disables the button. - We will use a disabled button
• [x] If we go for disabling a button how should the disabled button look like? - Active - Blue, Disabled - Grey
• [x] Should the prev/next arrows have tooltips? - Yes

[rastogi-bhavya]

Responsive Carousel

W = width of the entire preview container minus the size of the arrows, i.e. width of the carousel

hc = 92px (height of the image inside the preview container) mc = margin of the container pc = padding of container

hi = height of the image wi = width of the image

function getPreviewCount (hc, wc, hi, wi)
    widthOfImageInContainer = wi/hc --------------------------- w1
    totalWidthOfSinglePreview = w1 + (2 * pc) + (2 * mc) ------ w2
    numberOfImagesThatCanFit = int(W/w2)

    return numberOfImagesThatCanFit

1. To calculate the width of the image inside the preview container, its original width is divided by height of the preview image (this is a fixed constant as the height of the carousel won't change).
2. After calcuting the width of the image in the container, the width of the preview conatiner is calculated by add a fixed value ((2 * pc) + (2 * mc) for proper spacing) to it.
3. Now the number of images that can be fit inside the carousel is calculated by dividing W by the width of a single preview container.

Since the count is an int, it means that numberOfImagesThatCanFit * totalWidthOfSinglePreview != W. Therefore the spacing between the images would have to be changed, i.e. the margin (left & right) would have to be increased to uniformly distribute them in the carousel.

Everytime the window will be resized the value of W will change and this function will be called again, to get the new value.

[RFSH]

I created a new branch in chaise with the same name as the branch that you created in osd viewer (multi-z) that includes the changes required to send the request for the multi-z support. I also had to push some changes to osd viewer to make this work. You now should do the osd viewer part of these changes. you can test it here:

https://dev.rebuildingakidney.org/~ashafaei/chaise/viewer/#2/Gene_Expression:Image/id=16-2GJM

For now I’m printing a lot of stuff to console to make sure everything is working properly. you should see a

updating the z-plane-list with the following data:

message that is being printed in the z-plane-list.js file in the updateList function. This is the function that chaise is calling to update the list on load as well as page change. You should work on the rest of changes in osd viewer to make sure the returned data is properly displayed. If I want to give you a list of actions that you should take (in order):

• [x] make sure the totalCount and mainImageZIndex are properly displayed. I’m updating those based on the data that chaise returns in the init function of zPlaneList
• [x] change the _calculatePageSize to properly calculate the number of images that would fit. For now just assume the size of thumbnail.
• [x] use the hasNext, hasPrevious, and size of the images array to properly show the controls. For example in this case if the page is supposed to fit 15 images, just make sure you’re showing 15 placeholder images (again don’t worry about showing proper thumbnail.)
• [x] make sure the page size is responsive. when the browser size changes, you should ask chaise (by calling _fetchList) to update the list based on how many images would fit.
• [x] make sure pagination is working properly (you can do next, previous, and the list is properly displayed)

We will do the proper thumbnail later. that would require more thought from me

[rastogi-bhavya]

Meeting discussion (5th Jan 2021) When the number of indexes to display are less than the calculated page size, align the indexes to the left in the z plane carousel.

[RFSH]

• [x] Disabled prev/next are not actually disabled and users can click on them.
• [x] You need to display the spinner on load as well.
• [x] If you're borrowing the same gif for spinner, let's change it to look exactly the same (a white box where the spinner in the center and has a "Loading..." text. The gif doesn't display properly when there's a non-white background.
• [x] List all the different scenarios of how the responsive design should handle (all the normal and corner cases). Then make sure it's properly handling them. We should most probably add this list to our regression tests when this feature is merged.
• [x] The highlighted image is not changing when the image is changed.

[RFSH]

With the current implementation, the z-plane container is not displayed on load and it takes a seconds for it to show up. This causes a slight shift in the page. We should try to avoid this. We could show the container as soon as the iframe loads if we know there is a z-plane list in advance.

[RFSH]

The first iteration of this has been implemented. Moving the remaining tasks to #66