Prompted by
my colleague by a question about
mobile with Tridion, I'm predicting what my (enterprise SDL Tridion-using) clients will be facing as they take on the challenge of SDL Tridion with their "mobile" sites. With some humor, parental anecdotes, and the not-quite-obvious we'll see the future will be interesting, unpredictable, and in some cases, already here.
First some background. SDL Tridion can handle already handle the content for any desktop, mobile, or tablet site you can come up with. You don't even need to change your BluePrint (much). Usually the question "what about mobile?" isn't about Tridion, it's about what you want to do. But that's primarily a problem with strategy and business needs. From a CMS perspective, Tridion Strategist Manuel Garrido describes the key decision are what you'd like to re-use in terms of content, functionality, and structure.
The Web design community considered the
difference between a focus between devices and features two years ago but the W3C was already promoting
One Web back in 2008 with
Mobile Web Best Practices. The Responsive Design term was born out of this community (you've read the
A List Apart article, right?). Stephen Hay promoted
Structured Content First and suggested there's
No Mobile Web. UK designer and author Mark Boulton penned a post distilling these points into four words: "
Structure First. Content Always." He also advocates to, "
Start designing from the content out, rather than the canvas in" (I'll have to stop acting like my use of "desktop, fridge, car" is a new thing). For good review and thoughts at a better future, read
Is it really a mobile Web or a 320px-wide one?
The Web design community recognizes the significance of structure, content out, and contextual experiences. Your content strategy and content model are key here.
Some of my best content modeling training-in-disguise was as a Internet Research Analyst. I had some 26 months where my job was to evaluate some site, summarize its features, then craft a report. Report sizes ranged from a quick memo to 9 binders-worth of material. Add research prompts for Accessibility (and Section 508 in the US) and CMS vendors along with several manual updates in SQL, HTML, and XML, I had absorbed the significance of content structure.
As a content management consultant and aspiring thought-leader in my niche industry, my role is to help customers identify what they need to build and how that maps to SDL product functionality. I can't dictate your business or content strategy, but I can definitely help navigate the catches and pitfalls on creating a manageable content model.
Two big SDL Tridion with mobile "gotchas" are in some of Tridion's strongest features, one well-known and established with the other new, powerful, and more under-the-radar than I'd prefer.
1. BluePrinting. Avoid assuming there's a mobile
layer somewhere in your SDL Tridion BluePrint. The content explosion is bad enough without adding publication proliferation to your challenges. Go ahead and create publications to help with mobile or a mobile-specific website, but
localization is not personalization.
2. Mobile is more than mobile, it's contextual. Don't believe the hype, mobile solutions (especially with a capital "M") shouldn't be about solving
mobile challenges, it's about
contextual experiences built on knowing about your user's real-world context. It's about making it easier for your implementation teams to create experiences based on the information surrounding your user. The details in the background are
no longer ambient noise, they're ambient data relevant to your customer's interaction with your site, brand, or dare I say, experience.
In terms of content management, the term
experience simply recognizes that we're not dealing with just pages anymore. We're looking at multiple pages and the paths through them, possibly including information you already have about the visitor, but also session-based information during their duration, and real-world information like geo-location and type of device.
What SDL Tridion gives you is an SDL Context Engine Cartridge to let your engineers build around this ambient data. The open source
Tridion Context Engine wrapper gives you more tangible detection and the ability to create device families. Read more about these tools from
Nuno Linhares.
Let Authors Author.
Part of the confusion is what do these developer tools mean to your authors. We have to remember that authors are not managing the
design of your sites, they're working and hopefully collaborating within your content management organization, specifically crafting the
content experience. They need enough flexibility to structure their content formally and informally (in rich text) and should be able to work with a selection of themes, options, and layout choices that fit your brand.
Authoring and content strategy decisions will determine what pages, content, and functionality are shared across different experiences (or simply types of devices for now). But your authors aren't designing a mobile experience. Your entire team is, from strategy to concept, design, code, architecture, and content.
The team has to research, design, and build those experiences. And some experiences you won't know about until you measure across channels, interview users, and run experiments.
"So will there be a mobile check box?" If up to me, no, not in general. I'd start with
content types and what they mean to your users in a way that's manageable for your authors. You might need a specific device-specific component (e.g. "buy this app"). But I'm sold on what the Responsive Design community thought leadership is recognizing and suggesting, and that the mobile experience is more than mobile and will need to be more than the current techniques.
Yes, add more features as they're available across devices but don't assume what users will want or need. Let's focus on user attributes, ambient data, and things that might stay the same in the next 3-5 years. Did you ever have checkboxes for "IE" or "Firefox" in your content forms?
Use things like "geo-aware and touch-enabled" when adding features and group specific devices into families such as "mobile and tablet." Maybe consider user-context like "holding the device" or "in the bathroom" for when it's possible to detect these things. But be careful with assumption, knowing about others and acting on it can backfire.
We continue in
part 2.
