|
Thursday, February 02, 2006
Yours, Mine and Ours
For the last couple of years, I have been managing my weblog
with a desktop content management tool called CityDesk, made by Fog Creek
Software. This fine product has suited me very well. Most blogs serve their
content with a scripting language, dynamically generating pages from a database,
with all article editing taking place in a web browser. That approach doesn't
work so well for me. First of all, I prefer to serve my content as static
HTML. More importantly, I tend to write full-length articles, so I prefer to
write my content in something stronger than an HTML textarea.
So for me, CityDesk is a good piece of software. It has
templates and a basic scripting language and a simple built-in word processor
and tools to manage my links.
However, I stopped using CityDesk a couple of months ago
(Sorry Joel!). Sometime later in this article I intend to make some sort of a
point, but for now I want to tell the story of the tool I now use to manage my
weblog.
ESBMA
Like I said, CityDesk is great, but a few things about it
kept bugging me:
- CityDesk's built-in text editing facilities aren't quite strong
enough for me. I want to write my articles in a full-featured word
processor.
- CityDesk stores all content in a Jet database. I work at
SourceGear, a vendor of version control tools. I want my content stored
in a version control system.
So I decided to write my own content management tool. I
call it ESBMA, which stands for "Eric Sink's Blog Management App". (The astute
reader will realize now that this is not an article about how to choose cool
names for products.)
ESBMA is 8,469 lines of C# code designed to manage a weblog
exactly the way I want, including the following features:
- Static HTML output: When publishing my site, ESBMA
generates static HTML pages. Templates (based on the old "pages with
holes" concept) make it easy to change the general layout of the site.
- Integration with Microsoft Word: ESBMA has no
built-in facilities for editing articles. Instead, all my writing takes
place in Microsoft Word. When I double-click an article for editing, it
launches Word with the proper document open. When I publish my site, it
uses the scriptability features of Word to save each article as HTML.
Then it cleans that resulting HTML and processes it as necessary to
generate the pages of my weblog.
- Integration with SourceGear Vault: ESBMA stores
all my content under version control. Naturally, I used my own product.
Since the Vault client libraries are in C#, this was pretty simple.
- Management and pseudo-scripting: Like CityDesk,
ESBMA the ability to manage links (even when things move). It also has
very basic facilities for variables, loops and conditionals.
- Integration with Amazon: When I want to recommend
a book, ESBMA can use web services calls to retrieve information from
Amazon. It can automatically insert my Amazon Affiliate ID into product
links.
- Integration with Haloscan: For articles where I
want to allow comments, I can easily tell ESBMA to add Haloscan links at
the bottom of an item.
- CityDesk import: A utility program was used to
read all the content from my CityDesk file and convert everything to
ESBMA's formats, keeping all the paths the same.
- Easy publish: I click one button and type a
password and ESBMA uploads all new content to my web server. The
connection is tunneled through ssh for security.
For me, this is the best blogging tool in the world.
A different perspective
For anybody other than me, ESBMA is one of the worst pieces
of software ever written:
- ESBMA has no installer. It has never been run by anyone
but me. It has never been run outside the Visual Studio debugger. Every
time I want to work on my blog, I open ESBMA.sln and hit F5.
- ESBMA has no documentation. When I forget how to do
something, I look up the answer in the source code.
- Until quite recently, the only way to change the title of
an article was to exit the app and manually edit an XML file. One day I
got tired of doing that so I added a dialog box with a text field.
- The CityDesk importer isn't even close to being usable for
other people. It handles only the CityScript features that I needed and
ignores the rest. It has hard-coded stuff that doctors the imported
content in ways that make sense only for me.
- ESBMA publishes to my web server by invoking rsync
tunneled through ssh. Cygwin (with the rsync and ssh packages, of course)
must be installed, and it must be installed in a specific path, because
that path is hard-coded somewhere in the ESBMA source code.
- ESBMA communicates with Microsoft Office (just Word,
actually) in a couple of different ways. It requires Office 2003. It
will not work with any other word processor. It will not work with any
previous version of Microsoft Office. It will [almost certainly] not work
with any future version of Microsoft Office unless I change the code. Oh
yeah, and ESBMA crashes if the Primary Interop Assemblies for Word are not
installed.
- The same basic story applies for integration with Vault.
ESBMA works with Vault 3.1. It won't work with Vault 3.0 and it's not
gonna work with Vault 4.0 without extra effort. It doesn't work with any
other source control tool.
- ESBMA sometimes crashes when I delete an article. I'm not
sure why. I just don't worry about it.
- ESBMA supports HTML templates, but there is no built-in facility
for managing or editing them. When I want to tweak the template for my
site, I usually do something like this:
- Open a Cygwin bash shell
- cd /cygdrive/c/Documents and Settings/Eric Sink/Local
Settings/Application Data/ESBMA/working/wf_0
- vi template.html
- Oh, and ESBMA doesn't create a default template. When I
create a new site, I have to manually create template.html in the right
place. If I don't, ESBMA will crash.
- When ESBMA is performing a long operation, it doesn't show
a progress bar. Or a wait cursor. It doesn't even repaint the window.
Until the operation is done, the app looks like it is hung.
So ESBMA has lots of problems, but they don't really bother
me very much. Every once in a while I fix a bug. Mostly I just avoid them,
since I know where they all are.
Actually, this is my third attempt to write my own blogging
tool. The first two attempts failed because I took the time to consider the
needs of other people. Instead of building the perfect tool just for ME, I got
distracted thinking about how I could turn my blogging tool into a business
venture.
This time I succeeded. I built a blogging tool which works
perfectly for me. It won't work for anybody else. For other people, it is not
merely "user unfriendly", it is "user hostile".
My blogging tool is an example of "MeWare".
Yours, Mine and Ours
I claim here that there are three categories of software:
- MeWare: The developer creates software. The
developer uses it. Nobody else does.
- ThemWare: The developer creates software. Other
people use it. The developer does not.
- UsWare: The developer creates software. Other
people use it. The developer uses it too.
For completeness, I suppose I should probably mention the
obvious fourth category:
- NobodyWare: The developer creates software.
Nobody uses it.
Coming up with examples of NobodyWare will be left as an
exercise for the reader. :-)
Observations about ESBMA and CityDesk
As I said, ESBMA is an example of MeWare. I wrote it "just
for me". I have no other users, therefore I have none of the challenges which
arise when developing software for other people.
I consider the concept of MeWare to be somewhat new. Simply
put, MeWare happens today because today's developer tools are so amazing. I
would never have written ESBMA if I had to do it in C against the Win32 API.
Software development is really expensive. Typically, the
costs of developing software are recovered by convincing lots of people to use
it and collecting money from [or through] those users [directly or indirectly].
When software is developed for a single user, the opportunities to recover the
development costs are dramatically reduced.
So MeWare only makes sense when the development costs are
very low. I was able to create ESBMA for myself because coding with C# and
Visual Studio is an extremely productive experience.
In contrast to ESBMA, its predecessor CityDesk is an example
of UsWare. CityDesk is a shrinkwrap product of Fog Creek. It was developed by
Joel Spolsky. He uses it to maintain his website. Other people use it too.
To any objective eye, the difference between CityDesk and
ESBMA is obvious. CityDesk is polished and easy to use. ESBMA is user
hostile, sometimes gratuitously so.
At this point some reader who is familiar with CityDesk is
screaming, "Wait! You can't use CityDesk as an example of a good
product. CityDesk is a failed product. Joel hasn't released a new
version in 42 years and he never responds to questions about it anymore!"
OK, fine. Joel himself seems to admit that CityDesk hasn't
been the big seller he hoped it might be. However, the success or failure of
CityDesk isn't relevant to my point.
Which reminds me, I promised you I would make a point,
didn't I? OK, here it is:
The
gap between developer and user can be enormous.
It's a canyon, and it takes serious effort to cross it.
If in fact CityDesk is to be considered an unsuccessful
product, I claim that its failure is an issue of marketing, not an issue of
product quality. People who use CityDesk love it. It is elegant and extremely
easy to use. I daresay it is the leading application in its market niche. The
problem is that there just aren't very many people in that niche. In the world
of content management, the war between Web-based solutions and thick clients is
over -- the Web apps won. There just aren't many people like me who want a
single user desktop content management system that generates static HTML.
In other words, CityDesk did a great job crossing the
canyon, only to find out that there weren't very many people standing over
there.
Consider what would happen if I decided to take ESBMA up to
the next level, across the canyon, from MeWare to UsWare. I would have to make
it work as well for other people as it works for me. I would have to fix all
the problems described above, plus dozens more I didn't even mention. Off the
cuff, I estimate that an UsWare version of my blogging app would be ten times
more effort than the MeWare version I have now.
And of course, it would be marketing suicide, since I would
be competing with the well established CityDesk for the affections of the six
remaining people on earth who care about apps like this.
It's All about the Users
So let's face it -- MeWare isn't actually very interesting.
Aside from the occasional outlier like myself, nobody is developing MeWare.
All of us are developing software on behalf of other people. Whether your
software is commercial or open source, it's all about the users.
Why do we develop software for other people? Because they
need software, and they are not developing it for themselves, for only two
reasons I can think of:
- They don't develop their own software because they simply
don't know how.
- They don't develop their own software because they are too
busy doing other things.
In either case, the users are expecting us to create
software on their behalf. They expect us to see things from their perspective,
to value the things that they think are important.
This is hard.
The Challenges of ThemWare
The detachment between developer and user is greatest in the
case of ThemWare. I create software. Somebody else uses it. I do not.
This creates three challenges that I want to highlight:
1. Maybe I don't even know how to use my software.
In this situation, I work all day creating dialog boxes and
toolbars, but I don't actually know what to do with them.
Several years ago I worked as a developer of data
visualization tools for scientists. Our software could take data and create
pretty pictures like contour plots and line graphs and colorized grids. I took
physics and chemistry in college, but that doesn't make me a scientist. I
really never knew how to use the software I was developing. I could tell you
the arcane details of how our macro language worked, but I couldn't tell you
what a Fast Fourier Transform is. I still can't. So I could never make our
software do anything interesting, but our customers could make amazing pictures
with it.
2. Maybe I don't understand the people who use my software.
The people who use my software are not like me. They're in
another field. I'm a software programmer, but those people were trained in
auto mechanics or interior decorating or dentistry. I don't know how they see
the world. Understanding their perspective doesn't come naturally for me at
all.
I can illustrate this situation with a real-life example
that I face quite regularly. The SourceGear web site has a "store" which
allows our customers to purchase licenses for our products. This store is a
piece of software, and I am the developer responsible for it. However, I never
actually use it. Obviously I never buy a copy of my own software. (I was
tempted to once. It was the last day of the month and our sales were about a
hundred bucks shy of our monthly goal. I was so tempted to whip out my
credit card and place an order for one copy of Vault.)
Anyway, this store is ThemWare, and I don't think I
understand Them. We sell our products to developers, and I understand
developers just fine. But many companies funnel all purchasing through a
department which is dedicated to that purpose. Apparently there is some sort
of impedance mismatch between me and the folks in those purchasing departments,
because people keep coming to our store and buying the wrong thing.
One of our products is called SourceOffSite. The current
version is 4.1, but we do still continue to sell the 3.5 version for people who
prefer not to upgrade. (Starting with version 4.0, the SourceOffSite requires
the .NET Framework, and not everybody wants to install it.) Anyway, version
4.1 and version 3.5 require different kind of serial numbers. When you come to
our store, it's important that you buy the correct version.
So the store tries very hard explain the situation. The
information is at the top of the order form. In red. After you fill out the
order form, you are reminded again, just to be sure.
But so far, the canyon between me and Them still looks big.
We get email basically every day from somebody who just bought SourceOffSite
and then discovered that their newly purchased 4.1 serial number will not work
with their 3.5 server. It is only a slight exaggeration to say that everybody
who comes to buy 3.5 licenses does it wrong.
My next version of the SourceGear store needs to have an
additional verification step for people in purchasing departments who are
trying to buy SourceOffSite. When the purchaser places an order for
SourceOffSite, they will see a message like this:
Please
go ask the developer to confirm which version they want.
To
prove that you actually spoke with a developer, ask them for the answer to the
following question:
.
"Virtual memory" is:
1.
An upcoming technology for
recording TV shows
2.
A feature of your computer
3. A piece of jargon from Star Trek
3. Maybe I don't even like the people who use my software.
There are six billion people on the planet. I can't be
expected to be fond of all of them.
I am one of the few software developers in central Illinois who does not work for State Farm Insurance. State Farm is one of the largest
insurance companies in the world. Their headquarters is in Bloomington, just
an hour or so down the road from us here in Champaign.
The sheer size of State Farm is simply amazing. This
company is monstrous, like the Borg from Star Trek, assimilating every IT
resource in the area. They employ thousands upon thousands of programmers, all
of whom are busily working on software which will be distributed to countless
insurance agent drones scattered all over the nation.
Even though Bloomington is a small city of perhaps 100,000
people, Microsoft has an office in Bloomington because State Farm is their largest
non-government customer.
I can't imagine working at State Farm. I don't even like
insurance agents. Every day I would go to the office and build software to
help insurance agents be more efficient in their ongoing efforts to annoy me.
The temptation for sabotage would be overwhelming.
The Consequences of ThemWare
In terms of the size of the canyon, ThemWare is probably the
worst possible scenario. If I am building software that I don't use and don't
know how to use for people I don't understand or even like, how good is
my software going to be?
I probably see every feature in terms of how difficult it
will be to implement, rather than how valuable it will be for my users.
I probably find myself wanting to label or document the
features using my jargon instead of theirs.
I probably create features that are tedious or unintuitive
for my users. I can't imagine why the user interface I designed doesn't make
sense to them.
ThemWare is hard.
The Challenges of UsWare
The situation with UsWare isn't quite as bad. I create
software. Other people use it. So do I.
Unlike the situation with ThemWare, I as a developer
actually have at least one thing in common with my users: We both use my
software. This suggests that we probably have even more things in common.
Perhaps we can even understand each other.
The Best Dogfooding Story Ever
The common expression for using your own software is "eating
your own dogfood". Sometimes this term gets verbed by simply calling it
"dogfooding".
If you'll indulge me briefly, I'd like to tell you what I
think is the best dogfooding story ever. However, it's not a software story.
It's a woodworking story.
The primary machine tool in any well-equipped woodshop is a
table saw. Basically, it's a polished cast iron table with a slot through
which protrudes a circular saw blade, ten inches in diameter. Wood is cut by
sliding it across the table into the spinning blade.
A table saw is an extremely dangerous tool. My saw can cut
a 2-inch thick piece of hard maple with no effort at all. Frankly, it's a tool
which should only be used by someone who is a little bit afraid of it. It
should be obvious what would happen if a finger ever came in contact with the
spinning blade. Over 3,000 people each year lose a finger in an accident with
a table saw.
A guy named Stephen Gass has come up with an amazing
solution to this problem. He is a woodworker, but he also has a PhD in
physics. His technology is called Sawstop.
It consists of two basic inventions:
- He has a sensor which can detect the difference in
capacitance between a finger and a piece of wood.
- He has a way to stop a spinning table saw blade within
1/100 of a second, less than a quarter turn of rotation.
The videos of this product are amazing. Slide a piece of
wood into the spinning blade, and it cuts the board just like it should. Slide
a hot dog into the spinning blade, and it stops instantly, leaving the
frankfurter with nothing more than a nick.
Here's the spooky part: Stephen Gass tested his product on
his own finger! This is a guy who really wanted to close the distance between
him and his customers. No matter how much I believed in my product, I think I
would find it incredibly difficult to stick my finger in a spinning table saw
blade. Unbelievable!
Back to the problems with UsWare...
I think dogfooding is one of the most important things a
developer can do. Nothing gets you closer to the perspective of your users
than becoming one of them. But UsWare still has challenges. Your users are
still probably not exactly like you.
Recently, this very issue has been discussed
with respect to Microsoft's dogfooding of Team System. People wonder if Microsoft
is going to end up creating a set of developer tools that are useful only for
software companies. This is a valid concern. There are far more companies out
there that produce software simply as a means toward producing something else,
like jets or laundry detergent. Those companies probably don't work exactly
the way software companies do.
SourceGear DiffMerge
With UsWare, there is a tendency to get stuck in the
following path of logic:
- I use the software.
- I understand it.
- So everyone else understands it too, right?
I have this problem with the SourceGear DiffMerge tool that
comes bundled with Vault. This app can be used to help perform a three-way merge.
The basic operation is fairly complex, so the tool needs to do a great job
presenting a user interface which is easy to understand. Apparently, it does
not.
I helped designed the tool, so it always makes perfect sense
to me. So, when users have trouble understanding it, I have a tendency to
suddenly become Basil Fawlty, the rude
English hotel manager played by John Cleese:
User: I don't get it.
Basil Fawlty: It's
perfectly simple. There are three files being displayed on your screen and we
shouldn't have to label which one is which because it seems perfectly obvious
to us and so it is not the software which is defective here but rather, its
user. Thank you so much, good day.
Unfortunately, very shortly after this happened the first
time, one of SourceGear's developers walked into my office:
SourceGear Developer: Hey
Eric, you know that DiffMerge tool we ship? I don't get it.
Basil Fawlty: Right! Apparently
I'm the one who is defective here then. Manuel!
It is more or less impossible for me to design a user
interface that I don't understand, but it is all too simple for me to design
one that other people don't understand.
Rant: Flagged messages in Mozilla Thunderbird
Another problem with UsWare is the case where I the
developer design and optimize features for the way I use them, forgetting the
my users might be using them differently. For an example of this, I'm going to
switch places and cite a case where I am the user.
My favorite email client is Mozilla Thunderbird. I like it
very much, except I wish that flagged messages would work the way they do in
Outlook. Every time I see a new release, I have high hopes that flagged
messages will finally work the way I expect. Last week I upgraded to the new 1.5
release, and once again, I was disappointed. Thunderbird supports flags, but
it cannot search for flagged messages or filter views with flag as one of the
criteria.
Bottom line: Thunderbird has flags, but they seem to be
mostly for show. They look nice, but they aren't very useful.
I assume that Thunderbird is UsWare. In other words, I
assume that all Thunderbird developers actually use Thunderbird as their mail
client. I am forced to conclude that the Thunderbird developers just don't use
flags the way I do.
My Blindspot about Visual Studio integration with Vault
Let me tell you about another UsWare problem we've
experienced at SourceGear. First, a little background:
Oversimplifying, there are basically two ways to use a
version control system. You can use a standalone application, or, you can
integrate the features directly into the Visual Studio IDE.
Here's the problem:
 
You see, I hate using source control integration
within Visual Studio. Our product does include this feature, but I never use
it. In fact, right now most of the people at SourceGear don't use it.
However, a clear majority of our customers do. This little canyon causes
problems.
Sometime in the last year or so, the painfully obvious truth
hit me like a ton of bricks: Our users want integration. We have always
explained things to our customers somewhat like this:
- Our standalone client application is the primary way to
access the Vault server.
- Our Visual Studio integration client is available, but it offers
fewer features and somewhat lower performance.
But this is exactly the opposite of what they want. Most
people don't want a standalone source control application. Some of our
customers have never even launched it. They just want source control features
to show up in all the right places in their IDE. The key thing to notice is
that IDE stands for Integrated Development Environment.
If you are reading this and wondering how I could miss
something so obvious, then perhaps I have convinced you how easy it is to find
a canyon between you and your users.
Here at SourceGear, most of us are software developers, and
we use Visual Studio. We build version control tools for software developers,
most of whom are using Visual Studio. Obviously, we eat our own dogfood by
using our own product as our version control system for the entire team. Nobody
could possibly be more similar to their customers than we are, right? :-)
I have known all along that most of our users want
integration. But I guess I never let it really sink in. Sometimes my thoughts
about our product strategy have been better aligned with the way I use the
product, rather than with the way our customers use it.
Anyway, integration is getting a lot more air time among the
developers at SourceGear. On several occasions, we have changed our plans to
allow us to give a higher priority to integration. We are trying to cross the
canyon between us and people who only use our product within Visual Studio, and
other IDEs as well:
- Several months ago we released a very early preview of an
Eclipse plugin for Vault. Work on this project is continuing and will be
available later this year.
- On January 30th, we released the first preview
of support for integration with Dreamweaver.
- Vault 4.0 will include an all new Visual Studio
integration client for use with Visual Studio 2005.
We get it. A lot of our attention right now is being spent
trying to make sure that people can enjoyably use Vault in the IDE they prefer.
And by the way, once we get the new Visual Studio
integration client working, I will be using it. :-)
Meeting these Challenges
So ThemWare is hard is because our users are nothing like
us.
And UsWare is hard because we keep assuming our users are
exactly like us when they're not.
This is the point in the article when you are expecting me
to suddenly reveal a pearl of great wisdom on how to solve these canyon
problems.
Sorry, but our time is up. :-)
You see, this article is the essay version of a talk I am
presenting to the Jacksonville .NET User Group.
Right about now is the point where I will be out of time. If I had left time
for a really good answer to this problem then I wouldn't have had time to for
my John Cleese imitation, which I can assure you was far more effective in
person than it was in print.
However, although I can't offer give a good answer to
this problem, I have just enough time for something flippant and trite:
Listen to your users
And be transparent. Let
yourself be accountable for listening to your users. The main reason
SourceGear did a Dreamweaver plugin is because we have a public support forum
where dozens of people asked
us to do one. This is one of our most common feature requests. How could we
ignore them?
Your users have things to say. Stop telling them how great
your software is and listen to them tell you how to make it better.
| 
