Install buttons in the extension manager are left aligned

[andrii-i]

Description

Install buttons in the extension manager are left aligned rather than right, which seems to be more common in JLab.

Reproduce

1. Open Extension Manager
2. Note how install buttons are aligned

Expected behavior

Install buttons in the extension manager are right-aligned.

Context

Operating System and version: MacOS 12.6.3
Browser and version: Chrome version 109.0.5414.87 (Official Build) (arm64)
JupyterLab version: head-of-master (WIP 4.0.0)

[JasonWeill]

They also don't look at all like buttons; perhaps we should replace them with icons or some other visual design that looks like a button

[GabrielaVives]

Yes I agree @JasonWeill , we could replace the "install" with a button. I suggest a design like this:

I tried using an icon as well, but it looked overloaded as there is already an icon on the left. Also, it seems that there is no standard icon to represent the "install" icon. Those I saw looked very much like a "download" action, I think it's best to keep to the button illustrated above!

As for the position, I suggest to put the button on the top-right, aligned (by the middle) with the title. This is a common position for actions in list items, plus it avoids creating a third line for the button.

[krassowski]

[...] As for the position, I suggest to put the button on the top-right, aligned (by the middle) with the title. This is a common position for actions in list items, plus it avoids creating a third line for the button.

It seems that a few design considerations are missing in the above proposal:

• accessibility of the buttons (are we meeting the size criteria? judging by the thin horizontal padding I am not sure)
• consistency of button location with installed extensions;
  these need:
  - "uninstall" button
  - "disable"/"enable" button
  - "update"
  - we are considering adding "about" in Create an "About" button to show more information in the extension manager #14098 to provide full version information and more
  if we change position of buttons everywhere, putting three or more buttons on top of each other will cause inflation of height of the boxes and or will force too small margins leading to accessibility problems
• space for other information such:
  • load time etc see the "details" in Show memory usage and load time in extension manager #13402
  • version which is currently in the exact place you propose to put buttons at (added in Display the version in the extension manager #14078).
• consistency with other buttons regarding style (I agree that current style is wrong but I would prefer to reuse something which feels more familiar - why not use the same style as in 3.x and earlier?)
• consideration to the width of the sidebar/responsivness: one of the "selling" points of the JupyterLab compared to Notebook experience is that it has multi-panel experience enabling simultaneous editing of multiple notebooks/scripts side-by-side; even on 4k screen I often find my sidebar collapsed to minimum width; in that case buttons on the side would make the name of extension and description overflow into multiple lines (let alone for users with small screens or on mobile)

[krassowski]

Also, in visual hierarchy unique elements (extension name/description) should be more pronounced than the repetitive actions. The strong blue button seems to stand out too much.

Also we were talking about bringing back the "from jupyter" indicator which was dropped for technical reason in 4.0 (for now) but is considered an important part of the UX (security tool really):

See #12866 (comment) and #12866 (comment).

Picture for update button and version:

So everyone wants to put things in top right corner :) I hope this gives you a more complete picture.

[andrii-i]

I agree with @krassowski's arguments for not putting the button / button bar on the same line with logo and other information about the extension. I'd say that in terms of positioning aligning the button / button bar to the right would be enough.

@krassowski's arguments for not showing background color on buttons all the time to not visually overload the layout make sense. At the same time we color-code action buttons in other places in JupyterLab (for example, in dialogs) and it makes UI easier to navigate. Maybe showing background color on hover only would be a good middle ground (also if we would use color at all, all buttons should be consistent in terms of shape, either all rectangular or all round)?

Dialog:

consistency with other buttons regarding style (I agree that current style is wrong but I would prefer to reuse something which feels more familiar - why not use the same style as in 3.x and earlier?)

@krassowski Below is a screen from version 3.2.9. "Install" button is positioned and looks to me the same as in head-of-master. Maybe 3.2.9 is not early enough? Could you please post a screenshot of style you have in mind?

[krassowski]

At the same time we color-code action buttons in other places in JupyterLab (for example, in dialogs) and it makes UI easier to navigate. Maybe showing background color on hover only would be a good middle ground (also if we would use color at all, all buttons should be consistent in terms of shape, either all rectangular or all round)?

So in dialog windows colour background is fine because it's not a repetitive button and user has to press one. In places where the buttons are repetitive and completely optional we mostly use an icon and/or a very subtle background colour (except for the large blue button for add in file browser). Another way to delineate a button would be by adding a thin border or inset shadow but I don't think we do that elsewhere?

Below is a screen from version 3.2.9. "Install" button is positioned and looks to me the same as in head-of-master. Maybe 3.2.9 is not early enough? Could you please post a screenshot of style you have in mind?

Right, I was wrong the styling was the same in 3.x - sorry.

[GabrielaVives]

@krassowski @andrii-i thanks for the update! I've continued the research on this topic with the information you gave me.

I have created a document illustrating the options you described. It is far from being complete, but it can be a good starting point to fuel discussions and iterations. These prototypes group solutions for this issue and #14098, and can help enhance #14078.

The explanations by item are below, everything is illustrated in this Figma prototype.

Each design has a large and condensed example. For state 2, there are 3 different options (A, B, C). All these options can be iterated on, as well as mixed together if we find it useful. I have intentionally prototyped the interactions with the info icon on a separate prototype.

The states

To my understanding, there are 2 different states to consider here:

• When a user wants to view and manage already installed extensions (state 1)
• When a user is in a discovery workflow, and extensions are not yet installed (state 2)
  The design considerations for both states must be consistent, however some pieces of information may appear differently in state 2, as they don't exist in state 1.

The title

I think the title should not be in blue but in black (dark grey ideally). Blue is used for links and buttons, here it seems like an unnecessary use of color.

The version (see this prototype for illustrations)

• Coud we have the version following the extension name? It would make more sense as it adds contextual information to the title
• To display further information about the version, I tried putting an "info" icon next to the version number. Then, I tried out different interactions:

1. Hover or clicking
2. Information displayed in the frame or out of the frame
3. Another option not investigated yet: have the frame expand, and see additional information below (as in see more/see less)

• I haven't investigated adding an "about" button yet, this could also be an option, and can work with 1, 2 or 3.

Disable and Uninstall buttons

• I agree that they are not the main information the user is looking for, there are several options on the prototype to make them obvious without over-crowding the panel.

Update button

• As there is not always an update available, I think it is important to have a button with 2 states: an enabled and a disabled state. Instead of having the button disappear when disabled.
• Putting this button to the bottom left seems like a good option to me, as it is close to the information it relates to: the title and the current version.

Button styling

• I haven't investigated other styles than those in the prototype yet

Further information to be displayed

• I haven't addressed Show memory usage and load time in extension manager #13402 yet, but it surely could be information displayed in the same way as the versions.
• We could investigate whether it would be best to merge all this information into one interaction/one display, or have them in 2 different interactions/displays.

How can I use a Figma prototype?

In case you are not used to viewing Figma wireframes and prototypes, here are a few tips:

• If the prototype has several pages
  You can navigate using your keyboard arrows, or using clickable elements on the prototype
  You can jump back to the start of the prototype using the R key
• If you click anywhere, all the interactive elements of the page (hover, clicks, etc) will be highlighted in light blue. This can help you know where to click and what interactions to try out.
• If the page is larger than your screen, you can move around using your mouse or trackpad
• You can resize the page in the Options drop down on the toolbar at the top right of your screen

[andrii-i]

@GabrielaVives thank you for prototype, it's always easier to discuss and implement things with a reference. Because it touches on more than 1 issue and to facilitate discussion it might be worth to also create a separate issue for this Extension Manager prototype and list/link all issues it touches on

[andrii-i]

Created #14205 that just aligns the Extension Manager buttonbar right as there is no consensus of other changes.

[GabrielaVives]

Created #14213 to discuss the topics above in one issue.