Now that Viviti is rolling along with full beta steam, we're getting a lot of feedback and I find myself re-thinking parts of the user interface design. I thought it might be interesting to discuss my thinking while re-designing the editor toolbar.

In order to understand my thoughts on re-design, I'll need to briefly explain my thoughts on the initial design.

How Viviti Works

Viviti is a web site creation tool and content management system that let's users create a web site without writing any code. A Viviti site is made up of pages, which contain content locations, which contain content components, which contain actual user inputted content.

Viviti is an Inline Editor

Users can point at and click on whichever content component they would like to edit on Viviti, so the most direct way for a user to add content to a blog or photo gallery is to point at it and click the appropriate button when it is highlighted.

Site Specific Actions vs. Page Specific Actions

I usually begin designing an interface by laying out use cases on paper, what I like to call user actions. These are things a user may do with the site.

Originally I decided to differentiate Site Specific actions and Page Specific actions by way of a color variation on the toolbar:

In this image, the Manage drop down on the darker background is for performing Site Specific actions, and the options on the lighter background are for performing Page Specific actions. I've noticed a few problems with this approach.

The Problems

  • The Add Content button is misleading to users who want to add content such as a blog post or photo to an individual content component, rather than adding an entire content component such as a blog or photo gallery
  • No easy way for a user to add a single image to a page
  • The Settings and Delete buttons are not clearly defined as Page Specific rather than Site Specific and therefore are misleading to some users

Solving the Problems

To add a single image to a Viviti page, the user needed to be able to add an Image Component to a page with only a single image inside of it.

Our Add Content button would have popped up a dialog offering a number of content components available such as blog, rss, images, and more. Users who clicked the Images Component in the popup dialog were confused as the options presented to them were for adding an entire thumbnail gallery of images and not just a single image.

I resolved this by replacing the Add Content button with three smaller, but more direct buttons and a more accurate description:

I decided to highlight the Add Image and Add Text buttons because those are the first and currently most commonly added content components.

These buttons contain only icons, which isn't as clear as text, but the icons are fairly standard across operating systems and word processing software so I figure (hope) they will be received warmly.

Now it's clear in a users mind that to add an image or text to the page, this is where they click. It's also clear that to add more, they click the more button.

Content Components vs. Actual Content

The current method of inline editing is great for adding blog posts to a blog component, even photos to the photo gallery component, but what about when a user wants to sort through 100 comments on a single a blog post in a specific page and approve, delete, or feature them as needed? Should we force them to navigate to that page, click on the blog component, find the post in question, and then scroll through the comments, managing them as needed? This method seems a bit cumbersome.

In order to solve this issue, I needed to consider that content is not necessarily page specific; A user can add blogs (content components) to multiple pages, but they can display the same blog posts (content).

I figured that to speed up editing mass amounts of content, the user needs to have access to a central content repository or database, therefore I created a My Content dropdown in the Site Specific area of the toolbar.

Now the user has a place to go where they can manage content without needing to navigate to it directly or edit it inline. This re-inforces the idea that the Page Specific area of the toolbar allows them to add content components to pages, but they need to edit those components to add real content to them.

Here's an example of what the user would see if they clicked Manage Blog on the new My Content dropdown:

Additionally, by renaming the Manage dropdown to My Website, we've clearly differentiated between items relating to the web site as a whole, and items relating to content and pages.

In order for the My Website dropdown to be accurately named though, I made a few more changes:

  • I removed the Manage Theme option and replaced it with a Choose New Theme option
  • I moved the Customize HTML and Upload Theme options out of Manage Theme and into their own dialog named Edit Source Code to dissuade non technical users from clicking on them
  • I added a Domain Names option to the My Website dropdown rather than having DNS Settings inside the Website Settings option

Finishing Up

I'm hoping that my thinking on these issues will make things a little more clear for users of the Viviti web site. After the changes are launched, I'll monitor user feedback and write a follow up to let you know if they are successful.

If you'd like to thank me for this article or if you disagree with any of my thinking, please post a comment below. Also, please Digg this if you feel so inclined.