All posts by jonathankohl

Three Keys to Mobile Application Design Part 2 – Social Connections

In Part 1 of this series, we looked at mobility and app design. In Part 2, we look at some social aspects to consider with mobile app design.

Social Connections

Mobile devices provide an interface to the internet, but more specifically, to our relationships. Coworkers can contact us when we’re on the move, and we can stay in near-constant contact with friends and family. Social connections help us keep in touch, and often provide the quickest, most up-to-date information on current events or developments in our communities.

Social connections are important, and can be powerful tools, even in enterprise or business apps. We’ve all heard about the massive growth of social applications in the consumer market, but social connections are important for productivity as well. Our professional social circles provide quick access to information to help solive problems, discover important news, or for recommendations on products and services. Social connections also create cohesion and improve our relationships at work in ways that dress up days and team building activities fail to do.

Here is an example: a few years ago, I was working with my friend Ken March. We were getting tired of our individual music libraries that we were listening to, so we decided to share our music with each other. We discovered others who had also shared music in the office, and we expanded our listening. We started chatting about music when we ran into each other in the office, and teasing each other about guilty pleasure tastes. Ken decided to set up DJ software so we could create playlists, and he also set up an IRC (internet relay chat) channel so we could instant message each other about the music we were listening to. With IRC, you can type in short text messages either to the entire group who subscribe to the channel, to one other person, or a sub-group, depending on how private or public your communication needs to be.

Ken expanded the application so we could create playlists and control the DJ software using commands in IRC. We could also use the Unix “say” command to broadcast messages using Text To Speech. Ken also added in extra hidden commands that allowed you to temporarily block a certain genre of music if you thought it was getting over played. If someone made a request and someone else had blocked it, the system would block it and provide humorous messages. We had a lot of fun with the system but soon learned it was a great channel for work or technical questions.

It turned out that the IRC chats were rarely about music – we found it to be a great channel to talk about work. We could ask for help, or keep people apprised of what we were doing on other projects. Instead of walking over and interrupting someone who was busy, the messages could be ignored and then read after a period of focused concentration. Once you were no longer busy, you’d catch up and answer the questions, and set up any follow-up meetings or face-to-face meetings.

The group expanded from the IRC server to getting together for lunches. We shared ideas about work, and learned about each other’s families and backgrounds. When one team member’s wife became ill, we were able to offer them support and help them when they were telecommuting. One team member and I found out we were both interested in game theory and estimation with uncertainty factors, so we spent some time on our own collaborating. We all ended up contributing to each other’s work in various ways, and we all enjoyed a boost in productivity.

Something appealed to us in that relationship that we developed. It touched an intrinsic sense of belonging, of collaborating and building something worthwhile. If one of us worked over time, it could feel incredibly lonely without our work buddies there with us virtually. Even worse, you lost contact to quick and easy information that could help you solve problems more quickly. Eventually, most of us moved on to other projects and other companies, but we all remained friends. We all miss that simple social program that helped us communicate, keep in contact and help each other out.

What were the keys for this simple application’s success?
1. It was entertaining
We could listen to an interesting variety music which helped make our day more enjoyable. The group input into the music selections kept them interesting for us. Some people had a great sense of humour and it was enjoyable to read their posts to the group.
2. It was social
We felt like we were part of a group, and we got to know each other better, which helped us work better. We were also able to share information at a much deeper and richer level than the brief daily standups we saw each other in.
3. It was fun
Once in a while over the course of the day, would also share funny cartoons, or youtube videos once in a while to add some levity. Once we got to know each other better, we would tease each other a bit, or send a silly broadcast message to try to cheer up someone who was feeling down that day.
4. It helped us solve problems
Each person using the program had a different background and expertise, and they had different experiences and access to information within the company. Many problems could be quickly solved with a message on our music channel.

Easy access to social relationships are an integral aspect of mobile devices and apps. When we’re on the move, we’re often alone, and these devices provide access to people so we have company. If we’re alone in a strange city, we can connect to our friends and loved ones and feel a sense of belonging, safety and calm.
My wife Elizabeth says that social networks seem to be full of the following:

  • Sharing our current thoughts and location with our network
  • Bragging and complaining

I’d also throw in pictures of cats and food to the mix. But it isn’t all frivolous; I enjoy finding out where my friends are at, and seeing pictures of their holidays. If a friend complains about a company that did shoddy work on their vehicle, I stay away from it. If another friend recommends a home handiman service, I contact them when I need work done on my place. This mitigates the risk of getting ripped off, or shoddy work.

In the work place, sharing ideas can be powerful, especially with knowledge workers. I have been working on a new product design, and I’ve been struggling with one aspect of the technical implementation. A quick message on a social networking channel resulted in 4 possible solutions from a programmer friend. We also brag about accomplishments, giving shout-outs or kudos to other team members who we think have done a good job, or have simply shipped something after a long release cycle. We also complain about vapor-ware technology, vendor relationships that have gone wrong, or tools that don’t provide value. This is valuable information to utilize as we work on and lead our own projects.

Social connections help us feel motivated when we are on the move, and they can be a tremendous support when we need motivation, or a quick answer to a question or a problem. They are a great fit with mobile technology, since they help us connect to people, knowledge and allow us to share experiences from virtually anywhere.

Stay tuned for Part 3 of 4 of this series.

Three Keys to Mobile Application Design Part 1 – Mobility

While many of you know me for my testing work, I also do product management work, including business analysis and technical design for applications. I help clarify a vague product idea into something with a clear vision that is concrete enough for programmers and designers to help implement, with the right mix of features to satisfy and delight our end users. Here are some lessons I’ve learned doing this work in the mobile space.

When you start designing a new mobile application, you are probably like me, and refer to applications that are familiar. You look at past projects, at programs you enjoy using, or have impressed you. If you are new to designing mobile applications, that often means you will look at web apps and PC apps first, because that is what you are most familiar with. Then you pull out your smartphone, and look at the apps you like and use the most there. That’s exactly what I did when I started out, and while I felt like I had adjusted to a new paradigm (smaller screens, less powerful devices, different network technology, etc.) I felt like something was missing. I couldn’t quite put my finger on what was different, but the apps I use on my mobile devices, and the apps I helped create demonstrated it to me. We are going through a major shift in technology, and the software we use is moving toward a combination of mobility, social connections, and gaming and entertainment.

In this four part blog series, we will look at each of these areas of consideration when designing mobile applications.

Mobility Features

If you are new to mobile app development and use web and PC apps as your guide, you might overlook something important. Worse still, if you are used to an enterprise application development, stakeholders often just direct us create a subset of an existing web or PC app for mobile devices. While that is an aspect to consider with mobile apps due to less screen real-estate, and their one screen at a time focus, we often overlook the most obvious, and one of the most compelling characteristics of mobile devices: mobility itself.

When we are out and about, away from our desks, we don’t have the luxury of comfort and time. Think about it for a moment: these devices are used in all weather, in different locations (outdoors, in buildings) with different network strengths, while people are moving (walking, jogging, cycling, in a vehicle, flying, on public transportaion.) Imagine the difference between needing access to information or using an app on a warm sunny day in a beautiful park, vs. using it in a severe rain storm, outside and you forgot your umbrella. What effect might the different lighting conditions have on your screen design colors? Will their wireless services work better in good weather or poor? What impact might the weather have on the emotions of the user, and how much of that will be projected on how well our application performs? I’d wager that the user who is miserable in the rain will have much less patience with usability issues, or anything that slows them down with our app than the one who is relaxing in the park.

Context, and how the devices and applications are used on the move are important to take into account. Mobile devices represent a blurring of physical (hardware) and the virtual (software and services). When I’m designing an app for the web, or for PCs, I don’t think of the hardware that much other than to consider things like processing and memory. With mobile devices, we can tap into physical features of the devices to help create a different user experience that fits mobility better.

Here are some areas to think about when designing for mobility:

  1. Take advantage of mobile features
  2. Ensure your app is mobile-friendly

Mobile Features

When I’m on the move, I need my mobile device and apps to provide the following:

  • Access to information on the web (look something up, settle a friendly dispute)
  • Search for services nearby (for something to do)
  • Map and location services (so I can figure out where I am, and how to get to my destination)
  • Contact with others who aren’t with me (to communicate, co-ordinate and keep in touch)
  • Entertainment apps (play a game, watch a video or listen to music to help pass the time when I’m stuck somewhere or waiting)
  • Productivity (I’m here, I may as well see what work I can get done)
  • Utilize movement sensors (to help with most of the above)

Mobile-Friendly Design Considerations

Using a mobile device when you’re on the move has special challenges. It’s harder to see the screens, more difficult to type and enter information, and people often need to do something quickly. While you’re designing an app, here are some considerations to make your app more user-friendly for people on the move. Make sure you test your app out under different conditions while on the move, in different lighting, different weather, with different levels of urgency.

  • short workflows (don’t force people to spend a lot of time trying to reach a goal or get something done)
  • easy inputs and interaction (make things easy to see, and simple to interact with)
  • reduce typing (it can be painful to enter in too much text, so look for ways to reduce inputs)
  • colors that work in different lighting (watch out for very bright or very dark colors that could get washed out)
  • a clean, focused design (avoid bloat – keep it simple so people can work with the app easily) See: iOS Human Interface Guidelines for more.
  • great network performance on wifi and wireless broadband, with different network speeds, strengths (when I am away from home or the office, I have to depend on different networks, and I will move between them)

An app that takes advantage of mobility features will fit into the contexts that the devices are used in. An app that is just a stripped down web or PC app probably won’t. Remember: if the app isn’t easy to use on the move, it won’t get used.

Still puzzled? Spend time observing people around you, and if you can, spend time with your target users. You’ll be surprised at when and where they depend on mobile devices, and at what they enjoy, and what makes them frustrated.

(Thanks to my friend and mobile developer Jeremy Gale for helping me brainstorm mobile features for this post.)

Note: I first introduced some of these ideas in an interview with Heather Shanholtzer for Techwell in 2011: The Future is Mobile Technology.

Creating a Test Lab for Mobile Apps Testing – Part 3

In parts one and two of this series, I introduced some ideas on building a physical test lab for testing mobile apps. In part 3, I’m going to talk about devices. This is all based off of my own experience.

Purchasing Devices

This is the the most difficult aspect of setting up a test lab. I’m not going to make any hard and fast recommendations, because by tomorrow the market will probably change. You will need to research and adjust depending on what your current needs are.

Emulators are fine for basic functional testing, but you’re going to need to do testing on the real thing, whether your focus is on automated or manual testing. The devices have sensor and touch interaction, as well as network and other physical aspects that need to have real-world testing.

You will need to consider the following:

  • both smartphones and tablets
  • different hardware and operating systems or versions, per framework
  • devices with different screen sizes
  • different wireless broadband carriers
  • cables and other accessories for charging and syncing (never hurts to have extras)

Each of these areas will yield different results when testing. For example, I frequently test with a smartphone and a tablet at the same time, and it’s amazing how the app can behave or appear differently on one or the other.

Also remember that a platform for testing is a combination of a hardware model, operating system version, and if you are using network connections with your app, wifi, wireless broadband, different carriers and any special software carriers install.

Purchasing devices is a balancing act, because the market is so dynamic. You will need to get a reasonable number of devices for testing the real thing, but you can’t buy them all. I look at the following to help guide what I should buy:

  • What platforms are our customers using?
  • What are the most popular smartphones and tablets on the market?
  • What are the most popular mobile browsers?
  • What platforms are known to be problematic? (aka. problem child devices)
  • When is the newest thing coming out? Do we need it for testing?

To figure out what you need to do using this information can be challenging. Here is one example. If you don’t know what your target customer base are using, you can start with information you already have. If you already have a web presence, or a web app, find out your web traffic stats. Are people using mobile browsers? What brand is the most popular? Can you get a visual breakdown? This information will usually breakdown according to brand, such as Android or Apple iOS, but it won’t give you specifics, such as an iPad, with 1st gen. hardware running iOS version 5.1.1. But, if you know that Apple iOS devices are the most popular, you can find out information about what the most popular devices are in the market, and assume that your customer breakdown is likely very similar. Look at a chart of popular versions, and try to replicate that in your lab – ie. stock up on the more popular devices, with less of the less popular devices. Not perfect, but it’s a good heuristic.

If you are looking at mass market applications, there is some information out there to help. For example, this chart this chart by Net Marketshare would indicate we should focus a good deal of our efforts with iOS device testing. Here is some more information to help deal with proportions of devices to purchase: comScore Reports May 2012 U.S. Mobile Subscriber Market Share. Akamai has an interesting report on mobile web browser breakdowns here: Akamai IO.

Notice that these reports are already out of date. This information is difficult to get, and I doubt anyone really knows exact numbers. It’s important to research and look at a lot of data to help inform you. When you spot trends, that should help you with proportions.

Some people think that Apple devices are much easier because there are fewer hardware devices, and they are all made by one company. However, even with Apple, you can end up with a lot of platform combinations. Take the iPhone for instance. Let’s say we are going to have 3 devices: an iPhone 3GS, an iPhone 4, and an iPhone 4S. Since Apple encourages people to upgrade their OS, we have decided to stick with iOS 5, the latest version. At the time of writing, there are 4 iOS versions out there: iOS 5, iOS 5.0.1, iOS 5.1.1. Also assume our app requires an internet connection. If we choose 3G, the most popular wireless broadband networking type, and wifi, then we have 24 platform combinations. What if we now need to test on 4G now? Add 12 to the mix for a total of 36. That can be a lot of regression testing. If you want to optimize, you may decide to elminate everything but the latest version, 5.1.1. If you do that, try to find something that gives you an indication of upgrade proportions, like this information: iOS 5.1.1 Upgrade Stats. You may not want to upgrade all of your devices at once, but keep some back to mimic what is happening in the real world.

Here is a recent plan for an iOS test lab:
Apple iOS (all on the latest, 5.1.1):

  • (1) iPhone 3GS
  • (2) iPhone 4
  • (3) iPhone 4S
  • (1) iPod touch (they aren’t as powerful, and are great for finding problems you don’t see on other devices)
  • (1) iPad first gen
  • (2) iPad second gen
  • (3) iPad third gen
  • (at least 1) whatever the newest iOS device is when it comes out(these are always hugely popular)

Android, Windows Phone and Blackberry are more difficult, not just because of the different handset manufacturers, but there is more of a proportion of devices across versions of their OS, or OS family. For example, Android has a nice graphic of their Android OS Distribution. When setting up a lab for Android devices, I would try to replicate that pie chart in my own device distribution. For older platform families like Windows and Blackberry, you will have even more variations to consider, but temper that with how popular they are in your target market.

For mass market applications, or web testing, Brad Frost has a fabulous blog post test on real mobile devices without breaking the bank, and this blog post from the Mobile in Higher Ed blog is also very useful.

It sounds expensive, and it can be, but compared to test workstations and servers, it isn’t that bad. You can get multiple test devices for the price of many test servers when you take hardware, OS and required software into account. You will have to research using your favorite search engine, and you’ll need to stay on top of new developments, because you will regularly need to acquire new devices.

Looking for ideas on how to test mobile devices? Check out my I SLICED UP FUN mnemonic to help generate ideas.

Creating a Test Lab for Mobile Apps Testing – Part 2

In Part 1 of this series, I introduced some ideas on building a physical test lab for testing mobile apps. In part 2, I expand on those ideas.

Storage

You will want a clean, dry, secure storage area for devices to be kept in when not in use. I’ve used a drawer that locks with toolbox liner at the bottom to protect the cases and keep them from moving around. Here is an example: toolbox liner. The devices are small and disappear easily, so secure storage is a must.

Set up a sign-out sheet with each device noted by OS, version and serial number. Also create tags for each power/sync cable for each device so they can be kept track of if they leave the test lab. I used a label maker for this. There is nothing worse than losing your hard-earned test devices to other groups, or not having devices around when you need them. Cables disappear the most, so you need to make ownership for your lab visible. Think of the washroom key for a service station on the side of a busy road – the small key is often connected to something larger to make it more visible to help prevent it from getting lost. I always chuckle when I see a key on a chain with a hubcap attached, and I try to make my lab cables visible in some easily identifiable way.

Power Station

You will need access to power to charge the devices so they are available for testing when you are. It’s incredibly frustrating when you are getting ready to test on a device and find out that the battery is dead. If you can’t get power into your device storage area, set up a charging station in the lab.

Set aside counter or desk space near a power source, and add the following:

  • at least one power bar to plug in multiple devices
  • several power cables for the devices
  • toolbox liner or something similar on the surface to keep them from moving around

Lab PCs

You will need computers to manage the devices for testing, troubleshooting and other tasks. Consider at least one machine for each platform family. Here are four popular platforms. Your team will have their own mix of devices that they are developing for. Get the most powerful workstation you can afford for each platform; mobile app development tools can be large and complex.

iOS (Apple)

You will need at least one Mac for emulators and device management, and pulling screenshots and other information from the devices. Install XCode for emulator use, Also consider installing the Network Link Conditioner to help simulate different network connection conditions with an emulator. Install the iPhone Configuration Utility for getting stack traces, managing licenses, etc.

Android

You will need at least one machine with the Android SDK installed for managing Android devices and emulator use. Many developers use this within the Eclipse IDE, so talk to them about the correct combination of tools for your shop. The operating system doesn’t matter for Android development.

Windows Phone

If you are supporting Windows Phones, you will need a Windows machine with at least Windows 7 and the Windows Phone SDK and related tools.

BlackBerry

The new BlackBerry SDK supports several languages and implementations, so you’ll need to find out which version to install, and what other libraries need to be installed. I don’t think OS matters, but I have seen installation instructions recommending at least Windows XP or Vista.

Wireless Broadband

Data plans or other contracts for monthly wireless broadband access are important to test. I would get a reasonable plan for each device, from at least two local telecom providers. Try a larger provider, and a smaller provider (like a discount provider) to get more variation in wireless broadband technology. There is a huge diversity in what different carriers use to deliver this to the end user, so try to get some variation

Other

You will need internal test email addresses, and phone numbers for each smartphone for testing. Also get at least one developer license for each platform your team supports for your test lab. You will need test ids with the App Store on Apple for making purchases, or installing apps from the app store. You will likely need to do this with other stores as well such as Google Play and others for each device type you have.

Looking for ideas on how to test mobile devices? Check out my I SLICED UP FUN mnemonic to help generate ideas.

Creating a Test Lab for Mobile Apps Testing – Part 1

Some of you have asked me to expand on the physical aspects of mobile app development that I described in my article: Mobile Challenges for Project Management. If we have a testing burden when we develop mobile apps, what sort of considerations should we take into account when we are setting up test labs, when using real devices? Here are some pointers from my own experience.

This is part 1 of a 3 part series.  Feel free to add comments for anything I’ve missed.

The Room

You’ll need space where you can set up PCs for managing devices and using productivity tools, a place to store devices when they aren’t in use, space for charging devices, and plenty of space for people to move around with the devices while testing. (The mobility side of mobile devices needs to be tested.)

Network

Wifi

I prefer to have at least two dedicated test wi-fi beacons to test network connections and transitions between wifi, and wifi to wireless broadband. I prefer small, cheaper devices that have weaker strength so it is easier to set up test conditions for apps that require network connections. I like to have these for test purposes only, and it is better that they have weaker signals (so testers can walk away and get weaker wifi for testing), and can be turned off or unplugged for testing outages, etc. Also since they are smaller and weaker, you can set up two in a lab and transition between the two by moving in the lab.

Simulate Dead Spots

If you don’t have an office dead spot (no wireless broadband or wifi connectivity), or one that is convenient for testing, you may need to set something up yourself. If you have an elevator or other known dead spot near your office, that works well. In some buildings you don’t.

Consider building a faraday cage to test for dead spots. Try doing network/web searches or submissions within a deadspot, or transitioning into or out of one. You can use an old microwave, but make sure you cut off the power cord so it can’t ever be powered on accidentally. They are simple to use, try a web search or submission, or any action that requires a network connection, and put the device into the microwave. It will instantly be in a dead spot.

You can also buy them from providers, or make one out of wood and wire mesh:

  • build a box out of 2×4’s, hinges and wire mesh
  • create a door in the front
  • wrap the box with wire or brass mesh
  • attach a ground wire to the box

There are different instructions online on how to make them.

To test outages, or performance issues, and to monitor and measure performance, page sizes, security, and other things,  you may want your own network for testing. It’s a good idea to have a separate test network, so you can quickly create scenarios, outages, or easily monitor mobile app traffic, whether it is a physically separate network, or a virtual network without interrupting other work.  Your administrators can figure out the implementation.

Stay tuned for parts 2 and 3.

Looking for ideas on how to test mobile devices? Check out my I SLICED UP FUN mnemonic to help generate ideas.

Elisabeth Hendrickson on 15 Years of Consulting

Elisabeth has been in business for herself as an independent consultant for 15 years. She has a great blog post about it here: Happy Birthday Quality Tree Software. In the post, she describes the workload and the challenges. I’ve been an independent for about half as long as she has, about 7.5 years, and my experiences mirror what she describes. I too get queries from aspiring consultants who ask for advice. Elisabeth talks about long hours, hard work, and challenges. This quote in particular resonated with me: “The bottom line is that running a business, any business, is hard.”

If you are curious about going out on your own, this is a good piece to read. As a business owner, you are constantly looking at ways to be profitable, and dealing with challenges and changes in your environment. What do you do when you work very hard at a new revenue stream and it doesn’t work? What happens when a popular source of revenue loses favor in the market and you have to start over with something new? What do you do when people copy you, and your business model and a reliable source of revenue slows to a trickle because of market saturation? It is a balance of looking at your cashflow, looking at your financials and adjusting, taking risks, failing, succeeding, and adjusting some more. Also, a lot of what you do as a business owner is tedious – the logistics of running a business can be a big time sink, so you have to balance activities constantly to keep up with market forces. Elisabeth is correct, when you get it right, it is incredibly rewarding, but be prepared to put in time and effort, and to be able to motivate yourself through the boring parts, the low parts and the really hard parts. And sometimes, you have to reset your business and start over again.

Public Course: Testing Mobile Applications, in London, UK, May 10-11

Working with Electromind, I’m offering a 2 day public course on Testing Mobile Applications in London, UK, May 10-11, 2012.

Register here: Testing Mobile Apps Registration

Testing Mobile Applications Workshop Description

2 day tutorial by Jonathan Kohl.

Applications for smartphones and tablets are incredibly popular. Teams are facing pressure to deliver testing quickly and successfully on mobile devices. When faced with a mobile testing project, many testers find it tempting to apply the same methods and techniques used for desktop applications. Although some of these concepts transfer directly, testing mobile applications presents its own special challenges. If you follow the same practices and techniques as you have before, you will miss critical bugs. Learn how to effectively test mobile applications, and how to add more structure and organization to generate effective test ideas to exploit the capabilities and weaknesses of mobile devices. Hear first-hand experiences with testing mobile applications and discuss how to address various challenges.

Note: Participants must bring their own mobile device for course exercises. This is a hands-on course.

Public Workshop: Testing Mobile Applications, in Vancouver, May 25

As part of the Agile Vancouver Quality in Agile conference, I’m offering a 1 day public workshop on Testing Mobile Applications in Vancouver, BC, Canada, May 25, 2012.

I will also be speaking about testing and value during the conference on May 26.

Register here: Quality in Agile Conference Registration

Testing Mobile Applications Workshop Description

1 day tutorial by Jonathan Kohl.

Applications for smartphones and tablets are incredibly popular. Teams are facing pressure to deliver testing quickly and successfully on mobile devices. When faced with a mobile testing project, many testers find it tempting to apply the same methods and techniques used for desktop applications. Although some of these concepts transfer directly, testing mobile applications presents its own special challenges. If you follow the same practices and techniques as you have before, you will miss critical bugs. Learn how to effectively test mobile applications, and how to add more structure and organization to generate effective test ideas to exploit the capabilities and weaknesses of mobile devices. Hear first-hand experiences with testing mobile applications and discuss how to address various challenges.

Note: Participants must bring their own mobile device for course exercises. This is a hands-on course.

 

First post on my newly designed website

Welcome to the new kohl.ca website. The new design is mobile-friendly and has more features and information. We’re still working out some kinks and improving content; my original blog dates back to 2003, so we’ve had our work cut out for us on the update. If something is missing or broken, please contact us.

If you are reading this post via RSS, your reader is pointed at the new feed, and you are subscribed to any new posts. If you don’t see this in your feed reader, update or add: http://www.kohl.ca/feed  to your RSS reader to subscribe to my blog.