Fixing Maximize Bookmarklets in Safari 4

By Cody in OS X, Software Development

When Apple released the Safari 4 public beta at the end of February, I discovered an annoying bug: the little Javascript bookmarklet that I use to maximize the browser window didn’t work anymore. I find the behavior of Safari’s green zoom button extremely annoying. It doesn’t expand the browser window to fill the screen, but instead only resizes it to fit the content of the current page. This is typically some weird height and width that causes every subsequent page you view scroll vertically and horizontally.

Of course, Apple’s Human Interface Guidelines for Resizing and Zooming Windows explain that the zoom button isn’t actually supposed to expand the window to fill the screen, but toggle the window between a standard application-defined size and a user-defined size. Regardless of what the human interface guidelines say, though, I still don’t like what it does, and I’m apparently not the only person. There are hundreds of pages asking how to fix it.

In case you’re wondering, the bookmarklet is:

I simply put the bookmarklet first in my bookmark bar, which lets me maximize Safari by hitting ⌘1. I didn’t write this little snippet of Javascript, but I can’t remember where I found it and there are versions of it all over the Web.

So, back to the real story. Upon further investigation, I determined that the bookmarklet only works when the Safari window contains a single tab. If the window has more than one tab, the bookmarklet doesn’t work. I wasn’t the only one who noticed this bug, as I found the post Safari 4 breaks bookmarklets? on This Is the Green Room.

I figured the problem would be fixed when the final version of Safari 4 was released, but when that happened this past week, the problem remained. Googling a bit, I found WebKit bug 24218, which notes that the Javascript window.moveTo and resizeTo methods do not work in Safari windows with more than one tab.

Since the bug was marked unconfirmed and didn’t have any activity on it for months, I decided to download the WebKit source and try to track down the cause of the problem. I checked out the WebKit code and built it according to the instructions. After digging a bit and setting some breakpoints, I figured out that the following method in WebCore/page/DOMWindow.cpp implements window.moveTo in the Javascript engine:

This method basically does some adjustments with the screen and window rectangles, and then finally invokes Chrome::setWindowRect to perform the actual move of the window. Stepping through the method when clicking the bookmarklet with one and two tabs showed that all the rectangle calculations were resulting in the same values regardless of the number of tabs. The invocation of setWindowRect simply wasn’t moving the window when there was more than one tab.

After a bit of indirection through some other classes, Chrome::setWindowRect calls WebChromeClient::setWindowRect in mac/WebCoreSupport/WebChromeClient.mm:

This method basically translates the rectangle coordinates between the scale used by the window and the WebView itself, and then sends setFrame:windowRect: to WebUIDelegate. This delegate is the bridge between WebKit’s Javascript engine and the actual Cocoa browser window (I think), and WebKit is passing it the correct coordinates to move the window. WebUIDelegate, though, simply doesn’t move the window as it should when there is more than one tab, which leads me to believe the bug is in Safari itself, not WebKit.

I updated the WebKit bug and filed a new bug for Safari on Radar. I thought for a moment that this behavior might actually be intentional, to prevent pages from resizing the browser window via Javascript when there are other open tabs that would be affected. But since the bookmarklet works in Safari 3, I tend to doubt this new behavior is by design as it would break a lot of existing Javascript. Scripts embedded in an actual page are similarly unable to move or resize the window when there’s more than one tab open, so the problem doesn’t have anything to do with the Javascript being in a bookmarklet.

Share This

Know Your Limits

By Matt in Applications

Limitations. It’s one of the central tenets of the modern web application design and development aesthetic: less is more; niche-level focus is the path to success; feature creep spells doom and confusion. Limitations keep things on track. Building only what is necessary benefits both developer and user.

But, as with all principles, careful application is key, and limits are a sticky subject. Are your limits unexpected? Are they advertised, explained, or easily understood when discovered? What happens when a limit is hit? Is the limit purely a technical one? How much work is saved by placing a limit on something, and do you run the risk of raising user ire by enforcing it? What will you tell your users is the reason for the limitation if they ask? Are you trying to follow a trend of behavior, or set one?

Twitter

Twitter limits posts to 140 characters, and largely because of that limitation the platform is the biggest thing since sliced Facebook. Brevity is the cornerstone of Twitter; as a result, URL-shortening services have become a necessity to pack as much into a tweet as possible. You can only follow 2000 people on the service, which helps the servers that run Twitter and is a number that no user would be able to realistically keep track of anyway. And, for some reason, only only 162 pages of archived tweets are available — likely another technical limitation designed to reduce load on the historically unreliable Twitter architecture.

Twitter is a great example of an idea successfully based on limits, and the limits it enforces are not conspicuous enough to be annoying. On the other hand, Twitter’s limits on API usage have irked some deveopers, and when features sometimes disappear in the name of keeping the site live under heavy stress, users are understandably surprised, confused, even angry. As Twitter is iterated upon, these issues should become less and less prevalent, and the expectations of its limits will be fulfilled more consistently.

Muxtape

The late great Muxtape was all about limitations. Each user was limited to a single mix, and each mix was limited to no more than twelve tracks. This kept things from getting indulgent, and doubtlessly saved disk space. On the flip side, users were also limited to only twelve ‘favorite’ mixes to save on their profiles. As a frequent Muxtape user, I found this limitation made it difficult to keep track of more than that number of mixes, which presented a problem — I wanted to maintain a list of both friends’ mixes and mixes I wanted to save for later listening. It never kept me from using the site, and it may have been changed in the future, but it was a little annoying.

Take It to the Limit!

The key is to make sure your limitations never restrict exploration and excitement, but instead focus on creating those emotions in your users. For new users, exploring a site’s purpose can be intimidating and, potentially, a waste of time. If you can condense the message and narrow the feature set, your product will be much easier to understand, and thus easier to participate in. Once a user is in, however, don’t let them stop at accumulating reasons to revisit the site, or telling friends. Keep things as sticky as possible.

Helpful Limits

• Your site doesn’t need all of the features it could have. If a problem has already been solved, don’t replicate — incorporate or eliminate.
• Would your site’s content (user-generated or otherwise) be more compelling if limits were applied to it? What if you only had a sentence to explain each page? What if users’ bios could only be six words long? Restrictions can often provide the frameworks in which participation and creativity truly thrive. Read Peter Bregman’s Why Doing Things Half Right Gives You the Best Results for an idea of what can happen when users are presented with too many choices.

Hopefully Limitless

• Users should be able to have as many friends, favorites, and other “collectibles” as they need. If all that data storage is costing you too much to keep it free, make people pay to up their limits. It works for Flickr, and there are a lot of people who would pay for Twitter too.
• Explain your limitations upfront, and go easy on users that reach or try to break them.
• Limits should look like limits, not like errors or something unfinished.

So?

Limits and their potential consequences are a helpful structure in which to evaluate the features of your site and every facet of its design — both the system and the interface. Keep limits in mind as you’re building, and you may end up launching ahead of schedule, saving yourself time and your users the time of figuring out the ins and outs of your site’s feature-set.

I’ll leave you with some questions. Which of your favorite services employ limits, and how does it make things easier or more difficult? Is limiting favorites is a mistake? Is there something positive to be said for a limitation that users won’t like?

Share This

Wikipedia’s Babel Userbox

By Matt in Applications

There are few who would deny that Wikipedia is an incredible resource for information and a testament to the power of an intelligent global human community given basic interconnectivity and the tools to share knowledge. But it’s not perfect. From a design and usability standpoint, in fact, there’s a lot wrong. A number of sections and features on the site are downright baffling to use, and poor design is more than prevalent. I could go on for hours, but I’ll stick to one thing for the moment: something I noticed when I went to update my user-page this morning.

I am a contributor to Wikipedia, and I speak Japanese. To indicate that fact to people that visit my user page, there’s a box that lists the languages I speak and just how well. (This box, technically called a ‘userbox’, sometimes abbreviated ‘UBX’, is part of the Babel project, and was the first userbox template on Wikipedia. Since its inception, badges for every conceivable attribute have emerged.)

I don’t understand this box. What’s going on here?

The numbers don’t mean anything

The numbers are somehow meant to signify your proficiency at each particular language, but they are basically meaningless. The questions immediately raised are:

• Is 2 is a high number or low number?
• The range into which a number falls is unclear. Two out of what? Of five? Of ten? Of six hundred quadro-billion?
• There’s no way to tell the particular language skills actually signified by each number. What’s the difference between a ja-2 and a ja-3? Is it a difference in vocabulary size, conversational ability, etc.?

Furthermore, the scale isn’t limited to just numbers — there’s a ja-N for native speakers. Even more confusingly, I speak English natively, but the template Babel box posted for native English speakers uses only en, not en-N. (Incidentally, there’s also an en-N category). The system is totally inconsistent.

If you read the fine print, it turns out a lower number indicates a lower level of proficiency. There are many different metrics one could use for language proficiency (or any sort of skill, for that matter), and among them both high or low numbers could be used to indicate expertise or accumulated experience. You can be a first-class pilot (a low number) or a Level 64 Gaming-Warlock (a high number). Incidentally, the Babel box numbers are roughly based on the ILR scale, in which a lower number indicates lower proficiency. Contrast this with the Japanese Language Proficiency Test, where a lower number indicates higher proficiency.

The point is, the nature of the metric being used here needs to be made obvious by showing the bounds of the metric and the significance of each bound.

The explanatory text is unhelpful

The Japanese sentence next to the ja-2 box explains that I’m a medium-level speaker, but only people who read Japanese can understand that. (And what does speaking have anything to do with it, anyways? This is a website concerned with reading and writing.)

The design of the box is lacking

• Why is it titled ‘Wikipedia:Babel’?
• Is there any rhyme or reason to the color scheme?
• What does it mean to ‘Search user languages’?
• It’s aesthetically boring at best, ugly at worst.
• The syntax for creating userboxes is needlessly confusing.

It turns out that investigating the ‘medium-level’ link hidden in the explanatory Japanese sentence in my Babel userbox reveals yet another badge:

Confoundingly, this badge is a different color and is more explanatory, but it’s hidden away in the Babel userbox documentation pages. It doesn’t really even make sense as a badge in that context. I give up.

Why is it such a mess?

Clearly, the Babel userbox needs work. I chose to focus on this tiny little aspect of the site, but it’s indicative of a much wider swathe of design and usability flaws on the site in general. But why is this the case? Some insight into Wikipedia’s defects may be found in two places: Google and open-source software.

Those who find success in Google’s infamously minimal “non-design” point to its ability to sink into the background and make way for the important stuff — search results, emails, etc. Likewise, Wikipedia is about articles. Only the power-user needs to worry about things like revisions, categories, templates, and profile customizations such as the Babel userbox. The article (and editing it) are the strong idea, and Wikipedia has the momentum of quality, quantity, and notoriety, which, like Google’s search engine and email service, are enough to get beyond what’s lacking in the interface.

Open source software is plagued by poor usability. As an open-source software project, MediaWiki suffers from many usability problems. This is compounded by the fact that Wikipedia, the encyclopedia built upon it, is itself open to anyone. And those anyones are often experts, but not in the field of design or information architecture. Thus, amateur and suboptimal design is the standard.

Share This

Anatomy of a Stylesheet Rule

By Matt in Information Design, Design

We were putting together a CSS style guide for a client and created this image as a quick guide to the anatomy of a stylesheet rule. It’s helpful to have a common vocabulary of terms when talking about something you’re working on, and even more helpful to know they’re the right ones.

Share This

Novelty and Innovation

By Matt in Design, Commentary, Usability

Simply new and different do not innovation make. In fact, the difference is pretty substantial. According to the OED:

innovative: featuring new methods; advanced and original.
novel: new or unusual in an interesting way.

I was spurred to write this commentary after seeing a Tumbl’d photo of a creative bathroom arrangement by serial entrepreneur and innovator Jakob Lodwick. Here’s the photo, for reference:

While I find the arrangement of the toilet paper dispenser interesting, and love that there are people like Jakob out there willing to publish this sort of thing when they discover it, I take issue with it being called “innovation.” The bathroom does feature “new methods” (or at least one), and, hey, it’s plenty original, but does it fulfill the third requirement? Is it sufficiently advanced?

I call foul. It’s interesting that the toilet paper dispenser is screwed into the chair, but at the same time it’s a waste of a chair, arguably one of the most functionally perfect inventions in human history. There would perhaps be merit to this if it were posited as an art piece with some message behind the configuration, but that doesn’t seem to be the case here. I think it would make much more sense to put the basket on the floor, keep the roll in its usual place — at arm’s length on the wall — and then have an extra chair to use. From a functional design standpoint, it seems more like a misstep than innovation to me. As it stands, the chair is impaired for other uses and the toilet paper dispenser can now be accidentally removed from the bathroom.

I don’t mean in any way to single out Jakob or indict his creativity. In fact, I’m not so certain the post wasn’t entirely tongue-in-cheek. Rather, his photo-and-single-big-word post prompted me to write something I’d been meaning to articulate for a while. I think in the slightly feverish atmosphere surrounding the software and web development community nowadays, there is a tendency to get a little too excited about things before they’ve either been properly examined or vetted by history.

Novelty is a good thing, and I’d hate to live in a world without it. In fact, a lot of innovation — I’d even wager the vast majority of innovation — comes from experimenting with novel ideas. But novelty is not innovation on its own, no more than simply experimenting with food, machinery, or art (regardless of your credentials) is innovative on its own. The same goes for software. It’s the reason things that momentarily enthrall us eventually fade: many of them are just novel. The things that stick, on the other hand — the wheel, the chair, rock music, Craigslist, the MP3, and the Post-It (literally) — those are innovative.

Share This