Local blog covering the latest news, updates, and stories for Indonesian speaking developers.
Tips Membuat Actions on Google yang Sangat Bagus
29 September 2018
Ditulis oleh Cathy Pearl, Head of Conversation Design Outreach
Ilustrasi oleh Kimberly Harvey
Halo semua! Saya Cathy Pearl, head of conversation design outreach di Google. Saya telah cukup lama mem-build sistem percakapan, mulai dengan IVR (sistem ponsel) dan beralih menuju pengalaman multi-modal. Saya juga penulis buku
Designing Voice User Interfaces
yang diterbitkan O'Reilly. Hari ini, saya ingin memperkenalkan desainer dan developer ke
praktik terbaik desain percakapan
kami sehingga Actions akan memberikan pengalaman pengguna sebaik mungkin. Hari ini, saya akan berbicara tentang langkah pertama yang fundamental ketika berpikir tentang membuat Action: menulis contoh dialog.
Jadi, Anda punya ide keren untuk Actions on Google yang ingin Anda build. Anda telah mempelajari
Dialogflow
, melakukan beberapa
codelabs
, dan menemukan API yang ingin digunakan. Anda siap memulai coding bukan?
Tidak secepat itu!
Membuat Action harus selalu dimulai dengan
merancang
sebuah Action. Jangan panik; ini tidak akan memperlambat Anda. Merencanakan desain terlebih dahulu akan menghemat waktu dan menghindarkan Anda dari kesulitan nantinya, dan akan menghasilkan pengalaman yang lebih baik dan berguna.
Dalam postingan ini, saya akan berbicara tentang komponen pertama dan paling penting untuk merancang sistem percakapan yang baik: contoh dialog. Contoh dialog adalah alur percakapan potensial yang mungkin digunakan pengguna saat berbicara dengan Action Anda. Mereka sangat mirip dengan skrip film, dengan pertukaran dialog antara Action Anda dan pengguna. (Dan, seperti skrip film, mereka harus dibacakan dengan keras!) Menulis contoh dialog dilakukan
sebelum
menulis kode, bahkan sebelum membuat alur.
Ketika saya berbicara dengan orang-orang tentang pentingnya contoh dialog, saya mendapatkan banyak anggukan dan persetujuan. Tetapi ketika saya kembali lagi sesudahnya dan berkata, "Hai, tunjukkan kepadaku contoh dialogmu," Saya sering mendapat senyum malu-malu dan alasan mengapa mereka tidak ditulis. Alasan yang biasa dipakai adalah:
"Saya hanya mem-build prototipe, saya bisa melewatkannya."
"Saya tidak mengkhawatirkan kata-kata itu sekarang—saya bisa menyempurnakannya nanti."
"Bagian yang sulit adalah semua hal yang berhubungan dengan integrasi backend! Menyusun kata-kata adalah bagian yang mudah."
Yang pertama, ada kesalahpahaman bahwa "desain percakapan" (atau desain antarmuka pengguna dengan suara) hanyalah lapisan teratas dari pengalaman: kata-kata, dan mungkin urutan kata-kata, yang akan dilihat/didengar pengguna.
Namun sebenarnya desain percakapan jauh lebih dalam dari hal tersebut. Ia menggerakkan struktur dasar pengalaman, yang meliputi:
Panggilan backend apa yang kita lakukan?
Apa yang terjadi ketika sesuatu gagal?
Data apa yang kita minta dari pengguna?
Apa yang kita ketahui tentang pengguna?
Kendala teknis apa yang kita alami, apakah dengan teknologi itu atau ekosistem kita sendiri?
Pada akhirnya, semuanya ini bermanifestasi sebagai kata-kata, tentu saja. Tetapi menganggapnya sebagai "hal yang bisa Anda khawatirkan nanti" akan membuat Anda berada di jalur kegagalan ketika tiba waktunya pengguna berinteraksi dengan Action Anda. Misalnya, tanpa contoh dialog, Anda mungkin tidak menyadari bahwa semua prompt yang dimulai dengan kata "Berikutnya", membuatnya terdengar seperti robot dan kaku. Contoh dialog juga akan menunjukkan kepada Anda ketika Anda membutuhkan "perekat" kata seperti "pertama" dan "omong-omong".
Google telah menyusun
panduan desain
untuk mem-build sistem percakapan. Mereka berisi pengenalan untuk contoh dialog dan mengapa mereka penting:
Contoh dialog akan membuat Anda merasakan secara sekilas dan cepat dari "suara-dan-rasa" interaksi yang sedang Anda rancang. Mereka menyampaikan alur yang benar-benar akan dialami pengguna, tanpa gangguan teknis notasi kode, diagram alur kompleks, masalah pengenalan tata bahasa, dsb.
Dengan menulis contoh dialog, Anda bisa secara informal bereksperimen dengan dan mengevaluasi berbagai strategi desain, seperti cara mempromosikan visibilitas fitur baru atau cara mengonfirmasi permintaan pengguna (misalnya: apakah sebaiknya Anda menggunakan konfirmasi implisit, konfirmasi eksplisit, atau tanpa konfirmasi sama sekali?).
Lihat
contoh dialog Action untuk Google I/O 2018
untuk melihat contohnya. (Anda juga bisa melihat
kode Action untuk Google I/O 2018
.)
Masih tidak yakin apakah Anda
benar-benar
membutuhkannya? Mari kita dengar dari developer yang mengerjakan Actions, Jessica Dene Earley-Cha, yang mengatakan dalam
postingan Medium
terbarunya:
Mari kita bahas bagaimana ini di-build. Sebelum coding apa pun dilakukan, kita harus mem-build Desain Percakapan. Saya awalnya melewatkan langkah ini karena saya berpikir bahwa saya bisa mem-build struktur terlebih dahulu dan kemudian mengisi kontennya (seperti mem-build situs web).
Namun, strukturnya ternyata terikat dengan konten.
Saya menyadarinya ketika saya terbentur dinding penghalang yang saya pikir teknis, tetapi masalah itu ada di sana karena saya tidak memiliki desain.
Dia menunjukkannya dengan jelas bahwa merancang sistem percakapan berbeda dari merancang web. Dengan antarmuka percakapan, konten
itu sendiri
adalah bagian dari struktur, sehingga desain menjadi semakin penting.
Jadi sekarang setelah Anda (semoga) yakin, mari kita bahas empat kesalahan umum yang bisa dihindari developer dengan menggunakan contoh dialog:
KESALAHAN #1: Membanjiri pengguna dengan terlalu banyak informasi
Misalkan Anda menulis sebuah Action untuk toko sepeda: Action itu bisa membuat janji perbaikan dan layanan, memberitahukan jam buka toko, dan daftar transaksi terbaru. Kita mungkin tergoda untuk mulai mencantumkan opsi sehingga pengguna mengetahui semua yang bisa mereka lakukan. Mari kita lihat seperti apa contoh dialognya menggunakan strategi ini:
PENGGUNA
Hai Google, bicara dengan Alyssa's Bike Shop.
ACTION
Hai! Selamat datang di Alyssa's Bike Shop. Apakah Anda ingin membuat janji perbaikan, membatalkan janji, mengetahui jam buka toko, mengetahui tawaran minggu ini, atau mengetahui tawaran bulan depan?
Jika Anda membaca prompt ini dengan keras kepada orang lain, langsung terlihat jelas bahwa terlalu banyak informasi yang disajikan. Manusia memiliki kapasitas terbatas dalam mendengarkan suara, terutama jika suara itu baru pertama kali mereka dengar.
Akan lebih baik kalau seperti ini:
PENGGUNA
Hai Google, bicara dengan Alyssa's Bike Shop.
ACTION
Hai! Selamat datang di Alyssa's Bike Shop. Saya bisa membantu Anda membuat atau membatalkan janji, memberitahukan jam buka toko, atau memberi tahu penawaran terbaru. Mana yang Anda sukai?
Tips pro: bila menginginkan pengalaman yang lebih baik, tinggalkan opsi "batal" jika pengguna tidak memilikinya.
KESALAHAN #2: Tidak menunjukkan apa yang bisa dilakukan oleh Action Anda
Berikut adalah contoh dialog yang merepresentasikan kesalahan umum dalam banyak pengalaman percakapan. Dalam contoh ini, pengguna kembali ke Action yang sudah mereka coba sebelumnya:
PENGGUNA
Hai Google, bicara dengan Cathy's Astronomy Trivia Game.
ACTION
Ini Cathy's Astronomy Trivia Game. Selamat datang kembali!
PENGGUNA
Uhhh... apa yang bisa saya lakukan??
Ketika kita terlalu tenggelam dalam desain, kita sering lupa bahwa pengguna mungkin datang ke Action tanpa pengetahuan latar belakang yang kita miliki. Apa yang bisa dilakukannya tidak selalu jelas.
Akan lebih baik kalau seperti ini:
PENGGUNA
Hai Google, bicara dengan Cathy's Astronomy Trivia Game.
ACTION
Ini Cathy's Astronomy Trivia Game. Anda bisa bermain sendiri, atau bergabung dengan tim. Mana yang ingin Anda pilih?
PENGGUNA
Uh, saya akan bergabung dengan tim.
Ingat, Anda tidak perlu mencantumkan semua opsi di depan. Sebagai gantinya, cobalah untuk memandu pengguna melewati proses dengan cara yang jelas, dan akhiri dengan ajakan bertindak.
KESALAHAN #3: Tidak mengajak pengguna Anda berbicara
Masalah umum lainnya adalah tidak memperjelas ketika tiba saatnya giliran pengguna berbicara. Sebagai manusia, kita memiliki banyak cara untuk memberi tahu seseorang bahwa sekaranglah saatnya giliran mereka bicara: kata-kata, intonasi, pandangan mata, dan bahasa tubuh. Untuk sesuatu seperti Asisten, sangatlah penting untuk mengakhiri giliran bicara dengan pertanyaan atau instruksi yang jelas. Berikut adalah contoh jawaban Action yang menggantung pengguna:
PENGGUNA
Oke Google, bicara dengan Cool Animal Facts.
ACTION
Selamat Datang di Cool Animal Facts! Hewan apa yang ingin kamu ketahui?
PENGGUNA
Saya suka penguin!
ACTION
Keren, penguin. Apakah Anda ingin mengetahui tentang habitatnya, atau apa yang suka mereka makan?
PENGGUNA
Oh, apa yang suka mereka makan!
ACTION
Penguin bisa memakan hingga 13 pon ikan, kril, dan cumi setiap harinya! Dan tahukah kamu penguin jantan mengerami telur?
PENGGUNA
Oh, oke...
ACTION
Sementara itu, penguin betina pergi mencari ikan.
PENGGUNA
(berpikir) Tunggu dulu.. apa saya harus mengatakan sesuatu?
Dalam contoh ini kita melihat dua masalah. Pertama, Action mengajukan pertanyaan retoris. Ketika pengguna mencoba menjawabnya, Action mengabaikannya dan terus berbicara.
Masalah kedua adalah setelah fakta diberikan, tidak ada yang terjadi. Tidak ada petunjuk apa pun tentang apa yang harus dilakukan pengguna berikutnya.
Akan lebih baik kalau seperti ini:
ACTION
Penguin bisa memakan hingga 13 pon ikan, kril, dan cumi setiap harinya! Omong-omong, penguin jantan menghabiskan waktu mengerami telur, sementara penguin betina pergi mencari ikan. Sekarang, apakah kamu ingin mendengar lebih banyak tentang penguin, atau bertanya tentang hewan lain?
PENGGUNA
Saya sudah selesai, terima kasih.
ACTION
Sama-sama, terima kasih telah berbicara dengan Cool Animal Facts. Selamat tinggal!
Tips pro: Pengguna kerap kali mengharapkan pertanyaan sebelum keluar dan menjawabnya secara eksplisit, seperti mengucapkan "selamat tinggal".
Tips pro 2: Perkuat tata bahasa Anda! Untuk pertanyaan "Apakah kamu ingin mendengar lebih banyak tentang penguin, atau bertanya tentang hewan lain?" bersiaplah untuk menangani jawaban seperti "ya", "tidak", dan nama hewan.
KESALAHAN #4: Membuat satu prompt error untuk semua kondisi
Menangani percakapan dengan apik ketika ada sesuatu yang salah sangatlah penting untuk setiap sistem percakapan. Menulis beberapa prompt error untuk setiap giliran percakapan terasa sangat merepotkan. Menggunakan prompt default "Maaf, saya tidak mengerti" tidak akan membantu pengguna. Sebagai gantinya, hal tersebut harus berdasarkan pada apa yang telah terjadi hingga saat itu dan di mana posisi pengguna saat ini. Untuk mempermudahnya, tuliskan contoh dialog untuk kondisi error, yang akan semakin memperjelas apa yang seharusnya ada dalam prompt.
PENGGUNA
Oke Google, bicara dengan Zombie Quiz.
ACTION
Saatnya Zombie Quiz! Pertanyaan pertama: apa yang harus kamu lakukan jika dikejar zombie: kunci pintu; lari ke bukit, atau menanam di kebun?
PENGGUNA
(berpikir)
ACTION
Maaf, saya tidak mengerti jawabanmu. Mana yang kamu pilih?
PENGGUNA
Apa? Saya lupa pilihannya...
ACTION
Maaf, saya masih kesulitan. Mana yang kamu pilih?
PENGGUNA
Argh!
ACTION
Maaf, jawabannya salah. Pertanyaan kedua...
Penanganan error sensitif-konteks akan membuat pengguna kembali ke jalurnya:
PENGGUNA
Oke Google, bicara dengan Zombie Quiz.
ACTION
Saatnya Zombie Quiz! Pertanyaan pertama: apa yang harus kamu lakukan jika dikejar zombie: kunci pintu; lari ke bukit, atau menanam di kebun?
PENGGUNA
(berpikir)
ACTION
Yang mana yang harus kamu lakukan jika dikejar zombie: kunci pintu; lari ke bukit, atau menanam di kebun?
PENGGUNA
Uhh.. Saya tidak yakin... sebentar...mungkin..
ACTION
Anda juga bisa mengatakan nomor jawabannya, seperti satu, dua, atau tiga. Mana yang kamu pilih?
PENGGUNA
Oh, nomor tiga.
ACTION
Benar!
Checklist pra-penerbangan Anda
Saya tahu Anda sudah tidak sabar ingin segera lepas landas dan mulai menggambar alur dan menulis kode, tetapi luangkan waktu untuk menulis contoh dialog
terlebih dahulu.
Dalam jangka panjang, ini akan membuat coding Anda lebih mudah, dan meminimalkan jumlah bug yang harus diperbaiki.
Berikut daftar "Kerja" yang perlu diingat ketika menulis contoh dialog:
Lihat
Panduan Desain Percakapan
untuk bantuan selengkapnya
Mulai desain Anda dengan menggunakan contoh dialog
tertulis/lisan
; diagram alur mendetail bisa menyusul belakangan
Baca contoh dialog Anda
dengan keras
!
Buat setiap contoh dialog
satu
lokasi; mereka tidak boleh bercabang
Tulis beberapa contoh dialog "lokasi bahagia"
Tulis beberapa contoh dialog "lokasi error"
Lakukan "pembacaan tabel" dan minta orang yang tidak terbiasa dengan contoh dialog Anda berperan sebagai pengguna
Bagikan contoh dialog Anda dengan semua orang yang terlibat dalam build Action, sehingga semua orang berada di halaman yang sama
Saat menguji, bandingkan Action yang sedang bekerja dengan contoh dialog, untuk memastikan ia diimplementasikan dengan benar
Ulangi, ulangi, ulangi!
Selamat menulis!
Menjadikan Firebase Android SDK sebagai open source
28 September 2018
Di Firebase, kami berkomitmen terhadap transparansi dan komunitas developer yang berkembang, itulah sebabnya kami mulai menjadikan SDK sebagai open source tahun lalu. Hari ini, kami melanjutkan misi tersebut dengan menjadikan Firebase Android SDK pertama kami sebagai open source.
Untuk rilis awal ini, kami menjadikan SDK Cloud Firestore, Cloud Functions, Realtime Database, Storage, dan FirebaseCommon sebagai open source. Kami berencana untuk merilis lebih banyak SDK ke depannya, jadi jangan lupa membintangi atau menonton repo.
Di mana reponya?
Kode sumber Firebase Android SDK bisa ditemukan di
https://github.com/firebase/firebase-android-sdk
.
Untuk SDK yang termasuk dalam repositori, GitHub adalah sumbernya, meskipun Anda juga bisa menemukan project kami di
direktori Google Open Source
dan
firebaseopensource.com
. Di GitHub, Anda dapat mengamati perkembangan fitur dan perbaikan bug baru serta mem-build salinan lokal SDK di perangkat pengembangan Anda untuk pratinjau rilis mendatang. Detail selengkapnya tentang bagaimana Anda mem-build, menguji dan berkontribusi pada Android SDK tersedia di
GitHub README
.
Berkenaan dengan SDK iOS, Javascript, Node.js, Java, Python, Go, dan .NET yang sudah tersedia secara open source, bila Anda menemukan masalah dalam kode kami, Anda bisa melaporkannya melalui issue tracker GitHub standar. Masukan Anda sangat penting dalam membentuk masa depan Firebase dan kami menantikan Anda di GitHub!
Membangun pengalaman baru dengan Google Photos Library API
27 September 2018
Ditulis oleh Jan-Felix Schmakeit, Google Photos Developer Lead
Seperti yang telah kami sampaikan pada bulan Mei
, orang-orang membuat dan menggunakan foto dan video dengan beragam cara, dan kami berpikir bahwa ini seharusnya lebih mudah dilakukan dengan foto yang orang ambil, pada lebih banyak aplikasi dan perangkat yang kita gunakan. Karena itulah kami membuat Google Photos Library API: untuk memberikan Anda kemampuan dalam mem-build pengalaman foto dan video dalam produk yang lebih cerdas, cepat, dan bermanfaat.
Setelah kesuksesan developer preview pada beberapa bulan terakhir, Google Photos Library API sekarang tersedia secara umum. Jika Anda ingin mem-build dan menguji pengalaman sendiri, Anda bisa mengunjungi
dokumentasi developer
kami untuk memulai. Anda juga bisa mengutarakan ketertarikan Anda untuk bergabung dengan
program mitra Google Foto
bila Anda merencanakan integrasi yang lebih besar.
Berikut ringkasan singkat tentang Google Photos Library API dan apa yang bisa Anda lakukan:
Baik Anda seorang developer seluler, web, atau backend, Anda bisa menggunakan REST API ini untuk memanfaatkan yang terbaik dari Google Foto dan membantu pengguna terhubung, mengupload, dan berbagi dari dalam aplikasi Anda. Kami juga meluncurkan
library klien dalam berbagai bahasa
yang akan membantu Anda memulai lebih cepat.
Pengguna harus mengotorisasi permintaan melalui API, sehingga mereka selalu berada di kursi pengemudi. Berikut beberapa hal yang bisa Anda lakukan untuk membantu pengguna:
Menemukan foto dengan mudah, berdasarkan
apa yang ada di foto
kapan itu diambil
atribut seperti format media
Mengupload langsung ke library foto atau album mereka
Mengatur album dan menambahkan judul dan lokasi
Menggunakan album bersama untuk mempermudah transfer dan kolaborasi
Menempatkan machine learning agar berfungsi di aplikasi Anda juga bisa dilakukan dengan lebih mudah. Anda bisa menggunakan smart filter, seperti kategori konten, untuk mempersempit atau mengecualikan tipe foto dan video tertentu dan mempermudah pengguna dalam menemukan yang mereka cari.
Terima kasih kepada semuanya yang telah memberikan masukan pada versi pratinjau developer kami, kontribusi Anda membantu membuat API ini semakin baik. Anda bisa membaca
catatan rilis
kami untuk mengikuti setiap rilis terbaru API. Dan, jika Anda telah menggunakan Picasa Web Albums API,
berikut adalah panduan migrasi
yang akan membantu Anda bermigrasi ke Google Photos Library API.
10 Tahun Chrome DevTools
26 September 2018
Chrome memasuki usia 10 tahun! Terima kasih telah membuat komunitas pengembangan web begitu terbuka, kolaboratif, dan mendukung. DevTools mendapatkan inspirasi dari project-project lain yang tak terhitung jumlahnya. Berikut adalah sedikit flashback mengenai bagaimana DevTools hadir, dan bagaimana perubahannya selama bertahun-tahun.
Pada awalnya, hadir Firebug
Bayangkan untuk sesaat ketika browser tidak diluncurkan dengan fitur developer. Bagaimana Anda akan men-debug JavaScript? Anda memiliki 3 opsi:
Menambahkan panggilan window.alert() ke seluruh kode Anda.
Memberi komentar bagian kode.
Memandang kode untuk waktu yang lama hingga dewa-dewa JavaScript memberikan Anda sebuah solusi.
Bagaimana dengan masalah layout? Error jaringan? Sekali lagi, yang bisa Anda lakukan hanyalah melakukan eksperimen secara hati-hati dalam kode Anda. Ini adalah realitas pengembangan web hingga tahun 2006. Kemudian fitur kecil bernama Firebug hadir dan mengubah segalanya.
Screenshot panel Net Firebug, diambil dari
Saying Goodbye to Firebug
(
sumber
dan
lisensi
)
Firebug adalah ekstensi Firefox yang memungkinkan Anda men-debug, mengedit, dan memantau halaman secara real-time. Sebagai developer web, dari yang sebelumnya Anda tidak memiliki visibilitas ke halaman web, tiba-tiba Anda langsung bisa memiliki apa yang pada pokoknya adalah fitur inti dari fitur developer modern. Kemampuan untuk memahami dengan tepat mengapa Firefox berperilaku seperti ini menimbulkan banjir kreativitas di web. Tanpa Firebug, era Web 2.0 tidak akan mungkin terjadi.
WebKit Web Inspector
Pada waktu yang hampir bersamaan dengan peluncuran Firebug, beberapa engineer Google mulai mengerjakan project yang pada akhirnya mengarah ke Chrome. Sejak awal, Chrome adalah mashup library kode yang berbeda. Untuk rendering, para engineer Chrome memilih WebKit, yang merupakan project open source yang masih mendukung Safari hingga hari ini. Bonus tambahan menggunakan WebKit adalah bahwa ia hadir dengan fitur siap digunakan yang disebut Web Inspector.
Screenshot Web Inspector, diambil dari
Web Inspector Redesign
(
sumber
dan
lisensi
)
Seperti panel Net Firebug, Web Inspector asli mungkin tampak tidak asing. Banyak dari fungsionalitasnya masih ada sampai hari ini sebagai panel Elements di Chrome DevTools. Web Inspector diluncurkan beberapa hari setelah Firebug, dan Safari adalah browser pertama yang memaketkan fitur-fitur developer langsung ke browser.
Era "Inspect Element"
Chrome membawa banyak ide inovatif ke ekosistem browser, seperti omnibox yang menggabungkan penelusuran dan kolom URL, dan arsitektur multiproses yang mencegah satu tab menggantung membuat error seluruh browser. Namun inovasi yang paling kami sukai adalah menyediakan fitur developer di setiap build untuk setiap pengguna, yang bisa dijalankan hanya dengan mengklik mouse.
"Inspect Element" pada 2010
Sebelum Chrome, fitur developer adalah pengalaman pilihan. Anda harus menginstal ekstensi, seperti Firebug, atau mengaktifkan beberapa flag, seperti yang masih dipakai di Safari hari ini. Chrome adalah browser pertama yang menjadikan fitur developer dapat diakses dari setiap instance browser. Kami ingin mengklaim bahwa kami memiliki visi besar untuk membuat browser ramah-developer sejak awal, tetapi kenyataannya adalah bahwa Chrome memiliki banyak masalah kompatibilitas di hari-hari awalnya (hal ini masuk akal, karena tidak ada yang mem-build untuk Chrome) dan kami harus menyediakan cara mudah bagi developer web untuk memperbaiki masalah ini. Developer web berkata kepada kami bahwa ini adalah fitur yang bermanfaat, dan kami mempertahankannya.
Era seluler
Dalam beberapa tahun pertama project DevTools, kami pada dasarnya menambahkan babak-babak ke cerita yang dimulai oleh Firebug dan Web Inspector. Pergeseran besar berikutnya dalam pendekatan kami terhadap DevTools terjadi ketika semakin jelas bahwa smartphone hadir di sini untuk tetap tinggal.
Misi pertama kami di dunia baru yang menantang ini adalah memungkinkan developer untuk men-debug perangkat seluler real dari mesin pengembangan mereka, yang kami sebut proses debug dari jauh. DevTools sebenarnya diposisikan dengan baik untuk menangani proses debug dari jauh, akibat lain dari arsitektur multiproses Chrome. Pada awal project DevTools kami menyadari bahwa satu-satunya cara debugger bisa mengakses browser multiproses adalah melalui protokol klien-server, dengan browser menjadi server, dan debugger menjadi klien. Ketika Chrome seluler hadir, protokol ini sudah dimasukkan ke dalamnya, jadi kami hanya perlu membuat DevTools yang berjalan di perangkat pengembangan Anda berkomunikasi dengan Chrome yang berjalan di perangkat seluler melalui protokol ini. Protokol ini masih merupakan kekuatan DevTools sekarang ini, dan sekarang dikenal sebagai
Chrome DevTools Protocol
.
Proses Debug dari Jauh
Proses debug dari jauh adalah sebuah langkah ke arah yang tepat, dan sampai hari ini masih merupakan fitur utama untuk memastikan bahwa situs Anda berperilaku wajar di perangkat seluler real. Namun, seiring waktu, kami menyadari bahwa proses debug dari jauh menjadi kurang menarik. Ketika Anda berada di fase awal mem-build situs atau fitur, Anda biasanya hanya membutuhkan perkiraan orde pertama pengalaman seluler. Ini mendorong kami untuk membuat serangkaian fitur simulasi seluler, seperti
:
Dengan tepat mengemulasikan viewport seluler, menyimulasikan masukan berbasis-sentuh dan orientasi perangkat.
Membatasi sambungan jaringan untuk menyimulasikan 3G dan CPU untuk menyimulasikan hardware seluler yang kurang kuat.
Spoofing browser, geolokasi, data akselerometer dan banyak lagi.
Kami secara kolektif merujuk fitur-fitur ini sebagai Device Mode.
Prototipe awal Device Mode
Device Mode pada 2018
Era kinerja
Saat era seluler terbuka, aplikasi besar seperti Gmail mendorong batas-batas kemampuan web.
Bug berskala-Gmail diperlukan untuk fitur berskala-Gmail
. Salah satu kontribusi besar pertama kami ke ekosistem fitur adalah menunjukkan perincian secara mendetail tentang semua yang harus dilakukan Chrome untuk menampilkan sebuah halaman.
Panel Timeline asal, seperti yang ditampilkan dalam
Do More with Chrome Developer Tools
Panel Performance pada 2018
Fitur-fitur ini merupakan langkah ke arah yang tepat, tetapi untuk menemukan peluang optimalisasi, Anda harus mempelajari detail-detail mendalam tentang bagaimana browser bekerja dan menyaring banyak data. Akhir-akhir ini, kami mem-build berdasarkan fondasi ini untuk menyediakan lebih banyak
analisis kinerja terkendali
.
Lighthouse
engine baru menggerakkan panel Audits, dan juga tersedia sebagai modul Node untuk integrasi dengan sistem CI.
Saran kinerja di panel Audits
Era Node.js
Hingga tahun 2014 atau sekitar tahun tersebut, kami memikirkan DevTools sebagai fitur untuk mem-build pengalaman yang menakjubkan di Chrome. Kemunculan Node mendorong kami untuk memikirkan kembali peran kami dalam ekosistem web.
Dalam beberapa tahun pertama keberadaan Node, developer Node berada dalam situasi yang mirip dengan developer web sebelum Firebug, atau developer Gmail sebelum panel Timeline: skala aplikasi Node melampaui skala fitur Node. Mengingat Node berjalan di JavaScript engine Chrome, V8, DevTools adalah kandidat dasar untuk mengisi kekosongan ini. Dukungan untuk proses debug Node dengan DevTools hadir pada tahun 2016 dan menyertakan fitur DevTools yang biasa, seperti breakpoints, code stepping, blackboxing, source maps for transpiled code, dan sebagainya.
Node Connection Manager
Ekosistem protokol DevTools
Nama
Chrome DevTools Protocol
(CDP) menyarankan API yang hanya bisa digunakan oleh DevTools. Kenyataannya lebih umum dari itu: ini adalah API yang memungkinkan akses terprogram ke Chrome. Selama beberapa tahun terakhir, kami telah melihat beberapa aplikasi dan library pihak ketiga bergabung dengan ekosistem protokol:
chrome-remote-interface
menyediakan akses JavaScript tingkat rendah ke protokol
Puppeteer
membawanya ke tingkat abstraksi berikutnya dan mengaktifkan otomatisasi browser
headless Chrome
dengan JavaScript API modern
Lighthouse
mengotomatiskan proses pencarian cara untuk meningkatkan kinerja dan kualitas halaman
Kami senang melihat ribuan project bergantung pada package ini untuk mengaktifkan interaksi yang kaya dengan Chrome. Jika Anda berada di bisnis otomatisasi atau fitur, ada baiknya memeriksa protokol ini untuk melihat apakah ia membuka peluang apa pun dalam domain Anda. Misalnya, tim
VS Code
dan
WebStorm
menggunakannya untuk mengaktifkan proses debug JavaScript dalam IDE-nya masing-masing.
Apa yang berikutnya?
Misi utama kami adalah mem-build fitur yang bisa membantu Anda menciptakan pengalaman menakjubkan di web. Kami sangat bergantung pada masukan Anda untuk membantu kami menentukan produk atau fitur yang perlu di-build.
Jangan ketinggalan informasi fitur baru dengan postingan
What's New
kami
Usulkan fitur baru di
milis
Laporkan bug di
Chromium Bug Tracker
Ikuti kami di
Twitter
untuk menemukan fitur baru dan alur kerja mini
Ajukan pertanyaan di
Stack Overflow
untuk mendapatkan bantuan mengenai penggunaan DevTools
Selesaikan masalah dengan keahlian Anda dan
berkontribusi untuk DevTools
Terima kasih telah membuat komunitas yang menyenangkan. Kami menantikan kebersamaan 10 tahun selanjutnya untuk mem-build web bersama Anda.
Ditulis oleh tim Chrome DevTools
Apakah Anda kehilangan pendapatan dengan AMP?
20 September 2018
Catatan editor: Artikel berikut
awalnya diposting di Medium
oleh Vamsee Jasti, AMP Product Manager di Google
Saya adalah product manager yang bekerja di AMP dan kami berusaha keras untuk membuat iklan lebih baik di web sembari membantu penayang berkembang. Saya menulis ini untuk memberi Anda beberapa latar belakang tentang pilihan desain yang kami buat untuk periklanan di AMP dan kemudian menindaklanjuti setiap minggunya dengan rekomendasi optimalisasi khusus untuk membantu Anda memanfaatkan halaman AMP secara maksimal.
Maksimalkan pendapatan halaman AMP Anda dengan mengoptimalkannya
Pada intinya: Jika Anda memublikasikan halaman AMP, setidaknya pastikan mereka termonetisasi dengan baik. Hal itu bisa terjadi, jika seseorang berinvestasi di dalamnya.
Ketika AMP diluncurkan, penting bagi kami untuk membantu penayang meraih pendapatan dari halaman AMP seperti yang Anda lakukan dari non-AMP karena iklan masih menjadi sumber pendapatan besar bagi banyak penayang. Setelah banyak berbincang-bincang dengan penayang, saya melihat beberapa penayang tidak memanfaatkan sepenuhnya halaman AMP dan karenanya kehilangan banyak pendapatan.
Masalah
Kami bekerja sama dengan sejumlah penayang untuk mendapatkan masukan seputar monetisasi AMP dan sering mendengar bahwa ada banyak fitur iklan yang memerlukan dukungan di AMP, tetapi volume masukan tersebut menurun setelah kami meluncurkan sejumlah fitur selama setahun terakhir. Selalu ada banyak pekerjaan yang harus diselesaikan, tetapi sejak peluncuran AMP, kami telah meluncurkan sejumlah fitur dan menutup hampir semua celah sekarang.
Ada penayang di luar sana yang tidak hanya mencapai paritas pendapatan tetapi bahkan
melebihi pendapatan
dari halaman AMP mereka dibandingkan dengan non-AMP. Untuk beberapa penayang yang menerima hampir 50% dari traffic ke halaman AMP, potensi penghasilannya bisa lebih dari satu juta dolar per tahun!
Solusi
Jika Anda adalah penayang yang berada dalam bisnis pengembangan audience (pengunjung yang sering datang ke situs Anda) dan bukan traffic (pengunjung yang berkunjung berdasarkan umpan klik atau dengan membeli traffic di platform), Anda mungkin sudah secara sadar menyeimbangkan keuntungan dan kerugiannya. Keuntungan dan kerugian antara pengalaman pengguna situs dengan pendapatan yang Anda hasilkan dari iklan. Untuk contoh ekstremnya: seseorang bisa dengan mudah menampilkan 3 iklan pop-up berurutan sebelum artikel ditampilkan sehingga memperoleh banyak pendapatan, tetapi hal ini juga dapat menyebabkan pengguna langsung meninggalkan situs atau mengaitkan brand penayang secara negatif sehingga pengunjung akan berpikir dua kali sebelum berkunjung ke situs tersebut.
Prinsip-prinsip di balik periklanan AMP
Ketika mempertimbangkan aspek keuntungan dan kerugian, dengan AMP, kami mengambil sikap seimbang untuk memprioritaskan pengalaman pengguna di atas hal lainnya, dan mereka ulang bagaimana iklan masih dapat menghasilkan pendapatan yang sangat baik dengan fitur yang sulit diterapkan pada halaman non-AMP untuk alasan klasik.
Berikut adalah beberapa di antaranya:
1. Mengeluarkan iklan dari lokasi kritis perenderan halaman
Tidak seperti halaman biasa, halaman AMP membuat permintaan iklan pada halaman seawal mungkin dalam siklus hidup iklan. Hal ini memungkinkan kita untuk memparalelkan perenderan halaman, selagi mengizinkan server iklan menjalankan pelelangan untuk memilih iklan terbaik. Kemungkinannya, pada saat iklan kembali, halaman telah selesai memuat dan oleh karena itu iklan juga bisa langsung ditampilkan yang mengarah ke iklan yang memiliki rasio klik tayang dan keterlihatan yang lebih baik. Kami telah mengumpulkan data yang menunjukkan bahwa AMP berkinerja sangat baik dalam menangani tindakan ini. Kemenangan bagi penayang dan pengiklan hanya dengan menyusun urutan permintaan iklan. Kami menyebutnya “Fast Fetch” dan Anda bisa membaca semua tentang penyempurnaannya
di sini
. Setelah perubahan ini, kami mendapatkan hasil yang luar biasa dan pengguna melihat jauh lebih sedikit persegi panjang kosong.
Permintaan Iklan Fast Fetch vs Delayed Fetch
Sangat kontras dengan delayed fetch, dalam hal ini permintaan iklan tidak dibuat sampai browser menjumpai tag iklan, jadi menunda pembuatan permintaan iklan dan perenderan susulan.
2. Tidak mengizinkan pengubahan posisi iklan yang terlihat pengguna tetapi mendukung iklan multiukuran
Seberapa sering Anda mengunjungi sebuah situs dan mulai membaca kontennya dan entah dari mana, sebuah iklan muncul dan mendorong konten ke bawah, menyebabkan ibu jari Anda melakukan tarian-mikro sehingga Anda bisa terus membacanya selagi iklan dimuat? Kami pikir pengalaman ini jelas buruk bagi pengguna, itulah sebabnya AMP melakukan tradeoff awal untuk memastikan hal ini tidak terjadi. Oleh karena itu, setiap iklan harus memiliki ukuran primer yang sudah ditentukan sebelumnya, sehingga AMP bisa mencadangkan ruang untuk iklan tersebut tetapi juga terus merender konten di sekitarnya tanpa harus mengubah posisi konten.
AMP mencadangkan ukuran iklan primer sehingga pengubahan posisi iklan yang terlihat pengguna tidak akan terjadi
Namun kami tahu bahwa iklan multiukuran mengarah ke monetisasi yang lebih baik karena membuat kumpulan permintaan lelang iklan menjadi lebih besar. AMP memperkenalkan cara bagi penayang untuk menentukan ukuran primer dan juga memberikan ukuran sekunder yang memungkinkan pengubahan ukuran iklan ke ukuran yang ditampilkan selama iklan berada di bawah viewport atau lebih kecil dari ukuran primer, jika di viewport saat ini. Masukan penayang menunjukkan bahwa ini adalah pertukaran sehat yang memberikan penayang > 90% peluang untuk menayangkan ukuran iklan yang menghasilkan pendapatan terbesar bagi mereka. Saya akan membahas lebih detail di postingan berikutnya, tetapi di sini adalah
entri blog
peluncuran.
3. Pilih format iklan yang mudah ditutup atau di-scroll oleh pengguna
Mari kita mengakuinya. Sebagian besar pengguna mengunjungi situs Anda untuk melihat konten, bukan iklan. Jadi beberapa pilihan desain dibuat di AMP agar tidak menampilkan iklan yang “menutupi” konten. Yang artinya tidak ada jendela pop-up (pengantara) yang menutupi konten. Menariknya,
industri
secara keseluruhan menolak format iklan tersebut. Sebagai gantinya, kami mendukung semua iklan dalam layout tetap, termasuk semua Iklan Multimedia.
AMP lebih suka iklan yang bisa dengan mudah ditutup pengguna
Selain itu, AMP meluncurkan beberapa format iklan bawaan seperti
sticky ads
dan
flying carpet ads
. Kami pun berencana untuk mendukung
lebih
banyak
format yang lebih beragam yang menjadi ketertarikan para penayang sembari memastikan pengalaman pengguna yang luar biasa. Dengan format iklan apa pun, pengguna harus bisa menge-tap tombol tutup di iklan atau dengan mudah men-scroll-nya.
Oke, tunjukkan saya uangnya?
Jangan salah paham, tidak ada yang semudah memencet tombol. Anda terus-menerus mengoptimalkan, mencoba hal baru, bereksperimen, dan menyelesaikan penyiapan iklan yang memberikan Anda pendapatan paling banyak sambil mengikuti prinsip-prinsip UX yang baik.
Namun kabar baiknya adalah bahwa optimalisasi semacam itu cukup sejalan dalam AMP. Selain itu, Anda hanya perlu melakukan beberapa hal untuk memastikan bahwa halaman AMP Anda menghasilkan pendapatan maksimum.
Selama beberapa minggu mendatang, saya akan membahas lebih mendalam mengenai masing-masing topik ini:
Kepadatan Iklan
Memilih Keterlihatan daripada Jumlah Dilihat
Iklan multiukuran & mengalir
Memproses traffic iklan langsung terjual (format & arsitektur permintaan tunggal)
Header Bidding & AMP
Monetisasi video menggunakan AMP IMA Video
Refresh Iklan Otomatis
Masa depan dengan iklan AMPHTML
Membuat perubahan & menghasilkan pendapatan dari AMP
Dengan AMP, kami yakin dapat memberikan Anda fleksibilitas dalam mengimplementasikan dari mana asal sumber iklan Anda dan vendor yang bisa bekerja sama. Anda tidak akan kehilangan bagian pendapatan hanya karena menggunakan AMP. Ada lebih dari 100 jaringan iklan yang terintegrasi secara bawaan dengan halaman AMP dan banyak lagi yang didukung melalui header bidding (menggunakan AMP RTC) dan pertukaran sisi server.
Tim AMP sangat percaya pada open web dan berusaha membantu penayang mem-build bisnis yang berkelanjutan di dalamnya, baik itu
paywall
atau periklanan.
Nantikan informasi selanjutnya dalam beberapa minggu mendatang dan kami sangat mengharapkan
masukan
Anda tentang hal ini atau hal lainnya mengenai AMP. Bila Anda tidak sabar untuk memulai, lihat
rangkuman praktik terbaik monetisasi
dan terapkan!
Mengajari Asisten Google menjadi Multilingual
19 September 2018
Ditulis oleh Johan Schalkwyk, VP dan Ignacio Lopez Moreno, Engineer, Google Speech
Penggunaan multilingual menjadi semakin umum, dengan beberapa sumber [
1
][
2
][
3
] menunjukkan bahwa penutur multilingual sudah melebihi monolingual, dan jumlah ini akan terus bertambah. Dengan populasi pengguna multilingual yang besar dan terus bertambah ini, maka semakin penting bagi Google untuk mengembangkan produk yang bisa mendukung banyak bahasa secara bersamaan sehingga kami bisa melayani pengguna dengan lebih baik.
Hari ini, kami
meluncurkan
dukungan multilingual untuk Asisten Google, yang memungkinkan pengguna melompat antar dua bahasa yang berbeda di seluruh kueri, tanpa harus kembali ke setelan bahasanya. Setelah pengguna memilih dua bahasa yang didukung, Bahasa Inggris, Spanyol, Prancis, Jerman, Italia, dan Jepang, dari sana mereka bisa berbicara dengan Asisten dalam salah satu bahasa tersebut dan Asisten akan merespons dengan baik. Sebelumnya, pengguna harus memilih satu setelan bahasa untuk Asisten, dan mengubah setelannya setiap kali mereka ingin menggunakan bahasa lain, tetapi sekarang, ini menjadi pengalaman yang semakin mudah dan praktis untuk penggunaan multilingual.
Asisten Google kini mampu mengidentifikasi bahasa, menginterpretasikan kueri dan memberikan respons menggunakan bahasa yang tepat tanpa mengharuskan pengguna menyentuh setelan Asisten.
Namun, membuatnya bekerja, bukanlah pekerjaan yang mudah. Faktanya, ini adalah upaya multitahun yang melibatkan penyelesaian banyak masalah yang menantang. Pada akhirnya, kami memecahkan masalah menjadi tiga bagian terpisah:
Mengidentifikasi Berbagai Bahasa
,
Memahami Berbagai Bahasa
dan
Mengoptimalkan Pengenalan Multilingual
untuk pengguna Asisten Google.
Mengidentifikasi Berbagai Bahasa
Orang memiliki kemampuan untuk mengenali ketika seseorang berbicara dengan bahasa lain, bahkan bila mereka tidak berbicara bahasa tersebut, hanya dengan memperhatikan akustik ucapan (intonasi, registrasi fonetik, dll). Namun, menetapkan framework komputasional untuk pengenalan bahasa lisan otomatis sangatlah menantang, bahkan dengan bantuan sistem pengenalan ucapan otomatis lengkap
1
. Pada tahun 2013, Google mulai bekerja pada teknologi identifikasi bahasa lisan (LangID) menggunakan deep neural network [
4
][
5
]. Saat ini, model LangID terbaru kami bisa membedakan antara pasangan bahasa di lebih dari 2000 pasangan bahasa alternatif menggunakan
recurrent neural network
, famili neural network yang sangat berhasil dalam masalah pemodelan rangkaian, seperti yang terdapat dalam pengenalan ucapan, deteksi suara, pengenalan penutur dan lainnya. Salah satu tantangan yang kami hadapi adalah bekerja dengan kumpulan audio yang lebih besar — mendapatkan model yang secara otomatis memahami berbagai bahasa dalam skala besar, dan mencapai standar kualitas yang memungkinkan model tersebut berfungsi dengan baik.
Memahami Berbagai Bahasa
Untuk memahami lebih dari satu bahasa sekaligus, beberapa proses harus dijalankan secara paralel, masing-masing memberikan hasil yang terus meningkat, memungkinkan Asisten tidak hanya mengidentifikasi bahasa yang diucapkan kueri tetapi juga mengurai kueri untuk membuat perintah yang dapat ditindaklanjuti. Misalnya, bahkan untuk lingkungan monolingual, bila pengguna meminta “
setel alarm jam 6 sore
”, Asisten Google harus memahami bahwa "
setel alarm
" berarti membuka aplikasi jam, memenuhi parameter eksplisit “
6 sore
” dan membuat kesimpulan bahwa alarm harus disetel untuk hari ini. Untuk membuatnya berfungsi bagi
setiap pasangan
bahasa yang didukung adalah sebuah tantangan, karena Asisten menjalankan tugas yang sama untuk kasus monolingual, tetapi sekarang juga harus mengaktifkan LangID, dan bukan hanya satu tetapi dua
sistem pengenalan ucapan
monolingual secara bersamaan (nanti kami akan menjelaskan lebih lanjut tentang batasan dua bahasa saat ini di postingan ini).
Yang penting, Asisten Google dan layanan lain yang direferensikan dalam kueri pengguna secara tidak bersamaan menghasilkan hasil inkremental real-time yang perlu dievaluasi dalam hitungan milidetik. Hal ini bisa dicapai dengan bantuan algoritme tambahan yang menyusun peringkat hipotesis transkripsi yang disediakan oleh masing-masing sistem pengenalan ucapan menggunakan probabilitas bahasa kandidat yang dihasilkan oleh LangID, keyakinan kita pada transkripsi dan preferensi pengguna (seperti artis favorit, misalnya).
Skema sistem pengenalan ucapan multilingual kami yang digunakan oleh Asisten Google dibandingkan dengan sistem pengenalan ucapan monolingual standar. Algoritme peringkat digunakan untuk memilih hipotesis pengenalan terbaik dari dua pengenal ucapan monolingual menggunakan informasi yang relevan tentang pengguna dan hasil langID inkremental.
Ketika pengguna berhenti berbicara, model tidak hanya memastikan bahasa apa yang diucapkan, tetapi juga apa yang dikatakan. Tentu saja, proses ini membutuhkan arsitektur canggih yang tentunya membutuhkan biaya pemrosesan yang meningkat dan kemungkinan hadirnya latensi yang tidak perlu.
Mengoptimalkan Pengenalan Multilingual
Untuk meminimalkan efek yang tidak diinginkan ini, semakin cepat sistem bisa membuat keputusan tentang bahasa apa yang diucapkan, maka akan semakin baik. Bila sistem sudah mengetahui pasti bahasa yang diucapkan sebelum pengguna menyelesaikan kueri, maka sistem akan berhenti menjalankan ucapan pengguna melalui pengenal yang hilang dan menghapus hipotesis yang hilang, sehingga menurunkan biaya pemrosesan dan mengurangi potensi latensi. Dengan memperhatikan hal ini, kami melihat beberapa cara untuk mengoptimalkan sistem.
Satu kasus penggunaan yang kami pertimbangkan adalah bahwa orang-orang biasanya menggunakan bahasa yang sama di seluruh kueri mereka (yang juga merupakan bahasa yang biasanya ingin didengar pengguna dari Asisten), dengan pengecualian tentang menanyakan entitas dengan nama dalam bahasa yang berbeda. Ini berarti bahwa, dalam banyak kasus, berfokus pada bagian pertama kueri memungkinkan Asisten untuk membuat dugaan awal bahasa yang diucapkan, bahkan dalam kalimat yang berisi entitas dalam bahasa yang berbeda. Dengan identifikasi awal ini, tugas ini disederhanakan dengan beralih ke pengenal ucapan monolingual tunggal, seperti yang kami lakukan untuk kueri monolingual. Namun, membuat keputusan yang cepat tentang bagaimana dan kapan harus berkomitmen pada satu bahasa, membutuhkan perubahan teknologi akhir: secara khusus, kami menggunakan teknik
random forest
yang menggabungkan beberapa sinyal kontekstual, seperti jenis perangkat yang digunakan, jumlah hipotesis ucapan yang ditemukan, seberapa sering kami menerima hipotesis yang sama, ketidakpastian dari pengenal ucapan individual, dan seberapa sering setiap bahasa digunakan.
Cara lain yang kami lakukan untuk menyederhanakan dan meningkatkan kualitas sistem adalah dengan membatasi daftar bahasa kandidat yang bisa dipilih pengguna. Pengguna bisa memilih dua dari enam bahasa yang saat ini didukung perangkat Beranda, yang akan memungkinkan kami mendukung mayoritas penutur multilingual. Namun, seiring upaya kami untuk terus meningkatkan teknologi, kami berharap dapat menangani dukungan tiga bahasa pada masa mendatang, kami mengerti bahwa ini akan semakin meningkatkan pengalaman basis pengguna yang terus berkembang.
Bilingual ke Trilingual
Sejak awal, tujuan kami adalah membuat Asisten secara natural bisa berbicara ke
semua
pengguna. Dukungan multilingual telah menjadi fitur yang sangat diminta, dan ini adalah sesuatu yang menjadi perhatian tim kami beberapa tahun yang lalu. Namun tidak hanya penutur bilingual yang banyak di seluruh dunia saat ini, kami juga ingin mempermudah pengguna trilingual, atau keluarga yang tinggal di rumah di mana lebih dari dua bahasa diucapkan.
Dengan update hari ini, kami berada di jalur yang benar, dan hal ini dimungkinkan berkat machine learning lanjutan, teknologi pengenalan ucapan dan bahasa, dan komitmen tim kami untuk terus menyempurnakan model LangID. Kami sekarang bekerja untuk mengajari Asisten Google cara memproses lebih dari dua bahasa secara bersamaan, dan terus bekerja untuk menambahkan lebih banyak dukungan bahasa di masa mendatang — nantikan!
1
Secara umum sudah diakui bahwa pengenalan bahasa lisan jauh lebih menantang daripada identifikasi bahasa berbasis teks, ketika teknik yang relatif sederhana berdasarkan kamus bisa melakukan tugas ini dengan baik. Pola frekuensi/waktu kata-kata yang diucapkan sulit untuk dibandingkan, kata-kata yang diucapkan lebih sulit dibatasi karena bisa diucapkan tanpa jeda dan dengan kecepatan yang berbeda dan mikrofon mungkin merekam suara latar belakang selain ucapan pengguna.
↩
Menganimasikan Jadwal di aplikasi Android Google I/O 2018
15 September 2018
Ilustrasi oleh
Virginia Poltrack
Animasi di aplikasi Google I/O
Saya baru-baru ini menjadi bagian dari tim hebat yang bekerja untuk
aplikasi Android Google I/O 2018
. Ini adalah aplikasi pendamping konferensi, yang memungkinkan peserta dan orang-orang yang tinggal jauh untuk menemukan sesi, mem-build jadwal terpersonalisasi dan memesan tiket event (bila Anda cukup beruntung bisa berada di sana!). Kami build sejumlah fitur animasi menarik di aplikasi yang saya yakini sangat meningkatkan pengalaman. Kode untuk aplikasi ini baru saja dibuat
open source
dan saya ingin menyoroti beberapa instance ini dan beberapa detail implementasi yang menarik.
Beberapa elemen animasi di aplikasi I/O
Umumnya ada 3 tipe animasi yang kami gunakan dalam aplikasi:
Animasi hero — digunakan untuk memperkuat branding dan menghadirkan momen kegembiraan
Transisi layar
Perubahan status
Saya ingin membahas beberapa hal ini secara mendetail.
Hitung mundur
Bagian dari peran aplikasi adalah untuk mem-build antisipasi dan kegembiraan yang meluap terhadap konferensi. Karena itu, tahun ini kami menyertakan hitung mundur animasi berukuran besar yang menampilkan waktu dimulainya konferensi di layar pembuka dan bagian Info. Ini juga merupakan peluang bagus untuk menyematkan branding event ke dalam aplikasi, membawa banyak karakter.
Hitung mundur dimulainya konferensi
Animasi ini dirancang oleh perancang gerakan dan diserahkan sebagai serangkaian file
Lottie
json: setiap 1 detik menampilkan angka yang menganimasikan ‘masuk’ lalu ‘keluar’. Format Lottie memudahkan kami untuk memasukkan file ke dalam assets bahkan menawarkan metode mudah seperti
setMinAndMaxProgress
yang memungkinkan kita untuk memainkan hanya paruh pertama atau terakhir dari sebuah animasi (untuk menampilkan angka yang menganimasikan masuk atau keluar).
Bagian yang menarik sebenarnya adalah mengatur semua animasi ini ke dalam hitung mundur secara menyeluruh. Untuk melakukannya, kami membuat
CountdownView
khusus yang merupakan
ConstraintLayout
yang cukup
kompleks
yang menyimpan sejumlah LottieAnimationViews. Di sini, kami
membuat
delegasi
Kotlin untuk mengenkapsulasi permulaan animasi yang sesuai. Ini memungkinkan kami untuk menetapkan sebuah Int bagi setiap delegasi digit yang seharusnya ditampilkan dan delegasi akan menyiapkan dan memulai animasi. Kami memperluas delegasi
ObservableProperty
yang memastikan bahwa kami hanya menjalankan animasi ketika digit berubah. Loop animasi kemudian hanya memposting runnable setiap detik (ketika tampilan dilampirkan) yang mengalkulasi digit apa yang harus ditampilkan setiap tampilan dan mengupdate delegasi.
Reservasi
Salah satu tindakan kunci dari aplikasi ini adalah mengizinkan peserta memesan tiket. Karena itu, kami menampilkan aksi ini dengan jelas dalam
FAB
di layar detail sesi. Kami merasa bahwa penting untuk hanya melaporkan sesi telah dipesan setelah pemesanan berhasil diselesaikan di backend (tidak seperti tindakan yang kurang penting seperti membintangi sesi ketika kami langsung mengupdate UI). Ini mungkin memerlukan waktu beberapa saat selagi kita menunggu respons dari backend sehingga untuk membuatnya lebih responsif kami menggunakan ikon animasi untuk memberikan umpan balik bahwa kami sedang memprosesnya dan untuk memperlancar transisi ke status baru.
Memberikan umpan balik saat memesan tiket sesi
Hal ini dipersulit oleh fakta bahwa ada sejumlah status yang perlu digambarkan oleh ikon ini: sesi mungkin dapat dipesan, mereka mungkin sudah memesan tiket, bila sesi penuh maka daftar tunggu mungkin tersedia atau mereka mungkin berada di daftar tunggu, atau menonaktifkan pemesanan yang dekat dengan awal sesi. Hal ini mengakibatkan banyak permutasi dari berbagai status yang harus dianimasikan. Untuk menyederhanakan transisinya, kami memutuskan untuk selalu melewati status ‘working’; animasi jam pasir di atas. Oleh karena itu setiap transisi sebenarnya adalah sambungan: status 1 → working & working → status 2. Hal ini sangat menyederhanakan semuanya. Masing-masing animasi ini kami build menggunakan
shapeshifter
; lihat file avd_state_to_state
di sini
.
Untuk menampilkannya, kami menggunakan tampilan khusus dan sebuah
AnimatedStateListDrawable
(ASLD). Bila Anda belum pernah menggunakan ASLD sebelumnya, itu adalah (seperti namanya) versi animasi dari
StateListDrawable
yang kemungkinan besar telah
Anda
jumpai — yang memungkinkan Anda untuk tidak hanya menyediakan drawable berbeda tiap status tetapi juga
transisi
antar status (dalam bentuk
AnimatedVectorDrawable
atau
AnimationDrawable
).
Berikut adalah drawable
yang menetapkan gambar statis serta transisi masuk dan keluar status working untuk ikon reservasi.
Kami membuat
tampilan khusus
untuk mendukung status khusus kami sendiri. Tampilan menawarkan beberapa status standar seperti ditekan atau dipilih. Demikian pula, Anda bisa
menetapkannya sendiri
dan memiliki
rute
Tampilan ke setiap Drawable yang ditampilkan. Kami menetapkan state_reservable, state_reserved kami sendiri, dll. Kami kemudian membuat
sebuah enum
dari status-status yang berbeda ini, mengenkapsulasi status tampilan ditambah setiap atribut yang terkait seperti deskripsi konten yang berhubungan. Logika bisnis kita kemudian bisa dengan mudah menetapkan nilai yang tepat dari enum ini pada tampilan (melalui data binding) yang akan mengupdate status drawable, yang memulai animasi melalui ASLD. Kombinasi status khusus dan AnimatedStateListDrawable adalah cara yang cerdik untuk menerapkan hal ini, menjaga banyak status dalam layer deklaratif, menghasilkan kode tampilan yang minimal.
Transisi pembicara
Banyak transisi layar bekerja dengan baik bersama animasi jendela standar. Sebuah pengecualian dari hal ini adalah
transisi
ke layar detail pembicara. Layar ini menampilkan gambar pembicara di salah satu sisi transisi dan merupakan kandidat sempurna untuk transisi elemen bersama. Ini membantu memudahkan perubahan konteks antar layar.
Transisi elemen bersama
Ini adalah transisi elemen bersama yang cukup standar, menggunakan class
ChangeBounds
dan
ArcMotion
platform pada ImageView.
Yang lebih menarik adalah bagaimana memulai transisi ini sesuai dengan
pola Event
yang kita gunakan untuk navigasi. Pada dasarnya, pola ini memisahkan event masukan (seperti menge-tap pembicara) dari event navigasi, menempatkan ViewModel yang bertanggung jawab mengenai cara merespons input. Dalam hal ini, pemisahan ini berarti bahwa ViewModel
mengekspos
LiveData Event, yang hanya mengetahui ID pembicara yang akan dibuka. Memulai transisi elemen bersama membutuhkan View bersama, yang tidak kita miliki saat ini. Kita memecahkan masalah ini dengan
menyimpan
ID pembicara sebagai tag pada tampilan ketika terikat, sehingga tampilan nantinya bisa
diambil kembali
saat kita perlu membuka layar detail pembicara tertentu.
Filter
Bagian inti dari aplikasi konferensi adalah memfilter banyak event hingga ke hal-hal yang Anda minati. Setiap topik memiliki warna yang terkait dengan hal tersebut agar mudah dikenali dan kami menerima desain sangat bagus untuk 'chip' khusus yang digunakan saat memilih filter:
Chip filter animasi
Kami melihat
Chip
dari Material Components tetapi memilih untuk mengimplementasikan
tampilan khusus
kami sendiri untuk kontrol yang lebih besar terhadap tampilan dan animasi di antara status ‘checked’. Ini diimplementasikan menggunakan canvas drawing dan
StaticLayout
untuk menampilkan teks. Tampilan memiliki properti progress tunggal [0–1] yang memodelkan unchecked–checked. Untuk mengubah status, kami cukup menganimasikan nilai ini serta membuat tampilan tidak valid dan kode rendering
secara linear menginterpolasi
posisi dan ukuran elemen berdasarkan hal ini.
Awalnya ketika mengimplementasikan ini, saya membuat tampilan mengimplementasikan antarmuka
Checkable
dan memulai animasi ketika metode setChecked menetapkan status baru. Saat kami menampilkan beberapa filter dalam RecyclerView, ini memiliki efek menjalankan animasi yang tidak diinginkan bila filter yang dipilih di-scroll keluar dan tampilan diikat kembali ke filter tidak dipilih yang di-scroll masuk. Ups. Oleh karena itu, kami menambahkan metode terpisah untuk memulai animasi yang memungkinkan kita untuk membedakan antara animasi yang diaktifkan oleh klik dan update langsung ketika mengikat data baru ke tampilan.
Selain itu, ketika kami memperkenalkan tombol beralih animasi ini, kami menemukan bahwa itu tidak dapat diandalkan, yaitu bingkai yang turun. Apakah kode animasi saya harus disalahkan? Filter ini ditampilkan di BottomSheet di depan layar jadwal konferensi utama. Saat filter diaktifkan, kami memulai logika pemfilteran untuk diterapkan ke jadwal (dan mengupdate jumlah event yang sesuai dalam judul lembar filter). Kemudian penjelajahan
systrace
dimulai, kami memutuskan bahwa masalahnya terjadi ketika filter diterapkan, ViewPager dari RecyclerView yang menampilkan jadwal sebagaimana mestinya dan diupdate ke data yang baru dikirim. Hal ini menyebabkan sejumlah tampilan digelembungkan lalu diikat. Semua pekerjaan ini menghabiskan bujet bingkai kami… tetapi jadwal mengupdate tidak terlihat karena terletak di belakang lembar filter. Kami membuat keputusan untuk menunda menjalankan pemfilteran yang sebenarnya hingga animasi berjalan, kami mengorbankan beberapa kerumitan implementasi untuk pengalaman pengguna yang lebih mulus. Awalnya saya mengimplementasikannya menggunakan postDelayed, tetapi ini menyebabkan masalah bagi pengujian UI. Sebagai gantinya, kami mengubah metode yang memulai animasi untuk menerima lambda untuk dijalankan di akhir. Hal ini memungkinkan kami untuk lebih mengindahkan setelan animasi pengguna dan menguji eksekusi dengan benar.
Ayo Gunakan Animasi
Secara keseluruhan saya merasa animasi benar-benar berkontribusi untuk pengalaman, karakter, branding, dan responsivitas aplikasi. Semoga postingan ini bisa membantu menjelaskan mengapa dan bagaimana mereka digunakan dan memberi Anda petunjuk untuk implementasinya.
Menganimasikan Jadwal
awalnya dipublikasikan di
Developer Android
di Medium, di sini pengguna terus melanjutkan konversasi dengan menandai dan merespons cerita ini.
Labels
#GoogleforGames
#JetpackCompose
#TheAndroidShow
#WeArePlay
10 years
64bit
actions on google
ad blocking
admob
Ads
adventure games
agency
AI
amp
android
android 13
Android 14
Android 15
Android betas
android dev summit
android developers
android development
Android Emulator
Android Jetpack
Android release
android sdk
android studio
Android Studio Emulator
android studio flamingo
Android Studio Iguana
Android UI
androidstudio
anniversary
announcement
anthos
apac
api
aplikasi
App
app development
Apps
arcore
Artificial Intelligence
assistant
augmented reality
bangkit
Baseline Profiles
beginner
best practices
beta
big query
CameraX
case study
chrome
chrome ads
chrome os
Cloud
coalition
coalition for better ads
compose
conferencing
coroutine
DAC/Develop
DAC/Google
dart
data
data binding
data flow
data science
develop
developer
Developer Preview
developer stories
developer tools
developer wear os 4
developers
dialogflow
documentation
domains
doubleclick
ecosystem
emojis
entepreneur
entrepreneurs
events
explore
featured
film
firebase
flutter
flutter 3
flutter app development
flutter3
foldables
game
Game Development
Games
Gemini
Gemini Pro
Generative AI
Global Game Jam
gmail
google
google bisnisku
google cloud
google code-in
google design
Google Developers
google font
google for entrepreneurs
Google for Games Developer Summit
google io
google maps
google partners
google photos
google pixel
google pixel fold
google pixel tablet
google play
Google Play Academy
Google Play Console
Google Play Developers
Google Play Devs
Google Play Indie games accelerator
google play policy
Google Play x Unity Game Developer Training
google sign-in
googleforstartup
GooglePlay
graphics
gsuite
how to
how-to guide
hybrid interface
indie developers
indie game developers
indie games
Indie Games Accelerator
indonesia
insight
ios
Javascript
jetpack
jetpack compose
jetpack compose 1.5
JuaraGCP
kebijakan
kotlin
kubernetes
latest
launchpad
launchpad accelerator
Learn
Localization
lyft
Machine
machine learning
MAD
material design
meet
Meta
mobile
Mobile App Development
mobile games
modifier
now
OnePlus
opensource
pagespeed
partial
PGS
Pixel Fold AVD
Pixel Tablet AVD
platform
Platform_Update
play console
play privacy
play quality
play security
play store
Policy Bytes
Policy webinar
privacy
Problem Solving
Productivity
progressive web app
Project IDX
python
release notes
releases
reporting api
roadmaps
screen
screensharing
security
shapes
Sharing
small business
Solve
spotify
startup
student developers
subs
success stories
Tablets
tensorflow
testing
text-to-speech
The Android Show
theandroidshow
training
transparency
tutorial
Tutorials
twitter
update
usecase
users
Video
videocall
vr
Wear OS
web
windowmanager
workmanager
Archive
2024
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Subscribe
Follow @googledevsid
Visit
Google Developers
for docs, event info, and more.
