Content considerations for developers

Senior Developer
Valtech Netherlands

setembro 26, 2018

Yesterday I gave a talk at the Dutch Optimizely Meetup about content considerations for developers. What may seem logical to a developer… it might not be for an editor.

Together with my colleagues Kim Sterenborg and Pim Sebok, I have created a list of 12 tips for developers to make content editors more happy, based on their experiences. They might seem very obvious… but apparently they are not.

 

Involve

  • Involve the PO or the content editor(s) when creating templates and blocks.
  • Make the “ease of use” part of your acceptance criteria.

Mirroring

  • Try to mirror the front-end and the back-end of the website.
  • The order of the fields should be the same in the CMS and the live environment. E.g. first put the pre-title, then the title and then the subtitle.

Field size

  • Make text fields big enough so you can read the text that’s in it.
  • E.g. use a UIHint.Textarea attribute for a, plain, long text string.
  • You can use custom CSS to make textboxes bigger.

Maximum length

  • Think about setting a maximum on characters for some fields. This is to prevent people from putting endless sentences in title fields for example.
  • Use the StringLength attribute where appropriate, does not work on XhtmlString properties.
  • Nice UI extension to show statistics (https://gregwiechec.com/2016/05/textarea-with-statistics/)

Naming

  • Set the DisplayName property of the Display attribute.
  • Give display names logical names. They should be clear to content editors.
  • Avoid technical names if possible.
  • Use localization if appropriate.

Supply instructions

  • Use the Description property of the Display attribute for instructions, to clarify the use of the fields.
  • With custom CSS file the description can be displayed below the name.

Structure

  • For “long” pages / pages with a lot of properties, it helps when the fields in the CMS are scannable.
  • Create a block for large sets of properties that belong together, and use the block as a property, this will give you a header.
  • You can also use a separate tab if appropriate, make sure you don’t get an endless row of tabs though and check which tab the editor wants first.

Content areas

Blocks and templates

  • When creating new functionality, consider both blocks and templates. Sometimes templates are ‘abused’ by editors by adding an unlimited amount of blocks. Limit the amount of blocks that an editor can add.
  • Make sure the aim of a template is clear so that you know which blocks should be made available for the template. Limit the types of blocks that an editor can add to that template.
  • Creating a new template for a specific goal can be the wiser decision.

Manageable content

  • Make sure all editorial content is manageable in the CMS.
  • Avoid hardcoded content if possible.

Content and settings

  • Think about the difference between content and settings and make sure they are organized logically. E.g. should fallback images be put on a content page or in a settings tab?
  • Have / choose a “unified” system. Separate setting blocks / functionality, a settings tab on the start page for global settings, settings on a block for specific block settings. Make it consistent.

Icons

Like I said, the list might seem very obvious…. but I think there are quite a few projects that aren’t as easy to manage for a content editor as they could be.

Article originally published on Optimizely Development blog: Content Considerations for Developers

Casos Recentes e Insights com a Optimizely

Caso

Forex

Insight

A importância da experimentação

Whitepaper

The digital experimentation playbook

EVENT

Refining digital excellence: When art meets science
Descubra mais em nosso Hub de Conteúdo
Contate-nos

Contate-nos