Innovation By Limiting Options

Posted on by

As we work on a new project here for the first time in a decade I am thriving off some simple restrictions we put in place and causing me to be more creative. Those restrictions:

  • Should adjust naturally to screen size changes
  • Should be easily portable to other operating systems
These two issues have become major stumbling blocks for powerOne. powerOne is highly dependent on the screen dimensions of the device because of the calculator and the editors. It also takes a lot of work — 9 months to a year — to move it to a new operating system and device. Both of these issues make us slow moving in a market that is moving ridiculously fast.
This new project, which will remain nameless for at least another couple of weeks, is designed from the beginning to be a lot more portable. We have leveraged some existing code and existing iOS experience. We are about to enter a final testing phase with the product just three months after starting.
I like putting artificial limits on products, bounding the box with which I work. Creating restrictions forces creativity to flow in alternative directions and I hope, once I start showing the new app, that you’ll agree that boxes were placed in the right spots.

2 thoughts on “Innovation By Limiting Options”

  1. Elia,

    The mobile market is even worse than the desktop market in this regard. Since you chose to write the lowest layer of your code in portable C it’s really easy to move on the desktop, not so on mobile.

    I wish we had that option on Android, Blackberry, and Palm. Writing for portability on mobile probably means relying on a third party tool that may take you down a rabbit hole.

    Congratulations on trimming your time to new platforms, that should be commended. I’d be really interested to know how you did it, if you don’t mind sharing that is.

    • You are right about that — the mobile market is much worse. C, however, is generally portable, though, with the new native dev kits available. iOS and Windows Phone 7 are both based on C and Android and webOS have native C support. RIM is the odd man out in my equation but QNX supports C. My bet is that QNX replaces BlackBerry OS before long. So my assumption is native code.

      How did I do it? I started by putting a couple of restrictions on how the app could respond visually, traps that I knew were problems from working on powerOne all these years. And then I went about trying to answer the fundamental usage questions within these restrictions. What I found is that by placing these restrictions it forced me to be innovative in other ways that will become more transparent when we start showing the new product without losing the flexibility provided by powerOne when it comes to computational capabilities. Sorry to be so vague. Hard to go into details without announcing the product đŸ™‚

      Elia

Comments are closed.