Last June I wrote about initial screen empty states, their influence on users’ decisions to re-use or abandon an app and gave some alternative implementation options. However, while it’s ok to have an implementation startegy it doesn’t help if you don’t know exactly what you are going to to display instead.
Benjamin Brandall has a recent article on TechCrunch where he considers what might be placed in those empty state screens. I recommend you read the article to learn how to inject emotion, incentives and positivity as well as use the empty state opportunity to promote the benefits of using the app.
I have updated my Mobile Development Primer with more recent relevant content.
Many people, particularly individuals or startups, approach me who have an idea for a mobile app but have no experience of creating software or mobile apps. This site contains thousands of posts, created over 10 years, with lots of insights for startups. However, the blog-style format isn’t very digestible for people who ask me how to get from idea through to development.
The Mobile Development Primer lists some of the things startups should be thinking about when considering mobile development. It links to relevant posts on this site to give more detailed insights into specific areas.
Detroit Labs has a new post on 5 Reasons Why Your Android App Should Not Mirror Your iOS App (And Vice Versa).
Their first reason is something I have been saying for a long time: It will cost you more if you clone an iOS app. However, something I hadn’t considered is that paying attention to platform differences can be better for app marketing…
“If you build features that are Apple- or Android-specific, app stores are more likely to feature your app, and it will definitely garner better ratings.”
More specifically, at the moment, if you do a great job implementing Android’s Material Design then you will be on a faster track to being featured in the Play Store.
So what other kinds of things should be different? Take a look at my article on Porting iOS to Android for some high-level tips.
There’s an interesting presentation ‘Planning Android Screens’ by Dmytro Danylyk from GDG DevFest Ukraine 2015. He describes how the app designer should not be the sole decision maker…
“Developer will be able to give your design team visibility into areas of the design that can either become costly to implement, or present performance challenges for the app.”
I agree. It’s amazing how many UI designs I receive that have had no thought put into the cost vs customisation balance. The more you move away from the standard Android UI the more it’s going to cost. In some cases the extra complexities are for no good reason and it’s my experience that they often get removed later during a later UI iteration.
I believe the problem partly comes about due to the way developers are usually employed. There’s a traditional ‘how much will this cost’ or ‘how long will it take’ conversation that demands some sort of understanding of what needs to be implemented. Hence, companies are pre-disposed to decide what needs doing before contacting the developer. However, it doesn’t need to be like that. Consider contacting your developer earlier and employing them for a very short time to help with the initial screen planning. You might think this is difficult if you haven’t yet chosen a developer but in those situations you might even use the quality of the resulting advice to fine tune who you want to do the development. As with development features, mitigate the risk by assessing the unknowns as early as possible.
Involving the developer earlier will usually reward you with a faster, less expensive project.
I recently posted on how you might think about screen orientation support. This led to possible consideration on how devices are held in the hand(s). Following the theme of adapting your app design to how your app might be used, you might like to take a look at the free Pew Research paper (pdf) into mobile etiquette.
The report shows under what situations people think it’s ok to use their smartphones, what they do on their phones when taking part in a social activity and how this varies by age group.
Depending on your app, the results of this research might help you determine whether your app is likely to be used in particular contexts. Alternatively, you might even target a popular context such ‘Look up information about where you are going or how to get there’ or make other contexts more easily achievable, for example to help ‘Avoid interacting with others who are near you’! Tapping into common end-user etiquette and motivations might be used as a way to improve app use and retention.
I have been noticing a trend in apps I have asked to develop, also in apps developed by others and some of Google’s own apps, for example the default launcher on Nexus devices: A fix of app orientation to vertical.
There was a time when the advice was to develop apps so that they always dynamically handled any orientation. I think this came about because the original slide out keyboard-based Android G1 and popular Moto Droid relied on a horizontal screen. Rolling forward to more recent times, I am increasingly receiving designs that are vertical only with no thought or even hint that horizontal orientation has been considered.
Users are becoming more used to keeping smartphones vertical. Whether it’s because it takes effort to re-orientate a device or whether it’s a cause and effect of more apps becoming vertical-only, 29% of view time is now vertical vs 5% five years ago.
Vertical-only has the benefit of less to design and code and some types of content will never look great when horizontal. However, keep in mind there’s still a minority of phones, for example the Samsung Galaxy Stratosphere II where vertical-only apps are extremely difficult to use with the keyboard.
Should you make your app vertical only? I happen to be working on a specialised app, used for one purpose, on only one type of device, that fixes the app to landscape! Lists of things tend to work better on the vertical while image or vector based viewing, with panning, tends to work better on the horizontal. Take a deep look at your content and consider possible screen layouts before you decide. You might also like to take a look at how people hold their phones together with the context in which you expect your app to be used.
The Mobile Academy blog has lots of tips for startups. For example, last week there was an excellent post on 10 Tips to Market Your App for Little or No Money. It’s great to see some pragmatism and realism in this article. One of the problems with some high level advice and development best practice is that it comes from people in larger well funded companies. It often assumes you have infinite development effort and funding. In the real World of the long tail of tightly funded apps, the harder decisions are often associated with compromises to ideals.
Also take a look at the Mobile Academy post on insights from an audience with Russell Buckley. The first point is “If you haven’t read The Lean Start-up, you should”. I would go so far as to skip this book and read the much more pragmatic and actionable “Running Lean” authored Ash Maurya that’s part of the Lean series by Eric Ries – author of the original book. Ash takes Business Model Generation (mentioned in my Mobile Development Primer) and has developed a Lean Canvas.
The gist of the Lean Canvas is to document your plan, identify the risky areas and create lean experiments to exercise and evolve the plan.
The next Mobile Academy starts 1 October in London, a collaborative course that gives a grounding in mobile business and design.
For the last few years I have mainly worked with startups. Of the many companies I have worked with, very few, only about 10%, have used Agile. Does it matter?
On the one hand, we have a few Agile tech speakers and consultants who will tell you if you don’t do it their way you’re stupid or incompetent. On the other we have people such as Jeff Patton, who previously won Agile Alliance’s Gordon Pask Award for contributions to Agile Development, saying common Agile practice isn’t for startups. Jeff’s article is thought-provoking because he says, for many startups, learning velocity is more important than delivery velocity.
Martin Fowler has an related article where he says “You don’t do agile or lean you do agile and lean”. I am not sure this is always true as, in practice, Agile invariably results in a significant upfront investment in additional unit testing – but I suppose it strictly need not when mixing Agile and lean.
You really need to consider your project. Is learning velocity important? Agile and better testing came out of a time when there were huge projects that were failing. Is your mobile project that huge/complex (it can be) or are you over-engineering? What’s your initial budget? What’s the anticipated lifespan of your software? Will the code ever have to be handed over to others to continue to develop? Is the project mission critical? How many people will be developing the project and how experienced are they? How much do you trust your current development process if you have one? How quickly do you expect things to change and by how much? Answering some of these questions might help you decide how much Agile matters for your project.