Decluttering the CMS interface

[Stevie Mayhew]

Hey all,

I've had a lot of positive feedback about the way which we declutter the interface for users of the CMS, making sure that they only have access to things which the need to be able to see and removing the site tree completely for most clients.

I was wondering if any of you have similar experiences which can be shared, or thoughts about perhaps including some of this type of functionality in the core of SS to make administration easier for people?

You can view a talk about the issue here: https://vimeo.com/119727130

Cheers,

Stevie

[Cam Findlay]

Cheers for this Stevie, In some older 2.4 Sites I used to use a module called "simplify" to give the client less things to break/things to worry about.

It was pretty configurable as to what you could selected to remove for the client to see (and an admin still had full access).

I still like the SiteTree when setting up the structure of a site initially however once that is done it's pretty unlikely people will need to touch this, instead they'll be adding content to known areas of the site.

So this approach is really interesting.

[Zauberfisch]

I have similar experiences with my clients.

most of them will only use 25% of the CMSs functionality.
So I hide some of it, and others I tell the users "its there if you need
it, but you can probably just ignore it for now and ask me later if you
need any help with it".

In fact, I even had positive feedback from clients after hiding certain
features. They felt that the CMS has become even more easy/clear after
removing some features they did not use (either by using DataObjects for
many objects or limiting Page eg by removing fields such as PageType
dropdown, Access settings and sometimes even history)

And with less features, the requirement for training the clients to use
the CMS drops dramatically.
And further more, as stevie already pointed out, it also reduces
maintenance, because clients break less.

I really like what stevie shows in the talk, though I in many cases that
might be to stripped down.

but I would generally appreciate a slimmer CMS, with those extra
features being added by optional modules.

> https://vimeo.com/119727130 <https://vimeo.com/119727130>
>
> Cheers,
> Stevie
>
> --
> 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
> <mailto:silverstripe-d...@googlegroups.com>.
> To post to this group, send email to silverst...@googlegroups.com
> <mailto:silverst...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/silverstripe-dev.
> For more options, visit https://groups.google.com/d/optout.

[Ingo Schommer]

Hey Stevie, I'm very impressed with the attention to CMS user experience you guys have at Little Giant! Maybe you follow that up with a blog post explaining how to use the various modules? Cam, might be interesting for ss.org?

The single page admin is a nice solution for a fairly common CMS problem. It might even be common enough to add core support for a "singleton page type" like the homepage, search results etc. - at the moment, we basically encourage fragile logic by allowing authors to delete these pages, move them, or create duplicates.

Grouped CMS menus were originally envisioned for the 3.0 release, and just dropped due to time constraints. The grouped-cms-menu module seems to fill that gap well though. Maybe we should add a mention to it in the ModelAdmin docs? That's the main set of controllers where grouping becomes a topic usually.

On a longer perspective, I think there's great opportunity in finding a way to de-emphasise the tree UI in SilverStripe. A lot of the CMS UI implementation complexity comes from the fact that we show a complex DOM/JS structure side-by-side with the editing interface, which makes us jump through all kinds of AJAX/PJAX hoops to retain UI state. Many modern CMS UIs get away without much JS and full page loads by separating out the structure from editing UIs. Would need careful user testing of course, and might not appropriate for large sites with deep IAs, but worth exploring.

Getting there can take many shapes, such as a faster way to find/select pages through autocomplete+breadcrumbs, or by making it easier to create specialised list based management areas such as "news" with the full CMS features such as history views. Incidentally, these are areas we can push independently of large CMS UI core changes :)

Ingo

an email to silverstripe-dev+unsubscribe@googlegroups.com
<mailto:silverstripe-dev+unsub...@googlegroups.com>.
To post to this group, send email to silverstripe-dev@googlegroups.com
<mailto:silverstripe-dev@googlegroups.com>.

Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.

Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi Stevie 

Super inspiring talk.  Here are a couple of little notes:

1. having the full CMS access and a super simplified version available would be awesome.  Even for one user. The former you use every now and then and the latter is for quick changes without much thought (simplified can't go wrong).

2. There are a few things in the CMS out of the box that to me could be done better. For example, as you mentioned, the Security section is sometimes hard to understand.  There are some improvements I am sure almost all of us would agree on. 

3. Like Ingo, I love your concept of One Page editors (e.g. HomePage).  I almost wonder if this should be part of the basic CMS as this is such a CLASSIC concept.

4. I wonder if it would be worthwhile to set up something like a group of folk who are interested in improving the CMS user experience as this often hard to do with a couple of pull requests and also because at times discussion in this area will stifle good ideas.

Thanks again for sharing.

Nicolaas

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.

[Marcus Nyeholt]

Another +1 for the presentation. It's something I see happening in a few client implementations, but more as a reactive process than a pre-planned idea. Will try and keep it a bit more front-of-mind during planning and requirement sessions though!