Both Sketch & Figma have support for using component libraries, but the experience of using them feels far less central to the design process than they need to be. Finding and using a component in a library is how I think 90% of design work should begin. Right now, the discoverability of components, and the lack of support for including rich documentation which explains how and when to use a component place a barrier between a designer, and the systems created to make them efficient.
Knowing from CSS how easy it can be to inherit a property and reuse classes, I find the management of symbols (with all of that nesting) to be cumbersome. The design tools we have maximise for flexibility and freedom of the designer. I would gladly sacrifice some of that in favour of a better awareness of the conventions of the medium I’m designing for (breakpoints, flex, grid behaviour, box model, etc.).
In most cases, what makes the most sense is to move as quickly as possible to the browser: pixel perfect designs are never going to be of much value, as they’re always just a stepping stone to get elsewhere. Treat them as you treat documentation and other assets.
A Sketch library—or any collected drawings of software—can be a canonical UI reference only when the design is first conceived. Once the design gets into code, the product itself should be the reference, and fresh design should work on top of that foundation. It’s more important that our design libraries reflect what’s in the code than the reverse. Production code—and the UI it generates—has to be the single source of truth, or madness ensues.
Audio editing using text. You can remove filler words (uhm, ehm) automatically but, most impressive, you can change what you said by editing the transcription: the app will update the recording by generating a digital voice that sounds like you.
This sounds like a saner way to handle privacy settings than having a banner on every single website (security UI doesn’t work).
A reminder that the best emails are plain text and nothing else. Not only they read well on any screen (even on a watch), they actually perform better:
The plain email—which took no time to design or code—was opened by more recipients and had 3.3x more clicks than the designed email. The plain, unstyled emails resulted in more opens, clicks, replies, and conversions, every time. […] Replies to welcome emails were tripled. Cold emails were getting 30-35% open rates and 3% conversion rates, which is incredible.
Besides, every HTML email looks like an ad.
Some insights on voice interfaces from Ian Bicking:
Voice interfaces are voice interfaces. They are a way for the user to express their desire, using patterns that might be skeuomorphism of regular voice interactions, or might be specific learned behaviors. It’s not a conversation. You aren’t talking with the computer.
I’ve been speaking with Alexa for quite some time now — we like to talk about the status of the lights in the living room and which is the most suitable time for me to wake up.
Also very true:
I hate how voice interfaces force us to speak without pauses because a pause is treated as the end of the statement. Many systems use a “wakeword” or “keyword spotting” to start the interaction. What if we used keyword spotting to determine the end as well? “Please” might be a good choice. It’s like the Enter key.
Sean Martell, designer at Mozilla, goes through some of the FireFox related projects he got to work on at Mozilla over the last 14 years.
I kind of hate messaging these days.
Over the years different software have imposed on their users FOMO inducing features that lead us to this ridiculous reality in which we all collectively agreed that a response to a text needs to be returned within minutes, no matter the content nor the urgency.
I sometimes choose emails over texts for this reason. I know — I am weird. BUT! Expectations are different with emails. We read less into it if someone takes a day or longer to get back to us (even though some people are trying to make emails obnoxious too).
The online status (last seen at), the typing indicator (is typing), and — worst of all — read receipts somehow ended up being our default, with all which that entails (mostly anxiety). It’s all working exactly as we designed it, as in: it’s all quite shitty:
Privacy remains one of the big and unresolved issues in our industry and while we often worry about data leaks and agonize over how much companies know about us, we often forget that it’s the small and barely noticeable losses of end-to-end user privacy that affect us socially the most. And while turning every privacy related decision into a setting might be enticing, it’s ultimately shortsighted. Designers are well aware that most users won’t bother changing a default. And the act of changing a default ironically always inadvertently reveals something about users, whether they want or not.
So what does a future that respects people’s micro-privacy feel like?
It’s knowing you can go online without having to fear what our online status may reveal about you. It’s about liking someone’s photo without the anxiety of being called out for it. And above anything, it’s about reading a message, without feeling guilty of not sending an immediate response.
A web typography learning game