Two main points:
- It’s not about what the CMS is capable of doing; its more about what the business wants to achieve. A good CMS Technical Architect (TA) can draw that out early.
- If you don’t plan for mobile delivery upfront you might pay for it in the long run.
I have had several project managers and in-house technical architects ask mobile objective questions relatively late in the project life-cycle.
First off, it is difficult to retroactively adhere to some of these mobile techniques in CQ5 that are outlined by Adobe in their documentation and presentations. The key word is retroactively. Typically these are foundational business objectives to “mobilize the CQ site”. There are 2 dominant strategies I’ve witnessed.
- Incorporate strategies from the beginning of the project to maximize the CQ5 platform.
- Pro – This will help authors build content for both browser/mobile experiences simultaneously.
- Con – This often is misunderstood and bloats project time-lines.
- Treat it as a secondary objective and retrofit/revise components for specific mobile templates which are separated from the core CQ5 development.
- Pro – Basing this on AGILE principles you could say this strategies elevates the business objective when its appropriate.
- Con – You will NOT easily maximize CQ5′s framework without rework at the component and template level. Note: a good CQ5 Technical Architect could plan in advance for this strategy.
Adobe has some ideas or reference architecture in Geometrix on how they “want” you to achieve both of these scenarios. Typically, business owners have philosophies on how this is you be dealt with too. Some companies have isolated mobile teams that produce the experience and content based on their personal marketing goals. While others integrate mobile and browser experiences together using concepts like responsive design. The latter aligns nicely with CQ but should be worked into the project early.
Bottom-line: This should not be a developer’s choice on how it should be planned for during the course of the project. This should be a business objective first. It’s unfair to drop these requirements on the development team late in the game.
I suggest having a constant dialog about mobile on a regular pace throughout the project life-cycle. Some questions to ask:
- How should CMS authors manage mobile content?
- How is the content different from one device experience to another?
- Who is responsible for the mobile experience business strategy?
- How do the mobile objectives impact ongoing development?
Email me at firstname.lastname@example.org if you see it differently or would like to discuss deeper.
Related CQ5 Links:
- Adobe CQ5 Documentation for Mobile - http://dev.day.com/docs/en/cq/current/developing/mobile.html
- Adobe CQ5 Authoring for Mobile http://dev.day.com/docs/en/cq/current/wcm/mobile.html