I'm currently working on a new project and I'd like to hear some ideas on how you make sure the backoffice is as user friendly as possible. I know we can just throw everything in and as a developer we know it works, but, I really want to make the user experience nice and intuitive.
I know all projects are different but what are your common tasks / plugins / features you implement on most projects for your clients?
There's so much I can add here but I think you'll get a lot of chat on this so I'll keep it brief.
Use descriptions when you create properties and make them nice and conversational.
Keep names consistent across doc types. Don't use a 'Body text' on one that is a 'Main body' on another.
Labels are a really under-appreciated property type.
Keep tabs to the number you can comfortably view along the top, no more.
Think before you use a checkbox. It's something you may come to regret as the site grows.
Pick one system to architect the tree. I've seen sites that use child nodes in one section to pull content into a page, grid in another and nested content too. Pick one and then work out what's scalable.
Use icons!
Make them colour coded where poss.
Never allow the editor to do much more than they need to. If you don't reeeeally want a blog page to be created in the news section, don't allow it. Also, remember that you can allow and then disallow node creation, something I've found really useful upon set up. I want just the one landing page under here, I'll allow so I can create and then take away the privilege later.
Compositions make for a nice bit of consistency across the site and for a nicer user experience as a result. The more granular, the better so you don't end up with that intro field, for example, that is useful on one page but not another.
Zendesk Chat Plugin ~ Remind them again how to do it, this time in real time
Notely ~ I didn't know this one existed until now - will be looking further into it and will report
Other than that, try to think like an editor and even have user testing with others trying out your UI, unless there's an NDA and then maybe ask a very close friend what they think without showing them...
uEditorNotes is possibly one of my favourite editor help techniques. I've not yet used Tours but I can see that being helpful, particularly for onboarding new editors.
If you are creating your own custom editors, make sure you keep them as simple as possible to the editor to use. Remember to style them! It may sound stupid but if a custom editor looks bad it can be discouraging for editors to use.
Keep things logical, use error messages appropriately. Descriptions are great (as Emma says), especially for highlighting optional / required content (Don't do both pick one and be consistent).
If you have control over how they prepare content (do they use word docs etc), can you tailor their pre-entry processes to flow with the actual input, or do you need to have your input in the same order as their existing pre-entry process.
Overall, my biggest advise is, ask yourself when you look at it would you get annoyed using it if you had to every day for the next 6 months? If so, why, how can it be improved? We as developers are actually good at this when we stop and think, but as you say we do like to just throw things together. Just takes a couple of minutes to think and refactor and you'll find it makes a huge improvement.
Finally, Ask the editor after they've been using it for a bit, or even when you are first thinking about it. They will be able to give you the best advice.
What works very well for us is to get a dev to demo every feature/card/thing each morning to the PM and/or a content editor and show how it has been implemented.
There is nothing better than getting it in front of a 'real user' as they usually think differently to developers (no offence!)
So test, test and test again with a real user who will be using it on a day-to-day basis and see how they get.
And of course taking all the things Emma and John have said into consideration will get you on a good path to start with.
Great replies so far everyone - this is super useful and never thought about a number of the suggestions.
When it comes to actually designing the back office how do you decide what to do.
e.g. I've looked at building everything within document type and then using tabs to guide the user in to entering the info via Nested Content but I've also seen component folders under the parent and the 'modules' that are placed in this folder make up the content of the parent page.
In my experience a lot of our editors found the component folder approach more confusing, whether that is true with all users I couldn't say as no two users are the same.
I personally always lean towards Nested Content for that if the blocks are simple. If it's a bit more complicated, or you want multiple tabs on the block, I am really really liking the use of Stacked Content instead.
Alongside being able to offer a meaningful preview of each element seems to keep my editors happy.
Hi Anthony,
I was looking at the Nested / Stacked Content option but the biggest issue for me just now is, I can't get my head around how this would work in practice. Do you have any demo screenshots you could share?
Will try and pull you something together over the next, have been tempted to write a blog post about how the editing experience has changed on our sites as time has gone by.
This should be the kick in the butt I need to finally do it!
Good question. I think it depends on how content heavy we think the site will be. Nested content works beautifully for something that's going to be heavily segmented in terms of content.
For re-usablity though, you'd want to go with node inside a repository. Often, sites will grow beyond anything you imagine and sometimes clients feel they are going to be a lot bigger a lot sooner than they think too so there's an element of guess work.
Resuability is really important as this project may become a baseline for future projects. So it will have common parts in it which can be reused.
Hmm, lots to think about but node inside repo may be the way forward - does this work Ok with the preview button? Heard mixed reports where the preview button doesn't work very well in this case.
Jumping in on the "baseline for future projects" bit... I may have said a few times in the past about being careful with Starter Kits. It's very tempting for a development team to want this (mostly for speedier project starts), but it can be a trap.
@Owain, not sure if you'd seen our CG18 talk? https://vimeo.com/273473715
There's a part where Marc and I discuss Starter Kits and how they end up shaping your client's requirements rather than building to their needs, (or something like that) ;-)
As for the overall topic, I'm in agreement with many of the replies - quality knowledge!
It works fine for me, yes but if you come across that problem, maybe we can compare notes?
It is fantastic for re-usability. I'd love to know if there's another way that's just as user friendly though because it does feel a little old-fashioned at times? Not sure that's the right phrase but I do wonder if there's a better way out there that I'm missing. Let me know what you decide upon!
Reusability is always of high importance for us as developers, however - don't get lost in that for this project - keep it in mind when you're scaffolding things together but remember, get the job done and you can come back later to tweak for the next!
*This is coming from a guy who goes down that rabbit hole often! ;-)
So many great replies already and many of them covering the exact same thoughts that I have.
I just want to mention a tiny detail - If you need to make use of a rich text editor take care to configure it properly only allowing the editor to use those parts that makes sense. So leaving out macro insertion, image insertion, indents etc. if it's not something that the editor will need - Otherwise it will just cause confusion and if you don't want them to insert an image using RTE but have the option visible then rest assured that the expect they can do it this way and they will get disappointed to see that the design does not work so well with that image they picked in the RTE :-)
Also make sure to adjust the height of the RTE. If it's intended for an abstract then adjust it to a height of something like 100-200 pixels instead of that 500, which is standard.
It might be possible you'll need another instance of the RTE with one or more options added than your initial configuration but then make a new instance that suits the purpose instead - Thereby only presenting the relevant options for the editor in the given context.
Even thought these articles were written before v7 say the day of light the essence of them still holds true today in my humble opinion so they're still worth a read
Don't overuse the 'repository' pattern. The repository is there for them to be able to use some content. Simplifying what they need to do sometimes works better than having a repository.
For an editor being able to find what you're looking for at a glance is key. Had a case where client wanted to be able to see an advert's position and scheduled start and end date, without having to expand the nested content so we added a preview of this data on one line, small change, massive time saver.
Similarly in the grid - having a preview of the actual content (rather than 'Title' for example) without having to actually preview the entire page (I second the notion that 'preview' function isn't great - often shows totally different content to what is actually there) or click into and open up the module to see what the title field is populated with. It seems when it comes to images or videos, these are usually always previewed in the grid, but often for text fields this isn't the case - of course if you have a large piece of text you might not want to preview the entire thing but even a snippet will help massively to navigate the grid quicker and easier.
Might be something really small but it's nice having a navigation title field to over ride the page name - especially on multilingual sites I often found myself naming a page something to help me find it in the tree which you wouldn't want to appear as the page URL, or keeping the tree in English which without the over ride field means having to go through the entire tree to translate it just before go live - not ideal!
Already mentioned by Emma but I second ensuring that field descriptions are clear and written in editor-friendly language, and if something is a required field always add an *
Echoing Jon's comment - Personally, I'm really not a fan of macros in rich text editors, especially when they are used to insert images, I find them so annoying, moving text around them is like trying to maneuver a wet bar of soap
Whenever I'm working with the content repository approach I usually add the option of creating folders.
By having folder it's possible for me to have "DIS/PLAY" folder (The name of my company) because it makes it easier to delete my test/dummy content once the project is ready for the real content. Even though I always try to implement the sites using real-world content - Even though content often is not ready I find it a good approach to then use text and images from the existing web project. This approach in my experience has at least 3 benefits
The client can relate to the content used when presenting them with the implementation before they take over the site
As a developer you often catch those edge-cases that nobody thinks about when the site is just a static design
No unfortunate situations where there are only gibberish texts like "Heeere comes Jonny!", Lorem ipsum or whatever you come up with. This does not always go down well with clients and content editors and I'm all for avoiding situations like these :)
Media
The media section is really bare an empty before implementation starts. Lately I have begun to create 2 root folders - One called "DIS/PLAY" (Our company name), which is used for the images and files we use when implementing and then a folder based on usually the name of the client so it would be "Heinz" if my client was Heinz for instance. It's not though ;-)
The I usually create subfolders named "Images", "Videos", "Files" etc. - This way you at least do your best to help the editors on the way by leading the way with a minimum of structure in the media archive. And when educating them in how to manage content it's just easier when it's already setup like this in my experience.
This approach also has the benefit that you can set the start folder for the editors to the client folder, which means they will never see or be able to touch your own folder. This ways you avoid clutter and mess to build up over time since developers and editor don't use the same folders in the media archive :)
If you have some elements that are a yes or no (true/false) where there some that are usually yes and some that are usually no, don't just use the one datatype for both.
Make 2 datatypes with different defaults. It saves a few seconds, but one editor was gobsmacked with this, as it makes their life easier.
I also use Switcher to create more friendly and obvious toggles with explicit labels.
Remove most options for the RTE. Especially images. Images work better in a NC module or as a simple media picker. Trying to account for fluid text wrap is not friendly and developer intensive to tweak.
Use content blocks with Nested Content (I prefer NC over Stacked Content as I don't like the dialog input in SC). However I like that SC can have multiple tabs.
Compositions for re-usable bits. Inheritance always goes wrong for me.
A separate 'Site Settings' node instead of hiding all the options in tabs inside the 'home' node. Site Settings nodes says what it does. I also add sub-nodes to the settings when it makes sense. Great place for global stuff like social media.
Vorto All-The-Things when localization is needed.
Allow for the RTE to compose email templates (but again limit the options). I really want to make a PE that allows for tokens like {{putLinkHere}} and includes validation.
Would like NC/SC to include more optional controls (e.g. disable, copy) but that's an argument I've lost before :P
Very few 3rd party packages needed these days. My top picks:
Well, I've spent the day reading your comments and watching videos, reading articles about Atomic Design and trying to work out when I would or should use Nested / Stacked Content, Component layouts or throw it all into tabs! My mind is bursting and I'm not sure I am any further forward!
Tomorrow is another day though and I may have an eureka moment when I least expect it.
I've the designs to look at now so this may help me chop up each component and work out how I will implement them in the back office.
Thanks for all the comments and I welcome any more if people have more thoughts on this subject.
I know I'm a bit late to this discussion, but there's a very good A List Apart article which discusses this (and largely includes a lot of the recommendations mentioned above): https://alistapart.com/article/training-the-cms
Just finished reading the thread and I agree with pretty much everything that has already been mentioned.
One thing I don't think I came across in the previous comments, is to listen to editors on a regular basis after a solution has been delivered to the client.
My simplified view of how most agencies and clients perceive their projects is that the site/solution is done when delivered to the client, but before it actually starts being used.
I think it is very common that editors are not aware of how much customization is possible in the backoffice, and just "live with" the small annoyances they have to work around every day. In my opinion you could learn a lot about what makes your backoffice more user friendly by scheduling a follow-up session or two with key members of the clients' team.
This will help editors understand that their editing experience is not set in stone and make them take note of where their workflows could be improved.
It will require some extra time, but I am certain that the clients will appreciate it and gladly pay for the extra hours that could potentially save their content editors a lot of time in the long run.
How do you make the backoffice as user friendly as possible?
Hi everyone,
I'm currently working on a new project and I'd like to hear some ideas on how you make sure the backoffice is as user friendly as possible. I know we can just throw everything in and as a developer we know it works, but, I really want to make the user experience nice and intuitive.
I know all projects are different but what are your common tasks / plugins / features you implement on most projects for your clients?
Discuss :)
O.
There's so much I can add here but I think you'll get a lot of chat on this so I'll keep it brief.
Use descriptions when you create properties and make them nice and conversational.
Keep names consistent across doc types. Don't use a 'Body text' on one that is a 'Main body' on another.
Labels are a really under-appreciated property type.
Keep tabs to the number you can comfortably view along the top, no more.
Think before you use a checkbox. It's something you may come to regret as the site grows.
Pick one system to architect the tree. I've seen sites that use child nodes in one section to pull content into a page, grid in another and nested content too. Pick one and then work out what's scalable.
Use icons!
Make them colour coded where poss.
Never allow the editor to do much more than they need to. If you don't reeeeally want a blog page to be created in the news section, don't allow it. Also, remember that you can allow and then disallow node creation, something I've found really useful upon set up. I want just the one landing page under here, I'll allow so I can create and then take away the privilege later.
Compositions make for a nice bit of consistency across the site and for a nicer user experience as a result. The more granular, the better so you don't end up with that intro field, for example, that is useful on one page but not another.
I think that's all I've got for now!
Other than that, try to think like an editor and even have user testing with others trying out your UI, unless there's an NDA and then maybe ask a very close friend what they think without showing them...
... And everything that Emma said!!! :-D
uEditorNotes is possibly one of my favourite editor help techniques. I've not yet used Tours but I can see that being helpful, particularly for onboarding new editors.
If you are creating your own custom editors, make sure you keep them as simple as possible to the editor to use. Remember to style them! It may sound stupid but if a custom editor looks bad it can be discouraging for editors to use.
Keep things logical, use error messages appropriately. Descriptions are great (as Emma says), especially for highlighting optional / required content (Don't do both pick one and be consistent).
If you have control over how they prepare content (do they use word docs etc), can you tailor their pre-entry processes to flow with the actual input, or do you need to have your input in the same order as their existing pre-entry process.
Overall, my biggest advise is, ask yourself when you look at it would you get annoyed using it if you had to every day for the next 6 months? If so, why, how can it be improved? We as developers are actually good at this when we stop and think, but as you say we do like to just throw things together. Just takes a couple of minutes to think and refactor and you'll find it makes a huge improvement.
Finally, Ask the editor after they've been using it for a bit, or even when you are first thinking about it. They will be able to give you the best advice.
My advice is don't leave it to a developer ;-)
What works very well for us is to get a dev to demo every feature/card/thing each morning to the PM and/or a content editor and show how it has been implemented.
There is nothing better than getting it in front of a 'real user' as they usually think differently to developers (no offence!)
So test, test and test again with a real user who will be using it on a day-to-day basis and see how they get.
And of course taking all the things Emma and John have said into consideration will get you on a good path to start with.
Great replies so far everyone - this is super useful and never thought about a number of the suggestions.
When it comes to actually designing the back office how do you decide what to do. e.g. I've looked at building everything within document type and then using tabs to guide the user in to entering the info via Nested Content but I've also seen component folders under the parent and the 'modules' that are placed in this folder make up the content of the parent page.
In my experience a lot of our editors found the component folder approach more confusing, whether that is true with all users I couldn't say as no two users are the same.
I personally always lean towards Nested Content for that if the blocks are simple. If it's a bit more complicated, or you want multiple tabs on the block, I am really really liking the use of Stacked Content instead.
Alongside being able to offer a meaningful preview of each element seems to keep my editors happy.
Hi Anthony, I was looking at the Nested / Stacked Content option but the biggest issue for me just now is, I can't get my head around how this would work in practice. Do you have any demo screenshots you could share?
O.
Will try and pull you something together over the next, have been tempted to write a blog post about how the editing experience has changed on our sites as time has gone by.
This should be the kick in the butt I need to finally do it!
Good question. I think it depends on how content heavy we think the site will be. Nested content works beautifully for something that's going to be heavily segmented in terms of content.
For re-usablity though, you'd want to go with node inside a repository. Often, sites will grow beyond anything you imagine and sometimes clients feel they are going to be a lot bigger a lot sooner than they think too so there's an element of guess work.
Resuability is really important as this project may become a baseline for future projects. So it will have common parts in it which can be reused.
Hmm, lots to think about but node inside repo may be the way forward - does this work Ok with the preview button? Heard mixed reports where the preview button doesn't work very well in this case.
Jumping in on the "baseline for future projects" bit... I may have said a few times in the past about being careful with Starter Kits. It's very tempting for a development team to want this (mostly for speedier project starts), but it can be a trap.
@Owain, not sure if you'd seen our CG18 talk? https://vimeo.com/273473715
There's a part where Marc and I discuss Starter Kits and how they end up shaping your client's requirements rather than building to their needs, (or something like that) ;-)
As for the overall topic, I'm in agreement with many of the replies - quality knowledge!
Cheers,
- Lee
Cheers Lee - I'll watch this video.
It works fine for me, yes but if you come across that problem, maybe we can compare notes?
It is fantastic for re-usability. I'd love to know if there's another way that's just as user friendly though because it does feel a little old-fashioned at times? Not sure that's the right phrase but I do wonder if there's a better way out there that I'm missing. Let me know what you decide upon!
Reusability is always of high importance for us as developers, however - don't get lost in that for this project - keep it in mind when you're scaffolding things together but remember, get the job done and you can come back later to tweak for the next!
*This is coming from a guy who goes down that rabbit hole often! ;-)
So many great replies already and many of them covering the exact same thoughts that I have.
I just want to mention a tiny detail - If you need to make use of a rich text editor take care to configure it properly only allowing the editor to use those parts that makes sense. So leaving out macro insertion, image insertion, indents etc. if it's not something that the editor will need - Otherwise it will just cause confusion and if you don't want them to insert an image using RTE but have the option visible then rest assured that the expect they can do it this way and they will get disappointed to see that the design does not work so well with that image they picked in the RTE :-)
Also make sure to adjust the height of the RTE. If it's intended for an abstract then adjust it to a height of something like 100-200 pixels instead of that 500, which is standard.
It might be possible you'll need another instance of the RTE with one or more options added than your initial configuration but then make a new instance that suits the purpose instead - Thereby only presenting the relevant options for the editor in the given context.
Even thought these articles were written before v7 say the day of light the essence of them still holds true today in my humble opinion so they're still worth a read
https://24days.in/umbraco-cms/2012/remember-the-editors/ - By Kim Andersen
https://24days.in/umbraco-cms/2012/superhero/ - By Doug Robar
Just my wee 2 cents :)
/Jan
These are really great articles! I don't usually go as far back as 2012 but everything here is still true for me.
A VERY important one I came across recently.
Don't overuse the 'repository' pattern. The repository is there for them to be able to use some content. Simplifying what they need to do sometimes works better than having a repository.
Recent experience from a client.
For an editor being able to find what you're looking for at a glance is key. Had a case where client wanted to be able to see an advert's position and scheduled start and end date, without having to expand the nested content so we added a preview of this data on one line, small change, massive time saver.
Similarly in the grid - having a preview of the actual content (rather than 'Title' for example) without having to actually preview the entire page (I second the notion that 'preview' function isn't great - often shows totally different content to what is actually there) or click into and open up the module to see what the title field is populated with. It seems when it comes to images or videos, these are usually always previewed in the grid, but often for text fields this isn't the case - of course if you have a large piece of text you might not want to preview the entire thing but even a snippet will help massively to navigate the grid quicker and easier.
Might be something really small but it's nice having a navigation title field to over ride the page name - especially on multilingual sites I often found myself naming a page something to help me find it in the tree which you wouldn't want to appear as the page URL, or keeping the tree in English which without the over ride field means having to go through the entire tree to translate it just before go live - not ideal!
Already mentioned by Emma but I second ensuring that field descriptions are clear and written in editor-friendly language, and if something is a required field always add an *
N.B This was my first ever post on 'Our/Arr/Err'!
:-)
Uh! Forgot to mention...
Content repositories
Whenever I'm working with the content repository approach I usually add the option of creating folders.
By having folder it's possible for me to have "DIS/PLAY" folder (The name of my company) because it makes it easier to delete my test/dummy content once the project is ready for the real content. Even though I always try to implement the sites using real-world content - Even though content often is not ready I find it a good approach to then use text and images from the existing web project. This approach in my experience has at least 3 benefits
Media
The media section is really bare an empty before implementation starts. Lately I have begun to create 2 root folders - One called "DIS/PLAY" (Our company name), which is used for the images and files we use when implementing and then a folder based on usually the name of the client so it would be "Heinz" if my client was Heinz for instance. It's not though ;-)
The I usually create subfolders named "Images", "Videos", "Files" etc. - This way you at least do your best to help the editors on the way by leading the way with a minimum of structure in the media archive. And when educating them in how to manage content it's just easier when it's already setup like this in my experience.
This approach also has the benefit that you can set the start folder for the editors to the client folder, which means they will never see or be able to touch your own folder. This ways you avoid clutter and mess to build up over time since developers and editor don't use the same folders in the media archive :)
/Jan
Loads of good stuff so far!
My little tip:
If you have some elements that are a yes or no (true/false) where there some that are usually yes and some that are usually no, don't just use the one datatype for both.
Make 2 datatypes with different defaults. It saves a few seconds, but one editor was gobsmacked with this, as it makes their life easier.
I also use Switcher to create more friendly and obvious toggles with explicit labels.
Just seen the switcher package - I like it. Could be useful. Thanks for pointing that package out!
O.
Since v7.11 the default True/False data type has been changed to use the stylised toggle: http://issues.umbraco.org/issue/U4-11408
You might still want to use Switcher if you want to customise the toggle text, but in some cases the built-in control will do.
Comment author was deleted
I'll try to keep it short :)
Would like NC/SC to include more optional controls (e.g. disable, copy) but that's an argument I've lost before :P
Very few 3rd party packages needed these days. My top picks:
Ok that wasn't short. Sorry ;)
Well, I've spent the day reading your comments and watching videos, reading articles about Atomic Design and trying to work out when I would or should use Nested / Stacked Content, Component layouts or throw it all into tabs! My mind is bursting and I'm not sure I am any further forward!
Tomorrow is another day though and I may have an eureka moment when I least expect it.
I've the designs to look at now so this may help me chop up each component and work out how I will implement them in the back office.
Thanks for all the comments and I welcome any more if people have more thoughts on this subject.
I know I'm a bit late to this discussion, but there's a very good A List Apart article which discusses this (and largely includes a lot of the recommendations mentioned above): https://alistapart.com/article/training-the-cms
Just finished reading the thread and I agree with pretty much everything that has already been mentioned.
One thing I don't think I came across in the previous comments, is to listen to editors on a regular basis after a solution has been delivered to the client.
My simplified view of how most agencies and clients perceive their projects is that the site/solution is done when delivered to the client, but before it actually starts being used.
I think it is very common that editors are not aware of how much customization is possible in the backoffice, and just "live with" the small annoyances they have to work around every day. In my opinion you could learn a lot about what makes your backoffice more user friendly by scheduling a follow-up session or two with key members of the clients' team.
This will help editors understand that their editing experience is not set in stone and make them take note of where their workflows could be improved.
It will require some extra time, but I am certain that the clients will appreciate it and gladly pay for the extra hours that could potentially save their content editors a lot of time in the long run.
Great advice Martin.
Checking up on your clients once the site has gone live is also good customer service. :)
O.
is working on a reply...