Developing software costs money so it's important to make sure everyone on your team is moving towards a clear, shared goal to avoid wasted effort. There are many approaches to achieving your goal, and over the course of the last 20 years the software industry has seen them all.

Having spent a year researching Agile development (Scrum), followed by a year using it, I've seen the results of this approach first hand. In short, when you couple experience with a simple approach to estimation and tracking and add a capable Scrum master to manage impediments, your chances of successfully guiding a team to a goal, on schedule are very good.

You may have noticed the word 'experience' above is emphasized. This is very deliberate because this is where agile development (and Scrum) breaks down, and this is why agile can be the wrong choice when developing certain types of iPhone apps.

So what is it about certain types of iPhone apps (and a certain level of experience) that makes Agile the wrong choice?

Two things.

1. Often the goal of your team will be to add some magic to your iPhone app. This might be a 60 fps Doom renderer. Even with a well written spec, the actual final details of this magic may be unknown until well into the project. This may be because without prior experience writing an app just like the one you're working on, research is required. The results of research (and time required) are very, very difficult to estimate.

2. Some types of software development (like server side development) generally consist of well defined goals. The server receives A, stores B and returns C. An experienced developer can take this spec and provide a good task break down with estimates that will likely hold true. With most of the iPhone apps we've worked on, the same type of spec is usually present, with one added requirement. Quality. Achieving the required quality level usually means iterating over a project until a general consensus deems the app at a quality level ready for launch.

Point 2 could mean putting a beta in the hands of a sample audience and then responding to comments and requests that could dramatically increase the quality of you app. This is also very difficult to estimate and could mean a significant re-write if the quality of your app is of the utmost importance. 

Having said all of this, it is possible to use Agile to a high degree, when developing high quality iPhone apps.  For 3D Bookshelf, we identified the areas requiring research and scheduled them up front. This takes point 1 out of the equation. We accepted that we would spend a certain amount of time researching our options. This involved the production of a proof of concept prototype. We didn't know how long this would take. To keep things real, we did put a limit on the amount of time we could invest in this stage of the project. In the end, we got through it much quicker than anticipated, but we couldn't have known that in advance. With that out of the way, most of the rest of the project became very straight-forward to estimate and schedule.

Agile developers reading this are probably thinking, hold on, if you've put a time limit on the research task, surely this fits with Agile or Scrum. The answer is no. The results at the end of this stage could have an explosive effect on the rest of the project. For example, we could have tried to produce 3d Model content for the 3D Book system (and a lot of it) before we found out that it was much much simpler to produce a real-time engine to create the 3D Books. That's potentially a lot of wasted effort both in terms of management and content production.

There are other aspects to this project that were inherently suited to Agile development. These included the Twitter competition service, the web site and preparation of most of the content and tool updates.

The last few weeks were set aside for polish. That's where we are right now. We've said goodbye to schedules. That takes care of point 2. We're no longer trying to track this using Agile techniques. We know we're close to the end of the project. We know we can get to a quality level we'll be happy to release at. When will that be? We don't know yet.

Again, to be realistic we have set a limit to this. We can't throw infinite time at the project and expect to make any kind of financial return.  All I can say is we'll release between now and that cut-off date.

We've successfully applied the approach above before, to a previous iPhone project (a custom app for a high profile UK artist). Based on some initial research we produced a sprint task breakdown that came to 120 man hours. These tasks were completed in 131 man hours, only 11 hours over the estimate. Not bad considering the research involved (an advanced OpenGL renderer) and change requests. In the end we added a further 20 hours of polish at the request of our client. At all points in the project we had a good clear understanding of where we were in terms of the overall schedule.

Conclusion

Agile software development becomes quite powerful when it is coupled with experience and familiarity with the project domain. This is the guide we use for deciding when, and when not to use it.

Check back soon for more. Or, you can sign up to my RSS feed or follow me on twitter for updates!

When I started the web site for 3D Bookshelf, we had already decided on the graphical theme for the app. I had just completed the high-res icon PSD in Photoshop CS 4 along with all of the book covers, so I had a lot of content to play with. The first step was to plan the layout and determine what bits were going to be dynamic. Once this was done, I started setting things up in Photoshop using 960.gs.

960.gs

Web development can be a lot of fun, but it can be incredibly frustrating, especially when you come face to face with the harsh reality that is browser compatibility (or the lack of it). Things have gotten better over the years, but bugs and inconsistencies pop up from time to time. When it comes to setting up layouts that I know will work everywhere (I hope), I tend to use 960.gs. My technical lead (thanks Franklin!) at a previous job introduced me to 960.gs and I've been using it ever since.

The makers of 960.gs provide a PSD template (along with templates for other tools) with guides so you can design your site cleanly in Photoshop and then extract the pixel perfect sections which slot nicely into the html layout.

Below is a section of the 3D Bookshelf site with the guides visible, along with the markup to position the 'Features' text.

<div class="features">
                
   <div class="grid_4 prefix_11">
      <h1>Features</h1>
      <p>Leaf through each ...</p>
   </div>
                
   <div class="clear">
</div>

In the markup above you can see I'm enclosing the Features text inside a div with a class set to "grid_4 prefix_11". This means the text will be displayed on the 12th column and the content will span 4 columns. In total there are 16 columns in this particular layout. The background image is applied using the features css class.

Adding Dynamic Content

Various sections of the site are replaceable. For example, the 'Coming Soon!' banner will be turned off and the "Available on the App Store" will be turned on as soon as 3D Bookshelf goes live. In addition to this, there are two videos intended to be available on the site, and these will be played using jqvideobox_1.00, a JQuery plugin. JQuery is a remarkable javascript library. If you're doing web development, don't leave home without it.

We're also hoping to run a small competition once the app has been released and the competition rules are displayed using FancyBox, another JQuery plugin. The competition itself will be managed by a simple twitter competition service we'll host on our own VPS. There are hooks in the 3D Bookshelf site to query the competition service for the number of participants so far, along with a list of latest participants (and their twitter icons). Twitter competitions seem to be all the rage at the moment.

Screenshots

As we get closer to launch, we'll release more screenshots on the site. We've only got one up there at the moment, the splash screen.

As always you can find out more about updates to the above as and when they happen by following me on twitter or subscribing to my RSS feed.

3D Bookshelf is our second independent app for iPhone and iPod touch. When we started the project, we made a very conscious decision to spend a lot of time getting the look of the app just right and that includes the icon.

Although both myself and Kevin started out as animators and graphics artists, producing games in our early teens, we've pretty much focused on writing code for the last 14 years. So, we've had to re-learn a lot of the design trends and also the current tools, such as Photoshop CS 4 and Blender.

We brought all of this to bear on 3D Bookshelf. Aside from the book texts, the content production for the app can be broken down in to four categories.

1. 3D Content

As I mentioned in an earlier post, after some initial experimentation, we chose to write a real-time 3D book engine to generate the 3D book mesh so this meant we had no 3D content requirements specifically for the books. In the end, we only required one 3D model to be produced, the 3D bookshelf itself. This 3D model was produced in Blender and exported using our UtopiaGL exporter. The bookshelf model appears on the main menu screen where you can choose a book to read from the bookshelf.

2. Textures

Each book has a book cover texture. These were produced with Photoshop CS 4. In addition to this, the bookshelf model required a wood texture. This was generated using Filter Forge and post processed in Photoshop. You can see a selection of some of the front covers below.

3. Presentation Graphics

Since the central image in the application is a bookshelf, we decided to go with a wooden theme for the app. As I'm sure you know, this is not unusual for iPhone apps. All backgrounds, including the splash screen, were produced using a wooden background. Again, these were produced with Photoshop and Filter Forge.

4. Icon

For the icon we continued with the wooden theme. But the focus here is on a 3D book image. This was produced entirely in Photoshop using shapes, gradients and effects. The icon was modeled at 1024x1024 and it has quite a bit of nice detail up close. It also scales down to 57x57 very nicely. Below, you can see two sections of the icon up close. When this is reduced to 57x57 all of this detail disappears. But it can still be used for other promotional requirements, such as the web page and Google ads, for example.

As I mentioned before, we're currently adding polish to the app so things may change. It's an exciting time and although we want to get the app out, we're determined to keep the quality level as high as we can get it.

We're currently adding polish to 3D Bookshelf for iPhone and iPod touch before we submit to the App Store. 3D Bookshelf is a 3D eBook reader. From what we can tell, it looks like it's the worlds first proper 3D eBook reader application. Hopefully we'll be in review soon.

As with all our apps, we began with a proof of concept prototype. After Kevin had researched the typography requirements and identified the memory budgets, I began prototyping the 3D book engine. The design we put together required us to have a 3D book model that could be opened and closed to a specific page. The design also required a page-turn animation (left to right and right to left). In addition to this we wanted the book model to be resizable, so that we could change the dimensions of the cover, pages and depth (the number of pages).

I started by using Blender to model up some key frames of a book opening and closing along with page-turns. It quickly became obvious that we would need an enormous amount of content if we wanted to be able to reflect the exact page a user was looking at (in 3D) without sacrificing quality. So after 7 hours spent with Blender trying different approaches, I decided instead to write a real-time engine to build the entire book in 3D including page-turns.

This approach offers a number of benefits. First, the code builds the 3D model in real-time so (excluding textures) there is no content requirement except for the parameters for each book. The parameters to the system include the width and height of the book, the number of pages, the current page, how open the book is and some others regarding how the page-turn can happen. Second, since it's real-time we can vary all of these parameters at the same time or individually. For example, we can have a page turning as the book is opening and so on.

There are two constraints that the 3D real-time book engine must enforce to guarantee a coherent simulation.

1. The width of a page cannot change. It must be constrained to remain consistent during a page-turn. The page width must also be constrained when the book is fully open (regardless of the bend in the page) and it must be constrained when the book is fully closed (which is the easy bit).
2. The depth of the book (based on the number of pages in the book) must remain constant regardless of how open or closed the book is. Again, when the book is closed this is simple to enforce, but when the book is open and there is a bend in the paper it becomes more complex.

The constraints distill down to a simple quadratic equation which I converted to C# and then further optimized. I initially implemented the prototype with C# using WPF (Java would have worked just as well). I find it much easier to test and optimize mathematical algorithms in C# with unit tests at a high level, and then when I'm satisfied, I port to C++ and possibly make further tweaks. When we were happy, Kevin and I ported the lot to C++.

The 3D book engine prototype took just over 10 hours to write. I'll be releasing a behind the scenes screencast showing the prototype in operation in a follow-on post, so check back soon.

While I was working on the 3D book engine, Kevin was knee deep in the typography system in addition to getting the 3D book renderer ready. You can find out more about how he got on over at his blog. In my next post I'll talk about taking off my developer hat and putting on my designer hat to produce the graphics for the app, along with the website. Please subscribe to my RSS feed or follow me on twitter for updates.

Yesterday we announced 3D Bookshelf, our new application for iPhone and iPod touch. 3D Bookshelf features fifteen time-honored books, each brought to life with our new 3D eBook engine, built on top of UtopiaGL.

We are currently putting the finishing touches to the app. We will be updating the 3D Bookshelf site with screenshots and videos over the coming weeks.

All updates will be announced at http://www.twitter.com/idealbinary so follow us to keep up to date!