Last week I took some vacation. For me it meant a chance to actually open up an IDE and write some code. I wanted to learn more about developing for emerging mobile and HTML 5 standards since more of our clients are now expecting “Mobile” to be part of the solution. Here is what I learned…
1. Don’t trust emulator performance.
Your mobile web page or app will look great in the emulator. It’s lying. It will render quickly and look fantastic without bugs… until you deploy to real hardware. When you run your page/app on an actual devices you’ll see new bugs, page load issues, and slowdowns you never expected based on the emulator. I’m surprised that none of the big platforms have a slowdown switch on their emulators to mimic what you’ll see on devices, especially ones as old as
2. Your mouse is not a thumb.
You’ll think your UX is great with a mouse and keyboard because you can be precise. When you try the experience on actual hardware you’ll discover that you probably didn’t space links and buttons far enough apart.
To make matters worse… because of the pixel density differences between devices and most monitors these problems are exaggerated on the actual devices. It will look like you have plenty of space on your monitor, but when you hold the actual device… everything is smaller.
TEST ON REAL HARDWARE
3. Browse-Based Navigation is Critical
I don’t care what device you have. Typing sucks. Type-ahead search works great for desktop apps as a navigation tool, but it’s just not there on devices because:
A. Onscreen keyboards take up half of your UI space to show results anyway.
B. Most people seem to want to navigate around with one hand if your app is primarily about content consumption.
4. Downsize your Control Library
We ship an analytics package so I figured I’d try out some script based charting controls. Because of issue #1 I thought the fully featured control I used first worked great. Then you’ll realize that every KB of script that has to load impacts performance on the actual devices way more than on desktop browsers. I actually ended up using a scaled up sparklines control rather than a fully featured scaled down chart control. It doesn’t just impact web app performance… but if you are building native apps realize that not all controls are created equally and less is more.
5. And you thought desktop browser fragmentation was bad…
Check out this chart… http://jquerymobile.com/gbs/ and then realize that there isn’t a mobile browser with 80% of the market share and you’ll have some idea of what you are up against. And the quirks and feature support differences between the browsers is noticeably worse than the desktop browser market. So.. know your customers and plan your testing matrix accordingly.
6. Minimize your CSS & Script Churns
Because of the performance issues that I noted above you’ll want to be aware that the user is going to notice a lot more of the “UI Shifts” that go into building a lot of ajax based user interfaces. Part of the solution is to minimize the UI shifts required for your application in general on a mobile device and the other part is to make sure you do as much as you can in CSS by changing class names rather than individually changing items. Swapping a class with 2-3 changes generally seems faster than having script adjust each property. Now, this may seem like common sense, but bad code tends to be forgiven more on desktop browsers than mobile ones.
What have you learned about building and designing for mobile in the last year?