[Firefox] "Manage" UI changes

[stonecrusher]

Good news: Stylus 1.1.4.1 for FF is out!

1. The check for updates for all styles-button has an overflow issue now (red) for no reason, as there is vertical space available

   The string could be shortened by changing "Aktualisierungen" with the english "Updates" in the translation, but then the german translation is not consistent anymore as we always use "Aktualisierungen".

   Maybe related to https://github.com/openstyles/stylus/issues/156#issuecomment-323251240

2. Fontsize in the filter box is larger now, which I like! It just seems unintended as comparable other strings are still in smaller font.

3. Do we really still need the option for the old manage page layout? Can't see any benefit from that as the new layout also provides all information and is considerably shorter, clearer and more customizable.

FF 55.0.3 (32-Bit)

p.s.: Firefox only as 1.1.4.1 is not available yet for Chrome.

[tophf]

1. Simply rephrase the label text to be shorter on transifex. A 2-row text breaks the layout so the change was intentional to urge the translators to be less literal. There's no need for lengthy labels, but we still have a few because Jason really liked them for whatever weird reasons.

2. Our CSS didn't account for user-agent font style differences. I think all buttons and input controls may use the same 12px instead of current discrepancy (13.3px for buttons/selectors and 12px for other labels/controls):

   button, input, select {
     font: 12px arial, sans-serif;
   }

3. I don't know and I don't know how to measure its usage as we don't collect any metrics. It doesn't hurt anyway.

[stonecrusher]

1. Ok I'll try to find another translation.
2. Just do however you want to treat it, I only wanted to give a hint because it looked a bit odd
3. It doesn't matter if there is no reason against it, it is more important that there should be a reason for it. However it is not a big deal.

[tophf]

I'd say let's rename the button to "Update all" or "Update styles". No need for the current verbosity and eloquence.

As for keeping the UI option, the obvious reason is that someone may like the old layout because tastes differ. Personally, I don't mind if it's removed.

[stonecrusher]

Hmm then could you make an option for me to return to the old layout which allows big buttons cause I liked that better? Get the point? ;-)

For me personally a page where you can't read the meaning of a button is more broken than a page where some icon has another position than intended (although it is still clear where it belongs to and needs just about 600px in height which 99% of users have). But that doesn't matter, you decided to rename all and that's absolutely ok.

I can understand why Jason named it like this because there is a difference between searching for new updates and update all. To be honest that is/was a bit unclear to me which styles are force-updated if I press the button again and sometimes I thought they already were updated but I had to press the update icon again (one checkmark, two grey checkmarks, one grey, one black, two black? blurred in my memory). I know it's about not overwriting local edits. But that's another topic, I'll open an issue when I have clear proposals and reproduction steps. Just a bit confusing in the beginning.

Back to topic, I think it's always good to

• take out complexity in the code as it may need maintenance
• don't bother new users with options like that if not a considerable amount of people really dislikes the changes
• it is completely arbitrary, you could also make an option to "keep the old stylus icon"
• we don't even know if someone uses the old layout
• backwards compability for old userstyles on the internal Stylus pages is not a valid reason for me here
• might be solved when editor window is redesigned as planned in the future (can be deep down in some sub-sub-menu or visible in experts mode etc... that's how most programs do it if necessary)

[tophf]

Get the point? ;-)

Not really. Text size can be easily customized in a personal theme, but the UI layout has internal differences in the js code.

a page where you can't read the meaning of a button

I can agree in general, but I don't see how this is related to my suggestion. Both "Update styles" and "Update all" are self-explanatory even without reading the tooltip, which will contain the full text, of course.

I can understand why Jason named it like this because there is a difference between searching for new updates and update all

I can also understand or guess, but it doesn't make the reason any less weird. Regardless of how obvious any UI element is, there will be people who can't get it. They will read the tooltip or they will press the button and see what it does. The scenario you described is quite realistic, but a more verbose label isn't any more foolproof than a compact label.

Also, I'd say 99% of users who may get confused simply don't need to press this button at all, because Stylus automatically updates the styles. If we add more functions/filters/stuff to the manage page, it'd be reasonable to move the Update-all button into some "Advanced" tab or sub-panel.

TL;DR. I still don't see the point of removing the old layout.

[stonecrusher]

Did some testing regarding updates. I changed my mind and leave my thoughts just here and not in new issues.

because Stylus automatically updates the styles

That's why I didn't need to use it for quite a while. However I disabled that several weeks ago. There seem to have been improvements and less confusion, but still please see my points.

1. See above (main topic, hidden overflow on button text)
2. See above (note the different font sizes in the same box on the same context level)
3. See above (new design layout option not included on that screenshot)
4. There the confusion begins. Why check again and not force update? I already checked and Stylus already knows and shows which styles could not be updated and have local edits. The explanation text reads a lot like it would force update all if I click again. In fact there is another itermediate step afterwards. That step isn't clearer as there are still styles shown that are not affected by the force update (styles which just have been regularly updated).
5. This style has just been updated (and the tooltip correctly says the same). Not sure what the two checkmarks mean. If anything, I would expect two black checkmarks instead of one grey and one black. If I hover it, both become black. That suggests some functionality to me. When I click it, nothing happens (and I don't know what it should do to be honest). My suggestion is a grey checkmark for "update found" and a black checkmark for "updated". Or one black checkmark for "update found" and two for "updated". Either the icons are self-explanatory or a key box is needed. Yes, there is not much space for errors if you just click around, but as a user it is not a good feeling to be insecure using a program.
6. A light separator line would be cool to differentiate between functional icons and favicons. Clearer, more intuitive layout. See my suggestion in the image.
7. The tooltip on the update icon doesn't say what it does if I clicked it. First line should be check again or force update or whatever it does. Keys: updateCheckSkippedLocallyEdited and updateCheckManualUpdateHint. Btw the icon looks a lot like a magnifier but I think that is intended to symbolize "check".
8. In the german translation a fullstop was missing here ("no updates found" key: updateAllCheckSucceededNoUpdate). I guess that is because that string is used for multiple purposes. If it is used just as single notification there should be no fullstop. If it is used in an explanatory text paragraph there should be a fullstop. That's independent from language. However for now I changed the translation to have a fullstop as there also is one in the original english string. My suggestion: Remove fullstops in the translation strings and hardcode it for use in explanatory text.

[tophf]

We already discussed 1-3. As for the screenshot, apparently we need a wrapper with white-space: nowrap around the check button and the log button so that the two are always on one line.

4: the first time the edited styles weren't checked at all, they were skipped, which is shown in their red status icons tooltip, hence "check again".

5: the double checkmark is to differentiate the "already-up-to-date" and "update-installed, now it's up-to-date" icons. I think it's pretty logical and better than the one you suggested with different colors. You wouldn't believe but it's possible to nitpick on any icon, even a well established one, and point out inconsistencies and weirdness.

6: I'd prefer a larger space between the columns. I dislike separators, like really.

7: indeed, we should describe the action. BTW the icon intentionally mixes a magnifying glass for "search" and a recycle action for "refresh" that stands for getting a current, fresh state i.e. "search for updates".

8: updateAllCheckSucceededNoUpdate is used only in one place and it has a full stop in English. I guess because it's not a label, but a status message that expresses finality, but I don't have a preference on that.

[stonecrusher]

4:

the first time the edited styles weren't checked at all, they were skipped, which is shown in their red status icons tooltip, hence "check again".

I still don't get it. I don't know what exactly is done in the background, but if they are skipped because it already locally knows that they were edited, isn't it a consequence of a local edit that there will always be an update available because it has different code? What purpose has that second check? Even in the rare case if I would do the exact same edit locally as the style author on USO it wouldn't hurt to overwrite my local edit by the same code again.

5:

better than the one you suggested with different colors.

You're right, I would get rid of colour coding whenever possible. So you could take my second suggestion just using the number of checkmarks. The grey-black-thing is unclear to me and I still don't know if it has a meaning.

It's part of the confusion why there are two states of "up to date". Does it matter if a style still is up to date or if it was updated just now? It may make sense internally, but I only care about that it is up to date right now. I've seen it in the filtered view before which styles receive updates. The filter shouldn't show "already up to date" styles anyway. I think you introduced it because of that intermediate step.

The hover effect is still confusing as it usually indicates some functionality. I've noticed there is an hover effect also on other icons but then it happens uniformly. Following this as a style decision there should be two grey checkmarks and hovering it both should be black. Just that we don't miss it, a clear question: Is there any colour coding present?

Sorry if you see it as nitpicking (I know I can be annoying but I'm german and therefore hell-bent on details ;-) but I am interested in making Stylus as intuitive and userfriendly as possible. I would consider myself an experienced user and still I have problems understanding what's going on when I do updates.

6:

More free space also means less space somewhere else. But how bad can it be... both solutions are ok for me.

8:

updateAllCheckSucceededNoUpdate is used only in one place

Ok it's in the same place, but one time in a fluent text and one time stand-alone as status message. You also wouldn't use a fullstop after "deleted" or something like that.

[tophf]

4: some users modify externally maintained styles instead of properly creating a new one with their own customizations. Our conscience doesn't allow us to simply overwrite their changes. That's why such styles are excluded. That's why unattended auto-update was never implemented in Stylish.

5: there are two checkmarks because one is for "update installed" and the other one is for "up-to-date" so two actions completed = two checkmarks, pretty obvious IMO

6: uhm yes, but there is a lot of free space in applies-to column so it's not a problem

8: I don't remember now as I don't use the update button anymore; can you show a screenshot for the other use case?

[Mottie]

5: there are two checkmarks because one is for "update installed" and the other one is for "up-to-date" so two actions completed = two checkmarks, pretty obvious IMO

It wasn't ever obvious to me either... I think this needs a tooltip.

[stonecrusher]

4:

Our conscience doesn't allow us to simply overwrite their changes.

For sure, that's why they were skipped in the first place. At this point the program and the user know which styles were locally edited and skipped. They are almost guranteed to have different code available online (="update"). So why check again? The next step should be force updating.

8:

[tophf]

4: well, technically yes, but I think that current approach works as is, I don't see any problem in one more step that would decrease the likelihood of the users overwriting their changes, especially now that the users already are accustomed to the present behavior, changing it would be reckless and uncalled for.

8: in English both cases have the period and like I said above I think it's okay.

[stonecrusher]

4: It's absolutely irritating. Even the text updateAllCheckSucceededSomeEdited doesn't tell me that I have to 1. check again and 2. then update again. Users are already accustomed to it is a weak argument to me if you're talking about software in beta status. In fact that second check does absolutely nothing meaningful to the user and should be removed.

If you care about the likelihood of overwriting, then an alert is much more appropriate and clear. Another check doesn't warn you of anything. To be sarcastic you could also introduce a captcha before overwriting, that will drop the likelihood of errorneous overwriting a lot but still you'd get my vote to remove that. In the text it already says clearly local edits will be overwritten (but they won't if you press that button because that button will perform another check and not update or overwrite anything).

[tophf]

updateAllCheckSucceededSomeEdited tells what you can do so your argument isn't convincing and I don't understand what's so irritating and why you edit external styles at all and why you use the update button. At this moment the entire use case seems contrived and unnatural to me. Maybe someone who understands this weird workflow better than I do can weigh in.

[stonecrusher]

I sometimes edit external styles

• because it is possible
• because I sometimes like the style but just need very little adjustments like a darker font or wider pagesize
• because I can make obsolete styles that haven't been updated for years working again with little effort
• because it's much more convenient than copying and pasting, giving a new name, save the new, delete the old...
• because I don't want my list of styles crowded with unnecessary double styles

I use the update button because I have disabled autoupdate.

I don't think manually updating a locally edited style is an unnatural use case. This happens quite often e.g. when I beautified a previously minified style to read it.

[tophf]

Well, it still seems a rather unconventional and unnatural use case to me. And the very possibility of editing an external style also seems unnatural and weird. Like really backwards. A straightforward approach would be to disconnect the style and make it non-updatable with some warning displayed. We can add "make it local" and "clone as local style" button, it's much more easy to understand and handle during the update check than the unpredictable variety of intentional/unintentional edits.

[tophf]

It wasn't ever obvious to me either... I think this needs a tooltip.

Does it really? I don't think so. There is no real need for the explanation of why the two checkmarks are used, much less showing it in a tooltip, it's just that I'm humoring stonecrusher's curiosity.

[stonecrusher]

I'll take it as a compliment :-)

Yes you are right with that post before. I have some styles that I never want to update and they always show up because I locally edited them. By now I know by heart which ones to force update and which not. Would be much cooler if I had not to choose the others every time but to be able to force update all (unnecessary local edits like beautification, testing etc).

[tophf]

I guess we can add an ability to disconnect styles (e.g. "make it local"), and it'd be handy to have user-customizable labels in the manager. And technically it's possible to skip the additional check for edited styles, of course (it's just that I'm being overly cautious as I've stopped editing external styles and don't understand why this feature exists, now I always make my adjustments in a separate local style).

[Mottie]

now I always make my adjustments in a separate local style

Yes, I agree, it is easier, and better, to tweak old styles by adding a new separate style. Then there is no chance of your code being overwritten when the other style is updated.

[narcolepticinsomniac]

humoring stonecrusher

No doubt. Please summon this type of patience the next time I'm alpha-testing new features and pulling extreme edge-case scenarios out of my ass. =)

nitpicking

This entire thread in a nutshell. I don't even see any productive nitpicking, only personal preferences regarding insignificant details.

I would consider myself an experienced user and still I have problems understanding what's going on

This is a paradox. Both cannot be true at the same time. If you are halfway decent with CSS, why are you scratching your head as to why elements clearly converted from label to select might have a slightly different appearance? They have different functionality, so... should their appearance not be an indicator? Why are you pretending not to understand that the thread you referenced as "possibly having to do with", is clearly discussing those exact changes and why the ellipsis was implemented?

FWIW, we went through a lot of trouble to make the update processes as fool-proof as possible regarding edited styles, and users have really appreciated this feature. It's been months without a single bug report or even a complaint, so I'd say it's working pretty well. "As fool-proof as possible" does not make it fool-proof, however, but it is more than adequate. Instead of dreaming up ways to screw with it, maybe make better choices in how you edit styles. This is meant to be a preventative measure for users who have made bad choices, not an encouragement to do so.

[stonecrusher]

nitpicking

2,3,6, and 8 can be counted as personal preference if you want so, I call them interface and consistency improvements. Details are love and it's bundled here. If no one ever mentions it, devs will never know about it. What really will be changed is on another paper but at least I give suggestions. 1 is a small bug / bad change decision 5 and 7 are abiguous / questions 4 is that unnecessary misleading step in the update process We now also have 9: disconnect styles

why are you scratching your head

Am I? Writing CSS over 10 years by myself and told in my post that it looks unintentional and should be corrected. You don't need to be a genius to see what declaration might have been forgotten. Btw the quote you mentioned is out of context and not about CSS but ending with when i do updates.

Why are you pretending not to understand

Yeah, delete the "maybe" in the first post. I only quickly read through that thread and wanted to be nice and give a link but still have insurance if I linked shit. Also had problems translating "ellipsis" by heart. For me that was a squeezed circle, not three dots. So I didn't fully understand. Sorry for not investing more time to that at that moment. Before you complain: I never ever used the CSS3 ellipsis option for text-overflow although I now remember reading about it several years ago and I never ever styled the browser itself or internal addon pages. Not even opening the inspector there. Why should I when it won't work in the future anyway?

What I still don't understand is why you crop the button when that guy (that was impolite af and only claiming and threatening) actually wants a wider/flexible sidebar and already doesn't understand the button label in complete form. It's like you can't go through the door with the table so you cut off a leg. Ellipsis is just a nice form of hidden which imho is very rarely a good choice for text. However that point should be obsolete now by changing the text.

I never doubted that it probably is best practice to create a new style next to the installed one instead of editing. But everyone has to find out for him/herself and I gave some reasons above to still do otherwise. For styles that have frequent updates or considerable changes I also have a second style with personal changes. I didn't know that I have to justify making local edits when it is a featured function.

I absolutely do appreciate the update feature! It's about the handling.

maybe make better choices in how you edit styles

As you clearly have never had to update a list of styles including locally edited styles by yourself you might make better choices on what update routine you comment. Sorry, had to fire back on that :-)

You're talking a lot about fool-proof... as I already said checking again is no warning, it's like always leaving the first chamber empty in your revolver without telling the guy you gave the gun to. He'll know after 2 or 3 times but it will be confusing in the first place.

[narcolepticinsomniac]

Details are love and it's bundled here.

Found the new catchphrase for our promo tiles.

1, 2, 3 4, 5, 6, 7, 8

I saw no valid issues the first time, so I'm not cross-referencing which ones are less valid than others.

Am I? Writing CSS over 10 years by myself and told in my post that it looks unintentional and should be corrected. You don't need to be a genius to see what declaration might have been forgotten.

Seems like. Nothing unintentional or forgotten. Tophf changed them to select because they now have dropdown options. Makes sense. select elements have slightly larger text and arrows to indicate functionality. Makes sense.

As you clearly have never had to update a list of styles including locally edited styles by yourself you might make better choices on what update routine you comment.

None of this makes any sense. I have published styles which trigger the fail-safe, some of which are blanked-out deleted styles on US.o which I still maintain locally. The feature has two intended purposes. Authors with published styles, who should never need to overwrite their local copies, and users who have made the poor decision to locally edit someone else's published style, which is something you should only do if you never intend to update that style either.

If you want to alter someone else's published style, you should make a companion style and override whatever you want to change with specificity. This is not an opinion, it's a fact. The ability to override the fail-safe is there because ultimately the user should be able to decide if they know better. Maybe they tested something unimportant, or maybe they want to start fresh. This being the case, the extra step is warranted.

you could also introduce a captcha

Best idea you've had here IMO. =)

If tophf wants to implement a way to disconnect styles, sure, that'd be useful, but styles excluded as "locally edited" should not be styles users are looking to force an update on in 99.9% of scenarios, so them being excluded serves the same basic purpose.

[narcolepticinsomniac]

What I still don't understand is why you crop the button when that guy (that was impolite af and only claiming and threatening) actually wants a wider/flexible sidebar and already doesn't understand the button label in complete form.

I basically told that guy to get bent. It had nothing to do with what he wanted. I changed the button because tophf asked me to, and I agreed with the reasoning. Ellipsis is preferable to breaking the layout with super long and unpredictable translations.

Also had problems translating "ellipsis" by heart. For me that was a squeezed circle, not three dots. So I didn't fully understand.

NBD. I'd be lost if you start speaking German. You know now though. They're specifically intended for use in cases where text breaks the layout. They imply a tooltip, which there should be, correct? We make decisions based on what we think most users will prefer, but there's no accounting for taste. If you don't prefer it, it should take all of 60 seconds to make a userstyle to change it back. The same goes for any of the other little details you take issue with.

[tophf]

I don't mind skipping the additional step if it's an option disabled by default because there may be many users who edit external styles for the reasons listed above by stonecrusher. Here's the test version: issue-189.zip. The option is in the Advanced section. BTW it's collapsed now by default in Chrome due to its hardcoded limit of the overall dialog height at 640px.

[stonecrusher]

@tophf Cool. Tested your zipfile. Wrapping works, more space looks good, but I can't see any difference in update behaviour. The option is deactivated (switch on the left, was default) and it still finds updates for locally edited styles. FF Nightly 57.0a1 (64-bit)

[tophf]

When the switch is deactivated the behavior doesn't change, of course. I've only agreed to alter the behavior when the option is enabled, duh.

[stonecrusher]

The option says Include locally edited external styles. Deactivated = do not include. So when I search for updates they should not be included and no updates for locally edited should be found. However, no matter if the switch is on the left or on the right, it always finds updates for these.

[tophf]

Well, I'll rephrase it, I guess. When it's enabled it does what you wanted. Don't tell me you forgot already.

[stonecrusher]

As I said, if the option is activated it also finds updates. Thanks for thinking I'm stupid.

[tophf]

No, I don't think you're stupid. I think you're trying to make a point the option has a misleading name, which I already understand. Like I said, when the option is disabled, the update behavior remains the same (it skips checking modified styles on first check). When the option is enabled, the modified styles are checked for updates during the first pass so you don't need to run another check. This is how I understood what you wanted above.

[stonecrusher]

No, it was not about a maybe misleading name. I would have directly told you. It doesn't skip modified styles on first check. What I do:

1. temporary load the zip you provided (deleting github stuff before)
2. enable that option (also tried leaving it disabled)
3. install a style from USO and modify it by adding a comment
4. click search button in style manager
5. an update is found which should not have been the case

/edit ok it took me a while to spot a difference. Deactivated there is a yellow tooltip, activated there isn't. Apart from that everything is the same?! I thought it's more like a "never update locally edited styles". Or that they don't even appear when searching for updates.

However you don't need to make edits just for me (thanks anyway). It's more important that you know that this usecase might not be as rare as you think because it is the most naive approach on changing an existing style.

My proposal would be to get rid of the second step so you have search --> update in two steps and not search --> search again --> update and a switch in the options to never update locally edited styles.

/edit2 Found https://github.com/openstyles/stylus/issues/39 which would also be a solution (at least if not manually updating).

[tophf]

Apparently we completely have been misunderstanding each other all this time. I've followed the 1-5 steps above and I also see an update immediately upon checking which is the correct behavior. An update should be found because it's the only way to undo the local edits. The only difference the option makes (for which you fought so hard in my understanding of this thread) is that in its default state it won't find an update at step 4 (only a red icon will be shown in the style row).

[stonecrusher]

Apparently we completely have been misunderstanding each other all this time.

The root of all relationship problems...

An update should be found because it's the only way to undo the local edits.

Yes, only if updating locally edited styles is allowed in the options (that would be a possible new option). And it should be found in the first place, not searching again. We know it's locally edited and so we know there is an update. It's not beneficial to completely skip them on the first search attempt. Especially as they show up anyway ("problem updating") and irritate as they are not also updated in the next step. However it can be beneficial to skip them on the first update attempt but actually all of that makes it more complicated in my view.

Another approach on this could be two make instead of one two separate filters styles with updates and styles with problems updating and when you hit the update button it only updates the ones which are shown. So you don't need to mess around with checkmark boxes for each style or something like that and you're not insecure if all shown will be (force?-)updated or not.

in my understanding of this thread

yeah, no, you are right, I think we misunderstood each other. And actually in the beginning the thread wasn't even about the update process, but on the lovely details :-)

/edit To be clear again for the update process, what I want/expect as a user:

1. Search for updates
2. All available updates are shown (doesn't matter if you really checked for an update or only guessed it because of already known local edit). If locally edited ones - which would be overwritten - are present, they will be marked and the warning will be shown on the left (or an annoying alert popup in the next step if you want).
3. I choose which to update (e.g. by checkbox on each style - supported by meta checkboxes on top to "select all/none" "select only locally edited" etc.)
4. I press update and the ones I chose are updated.

If there is no step 3 to choose but all shown will be updated, the filter should be split in two filters as suggested above. Then only update what is shown on the right. Or keep the filters, all shown should be updated except the ones I marked as "disconnected" or "never update" before. These ones wouldn't even show up in step 2.

Straightforward, no confusion. As seen in many other programs before.

[tophf]

Eh, that's not straightforward IMO because the very editing of external styles is backwards. Your suggestion sounds like a complication of UI. I'd rather remove the option I've added and just forget the whole thing.

[tophf]

I've pushed the trivial fixes for UI layout issues reported in this thread so I'm closing it.

Please open a new issue with your ideas for updating locally edited styles. Even though I may not implement it personally, but having a separate issue with all the rationale will expose it to more users who are editing external styles, and someone might submit a PR that solves the problem in a way that doesn't complicate the UI and the code.

[stonecrusher]

Then do that.

IMO if you omit step 3 there won't be UI complications. My main claims are

• After search, (force-)update everything that is currently shown when I press update (gets rid of second search as a side effect and can be finetuned by splitting the filter Only with updates or issues into two filters)
• Give a possibility to exclude styles from updating (no matter if locally edited or not)

/edit

I've pushed the trivial fixes for UI layout issues

Thank you.