[Enhancement] Make login dialog more prominent, auto-show login dialog if necessary, hide empty smart folders for anonymous users
nagmat84 opened this issue · 12 comments
Hide empty smart folders for anonymous users
If no user is authenticated, i.e. in public mode, the smart folders which are empty should be hidden. This configuration could be made optional via a global configuration option such as hide_empty_smart_folder_public. If the albums are empty and nothing happens if one click onto them, user might be confused and false believe there is an error.
Auto-show login dialog when necessary
The login dialog should be automatically shown in various cases:
-
If an anonymous user browses to the on the front page and there are no public photos or anything else the anonymous user could potentially do, then the login dialog should be shown automatically.
At the moment the anonymous user must realize to click on the cog-icon in the upper-left corner to get to the login dialog. Not every user expects the login dialog hidden below a cog icon. See Gitter discussion on 11. August 2022 21:30.
-
If the user browses directly to a non-public, but shared album the user should neither see a 401 response nor be redirected to the landing page, but the login dialog should be shown automatically. This behavior would be consistent with how password-protected albums behave right now.
Make login/logout symbol more prominent in general
It should be possible to login/logout from every page of Lychee. The login/logout icon should not be hidden below a cog album at all. At the moment, this place is reserved for the "back" button in album an photo view. This is a probably somehow controversial proposition how it could like like.
Current situation
Suggested idea
This would also make the "down" arrow right of the title more prominent. Actually I only learned myself and really recognized the existence of the down arrow and the option to display an album tree due to bug LycheeOrg/Lychee#1155. Before that I never noticed this down arrow.
But probably this change is what @kamil4 calls "confusing the muscle memory".
Please do not take the suggested UI literally. I know that the logout symbol is blurry and too large. I was just too lazy to draw a good one.
I'm not a big fan of that bar in general, but I think that setup would be worse - that's definitely somewhere users will look for a back button, which will be used a lot more than a logout button. For Lychee specifically, logging out should only be required for people being extra-secure (or using a shared PC actually) or for testing (without wanting to use another browser or private/incognito mode).
If anything, I'd add it on the right, which seems more common, but I accept it is very cluttered over there.
I am in favor of adding a login button. I would be fine with keeping the log out under the cog wheel.
Personally, I think the UI need a big nice revamp (and Livewire might be a good opportunity for that). :)
I already have some ideas of how to improve the settings etc... Just lack of time. :(
First Laravel 9 (I really want to get rid of Larapass for Laragear/WebAuthn), then Livewire...
Re @d7415: Please do not concentrate on the logout button (this only the first symbol I found), but consider the login button as well. In LycheeOrg/Lychee#1462 we discussed the case that someone is browsing a public album and then needs to login without going back to the landing page.
But yes, I am open for any improvements. I am no UX expert.
Hide empty smart folders for anonymous users
Just to point out the obvious, but smart albums are not enabled by default in public mode; they need to be explicitly enabled to show up. Also, I'm not sure what problem we are trying to fix here; one can also have regular albums that are empty? And if empty smart albums are confusing and should be hidden away, then why only in public mode and not when logged in? The proposal seems inconsistent to me; I would either do nothing (always my first instinct 😉) or go all the way and always hide empty smart albums, whether logged in or not.
At the moment the anonymous user must realize to click on the cog-icon in the upper-left corner to get to the login dialog.
Actually, I think it's not the cog icon that gets displayed then, but rather the array pointing to the right (to the inside of the box). I don't know if there is an icon in use these days that more obviously represents "log in"? I think most websites use text ("Log in", "Sign in", etc.) rather than an icon these days, but given how cluttered our header is, I wouldn't advocate for it.
Make login/logout symbol more prominent in general
Personally, I'm OK with the logout being where it is; for better or worse, many websites these days hide the logout functionality inside a context menu, so users should be used to it.
Anyway, as I wrote in LycheeOrg/Lychee#1462, my recommendation would be to keep the back button where it is (both because it will be used more often than login/logout and to preserve the current behavior) but, in public mode, add the login button next to it on the right.
An issue that I haven't considered until you pointed it out is that one has to go to the top albums view to be able to log out; that does indeed seem suboptimal. So should the login button I proposed be replaced by the cogwheel for logged in users? That would also enable faster access to pages like Settings from, say, photo view, although we would likely need to do some clean-up to make it work reliably (I'm guessing there may be assumptions in the current front end that those pages are only displayed in the top-level albums view).
Actually, I think it's not the cog icon that gets displayed then, but rather the array pointing to the right (to the inside of the box). I don't know if there is an icon in use these days that more obviously represents "log in"? I think most websites use text ("Log in", "Sign in", etc.) rather than an icon these days, but given how cluttered our header is, I wouldn't advocate for it.
Yes. And I think that's the closest to a log in icon - I've seen it used, but you're right that it's not everywhere.
many websites these days hide the logout functionality inside a context menu, so users should be used to it.
👍
So should the login button I proposed be replaced by the cogwheel for logged in users?
I'm not sure about the positioning, but I like this concept of changing login to settings. It feels neat..
At the moment the anonymous user must realize to click on the cog-icon in the upper-left corner to get to the login dialog.
Actually, I think it's not the cog icon that gets displayed then, but rather the array pointing to the right (to the inside of the box).
Your are absolute right. The current situation looks like this
I only wrote "cog" icon because that was what the one user was complaining about in the Gtter lobby and I had not checked it myself before I wrote up this issue. Shame on me.
I don't know if there is an icon in use these days that more obviously represents "log in"? I think most websites use text ("Log in", "Sign in", etc.) rather than an icon these days, but given how cluttered our header is, I wouldn't advocate for it.
I believe, this icon IS the generally accepted icon for login, hence I am fine with it. However, it should be shown for anonymous user in every album, not only for the root album, which brings us back to the original problem, because this space is already taken by the back button in albums.
Anyway, as I wrote in LycheeOrg/Lychee#1462, my recommendation would be to keep the back button where it is (both because it will be used more often than login/logout and to preserve the current behavior) but, in public mode, add the login button next to it on the right.
If I follow you correctly you are suggesting something like this:
I could live with it, but I am not convinced. Personally, I would like to try to stick to the following design principles:
- The login/logout icon should always be in the same position
- The icon should toggle between login/logout depending on the current state
This does not say anything about a specific position. It could be everywhere: left, right, top or bottom. But I would like to avoid a "jumpy" icon. Positioning the login icon to the right of the back button implies that it jumps depending on wether there is or is not a back button. That is why I proposed to move the back button to another position.
An issue that I haven't considered until you pointed it out is that one has to go to the top albums view to be able to log out; that does indeed seem suboptimal. So should the login button I proposed be replaced by the cogwheel for logged in users?
Like this, I believe:
Replacing the login symbol by the cogwheel is fine for me. IMHO, I would have added the cog wheel in addition, but I can live with it either way.
Hide empty smart folders for anonymous users
[...] I'm not sure what problem we are trying to fix here; one can also have regular albums that are empty? And if empty smart albums are confusing and should be hidden away, then why only in public mode and not when logged in? The proposal seems inconsistent to me; I would either do nothing (always my first instinct wink) or go all the way and always hide empty smart albums, whether logged in or not.
You are right, the proposal includes some inconsistencies and I am not going to fight for it. Just let me sketch my thoughts:
- Empty smart folders don't serve a purpose for the unauthenticated user, but authenticated users can still upload photos into it.
- Hiding the empty smart folders for an authenticated user could mean that novice users will never discover their existence, hence I would keep showing them.
- If we show the login dialog automatically, hiding empty smart folders visually empathizes the fact that there is really nothing and that users must first authenticate before they can do anything. If we still showed the empty album in the background of the login dialog, users might still want click on it (basically only because it is there) and become frustrated because the login dialog is in their way. It's more a psychological thing. If you don't know what could be there, you won't be looking for it.
Anyway I would make it optional as I said.
I could live with it, but I am not convinced. Personally, I would like to try to stick to the following design principles:
- The login/logout icon should always be in the same position
- The icon should toggle between login/logout depending on the current state
Agreed.
I don't like that look. :(
Not convinced either.
I am also worried about user clicking the cog/back/login button by accident when there are two on the left side and we have already muscle memory (though I will shamelessly admit I use esc and L).
IMHO it would be better to make this part of a complete refactoring of the header bar/menu.
I think it's worth noting that that's already a "small" header...
@d7415 wrote:
I think it's worth noting that that's already a "small" header...
Right, it does not really count for "small", but do you see a problem here? I assume that most users which take photos seriously do use a monitor anyway, i.e. no smartphone. I like it, that most actions are only one click away. I would not like to need two clicks every time, because everything is hidden in a sub-menu if I have the space.
@ildyria wrote:
I already have some ideas of how to improve
Personally, I think the UI need a big nice revamp
and
MHO it would be better to make this part of a complete refactoring of the header bar/menu.
Maybe you could share with us what you have in mind? We currently have two suggestions. I agree (and I believe @kamil4 and @d7415 would, too) that none of them is the solution one would ultimately vote for. But simply keep telling that you don't like them and murmuring that you have some other ideas does not take us anywhere.
At the moment the score seems one to two for this
in favor of this
FYI, back in the day @SerenaButler made some design sketches for us. I can't locate the issue that had a whole lot of them, but here's at least one:
As you can see, he was advocating effectively splitting the items from the current single header into several places to avoid overcrowding...
Here are my Thoughts from 2019 about the UI.