Responsive CMS interactive mockup

[Paul Clarke]

I have created a interactive mockup for a responsive menu and two different options for how the preview could work. It would be great to get some feedback on those interactions (either here, or directly comment on the mockup). Open to suggestions.

https://invis.io/ZH7XCBCXV#/173199939_Responsive_Menu-Pages

[Mark Muller]

Hi Paul,

For me version two, however I would be concerned with the bottom bar being crunched on smaller devices maybe a combo of the two for small/medium devices? So version one for phones and quick dirty edits, and version two for phablets/tablets?

Just a thought.

Regards,

Mark

[Jonathon Menz]

I like version two better too. I find it more intuitive and I think the Preview button gets the weight it deserves in that design as an important action in the workflow. In version one users may not notice the action as they don't use the Settings or History tabs very often (in my experience).

A caveat... although I like version two better I worry it will confuse users if they make changes and hit the preview button before saving the changes. I would expect from that interface that it would be okay to do that and that I would see the changes I have made reflected in the preview, not the state from the last time I saved. So maybe in that case when you open the preview we need a little warning saying "You have unsaved changes. [Save and refresh preview] / [Dismiss]".

Regarding Mark's concern about space for buttons, where necessary icons could be removed or a button could become icon only where space is tight so I think the design should work okay on small screens.

[Sam Minnée]

I tend to prefer version 2 better, although I definitely think that they'd benefit from some user testing with some copywriters / cms users.

One thing that occurs to me is that if the typical usage flow is this:

 - Make a change

 - Preview it to make sure it's right

 - Save / publish it

Then should we have the save/publish buttons available somewhere from the preview screen?

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Sam Minnée

CEO

SilverStripe Limited

[Paul Clarke]

Often the first step is preview (or review) even before edits are considered, that is why I was interested to see if moving it from the end step, to any step in the process. For example changing the settings of a page or adjustments to files outside of the edit panel could also effect the appearance of the page.

I think that most of the reviewing happens while still in the edit view (edit, save, review, edit, save, review...), while preview is usually the first and last step, almost what we would consider browser testing. 

I like the idea of adding just the publish button to the mobile preview and fullscreen preview for larger devices. 

Obviously the second version is closer to the current desktop experience so I would be wanting to keep them as similar as possible, but it is always good to have a comparison for testing purposes as it help make a learn something new in the process.

The next step will be testing with actual users of the CMS, so this is an opportunity to get in a couple more tweaks before this happens.

[Jonathon Menz]

Maybe the button label needs to be something other than 'Preview'. That label to me implies that you can view changes before you commit them (by hitting Save or Save & Publish), but unless something is changing in SS4 it's not accurate. Maybe if there are no saved draft changes the button could say "View" and if there are saved unpublished changes it could say "Review"? In the latter case you could display a Publish button on the next screen as Sam suggested.

[Paul Clarke]

Some interesting ideas there, I will have a play to see if that makes sense in practice.

[Michael Strong]

I prefer version 1. The reason being that I think it makes more sense to keep the navigation in one place (header) and actions together in the footer. It also looks a lot less busy than version 2.

On 15 July 2016 at 12:42, Paul Clarke <pa...@silverstripe.com> wrote:

Some interesting ideas there, I will have a play to see if that makes sense in practice.

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Michael Strong | Developer
SilverStripe
http://silverstripe.com/

Phone: +64 4 978 7330
Skype: micmania1

[Naomi Guyer]

I prefer version 1 as well, for similar reasons to Michael. If version 2, perhaps the button could be more subtle? Though, even knowing it lives there on desktop, it took me longer to find it in the footer than in the header. User testing of both would be a great idea. :)

Cheers

Naomi

[Paul Clarke]

I've updated the concepts from some of the ideas mentioned in this thread and progressive enhancements based on user testing. 

[Mark Muller]

Hi Paul,

From those, Version 1 is definitely my preferred choice for all devices. Taking Jonathon's idea a step further 'Review' could be 'Review changes?' or 'View changes?' in the notification. As 'Review' would make me want to add one to five stars for the quality of the page content being published ;)

Looking good either way though tbf.

Regards,

Mark

[Richard Rudy]

While I  genereally prefer Version 1, as a designer I know how problematic adding CMS chrome to the top of the page can be. The CMS chrome at the bottom of the page (Version2) is less likely to conflict with site designs, unless you're rendering the page in iframe (like the current preview).

[Jonathon Menz]

Really liking the revisions to the review screen in both versions. With the addition of the pop-over 'Review' hint you've added I like version 1 best now, think that is looking really good.

[Paul Clarke]

Text updated to "Review changes" and "View changes".