The I-beam has apparently largely been unchanged since the beginning of time*. I need to change it because it clashes with custom [ and ] cursors I need for my app (an audio editor), making it difficult to tell which cursor is being shown. This answer on StackExchange indicates that it may historically have arisen out of slide ruler hairline indicators, but what are it’s UX characteristics in the modern world?
* with the notable exceptions of the additional horizontal center line introduced in OSX Mountain Lion, and some rounded corners in HiDPI versions.
General function
The I-beam functions essentially similar to the precision (crosshair) cursor in that it lets you select something while obscuring as little of the content you’re about to select as possible. The difference being that it expects you to primarily care about horizontal content which has less important areas above and below (ie text), and also assuming a minimum height for the selection you’re making. Using a crosshair on text would be incredibly awkward:
It’s ideal if the cursor size and the expected selected line size match – or in other words, if you’re expecting 12pt text, having the cursor cover the 12pt line height makes sense. It’s not super important that these match exactly exactly as it’s still a free-moving I-beam cursor, not the caret. In fact, you wouldn’t want to scale the I-beam beyond normal cursor size, as it still is a cursor.
Interaction with small objects and italics
To make I-beams work better with smaller selections that are much smaller than the cursor itself, and especially selection of slanted text, adding midpoint indicator helps you actually know where the “action pixel” is.
The midpoint indicator does slightly impede readability of the text you’re selecting – but not nearly as much as the frustration it’d cause if you’re making the wrong selection. Thus, if you’re expecting to work with small sizes (8pt), adding it may be worthwhile.
Detecting whether you’re hovering over slanted/italicised text and changing the cursor to a slant as well is something I’ve seen in the past, but compared to the normal I-beam it strongly struggles to maintain shape and not become too blurry or jagged with aliasing.
Using a midpoint indicator seems like it solves both problems.
Contrast and dark mode
Traditionally, I-beams had a 1px stroke and displayed as the negative of whatever they’re in front of. With the advent of higher pixel densities, 1px is too thin, and the targets an Ibeam needs to hit have grown larger accordingly. Currently, a 2px wide cursor with a 1px white outline (so 4px in total) seems like a good way of doing things.
Use in non-text contexts
In case of non-text, things change slightly. Timeline-based tools (audio/video editors) tend to have generously spaced tracks which may be several times the height of the cursor. Here, the added precision granted by the midpoint indicator is not needed and can safely be omitted.
The top and bottom horizontal beam of the I-beam also slightly lose their importance – in text use, they can’t protrude upwards or downwards too much, else they may poke into adjacent text and obscure it unnecessarily, but in a timeline, that’s not an issue. I found that angling them outwards wards made them feel more open while still being clearly recognizable as an I-beam.
Leo Wattenberg 