Category Archives: Mobile Research
Mobile development is no longer something entrepreneurs can ignore. Last year, cellphone sales surpassed desktop computer sales for the first time. There are now 3.4 billion mobile devices in use. Every minute, people share over 100,000 tweets, 700,000 Facebook posts and 40 hours of YouTube video; and most of this is now consumed on mobile devices, not computers. As Christina Warren put it in Mashable back in 2012: “Having a mobile strategy shifted from ‘nice to have’ to ‘must have’ for all businesses.”
There are two main ways of delivering content to mobile devices: websites and apps. Websites are accessed through a web browser. The advantage of a website is that it is built in a universal language (HTML) that can be accessed on any platform, including both mobile devices and PCs.
Websites therefore are relatively easy to develop and open by default to a large base of users. Sebastian points out that the disadvantage is that the user must know where to go—to download the content each time they want to use it.
Native mobile applications are made for a specific proprietary platform and downloaded from an app such as Google Play or the Apple App Store. They have the advantages of being tailored to the chosen device, which tends to make them better for unusual or process intensive apps. They are also easy to find from the app store and are readily available at any time, once they are downloaded. Unfortunately, a native app can be a lot more difficult to develop, since things like the user interface may need to be developed from scratch, and is only useful in the platform for which it is developed. Porting an app to additional platforms involves even more time and money.
The main disadvantage of hybrid apps is performance. The need to translate code means that hybrids tend to make less efficient use of a device’s hardware. If an app will be especially hardware intensive, it is better to make it native.
When developing for mobile devices, one size does not fit all. The decision to use a website, native app, or hybrid should not be based on what developers are most comfortable with, but on what is best for the project. For example: prototyping in HTML is a false economy if you know it will need to be made native later. Instead, developers and entrepreneurs should make decisions based on the project’s long term goals and needs.
Video: Why to use mobile apps
Video: What is programming language
Video: Hybrid Apps
When starting to build your app, there is the issue of which platform should be used. If you decide your app is more suitable to be distributed by a carrier rather than an app store, Renee Szuhai notes that there are some important things to consider. While working with carriers is a viable option, there are also manypotential challenges, and developers should be clear about and what they hope to achieve before they begin negotiations.
For example: Who is the target audience? How will billing be arranged? What platforms are being targeted, and how will integration be organised? Contract negotiation is another issue: Will the app be geared toward particular carriers or regions? How widely will the app be distributed; is it proprietary, national, or global? Then there is Over-The-Air (OTA) functionality and Application Programming Interface (API) support to consider.
Fortunately, the Global System Mobile Association (GSMA) has launched its ‘OneAPI’ pilot programme in Canada. OneAPI is an agreed standard for Network APIs among different mobile networks. Since OneAPI does the work of negotiating with carriers, developers can use it to make their apps available nationally to all carrier customers in a single step.
The GSMA website LINK explains
OneAPI in this way:
The OneAPI Exchange is an infrastructure that provides developers with access to mobile network operator assets via APIs. This infrastructure federates different operators into one unit providing a wider reach for developers.
As a developer you will set up a relationship with one mobile network operator. This operator will expose RESTful APIs to you. Once you have implemented these APIs and published your app, the API calls are federated through the OneAPI Exchange backend infrastructure to all of the other participating operators. This allows you to increase your reach to all subscribers of the other operators.
Negotiating with individual carriers can be a difficult experience, as Renee notes. Rogers is the only Canadian carrier that currently has a developer programme, and using this might limit an app’s distribution to Rogers’ customers. On the other hand, for all but the largest developers it can be very difficult to attract the attention of other carriers such as Bell and Telus. Renee likens the experience to ‘swimming through peanut butter,’ noting that even finding the right person to contact can be a trial, after which negotiations can drag on for months. Then there are the issues of arranging integration for billing, messaging, location, payment, and so on. The whole process, Renee notes, can be a bit of a headache.
For app developers, working with carriers is an option, but one that comes with its own issues and challenges.
Video: Working with Carriers
The User Experience with Ilona Posner
During the past few years, there has been an increase in the need for User Experience (UX) techniques to create and test products and services. Ilona Posner gives an excellent introduction and numerous examples of UX and how it can really change the way you see mobile design and development.
Why is it important to think about user experience design when creating your mobile product? Ilona presents compelling reasons why user experiences are important. Not only the economic traction but also the overall success of a product can be affected by the user experience design.
What is User Experience?
Defined by the International Organization for Standardization, user experience is “a person’s perceptions and responses that result from the use or anticipated use of a product, system, or service”. The whole process of the user experience is subjective and is shaped by the users: emotions, beliefs, perceptions, and behaviours to name a few.
From the moment your user finds your product, to when they use it, and even after they stop using it, UX is important. Every aspect of the journey through your product should be important to you when studying the user experience, it is always an opportunity to improve and understand your product as it relates to your customers’ experience.
You Are NOT a User
Ilona has created a mantra for her students and teams: “I am not a user.” The mantra is there to guide designers to remember that their perspectives are of a maker, not a user. What you see as obvious to you, might not be as obvious to the user.
You may know the manual of your product inside and out, but the true user doesn’t know or even think about your manual. The reality is, they will never go to a manual and only in true distress will they go to some form of help button.
When building and testing your mobile interface, keep in mind that you are tainted by the knowledge of the project. You do not posses the objectivity to be able to successfully understand how your product will be understood.
The Importance of The Prototype Stage
With a little imagination and creativity, you can “try” out your product before coding or building it. Paper Prototyping is where you draw out your designs step by step, working through the functions of your platform. One of the goals is to minimize the risk associated with a failed product, in turn saving both time and money in building. This is also the time for you to experiment and try different ideas, which may lead to greater innovation.
Ilona’s presents more examples on UX design and knowledge in the video’s below:
Video : User Experience Design
Video: User Research
Slideshare from Ilona’s presentation:
Wayne makes a key point about testing: “it’s not just about finding bugs in the software, but to really making it better.”
Wayne presents testing as a series of “zero sum games.” Budgets and deadlines mean you can’t test everything, so it’s important to decide the kinds of testing that are going to be the most effective. In other words, testing itself needs to be optimised. It should get the most ‘bang for your buck’ and help to actually fix bugs, rather than just collect them.
Top 4 Recommendations for Testing
Since not everything can be tested or fixed, Wayne introduces a few scientific approaches to help pare down testing to make it more manageable. Wayne’s recommendations for testing include the following:
1. Have a Plan: When you decide to test, it’s important to have a plan. Organize your limited resources, and schedule your testing to be effective as possible. It’s a good idea the spend time identifying ‘high-yielding’ tests and prioritizing ‘high-yield’ areas of code or features before setting up testing environments and thinking about test coverage.
2. Variety is Essential: Don’t always use the same data. Use different types of tests to compensate for each test’s weaknesses.
3. Knowledge is Power: Learn from other testers’ experience and pay attention to what is happening in the development practices, then ask questions, read the bug reports, and see what is breaking for others, so you don’t repeat the same mistakes.
4. Be Results-Oriented: Create priorities about what needs to be tested and work on the goal of choosing quality over quantity when testing. Avoid default test data, target critical bugs in main features, reduce and eliminate redundant tests, and generate ONLY quality bug cases.
Continuous Integration is just what it sounds like: a development process in which team members’ work is integrated continuously. Integration happens multiple times per day, and is tested with an automated build to find errors whenever they crop up. Wayne believes that continuous integration is a key aspect of modern agile development practices, since constant iteration requires constant testing to make sure each version holds together.
Wayne uses the analogy of Lego blocks: When building, you want to make sure that the individual blocks and the way they are connected work, and not wait until later to see if your construction falls apart. Under older integration processes, developers might spend as much time trying to integrate the unwieldy pieces of their creations as building them. Continuous integration is about avoiding that problem by identifying and squashing bugs as soon as they occur. By reducing the risk of unpleasant surprises later in development, it also allows you to get a good idea of the quality of your code and what kind of progress you are making.
Wayne sounds a note of caution: Automated testing will not identify all bugs, log issues, or help to debug software. Think of it as a part of a developer’s repertoire, rather than a replacement.
The Pitfalls of testing
Wayne outlines three pitfalls of testing: Human Bias, Group Think, and Inference and Assumptions.
Human Bias: We all have biases due to our backgrounds, and these may influence our decisions. While transcending bias is easier said than done, we all benefit from becoming aware of our bias and how it might affect our testing and objectivity. If you are aware of your bias, you might be able to make choices you otherwise wouldn’t have.
Group Think: Teams have their own biases as well. If everyone is just agreeing with each other, we might be creating ‘yes teams,’ instead of creating teams that test assumptions.
Inference and Assumptions: There is an additional pitfall: Obvious patterns can fool us into jumping to erroneous conclusions. Indicators are not results: They just indicate those areas where we should test for results. For any testing, past experience should be only used as a guide and not as a conclusion.
UPDATE since Wayne’s presentation at MEIC!
Since Wayne’s presentation on testing at MEIC, Steve Krugh has been recently acknowledged Wayne in a new chapter on mobile in his 3rd edition of “Don’t Make Me Think,” a very popular and must have book on UX. Steve Krug is one the leading authorities in research in human-computer interaction and web usability. Wayne highly recommends Steve’s book for everyone who builds mobile apps to buy this book.
Steve’s website: http://www.sensible.com/
Video 1: Introduction to testing
Video 2: Mathematics of Testing
Video 3: Continuous Integration
Video 4: Pitfalls of Testing
In this two-part presentation with Krista Napier from IDC Canada, Krista shares key information about when and how to conducting mobile market research. Her tips include how to focus a company’s market research to guide future mobile product development. For example, to validate a concept, market research data can be used to determine if there is a demand for the product.
Krista lists the following four reasons to conduct market research:
- Opportunity to make money
- Market Readiness
- Geographic Differences
Is there an opportunity in the market to make money? Searching for opportunities means looking for gaps in the market where customers’ needs or wants are not being met. Your mobile services and products may meet those customer demands, and the customers will be willing to pay for your solutions.
Making sure that there is market readiness for your mobile product. There might be an app you want to build, but the customers were not yet ready to accept. If the market is not equipped to use the technology, then wait for a better time to build it.
Your market research can look at geographic differences. Your mobile product will not suite everyone, so your market research will give you the ability to create a niche within your target market.
Market research can also provide insights to positioning; i.e., how you must position your mobile service relative to other competitors in the market. If there are many competitors in your market or not that many, it might be a question of large or minimal amount of demand.
Krista’s Research Tips
Krista offers two main tips to help with conducting market research: 1) the importance of the quality and quantity of your metrics and 2) the location they came from.
A very important part of market research is to be aware of the quality of the source of the data. Not only the number of respondents, but the quality. The quality of respondents has a strong impact on research results. They need to come from a diverse pool that answered without bias, again with the end goal of having accurate data. Respondents who have already used your app will be biased and should not be used. There needs to be an ample amount of respondents to create an accurate result.
Finally, customers’ data from Canada should not be used to for American market research and vice versa. Being in Canada, it’s better not to assume that US trends can be used cross-geographically. There are different dynamics of vendors and adoption patterns in the US compared to Canada. Using trends from one country for another will skew your strategy for your mobile apps.
Video 1: Market Research Part 1
Video 2: Market Research Part 2