I’ve actually had way more fun than I realized writing this series – I honestly didn’t think I had this much content on this subject. As I’m finishing up the series, I want to talk about how I personally feel about applets.
As I’ve mentioned before, I often end up sending mail to various email lists inside Microsoft railing about all the crap that <pick my favorite victim of the day> has running on my box (I did start these posts by saying “It’s my machine, dagnabbit”).
I always add a caveat to that comment: “Please remember that my definition of ‘crap’ is ‘Stuff I don’t use’. If I use it, by definition it’s not ‘crap’, and I recognize that my ‘crap’ isn’t always your ‘crap'”. What I find fascinating is the number of people who respond “Wow, I never thought of it that way!”
There are a lot of people who are rather upset about applets, given the lack of quality and respect for the user I’ve seen in some of them, I’m not totally surprised at this.
It’s extraordinarily easy, when designing a feature or component to get caught up in the idea that you MUST make your feature discoverable and thus you forget one of the basic tenets of system programming: “Do exactly what you need to do to get the job done as efficiently as possible.” They forget that it’s NOT their machine to do with as they will, it’s their customers’ machine, and their customer might not be as enamored of their feature as they are.
At the end of the day, I tend to be relatively agnostic about applets. I recognize that they have to exist, I like some of them (I’ve already mentioned that I like RSS Bandit’s (not really an applet, to be honest) use of the notification area, similarly, I like taskmgr’s use), I tolerate some of them (the flash helper applet), and I’m utterly infuriated by still others (there’s an printer driver that came with a printer I own that crashes the spooler service once a day, even though the printer in question is powered off and is used maybe once a month).
What gives me hope for the future is that it’s NOT impossible to write applets that have relatively minor impact on the user – if you follow some basic rules, it’s possible to have applets that don’t tank the system. But the critical thing is that you MUST change your mindset about your applet. Instead of trying to figure out how to get your functionality in your users faces, try to figure out how to make your user want to use your functionality. Make sure that you provide significant value to the customer before you start consuming their resources.
Every single applet that runs on a machine acts as a tax on the customers machine – they consume memory and cpu resources that could normally be used by the user. Eventually the taxes add up and the customer’s computer becomes totally useless.
I firmly believe that the people who write software actually want to help improve their customers experience (yeah, I know that I’m hopelessly naive). But the people who write the programs that our customers use are NOT trying to actively harm the user. They just don’t know how to do the right thing (or are faced with with schedule pressures that don’t allow them to do the right thing).
My personal feeling is that people will realize which vendors have produced bad applications and will eventually start avoiding those vendors because of the quality of their product. And when you hit them in their pocketbook, it works – the vendors will either improve the quality of their product or they’ll go out of business.