Attila's Den

We’ve just seen in the previous post Building Edito - Part 2 that we are following a 5-gated process to developing our app. By the way, the name popped-out later in the process, at the early stages I just called it iMarkdown. With most of the stages 1 & 2 well engaged, the big remaining task to get into stage 3 is to draw a list of features. Because Objective-C is object oriented, this list will likely turn into our main classes.
My method is the following:
1. get to a white board
2. start throwing ideas on it 3. second round: organize around one central idea
4. third round: time to introduce some logic into this mess. Which feature derives from which, essentially.

Now, this is the tricky part. When you’re done, make a clean representation of what you have, and distinguish between what is horizontal and vertical. Let me explain. Horizontal is everything that the user is going to interact with. Vertical is the “engine” of the software, ie. in our case the Markdown conversion, reading and writing to a specific format, the various libraries stored or called. In other words, the graph you will end up with is in two parts, where the first one (horizontal) gives a pretty good picture of the app UI, and the second (vertical) the built-in functionalities. The vertical part is easy here, we just want to convert ASCII to HTML following the Markdown syntax. The horizontal part, well, is depicted on the figure below.

On this pic we have everything we want and more. You can see that I’ve drawn an ellipsis on the features that we’re keeping for the version 1.0. That comes right after putting everything down on paper, and it’s the analysis of needs vs wants. On the graph, I’ve got all I want — and a potential customer may want or expect from such an app.
We could group everything as essentials and non-essentials, but that’s probably a bad calculation at this point. For instance, what would you do with an app that can just type, open and save documents? Hate it probably, or not use it more than once. What we’re set to achieve is an easy way to replace all the operations we’re doing in our favorite Markdown editor on our laptop or mainframe computer. We’re generally using it to produce HTML documents. Those generally contain links, images, and I’m constantly switching (at least I was, in the beginning) to a Markdown cheat sheet. All of that I want in my app. Then, I want to be able to send those documents. Let’s face it, iPad is not so cool to exchange documents, and iOs 4.2 is not solving that problem apparently (we would have been told otherwise). So, eMail gotta be a feature. In the end, I’m proposing to leave out (for now) what brings little (word count), complicates the operation (importing USER css) or just is impossible to support - I do not have time to spend checking the css files of users - and what I can’t implement in say 2-3 days. That includes syncing to other APIs, the spell check, and importing pictures.
This last one is a tricky one, as I’d like to be able to use pictures from my iPad library, and just include them naturally in the document. The best way to do it is probably to convert the picture to Base 64 and paste it in my document, but it’s going to look truly ugly, unless I find a way to make it magically disappear while being retained in the document. That’s actually going to influence our document format, this idea. Syncing to other systems was probably the toughest one to reject, as I know everyone wants these features. Yet, bear in mind I’ve got to learn Objective-C first, get to writing my own app, and get it accepted on the App Store, ie get through a full process loop, before I envisage to use some private APIs that may be tied to specific conditions…

All of that being done, I evaluate a ball figure of 2 months to get this thing up and running. I don’t have much more time, and since it’s not rocket science - I would do it in Java in a quarter to maybe half the time probably - this should be OK. The main difference with doing it in Java is that 1) I don’t know the language, although I now have a pretty good idea of what it looks like after browsing the first few chapters of reference books, and 2) I’ve got what appears to look like a solid, fully populated dev. environment.

Next part will be quick, it will just give references I used to learn Objective-C. Two weeks were good enough to grasp most of it…

Edit:

There are two important things I forgot, and that came afterwards. Well, in fact, 3.

1. there are some accessibility facilities in iOs now, so that a visually disabled could use the software. That comes at the price of a small effort, but since we’re aiming (and have achieved) at a clean, uncluttered interface, this should be possible. And give me a certain peace of mind;
2. producing PDFs… This does not look like an horizontal only task, and that’s why I dropped it originally, although I thought about it - and forgot about it. That’s the danger of splitting horizontal from vertical, you tend to forget some important things in the vertical domain to concentrate only on what the user will experience!
3. printing: this looked unreachable until iOs 4.2 was announced, but is not quite that out of reach now. I’ll definitely have a look into this for version 1.1 or 1.2, depending on the time it takes to implement and review the software.