Wikis seem to be catching on some at Microsoft. Several product teams are using Wikis to brainstorm features and product design, or even more mundane things like recording meeting notes. I love the simple collaborative nature of a Wiki, the openness that just invites every ready to contribute and respond to one another.
One thing I don’t like about Wikis is how they work when I’m on offline — which is that they don’t work at all. All the goodness of that collaborative web of data is trapped up on the server, and unless I’ve got a connection back to the corporate network, I can’t see any of it. Even when I am online, if I’m want to edit several entries, it slows me down to have each click launch a round trip, and wait for the server to return with the next page.
Others have observed the same shortcomings, and have started Wiki client projects here and there. JHorman seems to have wanted the disconnected Wiki experience so much that he built a personal Wiki-like notepad app. These are all neat client apps, and I’m glad to see them on Windows today, but I suspect they required a lot of code to handle storing the data on the local client.
So for my third not-bad WinFS scenario, I figured I’d taking an existing scenario – the local Wiki client – and talk some about how the WinFS platform would simplify the development process.
At the core of FwSynch and WikidPad must be some sort of data engine. You’ve got a collection of distinct Wiki entities, and a web of keyword relationships between them. How do you persist them on the client? How do you track changes on the client and synchronize them with changes on the server? Will your storage architecture be performant — how long will it take to boot the app and display an entry? Will the performance scale as the number of entries end edits reaches the hundreds, or thousands? Is your storage format able to recover if a small portion of data becomes corrupted?
There are plenty of options for client storage today, of course. The simplest solution might be to store all the data in a big XML file. Maybe you’re more comfortable with relational DBs than with XML’s hierarchical storage concepts, so instead you redistribute a DB engine like MSDE or SleepyCat’s Berkeley DB. Maybe you’ve got the right skill set to build your own custom storage engine. Each of these has its own tradeoffs across development time, feature set, and performance characteristics.
But, no matter what you choose, you will end up spending development time on something that is, in all likelihood, not a competitive differentiator. If you were building a competitor to WikiPad, where would you focus your energy on creating a different and more valuable product – would it be in tuning the performance of the storage engine, or would it be in improving the UI, or editing experience, or adding new features? If you were building a competitor in the music player market, going up against iTunes, MusicMatch and WinAmp, etc, would your distinguishing features be around visualizations, skinning, and play list management, or would they be around storage optimizations?
I’d argue that for most desktop applications, performance of the storage engine is generally not a competitive advantage – you’re not going to sell users on switching to your software just because it’s 10% faster than the other guy. Performance can be a disadvantage, if you’re the slowest app in the pack, but the goal in that case is just to catch up to everyone else so that you can get the same check mark in the performance column as all your competitors.
There are, of course, some apps whose main value-add really is performance – if you’re building a client search app like X1, then it’s probably worth spending a lot of dev cycles to eke out a 10% perf gain over your competitors. But for apps that manage music, photos, or Wiki entries, I think the real-value add is in the features and user experience, not the perf. I’m looking forward to reading everyone’s opinions in the comments, but really, have you heard of anyone switching from Quicken to MS Money (or vice-versa) because checkbook register look-ups happen a few milliseconds faster?
So how does WinFS help out? It provides an integrated storage engine that’s built into the platform, and which has been tuned for client performance by a dedicated team of storage experts. It’s has a schema and data model that’s built specifically to store relationships between items. As a core part of the WinFX platform, you can expect there to be a good set of tools from Microsoft and others to help tune the performance to suit your particular application. And if your app has to synchronize with data from a server, WinFS is built from the schema on up to support the notion of efficient synchronization, and has an extensible provider model for communicating with whatever your server back-end may be.
All in all, less time spent on developing storage infrastructure, and more time spent on building the real value-add features of your next great application. This isn’t quite as exciting as the last two scenarios, since they really focused on adding those killer new features, but I’m hoping that a lot of people will indeed breathe a sigh of relief when there’s a decent storage engine in the Windows platform, and they can turn their focus to more important matters.