How do I know my keyboard is dropping characters on a password field?
A power cut took out my home server–a Mac Mini running macOS High Sierra. It (sensibly?) has a boot password and encrypted SSD. I brought the system back online to be prompted with the usual login screen. No matter what I did, it would not accept my password.
After 3 attempts, macOS prompted me with a “reminder” (and suggested I could use a recovery key).
The rarely-typed password is pretty hard to enter correctly (that’s on me). But you cannot use a password manager this early in the boot process. There is also no feedback other than the masked characters in the input field, no way to visibly validate the characters being entered into the password field.
There’s a good pattern used in web for assisting here: put the visibility of unmasked password fields in the hand of the user. In my case, the Bluetooth keyboard was misbehaving: it apparently was dropping keypresses (a desperate keyboard swap accidentally fixed the problem).
Arguably this was all an edge case. I mean how often do you have a broken keyboard? But then you’d be ignoring an accessibility red flag: the input fails due to physical device awkwardness with no user feedback what so ever (other than “try again”). So what about users with alternative input devices?
Apple solved this on iOS. When you tap a key on any field (including password fields) you can get brief flash of that key. Elsewhere on web, a field can toggled between text/password visually, giving the user control of when the field is exposed.
Here’s a demo I put together a while back with progressively enhance password toggling for web:
The question is why this sort of toggle hasn’t made it into macOS.
Mobile navigation frequently consists of a burger menu placed in the top right of the viewport. But consider this: a user with a large phone using just one hand, can their thumb stretch that far? This is particular issue on the larger format phones such as an iPhone 7 Plus.
Some of the UX niggles in mobile navigation:
Awkward one handed navigation
Fiddly menu and links
Inappropriate menu items for context of device
Little room for styled menus or call to actions
Move the navigation to the bottom. By placing the menu toggle where it is easily reached in one-handed use. It also keeps the navigation controls for your site close to the control UI provided by most mobile browsers (bottom of the web view).
We reposition the menu with CSS, meaning the underlying HTML document remains logically (seminally) ordered for screen readers and document parsers.
Leave the brand where it is (top). We don’t want to waste our precious mobile screenspace, so we avoid making it “sticky” or “fixed” or anything else that obscures the content. In this example the brand is fairly large, but we should try to keep it small and out of the way. On visiting a site on a mobile, I want to know what that site is about quickly and without scrolling, so lets promote the content and not waste screen space with branding.
Tiles, not links. Links can be hard to tap on a mobile. We can significantly increase the hitbox for each menu entry by making them tiles. This also provides a lot of opportunity for branding or colourful styling—but not at the expense of a clear, readable label.
You don’t have to show everything. I’ve noticed many mobile menus try to show all the things, which may not actually be that useful for different devices. Why not hide the menus we don’t want? In this experiment, we can tag menu elements with menu-item--hide-desktop class to hide (natch) content from the desktop. We could equally do that for mobile.
Don’t be afraid to repeat links, sometimes it’s fine. Here, I’ve taken what I think are the three most important menu entries and explicitly called them out as additional ’tiles’ to display along side the mobile navigation button. Quick access for the user, without distraction.
Encountered a strange issue with Safari while building this one. An absolutely positions display:fixed element (the mobile nav, viewport bottom) was not being rendered at all. Chrome and FireFox were displaying the menu perfectly. This was due to Safari ignoring width: 100% on the menu wrapper. Replacing width with left: 0; right: 0 resolved the issue.
This experiment is reliant on flexbox (display: flex) support in your browser. These days that covers most browsers, but if you do need to support older browsers, consider adding a fallback to CSS tables.