Skip "create" menu when only 1 doc type allowed

[Len Dierickx]

Hi everyone, 

This is about the Umbraco 7 UI and I am looking at whether some of the actions in the UI can be customized.

Not sure whether here or the developer google group would be better suited.

 

We have several document types that can have only 1 document type as a child node.

Doctype examples are "News archive" > "News item", "Quotes" > "Quote", "Job folder" > "Job posting" etc...

 

All of these have only 1 doctype that can be added as a child.

You probably have this kind of relationship for many document types in your installations as well.

 

The editors perform this action quite often, and there are some unnecessary steps involved.

 

The sequence goes as follows:

• "hover over page in the tree structure"
• "point to ellipsis"
• "click ellipsis" 
• "menu slides out"
• "point to single available  doc type"
• "click single available  doc type"

The last 3 steps are unnecessary as the editor has no choice but to select the one doctype that is available.
Would it be possible to detect that there is only 1 doctype, and skip the menu and create that page when the ellipsis is clicked?

The user is an editor, and all that they can do is create the page. 

 

Instead of forcing the editor to click, the page could just show up immediately. The menu provides no additional information, as the editor cannot choose.  The editor can cancel creating the page as long as the page hasn't been published or saved, so no harm done.

Is there any way I can override this action in the UI and just create the page as explained above?

 

Thx in advance, 
Len. 

[Dan Booth]

Dunno how you'd do that in the code-base, but it makes sense as an idea. There is a feature request for this already: http://issues.umbraco.org/issue/U4-5329

Dan

[Len Dierickx]

Hi everyone,

I had a look at the ticket and it seems some other people had the same idea.


When talking to some of the content editors, they asked me why the
ellipsis opened the dialog box and not the whole menu with all the
actions.

In that dialog with all the page-actions (copy, move, delete), the
create action is marked with a "plus" sign.
This isn't consistent with the ellipsis, which also opens the create dialog.

Even though the ellipsis provides a clue that something is omitted,
the + sign would make it immediately clear you would create something new.

At this moment you have 1 action (create) represented with 2 icons:
ellipsis and plus sign.

I remember clicking the ellipsis not knowing what it would do for the
first time,
and if my memory serves me well, I also assumed it would give me
access to all the actions.

Maybe some people think the same, maybe some other developers could
talk to their editors and wee what they think of it?

If they have the same idea, please vote for this issue here:
http://issues.umbraco.org/issue/U4-5519

Thx / Len.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Umbraco UX" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/umbraco-ux/FM9WRqXd65o/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> umbraco-ux+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Len Dierickx @ astuanax

Website: http://www.astuanax.com
E-mail: l...@astuanax.com
Twitter: @astuanax
LinkedIn: http://lu.linkedin.com/in/lendierickx/

Tel: +352 66 11 298 97

[Douglas Robar]

Perhaps a bit of background would help, or at least the background as I recall it.

One of the goals of v7/belle was to reduce the clutter/noise for content editors. Rather than show the full list of all the actions that could be performed the idea was to show, be default, the action(s) that were most likely to be performed with a way to get to the other actions if that were desired. That's why the 'create' menu is shown prominently for all items, not just content, because that's most likely what users want to do. They don't have to select it from a long list of actions as they did in v6 and earlier. 

This has been further streamlined in the Content and Media sections by deciding that 'create' was what users most wanted to do. Rather than showing a short list of actions as you'd get in the Settings and Developer trees, for instance, 'create' is the only choice by default and thus the 'create' dialog appears instantly. Showing the available doctypes immediately means there's no need for a second step as in v6 and earlier. 

If you prefer, you can get to the full list of actions by either clicking the 'Do something else' button at the bottom of (most) action menus or, for power users or those who liked the bahaviour in v6 and earlier, by right-clicking on the item in the tree instead of using the ellipsis. There is also the 'Actions' dropdown button in the top-right that might be more convenient in some use cases, perhaps such as the one you're describing.

Consistency in the UI/UX was also very important, as was using established metaphors for actions. The ellipsis has been a UI standard for decades on menu items to denote that a dialog or prompt would appear (no ellipsis meant the action would take place immediately). That's also the behaviour in v7/belle. The plus sign for 'create' is also common, and when you see the full list of actions available (when you 'Do something else' or right-click a tree item) you see all the icons associated with the action menu and perhaps that makes it more obvious why the plus sign?

That's the basis of the background to why v7/belle is the way it is. Personally, I've found it superior to the v6 and earlier UX though it took a while to get over the changes and initially I wasn't convinced. I am now that I've gotten used to it. I've also heard zero questions/complaints from students since we've been doing v7 courses. 

As for noticing that in the Content and Media sections the ellipsis brings up the create action immediately... you're right, that's inconsistent with the rest of the UI but I think you can see why it was done (to simplify the most common action of content editors). It isn't that the ellipsis 'means' or 'signals' the create dialog but simply that according to UX standards the user can expect a dialog to appear. In this case it is the create dialog rather than a short action menu because there would only be a single action on the menu.

Why then aren't there ellipsis after the items in the (short or full) action menu? Because every single one would have an ellipsis except the 'Reload nodes' and that was thought to be excess noise. Go figure. That's the nature of human decisions/preferences even while trying to be consistent. Personally, I find the behaviour consistent enough and clear enough though some people might argue that point.

Lastly, your original question about auto-creating a new page if there's only a single doctype possible is an interesting UX optimization idea! Personally, I'm not in favor of it because I like that tiny step that asks the content editor which doctype to use. There's feedback that says, "yes, I want to create a job post" that just wouldn't be visible anywhere else. At least in my experience content editors never ever look at the 'Properties' tab. By having to select the doctype, even if it's only from a choice of one it gives them the chance to say, "hey, that isn't at all what I wanted" rather than create a page and populate it and only then realize it isn't correct when the preview/view the site. But maybe that little step is only important to me? 

cheers,

doug.

[Len Dierickx]

Hey Douglas,

Thanks for the feedback, and I understand what you are saying and
agree with most of it and the reasoning behind it.
I am just trying to give you guys feedback from what I hear, and also
looking at improving things.

I have been working with the old UI since version 2, so my habits are
quite deeply ingrained :-(
But, that is why I first listen to the editors, and keep my opinions
(very positive !!) about Umbraco out of the picture.

Lately I am trying to look at the UI using GOMS analysis, and then the
old interface wasn't so bad.

Anyway here are my comments.

>Rather than show the full list of all the actions that could be performed the idea was to show, be default, the action(s) >that were most likely to be performed with a way to get to the other actions if that were desired

Having this one action, is perfect.
It only takes 1 trial to learn it, then you will understand it forever.
Kinda like riding a bike. Everyone has to learn it, but once you get
it, you won't forget.
But still, you have to try it once to understand that an ellipsis
means "create".

Yes, hiding the full action dialog behind a right-click is a great idea.
The main action for editors will be "create", so having only 1 button
is a very good choice to simplify the menu.

I think there was some intention long time ago to expose more then 1
action as the "correct" action, and this might (guessing here) date
back from a time that Niels wanted to have this 1 action depending on
the users preferences, or most used actions.
In case you are an editor, that would be create a page.
If you are a developer, that might be something different (delete,
reload nodes, etc...).
Personalisation, but that never took off.

However, there is only one action at this very moment: create a page.

>It isn't that the ellipsis 'means' or 'signals' the create dialog but simply that according to UX standards the user can
>expect a dialog to appear. In this case it is the create dialog rather than a short action menu because there would only
>be a single action on the menu.

Yes, that is why I suggest to change the ellipsis into a plus.
The user can expect a dialog to appear is rather vague, and a "plus"
sign would clearly indicate that something will be added.

>Consistency in the UI/UX was also very important, as was using established metaphors for actions. The ellipsis has
>been a UI standard for decades on menu items to denote that a dialog or prompt would appear (no ellipsis meant the
>action would take place immediately). That's also the behaviour in v7/belle. The plus sign for 'create' is also common,
>and when you see the full list of actions available (when you 'Do something else' or right-click a tree item) you see all
>the icons associated with the action menu and perhaps that makes it more obvious why the plus sign?

The ellipsis should be used together with a verb or noun, that
indicates what will happen.
In "Chrome" (Max OS X, prob. on Windows too) for example, you have the
"Preferences" menu item which is shown together with an ellipsis.
Telling me that when I click "Preferences" something will happen and I
have to do something to finish what I was doing.
Apple has the same setup in their style guide.

In this case Umbraco is using the name of a page, lets say "Contact
Us", with an ellipsis.
There is no connection whatsoever between a random page name, and the ellipsis.

If you would follow the style guides, UX standards, you would need
something like "Create ...", meaning that when you want to create
something, there will be more choices to make down the road.

So, I understand where you are going with this, but in Umbraco 7, the
text that goes together with the ellipsis has no meaning in relation
to what will happen. That is also why nobody understands it at first.

Contact Us ...
Jobs ...
Blog ...

The next time they click, everyone understands, so from a usability
point, it lacks affordance, but is easily learnable and remembered.

>Lastly, your original question about auto-creating a new page if there's only a single doctype possible is an interesting
>UX optimization idea!

Yes, if there are more then 1 doc type available, there is no other
option but to show the dialog. I agree.

If there is only 1, the editor doesn't have a choice, even though you
are showing a dialog that expects input.
There is no input, the editor cannot add information.
Avoiding this step wouldn't do no harm either. As the page will not be
created until a name is provided and saved.

So, if there are more then 1, just show the dialog, if there is only
1, go straight into the editor to type the name and save.


To end this long email, I think that changing the ellipsis to a plus
does improve the UI, though the return will be very little. All that
will be avoided is this first encounter confusion, knowing that
something will happen when you click the ellipsis, without knowing
what exactly.

The next time you'll remember that this is the create button.

I don't think that anyone will argue that the ellipsis is a universal
symbol for "create" or "add", while the plus sign is certainly a
universal (math!) symbol for adding up.


Then the 2nd proposal, skipping the dialog only when there is just 1
doctype available, does improve the work flow of the editors. Asking
them whether they want to create a blog post, when that is the only
thing possible, it disrupts the work flow. Of course if there are
more, they have to make a choice.

But I do try to make the hierarchy as painless as possible even though
that means the developers have to create a lot more document types.

Thanks for reading, and yes I do love Umbraco 7, it looks great and is
a lot faster than the previous ui!.
Thx, Len.

[Douglas Robar]

Hi, Len, 

You're giving me credit for the v7/belle UI and UX that I don't deserve. I really wasn't involved except for some feedback early on. I was just hoping to add some history and reasoning for why the interface is the way it is.

The more I think about this the more I'm liking your idea. I, too, am a fan of making as many document types as needed and (hopefully) getting the structure such that in most cases there is only a single doctype possible at any point in the content tree. We aren't in the majority I fear but for those times when there is a 'choice of one' altering the UI to make that even simpler would be very nice for the users.

To summarize the idea so far (let me know if I'm mistaken about any of this):

1. The content section should behave as it does now, except that in every case where the Create action is the default action the ellipsis (...) icon should be replaced with a plus (+) icon. This is the case if there are multiple doctypes that should be chosen for which the user will be prompted to select the appropriate doctype, or if the user will bypass the selection of doctype if there is only a single doctype possible.

Let's see if we can hammer out a few more details and then implementation will be even easier for the devs should this change be implemented.

I can see a few situations we still want to consider:

1. What should happen when NO page can be created (that is, the doctype structure doesn't allow any child pages)? 
   Should there be no icon (neither ellipsis nor plus sign)? Should there be an 'X' icon indicating nothing can be done (though this might be confused with 'delete' so perhaps a different icon)? What will give the user (both content-only editors and site builders who like the 'You must enable these in the settings section under document types' warning? If nothing can be created, we would still want some way to get to the 'Do something else' button without forcing people to learn that there's a right-click shortcut for the full action menu. Or, should the ellipsis be shown and when clicked the full action menu appears (that way there is always an icon for consistency)?
    
2. Should the same behaviour apply in the Media section too?
   I assume so but will people realize that from the root of the media section you can only create Folders if the single mediatype of 'Folder' isn't listed? Over time users will learn this but for new and occasional users it could lead to frustration instead of ease. This is the basis of my argument for the content section as well but I'm being swayed toward your thinking there while not being as confident of that in the Media section. Would we want different behaviour in the Content and Media sections?
    
3. Should any of this apply to other sections or should it be limited to Content and Media, the primary places that content editors will use and thus the ones most in need of the optimizations? Or, at least, start with Content and Media and consider the other sections separately later?
    
4. In the case of needing to select a doctype, should the icon be the plus (+) or should it be the ellipsis (...)? I could argue this either way. The ellipsis means you'll be prompted to make a choice before continuing. The plus means you're going to the 'Create' step and the first step of that is selecting the doctype if there is any ambiguity. What do you think is best there? 

cheers,

doug.

 

[Per Ploug]

I do not in any way agree that the menu icon on the tree icons should change depending on what the user can do.  :) 

1. First of all, there will in most cases always be multiple actions, for content you will very likely always have "Create" and "Reload children" no matter what, if not, you also have access to the audit trail, going back to a previous version and so on. So you will very very likely never ever only have a single Icon to attach.

2. Besides that, how does it make the UI easier to decipher that you have Icon inconsistencies directly in the tree ? - in a super small space, with no chance to explain to the user why there is (...) on one node, and (+) on another - and if we use the convention on all other trees, we would end up having an icon buffet next to the nodes name.

3. And if you look at the different situations that Doug mention, that you need to take into account, (no allowed types == no icon??) - it just introduces loads of special rules and again, it makes the decision in the space with the least amount of space to offer any guidance.

At least when there are no allowed types in the current setup, we have a full dialog to tell the user WHY there are no options to create anything. With your suggestions you get nothing but an empty tree node.  

4. I don't see how this suggestion makes things simpler - it makes things more inconsistent for the user, and the only thing you would possibly gain is to have a plus icon on your nodes instead of (...) - which I explained in #1 will probably never happen for any user (if you are allowed to create, you are also allowed to reload children) 

To go back to where this discussion started, we did actually experiment with going straight to the content editor if there was only one doc type allowed, but it it just confused people, because you cant instantly see what type of content your create, so if you don't know, you think you accidentally clicked and item in the type list - because it appears when there are more then 1 allowed type - so we went back to always showing the dialog. its not technically needed, but it reassures people that they made the right choice.

/per

[Douglas Robar]

Thanks for the input, Per, really helpful insight into the original decision-making process!

It's an interesting question and my original reaction was much the same as yours. I thought the icons would be totally inconsistent throughout the content tree but that's actually not the case. In the Content section the ellipsis always leads to the 'Create' action and choice of doctypes. There is no 'Reload nodes' option directly from Content as there is in other sections. That makes the Content section unique already and when I poked around more I realized this was the case and started to consider that maybe there was merit in using the (+) icon instead as being more descriptive. You still get the 'Do something else' button or the right-click for the full action menu, and the 'Actions' button in the top-right if you want to do something else.

Anyway, it was that realization that made me consider the idea more kindly.

Once I got that far the second question of skipping the 'choose the one and only doctype' step became more interesting as well, though to go that far raises other issues, as I mentioned and I can't yet see a smooth path through some of them.

Does it make any difference to your thoughts, as it did for me, that in the Content section the icon always leads to the Create action dialog? If it weren't for that fact I'd still be totally against the idea because I don't like 'icon soup' at all. But as it is, I could certainly see using a plus icon as a minor UI tweak that might help content editors. And after that maybe consider the second optimization of skipping the doctype selection if it's a choice of one, assuming the difficulties can be resolved.

cheers,

doug.

[Sebastiaan Janssen]

There's still 2 things in that pane though: create a document of type... x and "Do something else". 

--
You received this message because you are subscribed to the Google Groups "Umbraco UX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umbraco-ux+...@googlegroups.com.

[Douglas Robar]

Good point, Sebastiaan... I guess there really is more than one thing possible and thus the ellipsis is the better icon.

[Per Ploug]

Douglas, you are always the voice of postive constructive feedback :) - which I am not always, but despit my grumpy initial feedback, it is an interesting discussion.

I think we should back off on talking about a specific solution first, and lets talk about what the problem actually is, that way we dont try to cram every problem into the same

set of solutions. 

So as Len initially talked about, his editors have 2 things that are annoyances:

1. its hard to decipher what the ( ... ) means, and in their context, the only action they perform is cration, so therefore ... makes no sense, since it doesnt say "create"

2. they feel they have multiple unneeded extra steps when they create new content

I think based on the discussion and points raised sofar, that the suggested solution is not ideal, a tree node will always have multiple actions, and ... is the correct icon to

illustrate this. We've seen this backed up in UI guidelines from multiple sources / projects and it is slowly becoming the standard - along with the hamburger icon

And we cant really live without having an action menu on tree items, it gives direct access to so many things, that we cant replace it with something else atm. 

So what I would conclude is that the tree is a pretty locked down UI component, and we should try to cram more stuff into it, there is already more then enough there. 

Then theres the option of looking at the old V6 UI which had a dedicated Create button, it meant that editors could just always click that when they needed to create new stuff, and its something

we could take a good look at for refreshing the V7 UI

But before we make any patching of the UI, we should take a step back and get the challenges defined, without having a solution in mind from the beginning :)

/per

[Douglas Robar]

Thanks, Per. I see your points about the tree UI/UX as being more or less locked at this point. The annoyances Len mentioned are exactly what we're talking about, though it's difficult not to suggest potential solutions in the discussion. It's also difficult not to think of them as a single item, but we do need to be clear that they are two separate issues and the 'answer' for one doesn't necessarily have a bearing on the other.

I'm not quite sure how to move forward on this. I feel as though I've offered about all I can say unless something new comes up. 

I will mention that, in all my years of teaching the Umbraco Level 1 course to new users, the 'Create' button in v4/v6 has never been something people used. Perhaps it was placed poorly and so was 'invisible' to users. Or maybe there was some functionality that wasn't quite right about it. Whatever the reason, I'd be hesitant to hold it up as a potential solution for v7 without considering why it wasn't a success in earlier versions as it might have been. After all, it was there for just the purpose we're discussing and yet to my knowledge it was almost never used. 

cheers,

d.