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. Subscribe to the RSS-Feed.
Sliders are cool. When they’re done well, customers love to interact with them. When they're not done well, they can cause a lot of frustration (not to mention lost sales) by standing between your customers and what they want. And getting them wrong is surprisingly easy.
In this article, we will present a solution, including the design and code, for a new type of Android slider to address common problems, along with a downloadable Android mini-app for you to try out. It’s a deep dive into sliders based on a chapter in Android Design Patterns. The experimental inventory-based slider we will look at would be at home in any application that asks for a price, a size, or any other faceted input within a widely distributed range.
In today’s fast-paced mobile market, consumers have no patience for mobile apps that compromise their experience. “Crashes” and “Not working” are the most common feedback on Google Play for unstable or sluggish apps (including games). Those comments and ratings make hundreds of millions of potential downloaders skip those lousy apps. Sounds harsh, but that’s the way it is.
An app succeeds not by chance. It is the result of the right decisions made at the right time. The most successful mobile app developers understand the importance of performance, quality and robustness across the array of mobile devices that their customers use.
As we refine our methods of responsive web design, we’ve increasingly focused on measure (another word for “line length”) and its relationship to how people read.
The popularization of the “ideal measure” has led to advice such as “Increase font size for large screens and reduce font size for small screens.” While a good measure does improve the reading experience, it’s only one rule for good typography. Another rule is to maintain a comfortable font size.
People use their mobile devices everywhere: on the train, while waiting in line, sitting on the couch. As much as we aim to design our mobile apps and websites for contextual use, testing their usability in context can be challenging.
While getting out in the field for user testing is not always realistic, simulating much of that contextual experience in a lab is possible. One approach to mobile testing is participatory design.
As mobile designers, we have a stark decision to make: do we spend time learning new tools and changing our design processes to create our own transitional interfaces, or are the tools that we've been using good enough? There's an old writing adage that advises writers, whenever possible, to “show, don't tell” when bringing characters to life. The goal is to reveal the story through the character’s experiences instead of the author’s.
When designing mobile products, we share a similar burden. Dammed up inside our heads are creative waterfalls of fresh interactions, transitions, and animations. But how are we supposed to communicate them to our teams, our developers? How do we get them out of our heads? Through a game of charades?
In a previous article, I discussed using POP to create sketch-based clickthrough prototypes in participatory design exercises. These prototypes capture well the flow and overall layout of early design alternatives.
The same piece briefly mentioned another category of clickthrough prototypes: widget-based mockups that are designed on the target device and that expand on sketches by introducing user interface (UI) details and increased visual fidelity. These prototypes can be used to pitch ideas to clients, document interactions and even test usability. In this article, I will teach you how to use the iPad app Blueprint to put together such prototypes in the form of concept demos, which help to manage a client’s expectations when you are aligning your visions of a product.
In the early days of mobile, debugging was quite a challenge. Sure, you could get ahold of a device and perform a quick visual assessment, but what would you do after discovering a bug?
With a distinct lack of debugging tools, developers turned to a variety of hacks. In general, these hacks were an attempt to recreate a given issue in a desktop browser and then debug with Chrome Developer Tools or a similar desktop toolkit. For instance, a developer might shrink the size of the desktop browser’s window to test a responsive website or alter the user agent to spoof a particular mobile device.
Responsive web design has become the dominant method of developing and designing websites. It makes it easier to think “mobile first” and to create a website that is viewable on mobile devices. In the early days of responsive web design, creating breakpoints in CSS for particular screen sizes was common, like 320 pixels for iPhone and 768 pixels for iPad, and then we tested and monitored those devices.
As responsive design has evolved, we now more often start with the content and then set breakpoints when the content “breaks.” This means that you might end up with quite a few content-centric breakpoints and no particular devices or form factors on which to test your website.