Tips for Content Editors

Content editors are the lifeblood of a content management system.  They are what most of the users will see and use most often.  The end user feedback on the content editors that are built by most Percussion customers is almost universal -- too many fields, too complicated, too long.  Most of these things are correctable, and have become a lot easier to do in Rhythmyx 6.  

Before diving into the tips, first an insight as to why this happens.  One of the primary reasons is the amount of time devoted to information architecture and modeling rather than usage modeling.  In Rhythmyx terms, implementers are often great at defining Content Types - what fields exist and why - but not so much in defining the Content Editor (the actual browser screen by any given user working on content of that Content Type).  To get better at usage modeling, we need to ask questions about the task, not the type:

• Who will know enough to fill in this field?
• Who is MOTIVATED to fill in this field? (Who cares that it has one value versus another?)
• When is this field really needed?

The good news is, these questions are additive (or parallel) to the those in the content modeling process.  That is, it may be perfectly reasonable to have a Content Type definition with dozens of fields on it (because the Web site or other channel output needs them to function).   It is probably NEVER acceptable to an end user to see that many fields in their Content Editor, or at least, not all at once.  In the definition, you not only define the Content Type, but the kind of Content Editor any given type of user will see.  Several key features let you control the "editing experience" over and above the actual needs of the content model.   For starters, these include:

• Field order - move fields together if they are related
• Field visibility rules - hide fields from people who don't need to see them
• Validation rules - can be a great way to avoid errors, or a bane to the user.  Be careful.
• Input translation - can some fields be calculated based on others, pre-populated with defaults?

Now for the tips.  Using the above can help you stay within these common design requests:

• Limit what any given user (by role) sees to a page or page and a half of fields.  This may change as the item moves through the  workflow.
• Don't show fields to users who don't know what they are.
• Don't show fields to users who don't CARE what they are.
• For visual impact, don't forget templates and Active Assembly as your editing interface.

Wondering what that last one is?  It's simple.  If you want to break out beyond what you can do visually in a standard Content Editor, just lay out the fields in a template that exists ONLY for editing.  You don't have to publish this template, it's just there for looks for users to use as a editor.  Since it's a template, you can make it render however you want.  The fields will be only those that you include in the template as editable, the slots will show up as slots (allowing you to edit and related content in one screen), and so on.  With this approach, the native Content Editor may only be used to create the item initially (it could be limited to just title and display title while in Draft for example).

If this seems odd, remember that users are contextual.  Active Assembly is about providing A context for in-context editing, not necessarily THE context.  If users really need the contextual help, it may well be worth doing.   Remember, a content management system is about the content, which really means, it's about the content contributor.  A bit of extra time making their life easier will pay dividends in the quality and volume of content you achieve.