I'm generally a big Microsoft fan, but they do some things from time to time that really bug me. I'd like to think that the reasons are linked to a grand plan somewhere, but I just can't tell sometimes. I've written a few words on this subject before with respect to the .Net framework, and I've got a couple more to gripe about today.I'll start with InfoPath. I recently started to slog through an RFQ for an application that needed to do a fair bit of forms processing (they're replacing paper forms, in fact). I'm writing the technical architecture for the proposal, and these guys are a Microsoft shop, so I pull out the old MS bag of tricks and go to town.
I start with .Net and SQL Server, of course, and since this RFQ called for a disconnected client for quite a few of the users, I spec-ed a smart client. Good stuff - this was starting to look like a fun project. Next, I needed e-forms, digital signatures, validation and workflow. I started considering the options, and as I'm researching specific features of some packages, I see a lot of references to InfoPath.
It turns out that InfoPath would be a great option for this project. It's obviously a great tool for e-forms. The thing that really gets my attention, though, is that I very quickly stumble upon all sorts of articles and examples for how to use digital signatures in InfoPath and how to integrate InfoPath into BizTalk to handle workflow and integration. Great - it looks like I can knock out all sorts of requirements in a flash.
Wait a minute.
There's a small problem with this plan. Remember the disconnected clients? They don't belong to the same organization that's issuing the RFQ. In fact, they belong to a whole bunch of third-party companies. If I spec InfoPath for this project, I add around $200 to every single install for that smart client. In a flurry of keystrokes, I add hundreds of thousands of $$$ to the cost of the project. That's not gonna fly.
I pause for a moment and let the steam waft away in a little cloud of despair. I'm back to doing the forms by hand.
Now, in the big picture, this isn't the end of the world for me, but as an architect, I'm always a fan of using functionality off the shelf. InfoPath was perfect for this project, but I couldn't use it because of the way it was licensed. Now, I understand that MS needs to pay the bills, and the Office suite is a big chunk of their revenue. Still, I needed a way to license this particular Office component as an embedded component -- not a stand-alone Office executable. In this application, InfoPath was going to end up so deeply rooted in the application that it would likely not be recognizable as a separate product. It was going to be a control, like a calendar or an RTF editor. There are some great examples on MSDN about how to create an application with an embedded InfoPath component, but the articles make it clear that you've to have InfoPath installed where this software will run.
Request to Microsoft: Give architects a way to spec InfoPath without incurring this kind of cost. Maybe an application license that lets us use the functionality for a specific application (bake a key into an assembly or something). Whatever. Just let us use it in a smaller increment.
The next gripe is pretty similar. As work continued on this proposal, I needed to start working with a Project Manager to get a WBS ironed out. Tool of choice, of course: MS Project. Here's another one I'm sure you've run into. You put a project plan together, but it's held hostage on your PC. Oh, sure, you can save the plan as HTML, but if you've ever seen the output from that, you know how uninspriring that is.
Have you ever noticed that there are free viewers for every other Office application (Word, Excel, etc.), but not Project? There are a handful of vendors out there selling viewers for $30-40, and ILog's got a free viewer that works as long as you save your project as XML, so again, this isn't the end of the world, but it's another one of those real head-scratchers.
Come on, Microsoft. Give us a little help here, ok?