Lego Sandcrawler Timelapse

With a little help from the boys we built the Lego Star Wars Sandcrawler set this weekend. Here is a time-lapse of the 3296 piece build.

This is Lego set 75059.

We built it over 3 days.

The most tedious was the 304 treads for the 8 tracks for the 4 legs of the crawler.

Don't be surprised if I order RC motors next to motorize this ;-)

Apple Watch Ideas

Like many iOS devs, I am playing around with Apple Watch ideas. As with most things, I have no shortage of ideas. It's the implementation that is always the hard part.

Now, why can implementation be hard? I think because we try for perfection too often.

Many devs I have spoken with, and myself included, come up with lots of features that we can add. Heck, everyone does this. Name a piece of software you could not make better with a couple features you'd love.

The problem when you are the product designer, graphic artist, programmer, and every other hat needed to ship your own product, is that you need to decide what to cut and when to ship. The inability to cut is one impediment to actually shipping.

As devs we want our apps to be perfect and have lots of neat features we would want. It has to be just right with tip-top graphics. It should have iCloud support, custom UI controls, support multiple languages, have accessibility, and the list goes on. All these things might be great but does the app really need it?

At times I have been parallelized by feature bloat as I design some apps and hence they never get built and never ship. I call this app day dreaming. Boy, wouldn't it be cool?

For example, recently I started to think about some apps I could build for smart watches. Some are for laughs with my two boys, some are jokes with coworkers as we batted around ideas, and some would solve problems I have which I would rather solve with a watch than a phone.

Like any project, I decided to capture these ideas and start to estimate how long I thought they would take. As I started to add features to the list for each app it grew longer and longer and the timeline started to crush my excitement.

As I waited for the Apple WatchKit to be released for development I started to say, maybe these ideas would not even be possible. So, I just planned more and made contingencies, "If Apple gives us support for this, then I can do this idea." etc.

Then the WatchKit came out and I realized I could actually do most of my ideas. Let's start in. But then reality hit. How am I going to build this feature set out?

• Full iOS App to support the Watch App?
• Ads to provide a trickle of revenue if the app gets traction?
• In-App Purchase to add additional features/themes so I can hope to get paid a bit for my work?
• Fully featured ability to edit content on the Watch?
• Storage of content?
• Graphics?

This is a lot of work for one person to pull together in their "spare" time. We all know how much of that we have.

While getting down from the work load ahead I was listening to the App Business Podcast. In particular, the episode ABP115 – Michael Dowell of App Indulge. During this episode, and others recently, I realized I am complicating things too much. 

How many of these features did I really need?

Could I design the apps differently to reduce the work but keep features?

So I started to look at how I can trim one app in particular:

• First off, drop the content editor.
• Instead: supply templates for users to fill in their information.
• Drop the in-app purchase for themes.
• Instead: re-package the app for each theme and release an app per theme instead of one app that can download the themes. Less work to create downloadable content. Increased SEO with the name of the theme being in the app name and app description.
• Move content editing into the templates as much as possible. Then move what can not be in a template into the iOS Companion App. Then leave the remaining for the Watch. Thereby simplifying the app on the Watch which makes it easier to use and less complicated to code.

Applying this strategy to several of my ideas means I will ship more apps that do less. That is fine, since my research indicates that you have very little time to get a customer to decide if they are going to buy/download your app. So I need to optimize the discovery time and effort for ROI which means simpler apps, with streamlined descriptions in the AppStore so I can hope to capture the most customers possible.

With the AppStore having so many apps it does not pay, from what I can tell, for a single person or small shop to spend a lot of time on adding features in their app when their app may never sell enough to pay for the cost of development, let alone living expenses.

So, let's see how this experiment works as I find spare cycles to write a couple apps to scratch my itch.