Responsive text or truncated text in Mobile devices?

Three big issues when you're considering how to deal with content on mobile devices, especially if you're trying to figure out how to re-prioritize content for different screen sizes or device capabilities. I've been calling this adaptive content, as a partner to adaptive design or responsive design.

1. How is the content written? Truncation might work... if the content is written to put compelling and important information in the first sentence. Web writers are often guilty of "burying the lede," hiding the useful information deep in the content. If you can't be confident that the first sentence or so will provide enough context and value to inform the user, then truncation is not an acceptable content strate...
2. How is the content structured? The idea that you might hide content on mobile devices is an interesting technical demo—but when I look at it all I can think about is what's happening in the CMS. Writers would need a way to specify which text is important and which can be hidden. They'd also have to write the text so it reads well for all formats.
3. Does the CMS support it? Many businesses will run into problems with their existing Web CMS needing to support a variety of mobile devices. Can they implement different fields and metadata to support the writers in specifying different priorities? Will the CMS support publishing text using a "progressive enhancement" model, or will the mobile user need to download all the text? In many cases, getting this right will require significant changes to the CMS.

I believe that the best way to support mobile devices is to rewrite content so it's shorter, better-written, less filled with jargon and fluff. It will also require putting more structure into content, writing flexible chunks that are designed for reuse. Doing this will create a good experience for mobile users—and for desktop users too.

In her presentation at An Event Apart in Washington DC 2011 Karen McGrane discussed the need for structured content in Web sites. Following this there were lots of amusing tweets and retweets on twitter of the form:

Luke Wrobleski wrote up some notes on her talk in which he says:

This is not a technology problem. It’s a strategy problem.

Amongst 'solutions' he lists (from Karen's talk still):

• Write for the chunk, not for the page. Truncation is not a content strategy. Don’t just chop content off to make it fit onto small screens. There is a war between blobs and chunks. We can’t let the blobs win.

• Demystify metadata. Metadata allows us to programmatically assemble content in appropriate ways (for different devices, etc.)

• Metadata helps prioritize content and eventually personalize it. But you need human judgment to decide what actually matters. Automated pages are not smart enough on their own.

• Better CMS workflow. Content administrators hate the input fields in content management systems but they are just a symptom of bad workflow. We have to stop making checklists for deciding on CMSs.

• We need to look at the workflows for content creators instead. We need to make sure the workflow is streamlined, the system is usable, and creating structured content is easy. A prettier font and better tabs are all great. But we need to look at the design of the workflow. Apply the same principles and techniques we use to design Websites to design our CMS systems.

• Use mobile as a wedge. We have a huge opportunity to take a step back and figure how content publishing practices can be rethought to set ourselves up for future success. This will allow us to make it onto new platforms.

• The more structure you put into content, the freer it will become.

• We have to separate content from display (for real this time).

• We need to capture content in a clean, presentation-independent way.

• We need ongoing conversations about structured content.

So essentially what is being said that we should rethink our content strategy to allow it to be relevant for different target devices.

I doubt there's a problem with 'more' links if relevant so that users can see there is a more detailed version of the content available. That fuller content can be provided in a more suitable reading environment perhaps (similar to Kindle for Android perhaps), but simple truncation of the full content is not the correct answer.

Truncation rarely provides a useful standalone chunk and almost forces the user to hit 'more' where as more often than not, a well formed shorter chunk might actually be enough to get the message across to the extent that (especially a mobile) user needs.

Data transfer

JonW raised the topic of data transfer: A well structured content hierarchy might be able to push/pull only the right size chunk for the device, whereas truncation typically requires the full text and for the truncation to happen client-side depending on the space available to display on the given device.

On this note (although I think we are more concerned with text in this question) embedded images alongside the text can also be sized correctly and appropriately for the chunk - or removed altogether - I'm not a fan of the responsive methodology for resizing images, since it does indeed download the larger image and scale accordingly (since scaling up looks ghastly).