App Challenge Episode 2: Attack of the Feature Creeps

I demoed the current version of TouchCase to an attorney this week and received valuable feedback. While looking at how the tool would fit into his current workflow, we compared it to the software that he was currently using, a web-based application. He showed many of the functions that he could perform using his current tool of choice. The session was eye-opening to say the least. Watching him work, I realized the beta missed the mark in a major way. As a result of the session, I came away with the following assessment for TouchCase:

  • It was missing essential data
  • It was missing key workflow elements
  • The TouchCase feature set was smaller

In light of this, my options included:  logging the feedback as stories in the icebox and continuing as planned or moving the suggested changes into the current sprint, pushing week 3 sprint work into week 4. Choosing the former would go a long way towards making TouchCase relevant to more users, even in beta, while choosing the latter would keep things moving along my previous plans. Questioning my choices in the context of agile development allowed me to make what I believed to be the best decision. The true goal of the App Challenge is not just to create 3 apps, but to deliver first versions that are viable. It was clear from my observations that my app wasn’t even minimally viable. I spent the week adding the missing data and updating the UX to more improve the workflow. I stopped short of updating the feature set. A product doesn’t necessarily have to do everything a competing product does.

I also made progress in improving the UI, thanks to some wonderful resources. Using elements from templates at App Design Vault and the UIAppearance protocol, I added some polish to the interface and support for easier subsequent changes. I should also apologize for my prior comments about homemade soap being ugly. Homemade soap looks much better now than what I remember from my grandma’s house.

Current Status (Week 3)

Sprint 3 work for PomoTracker/Haggler will commence this week (now Sprint 4). I haven’t abandoned hope of getting an MVP for all three apps yet (it’s the halfway point), but it looks like Haggler will most likely not get the UI love in its first beta.

After attending Rob Napier’s CoreText and Practical Security sessions at CocoaConf DC, I picked up a copy of iOS 6: Pushing the Limits. It has been a great resource for implementing the Rich Text features of UIKit and augmenting the information from each session.

On the BDD front, I found a great video of Sandi Metz talking about the design of  tests. It has helped guide me in creating more effective tests (i.e. fewer and in the right places).

Nomadism

I’ll be back at Greenville Cocoaheads for the monthly meetup. Looking forward to @emperioreric’s talk on the UIAppearance proxy (timely). Afterwards, it’s on to Atlanta to catch up with friends and attend the iOS Developer’s meetup.

 

 

Advertisements

App Challenge

As part of my transition to freelance, I’ve challenged myself to complete important projects that had been languishing. The goal is to deliver a version 1 for 3 apps in 6 weeks. Though it’s a daunting task, I expect an informative and productive experience.

BDD 

I’ve recently adopted the BDD (using Kiwi) approach to building products and want I ingrain the process. The simplest way I know to do this is repetition. By having 3 apps in development over such a short period of time, I can ingrain the habit of creating tests before coding and allow that to drive the design. Because each app is different in nature, I can gain more varied experience in the types of tests that I write. For example, one app requires connection to an external API so I will gain experience with asynchronous tests.

Product Scope

The constraint of a short development time forces me to concentrate on the core value of each product. The initial version of each app is confined to the bare minimum needed to ship. As I work on features, I always come up with ideas for additional features (or products). Anything outside of the scope of version 1 is added to the icebox. I allocate time each week for retrospectives and backlog grooming to evaluate progress and scope out future work. This practice helps me escape the ground-level implementation details and return to the high-level overview of the app to keep it on track.

Current Status (Week 2)

The beta for the first app, TouchCase, shipped yesterday. It’s functionality is simple. It’s UI is plain (honestly, it’s as ugly as homemade soap) but it gets the point across and the momentum has been established (objects in motion, right?). The other two apps, PomoTracker and Haggler, have each been  story carded for the version 1 and design work has started. BDD has been a little slow going as I’m learning the what and how to creating effective Kiwi tests.

Up Next

Week 2 concludes the current sprint for TouchCase. Next week will include model/service tests for both PomoTracker and Haggler. PomoTracker will be the next app to get to beta (hopefully by the middle of week 4). In hindsight, I should’ve built it first as it’s the product that I need to better track my progress through development.