Last month Apple released OS X 10.8 Mountain Lion, achieving record-breaking sales in the first few days. Included in the many new features is a new-and-improved Safari, bringing us up to version 6.0.
Over the last couple of years I’ve grown accustomed to buggy and unstable releases of my favorite1 browser; From pages going unresponsive for no apparent reason, to my entire browser spontaneously reloading, you could say I’ve grown somewhat of a thick skin to the sort of issues that would make most people raise an eyebrow or two.
Well, the latest salvo in Apple’s “war on Greg’s browser preferences” has arrived, and boy is it a doozy: The Web Inspector, a tool I practically live in during my day job, has been overhauled. And not in the “we added free beer and pizza!” kind of way. Not even close.
Who moved my cheese?
My initial reaction was one of cautious optimism. “Give it a couple weeks”, I thought, “and maybe I’ll get used to it.” I desperately wanted (and failed) to avoid falling into a cliche knee-jerk reaction to all things change.
Well, I gave it a couple weeks. And I’ve come to the conclusion that the Safari 6 Web Inspector is an unusable, unnavigable mess. I simply cannot use Safari 6 to do anything that amounts to real, hard web development.
In the next couple sections I’d like to cover just a few areas where I feel New Inspector falls short. For the purposes of this article I’ll be using the terms “New Inspector” and “Old Inspector”, which should be considered functionally equivalent to “Safari 6 Inspector” and “Safari 5 or Chrome Inspector”.
Exhibit A: Nerfed Network Tab
When it comes to dealing with Ajax, the networking tab is a vital asset. Lets see how the two inspectors stack up.
On the left panel we have a clean, easily scrollable list of all captured requests. On the right we have a details panel where I can view tons of data such as Request Headers, Responses, and Cookies.
Navigation is quick and easy. When a new request comes in I can simply click on it to get the data I want, right away.
This leads to a fantastic workflow where I can write up an ajax request in the console, watch it show up in the left panel, and view all the lovely details in the right panel.
Oh dear. In the middle area we have a terribly scrunched2 list of network requests that I can’t fathom reading.
The right panel is mysteriously left empty; Where are my Request Headers, Responses, and Cookies? Turns out those details are hidden away, safely ensconced in a nested panel that you can only get to by clicking the little gray right-arrow button next to the filename.
Clicking that button actually takes you away from the network panel, which introduces unnecessary navigational complexity. If you intend on quickly skimming the details for more than a handful of requests you’ll find yourself in a death spiral of details-back-details-back-details-back ad nauseum. Not fun.
console.log lines are noticeably missing. You’ll have to take a trip to the dedicated console tab if you want to see that information.
Exhibit B: Increased Navigational Tedium
Any tool that you use on a regular basis needs to be easy to navigate. Cruft that gets in the way, even in tiny doses, can add up over time. The overarching theme I’m picking up from New Inspector is that navigational tasks on average take twice as many clicks as they did in Old Inspector.
I’ve already outlined a few of those examples in the previous section, but here here is another big one: The “top” navigation.
Across the top we have a number of big, clearly labeled3 tabs. Clicking on a tab takes you right where you’d expect: “Elements” takes you to the DOM elements, “Resources” shows you the resources, “Network” takes you to the network requests, and so on.
A number of keyboard shortcuts are available to make navigation even quicker.
The top-left area contains a small navigational bar, which at first seems deceptively similar to Old Inspector’s big tabs. These tabs aren’t labeled, and the icons are only marginally helpful. As if taking pity on you, a label finally reveals itself after a moment or two of hovering with the mouse.
I said “deceptively” earlier because merely clicking these tabs won’t actually take you anywhere. What you’ll find is that the left panel is changing, while the middle and right panels remain in their current state.
So imagine you are viewing network requests and you want to switch over to the console log. This requires not one, but two clicks: Once to click on the “Log” tab, and once more to click on “Current Log”.
The same goes for all the other tabs. Want to view the DOM? Click the “Resources” tab, followed by clicking the top-level resource. Network requests? Click the “Instruments” tab and then click “Network Requests”. Are we tired of clicking yet?
New Inspector has its own set of keyboard shortcuts, but these don’t alleviate the issue either. Hitting Control-8 for example will take you to the “Log” tab but will not automatically select “Current Log” for you. Too bad.
Exhibit C: Weak-Sauce Color Scheme
This last one is more subjective; It is my opinion that the color scheme in New Inspector is a step backwards in terms of both usability and taste.
The key thing I’m looking for here is color variance. Good clear code highlighting can make a big difference when you’re digging around 20 layers deep in the DOM tree.
What I’m seeing in New Inspector color-wise is a move towards overall desaturation and lowering of the contrast from one color to another. This, to my eyes at least, leads to less visual clarity. If I have any hope of reading the code, I need to be able to tell the elements and attributes apart.
With the way the pink and red colors blend together in New Inspector, I’m lucky if I can see anything at all.
And So Much More
Sadly, I feel I’ve only touched the surface of the issues present in New Inspector. Missing features, confusing UI, the list goes on.
I’m reminded of when Final Cut X came out, and the overwhelmingly negative response it received. Back then, the logic I kept hearing repeated was that of a “One step forwards, two steps back” approach. Making progress often requires temporarily making things a bit worse. It’ll all pay off in the end, right?
Perhaps. I’m not so sure that is the case this time around, but we’ll see. Maybe a year from now, as OS X 10.9 is presumably out or just around the corner, we’ll all be reveling at the amazing developer tool innovations of Safari 7. Until then, I’ll be reluctantly sticking to Chrome for all my web development tasks.
I’m not going to delve into why I prefer Safari, because that would derail the true purpose of this article. For now, just assume I have my reasons.↩
Yes, I could “unscrunch” the network requests by hiding the right panel. But that panel is useful in of other contexts, and the last thing I want to be doing is toggling the show/hide on a panel all day long. ↩
I’ll admit that “Sources” and “Audits” may not be super obvious, at least until you learn what those terms mean in the context of the toolkit. ↩