Showing posts with label apps. Show all posts
Showing posts with label apps. Show all posts

February 19, 2013

This is the future

Last night I walked past a bus stop after checking that the next bus was in 6 minutes and that it would be better to walk to the junction 400m further down the road to take another bus from there.

But how did I check this? (I did not check the cardboard route table for sure and this was not one of the stops with the live digital display.) In steps, I:
  • Pulled out from my pocket a device with four times the screen resolution of my first PC and the computing power of a full room of gear not that many years before that
  • Started and began using an app in less than ten seconds
  • Pressed "Nearby stops"
  • Got real time data on the whereabouts of the bus while still walking past the bus stop
So even if there is a lack of flying cars, this is the future we were thinking about as kids - I am pretty sure of it. And it was only after walking hundred meters past the bus stop I did the reflections leading to this blog post, so it felt like a very natural and non-advanced use of technology. Almost Ubiquitous, if wanting to buzzwordify this post a bit...

Being a technology optimist, I think this everyday observation gives hope that we will find both useful and entertaining ways of using technology in the months and years to come. We have seen nothing yet.

January 29, 2013

Bet(t - ) it will be good

Bad wordplays aside, just a quick note to tell that I am going to Bett in London this week. Pocket full of nice new brochures, hoping to meet interesting people and more than ready to do a quick demo of TapBookAuthor.com if you are going there too...

So it better be good (OK, I will stop now). See you!

January 8, 2013

Happy Last Year

OK, two things first before writing the post: First and foremost, happy new year and best of luck for your projects, people, products and passions (the less known 4Ps?) in 2013! Then, if you have even a hint of allergy towards self-promotion, stop reading. Really.

Still there? I am going to share two great things happening to our product and team at the tail end of 2012. First, we got external recognition when we won an entrepreneurship price from a leading Norwegian legal firm. Apart from nice flowers and even nicer honors, this gives us some free legal advice which will be very useful when getting our first international customers.

Below are myself and partner at Wikborg Rein, Torleif P. Dahl - as well as those mentioned flowers.



Second, we landed two leading Norwegian publishing houses as new customers for our tool, making the total number of customers reach the great number of four (!). I am not joking, but I am also not joking about it being great. With these lighthouse customers secured, we are looking very much forward to demoing for smaller publisher as well as international ones. If you happen to be a potential user of the tool reading this, drop me a line to book a meeting.

Looking forward to a great year in 2013 as well - on our part we have lot of exciting things up our sleeve for the TapBookAuthor / ePekebok tool (push messages and Windows 8 apps prototype support are two items in the Q1 list of new functionality, with unlimited undo across sessions and interactive graphs and questions/tests on the list of autumn 2012 highlights). Happy last year. Happy new year!


October 9, 2012

Getting the heck out of the office


When teaching Entrepreneurship at NITH this semester, I am leaning quite heavily on Steve Blank's book The Startup Owner's manual (as a supplement to Business Model Generation by Alex Osterwalder, that is our main course book in addition to articles etc.).

One of the key phrases I particularly like in Steve's book, in addition to the definition of a startup as a temporary organization searching for a scalable business model, is the advice to get the heck out of the office (there are no facts or customers in there!).

Even if "the office" might be a metaphor for many startups, there are no subsititutes for actually testing hypotheses on customers.

So do I practice what I preach? Well, I try to - with tapbookauthor.com (and Norwegian variant epekebok.no) now up in low-fi version 0.5 to start describing our awesome app publishing/authoring tool, we are ready to get the first set of post-pilot customers! Next week we are demoing for potential customers and starting discussions with seed investors - getting (the h***!) out of the office...

February 9, 2012

Competing with "Free"

My company has spent the last two and a half years developing what we think is a kick-ass publishing tool (authoring tool) for apps in general, and school book apps in particular[1]. About a month ago iBooks Author was launched by Apple, with no cost for the product itself.

Having a competitor launch a free product, aimed right at the niche where you have invested thousands of hours, is seldom good news. And when the competitor is possibly the world's most admired for innovation (I for one find it absolutely stunning that they still grow almost like a startup and with profits the size of Google's revenues!), and at times the most valuable company in the world, is all lost? As it turns out: No.

I will freely admit that I was nervous before the product launch, given the rumours (which were true). And five minutes into the launch video, I was scared. But five hours later, some analysis helped calm the nerves. I created this little matrix, you can click to enlarge it, showing that the lunch was clearly not free this time (either):



So for the time being, I see the launch as positive. The product and the marketing around it clearly highlights the need for innovations in apps for school books (and maybe broader in learning) and with the product's current shortcomings, it is not that hard to still try to sell "an expensive alternative". But if iBooks Author's output products ran smoothly on Android with no restrictions on the content produced, I would probably go back to being scared. Or maybe just work even harder on the online-collaborative angle. Go David against the innovation Goliat!

[1] - This sketch, again click to view larger version, shows the principle of how the system works:



A more technical version is that the core is HTML5-based. When building the app we pull out the HTML5 content, wrap it with a set of native extensions (using PhoneGap) and build for the relevant iOS (mostly iPad, but also iPhones for books for children) or Android platform.

The response of a potential customer being shown it live in a meeting previous week was "Magic!". I smiled.

November 2, 2011

The App Store review process and queue theory

The last weeks I have had the mixed pleasure of pushing 19 apps through the App Store approval process for a client. Some updated to improve iOS5 compatibility and some brand new. It might be bizarre that this gave me associations to queue theory, but it did and I will explain why.

I won't claim that I remember much details from the queue theory I had at NTNU exactly a decade ago, in the context of building scalable web apps, but I remember this: If you have a mixture of a few large jobs and a lot of small jobs, you can improve the throughput a lot by introducing two queues[1] - one for the small jobs and one for the large. That way the small jobs can flow through quickly, while the big beasts naturally take some more time, but that is hardly unexpected.

An extension of this principle is exactly what Apple should do. I find it slightly ridiculous that an unchanged app (apart from the fact that it does no longer crash on startup with the combination of iPad1 and iOS5!) can take a week to review, going from version 1.1 to 1.2... So, Apple: Get that high pri queue for small jobs (i.e. minor bugfixes etc.) going and the perceived throughput from the job's (app submitter's) point of view will increase greatly! In practical terms, get dedicated teams (or time) to review updates of existing apps and make them flow through the review process on a less than two day average, compared to taking maybe the bulk part of a week today.

[1] - Or a variant thereof with allocating slices, as in a time sharing system like in modern computers - which de-facto will make small jobs flow through quickly if each job gets an equal amount of time "each round" and the big is not served again before every small job gets its share.