1536300 - Flashing text cursor makes it look like you can edit code in the debugger

Status: NEW

(DevTools :: Debugger, defect, P5)

Description

[Eric Shepherd [:sheppy]]

When using the debugger, clicking the source code view results in a flashing text cursor, which makes it look like you can edit the code. This is tremendously exciting until you actually try to do so and nothing happens. There should not be a text input caret in the debugger until/unless editing is possible.

Comment 1

[David Walsh :davidwalsh]

Good shout Sheppy. I've felt this way too, but since users can focus into the source doc and highlight/copy, there does need to be some type of caret. I've thought about keeping the caret but not making it blink, but then it just looks like a pillar in the document. Not sure what the right solution is.

Comment 2

[David Walsh :davidwalsh]

This will require a lot of thought. We could make the cursor not blink but then how can the user easily spot it?

Comment 3

[luc4leone]

(In reply to David Walsh :davidwalsh from comment #2)

This will require a lot of thought. We could make the cursor not blink but then how can the user easily spot it?

I think this is a very interesting topic, and following :davidwalsh advice I did "a lot of thought" and research on it. Let me share it with you. I look forward to reading your opinion.

A flashing (aka "blinking") text cursor is a signifier for editable text. Even if I guess we can all intuitively agree on the previous statement (in agreement with :sheppy and :davidwalsh) I tried to find a "proof" of it in authorative UI books or papers.

The blinking text cursor was invented by Charles Kiesling in 1967. The "blinking" (for CRT display) was the idea "to provide some means for accentuating the cursor position" [1]. In the Patent it's never directly asserted that a blinking text cursor signifies "you can edit this text". But from many sentences:

• "If the operator is entering the alphanumeric characters by means of the keyboard, he must have some means for determining where the next character is to be entered on the CRT screen"
• "... where the beam is located in order that the editing may be accomplished"
• "To implement the editing requirements and to enable the operator to determine where the next..."

we can safely infer that the blinking text cursor function has been to locate the position on the screen to insert the next character.

In IBM Object-Oriented interface design book [2] it's stated explicitly that "The text cursor is used to type text".

The operations described by David of text selection and copying can be achieved with the help of the mouse cursor. As of now the mouse cursor changes its appearance in the debugger editor when hovering on text, from the default arrow to the I-beam, hinting [3] that "the text beneath the cursor can be highlighted, and sometimes inserted or changed" [4].

Without a text cursor in the text we have to give up the keyboard as an interface to move around, but it can still be used to copy the text.

As a last step I checked what Chrome is doing. They have the blinking text cursor and consistently with its function they allow to edit the code. They do not allow to save edits to the file system unless the file is added to workspace (but the file can be saved in the file system with another name, "save as" functionality).

To sum up

1. Using the blinking text cursor without allowing for code edits can be confusing for the user
2. By not providing the blinking text cursor we eliminate the confusion, but the user will not be able to use the keyboard to move around and select text
3. Without a text cursor the user will be able to select and copy text by using the mouse cursor to point and click (or drag) to select text (and the keyboard or the context menu (mouse right click) to copy the selection)

References

[1] Patent 3,531,796 (1971) - Background of the invention
[2] Object-Oriented Interface Design - IBM Common User Access Guidelines (1992), page 41 and page 25
[3] https://en.wikipedia.org/wiki/Cursor_(user_interface)
[4] About Face - The essentials of interaction design - Cooper, Reimann, Cronin page 321 and page 475