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.
A cogent definition and spirited defence of progressive enhancement:
Progressive Enhancement is an extension of our shared values on the web and goes to the root of the web. I believe—and hope you agree—that the web is for everybody and should be accessible regardless of the device a user brings to the party.
Trent proposes a way to avoid implementing dark patterns: take a leaf from the progressive enhancement playbook and assume the worst conditions for your user’s context.
Jason pulls together some of the themes that emerged at An Event Apart DC this week.
A couple of years ago, the benefits of separate sites were more clear to me. Today, I can’t think of a good reason to maintain a separate mobile site.
A really lovely piece on the repositories of information that aren’t catalogued—a fourth quadrant in the Rumsfeldian taxonomy, these dark archives are the unknown knowns.
What Dan said.
I share Tom’s frustration with news apps that should be websites:
I wouldn’t download a BBC app or an NPR app for my computer. Why would I want one on my phone?
Mark gets to the heart of the issue with making responsive designs work with legacy Content Management Systems …or, more accurately, Web Publishing Tools. There’s a difference. A very important difference.
Bruce’s thoughts on the proposed inclusion of a “content” or “maincontent” element in HTML5.
Personally, I don’t think there’s much point in adding a new element when there’s an existing attribute (role=”main”) that does exactly the same thing.
Also, I don’t see much point in adding an element that can only be used once and only once in a document. However, if a “content” or “maincontent” element could be used inside any sectioning content (section, article, nav, aside), then I could see it being far more useful.
Maybe HyperCard is an idea whose time has come. Think about it: the size of mobile screens: perfect for a HyperCard stack.
This is an important subject (and one very close to my heart) so I’m very glad to see these data protection guidelines nailed to the wall of the web over at Contents Magazine.
- Treat our data like it matters.
- No upload without download.
- If you close a system, support data rescue.
Remember when I linked to the story of Twitter’s recent redesign of their mobile site and I said it would be great to see it progressively enhanced up to the desktop version? Well, here’s a case study that does just that.