Better understand cause & effect with: ☑︎Scroll Sync + visualizers: ☑︎Added ☑︎Removed ☑︎Omissions

[porg]

Feature Proposal

https://github.com/firasdib/Regex101/assets/737143/581cc65b-78a6-43b2-906f-4c94d9a70f30

[firasdib]

The problem with this is that there is no guarantee that both of them will have the same data, which makes the "sync" not very useful. I could add a toggle for it, but I'm not sure if its worth the work and how many would actually benefit from the feature.

[porg]

Hi @firasdib I had addressed these concerns in my initial post, but seemingly only the image made it through. Again the text too:

PROPOSAL: When jumping between versions and they have the same amount of lines, restore the same scroll position.

• This is highly likely b/c often you leave the same input and vary the RegEx over the versions.

• Even if the total line amount differs between version, the app should try to restore the line/scroll position.

  • As long as the just opened version has not fewer lines than the line scrolled to in the just closed version, this estimation will often be perfect if the changes occur in lines after the scroll position,

  • or at least a good approximation if only shifted by a few lines.

• Almost any attempt is better than being stubbornly forced to line 1 and needing to re-orient yourself.

  • Of this should be optional. But for the majority of use cases it's a win.

  • Jumping to line 1 is a strong feedback for "your action was processed".

  • Omitting that jump, is one signal less, but poses no UX issue, as long as there is a clear "refresh" indication.

  • The progress indicator on the top right X matches (Y steps, Z ms) near the version-switcher dropdown menu, is already a medium strong feedback, as it is next to the element which causes the refresh.

  • If usability tests turn out this is too subtle, the main content area could get an overlay during refresh, as an extra system feedback.

  • ☑︎ Wrap lines softly — Would be an extra option which would be useful for visual stability between input and substitution, if your RegEx operates line wise and lengthens/shortens the lines, but otherwise leaves the amount of lines the same (which very often is the case).

You can easily base your design decision on the huge data set you have

1. Is the substitution the same amount as the input in RegEx v1?
2. If so, is that also the case over the versions?
3. If they change, it that gradually from version to version? Or only one data-set change, and then again a stable amount for multiple versions, before changing again.

And many more aspects which I only have as assumptions, but which can easily be verified/falsified with existing data sets.

One more idea I had

• With sync in place another optional layout would become a further possibility: The text areas of input-text and substitution-text side-by-side, not on top of each other.
• In combination with "☐ Wrap lines softly" extremely powerful for line-wise visual comparison, and focusing on the (start / mid / end) of a line (if scrolling on the Y-Axis keeps the X-axis stable not performing any automatic "reset to the left").
• If you have narrow text areas widths --naturally on smaller viewports or resized manually on larger screens -- your eyes need to travel only very shortly on the Y-axis between input and substitution, extremely efficient evaluation of one's RegEx.

Collaboration

I'm willing to serve as a beta tester for an experimental version, and give you feedback with my experience of 10+ years as UX designer and 20+ years as software tester.