Tag: android

10 Tips and Tricks for Running Live Demos on a Mobile Phone

Here’s my short list of some things to consider when you demo your company’s mobile apps to a live audience. I’ve accumulated this list over the last several years as the team I’m on does a lot of showing off apps on iOS, Android and Windows Phone. We’ve also seen quite a few demos from customers and at industry conferences.

While most of these tips apply to personal demos where you have the phone in your hand while standing in a tradeshow booth, I’m actually talking about projecting demos on a big screen in front of a live audience, or during an internet video conference call with screen sharing.

  1. Screen brightness. Adjust the screen brightness so that the screen is not too dark and not washed out, and temporarily disable screen brightness auto-dimming. Auto-dimming is where the phones background light gets dimmed usually around ten to fifteen seconds before the screen auto-locks.
  2. Turn off auto-lock. Temporarily disable your auto-screen lock (if your company policy permits it). There’s nothing more aggravating than talking about something for a few minutes and then when you turn your attention back to the phone you have to re-enter your unlock code. I’ve also seen this happen to people on the screen behind them and they didn’t notice but the audience could see it.
  3. Silence the phone. For demos that don’t need sound, which is probably most demos, turn your phone’s sound all the way to “off”. Most phones beep, tweedle and pop as various things happen in the background, so spare your audience by making your phone silent.
  4. A/C Power. Plug your phone into a power outlet. While this may seem obvious, I’ve seen a phone die during a major industry conference plenary session.
  5. Shutdown extra apps. Shut off any unnecessary apps that will consume memory and CPU. You want your demo to run as fast as possible.
  6. Remove unnecessary icons. Clean any non-professional app icons from the navigation screens you will be showing live. On a few rare occasions I’ve seen some fairly disturbing icons that had no place in a professional presentation.
  7. Verify the type of demo camera. Ask ahead what kind of demo camera the conference has for mobile phones, one of the most common ones is called an ELMO. These are devices where you set your phone below it and it has a camera that points downward at the phone and connects to a projector through a switch. So, when you go to show off your app you turn a switch that connects the ELMO (or similar device) to the projector. Some of these are terrible and some are great. I use an IPEVO Point 2 for some demos because it’s portable and I trust it.
  8. Test demo camera. Test your demo camera well before your presentation. You may need some help from the conference’s audio visual team. Make sure your phone in focus, check if you can see the application details, look to see if the background colors aren’t too white and washed out, etc.
  9. Cache local data. Cache your data when possible. If you plan on connecting to remote data sources, consider moving that data onto a local SQLite database on your phone.
  10. Check internet connection. Check your internet connection beforehand. Conference are notorious for having limited cell and wireless coverage. My recommendation is always create a movie backup of your most important demo points. Yep, I’m 100% serious. With an IPEVO Point 2, for example, you can project the camera image in a desktop app and use software such as Camtasia Studio, which also offers a free trial, to create a movie with audio too. Also, a note to phone developers here, it’s a best practice to check if your app has an internet connection and to let your users know if the connection goes away, for example: https://www.andygup.net/?p=155.

What version of Android do I target?

The version of Android that you need to develop against really depends on your customers and your requirements. If you are simply planning on aiming for the latest and greatest version of Android there are some facts you should be aware of:

Approximately 86% of Android users are running Android v2.2 – 2.3.7 (Gingerbread). Less than 5% are running v3.0 and above (Honeycomb and Ice cream sandwich). And, only 1% are using Android v4 (Ice cream sandwich)! It’s true, and you can check my stats from Google here.

To add some context, Android v3 was released in February 2011. Android v4 was released in October 2011, which was less than one year later. That’s two major releases in one year, and there’s already press on Android v5 being released in 2012. Most software companies have major release cycles over several years for a variety of reasons including allowing time for their customer base to adopt new technology. Of course, consumers and organizations are going to continue to trade-in their smartphones for newer versions. But, that’s going to take time as contracts expire and phones wear out.

So, if you plan on building an app within the next few months that is mostly focused on the newest, coolest features and hardware there may be many potential customers that can’t use it. It’s something to consider. My suggestion is to check your current technical requirements against the deprecated list in Android v4 and see if all your functionality is forward compatible. Then weigh any new features that are only supported on Android v3 and v4 against how many of your most important customers will be able to use it and be willing to pay for it.

It’s interesting and disturbing at the same time that Google is two major operating system versions ahead of the vast majority of their customers. I’m not 100% certain, but I think this is an unprecedented position in the software industry. My take-away is if your product is targeting a much wider swath of users than the bleeding edge adopters, then you need to be careful about what new features you implement.

If you spend too many development cycles building cool new features that your customers don’t need or can’t use for another six months to a year, then it’s potentially a wasted effort, or worse.  And, if your strategy is to be ahead of the curve and entice customers with new features, then don’t get so far ahead of the curve that customers can’t keep up or you’ll risk leaving them behind.

So you want to build a mobile app? Not all mobile apps are created equally

Most smartphones users I know ditch apps pretty quickly if they don’t work or end up being clunky. So, if your company is considering offering mobile apps to your customers you should be aware of a few things.

Buy a Smartphone. If you don’t already have a smartphone then you should go out and buy one. Then download a number of apps that interest you and try them out and see what you like and what you don’t like. For example, if you do the shopping for your family you might consider trying out a bar code scanner app that lets you compare pricing. Some scanner apps may work faster than others. If you don’t own a smartphone then you won’t be able to understand what a good app is.

Likes and Dislikes. Pay close attention to what you like and don’t like about a particular app. Here are a few questions to take note of:

  • Was it easy to use?
  • Did it hang and/or crash?
  • Did it perform its tasks gracefully?
  • Did it do what you expected?
  • Was it visually appealing?

Become Tech Savvy. Become a bit more tech savvy about things that the phone is doing behind the scene. There are apps that do this for both Android and iPhone that help you monitor what’s going one. Things to look out for:

  • Apps that keep running even after you think you shut them off. These will run the battery down faster.
  • Apps that consume more and more memory over time. Using more memory equals more battery usage and shorter time between charges.
  • Apps that seem to slow your phone down when they run. These apps may be using more CPU than necessary resulting in greater battery usage.
  • Apps that connect to the internet frequently costing you extra data charges. There are apps that let you monitor how much data your phone uses and some apps can help pinpoint which apps use the most data.

Which Phones to Support? Understand what devices to support. If you are building an application for internal use, then you have an easier decision since you hopefully have some control over which devices are being used and how often their software gets updated. If you work in retail, your users may have Androids, Blackberries, iPhones, iPads, Kindle’s, Nook’s and possibly other tablets that get updated whenever and however the customer dictates. My advice is do some research and pick one that is used the most and work on that first.

Release Early and Iterate Often. Technology changes so quickly these days that if your app takes more than 3 – 6 months to build, then the technology will change underneath you. In other words, you might be releasing an application that doesn’t work perfectly with the latest phone operating systems or browsers that your customers are using. When that happens, it will cost you even more time and money to fix the problem and the problem will repeat itself. Be sure to take into account the speed at which technology will change once you begin your software development process.

Go Native, Go Web Browser, or Both? Last, it’s important to understand that there are two common types of mobile applications. Native apps are downloaded from an app store and installed directly on the phone, the other is a web app that runs in the phones web browser. My advice is to research and understand your target market. What do your competitors use? What do your customers prefer? What are the trends in your industry?

If you go with native apps, you’ll need to understand which phones to support and how often you will be updating the app. If you choose web apps you’ll need to know which browsers to support. Also take into consideration which skill sets your development team has and understand if they can tackle the project or if you need outside help.

Update, Update, Update. No matter what you decide, you can’t just deploy an app and think you’re done. If you want to keep your customers happy, you’re going to have to keep updating the app until the product line is discontinued or replaced. And, you have to update it often enough to stay on top of the latest technologies. New smartphone models are being released all the time and they all may have different screen sizes and screen resolutions. An app that looks good at one screen size may look horrible on a tablet or iPad. These things have to be accounted for. And, the smartphones operating system software may be updated three or more times per year offering new functionality and fixing bugs. If your customers download a broken app, or if they see the app that hasn’t been updated in a while and something stops working they may not be your customers for much longer. This is especially true for retail apps where customers make split second decisions whether to stay or walk away and try something else.

Conclusion. I hope you find this list useful and at least give you some ideas to think about before you dive head first into bringing a new mobile application into the world. It can be fun, be there is a lot of hard work involved. But, if you plan it right you’ll be successful and learn alot in the process!