I have spent one year working on TypograFix, adding little bits to the program every day, making it better and better. But now, I’m tempted to completely change the rules of the game by rewriting the application, employing a completely different strategy. Why? Because I’ve encountered a (fairly stupid) problem that I feel unable to solve with the current way of doing things.
Status Quo
Right now, TypograFix is a very powerful Html postprocessor, which turns ad-hoc HTML into something that can actually be published somewhere. I have published over 100 articles online using the system, and have fine-tuned it to the extent where it meets 99.99% of all my needs, with the extra 0.01% covered by hand-editing HTML or having to dig into the source code and changing things.
So far, the program does what it is supposed to do, but it has a few flaws:
- Inefficient design
Even though I have coded the program with the best practices in mind, the transformation script itself is one massive switch statement that goes through dozens of cases. The transformation function itself forms a kind of anti-pattern as far as programming goes, because its maintenance by someone other than me would be a nightmare.
- Lack of unit tests
When I started writing the program, I didn’t apply TDD. I know better now but, fact is, the transformer messes up sometimes. I have no integration tests, either, so I can’t say whether a new feature breaks old ones or not. I just hope that it doesn’t but, in reality, I’m not sure.
- Lack of consistency
Instead of going for the best language and framework available, I went with C# and WPF. This choice is dubious, mainly because I don’t really need WPF for such a simple UI. In fact, this application is emphatically not the type that one needs the power of WPF for. Also, C# is inefficient for graphics, which led me to add C++ code to the application at a later stage just so I could get faster rendering with Direct2D and support for OpenMP and the like.
- No support for uniform format
Turning HTML into HTML is just one of the many things that I need to do on a daily basis. But I seem to have failed to account for the possiblity of, say, publishing a book from the same materials.
The last point is particularly important because – guess what – I’m going to write a book! And, seeing how I have no intention whatsoever to use DocBook (don’t ask me why), I feel that I need to have a tool that is capable of producing both Html and, say, PDF or Word from a single source. Sounds neat, huh?
So What?
I’ve decided to make another version of TypograFix. This time, I intend to target not just the web (that’s easy, as practice indicates), but also the print medium. After all, producing nicely-made PDF documents is already a pretty good incentive, and seeing how Word isn’t up to the task (will it ever support the kern feature?), it might make sense to make something proprietary.
So what I’m thinking of is a structured document editor. The idea isn’t exactly new, but good execution is something of a rarity. Here’s what I’m thinking:
- Client-server architecture
- Fast, idiot-proof client (either RIA or ‘thick’)
- Really good tech choices—especially languages
- A thought-out architecture
Let the fun begin!