This category features articles on best and emerging practices for responsive website design, Web apps and native apps. While the mobile Web is still in it's infancy, we can learn from the experiences of professionals who are working on mobile every day. Curated by Derek Allard. .
Popular tags in this category: Android, iPad, iPhone, iOS, Tablets, CSS, HTML.
From time to time, when a discussion is taking place about ways to implement responsive images, someone comes along and says, “Hey, guys! What we really need is a media query that enables us to send high-resolution images to people on a fast connection and low-resolution images to people on a slow connection.” At least early on, a lot of people agreed.
At first glance, this makes a lot of sense. High-resolution images have a significant performance cost, because they take longer to download. On a slow network connection, that cost can have a negative impact on the user’s experience.
If you've had half an eye on the tech press over the last few weeks, you'll be aware of the update to iOS, or at least of its replacement of Google maps with the new iOS Maps app.
Stories of parks appearing where once there were roads, seas disappearing and more, abound. I'm not going to wade into the debate about whether or not Apple should have done this or whether the new app is an improvement or not, but instead I'm going to focus on the update to mobile Safari — and specifically, what it means for Web developers.
Advertising has always had an uneasy relationship with the media because of ethical considerations on both sides of the printing press. On the one hand, journalists are reluctant, quite rightly, to be seen as under the thumb of an advertiser, and on the other side, advertisers don’t want to be seen to be enforcing their views on the free press.
The relationship between the media and marketeers is the greatest sham marriage of all time: convenience, rarely love. We need each other. Writers need to be paid, and people making products need to be paid too. That being said, the journalism profession has been somewhat eager to hand a lot of control of their content to advertisers for some time now.
Twenty minutes after unboxing my first iPad, I realized this device’s potential to revolutionize the world of kiosks. Ten years ago, my team and I worked with Honda to develop touchscreen kiosks for its dealerships. Potential buyers could customize their purchase with a few touches of their fingertips. While innovative at the time, these early interactive kiosks didn’t come cheap, running Honda $3,000 to $5,000 per installation. Today, we can create such a kiosk for a fraction of the price.
Which industries are the most likely candidates for tablet kiosks? Four that immediately spring to mind are hotels, restaurants, museums and retailers. Kiosks help streamline information-gathering processes, such as signing up for mailing lists, making reservations, ordering products and services and checking in and out of locations. By automating these processes, the kiosk eliminates the customer’s frustration from waiting in line to speak with a representative and, likewise, frees the employees to focus their energies on higher-level tasks.
Most apps fail. This cruel reality has led many disillusioned developers to conclude, often subconsciously, that succeeding on the App Store is like striking it rich in the gold rush: you just need to get lucky. The idea of luck is a dangerous sedative to ease the pain of failure. Pain is a good thing. It shows something is wrong. If my app fails, I want to know why.
Instead of blaming forces beyond our control, why not look at what folks like tap tap tap and Tapbots are doing to succeed again and again and again. While applying this formula flawlessly is nearly impossible, working towards it will dramatically increase your chances of success. These concepts are based on the iOS platform, but many of the principles apply to other platforms as well. Any successful app rests on the foundation of a solid idea, because the idea determines the ultimate potential of the execution. Avoid the temptation of jumping straight into execution after having an epiphany in the shower. A little bit of research up front can save you a lot of pain down the road.
With all the talk about responsive Web design, designers and coders are moving even further from the fixed pixel layouts of design’s print-based history. We’re finally thinking in terms of fluid layouts and expandable, interactive content. But when you get down to it, we’re still thinking of the fluidity in terms of desktop, tablet and mobile sizes.
Chances are that your responsive websites have media query breakpoints at precisely the tablet and mobile widths, essentially creating three different versions of a website with the same code. While this is much more ideal than what we’ve all done until now, it’s not always the best way to approach things. Often, our content breakpoints (the viewport widths where content should be reformatted) are different from common device breakpoints (the viewport widths that reflect physical devices).
Testers are often thought of as people who find bugs, but have you ever considered how testers actually approach testing? Do you ever wonder what testers actually do, and how they can add value to a typical technology project? I’d like to take you through the thought process of testers and discuss the types of things they consider when testing a mobile app.
The intention here is to highlight their thought processes and to show the coverage and depth that testers often go to. At the heart of testing is the capability to ask challenging and relevant questions. You are on your way to becoming a good tester if you combine investigative and questioning skills with knowledge of technology and products.
Care to make a cross-platform mobile game with HTML5? No need to dabble in Java or Objective-C? Bypass the app stores? Sounds like an instant win! A handful of game developers are pushing the envelope of mobile HTML5 games at the moment. Check out the likes of Nutmeg and Lunch Bug for some shining examples.
The great thing about these titles is that they work equally well on both mobile and desktop using the same code. Could HTML5 finally fulfill the holy grail of “write once, run anywhere”? Now, as a Web developer you’re used to dealing with the quirks of certain browsers and degrading gracefully and dealing with fragmented platforms. So, a few technical challenges won’t put you off, right? What’s more, all of these performance and audio problems are temporary.