Is Apple’s one-size-fits-all approach starting to fail?

My mother-in-law cracked me up when she asked “What’s the matter with Apple, how come they only make things in one or two sizes?” She’s as non-techie as they come and I think she nailed an important point. I’ve joked about this with friends and colleagues and even mocked about it in presentations. Yet, ever since the Apple September 10th announcement I’ve been wondering: can Apple innovate enough to stay a true technological leader, or are they starting to enter an era of simply copying others and wrapping ‘improvements’ under a luxury brand umbrella? I’m leaning towards to latter. After seeing Tim Cook’s presentation on September 10th, my opinion has started to solidify even more.

Factoid: Everyone will agree, for better or for worse, we are in an era of choice. Look at the variety of Androids. Think about the sheer number of cable and satellite TV channels, the variety of TV shows aimed at a dizzying variety of demographics, music has splintered from the days of major rock bands into hundreds of niche, self published indie groups.  Satellite radio. Most major car manufacturers now have dozens of car models and many of them you can significantly customize. And, even grocery stores now have a ridiculous number of choices for a lot of items that use to only have several manufacturers or producers.

So, what about Apple?

Apple has so far resisted playing to the status quo set by IBM, Microsoft and now Android of allowing endless variations of their products to fit a variety of needs and wants. It wasn’t that long ago, for example, that Dell Computer was a leader in selling desktop and laptop computers. That era has passed and I don’t believe Apple wants to follow in these giants footsteps. Perhaps there is some sort of evolutionary cycle that these leading public tech companies follow, like natural boom and bust cycles that we see in economics, neighborhoods, cities and world economies that Apple won’t be able to escape.

This leads me right back to the September 10th announcement.  Apple seems to have entered an era of incremental improvements in hardware and software: new colors (big whoop), finger print reader (Moto Atrix had that) and faster hardware.  But, the biggest pressure I think they’ll start facing is they are now behind the curve in allowing people to have choices. Real choices…not just new colors for custom cases made of soft silicon rubber. Choices are the way they world is headed right now. Case in point, how long have iPhones had 4-inch screens? How many tens of millions of larger Android screen phones have been sold? Can Apple simply ignore this and stick to their one-size-fits-all guns if the board of directors starts seeing missed opportunities and potentially lower sales?

Android, in comparison to iOS, has more varieties of sizes, manufacturers, shapes and colors than there are grapes for making wine. Buying an Android is like shopping for clothes at any mainstream department store. In addition to a bijillion patterns and colors, you have sizes like XS, SM, M, L, XL, XXL, etc. And then there is relaxed fit, straight fit and athletic fit along with different collar sizes.  This is brilliant from a consumer standpoint, and yes it’s a nightmare for application developers and IT shops that support them. But, developers and IT folks only represent a small fraction of an enormous world-wide porous marketplace full of more consumers, cultures and tastes than perhaps existed in history.

Buying a Mac is like walking into a top-notch art gallery. As you glide along into the next majestic room, shuffling your feet in hushed respect you can hear the mac genius say in an elegant foreign accent, “…and here on this masterfully carved solid white marble pedestal, fabulously embellished with an aluminum case and crystal clear retina view screen, and protected from theft by 12 visible and hidden security features is, ladies and gentlemen…the (audience gasps) Apple Macbook Pro.”

But, at some point even art galleries change up their exhibits as people’s tastes and interests change.  Even galleries have to innovate to stay ahead of the times. Can Apple change? Can Apple adapt to a new era of endless choices? Can Apple reinvent itself?

Smartphones aren’t getting any smarter

As an Android and mobile web developer, I feel compelled asking people I know or meet a lot of questions about their phones. One trend I’ve been seeing is feedback that smartphones, themselves, aren’t really getting any smarter. The ironman/crossfit marathon to add new features at warp speed has left behind a trail of cool phones that have some fundamental issues. So, I’m going to take a look at some of these here.

To put things in perspective, at Google I/O 2013, Sundar Pichai announced that there have now been 900 million Android activations world-wide to date. That’s not including iPhone activations, of course. But, Yeow, that’s a lot of phones! So, let’s look at some things that haven’t improved much. It’s almost like Newton’s Third Law of Motion can be applied to smartphones: while some things improve, other things must take a back seat.

Security. I can say this with certainty – I have yet to see or hear about a smartphone advertisement that says something such as “we’re striving to make this phone the most secure phone yet.” One thing is clear that Apple’s app vetting process helps reduce the level of malware compared to Google Play. Sure I understand that nothing is 100% secure, but the operating system vendors and the handset vendors could at least talk about it.  And, why don’t smartphones come with built-in, optimized versions of virus checkers and anti-malware tools like Windows PCs and laptops?

Most people’s lives could be seriously disrupted by the data stored on your typical smartphone, and we lose these and leave them behind accidentally by the thousands, and we inadvertently install malware.

Case in point – do a search on Google or bing using the term “smartphone security”, and see how many articles are published by the major phone vendors about security and securing your phone. The top result is by the FCC about their Smartphone Security Checker.

Restoring an Android phone. If you reset your droid or buy a new one, restoring everything back to the way it was and in it’s exact place, well…a very manual process. This is not very user friendly. Hey Android vendors, you should take a lesson from Apple on this one.

Display brightness and energy consumption. Phone displays appear to continue to be the “number one” draw on battery life. I’ve started to think most (many?) like their screens really bright. I mean realllly bright. It’s funny, I keep mine pretty dim to squeeze as much life out of the battery as possible, and I’ve lost count of the number of times people have said something like “how can even you see what you are doing??”

GPS energy consumption. My Garmin GPS lasts over 17 hours of continuous usage with two AA batteries. The battery on a typical smartphone has much greater storage capacity, but in actual field tests I’ve killed smartphone batteries in as little as 4 -5 hours of continuous GPS usage. GPS used wrong is a huge draw on the devices battery. Sure, a smartphone is doing a lot more work than a typical, single purpose GPS. But, my point is why hasn’t GPS battery consumption improved over five generations of smartphones? Those of us who build GPS-based native and web apps have to jump through hoops to optimize battery life in applications that do more than take a snapshot of the users current location. Some of the algorithms we write should simply be built-in to the firmware.

Charging times. Now I admit this varies from phone-to-phone but it’s still not very fast in general. I know I have said before that many people are never more than 10 feet from a charger, but for those of us who aren’t that attentive to charging I can say charging times can be an issue. For example, my iPad (okay it’s more of a tablet than a smartphone) is the slowest charging device on the planet compared to my original Google Ion which charged from dead to full in about an hour and a half. Sure, I understand there is a huge difference in battery size, but my point still stands. The cute, itty-bitty charger for iPad is way under-powered for the needs of charging a larger battery.  And, maybe some people are okay with that?

Planned Obsolescence.  This one is totally on Android. I’ve lost track of the number of Android phones that I have sitting around that have been rendered obsolete because the handset manufacturer provided one or maybe even two OS updates to the phone, and then they stopped. They become obsolete in the sense that some apps don’t run on older versions of the operating system. Sure, the upgrades are enticing (better camera, more memory, faster processors, etc. etc.) but what if someone doesn’t want or need to upgrade?

This may become more of an issue for people as some carriers are stopping their subsidies of phones and pushing users to carry the cost of a new phone directly. And new phones can give you sticker shock. If you have to pony up $350 – $600 for that new phone and all it’s advertised features, you might not be inclined to upgrade phones as often as you used to.

Wrap-up. So, I’ve written a mish-mash of different things that should be improved for both Android and iPhone. What I’d really like to see, and it probably won’t happen, is for Android, Apple and Microsoft to take a step back from the feature/functionality marathon and work on some fundamental issues to build an even stronger foundation for the next generation phones.

 

3 Steps for Determining if Your Website is Mobile Ready

Here are three step for helping determine the mobile ready strengths and weaknesses of your existing website. I’ve had a number of conversations from website teams recently asking the question: “Can we reuse our existing site for mobile users?” I was surprised to learn that the individuals asking me the question had, in fact, never visited their own site on a mobile device.

Note, this blog describes steps that need to be address before you decide whether to build for the web or native applications.

Step One – Create a small focus group of company outsiders, friends as well as employees.

  • Gather as many different types of mobile devices as possible including: iPad, iPhone, Android tablet, and several varieties of Android phones. Try to use a combination of older and newer devices. Don’t fool yourself by simply using all of the latest great versions, especially if your web visitors are the general public.
  • Get a mobile projector, such an Elmo or IPEVO.
  • Write down the common use cases, and the workflows associated with them. An example use case might be logging in to your site. And, a workflow would describe the steps a user takes to complete the login process  from beginning to the end.
  • Visit your website and run through the common use cases.
  • Turn off wireless, if possible, and let everyone experience typical internet speeds to simulate, for example, standing in line at the grocery store.
  • Trade off using different devices.
  • Hire a user interface (UX) designer if you don’t already have one. Bring them on board at the beginning, or as early as possible, in this evaluation process.

Step Two – Create a grading system to help assess the experience everyone had with each device.

  • Were you able to accomplish your task as easily and quickly as if you were at your desk with a full-size laptop or computer?
  • Did you have to do a lot of extra panning and zooming in and out to navigate through the use cases and workflows?
  • Was there any functionality that simply didn’t work, didn’t work correctly, or didn’t work as expected on the mobile device?
  • Were there any aspects of the site that looked different or wrong? For example, was all the text the right size? Was everything in the right place?
  • Were you satisfied with the amount of time it took for pages and images to load?
  • Were you able to comfortably use the site when rotating the phone between landscape and portrait views?
  • Were you okay with how quickly you were able to switch between different pages on the website?
  • Were you able to access secure resources without any problems?
  • And, perhaps most importantly, were there any obvious improvements you would like to see made to make mobile surfing experience better?

Step 3. Apply some commonly known mobile-specific conditions to your findings and see if helps to provide context to everyone’s experience.

  • One-handed plus gestures. It’s a fact that navigating a mobile web is significantly different from a desktop browser. There’s no mouse! Mobile browsing is usually done with one hand, while the other hand is used to hold the device. The screen is driven by what are called gestures. Examples of gestures are when you swipe your thumb upward on a page to scroll it downward, or when you use two fingers, usually the index finger and thumb, to pinch zoom the screen in or out.
  • Smaller Screens. And, of course the screens are much smaller than what you would find on a desktop or laptop. Different devices have different resolutions. And, navigating a full website can seem more cumbersome as you use gestures to navigate around, in comparison to the desktop experience of seeing the entire page, and using your a precision mouse to whip through the different links on a page.
  • Download Speeds. Download speeds on mobile devices vary considerably compared to your work machine hooked up to a reliable local area network (LAN). A site that seems zippy on your work machine, may load much differently on a typical smartphone. Also, for some older phones they may have much less processor power and that may lead to the perception of slower download speeds as the CPU chugs through displaying the page.

How do I interpret the results?

When you are done compile, discuss and analyze the findings with your internal teams and stakeholders.

Good. If most testers successfully navigated the majority of use cases and workflows then you are in good shape, and you may simply need to do some additional tweaking to your site.

Not so good. However, if most testers had unsatisfactory experiences then you’ll need to spend more time looking more closely as what worked and what didn’t work. You may find workflows that are great on a desktop machine that are clumsy and awkward on a mobile device.

Don’t be surprised. Portions of your site may have to be redesigned. You may not be able to include everything that’s in your full site into your mobile site. You may have to spend a lot of time optimizing the site to speed up page load times. Pay special attention to functionality that didn’t work on mobile. Mobile web browsers have well known limitations compared to full browsers. Looking at what didn’t work may help you decide if you need access to native device capabilities.

You’ve just taken a huge first step towards helping your team set the stage for stepping into the mobile world.

7 Critical Things to Know When Building Any Mobile App

This blog post builds on concepts proposed in an earlier post about not all mobile apps being created equally. If you are a developer who is in the process of migrating to mobile this post is for you. It’s intended to raise awareness of important items to consider in your requirements. My goal is to help you identify some of the major gotchas early on in the development process and improve your chances for success.

There are many more details to learn on the topics I’ve described below. The good news is that in the last few years the amount of deeply helpful documentation has expanded considerably. Where possible I’ve tried to include links related to each topic.

Touch-based Workflows. Recent research has shown that people use their smartphones more often than web apps, and they spend roughly 80% of their time on social media and games. Because of this and the fact that smartphones today are touch driven and not mouse driven, you have to take that into account in your user interface design. Touch implies many things including gestures and multi-touch. You can toss your old conceptions of user interface design based on desktops and tablets, and check out Android’s recommendations as well as Apple’s. My strong recommendation is to hire a UX designer to help you through building a user interface.

Mutliple form factors come with various screen sizes and densities. Long gone are the days of building for just three main browser types. Now you have to take into consideration iPhones, iPads, tablets, numerous different style androids as well as desktop and laptops. Android defines the following screen sizes and, as you can see, this is quite varied and smaller than a typical laptop or desktop. Those typically run 1024 x 768 or greater.

  • xlarge screens are at least 960dp x 720dp
  • large screens are at least 640dp x 480dp
  • normal screens are at least 470dp x 320dp
  • small screens are at least 426dp x 320dp

This is important to know because an app that looks good on an iPad may not look good, or display correctly, on the four inch display of a Motorola Atrix at 960 x 540. A button that looks correctly sized on one smartphone may look too big on another. A whopping 84% of all Android screens are what Android defines as normal size (>=  470dp x 320dp) and between either medium dpi (~160dpi) or high dpi (~240dpi). But, you still have to take into consideration other densities. I also recommend taking a look at new HTML5 browser-based technologies to help with addressing this problem, such as CSS media queries.

Inconsistent Internet. It’s a best practice to check if internet connections exist and gracefully handle HTTP requests when the internet is down, as I blogged about here.  Depending on your application and needs, you should also monitor whether or not a wireless connection can be made and then allow the application to switch to wireless where possible. Wireless also has the advantage of using less battery power.

Slower Connections. And, on a related note, you can’t always depend on 4G connections having consistent maximum download speeds. Over the course of a user session, the connection speed will vary widely and you should plan for that. I’ve been trying to find some stats on mobile internet quality world-wide, if they are out there they are hard to find. But, we’ve all experience spotty mobile internet coverage. Take this into account if you are transferring large amounts of data between your servers and your app. You should also consider detecting when the user is in an area of greater bandwidth and use that to download more data less often. Use loosely coupled and event driven architectures. Test app load times on various devices and around town and away from your office.

Less CPU Horsepower. While the latest generation of four core phones are certainly the most powerful phones yet. In general, applications and web pages will run slower on phones than they do on your development machine running a desktop browser. Take older generation phones into account because they are usually significantly slower than the newer phones. There are a few workarounds in HTML5 to help with this, in that done correctly they can offload rendering to the hardware. In native applications be aware of memory leaks because, remember, more memory usage means less battery life and applications that can run slower over time.

Support across multiple operating system versions. Remember on Android that the vast majority of users are still running v2.2 – v2.3.7 even though v4.x is currently shipping. You’ll have to do some research on your target market and find out what versions and type of phones they are using. You can’t support everything, but you can make educated guesses. Apple, on the other hand, has a significantly more limited selection of phones and tablets that you have to support, and they do a great job helping you support those.

There are some solutions that help with building cross-platform mobile apps, to go into more detail will take another blog post. Here’s a few: Adobe Flex, PhoneGap and Titanium. Keep in mind that the future of Flex, as a development platform, is being called into question after Adobe open sourced everything but the browser and desktop runtimes to the Apache Foundation. PhoneGap and Titanium offer what is now being called “hybrid” solutions where you can build an application in JavaScript, for example, and then compile that code for native deployments on Android and iOS.

Battery Life. Ah, battery life is last but certainly not least. Be aware of how battery intensive your application is and try to minimize battery consumption as much as possible. The Android online docs have a number of highly information articles on this subject. Smaller app footprint in memory means less battery consumption. Heavy CPU usage means more battery usage. Minimize GPS usage through smart algorithms to help preserve battery life.  Switch to 802.11 wireless connections where possible, since this requires less battery power than 3G and significantly less power than 4G.

So, there you go. I hope these suggestions help. If you have more suggestions based on your own experience please post a comment!

References:

Android Gestures

Android Optimize Battery Life

Android Screen Sizes and Densities

CSS media queries

Android UI Design

Android Model for Best GPS Performance

iOS User Experience

HTML5 Hardware Acceleration

Event-based Architectures for Adobe Flex

HTML5 Geolocation API – how accurate is it, really?

If you are a developer building applications that require location information then you need to know what is really possible with the HTML5 Geolocation API and not a bunch of hype. The blog post attempts to give you some insight into how it works with desktop and mobile browsers as well as having a greater appreciation for what is and what isn’t possible. I’m going to show you that accuracy depends on many factors, some of which are beyond your control, and at best the location information returned by the API is just an approximation.

[Editors note: as of June 29th, 2013 Part 2 of this post is now available]

Most common use case. For the most part, HTML5 Geolocation works just fine in dense urban areas when you are stationary with your laptop or smartphone Wifi turned on. This is the use case most commonly cited when questions are asked about accuracy. This makes sense because urban areas have many public and private Wifi routers and cell phone towers are typically closer together. As you’ll see, HTML5 uses these and other methods to pinpoint your location. However, it’s not always that simple and below are some other use cases that you should take into consideration.  

How does the API work? Depending on which browser you are using, the HTML5 Geolocation API approximates location based on a number of factors including your public IP address, cell tower IDs, GPS information, a list of Wifi access points, signal strengths and MAC IDs (Wifi and/or Bluetooth). It then passes that information to a Location Service usually via an HTTPS request which attempts to correlate your location from a variety of databases that include Wifi access point locations both public and private, as well as Cell Tower and IP address locations. An approximate location is then returned to your code via a JavaScript callback.

As an example to show you what type of information is sent to a Location Service, I did some basic testing with Firefox 11. Firefox uses Google’s Location Service. On a related note, as far as I can tell with Firefox 11 it isn’t passing cookies any more where in Firefox 3.6 they use to pass a user ID token.

Firefox 11 browser sends queries to https://maps.googleapis.com/maps/api/browserlocation/json? The example results have been obfuscated, but by looking at it you should get the idea of what content is being sent:

GET /maps/api/browserlocation/json?browser=firefox&sensor=true&wifi=mac:01-24-7c-bc-51-46%7Cssid:3x2x%7Css:-37&wifi=mac:09-86-3b-31-97-b2%7Cssid:belkin.7b2%7Css:-47&wifi=mac:28-cf-da-ba-be-13%7Cssid:HERESIARCH%20NETWORK%7Css:-49&wifi=mac:2b-cf-da-ba-be-10%7Cssid: ARCH%20GUESTS%7Css:-52&wifi=mac:08-56-3b-2b-e1-a8%7Cssid:belkin.1a8%7Css:-59&wifi=mac:02-1e-64-fd-df-67%7Cssid:Brown%20Cow%7Css:-59&wifi=mac:2a-cf-df-ba-be-10%7Cssid: ARCH%20GUESTS%7Css:-59 HTTP/1.1

Which location service do browsers use?

Not all Geolocation services are the same, and they certainly don’t all use the same algorithms and exact same databases. Because of this the results typically vary across browsers that use different Geolocation services.

Here’s my best attempt to document which Geolocation service each of the major browsers are using. I haven’t done any definitive testing however I do know from experience that different browsers and even different laptops for smartphones will return different locations when tested from the exact same location. Some location services are better in some cities and others are better in other cities. I haven’t come across a definitive list, most likely because the information is constantly being updated. I’ve included a link to a demo application at the bottom of this blog where I encourage you to also test the API against different browsers.

  • Chrome uses Google Location Services.
  • Firefox on Windows uses Google Location Services.
  • Firefox on Linux uses GPSD – http://catb.org/gpsd/. I’m not sure if this includes Android. I haven’t had a chance to test it yet.
  • Internet Explorer 9+ uses the Microsoft Location Service.
  • Safari on iOS uses Apple Location Services for iPhone OS 3.2+.
  • I’m not sure what Safari on Windows uses. With all the public distrust between Apple and Google, I wouldn’t be surprised if Safari on Windows also uses Apple’s Location Service, but I haven’t found any documentation to verify this and I haven’t tested it.
  • Opera uses Google Location Services. On a related note, I’ve also noticed that mobile Opera on Android accesses the GPS. This is something to consider from a battery usage standpoint.

Not all browsers support HTML5. It’s important to note that not all browsers support the HTML5 Geolocation API, for example Internet Explorer 8. The HTML5 Geolocation API is built into the browser and is accessible using JavaScript methods that access the navigator object. In order to work it requires HTML5 support in the browser. You can research whether or not a particular browser supports Geolocation by going here: http://mobilehtml5.org/ or http://caniuse.com.

Additionally, if a user has disabled JavaScript for some reason, then your Geolocation app won’t work in their browser. JavaScript code is required to access the API.

HTML5 Geolocation requires an internet connection. If you lose your internet connection then you won’t be able to access the Location Service. With no internet connection most browsers will not return a location. Sometimes you can access a cached location that is stored in the browser by the API. But, that cached location is the last valid location that was calculated by the API.

Is Wifi turned on or off? If Wifi is turned off on your phone, desktop machine, laptop or tablet , the Geolocation API service will try to find your location by other methods which include your public IP address, Cell tower ID triangulation or GPS. Public IP addresses databases usually return a location for your internet providers Point of Presence or PoP. Furthermore, some internet provides offer rotating IP addresses. So you get to use one IP address for a particular time period such as 48 hours and then you get a different one. So a Public IP address is usually only good enough to locate you to a particular City, or a general area of the City, or a Country depending on where you are in the world.

As for Cell Tower IDs it depends on what type of information your particular phone and Telco Carrier provides to the API. Some smartphones only return information on the current tower that the phone is pinging, which obviously makes triangulation very difficult and decreases accuracy to within a radius around that tower.

I’ve noticed that the native Android browser is significantly less accurate without Wifi. Without it I typically see accuracy numbers in the 1000+ meters range. As soon as I turn Wifi back on and I’m in a neighborhood or downtown area, the accuracy drops to less than 75 meters almost instantly.

Are they in a rural or urban location? Granted the vast majority of users will be in urban locations. However if you have requirements for users traveling outside of urban areas then this section applies to you. Geolocation in rural areas is significantly less reliable. If Wifi is turned on but the user is not near any Wifi access points, then the Geolocation service will also attempt to fallback to the other methods mentioned above.  Triangulation can be much more difficult in rural areas where towers are spread further apart, and for browsers that don’t use GPS the accuracy will suffer significantly.

Are you moving or stationary? Being stationary in an urban area offers far better accuracy with the Geolocation API than when you are moving. On my native Android phones it’s rare to get an accurate reading while driving around town. Occasionally a sporadic result would be returned when you stop at a light. To date, I have never gotten a valid reading while driving on a highway at speeds over 50 mph.

Is a VPN turned on? If a VPN is turned on, then the location will resolve to the VPN’s public IP address. For example, a user in Denver is logged into the company VPN which host is hosted at their headquarters office in a suburb of Dallas, Texas. The HTML5 Geolocation API will resolve the location to the headquarters public IP address in Dallas and not the user’s actual location. Quite a few corporate users have VPNs for security reasons.

Custom Geolocation as a fallback? Depending on your requirements you may want to implement your own IP Geolocation using a company such as IP2Location. Or use a third-party Geolocation service, such as Skyhook, as a fallback. Remember IP Geolocation only returns locations to a City or an area within a City. So, if you need more accuracy than that for your application, then don’t bother with this approach.

The downside to custom IP Geolocation is that this requires writing a server-side service to grab the browsers IP address. All server-side languages such as PHP, C#.NET, Java and JSP support these capabilities. You also have to subscribe to another service that lets you query their database by IP address and get a return value of an approximate location. There is no current way to get this information from the browser, on the client-side, using JavaScript.

HTML5 Geolocation doesn’t meet my requirements, what do I do? If you have critical requirements for gathering more precise location information than the HTML5 Geolocation API is capable of delivering then I’d recommend building your application using a native API such as Android or iOS.

How can I test this? You can test HTML5 Geolocation in different browsers using a test application that I built. I recommend trying it on different browsers and comparing the results yourself:

http://andygup.net/samples/html5geo/

References

Mozilla FAQ

Mozilla Developer Network

Google Location Service

W3C Geolocation API in IE 9

Safari Developer Library

Opera Geolocation

IP Geolocation

W3C – Privacy of Geolocation Implementations

Apple Q&A on Location Data

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: http://www.andygup.net/?p=155.