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.
We’ll tell you what you really want: Mobile context, top tasks, and organization-centric thinking | Sara Wachter-Boettcher, Content Strategist
An excellent follow-up to the recent posts on the myth of mobile context.
You often hear about cutting content to cut clutter. I support this—if you’re cutting the clutter from everywhere, not just a mobile experience.
Maybe the answer isn’t cutting. Maybe it’s learning better skills for designing and structuring complex information to be usable and enjoyable in small spaces.
How about this for a trip down memory lane—a compendium of articles from over a decade of A List Apart, also available as a Readlist epub. It’s quite amazing just how good this free resource is.
The only thing to fault is that, due to some kind of clerical error, one of my articles has somehow found its way onto this list.
If this were Twitter, you’d be at-replying me with the hashtag “humblebrag”, wouldn’t you?
Yes, yes, yes! Karen drives home the difference between mobile and local (and there’s more about the myth of the mobile context).
If you’re making an argument for delivering different content to mobile users, or prioritizing content differently based on their context of use, stop for a minute and ask yourself if you mean local content. And if you do mean local content, then say that. Claiming that your travel example extends to cover the “mobile use case” leaves out millions of tasks and users.
Just to belabor this point: people use mobile devices in every location, in every context. Just because you know what type of device someone is using or where she is doesn’t tell you anything about her intention.
A really great article from Stephen on how we are mistakenly making assumptions about what users want. He means it, man!
A great article by Karen pointing to the real problem with the mobile strategies of so many companies: they are locked in by their CMS.
A great step-by-step tutorial from Brad on developing a responsive site with a Content First mindset.
Josh responds to Jakob Nielsen’s audaciously ignorant advice on siloing mobile devices. Josh is right.
Nielsen says his research is based on studies of hundreds of mobile experiences, and I don’t doubt it. But because he’s finding tons of poor mobile websites doesn’t mean we should punt on creating great, full-featured mobile experiences.
Andy points one of the potential pitfalls in linearising your content for small screens.
Yet another great post from Brad:
Whenever I think of the concept of “One Web” and providing universal access to information on the web, I tend to break it down into something much simpler: give people what they ask for.
An excellent piece by Stephanie on how to approach print stylesheets. I’ve always maintained that Print First can be as valid as Mobile First in getting you to focus on what content really matters.
A great article from Sara Wachter-Boettcher on crafting future-friendly content. The content prioritisation described here mirrors what I’ve been doing in workshops.
A rallying cry for a content-focused—rather than device-focused—approach to responsive design. Despite the awful title and occasionally adversarial tone, this article is making a very good point about being future friendly.
Some clarifying thoughts from Mark: “content first” doesn’t have to literally mean having the final content first …but it does mean knowing the structure of the content.
A great round-up of links and posts relating to the increasingly-important role of content strategy and structured content in our multi-device, responsively-designed online world.
Mandy’s inaugural article for Contents Magazine is a wonderful piece of thinking and writing.
Enjoy reading this.
Mark continues to hammer home the most important thing to keep in mind when creating responsive designs: design from the content out, not the canvas in.
A PDF of the slides (with copious notes) from Josh’s brilliant presentation. I love this guy!
Josh nails it: publishers need to stop thinking in terms of issues:
Publishers and designers have to start thinking about content at a more atomic level, not in aggregated issues. That’s how we already understand news as consumers, and we have to start thinking that way as publishers, too. This is why Flipboard, Instapaper, and other aggregators are so interesting: they give you one container for the whole universe of content, unbound to any one publisher.
An insight into Elliot’s current design process which highlights the advantages of designing in the browser when you take a content-first approach.
In this interview Mark discusses the “content out” rather than “canvas in” thinking that informs his new canon.
A brave attempt to explain the new outline algorithm in HTML (although it inaccurately states that no browsers have support for it—Firefox shipped with it a while back).
You can safely skip the comments: most of them are discouraging, ignorant, and frankly, just plain stupid.
The importance of structured content for longevity and responsiveness.
I agree 100% with Mark’s thoughts on what a Content Management System should and shouldn’t attempt to do.
I think that markup is too important to be left in the hands of the people who make content management systems. They all too often don’t care enough about it, and they can never know the context that you will be using it in, and so in my opinion they shouldn’t be trying to guess.
A wonderful post by Trent Walton on the thinking and workflows we can employ with responsive design. So many opportunities!
Web designers will have to look beyond the layout in front of them to envision how its elements will reflow & lockup at various widths while maintaining form & hierarchy. Media queries can be used to do more than patch broken layouts: with proper planning, we can begin to choreograph content proportional to screen size, serving the best possible experience at any width.
Steph Hay takes a look at how websites can allow a narrative to unfold, with the Ben The Bodyguard site as a case study.
A nice round-up of responsible responsive web design techniques, ‘though I would go a bit further and suggest that the rallying cry is not so much about Mobile First but Content First.
Once again the importance of a Content First approach to responsive design is made clear:
What responsive technique do we use? Whatever suits the content best.
Tom Phippen points to an excellent real-world example of a print layout that’s superior to the desktop version.
A great piece about the changing nature of content ownership and distribution. And now I share it with you, validating its central premise.
Aaaaaand once again, the Riegers show us the way. This time it’s Stephanie’s presentation at Breaking Development in Dallas. Bloody brilliant.
An excellent statement of intent from Mark. You can either read this now and start creating websites the right way, or you can scrabble to catch up further down the line; I recommend reading this now.
Embrace the fluidity of the web. Design layouts and systems that can cope to whatever environment they may find themselves in. But the only way we can do any of this is to shed ways of thinking that have been shackles around our necks. They’re holding us back.
Start designing from the content out, rather than the canvas in.
Could it be that the current penchant for quick, real-time bursts of content could actually be beneficial for more thoughtful, long-form content?
Edit this page. Then view source.
Erin is writing about content strategy for A Book Apart. This is good news for everyone.
A detailed look at traditional and digital publishing, considered from the content out.
If there's an RSS you think Ryan should know about, you can tell him here.
I love this article by Amber Simmons. The truth shines through.
Derek hits the nail on the head. User-generated content is such a cold, cold term.
An interesting take on the recent round of acquisitions by Yahoo.
You can now create podcasts on Odeo. This is going to be huge.