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!

Advertisements

3 thoughts on “Usability Tip: Use Categories to Prefix Component Names – Part 2

  1. Thanks for the quick response and representative examples within each category. I generally like your categories; I had some ideas about some alternate categories, but don’t know how specific to our organization they are.

    Any integration which has been established beyond a single component may warrant a new category. It may also make sense to map these with a prefix within the categories you have provided…
    For instance, Commerce integration is growing more common. If I had 10 or more components developed to deliver content which is managed by a Commerce solution, does it make sense to organize them native to a new category, or should they still functionally map (Eg faceted navigation managed by Commerce) to reside with other Navigation components?

    Using our Design Pattern Library for reference, we group by:
    “Content Arrangements”: a component that would build a common configuration of other components; this could fit within your ‘Layouts’ category
    “Forms”: includes Inline form, autocomplete, and general user forms
    “Navigation”: we have patterns for progress bar, relative navigation, breadcrumb, pagination, and fly-outs
    “Rich Interaction”: Includes Gallery, Image Light box, Modal Windows, Maps, Tool-tips, Expand/ Collapse, Carousel, Accordion (all could fit within content)
    “Site Standard”: includes things such as pricing, wrapper, utility bar, and approved number variations (date formats, decimal numbers, percentages, etc. capturing business rules around regional variances and site standards)

    We have a web style-guide underlying everything to enforce color, imagery use, icons, typography, etc.

    Again, these could both be nested or several could warrant the use of a new category (such as you have done with Search or Video). If you have some logic you used to decide these should have a parent category, please share =)

  2. Hi

    I am fairly new to the AEM platform, but this approach seems to me like a workaround for a lacking feature. I feel the platform should offer a way to only display the components in the Sidekick relevant to the context (site or even page template) you are working in (by way of configuration). If this is not possible then it should have the option to have a drilldown menu in the Sidekick as all you are doing is indeed categorizing components like you would do products in a webshop. If all this is not possible, I feel AEM is falling short.

  3. Ivo,
    You can get pretty creative with this, but which components are supported for a given section of the page is defined at the parsys level… so what we are doing is adding some governance around what can be dragged where with this ‘design’ specification.
    You can double click on a parsys to see the allowed components, which I think accomplishes what you are talking about, or take a completely different approach and remove much of the choice complexity in the sidekick by ‘baking in’ components to the template… just usually ends up in a lot more templates.
    My understanding of what you are describing is available, but the organization is still very helpful in some contexts where there are many component variations available. Does this make sense?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s