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

Should we use space better in the setting editor UI? #14403

Closed
krassowski opened this issue Apr 18, 2023 · 8 comments · Fixed by #14441
Closed

Should we use space better in the setting editor UI? #14403

krassowski opened this issue Apr 18, 2023 · 8 comments · Fixed by #14441

Comments

@krassowski
Copy link
Member

Problem

PR #14074:

  • removes the descriptions for plugins
  • moves the button to new line (which is called a button bar even though there is only one, hard-coded button)

this does not appear to be an optimal use of space.

Proposed Solution

With PR #14704 in Proposed
image porposed-changes

I am also proposing to use a font in between the very strong one used in #14704 and the light one used previously. Finally I would propose slightly reducing the size of the "Restore to Defaults" button (not shown on the mockup).

Large-size proposed:

porposed-changes

Additional context

Previous font for context:

Screenshot from 2023-04-18 20-09-25

Thoughts?

@krassowski krassowski added enhancement status:Needs Triage Applied to new issues that need triage labels Apr 18, 2023
@krassowski krassowski changed the title Should we use better in the setting editor UI? Should we use space better in the setting editor UI? Apr 18, 2023
@andrii-i
Copy link
Contributor

I think these are reasonable suggestions, I would be happy to work on them and on other issues connected with Settings Editor after 4.0.0 RC release. At the same time, I would like this to not block #14074 (it's ready for merge 🟢).

There are also other issues with Settings Editor architecture like state duplication, component duplication, unnecessary re-renders (not filed yet).

@andrii-i
Copy link
Contributor

Some other relevant comments by @krassowski from #14074 for discussion:

Let's discuss whether we want to have button bar in #14403. on CSS-level, I would suggest to replace jp-Buttonbar with a more specific jp-SettingsForm-buttonbar to avoid introducing a new unscoped class which is only used in a single place (and for performance reasons) - but this can be done in a separate PR

800px is a very arbitrary threshold, putting the button in a bit weird place on larger screens:
Screenshot from 2023-04-18 20-30-16
Why not right-align it?

@krassowski
Copy link
Member Author

Given #14441 (comment) I went ahead and created a poll to get indication of user preferences: https://discourse.jupyter.org/t/ui-preferences-survey-please-vote-settings-editor-edition/19134 (I am not voting, and I am not giving indication of my preferences; my preferences are on both left and right side to balance things out).

@krassowski
Copy link
Member Author

krassowski commented Apr 26, 2023

I will take a readout a week from now, let's see if there is a reasonable number of votes (or maybe even some alternative suggestions in comments) by then.

@andrii-i
Copy link
Contributor

andrii-i commented Apr 26, 2023

@krassowski Please see my opinion on the topic in question.

Regarding a poll, what about other questions like max-width threshold and where plugin descriptions should be located? If we want to learn users opinions, going to Discourse might be a good idea but it would also be nice to understand more information about people who answer questions: demographics, occupation, education, how often and for which purposes they use JupyterLab, why they choose one option over another. Sample is not randomized and probably would not be big enough to be representative so just polling A/B option does not give us much information to continue our discussion or to present to council before calling a binding vote.

@krassowski
Copy link
Member Author

If you want to do this survey better, please go ahead. I do not believe we need much more but if you have time why not.

@andrii-i
Copy link
Contributor

@krassowski #14074 is merged, let's see the outcome of the poll and discuss again

@ellisonbg
Copy link
Contributor

Let's see how the poll goes and call a council vote if we can't reach consensus. Thanks for working on this @andrii-i and @krassowski

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants