Olga Vasileva, writing at Diff (a blog ran by the WIkimedia volunteer community) about the new look that’s coming to Wikipedia, and also why they’re making the changes now:
Wikipedia has remained a critical and widely-used resource for knowledge across the world for the past two decades. Over this time, the site has expanded significantly to contain unparalleled amounts of reliable and thorough information, including 53 million articles across over 300 languages. While Wikipedia’s content has grown rapidly, our interface has not kept pace. We’re proud that our website is more direct, simple, and advertisement-free than the rest of the internet. Yet, the design of desktop Wikipedia and other Wikimedia Foundation projects have not seen any substantive changes for the past 10 years, leaving certain elements of the site’s navigation feeling clunky and overwhelming to readers and editors whose main purpose is to create, learn, and curate content.
There’s no definitive list yet on the differences that will be coming in the new design. But the improvements will include things like a max content width, collapsible sidebar, sticky headers, more prominent search bar and table of contents, and a few other things. You can see a few of these concepts on MediaWiki.
I just came across a really fun and interactive case study about HEY Email. It’s basically a run through of the user onboarding with an eye on the UX.
After going through the case study, it certainly isn’t a perfect experience. But I still feel like I need to check out HEY at some point. Even just to see what everyone is on about. Although I do already get the feeling that while I may like the idea, it’s not done in the right way for me.
These are of course preemptive, but I’ve got three reasons why I probably won’t like HEY:
- There’s currently no support for custom domains. So I’d be stuck with another email address.
- You have to use their own email clients. Which may be fine at the start, but I can’t imagine I’ll be wanting to use the HEY email client for the rest of my life.
- I’m not sure how I feel about paying for an email service. Especially as everything is so closed down. If I go all in on HEY, then after a year I decide to quit, then I’ve got to go through the process of switching everything to a new address.
Check out the case study on Growth.design
Jonathan Hoefler, on the problem with panoramas when proofing fonts:
In years past, our proofs were full of pangrammatic foxes and lynxes and the rest, which made for some very merry reading. But invariably, I’d find myself staring down a lowercase J — and if I questioned the amount of space assigned to its left side, I’d set off in search of some confirmation in the proof. Each time, I’d be reminded that while pangrams delivered all kinds of jocks and japes and jutes and judges, even our prodigious list featured not a single word with a J in the middle. I also started to notice that Xs had an unusually strong affinity for Ys in pangrams, because pangrams make a sport of concision. Words like foxy and oxygen deliver real bang for your buck if you’re out to craft a compact sentence, but to the typeface designer noticing that the pair XY looks consistently wrong, none of these words will reveal which letter is at fault. I’d find myself rewriting the pangrams, popping in an occasional ‘doxology’ to see if the X was balanced between round letters, or ‘dynamo’ to review the Y between flat ones.
It’s an interesting problem, and one I can’t say I’ve ever thought about. But it makes sense that when proofing a font, you’d want to be able to capture a high majority of scenarios, not just a few good looking panoramas that probably aren’t similar to what a real sentence would look like.
However, Jonathan has come up with a proof that tackles things such as the spacing between different types of letters, how each letter looks at the start of a word, what double letters look like, and most likely more things that I won’t understand. Font proofing is certainly nothing I’ve considered before, but I always find it intriguing to see how people identify problems, and especially how they come up with a better solution.
Ralf Herrmann, writing at Typography.Guru:
Apple has recently licensed fonts from type foundries such as Commercial Type, Klim Type Foundry and Mark Simonson Studio to be used as system fonts on Mac OS Catalina. But since these fonts are an optional download, many users of Mac OS X are not even aware they have access to them for free.
To see and install these optional fonts, open the FontBook application and switch to “All Fonts”. Browse the font list and you will see lots of font families that are greyed out—either because they were deactivated or they weren’t downloaded yet. If you right-click on a font or font family that wasn’t downloaded yet, you see an option to download the individual font or entire family.
Who would have thought there was essentially “hidden” fonts in Catalina? I certainly wouldn’t.
Well, there’s tons. And it includes some pretty nice ones as well, such as Domaine Display, Canela, Proxima Nova, Graphik, and Produkt.
Matthew Butterick, on the use of ligatures:
Ligatures in programming fonts—a misguided trend I was hoping would collapse under its own illogic. But it persists. Let me save you some time—
Ligatures in programming fonts are a terrible idea.
And not because I’m a purist or a grump. (Some days, but not today.) Programming code has special semantic considerations. Ligatures in programming fonts are likely to either misrepresent the meaning of the code, or cause miscues among readers. So in the end, even if they’re cute, the risk of error isn’t worth it.
His post certainly opened my mind up to the problems with ligatures in a programming font. It actually made me switch away from the new monospaced typeface from JetBrains, simply because of its use of ligatures, 138 code-specific ligatures to be exact.
Back to SF Mono it is.
(via Daring Fireball)
Theo Strauss, writing about Lyft’s new implementation of the search bar, and why its best placed at the bottom:
Although we don’t think about it too often, a search bar all the way at the top of the screen is hard to reach. Especially for users who have smaller hands or users who have less flexible hands, reaching up is annoying, mostly because the top of the screen is far away from where their fingers sit.
If you visualize most apps, the main content is in the middle or lower-mid area. Tab bars for navigation, posts on social media, and keyboards on messaging platforms are all examples of important pieces of experiences sitting in a more reachable position.
I feel exactly the same. The ability to search within an app, or just accessing the main navigational controls of an app, should be the most accessible parts.
In a world where we use tools such as a mouse, or laptop trackpad to direct a cursor around a screen, a classic vertical layout where all navigation is at the top, and the content filling the rest of the space, is probably fine.
However nowadays we interact with content on our displays directly, so it needs to be designed with a human hand in mind, not a cursor.
You can already see Apple pushing developers/designers towards this bottom-up approach, as they’ve added the “pull up” drawer-like component that contains a search bar and results, into the Maps app. This is the approach I feel needs to be standardised going forward, but this isn’t the only approach. As the Music app also follows this idea of having controls at the bottom, with the now playing indicator being there.
I do see this becoming a trend very soon, and I suspect that in a few months quite a lot of apps will be using a sheet similar to the one in Apple Maps. The only drawback is that Apple don’t provide a standard implementation of this bottom sheet, and instead developers either have to implement this manually, or adopt a library from other third-party developers.
I’ve been experimenting with it at work, and I’ve found one library to be very useful, and that is PullUpController by Mario Iannotta. It provides you with a simple one liner to add any view to act as the bottom sheet, and also manages the sticky points, management of inner scrolling views and content, and you can also extend it to your wishes.
Hopefully Apple can share their implementation and more developers can make use of this new interface style.
Michael Descy has written a great piece about finding a writing font, and why it isn’t just a waste of time.
Choosing the perfect writing font is a classic way to procrastinate—but it is not a waste of time. Fonts are important. A good font is not only highly legible, it also conveys a subliminal emotional effect on the reader. Naturally, it follows that it will also have similar effects on the writer. A good font will make you feel better while you are writing—maybe because you can read it more easily, or because you find elements of it, its curves or serifs, aesthetically pleasing. Whatever the reason, picking a font that is pleasing can have a profound effect on your writing.
He goes into detail on what makes a good writing font, some considerations you will have to make, and also a bunch of great suggestions.
For myself personally, I’ve always used a monospace font to write with. I once saw someone write about it before, although I can’t remember the source, but they explained how they used monospace fonts while they were writing/editing, and a sans-serif for previews. This is similar to how I feel myself.
Because I write everything I do in Markdown, it still feels like I’m writing code, not a programming language, but still something that has to be deciphered before it’s fit to be seen by anyone else. And for some reason, monospace fonts use feel like they represent something that’s in progress.
So, the font I use for nearly everything is SF Mono. It’s the monospace version of Apple’s San Francisco font, and it’s been my favourite ever since they released it. However, it requires some fiddling to have it installed like a regular font. Before that I used the pretty similar, Andale Mono.
Page 1 of 1 pages