I’ve talked about the importance of considering the author when doing an Adobe Experience Manager implementation before. Here is a link to watch the presentation I gave at Adobe Summit back in 2014. It is the role of an author to deliver content out to the sources that consume it and need it. Marketing authors are the heart of your organization’s web presence, delivering content to the people who need it most: customers.
As I stated in my presentation: “I personally have been involved with web development for almost 10 years now. And most of that time was spent creating websites using various tools that developers built based on business objectives or needs. And sometimes those systems were clunky, awkward, and not very easy to use. They got the job done, but they were far from elegant. Nobody really spent any amount of time considering how an author was supposed to use the tool to create content (content being arguably the most important part of a website). Simply put, a developer usually just wants to make a thing work and then move on to the next thing.”
I’m not trying to be down on developers, but in all honesty I have seen this a lot. In a way we have bred developers to be like this. Clients, analysts, and managers are known to throw a request to developers with limited details or requirements and tell you to build it as quickly as you can. That’s not fair. My job with this blog post is to suggest some ways that you can improve your process and development using Adobe Experience Manager, in a way that benefits the authors.
In that Summit presentation I mentioned some things an organization can do, one of which is to utilize an Authoring Advocate. “This is a person whose express job it is to capture the requirements for how content will be authored. A stakeholder that understands the author’s needs and can give feedback to the development team can be incredibly helpful and time saving.” I still stand by this and would recommend that you use this in your organization, but typically developers don’t have the necessary influence on this decision.
Here are a few suggestions about how you can take the author into consideration when doing development, that you can absolutely control:
- Be aware that a human is going to have to use this, likely on a daily basis – I know this seems dumb to say, but if you visualize your best friend being the one who has to use this authoring tool, day in and day out, then you might be more apt to give it a second thought. I find it best to think of authors as a finite resource. The idea of authoring fatigue is a very real concern. And if you can do something to make their process easier, then you should do it.
- Hallway usability tests – Grab a person who hasn’t been working on the project to come and use it. This should be in addition to your normal pull request/code review process that you do with your regular dev team. A fresh perspective is always helpful when you have been working on a project for a long time since you often end up with tunnel vision.
- Generate test content for your component so that you know how it works with all the needed material – Creating this test content serves multiple purposes: a) it’s a chance for you, the developer, to communicate the assumptions and behaviors you built into the component; b) it drives both the usability testing and edge-case testing for the QA team (If they know where the assumptions are, it’s easier to test what happens when they fail.); and c) it becomes a growing library of both functional and behavioral testing for the component over the long term, easing future maintenance and development efforts.
- Appropriately sized dialogs in Touch UI – Just because everything is there in the editing dialog for a component, doesn’t mean that it is the best it can be. Take some time to make sure that all the dialogs are sized appropriately on all targeted devices, so that you can view the contents of them all easily. A good example of this is the 6.0 release where the dropdown for Touch/Classic UI rendered below the bottom of the dialog, making it appear that there was only one option in the dropdown.
- Properly labeled dialogs and component titles – Label or name the component or page type (and, if possible, get the Author Advocate or stakeholders to help with naming). When you end up with a bunch of components on the page it will make everyone’s lives easier to know what each component is, especially if you have components with similar functionality. Plus, having all the fields of the dialog labeled correctly will make it easier for the author when they forget the training that they received.
- Demo, Demo, Demo! – Include the authors, or the Authoring Advocate, in your regular demo process. If you aren’t doing regularly scheduled demonstrations of your code then you should start. Nothing is worse than getting to the end of the project and then having the customer tell you that features are missing or functioning incorrectly.
We at Axis41 think that the fundamental consideration you should make to have a successful implementation is the author’s experience. And, thanks to AEM, you have the ability to optimize the authoring experience to your organization’s needs. This is true if you are running CQ 5 or AEM 6, Touch UI or Classic UI. I hope you take some of these considerations into mind as you develop with AEM. If you have any thoughts on these recommendations then drop us a line via our email: firstname.lastname@example.org