{"id":2707,"date":"2017-06-13T12:46:44","date_gmt":"2017-06-13T11:46:44","guid":{"rendered":"https:\/\/blogs.kent.ac.uk\/webdev\/?p=2707"},"modified":"2017-11-24T13:32:29","modified_gmt":"2017-11-24T13:32:29","slug":"site-editor-feedback","status":"publish","type":"post","link":"https:\/\/blogs.kent.ac.uk\/webdev\/2017\/06\/13\/site-editor-feedback\/","title":{"rendered":"Site Editor feedback"},"content":{"rendered":"

To improve the design of Site Editor (the tool to publish pages in the new website theme), we did user testing on a paper prototype and on some working code with web publishers. <\/p>\n

Overall the feedback we received was positive with many excellent suggestions to help us improve the design.<\/p>\n

Mostly people expect an experience where they can create content quickly and intuitively<\/strong>.<\/p>\n

Some support and training to use the system should be available\u00a0if needed. Training\u00a0topics which\u00a0focus on creating great\u00a0content, which are easily accessed when editing, were\u00a0welcomed.<\/p>\n

There is an urgent need for the basic functions of the Site Editor to replace Dreamweaver, but we need to balance our resource and time with the features we can deliver.<\/p>\n

We’ll be\u00a0prioritising our findings and will then work\u00a0on refining the user interface design and interactions.<\/p>\n

In a few weeks time, we’ll get more web publisher feedback to follow up on the feedback – we’ll keep you posted.<\/p>\n

For those interested, technical feedback follows below.<\/p>\n

\n

Paper prototype<\/h2>\n

A paper prototype is a quick way of exploring ideas as part of an experimental\/alpha phase<\/a> before you decide which features are needed.<\/p>\n

By using a low fidelity, it helps to focus on concepts and tasks, rather than the visual design detail.<\/p>\n

1. Starting points<\/h2>\n

\"\"<\/a><\/p>\n

People liked the concept of a\u00a0starting dashboard.<\/p>\n

Selecting a site<\/strong> – was straightforward.<\/p>\n

Recent updates<\/strong> – liked the ability to see what state the content\u00a0from themselves or their team was in. Useful if someone was on leave and makes it easy to return to\u00a0work that you were busy with.<\/p>\n

Labelling needs careful consideration<\/strong> – we need to clarify a workflow and page status labelling which could be ambiguous.<\/p>\n

Training and support<\/strong> – this should not be an after-thought that we\u00a0throw at people because our product and workflows are not user-centred. It needs to be a meaningful addition to an easy-to-use product with topics focussed on creating good content, such as mobile-first concepts, using\u00a0imagery, audience needs, writing for the web\u00a0and accessibility.<\/p>\n

Some people like to learn via trail and error, while others prefer a quick start overview.<\/p>\n

Overall, it needs to be intuitive enough so that people can just get going quickly<\/strong>.<\/p>\n

“I’m a have-a-go kind of person”<\/p><\/blockquote>\n

2. Choosing a template<\/h2>\n

\"\"<\/a><\/p>\n

People liked the idea of having a template to start with.<\/p>\n

Templates will need to serve a specific purpose relative to the content being created.<\/p>\n

We currently have feature, navigation and content pages<\/a>. These may need refinement and further description at the point of choosing. Being able to show, existing examples is important.<\/p>\n

Page\u00a0purpose and meta data<\/h3>\n

As there is a maintenance cost to everything added to the site, we want publishers to be frugal and questioning.<\/p>\n

The ‘page settings’ screen was to help publishers\u00a0think about the purpose and value of the content they are going to create, as well as to provide some meta data.<\/p>\n

Selecting an audience type\/priority<\/strong> – useful, but probably be\u00a0ignored over time.<\/p>\n

Defining outcome\/need\/purpose<\/strong> – good exercise in thinking about the need to create a page. If the page is within a user-journey flow, where would it link to?<\/p>\n

Review\/expiry date<\/strong> – a\u00a0concept where there is a way to review content was welcomed.<\/p>\n

The word ‘expiry’ scared a few people, but ‘review’ was seen as less drastic. If this resulted in receiving lots of emails, they may be ignored.<\/p>\n

A good\u00a0suggestion was that of a six month stats review email, which showed best 10 and worst\u00a010 performing web pages, might be more practical.<\/p>\n

There was a\u00a0good suggestion\u00a0that filling in page settings first, followed by a suggested\u00a0template, would be better approach.<\/p>\n

“Good idea in principal, but could be annoying and ignored”<\/p><\/blockquote>\n

3. Editing concepts<\/h2>\n

\"\"<\/a><\/p>\n

 <\/p>\n

Navigation<\/strong> – the interaction as to how you navigate the site structure and create a new page was understood by most people, but how you add a page within the hierarchy needs thought, as this could be confusing.<\/p>\n

Workflow<\/strong> – there was some ambiguity about the workflow. What is a preview? What is a draft? When is my content live? Do we still have test? How does this differ from a version or a copy? And is a mobile view content somehow different to desktop? Clearer visual cues as to the page’s status in the workflow would be good.<\/p>\n

Versioning<\/strong> – there was some confusion about what versioning meant, how it might work and its differentiation from archiving. Some people wanted a way to show different content at different times and thought this referred to a different version.<\/p>\n

4. Site Editor\u00a0(work in progress)<\/h2>\n

\"\"<\/a><\/p>\n

The Site Editor interface has not been refined at all, so the testing was quite raw.<\/p>\n

“Editing in place helps take away the guess work”<\/p><\/blockquote>\n

Hover and selected states<\/strong>\u00a0which outline an editable block are identical. This created some confusion. It was unclear if an element was editable or not.<\/p>\n

The visual design needs to give clearer feedback as to what is active and editable in the right-hand panel.<\/p>\n

Editing in place<\/strong> – everyone wanted to click directly on an element and edit in place. They didn’t initially spot the editing interface which appears in a right-hand panel.<\/p>\n

Text editing options<\/strong> – we should have only the editing options that you need for a given component, they should be context sensitive. For example you were able to add horizontal rules to a quote and this broke the quote.<\/p>\n

Also the ability to copy and past from Word into Site Editor, and then for Site Editor to strip Word formatting would be great.<\/p>\n

“I just want simple options\u00a0for the layman”<\/p><\/blockquote>\n

Adding new elements within\u00a0a content block<\/strong>\u00a0– this confused many. There was an option to add additional ‘cards’. As the system never gives feedback once this has happened, it isn’t clear that anything has changed.<\/p>\n

Labelling and input order<\/strong> – labels were unclear and the input order should follow the visual order of the item being edited.<\/p>\n

Image upload<\/strong> – everyone was able to do this task. There were questions about where images might live (image library) and how they need to be prepared. How will we deal with digital asset management?<\/p>\n

Help\/support<\/strong> – there were comments that it would be good to have support\/help links by the input fields – for example image editing, accessibility tips, content style guides to make them easy to find and access at the point\u00a0you need them.<\/p>\n

Saving<\/strong> – there was confusion as to whether work had been saved or not. Having two save button is confusing. A suggestion of an autosave was mentioned as a good option.<\/p>\n

Adding new content<\/strong>\u00a0– everyone struggled to find the place where you can add a new content block, there was no clear labelling to find this. Most got the concept of dragging and dropping content on the page.<\/p>\n

There was no feedback that the dragged element had gone to the bottom of the content so the user didn’t know that it has been added. Also would be good for the block to appear on the area of the page that it was dropped on.<\/p>\n

Changing position of content blocks<\/strong> – not all users were able to do this task. It wasn’t always clear that you had to click directly on the up\/down icon to move the panel.<\/p>\n

“You only find out by clicking around”<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"

To improve the design of Site Editor (the tool to publish pages in the new website theme), we did user testing on a paper prototype … Read more<\/a><\/p>\n","protected":false},"author":17235,"featured_media":2709,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1,79395,1220,79421],"tags":[79484,79412,79411,23153,79392],"_links":{"self":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts\/2707"}],"collection":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/users\/17235"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/comments?post=2707"}],"version-history":[{"count":38,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts\/2707\/revisions"}],"predecessor-version":[{"id":2756,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts\/2707\/revisions\/2756"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/media\/2709"}],"wp:attachment":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/media?parent=2707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/categories?post=2707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/tags?post=2707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}