BookRiff Design Philosophy - part 1 | November 5th, 2009
For those who do not know, BookRiff is an online web application that gives you the ability to build a book in real-time using nearly any kind of content. You can then have it printed and shipped to your door.
To build a book you may upload pdfs, word docs, text files, or search and import web content, clone other peoples content or just write from scratch using a rich text editor.
To say there are several moving parts to give you this flexibility would be a huge understatement. When we began this project we were without certainty that it would even be possible to build this system. Three important concepts have been key in getting BookRiff to where it is today. Modularity, Agnosticism, and Simplicity.
Modularity
When you get the opportunity to use BookRiff you will hopefully think to yourself “hey, this is pretty simple”. Thats what we want you to think but in reality BookRiff is taking your content on a great journey to get it into the BookRiff system and give you an accurate preview on your screen. Example of what we must deal with when accepting a pdf file…
- check for fonts embedded
- check/strip DRM
- scrape out text for search indexing
- remove padding
- calculate number of pages the content takes up once in a riff
- calculate where in your Riff content shows up (and what page it starts on)
- modify table of contents and attributions with appropriate data
- generate preview-able images
- backup files
As you can see there are a lot of considerations. These vary slightly for each file format that we support, and is different again when dealing with web or written content. Keep in mind that we are offering a real-time experience so doing this all behind the scenes and allowing the user to focus on their creativity is key which can add more complexity. Our solution? Keep everything as modular as possible.
We have developed a state machine that takes each file through a series of steps that all perform very discreet, simple tasks. Each step does one thing and one thing only. This allows us to swap one tool out for another without affecting the rest of the system. For example, we could find a Jar that does a better job of bursting that the command line tool that we currently use.
Every step in our system expects something very specific and outputs something specific. Even the state machine as a whole can be (and has been) re-factored for a better architecture without too much effort.
