Sunday, November 29, 2009

Firefox Updates and Magic Formation

For awhile now I have used a little gesture-based launcher called Magic Formation. Like many of the things that are designed to make my life simpler but end up consuming all my time, I found out about this tool on Lifehacker.

The tool is pretty simple. You draw a quick little circle with your mouse and up pops this circle of launch icons. It is also pretty addictive. When using a computer that doesn’t have Magic Formation installed, I find myself reflexively drawing useless little circles before realizing “Oh yeah, I’ve got to find the launch bar.”

One thing that keeps biting me, though, is that when Magic Formation is running, Firefox updates won’t work. When Firefox tries to apply an update you get “The update could not be installed. Please make sure there are no other copies of Firefox running on your computer, and then restart Firefox to try again.” Obviously Magic Formation is holding a handle to some kind of resource that Firefox update wants to change (firefox.exe?) and Firefox doesn’t like this.

The solution is simple. Just “Quit” out of Magic Formation, start or restart Firefox, let it update, then restart Magic Formation.

My only hope is that I will either remember I wrote this or goog will pick it up and I’ll find it the next time I have problems updating Firefox.

Technorati Tags: ,

Thursday, April 16, 2009

Intuit, What Were You Thinking?

The exercise of preparing taxes always sets me on a organizing binge where I try to get a handle on the chaos that surrounds me. This year one of my big pain points was medical expenses and the management thereof. For reasons I won't go into, we wracked up a lot of medical expenses last year and will probably continue to do so this year. Due to a certain, shall we say, disaffection for the treatments prescribed by the biomedical industrial complex (all of which seem to involve the use of patented pharmaceuticals with side-effects that can only be remedied by additional, patented pharmaceuticals with side-effects that . . . (recurse until death or complete exhaustion of funds)) none of these expenses are covered by my employers health plan (as another branch of the previously mentioned biomedical industrial complex, why would it?). So that brings in my "Flexible Spending Account", multiple, related transactions of slightly different amounts, etc. Obviously I need software to manage this mess.

It turns out that my old friends at Intuit have something called "Quicken Medical Expense Manager". Now I'm a Quicken user from way back. I used Quicken back in the days when you connected to the net with a 28K modem and SLIP. I was the guy constantly pestering his bank for Quicken integration and explaining over and over how I managed my money with a program that I ran on my computer, at home, which I would like to connect to their computer so I could save both them and me time and money. I still prefer to use the native version of Quicken despite my general enthusiasm for Software as a Service (or is it "cloud computing" now? . . so hard to keep up).

So I come across this Quicken Medical Expense Manager (MEM for short) and initially I'm thinking "Great! I'll buy this puppy online, download, install it and use it to keep track of all this stuff." My initial assumption was, of course, that MEM would integrate with Quicken. By "integrate" I mean something like "If I enter a transaction in Quicken that matches certain criteria (category, payee, tag, etc.) it will automatically show up in MEM." and "If I enter a transaction in MEM it will automatically be imported into Quicken". How else, right? But something made me dig in a little further.

It turns out that MEM is not integrated with Quicken nor does it seem that it ever will be (please, somebody prove me wrong). MEM is a stand-alone tool with no more links to Quicken than any other program you might download and install. If you enter a medical expense transaction in Quicken, you have to manually enter the same transaction into MEM and vice versa. WTF?!? Talk about out of touch with your customer base! Quicken users are, by and large, the type of people that are driven crazy by having to perform duplicate, manual tasks. We will pay money (and suffer through the unnecessary "upgrades" designed to milk us for more) for tools that save us from this time-sucking drudgery. Why would you try and sell us a tool that adds to this problem?

And what's with the "Quicken" label? How is "Quicken Medical Expense Manager" related to Quicken at all if they aren't integrated? "Intuit Medical Expense Manager" would be a more honest title. Note to Inuit: the secret to selling a software suite is to make sure that every application in the suite integrates with every other application in the suite so that, even though the individual applications may not be the very best application you could get for a particular task, the suite as a whole delivers greater value than a collection of unrelated/unintegrated applications. This is just common sense to the ordinary individual but, in the world of software marketing, it looks like a stunningly brilliant strategy ("in the land of the blind . . .")

The decision not to integrate Quicken and MEM is so dumb it must have been made by Inuit's upper management. I'm guessing that the thinking went something like this: "Because we have no way of measuring how much integrating the two products will increase sales, it isn't important enough to devote resources to. As long as MEM is 'good enough', people will buy it." They could actually have a point, but it's this kind of irksome decision that erodes customer loyalty and, when times get tough (like . . uh, now), you're going to wish you had that loyalty to fall back on. Ask yourself, "what would Apple do in a case like this?" Of course they would integrate the two even if you couldn't prove that it would result in more sales this quarter! That's why Apple has fanboys and Intuit doesn't.

Technorati Tags: ,

Thursday, November 13, 2008

Cool Ways to Teach History

Just saw this article in The Register and it made me think of an old idea for teaching what life in Rome was like circa whenever. Basically you start with the information in "Ancient Rome 3D" and you use it to create a mediated MPORG in which the students can participate as individual characters. I use the term "mediated" because I think it is important to allow the teacher to control plot lines and external events to illustrate specific points such as food riots, etc. The idea is not to replace reading and discussion, but to help provide a more immediate context for these more traditional types of instruction.

Obviously this same technique could be applied to just about any time and place for which we have enough data to create the 3D environment. You could hit all the high points, Athens circa 500 BC, Tenochtitlan circa 1400, San Francisco circa 1965. What is really exciting is that, technically, this should be relatively easy to do. That is to say, it could be done with an awful lot of work by artists, programmers, writers, etc. like any game, but we don't need to invent any new technologies to make it happen. All we need is a business plan whereby somebody can make money off of this idea while simultaneously providing it to schools for little to nothing.

Computer "Science"

Someone brought this up at a recent WS-I meeting and I thought it was funny enough to riff on; "Things with 'science' in their names usually aren't". Examples were provided such as "Political Science", "Social Science", and "Scientology" (the last one is a stretch). The shared joke being that we all felt our profession, despite outwards appearances, to be much more akin to political science than physics.

Certainly there are sub-fields of computer ccience that are scientifically rigorous, but I would guess that the majority of "programmers" rarely measure anything more than simple performance metrics, rarely use any math more complicated than basic combanitorics, etc. Obviously you need to be able to think logically and express your ideas in a non-ambiguous language in order to program, but that doesn't make us scientists any more than reheating frozen waffles makes someone a chef. I've always thought that Computer Science (the programming part - not the designing chips part) would be more properly thought of as a "Applied Philosophy" than as a sub-branch of mathematics, science, or engineering.

Friday, October 5, 2007

A Better VOIP Client

I dislike phones. Not so much the phones themselves, but their interface. The basic interface, a bunch of numbers and some special keys, is bad enough, but when this interface is extended it's always a mess. I don't think I've ever seen two phones with the same mechanism for programming the speed dial buttons and the conferencing features are always hopelessly arcane. Even something as simple as putting someone on/off hold can be ridiculously complicated.

This is one of the reasons I prefer VOIP service to POTS service. I use a service called MyPhoneCompany.com (bad marketing - reasonable service) because they allow me to pay minimal $ for "softphone only" plan. Not having to have a clunky piece of legacy, single-purpose audio signaling technology taking up space on my already overcrowded desk is a big plus for me. Wherever my laptop goes so does my "phone", which is perfect because I seldom call people unless I'm using my laptop and, if I weren't, I'd be using my cell phone.

But there's a problem to all this. For reasons that I can't comprehend, most VOIP clients go to great pains to try and look like physical phones. The number buttons are the primary interface element and the mute, conference, etc. elements look like the kind of tiny buttons you see on a cell phone. Meanwhile the crucial features like contacts and call history are buried beneath layers of menus. This is just stupid and misguided (I know that Skype, Yahoo, and other IM clients that provide voice service are an exception, but I'm talking primarily about SIP clients here). I want a VOIP client that exploits the fact that it is a computer application with access to all the GUI wizardry provided by a modern OS.

Here's what a VOIP client should look like (it's also what an IM client should look like, but let's not go there):

1.) It should integrate with my contacts database (whether that is Outlook, Thunderbird, Palm Desktop, whatever) so completely that it should almost seem like an extension of that system. I don't ever want to enter names and phone numbers into the VOIP application and have them stranded there. It would even be okay if the VOIP app didn't allow me to enter contact information, but instead forced me to use my PIM client (though it would be nice to, on those occasions when I manually dial a number, to easily record that number into my contacts).

2.) You need to be able to access "the number buttons", but they are not the most important element of the interface. A numeric keypad should be off to the side and out of the way. Handy when you need it, but not taking up too much space or attention.

3.) The most important element of the phone is my contacts. I want to see my contacts as a "tag cloud". The tags are placed on individual phone numbers but the phone numbers should have meaningful names like "Smith, Bob (home)" (the same way del.icio.us *tags* URLs but what you *see* is the "site name" or whatever label you have slapped on the entry). Clicking on a tag brings up a list of all the entries labeled with that tag. Clicking on an entry dials the number for that entry. Simple, right?

4.) I want the tags to be partially managed by me and partially managed by the VOIP app. For example, there should be an app-managed tag named "mostCalled". This should contain the 10 or so contacts that I call the most often as tracked by the app. Other automatic tags would be the letters a-z correlated against first letter of the persons last name or the name of the company, etc. For example, clicking on the "a" tag would show me a list of entries like "Adams, Michael (home)", "Adams, Michael (cell)", "American Airlines", etc. There could be other app-managed tags that might be useful like "recentCalls", but you get the idea. The other tags should be managed by me pretty much the same way I manage tags for del.icio.us.

5.) Obviously I should be able to search my contacts. The contacts/VOIP integration should include launching the VOIP app when I click on a phone number in the PIM app.

6.) Conferencing in another number to an existing call should be implemented with a context menu selection off an that entry; find an entry, bring up the context menu, select "conference" and they're called and added.

7.) All other features and functions (hold, mute, record, etc.) should be implemented the way you would any normal, modern GUI (menus, toolbars, ribbons, etc.)

If anyone implements something like this, please let me know and I'll help test it.

Tuesday, April 24, 2007

Two Forward and One Back

Got to see a demonstration of Salesforce.com's Appex platform and the AppExchange marketplace at SaasCon. I was very impressed by the demonstration. It's difficult to convey the visceral impact of seeing the cycle of idea->development->advertisement ->installation->evaluation->purchase taking place without either the developer or the customer having to install or manage anything. I caught a glimpse into one of software's possible futures. When all was said and done, though, I had to remind myself what I was really looking at; an application coded in a proprietary language running on a proprietary platform.

Obviously I have no knowledge of Salesforce's plans for Appex and AppExchange, but what I have seen leads me to believe that they have no intention of opening up the system to competition. Sure, sure, anybody can write apps on Appex and anybody can buy these apps. You don't even have to subscribe to the core CRM product anymore, but it's still a closed system. Appex and AppExchange are a big tent in which all sorts of interesting things can take place but, to get into that tent, you have to pay Salesforce for a ticket.

If you've been in the software industry as long as I have, you know where this is going. Neither Salesforce nor any other company is ever going to be big enough or good enough to contain the entire SaaS market. Already there exist SaaS platforms that are somewhat similar to Appex. These and others not yet built will grow in scope and sophistication to compete with Appex . The bigger more successful on-demand ISVs are going to find themselves writing and maintaining multiple versions of their applications for these various platforms. They are not going to like this (multi-platform support is a costly activity that provides no business value to the customer). Eventually there will be some sort of open SaaS platform in which the APIs, management touch-points, deployment model, etc. will be "standardized" (not necessarily by a standards org) and the platform operators will compete on price and service quality (reliability, scalability, etc.). Salesforce and the other proprietary SaaS platform players are either going to have to switch to this open platform or fight an increasingly difficult battle to keep their ISVs and customers locked in.

I'm an idealist so, of course, I'm bound to ask "couldn't we save ourselves the pain and go straight to an open platform?" Obviously it's in Salesforce's short-term interest to lock the ISVs into their language and platform; it's basically a license to print money. But in the long term, when the switch to open SaaS platforms occurs, they will have only hurt themselves. The history of the computer industry is full of companies that got so fat and sloppy on their proprietary systems they were unable to compete when the next wave removed their ability to keep their customers captive.

It seems counter-intuitive, but I think Salesforce's best long-term move is to open up the Appex platform to competing service providers. That way the de-facto, open SaaS platform is Appex, a platform in which they (obviously) have a huge lead. The similarities to Java are obvious but, to be fair, I don't think Sun stood as much to gain from holding onto Java as Salesforce does from holding onto Appex.