How To Evaluate Your Adobe AEM Project Success (Before You Start)

Check out the big brain on Brad

 

A long time ago in a school system far, far away (Grand Rapids, Michigan, to be exact)…

I spent the first ten years of my school life in accelerated programs and split classrooms. I had off-the-charts test scores, attended special schools for academically talented students, and hated every second of it. In the paraphrased words of Samuel Jackson in Pulp Fiction, I was a smart mofo. In 9th grade, I transferred to a public school and discovered the magical art of complacency and laziness. It was all downhill from there.

Since I was new to the school, breaking into the already-established social groups was a slow process. If you were to draw a Venn diagram of the various social groups in a typical midwest American high school (sportos, motorheads, geeks, sluts, bloods, wastoids, dweebies, and dickheads), you would find me sitting smack-dab in the middle – in the Venngina, as I like to call it. I didn’t fit into one particular social clique because I was a little bit of everything – an amalgamation of all. I normally sat the back of the class with the Metallica potheads, goth girls wearing black wedding dresses, and other clock-watching loners who counted down the minutes until 4:20 PM. No reading, writing, and arithmetic back there, just puff, puff, give.

To say that my high school grades sucked because of my complacency is an understatement. I went from being the next Doogie Howser to barely scraping by. I got straight C’s and D’s my senior year in one of the worst schools in Michigan. My high school has only a 55% graduation rate, my history teacher is currently serving a life sentence for the murder of a prostitute, and we made national news when a basketball player dropped a sack of weed onto the court during a game.   When you barely graduate from a school like this, you’re a dumb-ass. Even Joe Gunchy, the world’s worst Adobe Architect, could graduate with honors from here. To me, high school was a four (nearly five) year sentence that I had to serve because my parents and Michigan law forced me to attend.

Related: MEET ADOBE AEM’S BIGGEST ENEMY – JOE GUNCHY

Sometimes in class (when I wasn’t skipping), we were allowed to trade papers with our our neighbor to grade each other’s tests, reports, or quizzes. When that happened, no matter who in the Venngina I sat next to, I magically got all A’s.  Other times, we were allowed to grade our own papers. When that happened, I got A+’s!  The rest of the time, our papers were graded by the actual teachers (the ones who weren’t in jail). When that happened, I got F’s.

But, then I got wise…

Instead of reading books, I learned to read people. Instead of studying the subject, I studied the teachers themselves.  Understanding how a teacher prepared their lectures and graded material provided great insight into how to prepare for quizzes, tests, and exams to achieve top scores.  It isn’t cheating, it’s simply understanding the evaluation criteria and details of what good looks like before doing the work.  When I figured out this secret, my grades changed drastically. I spent less time doing unnecessary B.S. and had more free time to do more important things in life – like mope around, play Hacky Sack, and listen to The Cure.

Checkin’ Homework

Why do you suppose my self-evaluated grades differed so greatly from my instructor-evaluated work? According to me and my lenient peers, I was on course for an Ivy League life.  But, according to 100% of the Michigan colleges that didn’t agree with my D’s get degrees philosophy, I was on course for a life as a Walmart cashier.  The difference is, as a self-reviewer you have personal stake and pride-in-ownership which leads to overlooking the small details and errors. These ultimately add up to large errors when aggregated and break the proverbial camel’s back. This is why having an impartial reviewer is important.

Related: YOUR BABY IS UGLY: HOW EXPERIENCE, CANDOR, AND EMPATHY CAN SAVE YOUR ADOBE PROJECT

As consultants, we’re often called upon to evaluate a client’s Adobe AEM platform to determine how flexible, scalable, and (re-)usable it truly is. We effectively get to grade their homework and we need to do it thoroughly and impartially. Unfortunately, this engagement usually happens after the fact, when the platform is already live in production. So, the remediation of the findings often remain unattended, or fixing them causes significant refactoring of code and regression testing of the platform until it becomes entirely unusable, unmaintainable, and is scrapped entirely.  

Start. Right. Now.

What if you knew the grading criteria of a best-in-class Adobe AEM implementation before you began? That is, what if you knew the definition of good as defined by industry best practices, my kick-ass blog, and Adobe then designed your platform to those standards right from the start? This article does just that.  I will show you the evaluation criteria I use as well as additional input from Adobe to ensure you start your project the right way.

Evaluation Overview

I’ve broken down the evaluation into three major sections: Component and Template Reuse, SEO Best Practices, and the Authoring Experience. We will do deep dives into each section in future articles.

Only use this evaluation if the following statements are true:

1. You renounce the idiot Adobe Architect, Joe Gunchy and all his work and ways (and all his empty promises) and surrender yourself to the Adobe Best Practices Gods
2. You are creating a reusable platform consisting of templates, components, and services to be used by more than one brand or business unit to create independent websites or micro-sites
3. Your platform will provide the flexibility for a brand to create a best-in-class unique site, while keeping within enterprise standards and guide-rails. Play with whatever you want, as long as you stay in the yard, if you will
4. The primary user of the platform will be a brand manager or business-level user, not a nerdy developer
5. Your SEO mojo needs help and you want to improve your ranking, easily

Component and Template Reuse

You will review component and template documentation, architecture, and code to validate its capabilities for reuse and ensure the platform’s readiness for the creation of additional sites.

• Verify proper use of component inheritance for maintainability and extensibility
• Verify proper use of composite design in component architecture
• Verify components and templates are void of styling in the markup

SEO Best Practices

You will review template dialog options for the integration of SEO Best Practices.

• Reconcile inventory of templates and components against a checklist of brand-specific SEO recommendations to ensure inclusion of Schema Markup, canonical tags, social integration, and more.

Authoring Experience

You will find opportunities for simplifying the Authoring experience.

• Ensure proper use of contextual help, field labels, dialog field validation rules, component and template naming conventions, paragraph system, and more.

Evaluation Execution

Again, I will dive into the details of each in future articles. For now, munch on this:

Component and Template Reuse

To ensure the platform templates and components follow best practices for creating reusable, extendable components and services:

• Verify there are no styles, colors, or brand-specific functionally embedded into the components that cannot be re-configured without custom component development efforts.
• Verify proper use of composites in component and template design to maximize reuse and simplify the extension of the components for brand-specific functionality that deviates from the platform baseline functionality.
• Verify no embedded site-specific labels or copy are used in templates or components that cannot be changed through properties or placeholder labels and values
• Verify proper use of overlays for overriding platform functionality that will not affect other sites hosted in the environment
• Verify ability to display custom, site-specific error and exception pages independent of other sites hosted in the environment
• Verify supporting Java models are void of brand-specific functionality or configurations that would require code changes to incorporate into a new site
• Verify components do not duplicate functionality for ease of maintanance
• Verify use of Touch UI, versus Classic UI for editing pending deprecation of Classic UI in 2018 (and deprecation of Coral UI 2.0)
• Verify proper use of the paragraph system in templates to maximize flexibility
• Verify consistent authoring experiences across components
• Verify flexibility of AEM Tagging hierarchy for use on other brands
• Verify flexibility of workflow processes for other brands

SEO Best Practices

To ensure the platform templates and components incorporates industry SEO best practices into the framework:

• Verify ability to auto-generate site-independent dynamic sitemap XML
• Verify ability to customize page URLs
• Verify ability to include Canonical tags into pages
• Verify ability to include Meta description and custom Meta tags into pages
• Verify images include Alt Text
• Verify ability to include Schema markup (JSON-LD) in pages
• Verify ability to include OG tags in pages
• Verify ability to easily adjust page Redirects
• Verify ability to include Meta robots tags into pages
• Verify platform follows best practices to reduce Page load time
• Verify ability to generate Robots.txt
• Verify ability to display custom, site-specific 404 , 500, and general exceptions pages
• Verify ability to include Google Search Console and Bing Webmaster Tools integration

Authoring Experience

To ensure the platform templates and components incorporate industry authoring best practices and integrations into the framework:

• Verify consistency of dialog tabs and fields across various templates and components
• Verify templates and components follow a user-friendly, unambiguous naming convention
• Verify the organization of components in the Sidekick/Component drawer
• Verify components have consistent and user-friendly Field Labels
• Verify components have consistent and user-friendly Contextual Help
• Verify consistent use of component Edit Bars versus Roll-over editing
• Verify components have user-friendly naming of Tabs in Dialogs
• Verify consistent use of File Path Selection versus drag-and-drop fields for image and page path selection
• Verify components have consistent and user-friendly validation messaging for required fields
• Verify proper use and configuration of the Rich Text Editor
• Verify reuse of inherited component Dialogs versus re-created Dialogs

Evaluation Categorization

The output of the evaluation should label its findings into categories to simplify future prioritization of the recommendations to enhance the platform for more flexibility or reusability. I use a high, medium, and low scheme:

• High – Immediate need to modify or update platform functionality to accommodate additional brand sites into the platform. Failure to modify or update this feature would not allow additional brand sites to leverage this feature.
• Medium – Limitations of platform functionality that require future modification or update to accommodate addition brand sites. Workarounds or simple configuration exits for the interim until planned updates can occur to update the component or template.
• Low – Simple recommendations such as Authoring inconsistencies that still allow platform adoption by other brands, but limit usability.

Adobe Best Practices

Adobe has a ton of information on development and implementation best practices. Start reading the links below to get you on your way.

https://solutionpartners.adobe.com/home/enablement/training/aem_training.html 

Implementation Guides

Step-by-step technical guides to help implement a single Adobe Experience Cloud solution.

• AEM Sites Implementation Guide
• AEM Assets Implementation Guide
• AEM Forms Implementation Guide
• AEM Implementation Guides (Japanese)

Implementation Best Practices

• Continuous Integration for AEM
  
• Multitenancy and Concurrent Development in AEM
• Performance & Load Testing AEM Part 1
• Technical Resource Guide for Partners
• How to Win Friends and Influence DayCare
• AEM Best Practices: AEM Storage Considerations
• Integrating AEM with Adobe Campaign
  
• AEM Best Practice: Hobbes and Component Dialogs
• AEM Best Practice: Changing Author Session Timeout

 

Laziness and complacency forbid me from writing conclusions. Therefore:

If you like this blog, leave a comment or SHARE it on your social channels.

Finding the Unicorn: The Role Your Organization is Missing (and May Never Find)

Adobe states that over 80 percent of their clients own three or more solutions of the Adobe Marketing Cloud, including six of the ten highest revenue Pharmaceutical companies. This number will likely grow, as Adobe saw a record 26% increase in revenue Q1 of 2017. The true value of the Adobe Marketing Cloud comes when these solutions are connected together, to provide a consistent, relevant experience across channels and devices. Finding and retaining talent with the ability to connect multiple solutions of the platform is now a mandate. In the Adobe world, this rare role is called the Multi-solution Architect (MSA).

The mandate for an organization to retain a Multi-solution Architect was evident at the 2017 Adobe Summit, as the majority of technical sessions involved combining two or more integrations such as, Adobe Experience Manager integration with Adobe Analytics and Adobe Target, Audience Manager & Adobe Analytics: Your data management power couple, and The Dynamic Duo: Adobe Campaign & Adobe Analytics for real-time re-marketing. Last year, it was estimated that there were only about 15 true Multi-solution Architects worldwide at Adobe. In agencies, there are likely none.  And with an already steep investment on the platform itself, hiring this rare consultant would break even the largest organization’s implementation budgets.

Computer Futures is one of the leading supplier of Adobe talent in the U.S., with Adobe themselves being one of its largest customers. In their 2017 Adobe Market Report, they state that, “the true multi-solution architect will be the most valuable individual in the marketplace.” Currently, there are an estimated 40 open positions for an Adobe Experience Manager (AEM) developer alone, and even more for an Adobe Campaign developer. An individual with the experience to connect both systems (or even three or more solutions) would be like finding a unicorn. And with new legislation on the table that would effectively double the salary of H1B workers to a minimum of $130,000 per year, the available talent pool to fulfill these roles will decrease as the low-cost developer pool shrinks.

“For the most part, ‘true multi-solution architects’ are working for Adobe directly. This is where they naturally receive the best training and gain the most project exposure year on year. There are some that have flown the proverbial nest or exist outside of this, but they are extremely hard to come by.” -Dave Fox, Computer Futures

It’s important for you to heed the call and extend your AEM practice to multi-solution consulting and execution to align overall solution architecture to digital marketing strategy and goals. This ensures marketing campaigns are fully integrated to deliver a consistent, personalized experience and messaging across channels, and are continually measured and refined through data-driven insights.  Don’t say I didn’t warn you.

Since you won’t likely won’t find an MSA, you have to make one.  If it’s you, how do you get up-to-speed on your multi-solution architecture practice?

The Adobe MSA acts as the facilitator between the business and the individual Subject Matter Experts (SMEs) for each solution, so there are soft skills needed in addition to the nerd stuff. Even the greatest musicians need a conductor. Assuming your organization’s offering is silo’d (like most), it’s the job of the MSA to provide the connective tissue between your web, relationship marketing, social, media, data, and insights teams. Although the technology was created to provide the horizontality across these silos, your antiquated, pre-digital business model and processes will hamper its effectiveness. You are the glue.

Here are a few tips to get you started:

• Tell a story: “When Dr. X visits our homepage, we identify he is a Cardiologist who has never prescribed our drug. We dynamically show content in the hero space specific to first-time prescribing Cardiologists and a clear call to action to contact a sales rep in his area. When he clicks the button, we take him to a Contact a Rep Form. Blah, blah, blah.”  Notice the story has no Adobe solutions (or any technology solutions, for that matter) listed whatsoever.  You first need to define the what before the how.Your story should always tie back to a measurable business goal. In this case, it is to increase registrations and rep engagement. Now, it might not be your job to actually create the story, it is your job to bring the story to life.
• Start small. Too often, organizations take the Joe Gunchy approach and choose the largest implementation as their ‘pilot’.
  

  “Go big or go home.” –Joe Gunchy

  You need quick wins, so start with a short story (not a novel), then map the data, content, and technologies needed to bring your story to life:

  • Homepage (AEM)
  • Doctor speciality data (first and third-party data in Audience Manager)
  • Doctor prescriber data (first and third-party data in Audience Manager)
  • Geolocation data (browser info in AEM Context Hub)
  • Behavioral data (Analytics data shared with Target)
  • Contact a rep form (AEM/Campaign)

When you identify a missing piece in your technology landscape, you need to weigh the value of acquisition/customization.  Is it easier to modify the story or the technology landscape to achieve quick wins while still achieving your business goals?

• Connect the dots. Study the Adobe Use Cases  found in the Adobe Solution Partner Portal. If you’re not an Adobe Partner, you can register as a Community Partner to access this content. The use cases show how data is exchanged between solutions for a variety of scenarios. Understanding these will give you a foundation for implementing their connectivity.  A multi-solution connected diagram looks like this:
• Follow best practices.  Check out the Build a Digital Foundation using the Adobe Experience Cloud tutorial for tips on how to integrate AEM with other solutions. Also, read the  Integrating with the Adobe Marketing Cloud documentation then actually try some hands-on execution of a small use case. Start by simply personalizing a single piece of content in AEM using the out-of-the-box Context Hub for geolocation or other available trait, then eventually move up to AEM + Target integration, then Analytics to Target to AEM, then AEM to Campaign, etc. Fail fast, and learn.
  

  “E pluribus unum (Out of many, one)”

• Out of many, one.  This is the opportunity to organize around your team of internal SMEs to help with the connectivity between solutions to bring your story to life – a journey manager, of sorts.  Do you have to know every detail of every Adobe solution? Nope.”You don’t have to know how to push every button, you just need to know there’s a button to push.”   Let the SME’s do their SME’ing while you retire back to your cubicle knowing you’re the rarest mofo in the org.

  #unicorns4life.

Jumping into Adobe AEM Development

Got a great note from a reader asking advice on whether he should dive in and learn AEM development:

I am a User Interface Designer with minor Front End Developer skills. I was recently hired by a major eye wear company  for the sole purpose of migrating a version of one of their Native Apps over to AEM. I have no real experience with AEM Development, but I am a fast learner and I already have the AEM portal experience mastered (along with creating articles, collections, layouts, etc..)

My question is: Do you think it is viable/worth it for me to dive head first into AEM Development and try to learn the various languages/frameworks necessary to be able to customize an AEM app? Or is it something that would take years to understand and a complete change of my skillset?

Kind of a random question, I know… but your article was great so I thought I would reach out for advice. Thank you Mr. Meehan!

Seemingly Unrelated Story Time…

I grew up in a stereotypical, plain vanilla American suburban neighborhood – complete with station wagons, paper routes, penny loafers, Golden Retrievers, the works. There was even a pool up the street where you could pay 50 cents to swim all day.

I didn’t know how to swim until I was almost 11 years old, and none of my friends knew it. I could have won an Oscar for Best Actor for the work I did in that pool. I had all the individual skills to be a swimmer, but I never put the pieces together. If I held onto the side of the pool with my hands, I could float and kick my legs – no problem. When I was away from the wall, I would just walk with my feet touching the ground and paddle my arms so it looked like I was swimming. But, once I felt the curvature of the floor move towards the deep end, I would turn around and go back the other way because I knew I would be over my head.

Fast forward one muggy Michigan summer…

Somehow my ultra-conservative mom made friends with a backwoods, country bumpkin lady who had just moved to Michigan from a little town in West Virginia. She looked exactly like Willie Nelson in drag. I can’t remember her name, but it was one of those redneck stoner names where two regular stoner names are mashed together to make it even more rednecky, like “Misty Sue” or “Deena Jo”.

One day we were at the pool (or “swimmin’ hole”, as she called it) and she saw me walking in the shallow end, paddling my arms. She knew I couldn’t swim and I knew she was about to expose my secret as soon as she finished the Virginia Slim cigarette dangling from her lips. She paced back and forth along side the pool like a junkyard dog, watching me. I knew I was doomed, so I stayed in the pool until my hands and feet were as pruned as a crocodile’s scrotum. Yeah, I said it.

When I finally got out of the water, she took the last drag from her cigarette, dropped it into a can of warm Shasta soda and shook it.  Ssssssssssst.  She slowly walked over to me, grabbed me, then said, “Ya know what time it is, hound dog? …It’s swimmin‘ time!”

At first,  I thought it was weird that someone just called me, “hound dog”. Then, I was relieved because I thought she was going to say, “Hey, everyone! This kid can’t swim!”  Then, I realized “swimmin‘ time” loosely translated to “throw me in the deep end”.

I tried to scurry away and break her grip, but I couldn’t. She had me a crazy country wrestling hold I called, The Full Willie Nelson.  The more I struggled, the more my sunburned back scraped across the stubble on her leathery legs, until I could take no more. I conceded and wilted onto the scalding concrete.

She lifted me up over her head and threw me into the middle of the diving pool, which was the deepest part of the L-shaped pool. I sunk down about three feet, panicked, and started kicking my legs until I got to the surface of the water. I kept kicking my legs and flailing my arms and realized that the more I kicked and flailed, the more I moved closer to the safety of the wall. “Holy sh*t, I’m swimming!,” I thought.

I spent the rest of the day jumping into the deep end on my own and swimming back to the wall, all while Mrs. Willie Nelson smoked and watched from the edge.

Get to the Point…

Adobe is selling the hell out of AEM right now. Internally, they simply don’t have the capacity to keep up with all of the services opportunities to stand up, develop, and manage the platform, so they’re turning to partners to do the work.  If you’re hiring, you’ll be lucky to find a single AEM developer just sitting on the bench. And, if you do, they won’t be there long.

Time to jump in!

You already have some of the individual skills required to start developing in AEM. Most importantly, you’re already familiar with the tool. If you do this now, you can ride the demand wave for the next four years or so until the market evens out.  By then, you’ll be leading your own team.

The easiest way to learn it is to just jump in and do it.  Learning to code is the easy part. Since Sightly, we’ve enabled most of our front-end developers to create templates and components on their own without much back end coding. Template and component development is a good place to start.

Don’t get over your head!

You don’t need formal training,  but you do need a mentor who can take a look at your design and code to make sure you’re developing using best practices. Most of the clean-up work we do is directly related to a client hiring a development team who oversold their capabilities, didn’t follow any standards, and left the client with a non-scalable platform littered with hundreds of templates and components. Hundreds!  Don’t be that guy.  If you don’t have a mentor, get involved in the Adobe developer forums. There are some incredibly talented men and women on there who were once in your shoes and will answer any question you have.

I’ll leave you with a quote from Helen Hayes, whoever that is…

“The expert at anything was once a beginner.”

-Someone named Helen Hayes

Jump in the pool, hound dog. It’s swimmin’ time.

 

Article – Responsible Personalization: How Brands Can Build Trust With Consumers

I was recently published in Advertising Age with an article I wrote called “Responsible Personalization: How Brands Can Build Trust With Consumers.”     Please take a look and share!

 

Adobe AEM Implementations …from Hell

I am a single dad with three kids: Sophia (10), Connor (13), and Ariana (15). Together our initials spell, “S.C.A.B.s”.  As Team S.C.A.B.s, we love to embark on regular adventures, such as weekend getaways to Chicago, hiking through trails where Jesse James and his gang hid from the law, or just exploring the great city where we live.

This fall we decided to do something I enjoyed as a kid: visiting a haunted house. But we didn’t just select any haunted house, we chose The Edge of Hell, one of the top-rated haunted houses in the country located in one of the many vacant buildings in the forgotten part of the city. As we waited in line to buy our tickets, we were greeted by rat-eating monsters, a galloping headless horseman, and fire-breathing, tattoo-covered hipsters in desperate need of a tetanus shot.

I paid for four tickets into The Edge of Hell which cost me $25 a piece plus tax for a grand total of $117. NO REFUNDS.  Honestly, the receipt alone scared the hell out of me, but I’m cheap.  The kids seemed to be in brave spirits, so we assembled in a standard conga line in order of age: I led first, Ariana was behind me holding my shoulders, Connor held onto Ariana, and little Sophia held onto Connor with her eyes closed tightly.  We ascended the stairs near the entrance and our adventure began as the door and our last glimpse of light disappeared behind us.

The first thing we encountered in The Edge of Hell was a pack of large mechanical dogs (or “Hounds of Hell”) that popped out of a wall and barked rabidly at Team S.C.A.B.s.   Instantly, I heard Connor yell from behind me, “Daaaaaaaaaad!  I want to leave!”

“Connor, we just got started. Where are you going to go?” I asked.

Right on cue, an acne-covered teenage monster emerged from the darkness. “Chicken Exit,” he said, pointing to a steel door to our left. Before he even finished his sentence, Connor’s hands released from his sister’s shoulders and he walked towards the Chicken Exit.  Sophia, not realizing where Connor was leading her, followed him with her eyes still shut tightly. Before I could object, the door slammed shut behind them. “NO REFUNDS” echoed in my head.  The S.C.A.B.s were now reduced to just “A” and “B”.  Thanks a lot, Teen Wolf.

Ariana and I continued on. We finished the tour and we found Connor and Sophia waiting near the exit with the other chickens. Connor was staring off into space, still grappled with fear.   As we approached, Ariana folded her arms and said with her Big Sister attitude, “I think Connor should have to pay you back the $25.”

Connor paused, then stoically said, “Make it an even $30.”

“What’s the extra $5 for?” I asked.

“New underwear,” he muttered.

Why am I telling you this story on an AEM blog? Because it’s my job as a loving father to take every opportunity to embarrass my kids. But there is a point…

Fear is a powerful emotion and is amplified by surprise and the unknown. When you don’t know what’s hiding ahead, your senses are heightened, your pulse races, and the slightest deviation from ‘normal’ is enough to ruin your day (and likely your pants).

My kids have never been through a haunted house, but I have.  Imagine if I could tell them what was around every corner before we reached it? Or even better – what if I could guide them through the haunted house with all of the lights on?  I could take the fear of the unknown and every element of surprise out of the equation.

That’s your job as an architect or technical lead; that is, to help guide your clients through their digital transformation or AEM implementation with the lights on. This is likely their first foray through this process, but not yours. They have questions, they have concerns, and you have answers. Guide them.

I’ve recently been selected to take on a new role called the “Global Adobe Alliance Manager.”   It’s my job to act on our clients behalf to help guide them through the entire life-cycle of their digital transformation using Adobe’s offerings.

Your company might not have a dedicated person for this role, but there are some things you should be doing to help guide your clients through this process from start to finish:

• Web Context Experience Management (WCXM) system evaluation and platform recommendation – If the client has not yet selected a platform, it’s your job to help provide them an unbiased recommendation to satisfy their business and functional requirements. You’ll likely be reviewing three to four platform options and providing a gap analysis of each. You may even help them define the platform selection criteria. Your recommendation should also consider their in-house technology expertise. Are they primarily a Java shop or .NET? If the vendor themselves (Adobe/Sitecore/Acquia/Whoever) responded to the evaluation, you can help the client vet their responses or translate WCXM geek-speak into something their business leads can understand.
• Procurement and licensing negotiations – You should have a clear understanding of the architecture of their proposed system as well as the basic user journeys of the visitors to help determine how many (and what type of) licenses to purchase. You will also help determine the level of effort to develop features or functionality that are not part of the out-of-the-box offering. This all contributes to the Total Cost of Ownership (TCO) of the platform and must be considered.
• Architecture reviews – Did the client themselves or another agency define the architecture?  Review it. Does the client have their own hosted environment? Do they partner with a hosting provider like Rackspace? Do they know about Adobe’s Managed Services offering? Have they considered security, Single Sign-on options, or a robust caching strategy using a CDN?  Is there dynamic data? How is it being retrieved? How often is that data updated? Can that be cached, even temporarily? You need to call these things out when you’re doing a review.
• Best practices recommendations – Does the client want something that goes against usability or the platform’s best practices? Are they asking for guidance on governance, mobile, personalization, globalization, or digital asset management? More importantly, are they not asking about these things? It’s your role to provide them the thought leadership in these areas and they must be considered at the beginning of the project.  They don’t know what they don’t know. Bring these topics to the table early.
• Code reviews – Has your client decided to take on the development of the site in-house and it’s their first attempt at developing and AEM project (see also: the idiot Joe Gunchy)? Or, is your client working with a different implementation partner and they want a third-party agency to act on their behalf to do a review of what’s being developed?  These are perfect candidates for formal code reviews. Even if it’s your agency doing the development, you should be doing code reviews internally with your team and including the client’s technical leads, giving them full insight into what they will be taking over when the project development is complete. Even though you’re developing it, it’s their code and they will ultimately own it. If you have apprehensions about showing them their code, let’s be honest – something’s wrong with it.
• Continuous integration recommendations – You must have an established, repeatable build process for compiling, and deploying both your code and content packages to the various environments.  If you don’t, you’re wasting the client’s time by doing these repetitive tasks that can and should be automated using free, open-source tools like Maven, Jenkins, and Puppet. True, there are some upfront costs (hours) associated with setting this up, but I challenge you to compare this to the time spent manually deploying to the various environments over a week, a month, or even a year. The return on your initial investment greatly outweighs that time and continuous integration is a must-have for every project.
• Training and enablement – Once development is complete and you hand the ‘keys to the site’ over to the client, are you confident they know how to use each component, template, or even the AEM interface itself?  At minimum, you should provide an AEM overview and a site-specific training to the client to include each component, template, scaffolding page, workflow interface, etc.  Don’t show them the out-of-the-box Adobe Geometrixx demo unless they actually work for a company that sells shapes. C’mon, man. Show them their site using their stuff.
• Support and documentation – The client will have questions, even after you’ve trained them and they’ve taken control of the site.  Be a good partner, be available, and answer their questions.  I’m not a big fan of printed, formal documents. Instead, I prefer to create a page (or pages) hidden from the site navigation within the tool itself with supporting documentation, useful links, and support contact information the client can refer to as they use the tool. If they find more efficient ways to use a component, they can update this page themselves thus alleviating another obsolete, printed document.

 

If you find this information useful, please share a link to my blog. If there is a topic you’d like to discuss, please use the comments below.

 

Usability Tip: Use Categories to Prefix Component Names – Part 2

In my last article Usability Tip: Use Categories to Prefix Component Names (LINK), I showed how pre-pending a category name to the beginning of the component name aids in sorting and is a quick way to help find the component you want to use.  After receiving a few questions regarding the post, a follow-up article is due in the form of a Q&A:

Q: “Why not use the componentGroup property?”

A: This is an excellent way to sort components when the content author manages only one site. You can use the componentGroup sort and categorize and restrict access to the components by use of permissions. However, if the content author manages more than one site within the same instance, this approach breaks down. It is possible to have two or more components with the same name but have different functionality.  Joe Gunchy would totally do something like this. My approach uses the site name for the componentGroup property, then further segregates them by adding the category to the name itself.

Q: “Would you be willing to share your macro list of categories for reference?”

A: Yep.  Here is the list of categories I used on my most current implementation:

• Content – Any straight, content-managed components like Promotion Pods, Rich Text Editors, or anything that a content author uses to fill in the copy, imagery, or other content on the page.
• Layout – Column controls, tabbed-panes used to divide a page into additional content areas
• Navigation – Buttons, links, calls-to-action, list of links (footer, side rail, related links), etc. that help the user navigation the site.
• Search – Components related to search functionality, faceted results, pagination, etc.
• Social –  Components used to share or display social content such as “Add This”-type features, Twitter, Facebook, Pinterest, YouTube
• Video – Brightcove, YouTube, or any video player, thumbnail library, carousels, etc.

What other categories can you suggest? Please let me know in the comments and we can add them to our list!

Usability Tip: Use Categories to Prefix Component Names

The component name should reflect its usage within its name. A best practice is to prepend its intended usage with the major category of its function. Because the component sidekick sorts component names alphabetically, you can group by prefixing all component names with their major category. For example:

• Content – Promotion Pod
• Content – Image Carousel
• Layout – Column Control
• Layout – Three-tabbed Panel
• Navigation – List of Links
• Navigation – Call to Action
• Social – Share Button
• Social – Twitter

When this list of components is sorted within the component Sidekick, the content author can see the major function of the component and quickly make a decision on which to use without scrolling through an exhaustive, unorganized list. Using this approach in conjunction with the grouping feature of the Sidekick gives the content author a well-organized toolbox to quickly assemble pages.

Sidekick Organization

Usability Tip: Use Edit Bars instead of Roll-over Editing in Your Adobe AEM Project

The world’s worst developer, Joe Gunchy (read more about Joe here)  is at it again.  He created a new component to give content authors the ability to add rich text onto a page.  The content author loves this idea and wants to try it out.  They dragged the component onto the page, but there is no indication that the component is on the page and ready to edit.  The content author is confused, so they drag another component onto the page. Still, nothing shows up.

 

Where are the components?

 

They drag another onto the page, then another, then another.  Nothing is displayed. Now the content author has five instances of the component on the page that they don’t know about, forcing the content author to drink from a flask hidden in their bottom desk drawer.  Joe Gunchy laughs at the content author.  Joe Gunchy is an idiot.

 

“Content authors are so dumb.” – Joe Gunchy

 

Five instances of the component

Component Editing

There are a few ways to edit content in a component. Some components contain an “edit bar” to show the editor dialog, while some use “rollover” editing.  The component below shows an edit bar above the component with options to add, edit, but, copy, and paste. If you want to edit the content of the component, you click the “Edit” button which opens the editing dialog. Easy.

 

Edit Bar to launch the dialog

 

When there is no edit bar, the author must click on the component in the page until they see the green boundary box appear. This is referred to as “rollover editing”.  Once that’s selected, you can either double-click within the box or right-click to launch the dialog editor. Joe Gunchy’s component used ‘rollover’, but when there is no content in the component, there is no way to tell the component is on the page.  You can mitigate this in the component source code by checking to see if you’re in EDIT mode, then add some default text to the component to show it’s editable. Also, in many cases, it is difficult to click if you do not place your mouse at the precise point within the box to open the dialog, or even worse – components overlap each other and you can’t click them at all.

 

Roll-over editing (no Edit Bar)

 

Use the Edit Bar

For better usability and consistency across the editing experience,  use the Edit Bar on your components and never mix Edit Bar and Rollover on the page.  That’s a horrible authoring experience.  The Edit Bars below clearly show the author how to edit content on the page and when used exclusively, gives the author consistency when authoring a page.   It’s clean, has clear calls-to-action, and doesn’t require default text to know they’re on the page.  By adding a few options to the edit bar configuration, you can click on the “Cut” button and easily move them around the page.

 

To add the edit bar to your component, create an ‘cq:editConfig’ node of type cq:EditConfig under the component. This link shows the various properties to add to the component.  Adding cq:actions to the properties allows functionality to move the component around the page.

The table below from the CQ documentation shows the different options for the edit bar.

Property Value	Description
text:<some text>	Displays the static text value <some text>
–	Adds a spacer
edit	Adds a button to edit the component
delete	Adds a button to delete the component
insert	Adds a button to insert a new component before the current one
copymove	Adds a button to copy and cut the component

 

Here are some typical properties to allow editing, moving, and deleting the component from the page. You must have “insert” selected if you want to move the component around the page and replace it between two components.

 

 

Additional Tip: Remove the Wrapper

AEM adds wrapper containers around components to allow either clicking on the component on roll-over, or around the component tool bar when using the EDIT BAR. These additional DIVs tend to negatively impact the style of the component because of the extra container that the developer was not anticipating.

There is an easy way to force CQ to remove the wrapper when in any mode but EDIT mode.

Add the following snippet at the bottom of your component:

 <%
 //This code will only add the surrounding DIVs for the editbars when in EDIT mode only
 if (WCMMode.fromRequest(request) != WCMMode.EDIT && WCMMode.fromRequest(request) != WCMMode.DESIGN) {
    IncludeOptions.getOptions(request, true).forceSameContext(Boolean.TRUE);
 }
 %>

Website Globalization and Localization Best Practices

Globalization and Translations

Multinational companies face many wide-ranging challenges when establishing a global digital presence. On the one hand, there is a strong desire to make each country site look and feel like a part of the same global organization, yet in many cases each country site may have unique requirements such as localized content, localized language, layouts that accommodate right-to-left reading or different imagery to better reflect local standards and customs.

When planning a site to meet the needs of a global organization, there are many considerations that need to be taken into account. These considerations range in complexity but each must be carefully considered during the planning and development phases to avoid the many mistakes and pitfalls common to such a rollout. Some of these pitfalls include items such as irrelevant content, design restrictions, broken layouts, inconsistent authoring experience, unsupported character sets and mixed language content.

 

Common Pitfalls of Site Globalization

Adobe Experience Manager (AEM) provides out-of-the-box functionality to easily create multi-language support with its Multi-Site Manager (MSM) tool. I find AEM’s integrated Multi-Site Manager tool the most robust and easy to use for creating, managing and maintaining multi-language, multinational websites. Sections of the site can be deemed the “master language” from which content is copied to the various language branches of the site using the MSM. Entire sections or individual selections are copied to the site’s supported language branches.  But…

Irrelevant Content

Solely translating content from a master site is not sufficient in the globalization of web properties. Problems arise when the content is translated from the master site, but it’s not actually created as region-specific content. Just because content is translated doesn’t mean it’s relevant to the regional site. Phone numbers, addresses, contact information and social links may be specific to the region and require additional regionalization, as opposed to just translation. There may be content related to products and services that may not be available in a given region, idiomatic expressions may litter the copy, and imagery may not be representative of the region, which all contribute to a regional site being disjointed. Special attention must be given to ensure the content does not contain forbidden or inappropriate material. For example, China blocks access to Facebook, so social sharing capabilities must allow for disabling selected links. Additionally, imagery that may be suitable for one region or culture may be offensive in another and require specific attention by a regional content manager to ensure it’s appropriateness for the targeted audience.

The implementation of a centralized governance model with a single approving authority over all web properties is not sufficient for addressing these concerns. The content approver must be well-versed in the language, restrictions and customs of the region. Workflow processes should be created and enforced at the regional level, such that the regional content manager has the final review and publishing authority. This is an example of a distributed governance model.

Often seen in large, multinational companies where subsidiaries and regions act nearly autonomously from each other under a common brand, a distributed governance approach works well when unique governance model requirements exist within different lines of business or geographic regions due to regulatory, political or industry differences. Authority can be delegated to regional content managers to manage their own workflows and controls while the global content team can still maintain a centralized view.

This approach is extremely flexible and gives local and regional business units the power to implement their own unique governance models to support regional regulatory or compliance environments. Common branding can be enforced but business units are given the latitude to create and approve their own content.

Design Restrictions

When regionalization is not at the forefront of design, numerous issues can manifest in site templates and designs. Layouts can become jumbled when page elements cannot handle variations in text sizes, or when the components and page templates themselves do not support the region’s language.

Page elements such as buttons do not always have enough “real estate” to accommodate longer words for different languages, which can break either the element itself or the entire page layout. Longer words push page elements across the page, causing wrapping or overlapping of elements.

For example, the main navigation bar in the image below shows what happens when the page is translated into French. As you can see, links are pushed to the left, causing them to overlap existing copy on the page because the design did not plan for the added length of text. One way to mitigate this is to employ character limits on the elements, or to allow for expansion when the limit is surpassed.

Layout does not allow for longer text

 

AEM supports easily establishing and enforcing character limits and other validation rules within the content authoring interface of a component. When character limits are not enforced, text in buttons must comfortably wrap within the element and allow for expansion when longer words are used. The buttons below are at the limit of their expansion without either reducing the size of the text or enlarging the button itself, and are not indicative of good design with globalization in mind.

Page elements and components should be designed to expand to accommodate larger, translated copy or have sufficient space to allow for the edge-cases for longer words.

Buttons where further expansion is not possible in French

Mixed Language Content

Some websites suffer from partially translated content, leaving the visitor with the impression that the site is incomplete, or the page was constructed without care. This is most noticeable when parts of the page are displayed in more than one language. The most common type of mixed-language content occurs when copy is embedded into graphics or photos. When these images are used across regional sites, the content can quickly become mixed-language, as seen below. At best, mixed-language content may confuse your audience, while at worst it may be completely unreadable.

The second most common type of mixed-language content involves the use of proper names, taglines or other company branding for products or services. When creating regional sites, you should always consider whether your branding and taglines should be translated. In some cases it may be appropriate to translate a tagline, while in other cases it may not.

When a regional site contains mixed-language content, links to either fully translated or nontranslated content can confuse the user. The site should warn visitors they are leaving the selected language for a different language. Furthermore, navigational items and language switching elements should be uniformly located and prominently displayed across all sites, so visitors do not get “trapped” in another region’s site if they are not familiar with the other language.

 

 

AEM provides built-in workflows to facilitate the translation and review process, including numerous connectors to third-party translation services including Translations.com, Lionbridge, and Clay Tablet, where native speakers of the language perform the translations. AEM also provides the ability to translate pages manually, directly in the tool, making content authoring for other countries a one-step process. Workflow processes are used to enforce rules that a page should not be published to the regional site until all content is properly translated, including imagery. A well thought-out site and Digital Asset Management (DAM) structure for pages and assets helps segregate content to easily target the correct regional content manager for approvals and publishing. Without a rigid site structure and taxonomy, targeting the right content manager is a difficult process and requires significant custom development to determine the correct content owner programmatically.

Specialized Layout Requirements

Languages such as Arabic and Hebrew are read right-to-left (RTL). Often times, layouts and imagery from a site’s master branch are not designed with these special language requirements in mind. For example, text within a background image requires sufficient space in the image to safely incorporate the copy and is usually displayed at one end of the image, as seen below.

 

When faced with using the same imagery on an RTL site, the copy may overlay the subject of the image. Simply flipping the image’s orientation on its vertical axis does not always solve the issue, especially when the image contains text in the background on items such as signage or computer displays. Templates and the supporting imagery must be designed to accommodate RTL display and reading.

Right-to-Left (RTL) Content

Components and calls-to-action should also be designed with RTL support in mind. This can be accomplished by creating a single component to support both orientations or by taking advantage of component inheritance.

AEM supports the concept of inheritance in which common functionality can be shared between linked components or linked templates, allowing for the extension and reuse of components through the sharing of common elements. When I examines wireframes and requirements, I look for common features across components and then design the component hierarchy to take advantage of this powerful feature. This significantly reduces not only the time to develop the components, but also gives the content author a familiar user interface to create content using similar components. In our examination of features within a local or regional site, we can determine how many of the components such as navigation, social integration, promotional pods, calls-to-action, and shared content can be utilized in multiple sites with little or no modification. This approach allows us to build a library of common components to use on subsequent regional site development.

Inconsistent Authoring Experience

In addition to a fully translated and regionalized public-facing site, it’s important to ensure the user interface for the regional content authors supports the native language of the content authors, giving them a robust, user-friendly authoring experience. Many times in content management system implementations, this key piece is overlooked and content authors are forced to create and manage content using a toolset in another language. All instructional copy in the component and the authoring interface should be configurable in a separate language when appropriate. This is easily accomplished using AEM’s translator interface. Key/value pairs are assigned for each supporting language where placeholder variables are used in lieu of literal copy and are retrieved using the “key.” When the authoring interface is rendered to the user, the placeholder key variables are replaced with the value in the translation table in the author’s native language.

Oftentimes, when globalization is not at the forefront of the initial architecture, copy is often “hard-coded” into the templates or components, meaning it cannot be updated ad hoc without interaction with a developer. It is imperative that all text in a component be configurable and translatable into different languages to support other regions.

Unsupported Character Sets

In some cases, there may be limitations with respect to the character sets required to create content for a given language. The need to support specialized character sets impacts not only the content as it appears on the site, but also impacts areas such as content entry, site search and SEO, to name a few. When considering support for globalization, character sets should be closely evaluated to ensure compatibility across all users.

Translation of URLs

Careful thought must be given when deciding whether the actual URL of the page should be translated. There is very little search engine optimization (SEO) benefit gained from translating the URL itself when the page content is already translated into the region’s language. However, there are some negative consequences of translating URLs. When using a tool such as AEM is used to create pages and content, the page URL is auto-generated to match the page title unless it’s manually renamed to something else. When the URL is renamed in the region’s language, it makes it difficult to track the page from which it originated. In AEM, the page title is used to generate the SEO-friendly name. When special characters or accented letters are used in the title, these characters are stripped out and replaced with a hyphen.

 

Conclusion

When planning a global site, there are many considerations that play a key role in a successful implementation. Careful planning and consideration should be taken from the outset to evaluate future requirements related to supporting multilanguage and multicultural requirements. Care and consideration should be given when evaluating things such as designs, workflows and the authoring experience in order to support regional content creation, curation and publishing. To maximize the end-user experience, design and templates should be built to not only support multicultural, multilanguage requirements, but to also provide a unified experience across all global sites. By carefully considering each of these items up front, internal stakeholders and site visitors will enjoy a personalized experience, leading to higher customer satisfaction and conversions.

 

-with Scott Oppliger

Hiding Links from the Adobe AEM Welcome Screen

Unlike the world’s worst programmer Joe Gunchy (read more about Joe here) , you were smart and followed my guidance on developing your Adobe AEM project in the right order.  So we can assume you have Groups of users in your system with various permissions to access different sections of the site. Some Groups can manage workflow, some cannot.  Some can manage Tags, others cannot.

Did you know you can hide the links on the Welcome Screen to a Group of users so they never see them at all?

 

“Out of sight, out of mind.”

 

 Here’s how:

• Navigate to the Users section of your site and click on the Group you want to hide a link from.
• Double-click the Group name and select the Permissions tab

• Navigate to one of the paths below and remove the VIEW option in the permissions.

Websites	/libs/wcm/core/content/siteadmin
Digital Assets	/libs/wcm/core/content/damadmin
Campaigns	/libs/mcm/content/admin
Community	/libs/collab/core/content/admin
CQ Inbox	/libs/cq/workflow/content/inbox
Users	/libs/cq/security/content/admin
Tools	/libs/wcm/core/content/misc
Tagging	/libs/cq/tagging/content/tagadmin
CloudServices	/libs/cq/core/content/welcome/resources/cloudservices
Workflows	/libs/cq/core/content/welcome/resources/workflows
Replication	/libs/cq/core/content/welcome/resources/replication
Reports	/libs/cq/core/content/welcome/resources/reports
Documentation	/libs/cq/core/content/welcome/docs/docs
Developer Resources	/libs/cq/core/content/welcome/docs/dev
CRXDE Lite	/libs/cq/core/content/welcome/features/crxde
Packages	/libs/cq/core/content/welcome/features/packages
Package Share	/libs/cq/core/content/welcome/features/share
Clustering	/libs/cq/core/content/welcome/features/cluster
Backup	/libs/cq/core/content/welcome/features/backup
OSGI Console	/libs/cq/core/content/welcome/features/config

• Finito!