After almost two decades of avoiding Microsoft-based web products whenever possible, I’ve come full circle: the new Microsoft Edge is my browser of choice. It has excellent privacy options, a large extension community, and developer support that makes it a reliable option on macOS over Chrome, Firefox, and Safari.
Admittedly, when I first started using the new Chromium-based Edge a few months ago, I was skeptical about its potential. Microsoft’s Internet Explorer left a bad taste in my mouth, thanks to the struggles I had developing against IE6 and IE7 in the early 2000s. But the more time I spent with this fresh iteration of Edge, the more I was left impressed.
For engineers building user interfaces, I find there’s heavy emphasis on technical chops and little to none on design comprehension. Yet a subset of design skills can distinguish great from merely good UI engineers.
I’d term these skills “pre-visualization”: understanding design specifications before writing any code, and at a level beyond what designers formally deliver. A big part of pre-visualization is the ability to break down specs into reusable components. You discern visual patterns from existing parts of your app, site, or larger OS, and apply them to a designer’s work. In many, if not most cases, much of the spec maps cleanly to what came before. Common UI patterns like buttons, form elements, and navigation generally repeat themselves. Some will not.
To become a better web UI engineer, study design, communication, and vocabulary. Even if you cut back on some extra technical training, it’s worth it. That’s because the difference between good and great UI work rarely comes from technical prowess alone. It’s distinguished by creativity, visual insight, and sound organization.
Yes, JavaScript and styling fundamentals are important. You need to understand the tech behind your craft. But the solution to a tech blocker can be a tool or coworker away. And once you learn the basics of one MVC JS framework or CSS coding methodology, you can learn another.
Reusability is a bigger issue. Every time you change styling or write a new UI element, consider its impact elsewhere. Think ahead to where the application will grow and how you can cut repetition. It’s more than an blind grep through the code. It’s finding patterns. And visual patterns or usage trends are especially tricky to detect.
Flexbox is a powerful web styling tool, one my favorite recent CSS additions. It’s an effective replacement for hacky, float-heavy layouts. Given its wide browser support and mature feature set, I lean on Flexbox for most project work.
However, I’m surprised many developers stay away from Flexbox. They’re worried about browser support, a big learning curve, or otherwise strange behavior. They shouldn’t. Here’s how to get started.
Inefficient web styling slows performance, adds inconsistencies, and harms developer and designer productivity. But many teams don’t prioritize CSS tech debt; gains are subtle and hard to measure. And CSS testing suites aren’t as robust as those for JavaScript, Rails, and other web languages.
Yet the effort necessary to keep web styling lean and efficient is overblown. The key is abstracting page level styling into reusable components.
Components are distinct groups of elements on a page. Common examples include navigation bars, carousels, and form sets. Components should be standalone, easily moved to different pages without breaking layout. Some styling methodologies substitute other terminology for components, calling them modules or blocks. And the size and scope of component usage differs widely among projects. Large projects, given their size and scope, tend to rely more on components than smaller works.
Web styling advances at a ferocious rate. Vanilla CSS is a rarity. Almost every web presence relies on new frameworks, preprocessors, and workflows. Yet even in the midst of progress, the fundamentals often trip up our work.
Our CSS fights against the natural DOM (Document Object Model) flow. The DOM flows from left to right, and from top to bottom. Block elements expand as wide as possible within a bounding container. Elements grow only as tall as absolutely necessary. The more we resist this flow, the more likely things break.
To avoid this, I follow three rules. Whenever my layout feels janky or otherwise hard to debug, it’s usually because I’ve strayed off course from these guidelines.
I could recommend this post to almost any designer who works with front end web developers. It’s surprising how many designers I’ve worked through over my career that have little knowledge of what’s mentioned here, especially this:
It is the nature of the web to be flexible, and with this flexibility comes a degree of letting go of control. The first step in this process is to leave behind the idea of pixel perfection.
As a publishing platform, the web is on hard times. Paywalls and subscription plans are rarely successful. That makes ads and trackers the primary source of revenue. Yet ad tech is usually poorly designed, intrusive and inefficient. It slows down pages and pisses off users. That’s been underlined in recent articles highlighting the performance of The Verge , iMore and others. An otherwise simple news post bloats into megabytes of data, with ads and trackers taking the overwhelming share of that weight.
In the face of web bloat, users are opting out. Many strip out ad and tracker content with tools like AdBlock and Ghostery. Or they abandon the web for faster native publishing platforms like Facebook’s Instant News and Snapchat. Along these lines, Vox’s Ezra Klein predicts publishers morphing into a wire service, where the web becomes just one of many content platforms to publish on. Large publishers like Buzzfeed and The New York Times have already moved in this direction.
This is concerning. In reality, the web can be performant with ads, a subject matter for another post. A weakened web presence makes for an ugly future for publishing. It hurts the publishers themselves, and us, as readers.
Jeremy Keith on The Verge and the recent debate over who’s to blame for heavy, ad and tracking infested web pages:
For such a young, supposedly-innovative industry, I’m often amazed at what people choose to treat as immovable, unchangeable, carved-in-stone issues. Bloated, invasive ad tracking isn’t a law of nature. It’s a choice. We can choose to change.
Every bloated advertising and tracking script on a website was added by a person. What if that person refused? I guess that person would be fired and another person would be told to add the script. What if that person refused? What if we had a web developer picket line that we collectively refused to cross?
That’s an unrealistic, drastic suggestion. But the way that the web is being destroyed by our collective culpability calls for drastic measures.
Joel Johnson, writing for Fast Company on Apple News and other related publishing consolidation:
For publishers, Apple News and Facebook Instant Articles are simply another revenue stream that puts content where the audience has chosen to be…For readers, assaulted by bad advertising, these curated feeds could be a better—or at least universally banal—way to consume words and images. But it is unclear if most publications will be able to survive on only the revenue granted by these platform companies alone, and it feels incredibly aggressive for Apple to openly state that it—or at least some of its developers—have decided that advertising is always unwelcome, unless it happens to be advertising that Apple itself lords over.
This is exactly one of the major concerns I have with Apple News. Strong consolidation of media under a monolithic company like Apple generally doesn’t bode well for journalism and publishing in the long run.