Making it easier to install Mac apps

September 17th, 2009

Limi and Gruber recently wrote about what application developers can do to make installing Mac apps easier. All the choices have serious downsides:

  • Disk images take many steps, and many things can go wrong.
  • Zip files leave you wondering what to do, especially if you use a browser other than Safari.
  • Installers have a reputation for being sneaky (on Windows) or indicating that an application will require elevated privileges (on Mac).

What can browsers do to make some of these choices suck less, and make installing Mac apps easier?

Here's what I'd like to see: when you download a zip containing just an application, the browser offers to "install" it for you rather than just leaving it in the downloads folder. It could even do the same for disk images that contain nothing other than an application and a shortcut to /Applications.

Install applications only from authors whom you trust.

Malicious software can damage your computer or violate your privacy.

You clicked a link from http://adium.im/ that downloads an application called "Adium". Move it to /Applications and:

[x] Add to dock
[ ] Add to desktop
[ ] Launch now (if unchecked, reveal in finder)

Cancel / Install Now

Done right, this could be both easier and safer for users than leaving software in the user's Downloads directory.

Crash bug triage day #2

August 18th, 2009

Today is the second crash bug triage day. Can we beat the first one's record of resolving 104 crash bugs and identifying several important, valid bugs?

(Short, time-specific blog posts feel weird now. You should follow me on Twitter.)

iPhone Voicemail

July 29th, 2009

Dave Cronin complains that when he misses a call and gets voicemail as a result, the iPhone forces him to click both Recents and Voicemail to clear badges.

I agree with his complaint, but I don't like his proposed solution of making call history and voicemail a single list. I worry that with his design, leaving voicemails for an iPhone user would become a crapshoot, similar to emailing many people.

The reason email works poorly for many people is that it encourages them to mix reference information with to-do-reminders. A reminder mixed with a large amount of reference information is as good as forgotten. Good default workflow is especially important for voicemail, given its status as the last bastion of sanity in many lives:

I have never heard anybody say, “I get too many messages on my answering machine. I get too many voicemails.” What’s the difference? There’s no difference. [Just like with email], you get stuff that’s just reference stuff, that’s just trash, and stuff you need to act on.

What people don’t do is leave it there, undecided. But they do about e-mail. They also do it by paper. That’s why most people are highly voice-addicted, and most cultures are voice-addicted. That’s why interruptitis is so huge out there, because if you have something you consider timely and meaningful that somebody needs to know and hear, you’ve got to deliver it to them by some sort of auditory means, because that’s the only thing they’re processing.

Well, I just go, “Duh! Somebody give me the rationale for this.” And there is none. E-mail wouldn’t be a problem if it blew up like your answering machine did once you got more than a screen full.

The iPhone Recents list is primarily reference information. In particular, it provides shortcuts for calling people you have talked with recently. Mixing voicemail with Recents would force you to mix reference and reminders, because unlike with email, you have no other good place to put the reference information.

How could Apple address Cronin's complaint without leading iPhone voicemail users into the same trap that email leads people into? I think the solution is to divide the list not by kind (calls vs voicemails) but by purpose (needs-processing vs reference). An "In" list would show both voicemails and missed calls, and encourage you to keep it empty. The "Recents" list would serve only as reference; you would never feel compelled to go there to change something.

One challenge with my design is to ensure that removing missed calls from "In" feels more natural than ignoring them. Otherwise, users will fall into the email-like trap, just like I fear they would with Cronin's design. I suspect it would be best if it feels like moving the missed calls to Recents, rather than deleting them. A "Clear Missed" button button might also help.

Making Firefox faster for humans

July 26th, 2009

User experience designers Alex Faaborg and Alexander Limi are looking to broaden the scope of efforts to make Firefox faster. Until recently, most of the effort has involved reducing the computation time needed to launch Firefox or render a web page. Faaborg and Limi argue that we should also look for ways to make computation time matter less.

The wiki page Perceived Performance contains a long list of ideas. Don't be fooled by the "perceived" part of the name: although a few of the ideas would merely make Firefox users happier, most of the ideas are aimed at reducing the amount of time users spend waiting for Firefox to do various things.

Common themes include:

Improve handling and feel during input. For example, letting scrolling "accelerate" makes rapid scrolling easier without harming the ability to make fine adjustments.

Give instant feedback in response to input, even if an operation has to continue in the background. In addition to reducing human waiting time, these fixes make the experience feel more like direct manipulation and less like telling Firefox what to do. (See also: "snappiness" bugs.)

Allow users to interact with partially loaded pages sooner. This is especially important with slow connections, which are becoming common again as computing goes mobile. Boris Zbarsky's interruptible reflow work is likely to help, and I added some ideas about making better use of the cache.

Reduce the number of clicks and keypresses needed for the most common interactions.

Give users new tools that let them avoid waiting. The introduction of tabbed browsing made it matter less when pages loaded slowly, by letting users load links in background tabs while continuing to read, but also introduced new problems.

Diminish frustration when slowness can't be helped by making changes to activity indicators, progress bars, and other messages. Give users the impression that Firefox is working hard, and help users make better choices about whether to wait.

What kinds of slowness do you encounter while using Firefox? Where should we focus performance efforts, whether by reducing computation time or through more clever means? Can you think of new ways to apply the themes above, or any other ways to make Firefox faster where it matters?

100 crash bugs resolved

July 21st, 2009

Today's crash bug triage day was a success. We resolved 104 crash bugs, mostly as worksforme and incomplete. We identified several old bugs as still valid, even important. We demonstrated that the backlog is not impenetrable.

I was impressed with the volunteers in #bugday: tmyoung, kbrosnan, and SpeedEvil all helped throughout the day.

There will be another crash bug triage day next Tuesday. I'm looking forward to finding out what we can accomplish next time!

Crash bug triage day

July 21st, 2009

For the next 14 hours, let's see how large a dent we can make in the crash bug backlog. I'll be in #bugday as Jesse.

Whether you're interested in helping with the overall triage process or just a part of it (such as testing on Windows or making reduced testcases), please join us today to help make Firefox more stable and secure :)

How Mozilla finds crash bugs

July 20th, 2009

I wrote a post for the Mozilla Security Blog: How Mozilla finds crash bugs. It includes information about tomorrow's crash bug triage day in #bugday.

Language barriers and bugs

July 18th, 2009

A text-input bug affecting many Arabic speakers was discovered when we were about make Firefox 3.5 release candidates, and we chose to include a fix in Firefox 3.5.1 rather than delay Firefox 3.5.

The zero-day vulnerability in Firefox 3.5 was a frequent crash on the front page of a top-500 Russian site, but we didn't find out about it until after we shipped Firefox 3.5.

The reason we found out about these bugs late isn't a lack of non-English beta users. 1.8% of English Firefox users are beta users, and 1.6% of Russian Firefox users are beta users. Arabic beta use is much higher, at 3.5%, perhaps because Firefox 3 was such a large improvement over Firefox 2 for rendering Arabic text.

Instead, the reason may be that people who don't know English can't report bugs easily. They can't even search Bugzilla to find out whether their bug is known. They went out of their way to try betas, but beta-testing alone does not keep major problems from making their way into a release.

How can we enable the rest of the world to participate in reporting bugs, or at least ensure that we find out about the most frequent problems in other languages?