This is a continuation of the previous article, where I outlined the features that I wanted to see in the pacing and flow window. In this post, I will summarize the stages of implementation for this feature in the order that I completed them.

TRW Edit is a Windows Presentation Foundation (WPF) application. The predominate design pattern used in the application is Model-View-ViewModel (MVVM). All application logic is written in C#, using Visual Studio as the Integrated Development Environment (IDE). I used all of these tools to build and test my application’s new features.

Why this set of tools? This is what I use predominantly at work. I’ve used the Qt UI framework and C++ there too, but I prefer C#/WPF/MVVM for most applications unless there’s a constraint that makes this combination not suitable for the task at hand.

Step 1: The absolute minimum

Indeed, it will…

The first step is always to get the most basic functionality done. In this application, that means creating a new window and wiring it up to the rest of the application so I can push the appropriate button and see the container that I’ll be working with.

I do this because the tools I will be using to build this UI favor rapid iteration. Technically, there’s nothing stopping me from designing the architecture first and then implementing it but this is a personal project where spending time rewriting large sections of the codebase is more fun than sitting down and thinking things through.

My personal projects are places where I try out methodologies and design approaches that I wouldn’t be able to use at work due to needing to make products that the company can sell in a timely fashion so I can keep getting paychecks.

Step 2: Implement essential UI features

Now that the basic class structure is in place, it is time to implement the foundation level features of the window:

  1. Select and add books to be displayed
  2. Make space in the UI for these books to be displayed. Worry about appearance later.
  3. The UI must be able to fit into a container that’s too small for it.

Point #1 covers the essential user interactions. Point #2 covers the reaction to what the user does. Point #3 makes sure that the reaction is something that can actually be used, as opposed to not being usable at all.

All three of those points are essential for any user facing application. If there is nothing to do then what is the point of having an application at all? Likewise, what’s the point of the application if I can’t do anything with it? Finally, I can get the job done with a poorly designed application, but I will hate every second that I put into fighting it.

Put all three of those points together in the first stage of the prototype so you don’t have to shoehorn them in later.

Select book and press button. The book shows up in the UI. Multiple times, even.
Scrolling works correctly

On a side note, scrolling is so important that I put extra time in at the beginning to get that one part of the UI right. I didn’t say that I wasn’t going to plan anything at all, after all. Seasoned WPF users will know that there are many ways to lay out a UI that completely break when the user wants to change the size of a window.

Step 3: Refine basic functionality

Now that the most essential functionality is implemented an tested, it is time to turn the UI into something that is actually usable. Right now, my display of a book is nothing more than a rectangle with some text in it. It’s time to turn that into something useful.

What I do in this step is focus on nothing but that little rectangle. I turn that rectangle into a full WPF UserControl, then focus on implementing everything that goes in it to the exclusion of all else. My goal this whole time is to keep as little knowledge of the project in my head as possible. Don’t worry about the overall architecture. Don’t worry about what colors I’m going to use later. Just complete the one task at hand and keep moving on to the next until they are all finished.

Good scrolling behavior is important because one of the basic features of the pacing window is that it displays ” books, chapters, and scenes proportionally, according to their word count”. That means I need a way of specifying just how much space each section takes up on the screen. Let’s try 1000 words per inch and see what happens. That’s a lot of words per inch, right?

1000 words per inch isn’t all that much, when you think about it

A typical sci-fi/fantasy novel is at least 85,000 words. You would need an awfully big TV to display all of that. How about we make the words per inch configurable?

Now the size is configurable

Now I, the user, can specify exactly how large I want the UI to be. This is way better. At this point, all the essential features of the UI are in place. I can view a book and see how the chapters and scenes are laid out proportionally, which makes estimating story flow much easier.

On a technical note, when I say “words per inch”, I really mean it. It takes almost no effort to specify how large a part of the UI should be in inches in WPF. The reason for that is because WPF uses “device independent units” for measuring distances. 96 units corresponds to one inch. In theory, that means that this will be rendered the same size on every possible screen. In practice, it won’t be quite that precise.

Step 4: Add advanced functionality

The advanced functionality here is the ability to see how story characters and words are being used. This sounds like a daunting task, but in reality it only took a few hours to implement. The reason why is because 90% of the work for these features is done already. I just wrote the code for displaying scenes. I’ve had basic search engine capability in the editor for a while now. All I had to do was put the few features together with a little bit of code to make it all work.

All I had to do was completely rewrite the application logic for the window. That turned my 10% of effort into at least 25% of effort. If only I planned this out ahead of time! Oh well. Like I said, this is a personal project where I play fast and loose with the rules because money isn’t on the line.

Where do all the characters I’ve written for the story show up in the story itself?

Red areas mark where a character is physically present in a scene

I can see just from looking at this that the story is broken up into four parts, just by seeing which characters are present where. There are 6, 6, 5, and 6 chapter sections which looks really balanced. The last section has much bigger chapters though, so it takes up more space. Some chapters haven’t been completed yet.

How often is the main character referenced by last name vs when he is actually present in a scene? How about that item he always carries around with him?

The redder an area is, the more occurrences of that thing.

The color scale is per line only, for now. The main character is mentioned in some way even in scenes when he is not present. That item gets talked about a lot right in the middle of the book, and sees more mentions in the later sections of the book than the beginning.

Other fun facts I’ve learned:

  • Numbers are only used once in the entire book. (It’s the number 30).
  • The letter ‘q’ has the most irregular usage, followed by ‘z’, ‘x’, and ‘j’. This makes sense because these letters are the least used ones in the English language.
  • I use the letter ‘z’ the most in the chapter where there are only two specific characters talking to each other.

Conclusions:

I convinced my client (who is me) that he didn’t really need all the custom color settings, responsive UI, and links to scenes for reviewing. My client just automatically accepts everything that I tell him without question, which is either very good or very bad depending on your experience level.

He does gain a lot of tools for analyzing drafts in a way that I couldn’t find in any other product in about 15 seconds of google searching. I get a fun project to work on and something to write about on the blog.