Site Editor: Show theme badge for non customized theme templates in navigation panel #27041
Conversation
|
I created this PR to discuss the possibility of avoiding the blue dot (#26894) and instead we should indicate original theme template files. |
david-szabo97
requested review from
jameskoster,
Copons,
vindl,
noahtallen,
mattwiebe,
Addison-Stavlo and
jeyip
|
Size Change: +159 B (0%) Total Size: 1.19 MB
ℹ️ View Unchanged
|
|
I agree that the blue dot is not perfect (far from it), and probably needs to be re-thought. However, it is a pattern that has been consistently proposed across various design concepts to indicate when an entity has been customized from an initial state (Global Styles being one example). So with that said my opinion is that we should stick with it here for now, but perhaps open another issue when we have a clearer picture of all the eventual use cases, and explore more holistic solutions to what may be a common requirement in site editing. |
|
@jameskoster I think this PR was more meant to start a discussion than to be a solution. 🙂 I'm not sure about Global Style (you mention a design concept, which I assume didn't make the cut, as I don't see any dots in there 😄), but talking about it with other people it was also mentioned that blue dots are often used to indicate "customized elements in an unsaved state". See for example Visual Studio Code (for no other reasons that it's the app closest to the browser right now 😄 ). VSCode add a dot to tabs with unsaved changes:
If the project has a version control system, it also adds an
I might be biased by my heavy use of VSCode, but indeed I would probably expect to see the blue dot in the sidebar disappear on save. 🤔 |
@jameskoster - I think one thing this could potentially do is compliment the blue dot pattern. That is, if I understood correctly what should and shouldn't have blue dots:
This means that both uncustomized theme supplied templates and templates spun-up from the create flow look the same (no blue dot) and there is no way to differentiate between the two in the nav panel. So perhaps adding the 'theme' tag could at least fill in that gap? 🤔 |
yeah, totally. I'm so used to seeing little dots as "things to get rid of" in the UI. For example, an app shows a little dot on my profile picture. Now I know I need to take action on something in my profile to get rid of the dot. Similar for unsaved changes or notifications. |
Forgive me! I am sometimes guilty of defaulting to a mental model of PR = proposed solution, and Issue = "we need to talk about this", especially when a review is requested. I am 100% keen to discuss more and find a better solution.
That list is correct, and the notion was that it should be possible to see at-a-glance which theme templates have been customised, making it easy to revert to default. I agree with the general sentiment here though – as a UI pattern dots are typically used to indicate "unsaved changes", or activity like unread notifications. They do not say "this has been customized" very clearly. Off the top of my head, there are three states we need to consider communicating visually here, and whatever we come up with likely needs to work for both templates and global styles:
Additionally we need to think about the actual user flows in which one would need to interpret these states. Reverting back to the theme default is one flow, as is deleting a from-scratch template/style. I can see these actions being performed on a per-entity basis or all-at-once a la "restore to factory settings". Are there other flows? When exploring solutions we should probably aim for something lightweight and versatile enough to fit in to a variety of circumstances – I imagine that's why the dot was originally proposed. The "theme" pill in this PR doesn't quite fit the needs outlined above for me, especially as I imagine the average user will consider all templates to be part of their "theme" as the adoption of site editing increases. It may need to be something a little more abstract. I don't have any good ideas to present just yet. But will think about it some more this week. |
I'm not sure if this should be treated as a separate case? 🤔 If the theme doesn't supply a template we will use |
|
Good point, I suppose I was more outlining the perceived states that should be considered when thinking about user flows and design solutions.
On a technical level this makes sense to me, but on a UX level, I'm not so sure. Mostly because we present this action as "Create new" in the UI, which is a decidedly different action to the duplication that you explain happening behind the scenes. I suspect that creating has a slightly different set of expectations to duplicating or customising in this context. I would expect that the customised entities could be reverted back to default, while new entities could only be deleted. |
Just to be clear: the revert is in fact just a simple delete. When we delete a case 2 (theme-supplied and customized), the system will automatically create a new template from the theme file. Therefore, as I see it, the "revert to theme default" action should only exist for case 2. I'm aware that this logic is very confusing, especially for the end user. |
Exactly. And as I understand it this was the original motivation for highlighting these templates with the blue dot in the first place. |
|
For Global Styles I'm looking at using the dot to indicate when a color has been changed from the value set by the theme, and including some additional information (who changed it, and maybe when it was changed) along with a way to reset to the theme default:
These are just design concepts, and haven't been implemented. (Yet.) |
|
The Global Styles dot just reminded a similar case, again in VSCode.
It made me wonder why the border doesn't bother me, compared to the dot. |
|
I had a good chat with @shaunandrews about this yesterday. Sharing some thoughts after the fact: Ultimately I fear that the dots (or any similar pattern) are unnecessarily cluttering the UI, and not adding enough value to warrant their inclusion – particularly in the navigation panel. Let's consider two of the key user flows / stories:
In scenario 1, I already know the thing I want to revert/delete is custom. So I just open it up, find the action, and execute. I don't need the blue dot indicator. If I cannot find the action I'm looking for, that is enough to indicate that it is already in its default state. I'm not even sure that the reset action needs to be so verbose. "Reset to theme default" could simply be "Reset". As an example, I don't think anything is lost in this design when compared to the one Shaun shared above:
In scenario 2, I am much more likely to do this from a single dedicated "Reset all" action. In global styles that might work like so:
In template context it's likely to occur on the list / mosaic view, not in the navigation panel. |
If we are not verbose I fear this could be easily mis-interpreted. Without verbosity the state we are resetting to is ambiguous and up to user interpretation. For example, a user could interpret "Reset" as reset to last save. They could hit the button expecting recent changes to be discarded and their old customized state to be restored. Instead they would lose all their customizations and go back to the theme default. |
This sounds reasonable to me. 👍 @jameskoster given the above do you think that we should close this issue #26451 and not pursue it further? We can replace it with an Issue/PR for adding the Reset action to the Document Settings dropdown. |
I think it's a much more common expectation for a "reset" action to revert to default. But you do highlight a good point – resetting is can have significant implications, and could perhaps use a snackbar confirmation with undo option.
That is my opinion, yes. Paging @shaunandrews for any additional input.
We have one over here: #23421 (comment) :D |
Description
I find the blue dot idea in the navigation panel confusing. I think it would make more sense to show an icon/badge for original theme template files. (Theme templates that weren't modified)
This PR adds a
themebadge next to the original theme templates.How has this been tested?
themebadgethemebadge and save itthemebadge should disappearScreenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: