It really, really bothers me that wireframes have evolved from being a prioritisation tool into a layout tool (disempowering UI designers in the process), so I’m happy to see an alternative like this—somewhat like Dan Brown’s Page Description Diagrams.
A really deep dive into
display: contents from Ire.
I write to understand and remember. Sometimes that will be interesting to others, often it won’t be.
But it’s going to happen. Here, on my own site.
The latest video from Patterns Day is up—Ellen’s superb philosophical presentation: Patterns in Language, Language in Patterns.
There’s so much packed into this one, it might take more than one viewing to take it all in.
A transcript of the superb talk that Ellen delivered at Patterns Day. So good!
This is an excellent proposal from Emil. If we can apply
display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
If we describe patterns also in terms of content, context, and contrast, we are able to define more precisely what a specific pattern is all about, what its role within a design system is, and how it is defined and shaped by its environment.
Ellen goes through the principles behind the tone of voice on the new Clearleft site:
- Our clients are the heroes and heroines, we facilitate their journey.
- Speak as an individual doing whatever it is you love. Expose lovable details.
- Use the imperative, kill the “-ing”.
- Be evocative and paint the picture. Show don’t tell.
- Be a practical friend.
- Be inquisitive. Ask smart questions that need solving.
Here’s a nice little service from Remy that works sorta like Readability. Pass it a URL in a query string and it will generate a version without all the cruft around the content.
Everything that happens to the content prototype from now on is merely progressive enhancement. Because while the prototype is in a shared git repository, microcopy sneaks in, text gets corrected by a copywriter, photos change for the better and flows shape up, meta data is added, semantics are double checked, WAI-ARIA roles get in…
Mandy is fighting the good fight for the open web from within Vox Media. Her publishing tools have been built with a secret weapon…
This practice — which I refer to unoriginally as progressively enhanced storytelling — also has the added benefit of helping us make our content more accessible to more kinds of users, especially those with disabilities.
I’ve seen the exact problem that Rachel describes here—flexbox only applied to direct children, meaning the markup would have to be adjusted.
display: contents looks like a nifty solution.
A really terrific article from Dan on building pattern libraries. In summary:
- Naming things is hard,
- Separation of content and presentation is A Good Thing.
There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:
When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.
(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)
A really handy command-line tool that scans your site for mixed content — very useful if you’re making the switch from http to https.
A look behind the scenes of gov.uk. I like their attitude to Photoshop comps:
We don’t want a culture of designs being “thrown over a wall” to a dev team. We don’t make “high fidelity mock ups” or “high fidelity wireframes”. We’re making a Thing, not pictures of a Thing.
We don’t have a UX Team. If the problem with your service is that the servers are slow and the UX Team can’t change that, then they aren’t in control of the user experience and they shouldn’t be called the user experience team.
The transcript of Mark’s talk from last week’s Handheld conference in Cardiff.
There are mountains.
I agree completely with the sentiment of this article (although the title is perhaps a bit overblown): you shouldn’t need a separate API—that’s what you’re existing URL structure should be.
I’m not entirely sure that content negotiation is the best way to go when it comes to serving up different representations: there’s a real value in being able to paste a URL into a browser window to get back a JSON or XML representation of a resource.
But this is spot-on about the ludicrous over-engineered complexity of most APIs. It’s ridiculous that I can enter a URL into a browser window to get an HTML representation of my latest tweets, but I have to sign up for an API key and jump through OAuth hoops, and agree to display the results in a specific way if I want to get a JSON representation of the same content. Ludicrous!
The title is a bit sensationalist but I agree completely with what Karen is saying:
It’s time we acknowledged that every responsive web design project is also a content strategy project.