WIP: UI improvements

[JuliDi]

As discussed here #1210 I have drafted a few changes to the UI.
I tried to be very conservative about adding more padding etc. because I really like the rather minimalist design of Rauthy.
So here are also a few screenshots of what it looks like now and I'd like to hear what you think before proceeding with this.

Most notably, I switched the order of label and input because then the validation errors do not "collide" visually with the input description label (also most other websites have this order so I think it is more what users expect).
And I added a small border around the input to make it visible more clearly that it is an input, which I hope improves accessibility for people with vision impairments.

---

On the user page I have added an overflow: auto to the info div to avoid clipping:

Before

Now

[sebadob]

Thanks!

I am not sure if I like the switched order for the label. Before, it made just more sense to me when label + validation error are actually placed together instead of spaced apart, divided by the input. The red border can stay on errors for sure. The padding is out of place for the label in the suggestion as well. It at least would need to start at the same distance as the error message, more likely at the end of the border radius, and I would like it more towards the actual input, because if you have multiple inputs, you might get confused about where the label belongs otherwise. To make this work in all situations, you would need more margin between them in general, or push the label a tiny bit more toawrds the input, I guess. Especially the "Password" label in the screenshot looks out of place and seems to have more spacing than "E-Mail", which looks weird. The "Token Lifetime" in the 2nd screenshot looks better again, but I would add a padding-left of probably something like .5rem to have the same indentation as the error message.

All of this is the original reason why I had label + error message below it. To improve readability, I would probably only add a bit more spacing between label and error message in the original layout, but not too much, so they clearly belong together.

In terms of accessibility, the inputs were fine in the independent review, because they are also marked as invalid and screen readers can pick this up, but yeah the bigger, red full border is easier to see for sure.

In terms of spacing between inputs and label -> input -> error, adding a custom attribute is probably a good idea. This is a place where they are stacked on top and it should be clearly visibile where everything belongs, even without the context like "when you look at the top, you see the label is above the input":

This is also the reason why I currently have some negative marings for labels and error messages.

If we're going with the label on top and full border approach, I would reduce the inner padding for options selectors slighty to match the inputs. They are a bit bigger in your screenshot.

---

While you are on this, could you also add an overflow-y: auto for the Nav in the Admin UI to fix #1224 ?

[sebadob]

Something else I just noticed, it that label, actual input and error message should have the same indentation from the left to actually look nice. This looks a bit off as well in the screenshot. Either have all of them start at the same indentation, or maybe try to find a good middleground that the input value starts at the 2nd char of the label / error message, but this will probably not work with non-monospace fonts anyway.

[JuliDi]

Thank you for your feedback @sebadob
I will look into all your points and see how I can fix them – and then get back to you with more screenshots.

Regarding the fix for #1224 I can integrate that for sure, thanks for the hint.

[JuliDi]

While you are on this, could you also add an overflow-y: auto for the Nav in the Admin UI to fix #1224 ?

Fixed in 3f64235

I had to make a few more changes to prevent having two scrollbars in the navigation (one for the navigation bar and one for the menu elements). It seemed to me that having the bottom controls fixed in place and not be hidden would be more practical than having to scroll down in order to logout.

[JuliDi]

Something else I just noticed, it that label, actual input and error message should have the same indentation from the left to actually look nice.

Changed in dacd36e
I changed it so that it roughly starts at the end of the border, and label and error align. It's a bit difficult to get perfect with different fonts and font sizes, though :/

[JuliDi]

Especially the "Password" label in the screenshot looks out of place and seems to have more spacing than "E-Mail", which looks weird.

and for the password

Addressed this in 50473b5 by aligning the InputPassword's label with the one in Input and 92b936a by adding the missing invalid class to make the password input have a red border, as well.

[JuliDi]

In terms of spacing between inputs and label -> input -> error, adding a custom attribute is probably a good idea. This is a place where they are stacked on top and it should be clearly visibile where everything belongs, even without the context like "when you look at the top, you see the label is above the input":

This may be a bit excessive padding between the inputs, but I think it's quite clear where everything belongs. Should I reduce the padding a little?

[sebadob]

This may be a bit excessive padding between the inputs, but I think it's quite clear where everything belongs. Should I reduce the padding a little?

Yeah I like how it looks, but with a bit less margin / padding would be nicer. As long as the label text is clearly closer to the input it belongs to than the one above, I would reduce the distance between them.

[sebadob]

Just one thing I noticed as well: Could you please get rid of the auto-formatting and don't change files between spaces and tabs (I think that's what happened here), because this procuded a huge amount of changes and it's super hard to see what actually changed and what was switching from spaces to tabs and vice versa.

[JuliDi]

Yeah that really is a problem :/
Do you use any formatter that I could install to get the same formatting as you have?
My IDE does auto formatting on save, which does not align well with your formatter.

[JuliDi]

I am working on fixing a few other layout issues that I have introduced with these changes, e.g. for the datepicker.

Also I am thinking about how to best unify the CSS. Do you have preferences?
Right now I am mostly copy and pasting styles between input module files. Maybe move all the CSS to global.css? Or somehow reorganize how the input modules are used?

[sebadob]

I am using defaults from RustRover / IntelliJ and yes it does auto-format everything on save as well. I never created a specific formatter file for a JS project, would need to look that up later.

[sebadob]

e.g. for the datepicker.

Oh yeah regarding that one, I actually pushed a lot of fixes for the calendar input, because In found some issues in behavior with it. They were mostly in this push

Also I am thinking about how to best unify the CSS. Do you have preferences?

For CSS that should affect all inputs, check out the global.css, yes. There is already global stuff inside it and the other modules should have had more unique stuff applied to them, because when you start separating them in the global file by type, you can mostly edit in the specific components as well, which is a bit cleaner imho.

[JuliDi]

I am using defaults from RustRover / IntelliJ and yes it does auto-format everything on save as well.

Apparently you can export a .editorconfig file in IntelliJ https://www.jetbrains.com/help/idea/editorconfig.html
That might work with my IDE (Zed) then. Or at least I could try running another formatter before committing.

[sebadob]

Regarding the formatter, I just saw that my IDE is doing something to the indentation of some older files I used in the current PR. Either they were in a bad format before, or they changed the default formatter, not sure about it. I guess a dedicated one would be an improvement for sure.

[sebadob]

Apparently you can export a .editorconfig file in IntelliJ

I will have a look at this. Tried Zed before and really liked it, but it's still missing too many things for me unfortunately.

[JuliDi]

And it does have some weird bugs sometimes, but they are mostly fixed relatively fast. But I have no issue switching to VSCode or an IntelliJ-based IDE for working on this project if that makes things easier.

[sebadob]

fyi, I just added a .editorconfig file in #1240. This should fix all formatting issues.

[JuliDi]

I added it manually to my working copy, but it seems that especially the tabs vs spaces doesn't want to work. This is rather inconsistent across files and I don't know why. I will try to get something to work with the editorconfig, Or just go with Rustrover for the time being...

[JuliDi]

Hmm, it Rustrover itself doesn't do the formatting. It is the Svelte Plugin. And the Svelte Plugin for Rustrover does different formatting than the Svelte Plugins for Zed and VSCode. So the .editorconfig probably just doesn't contain the settings from the Rustrover/Intellij Svelte Plugin.

Maybe and external formatter would be good for the project. That could be run locally and enforced via CI.

[sebadob]

And the Svelte Plugin for Rustrover does different formatting than the Svelte Plugins for Zed and VSCode.

Oh yeah, wasn't even aware of this. The main issue is, that I cannot configure the Svelte plugin directly, so yeah, probably prettier is the way to go here.

Edit:

I guess that the Svelte plugin for IDEA could even be different as well, because I saw some re-formatting on my side for old files, which have been created when RustRover didn't even exist. That's super annoying.

Edit 2:

Yeah prettier is the way to go. I just need to figure out settings that I like, because the default makes things less readable (which is probably the reason why I disabled it ^^).

[sebadob]

Started to work on switching to prettier in #1241.

[JuliDi]

Great, thank you!

[sebadob]

I just merged #1241. The only annoying thing now it that you have quite a few file conflicts. -.-

But, there is the prettier end editor config. And you can either use npm run format in the frontend dir, or just fmt.

[sebadob]

Btw can it be the case that you need to do a merge from master to sync your git, or why is it still showing a diff here when there is none compared to main after your npm run format?

[JuliDi]

Yeah I will need to rebase but there is lots of conflicts :/

[JuliDi]

Gave rebase a try, now there are fewer conflicts – that's something.

[JuliDi]

I will fix these on the weekend so maybe we can get this into the next release along with the workaround from #1229