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).
