5 Apple Watch design patterns that should be skipped

The value of this translation is high today, the author summed up the 5 key essence from a lot of complicated mistakes, and suggested that the designer should learn it, and it would definitely help you understand this platform more deeply >>>

Contributors: Design translation, welcome students to pay attention to its micro-signal (design translation) yo.

This article for the author authorized excellent release, without the author's own authorization do not reprint, thank you:

Apple has struggled to serve developers since Apple Watch last fall, including building a community and offering a fresh version of the WatchKit SDK. All this is to encourage developers to make killer apps for the first generation of Apple Watch.

However, it turns out that there is no egg to use. The vast majority of third-party applications currently on the shelves are mediocre, sluggish and unwieldy.

Some say this is because Apple Watch is one of the longest-selling products ever from the public to the time of the official offer. This forced the developer to rely on the simulator to do experiments without any actual experience. Others say this is because Apple Watch is a new platform that offers an unprecedented use experience. So developers still need some time to explore and accumulate experience. In my opinion, these two reasons are reasonable.

So we've summed up 5 Apple Watch design patterns that need to be circumvented to help developers get around these pits and provide the best possible user experience based on the status quo.

　　First pit: Design with Apple Watch as center

Is it wrong to make a design with a watch as its core? I know it sounds strange, but in fact, the best Apple Watch apps we've ever seen are not based on the functionality of the table, but on those who use the table as an assistive tool for other IOS devices.

And the Apple Watch apps are too reliant on the dynamic data provided by the IPhone, which slows down the entire experience. Because the Apple Watch is connected to the phone via Bluetooth and the Bluetooth transmission is slow, the Watch app that needs a lot of dynamic data is a lousy experience. Twitter, for example, takes some time to transmit the latest tweets, but the wait is so long that users don't want to see Twitter with their watches.

On the other hand, receiving tweets on a watch is a passive behavior rather than an active operation. Twitter will take the initiative to send an apple-glance notification to your watch, rather than to refresh Twitter by yourself. The use experience here is fundamentally different from what it was before.

Twitter's Apple Watch app

　　Second pit: Using dynamically generated images

This is something Apple explicitly advises developers to avoid.

Using dynamically generated images can significantly slow down load speeds, which in turn affect the user experience.

The images built into the watch can be displayed directly by the device, and the dynamically generated images need to be processed and transmitted to the watch.

The data transfer between the IPhone and Apple Watch is indicative.

If your application has to use dynamically generated images, be sure to use the caching mechanism. This will make your application a little bit faster. Also, be sure to provide a built-in image when the dynamic image defaults. (See Clover Clover case Studies for more pictures and animations without impacting performance)

　　Third pit: Assuming the user knows the "press" action

Over time, pressing operations (Force Touch) will certainly become a natural operation for Apple users, as is the case with the latest Macbook Air trackpad. And there are indications that the future IPhone and IPad will also introduce this feature.

"Press" operation is different from the long, it also needs a certain force to trigger. If you've ever played a camera--I mean a real camera--you should have realized that long press and compressions are like the two actions of focusing and photographing, and the power required is different.

The menu that is triggered by the press operation.

The tragedy, however, is that there is no visual cue in the Apple Watch app to tell the user that the current interface has a "press" operation. Users can easily identify vertical browsing mode and operation buttons, but can not know the existence of press operation.

The problem may be solved by Apple in the future. But now, as a developer, it's best not to touch it.

If you have to use a press operation, you should provide a description of how the user triggers the menu using the press operation before the user uses it.

　　Pit IV: Doing to do

Not every IPhone app needs a corresponding Apple Watch app, even if it's a good gimmick for market operations. For example, we don't need to read a book on a watch, because no one has this kind of strange demand. (30 seconds of hand is worn out)

As the application icon increases, the watch's dials become crowded because there are no folders to receive them. At the same time, finding a target application in a bunch of icons is a pretty big deal.

Apple Watch's dial (this is only a native application, much more real than this)

We've seen some great watch apps, like Mint (budget apps), that just show the current budget. Remote applications have only one feature: Controlling Apple TV. MLB at Bat only provides a quick view of your favorite team's real-time score.

All in all, your IOS app is the core, and Apple Watch should be its affiliate. So, you'd better design IOS apps first, and if you've found a good watch application scenario in the process, then you're going to use the watch. (See BUZL and Cardioworkouttracker case studies for more information)

　　Pit Five: let users see a lot of information

Less is more, is the principle that Apple Watch respected. Don't put too much information on your glance interface so that users have to stare for a long time. The purpose of glance is to use very few words and pictures to convey the necessary information, while requiring easy reading and a glimpse of it.

If you show more than the necessary information, it means that the user has to spend more time reading, which can lead to a prolonged period of discomfort caused by lifting the arm. It is also not conducive to the battery of the watch.

The glance interface to the Do application

The figure above shows how much of the task remains, as well as the number of tasks that have been completed, that the To-Do application succinctly presents.

More likely, the theater app can use a watch to show the reservation, and the airline app can use it to showcase the boarding gate, which the news app can use to showcase the latest headlines. Other additional information should be given to the iPhone at hand for the user to complete.

Imagine that Apple Watch is like a pager (if you're old enough to know what I'm talking about), you get a notification that if you need to do something, go get your iPhone.

　　Summarize

The first IOS SDK was born in 2009, and it took years to find the best practices for the design, and it was implemented in the context of continuous hardware and SDK improvements. Similarly, Apple Watch in the future also need to take this section, at the same time, we also need to change the design patterns and ideas.