Hmm, Luis mentions this AOL-as-badware report. While some of the stuff is plainly bad, such as the fact that you can't uninstall fully, I can't agree with some of it.
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.
This innocent-looking code to cache RSS feeds in ROME is thus totally busted.
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.
I'm implementing a web-based prototype of the eventual Linux/Windows client interface right now. You can see the javascript code here and server side code here (sorry websvn is so slow).
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).
I've been known to complain about Javascript before. The thing that's bugging me this week: attempts to claim its misfeatures are a positive.
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!
OK, that may be debatable. But how about this defense of the Javascript class/inheritance "system":
JavaScript can be used like a classical language, but it also has a level of expressiveness which is quite unique. We have looked at Classical Inheritance, Swiss Inheritance, Parasitic Inheritance, Class Augmentation, and Object Augmentation. This large set of code reuse patterns comes from a language which is considered smaller and simpler than Java.
Gee, I live to choose among 5 kinds of inheritance, all of them inconvenient and bizarre.
Unlike sane dynamic languages such as Python, Javascript isn't even typesafe at runtime... if you pass the wrong number of args that's cool, if you pass the wrong kind of object that's cool too, assign to a nonexistent field - let's just create that!, use a string instead of an integer - let's just convert it! - do inheritance wrong - oh, you're inventing a cool new kind of inheritance! Sweet!
The hype about Ajax has to be amazement that anyone got this crappy language to do anything at all. Google has the right idea:
Google Web Toolkit (GWT) is a Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers who don't speak browser quirks as a second language. Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatibilities between web browsers and platforms, and JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.
That about sums it up...
If you think I'm overreacting you probably haven't written and maintained enough Javascript ;-) and we would be very happy to hire you so you can get more practice. You think I'm kidding, but I'm not...
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.