[Improvement] Enhance the visibility of edited values

Tagged: ,

Author Posts

ddenev May 6, 2018 at 4:56 pm

Heads up! this post was created when Microthemer was at version 5. The current version is 7. Some references to the interface may be out of date.

Hi Sebastian,

In order to improve the readability and visibility of the edited values (the same approach that you already have for tabs and groups with the blue dot), I would like to suggest that the edited values are also indicated somehow.

This came out because I am constantly struggling to locate the edited value although I know (by the blue dot) that it should be somewhere in the current tab/group.

Please take a look at a concept screenshot:
https://www.dropbox.com/s/dkzgtflzx1q0ff5/microthemer_edited_important_indication.png?dl=0

It also suggests how the !important values could be indicated, as a follow-up to https://themeover.com/forum/topic/improvement-enhance-the-visibility-of-values-that-have-important-set

Thanks!

Sebastian May 7, 2018 at 2:05 pm

Thanks for the suggestion Drago! I’ve passed this onto Monika. She’s away on a Yoga retreat but will be back in a week. I know what you mean about tracking down edited fields. I had a quick go at this myself a while back, but couldn’t arrive at an aesthetically pleasing solution, and moved on to other things. Hopefully Monika will have more luck 🙂

Regarding the red background for !important, that might be too close to symbolising an error. And I might need to reserve that signalling for an upcoming feature which will detect if the last value entered into a field successfully changed the existing style rule. This will alert users to specificity issues. In which case, perhaps a more obvious “i” with a background color would be an option for !important.

ddenev May 7, 2018 at 2:24 pm

Hey Sebastian,

thank you for considering this request!

I agree about the red color – maybe yellow or orange may be better, but I wanted to get the idea through – that a visual indication would be very helpful.

Best regards

ddenev February 4, 2019 at 8:20 pm

Dear Sebastian,

Is there any progress on the feature with visually indicating edited values?

I have to say that the blue dot on the tabs and the groups is very helpful but then I lose all the time I saved due to it when I reach value level 🙂

Best regards

Sebastian February 5, 2019 at 11:57 am

Hi Drago,

I let this one slip. But you are right to bring it up again. It is an important issue. I’ve chased Monika about it. Feel free to buzz me again if I haven’t come up with something by Friday. I’d like to arrive at a good solution for this too.

Cheers,
Sebastian

Sebastian February 8, 2019 at 6:44 pm

After playing around with several options, I’m trialling blue dots at the bottom left of property fields. My hope is that users are suitably tuned to the blue dots to help in this situation too.

You will need to enable Edge mode in MT’s preferences to see them (running version 5.5.3.6).

Blue dots on properties

Of course it may be too subtle given the breadth of the property options. But let me know if helps 🙂

Cheers,
Sebastian

P.S. I just noticed that the blue dot is bit misaligned on the background-image property, I’ll fix that in a subsequent release.

ddenev February 8, 2019 at 7:44 pm

Hey, Sebastian

Thank you very much for taking this request into account and coming with a solution!

It’s a nice touch indeed. I played a little bit and IMHO the dot is still lost in the overall “noise” of symbols, lines, boxes, etc. I was thinking about a bit more visually … er… visible way 🙂 to show the changed values.

I took the liberty to play a little bit to provide you with what’s on my mind. Please be forgiving, I just want to show an alternative.

In the long run you could play with the color, the thickness, the outline maybe inside the boxes (not outside), you could also glow/colorize the icons. You might also combine the dot with the outline.

ddenev February 8, 2019 at 8:42 pm

Here is the CSS code I use (I use a Chrome extension called Stylus to apply persistent styles) if this could help:


#tvr-options .property-fields .manual-val .tvr-input-wrap {
    box-shadow: 0 0 6px 2px #5086F7;
}
#tvr-options .property-fields .manual-val .tvr-input-wrap::after {
    bottom: -4px;
    left: -4px;
    width: 8px;
    height: 8px;
}

This is very basic but you get the idea :).

Another observation – the color value control does not receive the dot when changed. In addition, the parent of the <span class=”tvr-input-wrap”> that usually gets the “manual-val” class when a value is entered, doesn’t get this class for the color control – this prevents the above CSS from taking effect. If I reload the page after save though, the “manual-val” is applied even for the color control.

ddenev February 8, 2019 at 9:07 pm

A small bug:

The blue dots have z-index of “999914!important” which leads to:

ddenev February 8, 2019 at 9:12 pm

Here is what I settled at. It works great for me:

Here is the CSS:

#tvr-options .property-fields .manual-val .tvr-input-wrap {
    box-shadow: 0 0 6px 2px #5086F7;
}
#tvr-options .property-fields .manual-val .tvr-input-wrap::after {
    bottom: -4px;
    left: -4px;
    width: 8px;
    height: 8px;
}
#tvr-options .property-fields .manual-val .tvr-input-wrap input {
    color: #4169E1;
}

Sebastian February 11, 2019 at 12:11 pm

Hi Drago,

Thanks for sharing your experiments and reporting the bugs. I’ll get those fixed ASAP.

Your solution definitely succeeds in making the edited values obvious. We will need to balance this requirement with keeping the design congruent. I will discuss things further with Monika this week. In the meantime, are you OK to keep using Stylus to apply your custom highlighting?

I really appreciate you engaging so much with the development of MT BTW 🙂

Cheers,
Sebastian

ddenev February 11, 2019 at 12:16 pm

Hi Sebastian,

Thanks for taking into account the above suggestions!

I really don’t pretend them to be the best solution and just wanted to give you a possible direction. I’m sure you’ll do it in the best way.
No problem for me to continue with Stylus for the time being.
And thanks for the kind words, I enjoy your product and your attitude and that makes me want to be of help 🙂

Best regards

granthawkey February 20, 2019 at 2:03 am

I’m following this with interest as well. I’ve taken ddenev’s idea with the outline, and changed it to be a solid green line matching the other green in the UI. To my eye, this matches the UI more, and doesn’t add as much height as the blue dot.

Here’s my override code (again credit to ddenev for the bulk of it):


#tvr-options .property-fields .manual-val .tvr-input-wrap {
	box-shadow: 0 0 0 1px #34a853;
}
#tvr-options .property-fields .manual-val .tvr-input-wrap::after {
    bottom: -4px;
    left: -4px;
    width: 8px;
    height: 8px;
}
#tvr-options .property-fields .g-font, #tvr-options .property-fields .tvr-image-upload {
    margin-bottom: -5px;
}

Looking forward to seeing what Sebastian and Monika do with it 😁

Cheers.

Sebastian February 20, 2019 at 9:59 am

@ddenev I fixed those z-index/color picker bugs yesterday BTW.


@granthawkey thanks for sharing your interest in this. Good to know it’s an issue others want solved. And thanks for sharing your efforts, I’ll have a play with that. And I’ll try to pin Monika down this week to try out some variations in edge mode for you guys to review 🙂

ddenev February 20, 2019 at 6:38 pm

Hey Sebastian,

thank you for fixing the bugs!

One more small buglet to fix 🙂 – when just clicking (without changing anything) on the color control, the blue dot is added indicating a change (and a color is applied to the color control) even though there is no actual change applied to the element. If I just click outside of the color picker popup (effectively wanting to not apply any color) the color control stays with the blue dot and the new color (which was somehow automatically selected) while the actual element stays unchanged. I have to either click on the trashcan icon or reload the page.

I guess you immediately tell the color control that it is changed when it is clicked. Maybe an Apply button can help or explicitly selecting a color. IMHO the color picker component might need some additional love 🙂


@granthawkey: thanks for the improvement, I really like the subtlety that you added (mine was too much “in the face” 🙂 ). I still prefer the blue color though – I think it’s more in line with the blue dot. I settled for:

#tvr-options .property-fields .manual-val .tvr-input-wrap {
    box-shadow: 0 0 1px 1px #5086F7;
}

the rest is the same

Sebastian February 22, 2019 at 2:32 pm

I noticed that buglet too when I was fixing the blue dot on the color picker @ddenev. I had a feeling you would bring it up lol! I will take a look at it over the weekend. It will need a bit of thought. Currently MT defaults to the computed color to make it easier to anchor off – e.g. make the color a touch darker or lighter. But it will need some adjustment in order to do this without auto-setting the color value.

Sebastian February 24, 2019 at 3:55 pm

Hi guys,

I’ve just released 5.5.4.2 which includes a new design for the edited fields based on your suggestions. I’ve also included a green active state for the fields. Monika thought this was necessary as the blue border pattern is often used for active fields. Green fits with Microthemer’s green background for the active property group.


@ddenev – I also fixed the bug with the color picker defaulting to AND applying the computed color when clicking the picker when no color is set. I’m currently using the blue dot to mark it’s been edited. Maybe that will change. I’d like to hear how you guys find working with the current edge mode design for the edited fields.

Cheers,
Sebastian

ddenev February 24, 2019 at 9:10 pm

That’s great, thank you!

The new default active state is great, although a little bit too subtle for my taste 🙂
The green indicator was also a great addition – congrats to both of you!

One final touch (maybe) on the “saga” – IMHO making the green and the blue outlines have the same thickness will be more consistent.

Thank you again for listening to customers!

Best regards

Sebastian February 26, 2019 at 9:52 am

Glad to hear we’re moving in the right direction Drago. Could I ask that you try the current system for a week and then let me know if the blue outline is still too subtle? The logic for having an extra pixel width on the active field was to make it stand out against the blue, which may be lost if edited fields also have 2 pixels border-width.

Next week I will canvas some more opinion on this design change before taking the feature out of edge mode. I hope to trial the GUI-code editor syncing feature at the same time.

Cheers,
Sebastian

You must login or register to reply to this topic.