GNOME Bugzilla – Bug 688208
UX: The lockscreen needs further attention
Last modified: 2021-07-05 14:05:15 UTC
Hi, I think there's something wrong with how the whole screen locking is working, from a UX perspective. Image attached.
(In reply to comment #0) > Image attached. Nope :-)
Created attachment 228832 [details] Failed to attach for some reason.
Sorry, It's up. :P
And apparently, I was too tired to proof-read it. :(
Reda, this looks interesting, but it is hard to know exactly what you are getting at. Could you give us a short summary? It also looks like you are touching on existing bugs: * gdm => session transition doesn't look very good (bug 682429) * Lock screen - blur and desaturate the background (bug 682536) * Use a different image for the screen shield (bug 688210)
Yes, I tend to offer tens of possible solutions which can blur what I want to say. :) The first bug you listed is different(was going to report that actually :P), but the two are indeed touching the proposed solution(#3). In short, this report is more of a "case study" of how the lockscreen is behaving now(3.6.x) and how to improve it from both a logical perspective(the way the animation is done, and what is shown to the user) and from a user-friendly perspective(how to show the user how to unlock without frustrating him). The images shows multiple problems and try to solve them; so naturally, I might have touched an existing bug or ten. What I suggest is to discuss this, isolate the problems and we could re-report them as individual bugs for the devs. Problems? :)
"I can still see my desktop below it" -- this is a bug: bug 686943
No, I didn't mean it like that, Jasper. Let's break the whole thing down to layers(far right), I meant that while I had only the 'Desktop' layer at first, locking the screen will make an additional layer with the same 'Desktop' properties(Look, color...) _without_ being my desktop _and_ while keeping my desktop. So, if the original intent was "give the users a desktop-y lockscreen to make them feel at home" it should _not_ show me two desktops at the same time with one sliding from nowhere over the other. That's <a part of> what I'm trying to point out(and hopefully solve).
A central aspect of the design is that the lock screen appears as a physical layer on top of the session. We also use the grey texture for the login screen to suggest that you are outside of the normal session until you have logged in. This same texture is intended to be used for initial setup, boot progress and the message tray. The transition from lock screen to session is somewhat interrupted by the grey texture - the sense of the lock screen being on top would be greater if login happened on the lock screen itself - and perhaps the design could be refined in that sense. That said, the grey texture does mean that the login screen is consistently presented, and I'm not convinced that we need to be overly literal in how the metaphor is enacted. Still, ideas are welcome.
Although, I hinted at not using it, my main issue isn't with the dark login/password layer; my issue is with whether or not the lock screen layer should slide from the top, and if it does how logical(or illogical) to give it the same look 'n feel as the desktop _while_ showing the desktop and whether to explain to the user that there are actually _two_ layers that are covering the desktop; so instead of sliding one and show two later, I had the idea of delaying one a little bit. I think this could be best explained better differently. I'll try to put something together by tomorrow. :)
One of my early ideas as to have both visibly slide down when you locked the screen, with a bit of delay. So you would a sliver of the gray unlock dialog sliding down, and then you see the shield on top. This also worked a bit better with the arrow cutout in the original design. Maybe we figure out how to make the cutout work better, instead of the runway lights?
Exactly my idea. :)
Created attachment 228845 [details] Quick (delayed) animation. Here's something quick, I should be able to cover everything I explained in a longer video by tomorrow. :)
(In reply to comment #13) > Created an attachment (id=228845) [details] > Quick (delayed) animation. > > Here's something quick, I should be able to cover everything I explained in a > longer video by tomorrow. :) I don't really see the advantage of that. The extra grey strip looks a bit odd and is kinda distracting. I'm tempted to close this if you don't have any more concrete suggestions. Bug 682429 is the one to be focusing on, imo.
So sorry Allan, I know I said "tomorrow" ages ago. I've been a little bit busy. I'll do my best to send something shortly. As for the bug, I agree about the problem; but I'm trying to point out another issue. Please give me some time to sort things out and I'll be here. Thanks. :)
Hi, Sorry for taking an eternity. I wasn't sure how to simplify the report. Problems: http://db.tt/wXhk73ei #1- The only clue of the desktop state is a tiny icon. And it's so small it may not communicate locking at all. [1] #2- The same desktop wallpaper is used in the lockscreen. This not only creates confusion and the animation "explaining" is illogical(as stated before); it might simply not work at all if the wrong image is chosen. #3- There is no obvious clue of how to get out of there. The only clue is a semi-transparent, flashing arrow-set. Also, you expect the desktop user to understand what a flashing arrow means; for a tablet user maybe but for mouse user this is unnatural. #4- The way the notifications are stacked up is just broken: - It pushes the clock to the top. - Creates a huge box in the middle with some useless, redundant text. The useful text is the one the shows up after you unlock. - And most importantly, it covers the ONLY clue of getting out. Which worsens #3 even more. Suggestion: Fixing the problems separately and combining the results leads to these: http://db.tt/H1mJC3sp - The curtain concept is flawed(at least the current implementation). Works fine when revealing the password field, though. (probably fixing the illogical events that happen after locking #2). - Let the user choose the background, If you're not planning to add a dedicated icon on the control center(for some reason) add a section in 'Backgrounds' to choose the lockscreen image. (Fixes #2 too) - Use two different states: Locking and leaving will display a nice clock. Upon moving the mouse, the second screen kicks in EXPLAINING what's going on and how to get out of there in a human-understandable way. (Fixes #1 #3) - Use icons+emblems and get rid of all the extra stuff. This not only is cleaner, it's consistent with the way they are displayed in the messaging center. (Fixes #4) [1]: "...She misclicked and locked her screen instead of powering off. She had no idea that it was a lockscreen. In this case, GNOME 3 could be more intuitive. To defense GNOME 3, I must say that until today my mom had no idea that something like a lockscreen existed." From: http://eischmann.wordpress.com/2012/12/12/testing-gnome-3-on-family-members/
.(In reply to comment #16) > Sorry for taking an eternity. I wasn't sure how to simplify the report. No problem. Thanks for the continued input. :) > Problems: http://db.tt/wXhk73ei > > #1- The only clue of the desktop state is a tiny icon. And it's so small it may > not communicate locking at all. [1] The shield metaphor is intended to communicate the state - ie. it slides down to cover your session. > #2- The same desktop wallpaper is used in the lockscreen. This not only creates > confusion and the animation "explaining" is illogical(as stated before); it > might simply not work at all if the wrong image is chosen. Yep, that's bug 688210. > #3- There is no obvious clue of how to get out of there. The only clue is a > semi-transparent, flashing arrow-set. Also, you expect the desktop user to > understand what a flashing arrow means; for a tablet user maybe but for mouse > user this is unnatural. I've done user testing on this and people did understand it. Generally people either press a key (often return). Some of the users also understood the drag up to unlock behaviour. > #4- The way the notifications are stacked up is just broken: > - It pushes the clock to the top. > - Creates a huge box in the middle with some useless, redundant text. The > useful text is the one the shows up after you unlock. > - And most importantly, it covers the ONLY clue of getting out. Which worsens > #3 even more. Yeah, I agree with the layout issues for the notifications. > Suggestion: Fixing the problems separately and combining the results leads to > these: > > http://db.tt/H1mJC3sp * "Screen is locked" seems rather heavy-handed to me. The text will be redundant once someone has learned how to remove the screen. * Pressing a button will not guard the screen against stray taps on a touch screen (think about a device that is in a bag and accidentally gets activated). * I rather like the proposal for the notification layout - please file that as a separate bug.
> The shield metaphor is intended to communicate the state - ie. it slides down > to cover your session. For me the shield idea is fine as long as it makes sense. > Yep, that's bug 688210. Okay. Subscribed. > I've done user testing on this and people did understand it. Generally people > either press a key (often return). Some of the users also understood the drag > up to unlock behaviour. Yes, it's obvious enough...as long as you have an understanding of what's happened to the desktop. i.e. why it isn't responding to my clicks? And where is all my stuff?... > * "Screen is locked" seems rather heavy-handed to me. The text will be > redundant once someone has learned how to remove the screen. > > * Pressing a button will not guard the screen against stray taps on a touch > screen (think about a device that is in a bag and accidentally gets activated). Yes, I agree. But the point was just to demonstrate what I had in mind. If my solution is acceptable/better I think I can suggest some other means. But I think you haven't commented on one important issue: "- Use two different states: Locking and leaving will display a nice clock. Upon moving the mouse, the second screen kicks in EXPLAINING what's going on and how to get out of there in a human-understandable way. (Fixes #1 #3)" > please file that as a separate bug. Yes, no problem. :)
Some user testing I did myself showed that nobody understood the arrows.
Speaking of testing, do you guys publish the results somewhere?
The only contentious point left in this was whether the arrows were or weren't a good metaphor, right? A separate bug would make it easier to focus on one problem rather than the grab bag here.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.