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.
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.
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.
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.
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).
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.
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.
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.
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 🙂
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 🙂
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):
@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 🙂
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:
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.
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.
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.
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.
.
.