User Personas

Defining your app’s target audience and why it matters

There’s more to developing an app than choosing features and writing code that will bring the idea to life. There’s an important decision to make first. Who’s your target audience? Defining this group is critical to the success of any app.

Impact of your target audience

The target audience for an app is the core set of users, the group of people who need the app and will reap the largest reward. Defining a target audience tells you more than simply who will likely be the primary demographic. It also informs how your app is built and what features will be included. The target audience could be segmented by age, gender or motivation.

The process to define an app’s target audience begins by gaining an in-depth understanding of the core group’s motivations.

Ask yourself, “What problem will the app solve?” and “What will the user accomplish by using the app?”

Identifying user flow and features

Once you’ve determined your target audience, the user flow can be sketched — starting with how users will interact with your app when they first log-in. If your target audience values privacy, they may create a username that leads them to a landing page. Or maybe your target audience is busy, or less trustful, they can interact with app functionality right away. This can capture their attention.

Target audience definition gives you more insight than solely who the primary user is. It also informs how features are developed.

For example, studies have shown millennials aren’t using Google+ and Twitter, with the same frequency as Facebook, Instagram and Snapchat. A sharing mechanism that targeted Google+ and Twitter wouldn’t be useful for this audience. Instead, the app’s sharing should integrate with the audience’s platforms of choice.

Leveraging familiar usability patterns

Having a clear understanding of your audience allows you to replicate the usability patterns they are familiar with. That way, your app will be easier to adopt and users will be less intimidated by the newness of the technology.

Maximizing marketing spend

There’s a working development theory that a large percentage of your build budget should be spent on the actual app development and the remaining should be allocated to marketing your app. Following that line of thought, the size of your target audience impacts your marketing budget. If your audience is large, your marketing spend will be much higher. The benefit is clear: When you narrow down that audience, it helps the budget for your market spend.

Answer these three questions to begin thinking about your target audience.

1. Who is the user and how is the app going to better their lives?

The apps available to users increase by the day. Knowing who your users are will enable you to call out features that make their unique situations better.

2. As a user, why do I trust this technology?

We live in a world where the lifespan of many apps are fleeting. By knowing your user, you can ensure it benefits them now and into the future.

3. How do I leverage this target audience to increase adoption for my app?

Our ultimate goal is to release an app that will help improve the lives of your target audience. How do you incentivize this group of users to spread the word? As an example, if your app charges a membership fee like Betterment, you provide an incentive to waive these fees via invitations. This is a meaningful incentive for their target demographic.

Curious to learn more about target audience definition and how it could impact the success of your app? Talk with us.

51262107 29dc 47d3 8fdd ce19890d5e09
Google IO

Google I/O predictions 2015

Google I/O is Google’s top developer conference. At this conference, we see some of the most monumental announcements and releases of the year. The following are my predictions for 2015. They are based in part on leaks, publicly stated targets and goals, and wishful thinking.


ARC Beta

ARC is Google’s effort to bring Android applications to Chrome as a platform. ARC stands for App Runtime for Chrome. Currently Chrome serves as the #1 browser in the world. It’s used on more than 80% of all computers.

With the rise of Chrome OS in education, being able to deploy applications to Chrome means developers will instantly gain access to a huge distribution channel.

Google Pay

The biggest challenge to the success of Google Wallet has been the lack of support from carriers such as T-Mobile or Verizon. These carriers informally blocked the inclusion and deployment of the Wallet app across devices. Compared with the universality of Apple Pay, which Apple ships on every handset and is able to control absolutely, Google had a tough challenge.

Softcard (formerly ISIS), the US carrier-built competitor payment system, has also achieved little success to date.

A big shift has happened over the last few months. Google purchased Softcard to hopefully heal carrier relationships and empower Google to relaunch Google Wallet. I’m expecting the launch will be called Google Pay.

Physical web

As I discussed in my other post on the Physical Web, I’m hoping the Physical Web will take a key role at I/O this year.

The physical web solves the problem of real world context in a very elegant way.

I’m expecting kiosks and interactive stations throughout Moscone in San Francisco.


Chromecast Multistreaming

Chromecast for Audio is a new use case for Google’s Cast API. To date, no products supporting the new standard have been shipped. Chromecast for Video is now a hugely successful platform, and it’s not clear whether this success will be realized as Google tries to take on the world of Audio..

With the launch of devices like Sonos and Beep, it will be critical that Chromecast for Audio adds support for streaming to multiple devices or multiple rooms in a synchronized way. This will allow audio to play on multiple devices simultaneously. Theoretically, this could even be extended for video to allow simultaneous streaming of YouTube videos and live events.

Android 6  / Android ‘M’

I have no idea what features will be a part of the next version of Android, but it’s time. Lollipop was the biggest release of Android to date, but it came with a number of headaches for users — namely memory leaks and random crashes. Android ‘M’ will need to resolve these issues.

It will also be important to make another attempt at addressing the fragmentation of Android resulting from the proliferation of new Android devices (Nexus Player running Android TV, Android Wear, etc).

Twelve months after its announcement, Lollipop is only on 3% of devices as of April. Google has success deploying updates directly to Chrome and Chromebooks, and they need to apply this expertise to Android. They have had some success deploying new software versions directly to Android Wear. They launched a standardized hardware platform with Android One, but for users to take advantage of the latest features from Google, they need to take a fresh stab at the distribution and fragmentation problem.

getrefe camera small1 729x430

Google Photos

Google+ has not been the resounding success that Google hoped for. At one point, Google was tying all bonuses to the success of G+.  Since Vic Gundotra’s departure, G+ has taken a back seat.

G+ Photos recently integrated with Google Drive, and it’s expected that it will be relaunched as an independent platform, Google Photos.

I manage all of my photos in G+ Photos today, and I’m excited for this system to get additional attention.


Nexus 5 2015

The Nexus 6 is a great phone, but it’s a little bit too big for the average user. The Nexus 5 has been pulled from the Google Store. It’s departure left a gap that’s just waiting to be filled.

Nexus 7 2015

The Nexus 7 2013 was a fantastic small tablet at an extremely reasonable price point. In April of this year it was pulled from the Google Store, leaving another space for a  product launch.

As a somewhat sheepish owner of a Nexus 9, the Nexus 9 was a great tablet that was terribly executed.

Google needs to go back, edit and recapture the success of the second Nexus 7.

Chromecast 2

Google has been selling their $35 dongle like crazy. Tens of millions of these devices have been shipped around the world since 2013. While there has been no public indications of any sort of change to this strategy, I anticipate a hardware update to the Chromecast enabling 4k video and other incremental improvements. That said, I hope they don’t break what is a fantastic product today.

Moto 360-2

I love my Moto 360, but with the Apple Watch, the competition is heating up. It’s time for a longer battery, a better band system, removal of the ambient light sensor bar and more fitness sensors.

The recent price drop of the 360 is an indicator that a new launch is impending.

Need to adapt your existing platform to pace with new tech trends. Talk with us.

51262107 29dc 47d3 8fdd ce19890d5e09
The 10 Best Apps for Oncologists 735x423

The 10 Best Apps for Oncologists

Cancer is a word that strikes fear in the hearts of most of us. There is no way to know what it’s like unless you or a loved one has experienced it. For many people, struggling to survive cancer is the toughest battle they will ever have to fight.

A recent research study examined the use of ‘war’ related metaphors like ‘fight’, ‘survivors’, ‘battle’, etc., to refer to cancer, and concluded that patients are more likely to show less self-restraint and have less limitations if they feel they are about to enter a battlefield. And often, they will choose more aggressive treatment procedures to tackle their ailment head on.

What does this have to do with apps for oncologists? We believe this study shows doctors that patients need to be prepared for a fight. It shows that the most up-to-date and aggressive treatment is often the difference between life or death, and that, if sent into battle armed also with doctors who have the best information available to them, cancer patients will maintain a positive, hopeful attitude.

Why do Oncologists need apps?

Apps aren’t just for gamers and hipsters. The technology field has also been busy doing its part to make diagnosing and treating cancer easier for oncologists, patients and researchers. These latest applications can keep tech savvy doctors on top of the latest symptoms, diagnosis, and treatment procedures, and bring peace of mind to patients.

Top 10 apps for Oncologists

We went straight to the source,, home of the journal Oncology, to bring you this list. Here they are, in no particular order.

MedPage Today and CollabRx have developed Cancer Rx, “…the first mobile app to aggregate and contextualize the world’s knowledge of genomics-based medicine in oncology.” It is a warehouse of updated information which offers guidance for treatment based on its database of tests and results.

Along similar lines, but not quite as comprehensive, is PubMed on Tap which offers medical resources by accessing the PubMed Central database.

inPractice mobile app lets oncologists access PubMed resources. Clinical trial registry and guidelines to treatment procedures can also be accessed with this app.

Treatment guidelines can be referred to in detail with the help of the National Comprehensive Cancer Network app, available on smartphones and tablets including iPhone and Android. This mobile app ensures effective treatment by helping physicians implement guidelines smoothly.

Information related to medical news, as well as guidelines to be followed during treatment of cancer can also be found on the Medscape app. It has an estimated user base of more than four million in the United States alone.

BrownZine offers a collection of e-journals with articles and references. These can also be downloaded as PDFs. With the help of this app doctors can scan through numerous scholarly papers from a particular educational institution or any other source.

For information on medications, Micromedex Free Drug Reference app is one of the trusted resources for prescription drug reference. Details on medicines such as name, class, side effects, etc., can be found here.

QxMD’s Calculate, where healthcare providers and researchers can search for and find calculations and formulas, is supported on iPhone, iPad, Android, and BlackBerry.

To help doctors find out more about secondary ailments cancer patients may be affected with, along with support on how they should be managed, diagnosed, and treated, there are the Johns Hopkins Guides.

Keeping patients up to date in their treatment and surgical procedures is the main objective of the Draw MD app. It allows doctors to visually communicate anatomy, conditions, procedures and concepts with patients to improve understanding, retention and quality of care.

And Last But Not Least…

The app chose as one to watch is OhMD. It provides a platform for oncologists and their patients to communicate through simple and secure texts. It meets the stage 2 messaging criteria and will work on the patient portal in use.

Apps are being developed regularly, many with specialized focus areas to assist physicians in adopting the best treatment procedure for their patients. We are certain that they will continue to be improved upon and we will see new apps being developed as doctors continue to help their patients with their battle against cancer.

If you would like to learn more about this and other digital health topics register for MobCon today.

Photo Credit: agencia_Investigación y Desarrollo via Compfight cc

the physical web

The New Physical Web

October of 2014 was a big month for Technology Announcements. At the pace our industry is moving, every month is a big month for these sorts of announcements. With all the innovation that is going on, it’s easy to miss the minor technologies that could fundamentally change the ways we interact with technology. One of these technologies that is worth a second look is the Physical Web.

Started as a side project out of Google, but run independently from the broader organization, the Physical Web is a set of ideas and standards about how human beings and technology should interact.

The Way It Should Be

Story 1 – Retail
You walk into a Starbucks and on your phone’s lock screen you see a notification: “New Physical Devices Available”. You click on this notification and get a list of interactions available and offered by this store:

  • Jukebox Control – Pick a song from our approved library and add it to the queue
  • Digital Order – Place your order digitally and pay for it using your Starbucks card
  • App of the Day – Download the Starbucks app or song of the day

Each of these interactions are currently available in Starbucks stores around the country (Except Jukebox Control). The way you discover them is through signage and little cards next to the cash register, and through word of mouth. When you discover one of these capabilities, you most often have to search for them via your phone, type in a difficult URL, or scan a QR code.

Each of these interactions create friction for customers today. These experiences aren’t packaged and seamless, and often involve a fair amount of work on the hand of the customers in the form of typing, signing in, download applications, etc.

With the Physical Web, Starbucks would create one or many bluetooth beacons that broadcast the available physical services in a standardized way that phones can recognize and interact with.

This simple ability for my phone to connect me to these services without downloading a location or business specific application, while still protecting my privacy and security would create magical experiences.

Story 2 – Home Control
More and more devices are being connected to the internet every day. From toaster ovens to thermostats, and everything inbetween. Today for each device you add to your home, you need a custom application that speaks a custom protocol.

Tomorrow, after you plug your devices in, they may just show up on your phone automatically. Security will still be a problem that isn’t going away. You will likely need to type in an ID or press a button on your device. Devices would have the flexibility to lock a device to only you, or to share with others in your home, or even visitors. The overall interaction would still be much simpler than what we have today.

How it Works

The idea behind the Physical Web is that instead of all of the custom programming and protocols that have been built up around the Internet of Things, we can return to the same technology that made the web interoperable and standardized, the URL.

By using Beacon technology, homes and stores and offices can setup any number of web-based services that users already know how to interact with. This, combined with the latest and greatest in HTML5-based application development means that we have another solution to the problem of discovery and relevancy.

If a device manufacturer such as Nest wanted to, they could still build and ship a native application. Android has built-in capabilities for native applications to interpret and act on URLs. This would allow them to offer a superior user experience for frequent use cases where discoverability isn’t a problem. The nice thing about the combination of the Physical Web and native applications would be that the Physical Web could help users download and install the right applications.

Google I/O Leak

While this has been a slow sleepy project without a huge pace of innovation, there have been minor leaks that Google I/O this year will be taking advantage of the Physical Web to offer interaction throughout the conference. If this happens, it will likely happen in conjunction with standardized support throughout Android for the Physical Web, so we may be seeing Physical Web devices and services still this year.

apple watch display1

The Importance of Fashion

Fashion and Technology have long been frenemies. For decades, technologists and computer scientists have, in some ways, been shunned by society. It’s only been in the last 10 years or so with the rise of Apple and the consumerization of technology that these worlds have been able to intermingle. This ceasefire was great for consumers and device manufacturers until 2014, but with the explosion of Wearable technologies, fashion is now an integral part of launching a technology product.

When you look at this weeks’ announcement of the Apple Watch, they have effectively launched a single technology product with a number of different fashion choices. Instead of the price being based on the processing power and capability, they are asking users to pay hundreds (or thousands) of dollars for different looking metals and bands.

Apple Watch Sport

apple watch sport




Apple Watch (Standard)

apple watch




Apple Watch Edition

Apple Watch Edition





If you look at the incremental value that each of these pieces of technology provides, the $200 price difference between Sport and Standard upgrades your material from Aluminum to Steel. I firmly believe that if you put a bunch of people in a room without knowledge of the Apple Watch and asked them how much they would pay for their device to be Steel instead of Aluminum, I don’t believe any of them would go as high as $200.

This is the bridge that no other company has been able to make. When Lenovo or Samsung sells a device, they charge higher prices for more CPU speed, higher prices for more RAM, but Apple has cracked the code of getting people to pay more for the fashion and the social statement of a device. This allows Apple to decouple their costs from the price being paid by the users, and will allow them to dramatically increase their profit margins.

Even if they don’t sell more than 1,000 Apple Watch Edition devices, people will be more likely to purchase the Apple Watch Standard because “it’s cheaper”, even though it’s nearly the price of a new phone.

What do you think? Cast your vote below!

old software 729x4231 729x423

How the Appstore Changed Software Development

Long ago, in order to install apps on a computer, you had to go to a brick and mortar store and peruse aisles of boxed floppy disks or cd-roms. Consumers had to decipher an arcane list of hardware and system requirements to determine if the application they wanted to purchase would run on the computer they had at home. Return policies were stringent and unforgiving. If you went home and tried to install application only to find out your version of windows was too old or you didn’t have the necessary sound card, you were out fifty bucks and two hair pulling hours of your time.

computer smash

In 2008 Apple and Google introduced specialized app stores for installing software on their smart phone operating systems. Three years later Apple copied the distribution system for OS X. These app stores revolutionized software distribution. Consumers are only presented with apps that will actually run on their smart phone or computer, they can read reviews before installing, and updates are installed automatically. Buying software is as easy as tapping your finger on a screen or a trackpad.

The ease with which a user can install or uninstall software has had an effect on how consumers perceive software. What people would once pay $70 for at Best Buy, they now are only willing to spend money in the single digits. One reviewer of a popular video game writes, “Was great but not worth more than a dollar” for a game that cost $5. People have concluded that ease of acquisition is proportional to ease of development. They think that since the opportunity cost of a software purchase is less, than so to is the development cost.

top grossing apps ios thumb

As apps have gotten smarter and more sophisticated, users have come to expect more, but they are less inclined to part with money up front. In order to fund development, software makers have devised new and novel ways of monetizing their work. In addition to in-app advertisements, we now have the freemium pricing strategy. Freemium is somewhat analogous to the shareware of the pre and early internet days. Applications are free to download, but come with a limited set of features. Advanced functionality can be had by paying money to unlock them. Game developers restrict access to levels beyond the first few until a user unlocks them for a small fee. In free to play games such as Clash of Clans, players can buy in-game gems to speed development or purchase special items. Apps like Pocket and Evernote employ freemium subscriptions. Users have access to all the functionality of the application but there are limits. Pocket allows users to save and read as many items as they want for free, but for $49 a year, users have a permanent archive of the content they store, as well as the ability to tag and search their content. Evernote Premium increases the amount of storage space for notes and pictures and also allows users to collaborate on notes, as well as enabling the ability for the app to work offline.

The app stores have also helped customers and developers communicate better about software. Though in a somewhat broken way: reviews. Users employ the review system to not just convey the merits or defects of an app, but also to request features, report bugs, and ask for support. This is somewhat frustrating for developers. On one hand, they get feedback about their work quickly and from a wide range of users without having to seek it out, but at the same time users will try to bargain their rating for their pet feature request. Other times users will rate an application poorly because they can’t find a feature or because they are having issues with some aspect of the application that isn’t a bug or a crash. To mitigate these issues, Google wisely allows application developers to respond to reviews. Not only does this contextualize a negative review so as not to influence other potential users, but it also permits developers to reach out directly to users who are having problems and provide them with support.

App stores have also had an effect on how software is developed and released. With the rise of agile software development methodologies and product development strategies like minimum viable product, software makers release their applications with reduced feature sets and in unfinalized states. When Ulysses III, a text editor for OS X, was released to the OS X App Store in April of 2013, many users complained about missing functionality from the previous major version. This version was a complete rewrite of the seminal text editor, but in order to ship by their deadline they needed to leave out features that users had come to rely on in the previous version. The makers of Ulysses III, quickly iterated and enhanced the editor over the next year bringing in old features and adding new ones. Because app stores greatly reduce the cost of distribution, developers can get away with this. Often applications will be intentionally brought to market in an unfinished state and users will guide future development through feature requests and usage patterns.

In a way, users of software have become both beta testers and product developers. They try unproven features and provide feedback on usability or bugs. In the Android ecosystem, users also provide developers with data on phones and device configurations that the developer may not have had at her disposal when creating the application. By requesting features and making suggestions, users also guide the design of the product.

Though it is not without it’s problems, the rise of the app store has been a boon for both consumers and developers. This new ecosystem provides enhanced communication, faster development cycles, and stronger products.

A Quick Look at Cross Platform Philosophy 729x423 729x423

A Quick Look at Cross Platform Philosophy

When evaluating or designing an approach for reaching users across a wide variety of platforms and devices, MentorMate applies our core mantra of ‘Business Needs First, From a User’s Perspective’. This means that the chosen solution should support the outcomes and end state desired by the business in a way that supports and engages users effectively.

Across the industry, there is a significant amount of literature and time dedicated to the notion of Cross Platform Frameworks. These frameworks attempt to reduce development time and complexity by abstracting shared components across two or more mobile mobile platforms and optionally the web platform. For the purposes of this document, only iOS and Android are considered.


Cordova is a framework that acts as a layer between HTML5-based applications and native capabilities. With Cordova, the native capabilities of mobile platforms such as Contacts Integration, GPS, Filesystem, and other sensors are exposed to the application via a series of Javascript APIs.

Cordova applications are built by taking a client-side web (no server side code is supported directly within Cordova) application of one or more pages and enriching it with native capabilities. Cordova applications can be mixed with native functionality and screens, but this use case is less often desirable.


If the application you are developing is an offline client-side responsive web application, you have already written most of the code that will allow your “application” to function. This means that a well written web application utilizing a framework such as AngularJS can be leveraged as-is to begin offering offline mobile application experiences.

One of the best aspects of Cordova is that it allows developers experienced in the Web platform to begin building mobile experiences that take advantage of mobile paradigms and capabilities without significant retraining.


Cordova has two main downsides. . First, all of your UI will be web-like. This means that your input fields will look like web forms rather than native input boxes, it means that transitions and animations will render and perform like those found on a website (or worse), and that standardized components such as the Android Action Bar, or the iOS Tab Navigation cannot be leveraged by your application. By not matching the standards of iOS and Android, your users will need a small amount of additional time adapting to your custom experience, or may feel like the experience is less modern. This can be mitigated somewhat through creative experience design and/or the use of cross platform design frameworks such as Material Design, but will still make your application feel less like a smooth shiny native application.

The second core downside is that Cordova applications are limited by the Cordova framework. The Cordova framework is always going to be several releases or features behind “main line” Android and iOS. A great example of this is that there is still not an official way to build Android Wear or Apple Watchkit applications with Cordova. There are 3rd party libraries (including one we have written), but they don’t have the focus or attention that the native tools have.

There are other downsides with Cordova for Android such as the widely varying versions of the WebView that ship across multiple Android devices. In All Android versions before 4.4, the WebView was bundled with the OS and immediately out of date upon shipping, meaning new features of HTML5 are inaccessible. This can be worked around by shipping Android applications with a custom-built WebView called crosswalk using the latest version of Chromium, but this introduces another dependency and more complexity.


Xamarin is a framework indirectly supported by Microsoft that allows developers to build iOS, Android, and OS X applications using C#. These C# applications can be designed to have both a data and services layer built in C# as well as a User Interface built in C#, or developers can blend C# and native functionality.


Unlike Cordova applications, Xamarin applications are compiled instead of being interpreted at runtime. This means Xamarin applications have better performance than Cordova applications. Additionally, Xamarin applications use reflection to expose native APIs automatically, meaning that Xamarin developers do not need to wait for the Framework to update in order to gain access to new or device-specific native APIs.


Xamarin is a new platform It does not have the same level of extensive and numerous application frameworks as HTML5. Tools like Xamarin Forms which allow users to build shared UI code that renders well across platforms are still in their infancy, and can create significant barriers to building top-notch experiences. User Experience elements such as gestures and animations can be difficult to achieve due to the fundamentally different ways these are natively achieved by the platforms.

It should also be acknowledged that because Xamarin ties so closely to the platforms, many things that one might expect to be cross-platform may not be. One example of this is Wearable interfaces. If you are building wearable experiences using Xamarin, you must still build them twice to target both iOS and Android.

According to Xamarin, best of breed applications are able to achieve around 70% of the code between platforms, so expect to be working on platform-specific behaviors as well as overcoming unexpected issues with the shared code.

Last, to get started or to continue working in Xamarin, each developer will need a license to Xamarin, which serves as an additional barrier to entry for new team members to get up to speed.

Native Development

Native development of an application for each target platform may seem to be the most costly approach, but with fewer risks and compromises required the cost can sometimes be less than an equivalent Cross Platform application.


Across both of these Cross-Platform frameworks, there may be an overall reduction in development time in exchange for limiting the types of interactions and experiences that can be built to those that are “lowest common denominator”, but these platforms are evolving every day. This must also be considered in combination with the additional developer skill sets implied and required by the use of an additional framework. For a Cordova solution to work successfully, the development team must be familiar with both Blink and Webkit capabilities and peculiarities (including their mobile components), as well as the best practices for building mobile applications. Xamarin developers need to understand the iOS and Android platforms and capabilities as well as have extensive experience building C# applications.

Finally, packaging and designing an application should be done intentionally for each platform. Each store has separate submission and review processes. Things like screen shots and marketing text may be significantly similar, but users hate seeing platform-specific images for the wrong platform in either store, and may risk the rejection of your application.

clutch co award

The Impact of App Platform Selection on Development Costs

MentorMate was recently selected for an interview with Clutch, the online authority on mobile app development companies, as part of a series of expert interviews on mobile app platform selection and the cost to develop an app.

Clutch sat down with Chief Strategy and Innovation Officer Stephen Fluin to pick his brain on topics such as how price quotes are determined, what the biggest cost drivers are, and whether iOS or Android costs more to develop:

In general, we treat them about the same. When it comes to developing for iOS versus Android, the net total, end of the day cost is going to be about the same. What we say internally is that the differences between one developer to the next are going to be greater than the differences between iOS and Android. Developers tend not to be fungible and all equivalent. Some are faster than others. A fast Android developer is going to do an Android app faster than a weak iOS developer and vice versa. A fast iOS developer is going to do an iOS app faster than a weak Android developer.

The interview also dove into different mobile app platform options, and what factors inform the platform decision:

Some of the first questions we ask when onboarding a client are, “Who are your customers?” “Who do you want your customers to be?” Then, depending on the demographic, the income bracket, the industry, and whether it’ll be used personally or professionally, we’re going to see different device needs.

For example, in the engineering industry, we see almost exclusively Android. Whereas in the medical space, we see almost exclusively iOS. We tend to see higher income individuals preferring iOS. We tend to see lower income individuals preferring Android. But, it’s also the number of people you’re trying to hit. So, if you’re trying to hit 60 percent or 70 percent market share in terms of mobile users, at that point you probably need both iOS and Android. It’s always going to come down to what the users are holding in their hands.

Read the full interview with MentorMate’s Stephen Fluin at Clutch.

android lollipop developers perspective1

Android Lollipop – A Developer’s Perspective

A Brave New World

The future of Android is here and it is bright indeed! The new Android 5.0 Lollipop is one of the most fundamental updates since the introduction of the OS, bringing a bold new visual style and a ton of performance enhancements. These changes provide new tools, but also lead to new challenges for Android developers. By mastering the components and guidelines of the new OS, developers will be able to create new exciting apps and reinvigorate old ones.

Android Runtime (ART)

One of the major changes in Android 5.0 is the new ART runtime that replaces Dalvik as the platform default. And what a change that is! The new runtime brings 64-bit CPU support, an entirely new memory allocator, ahead-of-time compilation and improved garbage collection. Users can expect upwards to x3 performance improvement in their applications, as demonstrated by the below graph from Google’s 2014 IO conference.

art dalvik speed
But how does this affect Android developers? Most apps should work just fine without any changes under ART. However, developers should be mindful that they can run into some issues if their app uses Java Native Interface (JNI) to run C/C++ code, or development tools that generate non-standard code, such as some obfuscators. Google has provided some helpful guidelines concerning these cases.

Material Design

Android 5.0 Lollipop brings one of the biggest visual redesigns the OS has seen to date. Material Design is based on what Google calls “unifying theory of a rationalized space and a system of motion” and it’s goal is to incorporate a consistent visual theme on multiple platforms, including mobile, desktop and wearables.

material design

The first step to creating a Material Design app is applying the material theme. To support older versions, a separate styles file will be required. Layouts and components in the application will have to follow specific Material Design Guidelines. These encompass the fundamentals of Material Design and both developers and designers must acquire a firm understanding of them before beginning development.

Of course the Material Design look and feel cannot be achieved without some new widgets. These include the new RecyclerView, CardView and more.

RecyclerView is a more advanced and more flexible version of one of the most used UI widgets in Android applications – the ListView. The power of the RecyclerView comes from the Layout Manager, which dictates how the items in the list will be ordered. This empowers developers to easily create imaginative and nonlinear item arrangements. Experienced Android developers know how to increase a ListView’s performance by using a pattern called ViewHolder. This pattern consists of a simple class that holds the references to the UI components for each row in the ListView. Now the new RecyclerView fully integrates this pattern and makes it mandatory.

CardView is a UI component that shows information inside cards and has a consistent look across the platform. Developers can customize the view’s corners, elevation and more.

Another new feature in Material Design is that UI components can now cast shadows. This is achieved by specifying an elevation value for a view, which creates the visual effect of the views floating in a 3D plane, while in fact they are two dimensional.

Animating transitions between activities is now even easier with the new Activity Transitions API. Designated shared elements between two views will automatically be animated when the user switches between activities.

Power Saving (Project Volta)

Project Volta was born from Google’s observation that roughly every 1 second of unnecessary active time (for example the processor waking up to do a task it could do later) results in a 2-minute reduction in stand-by time. In order to remedy this, the company takes an approach it calls ‘lazy first’. Lazy first is basically a principle that encourages developers to schedule non-urgent tasks to be executed in the last possible moment. This can be achieved with the new JobScheduler API that lets developers optimize battery life. by defining jobs for the system to run asynchronously, at a later time or under specified conditions. Such conditions include whenever the device is charging, idle or connected to a network.

New tools provide developers with improved ways of monitoring how their app utilizes the device’s battery. A simple way to obtain detailed power usage statistics since the device was last charged for a given app package, is by running the new dumpsys batterystats command: $ adb shell dumpsys batterystats –charged

Loading the dumpsys output into Google’s nifty Battery Historian tool will generate an HTML visualization of the data. The statistics including history of battery related events, approximate power use per UID and system component, global device statistics and others.

New Notifications

With the new Android 5.0 come new and improved notifications. These can now appear on the lockscreen, so users can read them at a glance, without unlocking their phones. Users can manage notification priority and toggle whether they want them to appear on the lockscreen from the Settings menu. Developers now have more control over how their notifications are displayed by setting their visibility property to Private, Public or Secret.

Support Library Additions

Wide spread adoption of Lollipop is still a ways off, but there are components that developers can use right now in order to bring their old apps up to speed. The new version of the Android Support Library comes with a substantial list of new additions, including the new Toolbar widget, RecyclerView, CardView and others.

Developers can start by letting their themes extend Theme.AppCompat which includes everything they need to support Material Design in previous versions. Using a base theme and overriding the final theme in the values-v21 folder is advised in order to retain full functionality for devices running Lollipop.

The new Toolbar widget is a generalization of the Action Bar pattern that gives much more control and flexibility. It can be placed as a view in the hierarchy just like any other, making it easier to interleave with the rest of the views, become animated, or react to scroll events. The Toolbar can also be set to represent the Activity’s action bar, meaning that standard options menu actions will be displayed within it.

In Conclusion

With Android Lollipop Google continues it’s attempts to innovate and grow its mobile platform on multiple fronts. In order to keep up with progress, developers must change the way they think about, design and develop their applications, in order to fascinate users and engage them on multiple levels.

Writing User Stories for Mobile Apps Adding Context 729x4231 729x423

Writing User Stories for Mobile Apps – Adding Context

I saw an interesting presentation at MobCon 2014 from Josh Bernoff over at Forrester Research on the concept of the Mobile Moment. This is the idea that there are two additional dimensions that you need to account for in your mobile apps: time and space. That is, when are your users using the app and where are they using it?

The Mobile Moment concept struck me as quite powerful: knowing where and when users are interacting with your app can help you craft more powerful, intuitive features. Mr. Bernoff provides examples for Starbucks in which the mobile experience might change if you’re not at Starbucks, standing outside a Starbucks, standing in line, at the register, and even after the purchase. Josh is now even talking about Micro Moments, in which the user is interacting with your app (or maybe, with only a push notification from your app) for a few seconds only. This got me thinking about the mobile apps I’ve been working on, and it made me think that I might be leaving out some important details in my users stories.

dilbert userstories

In the agile development world, user stories are king. They describe who will be using a feature, what they will be doing, and why they are doing it. Typically, they go like this:

As a [user role] I want to [perform some function] so that [some value is realized]

And this works really well as a starting point of discussion when reviewing product backlog items. The development team knows three dimensions of the requirement:

  1. Who will be using the feature
  2. What the feature is
  3. A notional idea of why the feature is important

Knowing these dimensions of the requirement helps guide the team to make the right decisions when there is ambiguity and helps guide the discussion of the story’s acceptance criteria (the how). Other forms of requirement development (you know, those requirements that start with “The SYSTEM shall…”) can often leave these dimensions out.

So the question then is: How do we account for the two additional dimensions represented by the Mobile Moment? The tried-and-true template doesn’t have any placeholders for where or when. Just who, what, and why. The easiest way is just to modify the template, adding the where and the when:

As a [user role], [in a certain mobile moment], I want to [perform some function] so that [some value is realized]

Let’s imagine that you are working on requirements for an urban touring app, and you want your users to be able to see information about different locations on a tour. You might write a story like this:

As a tourist I want to pull up Wikipedia articles about each stop on my urban tour so that I can learn more about each location.

urban street tour

The product development team would discuss that story and they may end up developing a feature in the app in which the user can pull up a map of the tour, choose their current location on the tour, and then tap a button to learn more about that location. While this works, it isn’t ideal. The tourist has to go through several steps to get to the information she wants.

How could capturing the mobile moment in the story help? Let’s re-write the story to include the mobile moment:

As a tourist on an urban tour at a stop on the tour I want to pull up a Wikipedia article about the current stop so that I can learn more about it.

The product development team would discuss this story and decide that the mobile device can detect that the tourist is on a tour, and where on the tour the tourist is, so they may develop a feature that launches the Wikipedia entry for the current location when they launch the app. They have captured that tourist’s mobile moment, providing her exactly what she wanted, when she wanted it.

The problem with including the Mobile Moment in the user story itself is twofold. First, writing user stories that coherently capture who, what, and why is hard enough. It often takes a while to format the sentence in a way that both makes sense and captures the intent. Adding the where and when factors complicates things even more and might frustrate the product owner trying to capture the requirement in the user story format. Secondly, not every story has a mobile moment. In fact, some apps, such as games, will have very few Mobile Moments.

Another approach to capturing the mobile moment is to place it in the body of the user story, near where the acceptance criteria reside:

As a tourist I want to pull up Wikipedia articles about each stop on my urban tour so that I can learn more about each location.

Mobile Moment: While on an urban tour, at a tour site
Acceptance Criteria:

  1. Item 1
  2. Item 2


This method keeps the Mobile Moment in the developers’ minds as they are reviewing the story and helps drive the discussion, but doesn’t get in the way of the user story itself. It may not be as effective as including the moment in the story template, but it also doesn’t get in the way if the story doesn’t have an obvious Mobile Moment.

A third approach is to place the Mobile Moment in the acceptance criteria themselves. I don’t like this option because it intermixes the important where and when with other run-of-the-mill acceptance criteria (i.e. the how). This diminishes their importance and top-of-mind relevance.

Some apps, such as Uber and Lyft, are defined almost entirely by their mobile moments, some have few or none at all (Angry Birds?), and most fit somewhere in-between. If you don’t have a way to capture these moments in your user stories, your development team won’t know about them and you’ll end up missing out on important opportunities. Find a way that works best for you to represent the where and the when in your user stories, and watch your development team turn those mobile moments into killer features.