Questions on the UI
remusao opened this issue · 5 comments
Hi @devidw,
It's great to see this tool getting together and having a community-based editor for Goggles! So congratz for that.
I was giving it a shot and has some early feedback on the UX, in case that's something you'd like to consider.
On the below:
- There are a few buttons but it's not immediately clear what they do, maybe would it make sense to have on each of them a short tooltip when hovering with the mouse to explain what they are about?
- When duplicating a Goggle instruction, we end up with two entangled rules (changing the action of one for example will also apply the same change to the other one).
On the below image, if we create a rule then use a newline, then it is seen as two rules (one being empty and resulting in $downrank=6,inurl); maybe would it make sense to ignore empty lines? Or prevent the edition of two instructions at the same time?
On the below image, when creating an empty instruction, then maybe we should not reflect it to the Goggle until the pattern or action is non-empty?
Otherwise we end up with something like this:
Thanks a lot for working on this, it's looking great!
Hey @remusao
Thanks for those detailed suggestions and notes ✨
Will go over all of these in detail
One note on the Goggle-Editor, the Site field above the Pattern field is designed to handle the $site=… option.
Maybe there is a better way to indicate to the user that these non-input like fields actually are editable. 😅
Screen.Recording.2022-09-24.at.18.03.53.mov
Ha! I did not get that at first, thanks for pointing it out. I wonder if it would work to keep it one field, but have it be smart enough to detect the different parts (e.g. you type a , coma and then it starts autocompleting on what can possibly come next). Grafana works a bit like that and it might be more intuitive (but I guess that's very subjective).
Edit: One benefit of that is that the Goggle-Editor is more like a code editor (hence you can type your rules in the same way as you would do in a normal code editor, but you get more contextual cues and help to ease the process).
Yea, this would be a really nice enhancement to make it feel more natural for developers. 👌
At the moment, the project is a little more intended to provide a solution for non-developers.
However, such functionality would be really sexy for the more advanced user, perhaps it makes sense to let users enable an advanced editing mode where you get those suggestions along with the code output for every rule.
Will keep this in mind. 🆙
Action bar labels
There are a few buttons but it's not immediately clear what they do, maybe would it make sense to have on each of them a short tooltip when hovering with the mouse to explain what they are about?
Good point, should become intuitive over time, but definitely not right from the start
Guess would add some labels on wider devices:
Coupled duplicates
When duplicating a Goggle instruction, we end up with two entangled rules (changing the action of one for example will also apply the same change to the other one).
Oh okay, I do know such behavior from earlier versions, but since I implemented unique IDs for each rule the reactivity system of Vue should theoretically treat them as separate rules.
At least that's the behavior I am able to produce:
duplicate.mov
If this somehow is still an issue, please let me know.
Multi-line pattern generates multiple instructions
On the below image, if we create a rule then use a newline, then it is seen as two rules (one being empty and resulting in $downrank=6,inurl); maybe would it make sense to ignore empty lines? Or prevent the edition of two instructions at the same time?
100%, same issue for rule site, metadata name and metadata description.
Will track this in #40
No generation of empty instructions
On the below image, when creating an empty instruction, then maybe we should not reflect it to the Goggle until the pattern or action is non-empty?
Generally yes. I guess the question here would be:
- is the editor a “plain” graphical way to generate goggles, no matter if the goggle code makes sense or not
- or is the editor a guided and linted solution for building goggles that actually make sense
A note here: By default when goggles are loaded from a goggle host, e.g. GitHub, during parsing by Goggledy some errors are raised to the user if their goggle code is invalid. Inclusive line and exact parsing issue. This can be simulated in this basic REPL.
From my understanding, instructions without pattern and site should still be valid instructions for the search engine?
For boost/downrank the use case might be pretty small, but for a single discard without any pattern and site as a general “reset” there is legit use.
Perhaps we could exclude empty rules (no pattern or site) from the code generation and add an extra/special UI element that provides something like a checkbox for the “discard all” rule/feature of a goggle?
Thanks a lot for addressing the feedback.
or is the editor a guided and linted solution for building goggles that actually make sense
I would lean towards this approach, since we could then enforce that instructions are at least structurally and syntactically valid. I least in the mode meant for non-programmers I think it would add value to put safe-guards against mistakes and try hard to only produce valid Goggles (or ones that make sense).
Perhaps we could exclude empty rules (no pattern or site) from the code generation and add an extra/special UI element that provides something like a checkbox for the “discard all” rule/feature of a goggle?
That makes a lot of sense to me. Since these "discard all", etc. are meant to be a little special, having a separate checkbox with explanation would probably be more intuitive than treating them as any other instruction.