MVP What and How

November 5th, 2014

There’s a diagram doing the rounds that demonstrates what a Minimum Viable Product (MVP) is (and isn’t). It shows that a MVP shouldn’t be just about functionality but also about reliability, usability and user experience. Building a MVP is one of the first steps after which you have to measure, learn and iterate. However, just getting to an MVP can be difficult and how you do it can affect ongoing development.

mvp.png

The diagram is a clever way of showing what’s sometimes hidden when first thinking about a new product. It digs deeper into the what side of a MVP. i.e. What the product should be. I have found that, in practice, creating a MVP is a delicate balance because it not only concerns what but also how these things are implemented.

I have seen my clients’ MVPs (server-side and apps) scrapped and started again and I have also seen them used as the basis for further iterations. I have seen large amounts of effort on over-thought through, over-generalised and over-tested MVPs be dropped. Conversely I have seen under-thought through, under-designed, under-tested MVPs with lots of technical debt become the basis of future development. Perversely, the flexibility of the latter approach seems to foster more success and these are the projects that then end up having to build on sand. So, also think how (well) as well as what.

Related Articles:

iOS <-> Android Native App Conversion

November 4th, 2014

myappconverter.pngOne of the problems of mobile development is that it’s a human resource driven activity that’s expensive. Multiply that by iOS and Android and the costs double (or more). Wouldn’t it be good if you could develop on Android or iOS and a tool could automatically generate for the other platform? Well, MyAppConvertor has that ambition. Really. This isn’t some limited, poor html-based or intermediate language-based ambition. It’s the real thing - Objective c to Java and vice versa.

MyAppConverter presented at the recent DroidCon UK 2014. You can signup with SkillsMatter to see the presentation.

MyAppConverter is currently in beta and is limited to online conversions via their web site. It only works for games, only converts from iOS 7.1 to Android 4.4.2 and only on Samsung Galaxy S5. However, the aim is to eventually support IDE-based conversions, for all types of app, to and from all major mobile platforms and versions of those platforms.

The presentation outlines their approach based on models and meta models to not only directly map code but to also do it in such a way that creates the right algorithmic and UI idioms/patterns on the respective devices. While the converter can create source code for completion by a developer, they are aiming for 100% conversion so that anyone can use the tool. Anything less is much less useful as it then needs a developer and the ‘extra stuff’ the developer adds needs to be somehow added every time there’s a new version of the app which would get difficult to manage.

myappconvertermapping.png 

The intention is impressive and hugely ambitious. However, it’s so ambitious I question whether it’s viable. The Droidcon presentation hints that they have already spent 5000 man days on iOS to Android transformations, just for games APIs. Games are the simplest, low hanging fruit, case as they don’t use that many APIs and are mainly drawing code.

This isn’t just about mapping APIs which is complex in itself. It’s also about knowing all the nuances of the APIs that are documented in places like stackoverflow. It’s also about mapping idioms and patterns of doing things, somehow mapping 3rd party libraries, knowing fragmented differences between (target) devices and knowing differences in APIs across OS versions. Even then, it won’t cover apps that use ‘real native’ c/c++ NDK code - previously estimated by Intel to be of the order of 25%. Once all this is solved, consideration has to be given to keeping all this up to date into the future. APIs can become deprecated over time and new API’s are created. For example, in Android Lollipop there are over 5000 new API’s. New devices will also become available with new nuances.

I don’t think what they are trying to achieve is possible in a reasonable time and/or with a reasonable team size. The World really needs tools like MyAppConverter. I sincerely hope they prove me wrong.

If I am wrong and the tool comes to fruition then there are some interesting possibilities MyAppConverter might not have considered. It might be possible to create a new tool to create apps by visually (or otherwise) building up the pre-existing meta models. These meta models, together with some kind of configuration data (the static, unchanging data in an app), would then be able to auto generate to multiple platforms with no actual developer coding thus putting developers such as myself out of business. Lay people, capable of wiring things together, could create complex apps.

Related Articles:

Notifications vs Apps

November 3rd, 2014

intercom.pngThere’s a thought-provoking article and discussion at Intercom on "The End of Apps As We Know Them". The premise is that we will use apps directly less and less and instead interact with rich notifications or cards.

While I can see some notification-rich apps might work this way, I am less convinced that the majority of apps will end up working that way. Most apps do too much to be shoehorned into a notification style app. Also, people are more used to invoking apps via icons and I can’t see that going away. I think cards/notifications are great for end user consumption but not end user content creation. If the majority of apps were to use this paradigm then the user would become overwhelmed with notification overload.

Shift in Smartphone Market Shares

October 31st, 2014

idc.gifIDC have a new press release showing smartphone vendor shipments for Q3 2014. Samsung lost market share at the expense of Xiaomi, Lenovo and LG. Apple’s market share dropped slightly by 0.9% to 12% meaning shipments of units grew by 16.1% vs 25.2% for all smartphones.

idcsmartphonevendorsq32014.png 

What does this mean for developers? For Android developers it’s going to be increasingly the case that testing mainly on Samsung devices won’t get you the majority of the devices being used. With iOS now having only 12% market share, there’s going to be continuing intolerance by end users of some companies that still only provide an app for iOS.

Related Articles:

Mobile Potential

October 29th, 2014

benedictevans.pngBenedict Evans has a new presentation given at the WSJD conference and also at the a16z Tech Summit. It consists of very many charts showing how Mobile is Eating the World.

There’s also a related healthy discussion on ycombinator where people question what can be really done on a (UI) limited mobile device, others observe that many popular apps don’t necessarily do anything really useful / don’t fulfil devices’ full potential and how some people suspect we might be in a bubble after which there might be 2nd wave of mobile innovation based on less expensive devices.

Related Articles:

WebView Unbundling

October 28th, 2014

arstechnica.gifThere’s an interesting post on ars technica on "Unwrapping Lollipop" talking to "high ranking members of the Android team" about changes to the OS. It includes a very useful breakdown of what’s now in the Android OS, what’s in Play services and what’s distributed via the Play Store.

lollipopunbundling.png 

Of particular interest is that WebView has been unbundled and now comes from the Play Store. The idea is to be able to more-easily (auto) update WebView for performance and security reasons. However, this won’t be for pre-Lollipop devices. In the near-term, there will still be a large number of old devices on old and varied versions of WebView. Also, unbundling has the side-effect that, going forward, non-Google sanctioned, AOSP-derived devices won’t have the latest WebView. Google will obviously care less about this but it will affect the 20% of developers on those platforms.

Related Articles:

Samsung Knox Security Blunder

October 23rd, 2014

samsungknox.pngThere’s an anonymous single-post blog at blogger.com that takes a look at Samsung’s Knox. Surprisingly, Knox relies on security by obscurity to hide the encryption key, the method of generation of which is now public information. It’s now known that it’s generated using the device’s Android ID and a hardcoded string.

As the author states, a stronger key should be derived using Password-Based Key Derivation Function 2(PBKDF2), from the user’s password, that shouldn’t be stored on the device.

Related to this, if you are instead relying on Android OS disk encryption, you might like to read how this has changed over time. Prior to Android 4.4 it was based on a PBKDF2 with only 2000 iterations, using the lockscreen PIN or password which tends to be short and more amenable to brute force attack.

UPDATE: Samsung have now refuted the problem but there seems to be a confusion/discrepancy between the versions of Knox mentioned by Samsung and the version that comes pre-installed on Samsung phones.

Related Articles:

Mobile Retail Behaviour is Changing

October 22nd, 2014
gfk.gifGfK has new research into mobile consumer behaviour showing double-digit point changes in metrics that measure where and how people are shopping. 

  smartphoneandtabletsforonlineshopping.png

Gfk says that companies should "build out an up-to-date and nuanced shopper insights platform" to provide insights, without which brands will be in a ‘hit-or-miss’ mode in execution. This dovetails well with my Does OS Market Share Matter post where I encouraged analysis of users on a project-by-project or case-by-case basis.

Related Articles: