> In modern Windows, press Win-key and start to type, oops, it missed the first keypresses, presented the completely wrong results and made a mess of your workflow.
The worst offender is the login prompt. In Gnome, from the lock screen, I simply start typing my password. As soon as I type the first letter of the password, the password prompt appears, and when I'm done I hit enter and it unlocks.
On Windows, the first letter merely makes the prompt appear, but does not yet type into the prompt. In fact, it will only start feeding letters into the prompt once the little prompt-appearing-animation has finished. If I just start typing my password, it will eat the first three or four letters. So I hit enter, wait for the animation to finish, and only then start typing.
That's not the end of the world, honestly. But it is a learned gesture that the system taught me by failing to do what I'd asked it to do. It just goes to show the attention to detail that makes a UI feel fluid and frictionless.
> In Gnome, from the lock screen, I simply start typing my password. As soon as I type the first letter of the password, the password prompt appears, and when I'm done I hit enter and it unlocks.
Congratulations! You were able to recognize that it's a _login screen_ without seeing that there's a hidden password field.
The first time I booted to Gnome I waited damn near ten minutes for it to tell me it's ready for my login before I decided to start typing things to see if it was stuck.
Miming mobile OS lock screens is one of the weirdest damn things about modern desktop trends. It's so obviously a bad idea. I can't even figure out what useful functionality anyone thought that would provide. It's a fucking desktop, there's plenty of room to stick notifications or the weather or whatever on the same screen as the login prompt, if that's what you want.
I've said this on Reddit before, but the current Gnome is excellent for someone who loves it and only needs a few changes to make it work for you. Personally, I like how everything works (you could also say that this is some form of Stockholm Syndrome, ha ha). I like not having anything distracting from
The answer for most of these is "there's an extension for that"
> - Where can I go to see my current running applications?
I rarely have to do this (for me it's almost always IDE, Terminal, Browser), but "alt-tab then escape" is an option. For the window list at the bottom, there is the Window List Extension (https://extensions.gnome.org/extension/602/window-list/), part of the core Gnome desktop as well.
In short, most of your complaints would be solved by logging into Classic Mode, which tries to emulate the Gnome 2 experience using some built in extensions.
> - Why does the top bar do nothing and function like my Android top bar?
I am not sure what this means, but I like the Shell's current behavior where we have as few active elements as possible detracting from your active window.
I should preface that I love Gnome and am excited by the future. My criticisms come from a place where I want to see it be the best experience possible on desktop, and the obvious choice when it comes to choice of DE.
> there's an extension for that
Yeah this is fair, sadly it's not a satisfying solution. Extensions are often not supported on the latest version of Gnome for some time and even then, there's an issue of discoverability for both experienced and new users.
I understand the desire for customizability, but I'd prefer my desktop environment come out of the box tailored to facilitate a desktop experience.
I am happy there is an alternative however this has the side effect of removing the "Hit the super key then type a search query" workflow. Ironically, an actual application menu is nearly entirely useless for me outside of niche cases. I have been using start menu search and spotlight for years at this point - gnome's activities overlay is just that with extra animations.
> I rarely have to do this (for me it's almost always IDE, Terminal, Browser), but "alt-tab then escape"
This is exactly how I use my desktop too.
In MacOS I used virtual desktops so heavily to organise this and it was an _incredible_ workflow.
Monitor 1, desktop 1 is terminal, desktop 2 is IDE. Monitor 2 desktop 1 is debugging browser, monitor 2 is slack, music and misc. Flicking between the desktops, everything is positioned exactly where I want it to be and there is no guessing what is going to be shown.
I only started using Alt+Tab after coming back to Windows and now again on Gnome. Alt tab is a bit too guess-y for my taste. If you have multiple windows of the same type (e.g. browser and seperate browser debugger) open, what does Alt-Tab open?
In Gnome, rather than using virtual desktops, I hit the super key and pick the application out of the application mosaic because it's deterministic and faster than Alt-Tab
> I am not sure what this means
Swipe down from the top left and you have applications, swipe down from the top right and you have quick settings. Clock is in the center. The elements are responsive. It looks and functions like the top bar for a mobile device.
The top bar doesn't have application shortcuts, it doesn't show you active background applications.
If you look at the effort that all desktop experiences have made to make their top bar/desktop bar useful, you will see distinct differences when compared to mobile operating systems that have to be cognizant of their use of space.
MacOS has a global menu, taskbar tray, taskbar add-ons (for cpu usage, international clocks, etc) and applications are opened via spotlight (Albert) search.
Windows has shortcuts, a start menu with search, and a taskbar tray, along with lots of options to administer the computer when you right click the start bar.
Gnome offers a horizontally space efficient mobile-optimised top bar and a full screen, mobile style application picker. Application search and the open apps mosaic are the saving factors of it
>Why are there no icons in my tray for my background apps (steam, slack, etc)?
I understand the other ones but I don't understand this one. The Android tray does exactly this, background icons on the bar are a mobile feature. If you consider the Windows taskbar to be the ideal desktop experience, it doesn't do that, it hides the icons in a menu.
Not sure what you mean here - both MacOS and Windows have icons in the system tray for background applications and it's been that way since before Android was a thing.
Windows does hide excessive icons, which MacOS doesn't do - it's a great way to hide running the pre-installed Skype and Teams at the same time :laugh:
Normally I'm a Mac/Linux user, but last time I tried Windows it hid all the icons by default. They used to show them in older versions but they do not anymore, probably because everyone including the OS vendor itself uses it as a dumping ground for product tie-ins and clutter like that.
These things made me move away from Gnome. In gnome3 occasionally the login screen would require me to click the screen and drag upwards to get the login prompt. Customizing any if these things was always a hacky workaround. I'm very happy with Mint Cinnamon right now.
One unfortunate reality is, for a lot of new users - especially people who haven't used desktop computers before - their first computer was a mobile device. If we don't want Apple and Google to take over the entire space, we need to meet them halfway.
The lock screen is weird, though, I agree. The newer (blurry background) one is better than the old one with the tedious swipe animation, but really could use a persistent "do this to unlock" prompt / button, because many people just aren't comfortable poking their computer unless they know what it is going to do. A lot of modern UI design unfortunately forgets that.
For what it's worth, the original design for GNOME's current lock screen involved bridging the gap between it and the login / switch user screen, which _would_ involve some more UI elements, but the actual implementation must have stalled somewhere.
Oh ok, so people don't make the difference between a mobile phone and a computer. That is also why they don't know how to use a TV because it's not like a smartphone, right ?
That was a very bad idea from the very start. But it's the motto Gnome 3 was built on... I agree with the initial comment, Human-Computer Interraction SCIENCE went down the toilet drain to be replaced with so called UI/UX "experts"
That is one of the main reasons why I switched from XCode to CLion. XCode lost keystrokes, which drove me crazy. The other thing was that I could reliably type faster than XCode could display the letters, which made me feel like I'm drunk.
CLion seems to be quite excellent at recording and replaying everything, including stuff I type while the auto-completion is loading. Plus it has a really fast key to screen loop.
As an aside, I find it amusing that more latency is introduced by a USB keyboard than existed in an entire 80's computer (from keypress to rendering on screen). See also: Carmack's rant about how it takes longer to put a pixel on the screen than ping across the Atlantic.
About the USB keyboard, that may be true only for the cheapest keyboard you could find, but basically not applicable anymore nowadays. Rather than giving you the details, let me link to this video, which is awesome at explaining it and much more -- the USB vs PS/2 part starts here: https://www.youtube.com/watch?v=wdgULBpRoXk&t=1766s
>at the time I did these measurements, my 4.2 GHz kaby lake had the fastest single-threaded performance of any machine you could buy but had worse latency than a quick machine from the 70s (roughly 6x worse than an Apple 2), which seems a bit curious.
>We can see that, even with the limited set of keyboards tested, there can be as much as a 45ms difference in latency between keyboards. Moreover, a modern computer with one of the slower keyboards attached can’t possibly be as responsive as a quick machine from the 70s or 80s because the keyboard alone is slower than the entire response pipeline of some older computers.
Most normal keyboards, mice, and USB HIDs report events at a rate of 125 hz == 8 ms between reports.
Gaming mice usually go up to 1000 Hz / 1ms, the wireless ones usually let you configure down to 500/250/125 Hz if you want a bit more battery life. I'm sure that gaming keyboards also have a high refresh rate.
If you have a 144 Hz monitor that actually means your (normal) keyboard and mice are reporting events less often than your display is updating.
A lot of gaming hardware is trash. 1000 Hz on the package, endless latency inside, buggy firmware, buggier and resource-hogging companion apps, which are always Windows-only, and there are still even "gaming keyboards" which are 2KRO, bad materials and so on
That being said pretty much any 1000 Hz mouse is better than any 125 Hz mouse when using high refresh rates because the discrepancy between the 125 Hz mouse poll rate and the 120 or 144 Hz display causes very noticeable jitter. If you have a mouse where the poll rate can be adjusted, this can be easily A/B tested; it's quite visible in high-framerate recordings as well (this can be done in OBS by using the fractional frame rate selector and just inputting 144:1).
All of the Jetbrains editors also have these bugs in some places too unfortunately. The main one I run into is when you open the fuzzy goto modal (CMD + O) there’s a delay before the window opens where if you paste/type anything it goes into the file you’re editing instead of the search box. It’s been like this for at least 5 years.
Win 10 tought me to type again at least CTRL+ALT if i want my password to be accepted from the first time. Clicking with the mouse sometimes works before entering the password. It seems that at MS and also in other areas (Android, Gnome) people want just to code new things but not debug or fix bugs. They also must be as simple as possible because: 1. code reuse sucks. 2. Thinking is hard.
When I log into a Win 10 virtual desktop with 1024*768, the login form with 2 text fields and a button gets shoved into a box and I have to scroll down to see it fully.
It's certainly not the end of the world, but it's death by a thousand papercuts. I find macOS has fewer sharp edges (but still has plenty of them), and Linux too, once the system is configured and only used for writing code.
> That's not the end of the world, honestly. But it is a learned gesture that the system taught me by failing to do what I'd asked it to do.
Although I agree this is annoying, to be completely fair, it doesn't suggest that you should start typing your password immediately.
You could also start typing 'news.ycombinator.com' and it wouldn't browse to HN, but you wouldn't say that it failed to do what you asked it to.
Arguably, you have been 'taught' or you have inferred yourself that you should expect a sleeping system to immediately accept your keypresses as a password, which although reasonable is not necessarily a good practice.
For example - I have two computers connected to the same keyboard, one is indeed Gnome, the other Windows. I have twice now typed my password into what I thought was my sleeping Gnome system, hit enter, only to have to apologise to someone on Teams because I accidentally sent them my password because my keyboard was sending my keypresses to the Windows PC.
I... am sorry, but I think that is extremely bad practice. You should not put yourself in that position, and your experience in that position does not excuse the design flaws in windows.
> You could also start typing 'news.ycombinator.com' and it wouldn't browse to HN, but you wouldn't say that it failed to do what you asked it to.
Well firstly, that isn't what the prompt is for, so I'm struggling to see the relevance. However it is a good example for me- When I type C-l right now, I can _immediately_ start typing 'news.ycombinator.com'. There is no delay, no animation, nothing. I didn't go through a learning experience of finding out how long I should wait before typing- it's just ready.
Fundamentally: _why_ should I have been "taught" anything about how long I should wait? I don't have to do that on my ubuntu laptop. I don't have to do that on firefox in the example you handed to me. It's bad when I have to learn that. The computer should never make me wait unnecessarily, and I find it worrying that people are so readily accepting of it.
GP's (I think reasonable) point was that typing A on the keyboard of a locked (or worse, sleeping) computer has no reason to be interpreted as "input the letter A into the password field that will be displayed on screen", which is what the original post is assuming it should mean. There's no real reason it should even mean "input the letter A into the first field that comes into focus", which may anyway not be the password (it could be the Username field in certain setups).
Well, you usually see the logged in user’s name and icon on the screen, and presumably you left your own computer there.
And frankly, UX is about finding the little practices that make the experience better — arbitrarily waiting for windows to bring up a prompt is not making me any good, since I know what I want to do. So in my opinion in this very special case, windows is simply doing an incorrect thing — making the common case slow.
> Well, you usually see the logged in user’s name and icon on the screen
I don't have this experience. On Windows (10, at least), normally I see either a black screen (if it's asleep) or a wallpaper, clock, and a message saying 'Press Ctrl + Alt + Delete to unlock.'
> arbitrarily waiting for windows to bring up a prompt
I don't think it's arbitrary. It's doing something - it's calling Winlogon, spinning up disks and reading hibernation data into memory, restarting power to powered down components, probing authentication methods available (eg: fingerprint/card readers), in case of domain joined computers, validating whether the domain is available (which means firing up network interfaces), and if so, whether the user's password has changed, etc.
There are definitely downsides to Microsoft's approach here - as you mention, in a large number of cases, it takes more time to unlock the computer.
However, there are also upsides if you accept that UX is only one consideration when designing a secure log on prompt, and there may be other priorities.
> I... am sorry, but I think that is extremely bad practice.
Completely correct - I'm not excusing my lack of attention there.
> Well firstly, that isn't what the prompt is for
That's exactly my point. There is no prompt displayed on the screen, you have not been asked for input. You are pre-empting the next prompt before the system is ready for it.
> When I type C-l right now, I can _immediately_ start typing 'news.ycombinator.com'. There is no delay, no animation, nothing. I didn't go through a learning experience of finding out how long I should wait before typing- it's just ready.
Agreed - but that's with the application already open. From the lock screen, it won't do what you intend. With Firefox running and in focus, Ctrl + L tells the application to focus the address bar, but it only works in that context, you first have to prepare the correct context (computer unlocked, Firefox running, in the foreground and focused).
On Windows, Ctrl + Alt + Del tells the system to wake, not 'the next characters entered will necessarily be the password of the most recently logged in user'.
In fact, I tested a little bit, and often Ctrl + Alt + Del on a sleeping system actually asks me to enter a username first, not a password, although in some cases the username is pre-filled for me, and the password prompt will be focused. I cannot necessarily know a priori which I will be asked for until the system wakes and decides.
As soon as Windows displays the prompt, you can type into it (same as Gnome). The only difference is that Windows requires you to first wake and then authenticate once the system is woken, while Gnome allows you to do both simultaneously.
There is one particular 'pro' to the Windows approach of requiring Ctrl+Alt+Del which is that it's an interrupt sequence. If a malicious actor created a full screen application that mimics the Windows password prompt, it would not be effective because the Ctrl+Alt+Del sequence cannot be handled by an application. The same is not true for Gnome - if a malicious actor created a full screen application that mimics the login prompt on Gnome, you could be tricked into entering your password.
> Arguably, you have been 'taught' or you have inferred yourself that you should expect a sleeping system to immediately accept your keypresses as a password, which although reasonable is not necessarily a good practice.
I fail to see why that wouldn't be a "good practice". Last weekend I read some articles on Canon Cat[1], and Jef Raskin referred[2] to the feature as something desirable:
> In many ways it was, for 1987, far ahead. [...] instant on with any keystroke (and you didn't even lose the keystroke)
He goes on to explain why it's a good idea to do so in the article, it's a good read.
Thanks for sharing. I can definitely see why it might be appealing. However, using Ctrl + Alt + Del guarantees that only Winlogon can handle the logon, no other process can be simulating the login prompt.
My dad told me about a program he wrote for a PDP-11 which would just simulate a login prompt. When a username and password were entered, it would append it to a file somewhere, then print the 'Incorrect username or password' message, and exit silently.
The user would assume they'd fat-fingered the password, and try to log in again (successfully) and be none the wiser that their password had just been stolen.
The Windows dependency on Ctrl+Alt+Del makes this type of attack impossible, while systems that don't require a Secure Attention Sequence (as apparently it is called) to log in are susceptible to a slightly more sophisticated version of this attack.
I see. It makes sense, and it's a valid concern that I didn't think of. Personally, I prefer the convenience of continuing where I left off with as little friction as possible, so I don't even lock the session when the screensaver kicks in. But I never take my laptop outside, and the threat of malware is considerably lower under Linux. If that wasn't true, I would probably also want to err on the side of caution. Choosing a specific key (I have a very conveniently positioned X86WakeUp physical button) or combination for waking up and getting to login prompt seems like a good idea in that case.
The worst offender is the login prompt. In Gnome, from the lock screen, I simply start typing my password. As soon as I type the first letter of the password, the password prompt appears, and when I'm done I hit enter and it unlocks.
On Windows, the first letter merely makes the prompt appear, but does not yet type into the prompt. In fact, it will only start feeding letters into the prompt once the little prompt-appearing-animation has finished. If I just start typing my password, it will eat the first three or four letters. So I hit enter, wait for the animation to finish, and only then start typing.
That's not the end of the world, honestly. But it is a learned gesture that the system taught me by failing to do what I'd asked it to do. It just goes to show the attention to detail that makes a UI feel fluid and frictionless.