Two’s Company
- Image via Wikipedia
It’s been about 10 months since Home Document Manager made the transition from project to product. Looking back on those 10 months I can level a couple of criticisms at myself; the main one is that I haven’t iterated aggressively enough. The other is that I’ve ignored some customer feedback because it didn’t gel with my vision of where I wanted Home Document Manager to go.
Something happened in the last month that has injected a bit of pace into my development. I started considering a closely related, although entirely seperate product. Where HDM is a desktop document management tool, the new product was an advanced PDF Viewer/Editor/Annotator.
Part of the dance that micro ISV‘ers do when conceiving a new product is to evaluate competition, see what they do, see what they don’t do, see if they alleviate the particular pain that you’re trying address, and why, or why not. In short, we try to find our Unique Selling Proposition. I looked closely at a number of big names in the document imaging and PDF worlds, products like Acrobat Professional, Abbyy Finereader and the like. Not only did I find my USP within minutes, I’ve found a wealth of new user interface ideas and major bits of functionality that would slot right in to Home Document Manager.
I’m already a decent way through coding for the new product and have had so many a-ha moments for version 2 of HDM too.
Choosing WPF was a mistake. I love WPF. I work for Microsoft writing WPF. But for this particular project, it was the wrong call. The new project I’m writing uses Windows Forms. It’s been a while since I did WinForms, but my WPF experience is illuminating my UI architecting in new ways. I also really don’t miss the WPF cold start times. I’m certainly more productive using WPF, but let’s face it, in the B2C world, your customers really don’t care about that. Version 2 of HDM will use WinForms.
I haven’t paid enough attention to minimising the clicks my users have to go through in order to perform common tasks. This was immediately apparent when reviewing the competition for my new product, so version 2 of HDM will have a much improved UI.
The deployment mechanism I use for HDM (ClickOnce) has its advantages. I can update end user installs easily, but serious B2B is a struggle because of the lack of Proxy support in ClickOnce. I also fell into the self signed ClickOnce bootstrapper trap, which effectively brought iterations of version 1 of HDM to a premature end. Bog standard installers from hereon-in.
One of the things I have to consider is whether or not to bring two such closely related products under the same umbrella on the same website. This has obvious advantages for marketing and SEO, they are both paperless/PDF/document related products.
A lot to mull over, but for me, speccing and developing a second complimentary/related product seems to be a good thing so far. I know the arguments about laser-like focus for micro ISVs, and I’m hoping that I’m not stumbling into a heffalump trap. But having two related products, particularly on the same website, should add credibility, and the 2 products can also have a beneficial effect on each other. Time will tell.
p.s. I’m writing this on Christmas day only because I’m standing in the kitchen with our latest edition (Eli Benjamin, 6 weeks old) strapped to my chest while I wait for the turkey to cook. Happy Christmas everyone.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=fc071dc3-6da3-4fd5-a4c9-b05b21c37ced)
Hi Tim,
I’d really like to know what problems did you face using WPF that drive you to the conclusion that choosing that technology was a mistake. I’m planning a new product and I’m leaning towards WPF even though I’m a WinForms guy.
Hope you can comment on this.
Hi Jose, the main reasons *for me* are:
1 – Over 50% of all visitors to the Home Document Manager website use Windows XP. About 20% use Vista and 20% Windows 7. I can target v2.0 of the framework with a clear conscience with Winforms in the knowledge that I’m not adding bulk to my download.
2 – WPF’s cold start times suck. The prettiest splash screens in the world won’t alter that fact. It’s not as big a problem in B2B world, but when you’re selling to Joe Public, a perceived sluggishness at startup is another reason for them to buy your snappy native C++ based competitor.
3 – Third party WinForms UI components are more advanced and more mature. DevExpress in particular.
I’m not creating an “out-there” UI in my apps. They look and feel like Windows applications, so I don’t need WPF’s awesome UI power. I can’t think of a reason *to* use WPF for B2C apps at the minute. YMMV.
I’d love to know which way you decide to go, and why.
I pretty much wrote all my doubts about which path to take some months ago (http://www.nowfromhome.com/new-project-wpf-or-windows-forms/).
The thing is that I’m still not 100% sure and your post made me rethink it again. It specially called my attention that you you said that it was a “mistake” and the fact that you are rewriting your UI.
I’m entering a crowded niche. However 90% of the competition have very complex and intimidating UI. I’d like the GUI to be one of the differentiation points in my application. Ideally I’d like something like the Lawson M3 screenshot you can see on my post. The problem is that I’m not a designer and it’s very likely to end up with a mess or a typical WinForms application.
Anyway, I think I’m going to go with WPF. This is a mid-term project and it has to be fun. I also think that .NET 3.5 adoption is going to improve quickly. Also, what do you think about .NET 4 Client Profile? 30 Mb doesn’t sound that bad (at least in my niche) and it is supposed to improve WPF performance as well.
We have two apps, one written in WinForms and one in WPF. When making the decision to use WPF, the deciding factor for me was databinding, XAML, and Silverlight. WPF databinding rocks, and I think its the most beneficial non-visual advantage. My first impression with WPF was that Microsoft accomplished their goal of “best of winforms, best of the web”, however after using it for over a year, there are definite painpoints. As Tim points out, cold start times are painful. Also, debugging is often more difficult as the framework is extensive, especially around weak references and our use of the command infrastructure. And finally, our solution will eventually lead us to web work and the investiment in WPF and XAML technology will hopefully pay off as we look to utilize Silverlight in a web UI to avoid javascript based business logic.
One more note on WPF. I had a customer request support because our app UI was not rendering properly. Double visuals and cutoff panels. The solution was to update his video driver! As a business app developer, that was a first for me. You wont have that problem with WinForms.