underscore in mouseover is misleading

[shriram]

Emu points out when you mouse over an error, it underlines the text at the same time as it highlights source. The underline is confusing because it makes something look clickable, when it's not really (because nothing new has become clickable than from the mouse-over).

[blerner]

@shriram Do you have an alternate styling you'd prefer? Otherwise, close...?

[schanzer]

Why not just make clicking have an actual behavior, like scrolling to the offending line? It's totally natural to want to click the underlined thing (I keep doing it by mistake), and it would make it really clear that this error is for this line of code.

I have to say, the current error reporting graphics seem sadistically confusing. Mousing over an error will either highlight the error in the source or display a complex graphical tease that says "the error is somewhere...but you can't see it!". Then there are buttons on the tease, but mousing over to them has to be done quickly or they disappear ("too slow! try again!"). Bizarrely, sometimes these arrows appear in both directions!

Oh wait, are those seriously not buttons? I only just did some testing, and it appears that they're not. Well that's even more confusing - are they merely hinting that I should scroll up or down? If so, how do I know how far to scroll? If not, what are they for? And if this whole behavior is subsumed by clicking on the line number, why do we have it at all?

In fact, it looks like clicking anywhere in the error message will auto-scroll. So why are only the line numbers displayed as links? Do they have a special property that is different from the whole click-target?

Proposal:

• Error messages have one clearly-defined click target (the source location will do)
• Mousing over an error highlights the error, whether or not it's visible
• Clicking an error scrolls to the location and causes the offending location to blink once (a much better visual cue, esp since Pyret has so many one-character lexing errors)

[blerner]

I disagree with a bunch of this (it's not sadistic at all!), and I think there's some background that might help explain the design we currently have. First of all, many errors do not have one clearly defined click target because they don't have the source location -- so "the source location" will not do. (Think about errors that say, e.g., "this expression was wrong because of that annotation" -- both locations are very relevant.) Second, we found it extremely disconcerting to mouse over an error message that referred to an error location that was scrolled off-screen, and not get any visual indication of the error. Third, when we tried auto-scrolling on mouse-over rather than mouse-click, we got motion-sick.

As a result, we introduced these red gradients and arrows, borrowed from video game displays basically, to indicate that your program "took a damaging hit" from somewhere out of view. Mousing over an error does currently highlight the error, but you can't see it because it's offscreen, and because scrolling to that location automatically is really, really annoying (suppose you have several errors and your mouse moves across all of them while you're trying to get to one of them in particular...) The buttons were a compromise between no indicator and nauseating behavior.

In the error message, the line numbers are displayed as links because when there are multiple error locations, it makes sense to have only the line numbers be clickable. In those error messages where there's just a single error location, it appears to be the case that clicking anywhere scrolls you to the error. I'm not sure why that is, actually; I don't recall our reasoning for that.

(In your particular error message, I honestly don't know how you managed to trigger both indicators; that's a bug that I can sporadically reproduce, but not long enough to diagnose.)

So of the proposal you have: I think error messages shouldn't be clickable everywhere, but only on the location(s), which ought to still be styled as links. Mousing over the error message does highlight the error, so that's easy. I don't much like blinking, because that's again a blink-and-you'll-miss-it think; instead, while you hover over the reported error location the source of that location is highlighted.

[schanzer]

The multiple-error-location stuff explains the design a lot better. Thanks.

I really dislike the red gradients, however. The arrows look like buttons, and it's frustrating when they disappear before you can click them. It's also not a good use of what we know about the user: they're looking at an error in the interactions window, so we show them a hint in the definitions window? If the code is offscreen, why not have the link itself say "scroll to the error" or "show me"? It's self explanatory, and in the place we know the user is already looking.

Yeah, the whole error should not be clickable. Things that look like buttons/links should be. If there's one location, show one link. If there's multiple locations, show multiple links. All of them can say "show me", or perhaps have a little icon to communicate what clicking will too.

I don't think I understand your objection to blinking. If it's highlighted already, why would blinking make it less noticeable? Our peripheral vision is more sensitive to movement than anything else, so blinking would draw the eye towards the error, which is already highlighted.

[blerner]

Your proposal said to blink the offending code once; if the user happens not to see that blink (because they were reading the error message text), they'd miss the visual cue. By contrast, the sustained highlight lasts as long as the mouse is over the text, so it seems like a better design. I don't mind a hybrid approach, of blinking the text a couple of times to draw attention to it, then leave it highlighted if the user doesn't want to react to it immediately.

I'm also happy redesigning the red damage indicators to not look like buttons too much (I picked the arrow-in-a-circle design so that it was legibly an arrow against any background text, and since at the time there was no common UI that used round thingies as buttons...). But Shriram had had specific feedback that if the offending code was off-screen when the user moused over the error message and nothing got highlighted at all in the code window, it looked like a disembodied error message, "whadaya mean, there's a problem; I don't see anything!". So there's definitely a tension there between wanting some indication that the problem is currently off-screen, and not distracting the user too much.

[schanzer]

I think you misunderstand - I'm not suggesting you replace the highlight with a blink. That cue remains, no matter what. I'm proposing that we maintain sustained highlighting during mouseover, but blink-on-click. No objections to blinking multiple times. This gives us better visual cues, and a proper separation of behaviors between mouseover and mousedown.

I think it's a common UI metaphor to say that clicking has more impact than hovering. People don't expect the code to move when they mouse over an error, but I think they'll understand if clicking is involved. Honestly, the error should be responsible for telling the user it's out of view. That's where their attention is, and I think it's a lot to ask them to scan all over the window for extra context that's not in the message itself. @shriram , would you be opposed to having the message include something like "show me" for errors that are offscreen?

[shriram]

@schanzer Do you think this is still a problem?

[schanzer]

The new error system does the right thing in terms of highlight/hover, IMHO. However, it doesn't auto-scroll to the relevant error on click. @jswrenn , can we scroll the definitions window to the relevant line?

[jpolitz]

The error highlight clicks scroll on click now.