We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.
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.
For many months, your entire team has worked their butts off to create an awesome mobile app. Finally, with your team exhausted and excited, it’s showtime! But then, your dream app turns into the ultimate nightmare: Eager customers download the app, use it once and never return. All the sacrifice and months of hard work — wasted. What went wrong?
Your app has become another victim of the latest trend, joining a whopping 41% of today’s apps that are abandoned after only a single use. This trend has many parallels with the story of the 400-year-old Vasa ship. The most impressive warship of the day, Vasa floundered and sank just one mile into its maiden voyage due to fundamental design issues.
There is no winner in the battle between iOS and Android, and we all know that. If a product succeeds on one platform, it will undoubtedly be ported to the other. Sometimes app developers don’t even bother waiting, and release apps for both platforms simultaneously. For designers this means only one thing — they will have to adapt an application’s UI and UX to another platform while ensuring a consistent design language across the product.
There are three different scenarios for UI multiplatform adaptation: retaining brand consistency; aligning with the conventions specific to the platform; and seeking a balance between the two. We decided to analyze these three approaches by looking at the most popular apps out there so that you get some insight into what method might work best for you.
1.5 million apps in Apple’s App Store and another 1.5 million in Google’s Play store. That’s a lot of apps, and for a growing number of mobile users. An average user in the US will download only three new apps per month (at best), according to comScore’s “US Mobile App Report.”
Competition in the App Store is fierce, and if an indie app developer wants to get noticed, having an amazing product is no longer enough.
How do you write a useful app for the Apple Watch? In what ways does it differ from coding for iOS? And what if you don't have a Watch on hand to test with? Before the launch of the Apple Watch, our iOS team at myMail (one of the popular alternative email apps for iOS) worked tirelessly with a simulator to create a new Apple Watch app.
We wanted the first buyers of the Apple Watch to have the opportunity to use myMail from day one. What we learned through using the simulator and creating the app — including the Apple Watch's UI quirks, passing data between devices, and the rigors of simulator-only development — is described below and (we hope) will help iOS developers get to results, faster, and avoid a few headaches down the road.
Although Windows Phone usage is still low compared with other browsers it's sometimes necessary to test your web work for Internet Explorer Mobile. For web developers, this could be a complication. Testing for the Windows Phone environment is not always optional, but it can be a chore — especially because the version of Internet Explorer that comes with the Windows Phone can be quirky at best. If you're a developer without a Windows Phone device, you might have to get a little creative to ensure that your websites are being rendered properly.
In this article I want to point out a few different tools and techniques which can help test websites for Windows Phone even if you don't have the real device handy or if you are not developing on Windows. But first let's quickly look into the differences between mobile and desktop Internet Explorer.
It's one thing to create a web application and quite another to create an accessible web application. That's why Heydon Pickering, both author and editor at Smashing Magazine, wrote an eBook Apps For All: Coding Accessible Web Applications, outlining the roadmap for the accessible applications we should all be making.
Picture the scene: it’s a day like any other and you’re at your desk, enclosed in a semicircular bank of monitors that make up your extended desktop, intently cranking out enterprise-level CSS for MegaDigiSpaceHub Ltd. You are one of many talented front-end developers who share this floor in your plush London office.
You don’t know it, but a fire has broken out on the floor below you due to a “mobile strategist” spontaneously combusting. Since no expense was spared on furnishing the office with adorable postmodern ornaments, no budget remained for installing a fire alarm system. It is up to the floor manager in question to travel throughout the office, warning individual departments in person.
Mobile back end as a service (MBaaS) aims at giving app developers the ability to create seamlessly new feature-complete cross-platform native and web applications. In the first part of this series, I walked through a messaging application demo powered by the Kinvey application. We explored how to leverage user management, file storage and the data store.
To complete the demo, we need to leverage two key pieces of Kinvey functionality: the permissions provided by the data store, and push notifications, which are enabled through the business logic functionality.
There’s more to designing mobile apps than meets the eye. The task requires a deep knowledge of devices, and it often means changing the way we think — even if that means leaving behind much of what we’ve learned from designing for the web.
I started my career like many designers: working on print design projects. Shortly thereafter, I discovered the world of websites, which fascinated me and became the focus of my work for some time. Along the way I learned concepts related to interaction design and user experience, which I hardly knew existed until then.
Testing responsive websites is a laborious task. Until now, implementing a stable and maintainable automated solution for cross-browser and cross-device testing of a responsive layout has been nearly impossible. But what if we had an opportunity to write visual tests for responsive websites? What if we could describe the look and feel of an application and put this directly into our tests?
Upon considering this question, I decided to also look at another interesting side of visual testing. For quite a long time I have been a fan of the test-driven development (TDD) methodology. It helps me in my daily programming work. TDD enables me to formalize the task and to make sure everything is implemented according to the requirements.