Spotlight: How can you have two blinking cursors at the same time?

Posted by Pierre Igot in: Macintosh
March 9th, 2007 • 6:45 pm

Here is a very simple question for Apple’s engineers, and more specifically for those who designed the user interface for Mac OS X’s Spotlight search feature:

Spotlight - Two I-Beam Cursors

How on earth is it possible to have, in a single user interface, two I-beam cursors (insertion points) blinking at the same time? (You cannot see them blinking in the screen shot above, but I snapped the shot when they were “on.” They were both coming on and off almost simultaneously.)

The very fact that they are blinking is supposed to indicate that they are active, i.e. that the focus is on them and that the computer is waiting for text input from the user.

How can the focus be on two different text fields at the same time?

It clearly is not, and the fact of the matter is that, when the Spotlight text field is on, it takes precedence over whichever interface item is currently active in the front-most application window.

But then why is the I-beam cursor in the front-most application (iTunes in the case of the screen shot above) still blinking? If the focus is on Spotlight, then the I-beam cursor in the iTunes search field should stop blinking. It’s a simple as that. And in my humble opinion the rest of the UI controls in the front-most application window should also change their visual aspect to indicate that the focus is no longer on them.

At present, they don’t change their visual aspect. This blinking I-beam cursor is just the tip of the iceberg. The Close, Minimize, and Maximize window buttons keep their red, yellow, and gree colours, the “Search” field keeps the blue halo that it had before Spotlight was invoked, etc. In other words, when the global Spotlight text input field is invoked, the visual appearance of the front-most window of the current application does not change one iota. And the I-beam cursor in the text field continues to blink…

This can be misleading for the user, who, based on the window’s visual aspect, might assume that the window is still in the fore and that he can still interact with it. This actually happens to me quite frequently, because I have a very large, 30″ screen, and the Spotlight text input… thing only takes up a little bit of room far on the right, in the top corner. Sometimes my attention is elsewhere, on the left-hand side of the screen, and I accidentally press the command-Space shortcut that invokes Spotlight without noticing it, and then I continue typing and nothing happens and I wonder why…

I suppose this is less likely to happen for people with smaller screens. They are less likely not to see that Spotlight has been invoked, and that the Spotlight text input thing is where the focus is now.

But the only indication that the focus is there is the very presence of this blue thing. There’s no other visual indication of it anywhere else on the screen. And it breaks one fundamental rule of UI design, which is that you can only have one thing in the foreground at any given time.

I realize that there are already other aspects of the Mac OS X interface that stretch this rule… namely the inspector-like windows in applications such Pages and Keynote, or the Character Palette. These things are never in the “background.” They always stay in front of regular document windows and, in the case of the system-wide Character Palette, they stay in front of all applications.

But the controls within these palettes do not keep their focus when they are not in use. The palettes might contain text fields where you can type stuff (the “Before Paragraph” and “After Paragraph” fields in the “Text” tab of the “Text” section of the Pages inspector palette, for example), but the blue halo around the field and the I-beam cursor in the field disappear as soon as you switch to something else (back to your document window, for example). So while the palette itself always stays in the foreground, the focus does not stay on individual controls in that palette when the user does not interact with those controls.

In the case of the Spotlight text input, however, the visual focus does stay on whatever is in the foreground when Spotlight is invoked. And that’s just plain wrong. It’s the kind of ugly UI you might expect in Windows, but, you know, the Mac is supposed to be better, more elegant, more consistent, more intuitive.

I am sorry, but there is just no way that having the visual focus on two different UI controls at the same time is intuitive.

And it’s part of a more general problem with the global Spotlight UI, which is this system-wide thing that refuses to be part of the regular Mac OS X environment. When you bring up the window with the results of a global Spotlight search, for example, that window comes to the foreground, but the application listed in the application menu on the left-hand side next to the Apple menu remains the last application used, as if the Spotlight results window belonged to that application.

When the Spotlight results window stays open, but becomes hidden by other windows, the only way to bring it back to the foreground is to invoke Spotlight again, as if you wanted to start a new search. This, again, is utterly inelegant and non-intuitive, and the reason for it is, again, that Spotlight breaks all kinds of UI rules just through its very existence.

Do you think that Apple’s engineers will come to their senses and realize how ugly and inelegant and non-Mac-like all this is, and fix it in Mac OS X 10.5? I highly doubt it. I submitted all kinds of feedback about this during the testing phase for Mac OS X 10.4, and nothing ever came of it. As far as I can tell, by the time Apple asks AppleSeed users for feedback, all the major UI decisions have already been made, and there is no room left for discussion. All that we are good for is finding bugs, and maybe a small amount of UI fine-tuning here and there. But we lowly users and AppleSeed testers are not allowed to question any of the major UI decisions made by Apple. So whoever makes such decisions bears the full responsibility for them.

And I’d argue that Apple’s Spotlight UI designers are simply irresponsible.

9 Responses to “Spotlight: How can you have two blinking cursors at the same time?”

  1. Chris Grande says:

    It seems to be a bug in iTunes (maybe carbon), because everything else I have tried has released the focus. From what I’ve seen of 10.5 Spotlight seems to be its own app now.

  2. Pierre Igot says:

    Here’s another example: Try the search field in any Open File dialog box in a Carbon application (MS Word, Photoshop, etc.). iTunes is not the only case. But you’re right that it’s not a universal (so to speak) problem. It probably has something to do with Carbon vs. Cocoa.

    Not that it matters. The very fact that this kind of problem is allowed to exist is a major issue. And even without the focus on the text field, the fact that many other controls remain in the foreground is still confusing.

  3. Jezza says:

    It happens in Firefox as well. If you click into the search field and then click into the spotlight search field you get two blinking cursors. Tiger is becoming more and more beta like by the upgrade. Hopefully Apple will restore some sanity in Leopard and perhaps get some concistantcy back in the UI. Although I’m not sure that identical windows for different applications are a good idea.

    This particular annoyance though seems to come from Apples own confusion, Spotlight is behaving correctly, in a ‘layer’ above the OS, it’s even part of the Finder, in a similar way that dashboard works in a layer ‘below’ the OS. Above and Below in this context is purely descriptive

  4. Arden says:

    Spotlight works correctly on a fundamentally low level in the operating system, but it’s broken in many ways much higher at the user level. And what isn’t generally broken simply isn’t done very well. I would say to change the shortcut for the blue Spotlight search field to something harder to press accidentally (Cmd-Cntrl-Space, perhaps) and then just use the big window for search, but you really can’t fix the UI (that’s Uneven Inconsistencies) between Spotlight and Carbon.

    BTW… “gree colours?” Everyone knows there’s no “u” in “color.” ;)

  5. Pierre Igot says:

    Sorry Arden, I am Canadian and this blog is Canadian English :).

    I agree that the core foundation of Spotlight is good—although it does not support Match Case or Exact String (for multiple-word phrases) searching, which is a major limitation. But the UI most definitely sucks in numerous ways. It’s highly disappointing.

  6. Pierre Igot says:

    I should also note the problem is more widespread with Carbon applications. For example, you can have the I-beam cursor blinking in a Word 2004 document and in Spotlight at the same time.

  7. Arden says:

    I should also note the problem is more widespread with Carbon applications. For example, you can have the I-beam cursor blinking in a Word 2004 document and in Spotlight at the same time.

    Many things are worse and more widespread in Carbon, and many default behaviors are also different. For example, I find it EXTREMELY annoying how Carbon applications tend to capture my scroll wheel actions and apply it to the primary window, even when I’m not hovering over it (as you probably know, Cocoa (and actually, most Windows) applications tend to favor hover-scroll interaction). This is compounded by the fact that one of my girlfriend’s late pet rats chewed part of my scroll wheel, so there are times when I want to scroll it simply to “fix” its position under my finger, but my document moves up and down as a result. I see this most often in Word and Photoshop, the two non-Apple Carbon applications I use most frequently (though not necessarily in that order).

  8. Pierre Igot says:

    Arden: I don’t think the scroll wheel behaviour is necessarily a Carbon vs. Cocoa issue. For example, Microsoft Excel is most definitely a Carbon application, and the sheet in the foreground window doesn’t scroll when you move the wheel unless you are hovering over it. So it looks like it’s more like too many Carbon developers are too lazy to implement the correct behaviour in their applications, but it can definitely be done properly in Carbons applications as well. (And obviously the Excel developers are a bit better than the Word developers in that respect!)

    I agree that there are a number of outstanding inconsistencies in Mac OS X that are most definitely related to the Carbon vs. Cocoa paradigm. But in many cases it’s mostly because the Carbon developers haven’t bothered to fix their applications. It’s not because of a technical limitation in Carbon.

    This particular issue with Spotlight, on the other hand, might be a more challenging technical issue. At least that’s what you have to assume to explain why Apple’s own engineers have allowed this glaring problem to remain unaddressed.

  9. Pierre Igot says:

    BTW, a rat nibbling on a mouse’s scroll wheel… Pretty funny! Make sure your girlfriend doesn’t start raising pet worms, because you might end up with a worm in your Apple! :-)

Leave a Reply

Comments are closed.