Skip to content

Author Admin UX Scratchpad

Jump to bottom
Eaton edited this page Oct 24, 2018 · 2 revisions

High Level Problem Areas

  • Previewing work in progress (lots of ways to slice this, but it's a consistent frustration)
  • Content Type Selection (On sites with more than a few types, many authors are unsure which is the right one — and they often just pick the simplest one, regardless of its appropriateness)
  • Managing Hierarchy/Organization
  • Managing clusters of linked nodes, finding nodes you want to link
  • Making the same change to many things at once

Tasks/Scenarios

These are example usage scenarios with a bit more context than "create a page" or "add an image", which tends to be pretty streamlined already.

  • Creating a new piece of content from an offline source documents (word files, emails, print docs)
  • Checking to see if content is correct before publishing it (copy, image cropping and composition, visual layout, display info generated from metadata, etc)
  • Reviewing, approving, and potentially publishing another person's work
  • Changing/customizing the authoring/management UX
  • Choosing the right type of content to create
  • Laying out a custom, one-off promotional page
  • Creating and updating an index/hub/landing page for a site section or topic
  • Finding a piece of content to edit
  • Finding occurrences of a link, string, or other piece of content around the site

Potential Phase 1 Improvements

Most of these are changes to the existing administrative interface that could be made regardless of the React work, but might be good compliments or easy wins.

  • Left and right sidebars as part of form layouts? (Let site builders customize them more extensively, ensure they aren't baked in?)
  • UI for Form Build Mode activation (i.e., when should a build mode be used) In current mockups this is selected by the editor during the editing process, but in real world use cases it's likely to be managed by context. Do we want to address this?
  • Autosave / Partial Save (This would be a blocker for required-for-state in core — wouldn't that be a big win?)
  • Better Node Type Selection screen (We have some mockups that could help with this; in larger builds we often see confusion about what type is right/default to the one they know)
Clone this wiki locally