Template-picker lowers UX

[Ruslan-Aleev]

Feature request

Summary

In MODX 3, the "Template-picker" has been added, which is intended to simplify the creation of resources by the manager.

However, after the manager understands what the template looks like (after 3 times of resource creation), "Template-picker" will interfere with work.

There is no content field in "Template-picker". And now you will not be able to go directly to editing the resource (when creating a resource in a tree), you need to either create a resource through the "Template-picker" and go inside it, or call the context menu, which increases the number of clicks and the time of work.

Suggested solution(s)

1) I would leave resource creation in tree as it does in MODX 2.x, without popups.

2) Creating a resource through the window, I would hang on the "New page" button in the widget on the manager panel. It is easier to explain to the manager that in the widget, by clicking "New Page", you can see "what the template looks like".

3) MODX has a quick resource creation form. It seems to me that it is worth combining the "Template-picker" and "Quick Create Resource", make the template preview a separate tab. We can even place the "Template Preview" as the first tab, and the text fields (description, introtext, content, etc.) can be moved to the second, "Content" for example.

The current version is dubious and will be annoying in my opinion. I suggest everyone try to create 5 resources in the manager and evaluate the usability :) There is a setting that disables the "Template-picker", but not everyone will know about it...

Related issue(s)/PR(s)

https://github.com/modxcms/revolution/pull/15535

[Mark-H]

Before when creating a new resource:

• Click "new page button" navigates to ?a=resource/create
• Changing the template to the one you want to use gives a popup that the state will be temporarily saved. Click okay, page refreshes.
• Also changing the class key for a link (admittedly, a rarer use case for regular users) gives the same popup and refresh.
• In some cases (like a moregallery resource type, I think Babel too) you need to save the new resource before it can be properly used, requiring another full refresh of the page as you're navigated to ?a=resource/update. Can't save before entering a title or any potentially required TVs, either.

Now when creating a new resource:

• Click new page button opens the template picker without browser navigation
• You can change the template, class key and parent without further confirmation popups or refreshes. Bonus point for being able to see the template preview, if you have many.
• On save, the resource is immediately created and you jump straight into ?a=resource/update

Quick create is unaffected and available with the same number of clicks as before as an advanced feature, also with the same limitations as before (no RTE, no ContentBlocks, no TVs, etc).

I'm really struggling to see how any of this could be described as a worsening the UX when it does away with numerous confirmation popups and refreshes for the essential function of creating a resource with a certain template and type. It's my favorite user-facing feature in 3.0 by far.

[Ruslan-Aleev]

Before when creating a new resource:

• Click "new page button" navigates to ?a=resource/create
• Changing the template to the one you want to use gives a popup that the state will be temporarily saved. Click okay, page refreshes.

You are leaving out the automatic_template_assignment setting (and default_template), which removes these items. Although, in fairness, this is relevant for "frequently created" resources, for example, "News". But, as it seems to me, these are the resources that are created more often.

Before: You pressed the plus in the tree, and there was already the template you needed, all you had to do was add content and save (there is a resource for automatic_template_assignment = sibling).

Now: Now you ALWAYS have to look at the window animation, look for the desired template (use search if there are many templates), save in window, then you jump straight into ?a=resource/update - although this is a page refresh, in fact, and only then add content and save.

Also changing the class key for a link (admittedly, a rarer use case for regular users) gives the same popup and refresh.

No, when changing class_key, parent there are no popups and refreshes.

when it does away with numerous confirmation popups and refreshes

Removes the confirmation window when changing the template, but creates the "Template-picker" window, removes the "OK" click on the confirmation window, but creates "Save" on the "Template-picker" window, removes the page reload when changing the template, but creates a reload after "Save" in the "Template-picker" window :)

[JoshuaLuckers]

I agree with both of you. It's a really nice feature and in some use cases it is an UX improvement and in others it is not.

[theboxer]

tbh. I don't think that the negatives are that huge of a deal. For example if you are concerned about speed of creating news, or block articles, just use Collections. They have a dedicated button to create a new child that will take you directly to the create page and prefil template and all other fields you'll set.

With that said - it might be worth considering if we'd allow CRCs to inject own items to the context menu in the resource tree; right now it can only disable the quick create and the create button - but with that you kind of loose the quick access to create childs and you have to open the resource itself.

[Ruslan-Aleev]

I don't think that the negatives are that huge of a deal.

Here is the question of what is the purpose of the "Template-picker" initially. If the goal is to reduce the number of windows, as @Mark-H pointed out above, then this does not happen (moreover, now the number of actions is ALWAYS the same as if I changed the template of the resource). And if the goal is to add a preview of a template with a template search, then yes, there are almost no negatives.

For example if you are concerned about speed of creating news, or block articles, just use Collections.

Good argument, or is it easier to use another CMS :)

[theboxer]

@Ruslan-Aleev you get offended way too quickly if others don't agree with you.

I believe we provided a handful of reasonable arguments for why it seems like a better UX to have it this way. If you don't agree lets continue with a constructive discussion.

I'm not sure how suggesting using an extra that's specifically designed for speeding up creating news, blogs and similar type of collections is same as suggesting switching to a different CMS, but ok, I'm not going to follow this route with you.

[Ruslan-Aleev]

you get offended way too quickly if others don't agree with you.

@theboxer I agree, but the problem is that you are not giving reasonable arguments. For example, with Mark we are discussing quantitative change, something that can be compared (this is objective information). You are operating "I don't think ..." - and this is subjective information. And the fact that you can use "Collection" is understandable, but it doesn't fix the UX problem for "Template-picker", it just gets around it. Therefore, I sarcastically gave a variant using another CMS. Not only that, you can just turn off "Template-picker" via the setting, but that doesn't fix the UX either.

[theboxer]

@Ruslan-Aleev since when are subjective information wrong?

This whole issues is based on your subjective opinion that the template picker worsens the UX.

The new resource create modal speeds up the resource creation as it lowers the number of reloads.

• Even if you create a resource without changing a template in 2.x, after you save it, you'll be forced to wait for the page to reload.
• If you have extras that rely on having a resource ID before correctly functioning, before you had to save the resource, wait for the reload and then you can access their functionality; now you'll have them right after you confirm the modal (but Mark already mentioned this).

Also it seems like you misunderstood my collections suggestion - I didn't suggest to use collection to get around the new resource creation modal. I did suggest to use collection for news/blogs section - where your concern was speed of creating new items with predefined fields.

Your sarcasm was quite a bad one - as extras are the core of this CMS, I don't know anyone who would use it without a single extra.

You're using extras to get additional features or better UI/UX for specific tasks. I'm sure you can build let's say gallery without any extra, just create a resource and put the image to the content or TV - pretty terrible UX In my opinion, but I won't judge if someone does that. You can also use a Gallery extra (whichever you'd like) that will give you a handful of additional features and a lot better UX. Or of course, you can go and use different CMS because creating galleries using resources is dumb and you don't want to use extras.

[Ruslan-Aleev]

This whole issues is based on your subjective opinion that the template picker worsens the UX.

Removes the confirmation window when changing the template, but creates the "Template-picker" window, removes the "OK" click on the confirmation window, but creates "Save" on the "Template-picker" window, removes the page reload when changing the template, but creates a reload after "Save" in the "Template-picker" window :)

So, I meant it, about the objectivity of the fact that it can be compared. Those now any creation of a resource is the same as if I manually change the template of the resource. Even if we remove 1 reboot as you pointed out, then it does not improve the process.

If I'm wrong on this point, please indicate what (without suggesting extra, more on that below).

Your sarcasm was quite a bad one - as extras are the core of this CMS, I don't know anyone who would use it without a single extra.

So can "Template picker" be made a separate extras (there are similar ones, with the installation of templates), and not add to the core?

In any case, if you think that I am wrong, you can close this issue.

[theboxer]

What do you mean that it doesn't improve the process?

• Removing unnecessary reloads that takes quite a lot of time (to happen and re-render the whole form)
• Displaying the very light form to just fill pagetitle and template, before smacking user with dozens of other fields
• Showing the template preview image

All these seems like a huge improvement to me.

And of course this could be an extra (probably with some tweaks to core to allow it), but people thought it's a great addition directly to core and it got approved and merged.

In any case, if you think that I am wrong, you can close this issue. Here we go again, offended way too fast. I think you are wrong, but this is just my personal opinion I wanted to express. So at the end of the day it will be a matter of what the majority who care about this project will think. If there will be enough people thinking that the new template selector is dumb and should be removed - it'll get removed.

I think I shared all my reasons for keeping it as is and an extra idea to allow custom context entries for CRCs. So I'll go and check some other issues & PRs ;) See you there

[Ruslan-Aleev]

Here we go again, offended way too fast. I think you are wrong, but this is just my personal opinion I wanted to express. So at the end of the day it will be a matter of what the majority who care about this project will think.

I'm not offended, I'm just tired of discussing and explaining what I see the problem. It's a pity for time. In any case, yes, let the majority decide.

[Ruslan-Aleev]

We need to think about what to do with the automatic_template_assignment and default_template system settings, because it is not clear how they will work now. Perhaps in the Template-picker it is worth choosing a default template, taking into account these settings.