Spotlight on Spotlight, Part 01 of ∞

Somehow, it technically got to be Friday a little bit ago, which means it's Apple Bug Friday again. My brain is trying to reject this, because yesterday seemed like Monday night, but here we are and there they are. Once again, we'll be revisiting our old friend: The Mac OS X Finder.

stupid finder

More specifically, how it integrates Spotlight. It's rare that someone is able to introduce a technology meant to be better than what came before, but due to f'ing up the implementation it ends up being worse in just about every way. It happens, but generally not if the right people are paying attention and there's a competent testing and feedback loop involved, yet here we are with Spotlight.

The ∞ symbol is in the title because aside from some of the core tech and exposing it to developers (Well, developers already had SearchKit), there's just so little they've gotten right, and today we'll note a few of those...

What's in a Bug

This is going to be cursory, and I'm not going to hit you over the head with explaining things like unit testing, however software development has been around for awhile now and over time people have picked up on some basic ways of doing things. If you work on enough software projects, especially larger ones at different companies, you'll find that most companies have very similar ways of categorizing and prioritizing how they deal with bugs.

The names might differ, the criteria might differ, and whether they stick to the criteria might differ, but the categories themselves generally have corollaries.

I.E., most projects make a general distinction being a bug being marked as critical and a bug being marked as everything else. When it comes to critical bugs, many companies simply won't let the software out the door until they're resolved. "Critical" usually means it's a show stopper, and needs to get fixed ASAP before the product goes out the door or a project has been said to reach a new milestone.

For example, let's hypothetically say you're developing a game, and find out that it crashes when you reach a certain level, or plugin headphones. In most circles, this would be considered a critical bug, that needs to get fixed before it goes out the door. Of course people have to make ship dates, and are faced with having to not ship while you hunt down what's causing a critical bug, or making up a rationalization to leave it marked as unresolved or a different level of priority...

While you see this happen, most companies that care about their reputation just wouldn't do it. However, if it crashes at that level only when you have the game set to an italian localization and have a particular brand of headphones plugged in, the probability is higher that the person in charge will decide to ship it and patch it later.

You'll have some severely pissed of users, but it will just be some users, and it won't hold up the shipping of the project. Every company handles these types of situations differently, depending on their standards for what's considered acceptable.

Swinging in User Interface

Over time, it's become accepted that usability is important, to the point where its considered a feature, and as a feature of the app it means that user interface issues can be classified as bugs. Just about every large software project that takes HCI seriously treats them this way, because it's unavoidable -- you have to keep track of it somehow if you are doing any real usability testing, otherwise how would you know whether or not a change has sparked a regression or improvement?

Because it's not accepted that usability issues can be classified as bugs, and are thought of as bugs, they're similarly categorized.

A regression occurs when changes made to the code cause it to revert to a previous state or become worse than it was before. I.E., if you optimized your app until it was benchmarking at 1000, but changes or additional features make it now benchmark at 800, you'd have a performance regression. Something you've done has caused something to break, or be worse than it previously was.

Similarly, most UI bugs have to be classified into:

  • Actual bugs in behavior

  • Feature requests, where something does something the way its supposed to, but someone wishes it would do something else

If you can't tell, it's just like a regular bug, where there's a big difference between someone saying "It wish it did x." and "It's supposed to do x, but isn't doing it well or is borking while trying to do it." Every company is going to handle how the two are classified differently. Most often, whether they're even taking seriously or marked "Works as intended" is going to depend on who is in charge and whether they believe in the science or their own taste and how much they really care about design in general.

A regression

An easy joke here would be to post a screenshot of the 10.x Finder and move on, but we'll be serious here. In 10.x, Apple added a little search bar.

In 10.3, this was upgraded to the top-right of every Finder window that hasn't turned off metal or the sidebars, and showed up "live". Type what you wanted to search for, and the results would show up in the Finder window.

In 10.4, it's in exactly the same place and does exactly the same thing, except it's missing the little triangle denoting a drop-down list. That drop-down list let you tell the Finder where you wanted to search before you actually put it to work searching. You could tell it to search everywhere, or just disks attached to your system, or just the folder you happened to be in.

You can still do this in 10.4, but the key is that you have to first search in the box in order to have access to those refinements, after-which you can then refine the search by clicking buttons at the top. I.E.:

Now, the Finder remembers what you last searched by, which means if you are in a folder of your old writings and want to search that directory and down for the term fubar, yet the last time you searched servers for something else, the Finder is going to start off searching all connected servers for files that have fubar in their names or contents. You then have to click to tell it pull its head out of its ass and stop searching the servers and only search the folder you're currently in.

It's just stupid, does no one any good, and I consider it to be a regression.

A WTF.

Of course, right about now a bunch of you are saying "Well, that's true, but if you want that control over your search you can just use the "Find" command under the "File" menu, or just hit Apple + F." They'd have a point in a sense, which brings us to our next treat.

In a 10.4, if you search via the little box at the top of the window, you're presented with a screen that looks like this...

Also in 10.4, using the Finder's Find command no longer brings up a separate search box, rather you're dumped directly into a Finder window whose interface is just as it would be if you'd searched above, except you can add more requirements before you actually tell it to search...

As noted in the comments, if you have the "Back/Forward buttons enabled in your toolbar, you can use them to get out of the search.

Good catch, yet I still consider this to be a bugger and not well thought through.

If you'll notice, the little "X" in the search field is now gone, which was the only way to get the Finder window back to being a Finder window. This means the user is "trapped" in the UI, and now either has to start a search in the field in order to have that X show up, or has to select something from the sidebar which removes them from where they were previously, and they get to backtrack.

Alternately, they can just close the entire Finder window.

Approaching #!?@$!%*!

Now, something that may surprise you if you were in the Finder window above is that the search criteria you'd see aren't all that's available. You'd be forgiven for not knowing this, as if your Finder window was larger you'd see...

You aren't aware of this, because the UI is designed to only be usable at a certain minimum size, so the content overflows the box and you can't see the stuff on the right. This happens all the time in computers, and it's why these little things called scroll bars were invented.

This is bad. We're talking Ed Wood Plan 9 bad, where it rounds the horn and is on some other plane of bad. One is almost in awe. Almost.

yummy alcohol posted button Posted by drunkenbatman
    September 09, 2005, at 03:30 AM


Comments (32)




Post a comment



Anonymous comments are allowed, but please enter something for a name.

And do endeavor to appear sane.









Remember personal info?