Local blog for Indonesian speaking developers
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.
‘Web yang Berkemampuan’: Retrospektif 10 Tahun
14 September 2018
Ketika kami
memperkenalkan Chrome
pada tahun 2008, tujuan kami adalah “terus berevolusi bersama dengan web dan terus mem-build fondasi kuat bagi aplikasi web modern.” Untuk merayakan tahun yang kesepuluh, kami ingin menyoroti beberapa perubahan besar dalam beragam kemampuan web dan kami merasa beruntung bisa berbagi dengan vendor browser lainnya.
Ketika pertama kali halaman ditayangkan di open web pada tahun
1990
, orang-orang menyadari bahwa kemampuan untuk menghadirkan konten dinamis akan menjadikan web unik—Anda bisa memberikan informasi dan fungsi hanya dengan membagikan URL.
Common Gateway Interface
standar dirilis pada tahun 1993 yang menetapkan antarmuka sederhana untuk server web guna menjalankan kode dalam merespons permintaan web. Ini membawa era pengalaman dan kemampuan baru dalam berkomputer, dapat diakses hanya dengan mengklik link. Lompat maju dua tahun ke JavaScript, lalu setahun lagi ke bingkai, khususnya tag <iframe>. Inovasi ini memungkinkan developer memuat konten secara dinamis ke dalam halaman, menghadirkan tingkat interaktivitas baru untuk web, dan meningkatkan ekspektasi pengguna tentang apa yang bisa dilakukan di browser.
Aksesibilitas, dapat di-link, dapat diindeks, dan jangkauan universal akan selalu menjadi kekuatan inti web. Bersama dengan kekuatan super ini, pengguna menginginkan pengalaman yang lebih kaya dan menarik. “
Ajax
” diciptakan pada tahun 2005 untuk menggambarkan kombinasi XML dan JavaScript tidak bersamaan, yang membentuk web yang lebih interaktif dan modern. Hal ini mengarah pada pembuatan layanan seperti Google Maps, menggabungkan web sebagai cara terbaik untuk menghadirkan pengalaman yang tersedia bagi siapa saja, di perangkat apa pun.
2008 – 2014: Aplikasi web, HTML5, dan dimulainya era seluler
Chrome mengalami kemajuan besar pada tahun-tahun awalnya, dengan sejumlah besar apa yang sekarang disebut “core API” yang tersedia bagi web setelah implementasi WebKit. Elemen
video
,
audio
, dan
canvas
adalah beberapa fitur “web modern” pertama yang masih bisa kita ingat dengan jelas (dan siapa yang dapat melupakan border-radius?). Fitur-fitur ini membawa tingkat interaksi baru untuk pengalaman web, dan artinya developer tidak lagi membutuhkan plugin seperti Adobe Flash atau Java, untuk mem-build media interaktif dan pengalaman grafis.
Eksperimen Chrome
telah merekam contoh-contoh hebat pengalaman beragam yang merupakan hasil langsung dari kinerja web yang ditingkatkan.
“Web Seluler” benar-benar menghantam dunia pada tahun 2010, dan kami melihat banyak primitif platform baru yang diperkenalkan untuk platform ini (banyak yang terinspirasi langsung oleh
Google Gears
) untuk membantu mem-build aplikasi web menjadi lebih mudah. Kita sekarang bisa membuat aplikasi yang responsif dan aktif secara offline dengan
AppCache
dan
WebSQL
, meminta izin untuk mengakses
geolokasi
pengguna, bahkan mengetahui
orientasi
perangkat pengguna.
WebSocket
hadir di platform ini pada tahun yang sama, menjanjikan perubahan dalam tipe pengalaman yang bisa diberikan oleh developer di web. Mereka tidak lagi harus menggunakan long polling untuk mengaktifkan saluran dua arah antara pengguna dan layanan; developer sekarang memiliki saluran dua arah dengan API sederhana untuk menyediakan komunikasi real-time.
Plink adalah eksperimen musik interaktif yang menyinkronkan status player lewat websocket.
Empat API utama hadir di Chrome pada tahun 2011.
WebGL
,
Web Audio
, dan
Fullscreen API
memungkinkan kita build pengalaman yang kaya dan imersif dan bisa memanfaatkan seluruh layar.
IndexedDB
— mekanisme penyimpanan "web pertama kali" yang baru - memungkinkan kita menyimpan dan melakukan kueri objek JavaScript yang dapat diserialkan seperti String, Objek, Array, File, dan Blob dengan lebih efektif.
Chrome Web Lab adalah eksperimen yang menjembatani dunia fisik dan digital. Chrome Web Lab menggunakan Web Socket, video, streaming real-time, WebGL, dan Audio Web untuk menciptakan dunia yang imersif.
Tahun perubahan besar bagi pengalaman pengubah-permainan di web hadir pada tahun 2012. Dengan memanfaatkan
WebGL
dan
Fullscreen
,
Pointer Lock
dan
Gamepad
API memungkinkan kita build game dan pengalaman web lainnya yang terasa sangat interaktif. Pengumpulan
WebRTC
API yang mengubah-permainan benar-benar membuat web berbeda dari semua platform lainnya: Ini memungkinkan kita build chat-video P2P dan berbagi data secara real-time, tanpa memerlukan plugin atau tumpukan kepemilikan, dan dapat diakses hanya dengan mengklik link.
Salah satu panggilan pertama WebRTC Chrome pada Android ke Chrome pada Android (Maret 2013)
Hanya dalam tujuh tahun, web berubah secara drastis. Browser menjadi jauh lebih cepat dan berkemampuan, memungkinkan developer mem-build pengalaman yang lebih beragam di desktop. Pengguna mulai mengonsumsi lebih banyak konten di seluler, yang berarti kami semua harus memikirkan kembali bagaimana pengalaman akan berfungsi di berbagai perangkat dan faktor bentuk, bahkan ketika pengguna tidak memiliki konektivitas.
2015-2018: PWA, Extensible Web, dan era integrasi yang lebih mendalam
Pada tahun 2015, kami mengalami perubahan mendasar dalam cara berpikir tentang mengintegrasikan kemampuan ke dalam platform web.
Manifesto Extensible Web
meminta engineer browser untuk mempertimbangkan platform berlapis yang menawarkan primitif tingkat rendah yang lebih mudah dijelaskan, lebih efisien untuk diimplementasikan dan memungkinkan developer web bisa dengan mudah mem-build abstraksi tingkat lebih tinggi, sehingga meningkatkan modulasi dan ketersediaan fitur baru yang menarik.
Pekerja Layanan
adalah contoh build dalam API yang mengikuti prinsip-prinsip ini. Pekerja Layanan adalah potongan kecil JavaScript yang berada di antara browser dan jaringan, dan memungkinkan developer memutuskan apa yang harus dilakukan dengan setiap permintaan web.
Kombinasi Pekerja Layanan dan beberapa API baru menandai awal era Progressive Web Apps (PWA). PWA adalah situs berkualitas tinggi yang menggabungkan jangkauan web dengan ekspektasi pengguna yang datang dengan platform bawaan. Secara khusus, PWA...
Cepat—mereka dimuat dengan cepat
Andal—mereka tidak akan menampilkan “
downasaur
,” bahkan dalam kondisi jaringan yang tidak menentu, dengan memanfaatkan Pekerja Layanan dan Cache API
Menarik—mereka merespons interaksi pengguna secara cepat dengan animasi super halus dan scroll mulus
Berkemampuan—situs terasa seperti ekstensi alami perangkat, dengan pengalaman pengguna imersif yang disediakan oleh fitur seperti “fullscreen” dan mode standalone melalui Manifes Aplikasi Web; mereka memberikan kemampuan untuk mencapai tujuan bisnis tertentu, seperti interaksi ulang melalui fitur Add to Homescreen dan notifikasi Push Web
Seiring dengan PWA yang semakin mapan, begitu pula dengan kemampuan platform ini.
Background Sync API
meningkatkan peluang developer untuk meningkatkan ketahanan aplikasi mereka. Kami juga mendapat pemahaman yang lebih baik tentang kemampuan jaringan dengan ekstensi untuk
Network Information API
.
Pointer Events
, komponen penting bagi setiap situs web atau aplikasi, hadir di Chrome setelah menunggu lama. Pointer Events menghadirkan model terpadu untuk menangani semua bentuk masukan berbasis gestur, mulai dari sentuhan ke pena hingga pointer mouse.
Pada tahun 2017, integrasi aplikasi web yang lebih mendalam dengan sistem operasi host dan akses aman ke perangkat di sekitar pengguna telah hadir..
Image Capture
dan
Media Capture
API menyediakan akses full-frame dan kontrol atas kamera ponsel, serta sumber masukan lain seperti canvas.
Web Share API
memungkinkan situs berbagi data secara langsung dengan sistem berbagi bawaan milik sistem operasi.
Web Bluetooth API
memungkinkan pengguna dengan aman memilih perangkat Bluetooth LE dan memiliki halaman web yang berinteraksi dengan perangkat tersebut.
Web USB API
mengaktifkan tingkat konektivitas yang sama, tetapi ke perangkat yang terhubung ke komputer pengguna.
WebAssembly
(WASM) membuka banyak kemungkinan. WASM membawa waktu proses yang bisa mengeksekusi kode pada kinerja mendekati-bawaan. Ditambah, ia membuka dunia baru pengalaman di web dengan mengizinkan developer menggunakan basis kode yang sudah ada yang di-build untuk platform lain di platform web.
Web VR
datang ke web pada waktu yang hampir bersamaan dengan kedatangannya di platform bawaan. Web VR memungkinkan kita memberikan pengalaman imersif tanpa menginstal aplikasi, yang secara signifikan mengurangi kesenjangan antara aplikasi primitif bawaan baru yang hadir di platform dan yang tersedia di seluruh platform web.
Meneruskan ke masa depan
Kami sangat bersemangat dengan kemungkinan platform web. Web bisa (dan seharusnya) kaya fitur, tetapi kemampuan baru tidak berarti harus lebih kompleks. Pengembangan web harus bisa terprediksi, terkelola, dan dapat dilakukan dengan mudah. API yang akan datang seperti
Feature Policy
adalah contoh yang sangat bagus dari tambahan tersebut yang akan membantu developer membuat situs menakjubkan dengan cara yang lebih terprediksi, dan menyediakan kontrol dan kustomisasi lebih banyak atas UX fitur browser tertentu. Feature Policy adalah jalur panduan bawaan browser untuk membantu developer web menghindari perangkap awam dan menggunakan praktik terbaik.
Layered API
adalah inisiatif lain yang membuat kami bersemangat. Dengan hal itu, developer akan dapat memuat dan menggunakan fitur tingkat-tinggi yang dikirimkan langsung ke browser sebagai modul JS. Misalnya, daripada mem-build komponen scroll-virtualisasi khusus, developer bisa mengimpornya saja dan menggunakan <virtual-scroller> di sebuah situs. Layered API bisa dengan cepat diiterasi oleh badan standar dan diimplementasikan oleh vendor browser, dan akan membantu membuat library standar "prabayar" untuk web. Dan lebih jauh lagi, Houdini dan Web XR API akan secara radikal mengubah pengalaman mengenai apa yang bisa kita build di web dan dengan web.
Dalam 10 tahun terakhir, kami telah melihat laju peningkatan besar ketika fitur primitif dan kemampuan baru diperkenalkan ke web. Kami berterima kasih kepada semua vendor browser untuk pekerjaan berkelanjutan mereka dalam membuat dan mengiterasi spesifikasi, menggunakan proses yang disederhanakan seperti yang ditetapkan oleh
WICG
dan berdasarkan prinsip-prinsip dalam
Manifesto Extensible Web
. Kami akan melanjutkan komitmen kami untuk terus bekerja dengan vendor browser dan ekosistem developer untuk memprioritaskan fitur yang dibutuhkan pengguna, dan memastikan bahwa kemampuan tersebut hadir “melalui web”. Dengan demikian, kami bisa menegakkan misi awal kami, dan pada saat yang bersamaan juga dapat memprioritaskan keamanan pengguna, visibilitas, akses instan, dan jangkauan universal ke semua orang di planet ini.
Inilah masa depan open web yang lebih berkemampuan.
Ditulis oleh Paul Kinlan, the Wizzy Web Warrior.
Subscribe
Labels
actions on google
admob
agency
amp
android
assistant
augmented reality
chrome
dialogflow
documentation
domains
doubleclick
firebase
flutter
gmail
google bisnisku
google cloud
google code-in
google design
google font
google for entrepreneurs
google io
google maps
google partners
google play
google sign-in
gsuite
ios
launchpad
launchpad accelerator
machine learning
material design
pagespeed
progressive web app
python
tensorflow
vr
web
Archive
2018
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
Google
on
Follow @googledevsid
