Effortless UI, II
This is a followup to my original post on creating an effortless user interface for the user.
In some of my earlier posts, “NStatic Status and Direct UI”, I mentioned the use of arrows and other markup to depict the flow of execution up to the current error or breakpoint. Right now, I am currently tweaking the highlighting and would appreciate any opinions.
Arrows are drawn from each statement or condition to the next statement or condition. A solid arrow indicates that code underneath the solid arrow may be executed. The words “may be” is key as we may have an if or other statement whose condition may be either true or false but which does not provide any relevant information for understanding an error. In this case, a solid arrow just skips over the body of the if statement to the next statement in the enclosing block (as depicted below), indicating that some code in that if statement is executed.
A dashed arrow indicates that code between the start point and the end point of the arrow is ignored. (I’ll probably choose a lighter color for the dashed arrows; my original choice, alpha-blended yellow, was not a good one.) Normally, the ignored code sequence will also be dimmed, allowing the user to focus on the more important statements in the function. The examples above illustrate dimming inside conditional statements and expressions, but switch statements and other control statements (break, continue, return, throw, goto) can also introduce dimming.
Besides arrows, conditional expressions may also have additional highlighting indicating its truth value, but there is a small complication. A conditional expression may be always true/false, or it may have an assumed value, which is necessary to trigger the current error or breakpoint. Both types are shown in the first image above. “Always” values contained an additional checkmark or cross to indicate truth or falsity.
I am not satisfied with the current visuals and will probably use underlines to distinguish one of the types from the other.