Local blog for Italian speaking developers
Come migliorare il design dell'app Wear 2.0
20 settembre 2017
Pubblicato da Steven Tepper, App Quality Consultant, Google Play
Wear 2.0 è stato lanciato
a febbraio con supporto aggiuntivo per le nuove funzionalità hardware, oltre ad adottare i nuovi
temi di Material Design
, le sue linee guida e un modello UI verticale più semplice. Viene inoltre introdotta una
Complications API
che consente alle app di fornire i dati ai quadranti in modo più semplice, e ai quadranti di incorporare i dati esterni. Il grande aggiornamento finale è che le app che utilizzano Wear 2.0 hanno la capacità di operare in
modalità standalone
senza bisogno di una connessione con un'app complementare sul telefono.
Ci sono alcuni aspetti del design da considerare relativi alla navigazione, alle notifiche, alla Complications API e alla modalità standalone per ottimizzare i dispositivi Wear 2.0.
Navigazione
Utilizzare il drawer di navigazione
WearableDrawerLayout
per la navigazione semplice e infrequente:
la navigazione semplice include attività come accedere alle impostazioni delle app, cambiare utente o disconnettersi
.
Puoi implementare questo drawer su Wear 2.0 per passare da una visualizzazione o sezione dell'app all'altra con uno swipe dall'alto verso il basso o impostare un drawer di azione per azioni specifiche al contesto con uno swipe dal basso verso l'alto.
Presentare il drawer di navigazione a pagina singola per consentire agli utenti di navigare più velocemente tra le visualizzazioni:
un drawer di navigazione può essere presentato come multipagina o a pagina singola. Il layout a pagina singola è consigliabile se l'utente utilizza velocemente al massimo 7 visualizzazioni all'interno dell'app. Ricorda che se l'app usa un drawer a pagina singola, l'iconografia deve essere chiara e comprensibile poiché non vi sarà alcun tipo di etichettatura del testo in questo layout. Se ci sono più di 7 visualizzazioni di navigazione o le visualizzazioni non sono facilmente rappresentate da icone, consigliamo di utilizzare invece il layout con drawer multipagina.
Utilizzare i launcher di applicazioni multiple se l'app include due o tre funzioni discrete:
ad esempio, se l'app supporta
sia
il monitoraggio delle attività (con opzioni, azioni e visualizzazioni diverse) sia l'analisi cronologica e la gestione delle attività monitorate, è possibile utilizzare i launcher di applicazioni multiple per gestire queste attività. Invece se l'app dispone di una semplice schermata iniziale, queste funzionalità potrebbero essere posizionate in fila nella parte inferiore dello schermo.
Utilizzare la visualizzazione rapida nella parte superiore del drawer di azione per fornire accesso rapido per l'azione primaria:
se alla visualizzazione non è associata alcuna azione primaria, ignora il comportamento predefinito e imponi un pulsante di overflow per la visualizzazione rapida che fa apparire tutte le azioni nella parte inferiore della visualizzazione, se toccato.
Assicurati che, per i dispositivi con Wear 2.0, l'app utilizzi questi nuovi modelli UI per garantire un'esperienza utente uniforme. Scopri più risorse di formazione per
Navigazione ed Azioni di Wear
e le specifiche di Material Design per i drawer di
Navigazione
e
Azione
.
Notifiche
Wear 2.0 utilizza un modello di navigazione verticale più semplice e sostituisce così il gesto di swipe orizzontale che mostrava le azioni di notifica. Le azioni di notifica vengono ora presentate come una singola azione primaria (se applicabile) in fondo alla notifica stessa. Se non esiste alcuna azione primaria, l'espansione della notifica mostrerà le opzioni in una singola visualizzazione scorrevole verticale.
Le notifiche funzioneranno senza apportare troppi cambiamenti su entrambi i dispositivi 1.x e 2.0 ma avranno un aspetto molto diverso.
Durante la creazione di app per dispositivi Wear 2.0, si può migliorare l'esperienza dell'utente con le notifiche applicando le seguenti best practice:
Supportare le notifiche espandibili:
usa
BigTextStyle
in modo che gli utenti possano vedere più contenuti sul loro orologio.
Utilizzare la visualizzazione compressa della notifica (se applicabile):
aggiungi l'azione primaria della notifica alla visualizzazione compressa della notifica tramite setContentIntent(), se necessario.
Utilizzare
MessagingStyle
per le applicazioni di messaggistica
: offri un'esperienza soddisfacente di chat simile a un'app nella notifica espansa usando questo stile.
Aggiornare le specifiche istruzioni per l'utente di Wear 1.0:
rimuovi qualsiasi testo che indichi agli utenti come agire su una scheda usando il swipe orizzontale (modello Wear 1.x).
Migliorare le notifiche per utilizzare le azioni inline:
consente agli utenti di fare ciò che desiderano senza utilizzare il tocco per visualizzare i dettagli della notifica espansa. Le azioni per le notifiche di messaggistica possono utilizzare diversi metodi di input, inclusi i preset Smart Reply o l'input vocale e di tastiera. Sfrutta queste caratteristiche per fornire nuove funzionalità e soddisfare ulteriormente i tuoi utenti.
Per saperne di più su come
aggiungere funzionalità alle notifiche
.
Complication
La Complications API di Wear 2.0 consente a sviluppatori di quadranti e fornitori di dati di terze parti di rendere visibili le informazioni importanti che gli utenti vogliono visualizzare a colpo d'occhio. I quadranti che supportano l'API possono essere configurati per utilizzare qualsiasi fornitore di dati installato sull'orologio pur mantenendo il controllo completo del loro aspetto. Le app che supportano la Complications API consentono un accesso rapido ai dati dell'app su tutti gli orologi che supportano le complication. Queste complication possono essere visualizzate in una varietà di forme (testo breve, icona, valore variabile, testo lungo, immagine piccola e immagine grande) in base a quanto sia già stato configurato dal fornitore di dati e quanto spazio sia stato assegnato sul quadrante dell'orologio.
Per garantire che le complication si adattino al design complessivo del quadrante dell'orologio e gestiscano correttamente il loro tipo di dati, quando aggiungi il supporto per le complication, assicurati che i produttori di quadranti:
Utilizzino la classe
TextRenderer
disponibile nell'SDK Wear 2.0:
ciò garantisce che il testo all'interno delle complication si adatti ai limiti presenti, riducendo il testo, supportando dinamicamente le interruzioni di riga o inserendo ellissi alle stringhe quando superano i limiti di una complication basata sul testo.
Utilizzino la classe
ComplicationDrawable
per impostare colore di sfondo, forma, bordo e opzioni dei caratteri per le complication:
offre il controllo completo del rendering della complication nel quadrante dell'orologio.
Progettino in modo che gli utenti possano configurare o regolare le complication sul quadrante tramite un menu impostazioni:
per scoprire come creare queste impostazioni, vai a vedere il
campione di un quadrante
su GitHub.
Utilizzino l'app
test suite
del fornitore di dati per alimentare i dati dummy alle complication del quadrante dell'orologio:
ciò consente di verificare che tutte le complication siano eseguite correttamente e che i caratteri siano formattati in base ai loro limiti.
In qualità di fornitori dati di complication, rendano ben visibili i dati rilevanti utilizzando
ComplicationProviderService
:
ciò consente di definire e configurare quali tipi di
ComplicationData
può fornire l'app alle complication.
Funzionalità standalone sui dispositivi Wear
Assicurati che l'app sia in grado di autogestirsi anche se non è installata un'app complementare quando utilizzi il flag della funzionalità hardware di android.hardware.type.watch
: l'uso di questa funzionalità consente all'app di essere ricercata e installabile direttamente sui dispositivi Wear senza dover installare un'app telefonica complementare, e assicura che l'app possa autogestirsi per evitare problemi o interruzioni all'utente.
Assicurati che l'app indossabile non si basi sull'app telefonica per accesso/autenticazione o altre funzionalità primarie
: quando è necessario un input complicato per l'autenticazione (ad esempio l'immissione della password), la tua app indossabile può indirizzarti al telefono complementare, ma dovrebbe comunque basarsi sull'UI web per l'inserimento di account e password piuttosto che sull'app.
Se per qualche altro motivo sul telefono deve essere presente un'app complementare che supporti la tua app, allora quest'ultima dovrà utilizzare
CapabilityApi:
per indirizzare correttamente gli utenti agli elenchi del Play Store del dispositivo complementare in modo che possano installare l'app mancante. In caso contrario, l'app dovrebbe funzionare da sola, utilizzando le funzioni Wi-Fi e GPS integrate o le altre funzioni di connettività.
Includi il testo sui requisiti dell'app complementare o illustra brevemente come funziona l'app Wear nella descrizione degli elenchi del Play Store
: aiuterà a creare le giuste aspettative, a guidare l'utente nell'installazione delle app corrette e a garantirgli la migliore esperienza possibile.
Incorpora il flag
com.google.android.wearable.standalone
nel manifesto se la tua app indossabile può operare senza interagire con i telefoni complementari
: questo flag indica che l'app indossabile può essere installata ed è pienamente funzionante anche quando non è associata a un telefono Android o iOS complementare.
Oggi abbiamo affrontato molti argomenti ma sono disponibili tante risorse aggiuntive per consentirti di ottimizzare e utilizzare gli ultimissimi schemi e funzionalità di Wear nei tuoi giochi e applicazioni. Consulta le
guide linea sulla qualità
e la documentazione di formazione degli sviluppatori per saperne di più sulle best practice dello
sviluppo delle app indossabili
e del
design delle app indossabili
e creare app di qualità per Wear.
Quanto ti è stato utile questo post?
★
★
★
★
★
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly