Skip Navigation

OmniWeb: the gripes

I’ve already discussed the new features of OW5, and mentioned in the opening that this beta leaves me feeling somewhere between elated and exasperated. Considering that I spent the rest of the entry praising its new features, you’d be right to wonder what left me feeling disappointed… and here it is.

Standard State

Application windows in Mac OS X have two states —Standard state and User state— that describe the size and position of the window. You toggle between these states with the ‘zoom’ button in the title bar (AKA the green ‘+’ button). An app’s Standard state is hard–coded; the user cannot change it, which is why we have a User state in the first place. For most users, 99% of the time, application windows will operate in the User state. For most users, in most applications, Standard state is only sometimes invoked as a ‘maximize’ command. Yeah— the Standard state for a lot of apps is having the window filling the entire screen; in other cases it’s having the window expand to accommodate its contents. I prefer the latter.

Not so in OmniWeb. New browser windows are spawned in Standard state; and their Standard state is a largish, squarish affair. To put it plainly: this sucks. I, like most other people, in most other browsers, have my window set to a size I’m comfortable with. Maybe that window size is reflective of the screen resolution I’m working at, maybe it’s reflective of the width of one of my most frequently–visited sites so I don’t have to side–scroll; it differs for all of us. But OmniWeb doesn’t remember your browser window’s preferred size, it just gives you the Standard.

Perhaps this is a push for you to use workspaces more often, since workspaced windows remember their size and position; or perhaps it’s a bug that will be merrily squished before shipping. Time will tell.

Update

Time did tell; and John G tells me that OmniWeb’s ‘Window’ menu contains a ‘Save Window Size’ item that lets you manually determine the window size of OmniWeb’s Standard state. This is a bigger deal than it looks, since it means OW5 will remember my preferred window size even after I’ve visited one of those arty–farty “I could care less about usability” websites.

A person migrating from any other web browser, one that handle things the other way, won’t find this option immediately; but that’s hardly Omni’s fault. Is it? This makes me happy — that was a potential deal–breaker for me.

Other Window menu niceties include proper support for ‘Close All Windows’ and ‘Minimize All Windows’ shortcuts. Sweet.

Text Encoding

OmniWeb’s “assumed” text encoding (its fallback encoding, should the page not specify one) is Windows Latin 1 by default, which isn’t altogether a bad thing, but it also claims to ‘Use encoding provided by server’ as its default in cases where one is specified.

Not true.

I’ll tell you right now that every page served at decaffeinated.org is served with a charset header that says UTF-8, but OmniWeb 5 doesn’t respect that header. One might assume that it’s looking for clues inside the document instead of in the headers, and it’s turning up bubkes. Hey, that’s not how things work in XHTML. Look in the freakin’ headers and stop assuming I’m using Windows Latin 1.

Stiffness

I’m really not sure whether this is another squish–it–before–shipping bug or whether they actually want it this way, but the user interface is a little… stiff. Rigid. It lacks fluidity.

Not sure what I mean? Pull up an OmniWeb window and any other window in Mac OS X that features a toolbar. Click the toolbar–disclosure button on one, then the other. One app slides the toolbar in and out; collapsing and expanding. The other (no prizes for guessing which) clicks it on and off. It's as though it’s a switch for visibility, instead of state. The tabs drawer has no such problems with animating its appearance and disappearance, no siree. Consistency, I like it.

The same complaint extends to the appearance of the Site Preferences pane (the pane appears; as if from nowhere) and to the lack of smooth scrolling. Yes, this stuff is just polish… but when smooth scrolling is an operating system function, one that applies to almost any scrollable area in any application, you have to wonder why it doesn’t work here.

Preference Madness

Being as feature packed as it is, one would expect OmniWeb to have a whole swag o’ preferences; and it does. What I fail to understand is this: when every other drawer–toting application in the Mac world just opens the drawer on whatever side of the window isn’t obstructed by the screen edge (and defaulting to a developer–defined side when it has ample room on both sides), why must OmniWeb ask the user what side they want the drawer to open on?

Not only that, why does it enforce this preference so brutally? This isn’t a life– or data–threatening problem, I will not cry if the tab drawer opens on the left side of the window because the window is hugging the screen’s right edge, why must you scoot the window away from the edge, then open the drawer, then scoot it back when I close the drawer? My decision to have the drawer on the right was completely arbitrary, I just don’t care.

Input

Like Safari and many other browsers, OmniWeb works around the ‘uh–oh, the toolbar is collapsed but they just hit command–L, meaning they want to type in a URI, what do I do?’ situation by quickly expanding the toolbar, allowing input, then collapsing again when the user commits the input by hitting Enter. This isn’t a terrible way to do things, certainly, but there are other factors to consider; which is why I still consider Camino’s sheets to be the superior method for handling this.

First of all —bug reporting for bug reporting’s sake— the expand/collapse toolbar method doesn’t work for OW5 when you hit command–shift–F to get to the Google Search field. When the toolbar is open this works as advertised (which is one more shortcut than Safari has, to OmniWeb’s credit), but when it’s closed OmniWeb plum forgets it even has such a search field. Guess it’s back to the keywords then, huh?

Second of all, though it’s acceptable to expand my collapsed toolbar so I can type in an URL, remember that I wanted that toolbar shut; no matter what I do next. It’s all well and good to collapse it once I hit Enter, but what if I don’t hit Enter? What if I only hit command–L because I wanted to copy and paste the URI of the page I’m viewing into ecto? What now? Why in the hell would I hit Enter now? That would only serve to refresh the page I’m trying to read, thankyouverymuch. The most reasonable course of action for me, as I see it, is to hit Escape to dismiss the now–unwanted toolbar; but hitting Escape will get me nowhere. In fact, the only way I can dismiss the toolbar without hitting Enter is to hit command–option–N. A cumbersome shortcut in an otherwise–simple situation. Similarly, in Safari, I need to hit command–shift–\ to dismiss the navigation bar. Not cool.

This is why I advocate Camino’s sheet input — users know how to use sheets, and sheets work in predictable, predefined ways. You might assume that the percentage of people who surf with their toolbars collapsed is insignificant, and you might assume that most browsers’ handling of it is a weak attempt at contingency design; and you’d probably be right. But damnit, I’m one of those people, and your contingency plan sucks!