This is a simple trick for automatically displaying icons (such as social icons) without any script. Using a CSS wildcard selector, we check the href of our link and display a pseudo-element with matching content.
The above example uses a Font-Awesome glyph as content, but this could easily be replace with an image: content: url(/path/image.svg). Any subsequent link matching our selector would display our pseudo-element.
Be careful with your selectors. You could end up accidentally styling links that have been entered into a user-editable field (such as a CMS)… unless that’s what you really want. Wildcard selectors require the browser to do extra work, so you should use sparingly.
This little experiment creates a simple battery UI element, with its background an indicator of battery percentage remaining (plus percentage text): CodePen Experiment
The API provides a bunch of events we can hook into:
chargingchange – is the battery charging?
levelchange – percentage of battery remaining
chargingtimechange – amount of time until battery is charged (estimate)
dischargingtimechange – amount of time until batter is discharged (estimate)
All we need to do is check that we have support for the API and off we go:
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.
Password fields usually mask their content, but is that really good UX?
UX challenges of password fields
User ‘loses their place’ forcing them to start entering the password again.
Password hard to type or complex, no visual guide to text being entered.
Difficulty in paste a password from elsewhere.
Difficult to visually check validity of password before submitting.
Hard to copy password elsewhere before submitting.
An increasingly common pattern is to allow the user to toggle the visibility of the password field content, which has a number of accessibility benefits.
Many users have password manager add-ons—such as LastPass—which may adapt the display of password fields, so we have to be careful when it comes to styling the field itself.
There’s a possibility that the browser could cache or save the state of the field in plain text, which would be a Bad Thing.
Taking point 2, we can be a little smarter about how we handle form submits and ensure we only ever submit password fields, regardless of a toggled display state. This prevents point 3.
By placing the toggle outside of the password field, we can avoid most visual clashes with add-ons or password managers, covering point 1.
Here’s a dead simple trick for creating alternating boxes (flipping the order of element display) in CSS with display: flex. Each pair of boxes is wrapped in a div with flex applied. We can then select every odd wrapper and change the order of the content.
While experimenting with a new Pattern Library based workflow and I put together something to play with scaling content based on css vw units (viewport width) and full-page splashy design.
All it takes is…
…and the browser will calculate the size on the fly. There are 4 related properties, vh, vw, vmin, and vmax which can be used to scale most content base don the dimensions of the browser viewport. These units are percentage of viewport size, so 10vw == 10% of the viewport width.
vh = % of viewport height
vw = % of viewport width
vmin= whichever of vh or vw has the smaller size*
vmax= whichever of vh or vw has the larger size*
* As of Jan 2017, Microsoft Edge browser doesn’t support vmax, but you are safe to use vh/vw in all modern browsers
This bare bones experiment also deliberately puts the navigation elements at the bottom of the page on mobile—in theory closer to the users thumb. This was sparked from a discussion at the studio this week over mobile menus. The ubiquitous hamburger menu feels increasingly unwieldy UX as we become more attached to our mobile devices, especially phones. The thumb reach from the bottom of an iPhone 7 Plus to the top right corner (traditionally where the burger menu resides) is a stretch for me. A struggle for folks with smaller hands, which could results in phone-fumble annoyance. There are solutions—more app-like behaviour (think iOS apps, icon bars), tile menus, InstaGram style slide-in/out menus to name a few—but there’s the risk of user confusion. People are used to burger menus, even if they don’t have the most elegant UX. Food for thought (hmm, burgers).
Here’s a rehash of an experiment I did a while back with responsive tables. The goal is to make style a table ‘truly’ mobile first, while maintaining semantic HTML.
The initial demo was using min-width to handle the breakpoint which resulted in overly complicated CSS. This second demo reworks the CSS to use a max-width based breakpoint instead. It allows the table to naturally return to a table-like layout after the breakpoint is hit.