Case study:
La Trobe Publishing System

Via weekly workshops, we examined existing content types to identify which were most used and which were not.

Users identified ongoing issues with particular editing tools and together we explored how these issues affected content currency.

Common editor errors were identified and logged.

Throughout the calendar year, there are repeating cycles where content may be reused and editors asked if we could address this need.

From here I presented many iterations of wireframes to the stakeholders and users. We tested different content combinations and layouts to finalise on a set that satisfied users and stakeholders.

Solution

• Review existing edit tools
• Workshops with users and stakeholders to uncover content requirements
• Extensive wireframing to test iterations of components
• Reach a consensus for 12 components

My first attempt at a publishing toolkit for editors was made when we were still learning our CMS. Some decisions turned out to be right, others were obviously wrong and very frustrating for the user. The content definition was spot on. It was small and easy to understand and very flexible. We could continue using it without change.

Meanwhile, the process of finding the content you wanted to edit was very difficult. Users complained how slow the system was and how much other stuff you had to wade through to find your item.

All the user’s content was tagged with our existing taxonomy, but the old tool required you to select which taxonomy items you wanted to work on. This was an unnecessary step and could be avoided by integrating the editing experience with published page.

The CMS allowed template switching which we could use to create an editor interface. Editors would be able to switch to this template which would automatically load all their existing content via the taxonomy term applied to the page. This would eliminate many repeated steps in the process.

Solution

• Remove unnecessary steps and choices: 12 steps reduced to 6
• Make use of new CMS features
• Identified configurations that caused excessive time to load

As the CMS in use only offered a standard WYSIWYG editor, we knew it would not meet our needs. We required tools that would allow us to edit content related to this page, not content directly stored on this page.

However the CMS did include a Javascript API with which you could build more intuitive and flexible tools. This would mean building all create, read, edit and delete functions ourselves. It would also mean we would have full control over the interface.

I had to create an easy to use interface by which site editors could maintain their content without writing any html. I began prototyping and testing cycles with users.

I also worked closely with our lead developer to understand what was feasible and any drawbacks that we might have to work around. Unfortunately, we didn't have time to create a seamless experience for editing existing images. Users would have to use the standard edit interface to do this. We could offer them a direct link to accomplish this though.

Solution

• Visual updates as you typed
• Drag and drop features to place content, replace or reorder
• Efficient data calls for rapid asset loading
• Create content wizard
• Content libraries for each component type
• Timely and meaningful notifications on success or failure
• Integrations with standard editing environment

The newly created components adhered to the established design system and would have to meet editorial quality standards. This meant the edit interface would need to enforce editorial rules and guidelines to ensure the content would fit the available space, that no content could be omitted by accident, links to asset IDs were valid, only system colours could be used, et cetera.

Once development had reached a point where you could control your content, it was time to perform extensive tests using existing content, all possible combinations of the components, new content variations and empty components.

We uncovered these rules and guideline requirements

• Control number of items in a group
• Ensure only eligible items are available to a component
• Set character limits
• Allow flexible options such as links with query strings
• Share content across sites where the maintainers own both sites
• Set custom tracking attributes
• Provide background colour options

Solution

• Extensive testing to uncover content quality, quantity, spacing, validation, order and omission issues.
• Stakeholder workshops to define editorial rules and guidelines.
• Collaborative design to create interface rules and notifications.