Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wf-details: display workflow size #321

Conversation

giuseppe-steduto
Copy link
Member

Closes #151

@giuseppe-steduto giuseppe-steduto force-pushed the size-in-workflow-details branch 4 times, most recently from cf303bc to e318e24 Compare May 9, 2023 08:21
@mdonadoni
Copy link
Member

There are some visual differences introduced by this PR.
In particular, the workflow size displayed on the main page has a different colour and size than before. Also, the three dots on the right side are always shown, instead of being visible only when hovering over the card.
Before:

After:

When the workflow is not in its final state (i.e. when the status is created/pending/queued/running), the button to refresh the workflow details shouldn't be visible.
Before:

After:

Another difference is that the "launcher label" is now present also in the main page for workflows that were launched from REANA UI.
Before:

After:

What do you think about this? I haven't checked the code yet, but do you think it makes sense to have a single WorkflowInfo component, or should we keep them separated as they were before? Maybe it makes more sense to only extract some common subparts (e.g. workflow size, workflow duration, ...)?

@giuseppe-steduto giuseppe-steduto force-pushed the size-in-workflow-details branch 2 times, most recently from 35050d0 to d033266 Compare May 11, 2023 09:29
@giuseppe-steduto
Copy link
Member Author

I think that using a single component would still be a nice solution, because the information and the way it is displayed is very similar. Maybe in the future we could also think about grouping some elements in subcomponents (workflow size, workflow duration, ...), but always keeping them inside the WorkflowInfo component.

I fixed the visual inconsistencies adding a small CSS class that contains the styles to be applied to the component only in the workflow-details page (e.g. display the launcher label). The only difference with the previous version that is still present is that, in the workflow-details page, the jupyter notebook icon is displayed under the workflow name (next to the workspace size), as is done inside the workflow-list page, and not next to the workflow name anymore (where the launcher label is), which I don't think is a problem.

What do you think?

@mdonadoni
Copy link
Member

Other than the change in position of the jupyter icon, there are still some issues when the workflow is running:
Before:

After:

There are also some small visual differences (e.g. sometimes different spacing between components), but I think most of them do not really matter.

I am not convinced this is the right approach. In particular, I find it quite hard to review all these changes and I fear that some issues might not be caught in time. From my point of view, I would probably prefer to:

  1. Keep it as it was before
  2. Instead of a "top-down" approach, start from the bottom-up by extracting shared components. This should make it easier to review the changes, as each subcomponent is independent from the others. After doing that, it should also be easier to merge the two WorkflowInfo into a single one, as they will share many parts already.

At the same time, I don't want to waste the work you have done in this PR. @audrium could you please also have a quick look and tells us what you think about this PR?

@mdonadoni
Copy link
Member

mdonadoni commented May 12, 2023

Regarding the placement of the workspace size, what do you think about placing it after Finished ...? /cc @audrium
In this way we avoid having a new mostly-empty line that contains only the workspace size, but I understand that this is difficult to achieve given that in the homepage it's in a different position!


@giuseppe-steduto
Copy link
Member Author

WRT the workspace size placement, I think that a nice option could be showing the workspace size under Finished..., both in the workflow-list and in the workflow-details page.
The result would be something like this:
image
image
I personally think it's visually better and more balanced. Since it's not directly related to displaying the workspace size in the workflow details page, maybe we can open a separate issue to discuss it.

@tiborsimko
Copy link
Member

Some comments on the icon position topic, with some further unrelated musings down the list about the information display in general:

  • It may be good to keep the same position of "icons" on the workflow list page and on the workflow detailed page. This would call for displaying them in the middle row in both places, for consistency. Otherwise the two lines would simply look inverted, as it were, on the detailed page when compared to the list page. (But read on!)
  • As for using middle row vs bottom row, the first has a merit of being backwards compatible, but I agree with Giuseppe that the second may look visually more balanced, so we could switch. (And read on also about icon styling!)
  • Currently, the Jupyter icon is clickable and brings the user to the notebook. The same for the GitHub/GitLab badge on the detailed page, that is clickable and brings the user to the location from where the workflow was launched. What about making the disk size information also clickable so that the users would be brought to the Workspace tab on the detailed page? (And here they would be able to see which files are big, which files expire soon, and in the future also ask for expiration extensions.)
  • What about trying to harmonise the style of the three icons, disk space size, jupyter, and GitLab location to have a common style? E.g. we could model everything after the GitHub badge style, i.e. oval badge and icon and a text. In the first box, the disk size would be displayed, in the second box the Jupyter icon with the word "notebook", and in the third box the gitlab logo with the GitLab text. In this way the users will have an easy visual way to see which elements are "actionable" (clickable).
  • When speaking of consistency between the list page and the detailed page, we display the GitLab icon only on the detailed page. If we do go for full consistency, we'd probably have to display it also on the list page. (But this may also lead people to "click away" from REANA, which may not be a good thing. Perhaps we could think of having an arrow "-> GitHub" to indicate that this click will lead them away.
  • One thing that we discussed some time in the past is that lhs shows "finished 3 hours ago", and rhs shows "finished in 13 seconds". I.e. the information about time is displayed both on the lhs ("when" things were run) and on the rhs ("how long" it took to run them). Not sure if we'd like to reposition things; mentioning this just for completeness. Having "finished 3 hours ago in 13 seconds" would be probably long and confusing. So better keep the current distinction, the lhs being for general things, and rhs for duration/steps only.
  • Finally, note that if someone go fullscreen, the workflow list page is not responsive; the body stays relatively narrow. We may perhaps want to amend that; this will leave more breathing space for the various icons we are putting into the displayed information.
  • BTW, when refactoring, I do like the suggestion of extracting common components and going progressively in the bottom-up style... But this can also come later for the more important changes. (As can do some of the above observations!)

@mdonadoni
Copy link
Member

mdonadoni commented May 16, 2023

I agree! Just a couple of comments:

When speaking of consistency between the list page and the detailed page, we display the GitLab icon only on the detailed page. If we do go for full consistency, we'd probably have to display it also on the list page.

We should also consider that, in the list page, these buttons would be nested inside another clickable object (the whole "workflow box") and I think we should try to avoid this as much as possible, as it might be confusing for users.

Finally, note that if someone go fullscreen, the workflow list page is not responsive; the body stays relatively narrow. We may perhaps want to amend that; this will leave more breathing space for the various icons we are putting into the displayed information.

I think we should keep the width of the workflow list the same, or at most widen it just a little bit. I feel that, by keeping the list narrow, all the details about a workflow are "together", while if we widen it then the details "get lost" in the page. Keeping the list narrow also forces us to show only the important details of a workflow. Note that the main content (that is excluding lateral menus and similar) of many websites is very narrow (e.g. Google search results, GitHub issues, Python docs, etc.).

@giuseppe-steduto
Copy link
Member Author

I like the new ideas!

I think we should keep the width of the workflow list the same, or at most widen it just a little bit.

I agree with Marco on this. However, at the moment, the width of the workflow list container is optimized for
the readability of flowing text (more info). We may want to widen this a little bit, since we're not really dealing with a column of free flowing text.

What about trying to harmonise the style of the three icons, disk space size, jupyter, and GitLab location to have a common style?

I tried to do that, and the result looks quite good to me:
image

However, I share with Marco the concern of the confusion that nesting multiple clickable buttons inside an already clickable object may cause in the user (even though it's a bit like the current behavior with the Jupyter Notebook icon). Maybe making the labels simpler and with a darker background on hover is a more suitable solution:
image

@giuseppe-steduto
Copy link
Member Author

giuseppe-steduto commented Sep 28, 2023

If we try to find a way to get rid of the "nested clickable elements" issue, a few alternative approaches arise:

  • Trying to be more creative, one may think about putting all the the labels on the side of the workflow box:
    image
    I see two problems with this approach, however. One of them is that the number of labels may become too large (think about the last workflow shown in the image, and imagine it is shared, therefore needing a "Shared" label) and the space for the labels would not be enough. The other one is that it would put together clickable elements (the notebook icon and the GitHub / GitLab one) with non-clickable elements (the workspace size and the "Shared" or "Read only" label for workflow sharing).
  • Starting from this, trying to solve these two problems led to a slightly different and more functional UI:
    image
    In this example, only the clickable elements are on the side, whereas the info about the workspace size and the workflow sharing is given in the additional row at the bottom. This would mean that there is always enough space for the clickable labels, and would make the UI more consistent.
  • With this in mind, I then tried to experiment a bit more: this is another version in which the lateral buttons are not very prominent, since they only have the icon without the caption (I placed them on the right, but on the left might work just as well):
    image
    This also is a more scalable solution, as I can easily picture multiple columns of these round icons / labels that point to different stuff. For example, something like this, maybe vertically centered:
    image

@giuseppe-steduto
Copy link
Member Author

The first options with the rectangular label inside the box is probably the best. To address the issue of the nested clickable elements, we could

  • simply make only the name of the workflow clickable :), even though this could degrade the usability of the interface
  • change the clickable area to include only the "upper" part of the box: a very simple yet elegant concept could be something like this:
    image

WDYT?

@mdonadoni
Copy link
Member

Superseded by #394

@mdonadoni mdonadoni closed this Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ui: display workflow size in details page
3 participants