Web Standards

An Event Apart: Scenario-Driven Design Systems

LukeW - Sun, 04/01/2018 - 2:00pm

In her Scenario-Driven Design Systems presentation at An Event Apart in Seattle, Yesenia Perez-Cruz shared lessons learned building design systems for multiple brands/Web sites and how specific user-scenarios are key to making flexible solutions. Here's my notes from her talk:

  • Design systems have helped many organizations build better, more cohesive experiences faster. but what's really behind a design system? is it a set of components? a common language? or something more?
  • A good design system feels cohesive, unified, and connected. It achieves something.
  • Bad design systems fail when there's too much focus on elements and not enough focus on how common components work together to create an experience.
  • We need to start our design systems with user-scenarios, not with individual components.
Starting with Elements
  • Vox wanted a design systema nd common platform for their 8 brands and 350+ Web sites. They made a lot of assumptions in the beginning that didn't work. Primarily: a set of flexible, brand-agnostic modules with a theming system would give them the most range. Essentially, legos.
  • This approach was too focused on layout and the end result was that each of the sites felt too similar. Critical content and focus differences were missing. The end result did not not allow Vox to tell better stories faster, as it only defined common modules not ways to solve common user problems.
  • Vox learned they needed to start with something specific in order to develop a flexible system. You can’t start with individual components because successful design patterns don’t exist in a vacuum.
Starting with Purpose
  • The next iteration of Vox's design system started with people and content. What goals did the audience have? What range of content and tone needed to be supported? What was the editorial workflow of the people making content?
  • This requires user-scenarios driving design not hypothetical situations. We need to ground our design systems in tasks people and companies actually have not trying to account for "what if" ideas.
  • Instead of starting with an inventory of UI components, start with an inventory of core workflows/tasks, and then identify common patterns in these workflows. All patterns should solve a specific problem.
  • Identify core workflows and the patterns that need to support these workflows. Understand the role each pattern plays in a user’s journey. Define how the patterns work together to create a cohesive experience.
  • Thinking and organizing a design system in terms of workflows, makes it easier for teams to know which patterns to apply when faced with a user problem.
  • At Vox, a scenario-based design system allowed the team to turn 18 distinct templates into a unified structure. They identified common audience goals but supported variants driven by differences in content.
Supporting Variants
  • Variants can help components address specific user-scenarios by highlighting specific content that matters to audience goals. These content-specific components can be re-used across themes/brands.
  • Scenario-driven variations can help brands feel unique/deliberate vs. becoming too generic/unspecific.
  • Naming elements very specifically helps people agree on their function. This ensures each element supports the right level of customization & functionality.
  • How do we theme a design system? Brands need to support distinct visual designs that support the unique audience and content within a site.
  • When varying fonts across brands, you need a flexible type scale to ensure legibility across different font faces. Similarly, color variables can be used to manage different colors schemes across brands.
  • When should you support variations in your design system? Only add a layout if there’s a content need. Does it add value? Is it available to more than 3 brands? Is it a must-have for 1 brand?
  • When are variations in your design system a bad thing? Visual variation on components that serve the same function across brands and/or don’t do much to strengthen brand voice.
Finding a Balance
  • There's a constant push/pull between appropriate levels of consistency and customization. Finding the right middle ground is a constant process of iteration.
  • Successful design patterns don't exist in a vacuum. Instead of focusing on individual components, look at the ecosystem: the people, content, and complete design. Successful design systems solve specific problems and start with people & content.

w descriptors and sizes: Under the hood

Css Tricks - Sun, 04/01/2018 - 3:23am

Eric Portis digs into how the browser decides which image to downloads when you give it <img srcset="" sizes"">. Notably, a browser can do whatever it wants:

Intentionally un-specified behavior lets browsers provide innovative answers to an open-ended question.

Still, calculations happens based on what you give it and you can still do a good job with that part.

The very weirdest part about all this is that the sizes attribute can alter an images "natural width", which can lead to unexpected upscaling, a thing we're trained to loathe. If you're in that situation, you can either...

  • use an inline width attribute
  • set an inline style with a max-width
  • embrace the fact you might experience occassinal upscaling

Direct Link to ArticlePermalink

The post w descriptors and sizes: Under the hood appeared first on CSS-Tricks.

A DevTools for Designers

Css Tricks - Sat, 03/31/2018 - 3:39am

There has long been an unfortunate disconnect between visual design for the web and web design and development. We're over here designing pictures of websites, not websites - so the sentiment goes.

A.J. Kandy puts a point on all this. We're seeing a proliferation of design tools these days, all with their own leaps forward. Yet...

But, critically, the majority of them aren’t web-centric. None really integrate with a modern web development workflow, not without converters or plugins anyway; and their output is not websites, but clickable simulations of websites.

Still, these prototypes are, inevitably, one-way artifacts that have to be first analyzed by developers, then recreated in code.

That's just a part of what A.J. has to say, so I'd encourage you to read the whole thing.

Do y'all get Clearletter, the Clearleft newsletter? It's a good one. They made some connections here to nearly a decade of similar thinking:

I suspect the reason that nobody has knocked a solution out of the park is that it's a really hard problem to solve. There might not be a solution that is universally loved across lines. Like A.J., I hope it happens in the browser.

Direct Link to ArticlePermalink

The post A DevTools for Designers appeared first on CSS-Tricks.

Linkbait 39

QuirksBlog - Tue, 03/20/2018 - 1:31am

More like a link-late, but here it finally is.

  • Tim Kadlec takes a look at how fast AMP really is, spurred on by Ferdy Christiant’s research that we featured earlier. Tim concludes that the main performance benefit comes from AMP pages being served from Google’s CDN. Other than that AMP pages are mildly more performant than non-AMP pages, mostly because it arranges some optimizations and resource loading for you. The cost, however, is a slightly slower Start Render time, because the scripts that arrange all those optimizations and loading have to run before the AMP page is ready to be shown.

    Right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.

  • Steve Yegge shares his thoughts on the current state of Android. While Google still retains control over Android itself, it may be losing its grip on important auxiliaries:

    We’ve seen that there are at least three coordinated types of attack happening in different dimensions: The developer ecosystem (React Native and friends), the store (Amazon’s app store and Cyanogen’s rumored successor), and the lightweight in-app marketplaces (Facebook and WeChat, so far). Google’s reactions to each of these threats so far have been… well, let’s just say they’re still on top. For now.

    Does that matter? Yes, for tech shops it does.

    If you think there’s any risk at all that Google might lose control of Android, then your best bet is to use a cross-platform framework, because it hedges your bet via improved portability.

    React Native, in other words. If it can survive the current storm aimed against Facebook — but it probably can, because it can always be spun off.
  • Why I quit Google is an interesting article about self-defeating “objective” promotion criteria at Google.
  • Steve Faulkner clarifies how the HTML/CSS DOM, which can be changed by, among others, the flexbox order property, isn’t reflected in the browser’s accessibility tree. This is a reaction to last time’s discussion about CSS variable use for table sorting.
  • Chris Coyier shows how to make notched boxes in kind-of Battlestar Galactica style. Nice.
  • Excellent article on dealing with huge collections of DOM nodes — think tables with 1,000 rows. Vanilla JavaScript remains by far the best option performance-wise. Also, don’t bother optimising your core JavaScript loops and stuff — instead, optimise DOM handling. Clear DOM subtrees through innerHTML. On the other hand, don’t destroy nodes you may need later on — re-building them is way more expensive than keeping them around in memory.
    And no, this is nothing new. Ten years ago I would have given the same advice. But it’s good to know that the old rules are still being supported by the current data.
  • Food for thought:

    I’m beginning to think JS may be bifurcating into two largely disjoint communities. The “sw engineers” comfortable with pre-deployment tool chains and the “explorers” who want "live programming" tools

    I’m not 100% sure what Allen means by live programmers, and when I wanted to ask them I hit on my own definition and tweeted that instead.
    I think that the big split in JavaScript land is between those who firmly keep their eyes on browsers as our development platforms, and those who want to abstract away browsers.
    And yes, I think the first group is right and the second one is wrong, and that the second one will run into problems due to not understanding the platforms it’s creating software for.
  • This article calls the front-end/back-end division an antipattern. While I disagree with that premise, most of the article treats how back-enders look down on front-enders, and why that attitude should end — which is something I agree with.

    Frontend engineers now solve the same kinds of problems as their backend counterparts, using the same kinds of solutions, and it is harmful to continue arbitrarily dividing us.

    To be clear, I’m not saying that we all need to be experts in everything. [...] While it is perfectly valid to dislike a particular technology, such as CSS, the industry's culture of contempt for frontend work feeds into the outdated divide between frontend and backend, and detracts from building fast-moving, competitive teams and companies.

    Such as CSS. Thar’s a problem I’ll have to get back to one of these days.
    Pointing out that front-end can be as complex as back-end, and doing so in a back-ender-friendly way, is a good idea. Still, the article manages to ignore browsers as a developer platform entirely, despite the fact that mentioning them would have made its point even stronger. But maybe back-enders don’t want to hear about browsers because they’re terrified of them.
  • According to Tobie Langel contributing to OSS has ROI roughly equal to using OSS. Twenty years ago large companies were leery of using it; now they're leery of contributing to open source. So we have to convince them.
  • Insights and data, baby! The StackOverflow developer survey and the Design Census have been released. These surveys always yield interesting data.
  • Seems like an awful place to work for the health-unconscious such as myself.
  • Chronicles of Crime is a board game that incorporates an app, VR, and QR codes. Apps and VR have been done before in board games — the wonderful Alchemists was the poster child for apps in games — but as far as I know nobody yet combined them (i.e. let the app do more than just show VR), and nobody yet added QR codes, which are supposed to be a dying technology.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 38

QuirksBlog - Tue, 02/27/2018 - 6:16am

The missing links.

  • Elegant and simple solution by Mr. M. that shows breakpoint information during website development. So simple that it surprises me this isn’t being used widely yet.
    Emil Björklund adds a slight twist and a few notes.
  • VERY cute animated avatar. Simple, subtle, efficient animations FTW!
  • Excellent article about designing with grids. Not exactly a tutorial; more like a showcase of how to bring all those grid elements together to form a nice, and above all non-standard site design.
  • Lea has a new talk: an introduction to web development for CS students. It contains a JavaScript context quiz (I had only two errors), and highlights CSS Grid Garden, where you can learn grid, and a CSS Selector challenge with plates, bento boxes, apples, and more.
  • Good piece by Ronald Méndez on ALA about earning a seat at the table as a front-end engineer. His early steps mirror the ones I made about ten years earlier: the biggest change was me just sitting down with graphic designers to go over their work before showing it to clients. This worked amazingly, as Ronald also found.
    Anyway, worth a read if you feel under-appreciated as a web developer.
  • Stuart muses about collecting data, and shows that it’s possible to collect meaningful data without compromising individual users’ privacy. The trick is that users should lie. Not all the time, and not all the users, but you should ask a certain percentage of your users to lie.
    If, say, 10% of Chrome users say they use Firefox and 10% of Firefox users say they use Chrome, the aggregate browser use statistics remain roughly the same, but you cannot say with certainty which browser an individual is using.
  • Roman Koramov published a truly eye-opening use of CSS variables for making a sortable table. No JavaScript needed.
    Unfortunately, the technique causes accessibility issues because screen readers cannot follow CSS order — just DOM order. So they ignore the sorting.
    It seems to me we can invoke progressive enhancement for some problems. Table isn’t sorted? Pity; it works OK enough without being sorted. Patrick Lauke disagreed, but I feel he’s arguing strictly from a worst-case scenario.
    Anyway, make up your own mind — as long as you remember CSS variables are awesome.
  • Frank Chimero defines spaghetti toolchains. I wish I thought of that term.

    simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw

    [...] Last month, I had to install a package manager to install a package manager. That’s when I closed my laptop and slowly backed away from it. We’re a long way from the CSS Zen Garden where I started.

    If you go talk to a senior software developer, you’ll probably hear them complain about spaghetti code. [...] while I can’t identify spaghetti code as a designer, I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web.

  • Chris Coyier reacts to that article. He doesn’t exactly disagree, but points out that the web is a big place, and while some sites don’t need complexity, others do.

    Developers generally aren't asked to innovate on the business and product side. They build what they are told to, so they use their smarts to innovate on their own tools.


    We talk about complexity, but it's all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don't just break.

    What I’m afraid of, though, is that today a simple website is regarded as a sub-optimal solution. A website has to opt into everything the web has to offer, or ... well, I’m not sure why, but there must be a huge downside to not making it complex.
  • An inside look at Facebook in the 2016 campaign, and more in general the way it sells ads, with controversial ads getting a discount.

    The Trump and Clinton campaigns bid ruthlessly for the same online real estate in front of the same swing-state voters. But because Trump used provocative content to stoke social media buzz, and he was better able to drive likes, comments, and shares than Clinton, his bids received a boost from Facebook’s click model, effectively winning him more media for less money.

    No Russians necessary. The Russian involvement existed, but it was hyped up by the tech caste in order to show that technology was still magic, and was gratefully accepted by “moderate” right-wing voters wishing to be absolved from Trump — and possibly hardcore Clinton supporters wanting to shift blame away from her.
    As Matt Yglesias said:

    Given that Trump’s strongest support is among the least-online generation we should be a little skeptical of attributing anything to digital wizardry.

  • Jeremy continues last week’s AMP discussion with the fundamental question: should we countenance companies’ power over the web, even if they mostly use their power for good?

    One of my greatest fears for the web is that building it becomes the domain of a professional priesthood. Anything that raises the bar to writing some HTML or CSS makes me very worried. Usually it’s toolchains that make things more complex, but in this case the barrier to entry is being brought right into the browser itself.

    [...] some CSS will be off-limits until they meet the entry requirements of HTTPS …even though CSS and HTTPS have literally nothing to do with one another. [...]

    No doubt Mozilla (and the W3C Technical Architecture Group) believe that they are doing the right thing. [...] They believe that, in this particular case, the ends justify the means.

    I strongly disagree.

  • Interesting examples of AR by Luke Wroblewski.
  • Samsung puts on its first own web conference, Samsung Create. I approve of browser makers setting up their own conferences. It makes the engineers accessible to web developers, and allows both sides to find out what the other is thinking. Also, I approve of more browser vendors, since it helps diversity. Pity the conference is in San Francisco; let’s hope for a European edition. Also a pity there’s not much more information yet.
  • And Tomi gives us the definitive 2017 smartphone stats.
    1. Samsung
    2. BBK
    3. Apple
    WTF is BBK? Read the article; was new for me, too.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Wed, 12/31/1969 - 2:00pm
Syndicate content
©2003 - Present Akamai Design & Development.