inline search does not show description and/or more sugesttions
paponius opened this issue · 5 comments
Bug Report and few suggestions
Bug Description
There is no description shown while viewing found Styles in inline search.
The description is shown only after a style is just installed, and only until the search is re-opened.
Screenshots
CSS Code
System Information
- OS: Linux and Windows
- Browser: Firefox v122 and Chrome v121 and v119.
- Stylus Version: 1.5.46
Additional Context
Additional rather suggestions for the inline search feature
-
Configure button could be visible and clickable before installation.
It is possible to view options on USo site (or was when I was using it).
Checking possible Options might provide additional quick description to what a Style does, e.g. in this Deannoy Style: https://userstyles.world/style/14775/deannoy-imdb-papo -
Some installed styles are not "connected" - recognized as installed.
Some Styles I have installed for a longer time do not show as installed in inline search.
If I click to install it and then uninstall, it will be uninstalled. Then I can install it regularly.
No idea if this is by design or a bug. Please let me know if I should investigate more. -
Similar and possibly the same issue occurs with Styles I created locally and uploaded to USw.
- Maybe a special property for own styles. To know it's mine own. To not uninstall it by mistake. Though it still would update, as edits can be done in another browser or externally.
-
[bug] When a Style, locally created or not, is successfully uploaded, it should have its "Edited locally" bit reset.
Successfully uploaded Style should be considered identical with its repository version. And it should be possible to later update it from the repository. (automatically and without force).
Now when a style is created/edited in Browser A and uploaded, then modified and uploaded in Browser B. It will not be updated in Browser A. -
[bug] Missing conflict resolution.
When a Style is modified in Browser A but not uploaded, then later modified in Browser B and uploaded,
uploading the Style from Browser A will overwrite the repository version.
Even if a version from Browser A is lower than the version uploaded from Browser B before. (but that by itself is not a problem, as the resolution shouldn't be based on higher/lower version)
This situation should instead create a conflict (inform and confirm dialog), saying the version in repository did change externally meantime. -
"Also search global styles" checkbox.
- It is not self-explanatory (at least not to me)
Suggestions:
"Also show Styles not specifically for this domain/site"
"Also show Styles not applicable to this domain/site"
"Don't limit search to this page domain" - [bug] It is enabled by default, but the list of found Styles (while the Search box is empty) does not represent "global" style search
Also, is it more probable a user will want to search "global" styles, or just those specifically for current site?
- It is not self-explanatory (at least not to me)
-
New Search sort option: "Sort by popularity", a sort which multiplies total installs by a coefficient of a style age (since update).
As the Total Installs sort does often show a lot of non working styles at the top.
e.g. A style installed 100 times, which was updated withing last year has the same sort score as a style installed 1000 times withing past 10 years.
The issues and suggestions above are somewhat connected, but let me know if you want me to re-post them separately to get more attention.
description is shown only after a style is just installed
Configure button could be visible
All of this is intentional, the index doesn't have such info, and I don't want to make 1-100 network requests for each style individually. I guess I can add a tooltip over this area "Click to install the style and load the description"
Some installed styles are not "connected" - recognized as installed.
Similar and possibly the same issue occurs with Styles I created locally and uploaded to USw
Can't investigate without seeing it myself.
Maybe a special property for own styles. To know it's mine own. To not uninstall it by mistake.
I don't see such feature in other apps. Just be careful and regularly/automatically back up all your data.
When a Style, locally created or not, is successfully uploaded, it should have its "Edited locally" bit reset.
We can do it for USW if the installation URL is also from USW.
Actually we can't because publishing doesn't save the style.
"Also search global styles" checkbox.
Your suggestions seem much more confusing to me. I can't think of a better alternative, but I can add a tooltip with a detailed description how this checkbox works depending on whether there's any query.
"Sort by popularity", a sort which multiplies total installs by a coefficient of a style age (since update).
There's no such info in the index. Only the overall numbers.
The issues and suggestions above are somewhat connected
It doesn't matter, each issue should be reported separately, otherwise it's impossible to keep track of things.
Missing conflict resolution
I'd say we aren't git and dismiss the idea, but maybe @Gusted or @vednoc could implement it on USW server - if it makes sense - to reject the upload by default if the code version is below the currently published one and allow publishing when body is {code: '...', force: true} or something like that.
Or it can be true by default to keep the API backward-compatible and Stylus will send false first, analyze the rejection code, ask the user, then send true or omit it altogether.
"Sort by popularity", a sort which multiplies total installs by a coefficient of a style age (since update).
Apparently I misunderstood this suggestion. This may be close to "yearly average installs", which I can implement can't implement anyway as the index doesn't have a "created date" whereas using only "updated date" wouldn't produce a sensible estimate.
description is shown only after a style is just installed
Configure button could be visibleAll of this is intentional, the index doesn't have such info, and I don't want to make 1-100 network requests for each style individually. I guess I can add a tooltip over this area "Click to install the style and load the description"
Tooltip seems a good idea.
But as the Description bottom bar is too small anyway to show something useful, why not just remove the description bar and show full description in a hint.
A Fetch could start 0.2s after hover and show a tooltip with full description in 0.5 or 1 sec. With a bit of Sleep, to have a time consistency.
Not sure if there is proper API, or a part of a script must be loaded, but in most cases a description should come in first 500 to 1000 bytes. And a Fetch could be cancelled now if mouse leaves the item.
The 0.2 delay will take care of a fast scrolling case, with possibly dozens of Styles "hovered". It'll make max a dozen of Fetch requests.
This is not an unreasonable API use.
Or viewport instead of a hover. Loading couple of Styles descriptions ahead, also with some delay to take care of fast scroll.
Some installed styles are not "connected" - recognized as installed.
Similar and possibly the same issue occurs with Styles I created locally and uploaded to USwCan't investigate without seeing it myself.
Yes, sorry, I meant me. That I can investigate, do some tests. Maybe it's sync related.
When a Style, locally created or not, is successfully uploaded, it should have its "Edited locally" bit reset.
We can do it for USW if the installation URL is also from USW.Actually we can't because publishing doesn't save the style.
That shouldn't matter. Uploading in a clean state, and vice versa, could reset the "Edited locally" bit.
But there is also the idea I proposed before. Always upload on save. With a checkbox. Though unsuccessful uploads should then be handled somehow. e.g. show red icon in Manage, click to manual re-try.
And the "Edited locally" bit mustn't be reset before an upload success.
"Also search global styles" checkbox.
Your suggestions seem much more confusing to me. I can't think of a better alternative, but I can add a tooltip with a detailed description how this checkbox works depending on whether there's any query.
I agree it's an opinion based case.
A Style for the Wikipedia will give 557 results. Entering "Dark" in Search box will not show less (which I expected), but 619 results.
As I understand it, I really think the "Also search global styles" checkbox should be off by default and even disabled when there is no text in Search as it does not play role without text.
I know probably more than an average Stylus user, I know there are misnomer-ed "Categories" and also how @-moz-document works. And that it could be as narrow as a specific html page, or broad up to .*. But this just adds to the uncertainty of what the "Global" is. Also which fields Search is searching, and by what are results limited when "Global" is off. Would make sense if Global means "Categories" are ignored and only @-moz-document applies. But IDK.
I am not asking for an explanation, I can find out by testing, it's just to illustrate how it could confuse a user.
Missing conflict resolution
I'd say we aren't git and dismiss the idea, but maybe @Gusted or @vednoc could implement it on USW server - if it makes sense - to reject the upload by default if the code version is below the currently published one and allow publishing when body is {code: '...', force: true} or something like that.
Or it can be
trueby default to keep the API backward-compatible and Stylus will sendfalsefirst, analyze the rejection code, ask the user, then sendtrueor omit it altogether.
It can't be version based. There could be at-work and at-home PC or even two users co-authoring. From v 1.0, Browser A can edit to version 1.1, later to 1.2, then later Browser B will edit to "1.1", which is newer. But it does not matter, as even two different 1.1 versions must be resolved.
There is only one way, I can see, to do this without more issues popping up later. Stylus must save hash of the "clean" Style. That is just before it gets the "Edited locally" flag. Then within one upload session, it will compare the hash to the hash of the Style in the Store. A resolution would be a dialog: save locally modified Style as a new Style, discard local edits, force upload and overwrite server copy.
"Sort by popularity", a sort which multiplies total installs by a coefficient of a style age (since update).
Apparently I misunderstood this suggestion. This may be close to "yearly average installs", which I
can implementcan't implement anyway as the index doesn't have a "created date" whereas using only "updated date" wouldn't produce a sensible estimate.
The inline search shows by default sort by number of installs. A lot of styles on top places are 10 years old and not working, or not working properly. Furthermore, as users have to Install to find out that such Style is broken, they will raise the Installed count even more. And we'll never get rid of broken Styles sitting on top positions.
The "popularity sort" could be more complex, I just proposed simple two parameter score calculation. But of course rating should play a role. Still, the most important two parameters are Updated Date and Installed Count.
A Style with 500 Installs, updated ten years ago. 500 / (10 * K). If coefficient is just plain 1.0, This Style will have pop score 50.
Another Style with 100 installs, but updated one year ago. 100 / (1 * K). Gets pop score 100 and will show above the old one, which is possibly broken.
Sure it's not perfect, but probably a bit better. There is a possible issue of fake update to gain score. But such checking is a job for a Store.
Optimally, an API which can receive rating from an app (Stylus), disable and uninstall stats, token protected for rating spoofing.
Then store would offer such Popularity score itself with each Style. But meantime, at least the above?
The issues and suggestions above are somewhat connected
It doesn't matter, each issue should be reported separately, otherwise it's impossible to keep track of things.
Yes, I can see that now. I didn't expect my ideas to get too much attention. And did not want to post 10 "Issues" at once.
description
No, these suggestions are unreliable/glitchy. I've already removed the description bar so now it'll be shown only after clicking.
"Also search global styles" checkbox should be off by default
how it could confuse a user.
I'm not convinced because so far you're the only one.
A resolution would be a dialog: save locally modified Style as a new Style, discard local edits, force upload and overwrite server copy.
No git. We already support a good workflow used by developers universally: edit your file using an IDE/editor in a git-controlled folder.
popularity sort
Sure it's not perfect, but probably a bit better
No, it's entirely unreasonable as we can't be sure that an old style doesn't work.
And did not want to post 10 "Issues" at once.
It's impossible to discuss 10 issues in one meaningfully.