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 explore the best practices of design, and this was achieved with the continuous improvement of the hardware and SDK. 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.
Note : More wonderful tutorials Please pay attention to the triple mobile phone tutorial section, triple mobile phone Digital group: 296605639 welcome you to join