Fedosja from Perplex recently wrote a great article going through V8 and showcasing some of the changes and improvements. When describing her thoughts on the editor experience, one of the comments she made was:
I was positively surprised at the launch of Umbraco 7 because it was
obvious and clear how much more attention had been given to the
editor. While Umbraco 8 is clearly following the path set out by its
predecessor, it is also obvious that there is less of a leap in
progress for editors compared to Umbraco 7.
This has got me thinking. What could be done (if anything indeed actually needs to be done) to push the editor experience to the next level?
Does it need to be pushed further, or is it better to improve stability further and introduce small improvements as we go, or is there something innovative that we could introduce to improve that experience even further.
For example, the use of text to speech is becoming ever popular and with the rise of voice interaction with our devices could we employ similar tool to Umbraco such as the ability to dictate in to a rich text or text area.
We've also seen some cool integrations with the Microsoft Cognitive services for image data. Obviously that sort of think is more suited to a content app, but if it's something that could make editors lives easier, maybe it's something that could be worked on and showcases (if it isn't already)
I'm just throwing ideas out but thought it would be an interesting discussion to have.
Good start, it would be interesting to investigate specifically which areas that the number of clicks could be reduced. I'm guessing you have some ideas on this already?
It would also be good to have some people who use accessibility tools whilst using the Umbraco backoffice to get some insight from there perspective.
One thing I mentioned in another thread, based on something Marc Goodson mentioned, would be making a distinction in the UI between content that appears on pages and content that acts as metadata or is used for configuration etc.
So in v8 we currently have "Content" and "Info" tabs at the top when editing a page. So add an extra tab called "Settings" (or "Metadata" or something) which can be used to separate properties / compositions that don't appear visually on page eg. SEO Settings etc. This would also help alleviate the length of the editing accordion and maybe help resolve some of the issues around that can of worms!
Another thing that would be good would be to allow developers to set on a doctype (or composition) whether an accordion item is open or closed when first viewed. Currently in v8 all accordion items are open by default (which kinda defeats the purpose!). It would be good if a dev could specify that, say, the main content and secondary content is open by default but, say, SEO section is closed. It would help focus editors on the stuff that changes.
Yep, my initial thoughts are the ability to define 'personalities' that can either be switched in/out of or assigned to user profiles - developer, admin, editor - so the complexity can be hidden from those who don't need/want it, and made available to those who do.
That sounds like a brilliant idea, i suppose something like that could be set up in relation to the user types/groups. It does make me wonder whether some of the issue we have at the moment are due to the backoffice catering for everyone's needs. This can have positive and negative side effect, such as it being an incredibly flexible tool to build with, whilst maybe offering to much to those who just want to go in a edit content.
The other one I often think about (and have toyed with from time to time on other CMS platforms) is a concept of 'Live PreView' - to address the perennial issue of people asking (bugging) me for In-Line Editing.
Most content-editors I speak to, balk at the idea of using a backoffice at all, and say that they would prefer to work with an In-Line Editor, in a more WYSIWYG mode... clicking on sections of a live page, which switches them to an editor overlay as/when they need it.
However, when pressed, most non-techs typically struggle to articulate the details of how they would see it working and how that offers an advantage to using the backoffice, other than the general desire for a reduction in complexity - which is also part of the aforementioned 'personalities'.
Of course, the reason that so many CMS's do inline editing badly is because it's hard to do well and provide a demonstrable advantage to using the backoffice for those with an aversion to such things. There are usually so many gotchas and unresolvables that you end up resorting to the backoffice so you can edit the value you need to change rather than the one the inline editor thought you wanted to change, if it could even figure out what that was from a click.
Usually what content editors really want is to be able to navigate pages via the front-end rather than the backend, change content elements on that selected page, and then see the changes they make in real-time. i.e. I know what I want to change and I know what it needs to look like, don't make me have to deal with unnecessary tech stuff and navigate some arcane back-end structure to find/edit it.
My thoughts are that perhaps a hybrid solution of a backoffice with a 'Live Preview' - as an off-canvas overlay you activate just by pointing at it (obvious responsive issues to be resolved there) - that allowed editors to navigate their node structure using the live preview, and then see the changes they make to the selected node in real-time on the Live Preview, rather than needing to navigate the node structure to find the content they need to change and then activate a preview to see the changes they make.
From the developer/admin point of view this is all a bit of a 'meh' difference in approach, but from the non-tech editor's point of view this is, in essence, an extension to the 'Infinite Editing' concept of reducing the friction points and just letting people do their jobs.
I would say to make as much things configurables as possible. For example: the new accordion system. I'm happy with that feature, but I understand who are not.
What can be done to push the editing experience further
Hi everyone,
Fedosja from Perplex recently wrote a great article going through V8 and showcasing some of the changes and improvements. When describing her thoughts on the editor experience, one of the comments she made was:
This has got me thinking. What could be done (if anything indeed actually needs to be done) to push the editor experience to the next level?
Does it need to be pushed further, or is it better to improve stability further and introduce small improvements as we go, or is there something innovative that we could introduce to improve that experience even further.
For example, the use of text to speech is becoming ever popular and with the rise of voice interaction with our devices could we employ similar tool to Umbraco such as the ability to dictate in to a rich text or text area.
We've also seen some cool integrations with the Microsoft Cognitive services for image data. Obviously that sort of think is more suited to a content app, but if it's something that could make editors lives easier, maybe it's something that could be worked on and showcases (if it isn't already)
I'm just throwing ideas out but thought it would be an interesting discussion to have.
FYI Fedosja article can be found at https://www.perplex.nl/en/blog/2019/the-all-new-umbraco-8/
Cheers
Reduce the number of required clicks and make the whole thing accessible.
Good start, it would be interesting to investigate specifically which areas that the number of clicks could be reduced. I'm guessing you have some ideas on this already?
It would also be good to have some people who use accessibility tools whilst using the Umbraco backoffice to get some insight from there perspective.
Reverting this would be a healthy start.
https://our.umbraco.com/forum/umbraco-8/93641-discussion-about-tabs
One thing I mentioned in another thread, based on something Marc Goodson mentioned, would be making a distinction in the UI between content that appears on pages and content that acts as metadata or is used for configuration etc.
So in v8 we currently have "Content" and "Info" tabs at the top when editing a page. So add an extra tab called "Settings" (or "Metadata" or something) which can be used to separate properties / compositions that don't appear visually on page eg. SEO Settings etc. This would also help alleviate the length of the editing accordion and maybe help resolve some of the issues around that can of worms!
Another thing that would be good would be to allow developers to set on a doctype (or composition) whether an accordion item is open or closed when first viewed. Currently in v8 all accordion items are open by default (which kinda defeats the purpose!). It would be good if a dev could specify that, say, the main content and secondary content is open by default but, say, SEO section is closed. It would help focus editors on the stuff that changes.
Yep, my initial thoughts are the ability to define 'personalities' that can either be switched in/out of or assigned to user profiles - developer, admin, editor - so the complexity can be hidden from those who don't need/want it, and made available to those who do.
That sounds like a brilliant idea, i suppose something like that could be set up in relation to the user types/groups. It does make me wonder whether some of the issue we have at the moment are due to the backoffice catering for everyone's needs. This can have positive and negative side effect, such as it being an incredibly flexible tool to build with, whilst maybe offering to much to those who just want to go in a edit content.
The other one I often think about (and have toyed with from time to time on other CMS platforms) is a concept of 'Live PreView' - to address the perennial issue of people asking (bugging) me for In-Line Editing.
Most content-editors I speak to, balk at the idea of using a backoffice at all, and say that they would prefer to work with an In-Line Editor, in a more WYSIWYG mode... clicking on sections of a live page, which switches them to an editor overlay as/when they need it.
However, when pressed, most non-techs typically struggle to articulate the details of how they would see it working and how that offers an advantage to using the backoffice, other than the general desire for a reduction in complexity - which is also part of the aforementioned 'personalities'.
Of course, the reason that so many CMS's do inline editing badly is because it's hard to do well and provide a demonstrable advantage to using the backoffice for those with an aversion to such things. There are usually so many gotchas and unresolvables that you end up resorting to the backoffice so you can edit the value you need to change rather than the one the inline editor thought you wanted to change, if it could even figure out what that was from a click.
Usually what content editors really want is to be able to navigate pages via the front-end rather than the backend, change content elements on that selected page, and then see the changes they make in real-time. i.e. I know what I want to change and I know what it needs to look like, don't make me have to deal with unnecessary tech stuff and navigate some arcane back-end structure to find/edit it.
My thoughts are that perhaps a hybrid solution of a backoffice with a 'Live Preview' - as an off-canvas overlay you activate just by pointing at it (obvious responsive issues to be resolved there) - that allowed editors to navigate their node structure using the live preview, and then see the changes they make to the selected node in real-time on the Live Preview, rather than needing to navigate the node structure to find the content they need to change and then activate a preview to see the changes they make.
From the developer/admin point of view this is all a bit of a 'meh' difference in approach, but from the non-tech editor's point of view this is, in essence, an extension to the 'Infinite Editing' concept of reducing the friction points and just letting people do their jobs.
I would say to make as much things configurables as possible. For example: the new accordion system. I'm happy with that feature, but I understand who are not.
is working on a reply...