e.g. Google Talk also does automatic updating, and I think it's exemplary good software behavior; the alternative is all the apps that install a "check for updates" tray icon and tell you about it all the time. "Look at me! I'm updating too! Check it out!" - cute for one app, sucky when you have quite a few installed. Hmm, Firefox also does automatic updating; it auto-downloads, then asks if you want to restart Firefox, and whether you do or not the next time you start up Firefox you automatically get the new version. Are these badware too?
I don't think putting a toggle for this in an installer would make any sense. Many people wouldn't know what it meant or wouldn't read carefully, and if they turned it off they'd just be shooting themselves in the foot by not getting security updates. Why clutter the installer? Allowing auto-updates to be turned off in preferences is just fine.
Seems like some of these "badware" guidelines lead to "dialogware" (which is also a nasty Windows disease), where instead of just picking sane behavior and allowing you to modify it later, the app asks you about everything in a dialog. As I think Joel notes, programmers love dialogs, but in my experience designers will LART you pretty much every time you put one in. I also suspect that technical users are more prone to want to be asked everything than nontechnical users are. (Random aside, Visual Studio is the worst in this respect, it's like a dialog firehose.)
Anyway, I'm not sure the badware guidelines should include debatable design decisions or stuff that's merely annoying. As long as the app uninstalls completely and easily from the normal add/remove programs screen, if people think the app sucks they can always get rid of it. Of course, the AOL software does appear to be hard to get rid of.
I have to admit I was surprised and annoyed when the AOL Instant Messenger installer also installed some crazy-weird web browser (not IE, not Firefox) ... the bundled software with AOL 9.0 could conceivably be there as dependencies (e.g. maybe AOL 9.0 requires Quicktime to work right), but it's tough to imagine that an IM client needs to replace my web browser in order to work.
Deadly trap all Java programmers should know: URL.equals() and URL.hashCode() resolve the hostname in the URL, then compare equality by IP address. Which means 1) these methods are way too slow and 2) virtual hosts break them - every RSS feed URL on blogspot.com (for example) compares equal.
Two months ago we launched a limited user trial of our Mugshot prototype, and have learned a lot since then, both about the user experience and about how to keep the server from falling over. Thanks to everyone who's been helping out, we've had good comments, advice, and patches.
On the user experience front we've decided to pull together a number of new features we've tried over the last couple months into a new design we're code-naming the "stacker". This pulls some of the flavor of where I'm at into the primary Mugshot UI, letting you easily keep track of everything that's happening online in your network of friends and interests.
The goal is to put up an ugly, but usable, web-based prototype probably sometime next week for people to try. Once we get the basic interactions about right (and hopefully verify that this direction makes sense), we'll do a more web-friendly design and replace the main Mugshot page with that. We'll also code the Windows and Linux desktop versions.
In parallel, we're investigating server scalability and will be redoing things as required to spread the load over two servers (right now we still have only one). The big step is from one to two of course, from two to four is in principle much simpler. Ideally this will come together about when we have the new UI.
(Another shorter-term task, Owen is finishing up the improved Firefox support.)
If it all pans out we should have both a better user experience and the ability to scale up as we add more users - woot.
One effect of the new direction is that Mugshot could offer a very interesting API, both via web services and over D-Bus/COM to desktop applications. This API could let you get people's profile information including pointers to their stuff on Flickr, YouTube, blog; list of friends; email addresses; etc. (getting some of this would require you to be logged in as a friend of the person). It could also allow apps to get live notifications when things happen, such as new Flickr photo sets, new links shared, new friends appearing, new comments on your blog, new songs played, or whatever it is.
We have to focus on our two current goals of implementing the "stacker" and server scalability basics. This keeps us from fleshing out the API too much right away, but if there are specific API calls you'd like to have or experiment with in an app, please let us know. The other night I added a really lame API docs page using introspection (sometime next week you can probably see it on the live site, right now it's only in Subversion).
First we have this tutorial on splice():
Using the example, try entering bad data in the boxes. Try entering letters (numbers are needed). Try entering numbers too large or small for the array. You'll notice that nothing happens. The program does not crash even though I've coded no error control. One of the best features of using array methods to update dynamic arrays is that errors are automatically handled with a default action of nothing.
Wooohooo! My program silently does nothing when it has a huge bug in it!
Gee, I live to choose among 5 kinds of inheritance, all of them inconvenient and bizarre.
The hype about Ajax has to be amazement that anyone got this crappy language to do anything at all. Google has the right idea:
That about sums it up...
A team at Red Hat is looking for people to take this survey entitled "what do you think of us?" - if you have a chance I'm sure they'd appreciate your help.