Notifikasi toast adalah UX yang buruk

• Kelemahan utama notifikasi toast adalah lokasi fokus perhatian pengguna terpisah dari lokasi umpan balik, sehingga sulit langsung mengaitkan hasil dengan tindakan yang baru saja dilakukan
• Alur penyimpanan YouTube membuat pandangan berpindah dari tombol Save di kanan, ke modal di tengah, lalu ke toast di kiri bawah sehingga interaksi terputus, dan juga tidak ada indikator loading saat terjadi jeda
• Setelah mengubah checkbox, pengguna harus menunggu toast sebelumnya menghilang untuk melihat pesan konfirmasi terbaru, dan tombol Undo pada toast juga tidak perlu bila cukup menekan checkbox lagi
• Cara yang lebih baik adalah menempatkan umpan balik di dalam lokasi tindakan, misalnya menampilkan playlist di bawah tombol dan menunjukkan indikator loading saat checkbox sedang diubah untuk memperlihatkan status proses
• Yang lebih buruk daripada toast adalah tidak ada umpan balik sama sekali, jadi jika belum ada waktu untuk merancang atau mengimplementasikan umpan balik yang lebih baik, toast masih lebih baik daripada tidak ada apa-apa

---

Masalah dasar toast

• Notifikasi toast umumnya muncul jauh dari tempat perhatian pengguna saat itu
• Jika umpan balik muncul di lokasi yang berbeda dari tombol yang baru ditekan atau area yang sedang diedit, pengguna akan kesulitan memahami hubungan antara tindakan dan hasilnya

Masalah pada alur penyimpanan YouTube

• Dalam contoh YouTube, setelah pengguna mengklik tombol Save di sisi kanan layar, mereka kemudian melihat modal di tengah layar dan toast di kiri bawah secara berurutan
• Alur ini memaksa pandangan berpindah ke beberapa lokasi dan membuat umpan balik lebih sulit dipahami secara langsung
  • Toast tertunda tanpa indikator loading
  • Saat checkbox di dalam modal dinyalakan atau dimatikan, pengguna harus menunggu beberapa detik sampai toast sebelumnya hilang untuk melihat toast konfirmasi terbaru
  • Tombol Undo pada toast tidak perlu karena pengguna cukup mengklik checkbox lagi

Cara menyelesaikannya tanpa toast

• Dengan perancangan ulang yang sederhana, umpan balik yang sama bisa ditangani tanpa toast
  • Menampilkan playlist tepat di bawah tombol, bukan dalam modal
  • Menunjukkan indikator loading saat checkbox dinyalakan atau dimatikan
  • Ketika indikator loading menghilang, itu secara alami memberi tahu bahwa tindakan telah selesai
• Karena umpan balik tetap berada di lokasi yang dimanipulasi pengguna, tidak diperlukan toast terpisah

Contoh Gmail dan umpan balik salin

• Saat email diarsipkan di Gmail, muncul toast konfirmasi
  • Namun, hilangnya email dari daftar sebenarnya sudah cukup untuk menunjukkan bahwa pengarsipan berhasil
  • Meski begitu, toast bisa berguna untuk fungsi urungkan dan saat menggunakan pintasan keyboard
• Ada juga kasus ketika toast ditampilkan setelah sesuatu disalin ke clipboard
  • Dalam contoh ini, tombol itu sendiri sudah memuat status konfirmasi sehingga toast benar-benar tidak diperlukan

Umpan balik tetap diperlukan

• Yang lebih buruk daripada toast adalah tidak ada umpan balik sama sekali
• Jika belum ada waktu untuk merancang atau mengimplementasikan mekanisme umpan balik yang lebih baik, toast tetap lebih baik daripada tidak ada apa-apa

Cara Cakedesk menghindari toast

• Cakedesk adalah aplikasi invoice yang mengutamakan offline dan tanpa biaya langganan, serta dapat mengirim email dari dalam aplikasi
• Setelah menekan tombol Send pada email, alih-alih memberi umpan balik lewat toast, alur status dirancang agar berlanjut di dalam konteks yang sama
  • Invoice yang belum dikirim memiliki tombol Send di daftar
  • Saat email sedang dikirim, modal tetap terbuka dan tombol kirim menampilkan status sedang mengirim
  • Jika pengiriman berhasil, email dianimasikan keluar dari layar untuk menunjukkan bahwa pengiriman selesai
  • Tombol Send di daftar berubah menjadi checkbox Paid, sehingga pengguna dapat memastikan email sudah terkirim dan lanjut ke tindakan berguna berikutnya
• Pengguna juga dapat menekan tombol konteks untuk memeriksa apakah email sudah terkirim

[wkang586]

Jadi maksudnya toast yang buruk itu memang buruk, ya??

[GN⁺]

Komentar Hacker News

• https://en.wikipedia.org/w/index.php?title=Toast_(computing)

• Saya tidak yakin. Sebagian besar argumennya tampak seperti mengatakan bahwa UX yang redundan adalah UX yang buruk
  Sulit bagi saya untuk sangat setuju dengan contoh seperti: saat email diarsipkan, email itu hilang dari daftar sehingga sudah mengisyaratkan keberhasilan, atau karena ada tanda centang pada tombol maka toast tidak diperlukan. Menyampaikan hal yang sama secara bersamaan dengan cara berbeda bukanlah bug, melainkan fitur, dan hal itu ada di seluruh bahasa manusia. Karena ini membantu pesan tetap tersampaikan bahkan dalam kondisi yang tidak ideal
  Toast memberi tahu status semua tindakan dengan satu cara standar dan, bila memungkinkan, juga menyediakan undo, sehingga pengguna bisa cepat mempelajari polanya. Indikator tambahan di dekat tindakan juga bernilai, tetapi dalam banyak kasus maknanya menjadi jelas ketika ada bersama toast. Jika toast dihapus dan diganti dengan berbagai indikator spesifik, pengguna harus belajar berbagai ungkapan yang berarti “sekarang sudah selesai” hanya dari konteks. Ini bisa sangat tidak baik terutama bagi lansia, penyandang gangguan penglihatan, dan anak-anak
  Selama tidak benar-benar mengganggu, toast bukan UX yang buruk melainkan UX redundan, dan desainer UX tidak boleh terobsesi menghilangkan redundansi

  • Sayangnya, keduanya tidak menyampaikan hal yang sama
    Dalam contoh YouTube, checkbox adalah 100% optimistic update, sedangkan notifikasi toast berarti permintaan yang dikirim secara asinkron ke backend berhasil. Pengarsipan email juga sama: pesan dihapus dari daftar secara optimistis, dan toast menunjukkan bahwa pesan itu benar-benar telah diarsipkan
    Saya justru ingin menerima toast hanya ketika commit perubahan gagal. Biasanya toast yang tiba-tiba muncul mencuri perhatian dari hal yang sedang saya lakukan, dan jika posisinya jauh di layar dari tempat tindakan dilakukan, itu makin mengganggu
  • Tidak, toast itu buruk. Pesan yang berada di pinggiran bidang pandang atau perhatian saya, misalnya pesan yang muncul di satu sisi monitor lebar, secara aktif membingungkan. Saya sedang menangani masalah ini di sini, tetapi ada sesuatu yang berkedip di sana. Saat saya mengalihkan fokus untuk membacanya, separuhnya sudah hilang
    Pesan harus ditempatkan di tempat perhatian pengguna sudah tertuju. UI sudah mengarahkan pandangan saya ke sana, jadi tampilkan di sana
  • Saya terutama menggunakan komputer dengan alat pembesar, memperbesar teks dan area sekitar kursor mouse/jari. Toast dan sebagian besar notifikasi tidak berada di tempat saya bekerja, jadi hampir selalu terlewat. Dalam cara saya menggunakan komputer, hanya umpan balik di dekat item yang sedang saya interaksikan yang bernilai
  • Dikatakan bahwa “redundansi dalam komunikasi adalah fitur, bukan bug”, tetapi jika ada terlalu banyak informasi bising, pengguna akan terlatih untuk mengabaikannya, dan masalah muncul ketika sesekali ada informasi yang benar-benar penting tercampur di dalamnya
    Pelajarannya adalah jangan mengirim informasi kepada pengguna jika tidak benar-benar diperlukan
    Bacaan lebih lanjut:
    https://en.wikipedia.org/wiki/Banner_blindness
    https://en.wikipedia.org/wiki/Alarm_fatigue
    https://en.wikipedia.org/wiki/Inattentional_blindness
    https://en.wikipedia.org/wiki/Habituation
  • Menurut saya, maksud dari perbaikan yang diusulkan adalah seperti ini. Jika Anda khawatir elemen UI yang sedang diinteraksikan pengguna tidak cukup menyampaikan situasi saat ini, jangan menambahkan elemen kedua yang memecah perhatian pengguna dan menuntut mereka cepat membacanya lalu menghubungkannya sendiri; sebaiknya perbaiki elemen itu sendiri. Kegagalan harus disampaikan dalam konteks elemen yang diinteraksikan pengguna agar keterkaitannya jelas
    Dalam skenario terburuk, toast masuk akal sebagai upaya terakhir untuk menyampaikan sesuatu kepada pengguna tanpa konteks. Misalnya, jika pengguna menghapus centang playlist lalu menutup daftar playlist saat penyimpanan sedang berlangsung dan penyimpanan gagal, konteks tindakannya sudah hilang, jadi toast yang menampilkan informasi di lokasi sembarang di layar masih bisa dimengerti
    Meski begitu, jika Anda ingin pengguna benar-benar memahami error, kemungkinan besar toast bukan pilihan terbaik. Dalam aplikasi berbasis iklan seperti YouTube, di mana pengguna adalah produknya, mungkin mereka tidak terlalu peduli jika pengguna melewatkan error semacam ini, atau bahkan mungkin menginginkannya. Namun untuk aplikasi kerja, Anda tidak ingin bertaruh bahwa pengguna akan melewatkan toast atau mencampuradukkannya dengan error lain. Biasanya lebih membantu bagi pengguna jika elemen terkait dibuka kembali dan error ditampilkan dalam konteksnya. Daftar playlist bisa dibuka dan diberi animasi yang menarik perhatian pada fakta bahwa perubahan belum tersimpan. Ini mungkin idealisme yang sulit diterapkan secara sistematis, tetapi idealnya pengguna harus selalu melihat error dalam konteks

• Hal terburuknya adalah toast menghilang terlalu cepat, dan secara tidak perlu menarik perhatian bahkan untuk tugas yang keberhasilannya sudah sewajarnya. Kalau keduanya digabung, hasilnya sangat menjengkelkan. Perhatian dirampas tanpa perlu, tetapi toast hilang terlalu cepat sehingga kita tidak tahu apakah isinya sebenarnya penting atau tidak. Sebaliknya, ada juga variasi yang bertahan terlalu lama dan menutupi bagian UI yang hendak segera dilihat atau digunakan.
  Cara desktop tradisional lebih baik. Pesan kesalahan ditampilkan sebagai modal agar tidak terlewat, sementara pesan sukses ditampilkan sebagai teks biasa yang tidak mengganggu di bilah status yang selalu terlihat tanpa batas waktu. Jika tidak ada modal kesalahan, pengguna bisa menganggap tugas berhasil; jika perlu memastikan, mereka bisa memeriksanya di bilah status tanpa tekanan waktu. Informasi tambahan juga bisa dimuat di sana.
  Beberapa aplikasi juga menampilkan riwayat pesan bilah status sebagai popup. Dalam pendekatan ini, bilah status seperti baris output terakhir di terminal command-line, dan output sebelumnya juga bisa dipanggil kembali.

  • Selain itu, sebagian toast menampilkan informasi penting yang dibutuhkan pengguna, tetapi menghilang terlalu cepat, dan isinya juga tidak lengkap karena batas ukuran toast.
    Saya sering harus masuk ke notifikasi untuk melihat isi yang terlewat. Karena tampaknya penting, tetapi waktu untuk membacanya tidak cukup. Saat menekan item yang terlihat seperti pesan terpotong di sana, saya berharap akan dibawa ke konteks lengkapnya, tetapi kenyataannya notifikasi menghilang dan hanya aplikasinya yang terbuka, tanpa deep link ke masalah tersebut. Lalu saya harus mencari-cari masalah yang mungkin terlihat atau mungkin tidak terlihat di dalam UI standar aplikasi.
    Saya sudah mengalami hal seperti ini tak terhitung banyaknya, dan setiap kali itu terjadi saya marah kepada orang yang merancang sistem seperti ini.
  • Toast membuat seolah-olah ada event log di suatu tempat untuk meninjau kembali apa yang terjadi nanti. Kenyataannya tidak ada event log yang bisa diakses, dan begitu pesan toast hilang karena timeout, pesan itu hilang selamanya.
  • Sebagai eksperimen pikiran, berapa lama toast seharusnya tetap berada di layar? Pengguna memang harus diberi waktu untuk membaca, tetapi karena kita tidak tahu kapan pengguna akan mengalihkan pandangan ke layar dan tidak tahu kecepatan membacanya, tidak ada batas atas yang aman.
    Hari ini saya mengalami masalah ini dengan anak saya. Ia sedang berlatih kecepatan membaca dan kami menggunakan aplikasi baru bersama, tetapi toast terus bermunculan sehingga ia sulit mengikuti dan terdistraksi. Akhirnya saya harus membacakannya dengan suara keras. Jika pesannya bertahan lebih lama, ia mungkin bisa berhasil tanpa bantuan tambahan.
  • Solusi yang lebih baik adalah mengasumsikan keberhasilan, dan menampilkan pesan semacam ini hanya ketika terjadi kesalahan.
  • Implementasi toast terburuk adalah yang benar-benar menutupi elemen UI, sehingga elemen itu tidak terlihat dan tidak bisa diklik sampai toast menghilang.

• YouTube punya contoh yang lebih baik.
  Buka https://www.youtube.com/feed/history, klik “Comments” di sebelah kanan, lalu hapus salah satu komentar; akan muncul satu toast bahwa komentar dijadwalkan untuk dihapus, lalu 1–2 detik kemudian muncul toast lain bahwa komentar sudah dihapus.
  Jika Anda menghapus beberapa komentar dengan cepat secara berurutan, beberapa toast “akan dihapus” muncul lebih dulu, lalu setelah jeda 1–2 detik masing-masing toast konfirmasi muncul berurutan. Penghapusan sebenarnya juga diproses secara berurutan, jadi Anda harus menunggu semua toast konfirmasi. Meski Anda mengklik 10 komentar dalam 2–3 detik, konfirmasinya memakan waktu lebih dari 10 detik.
  Komentar live juga sama:
  https://myactivity.google.com/page?page=youtube_live_chat&co...

• Saya umumnya tidak setuju dengan bagian bahwa “tombol Undo pada toast tidak diperlukan karena pengguna cukup mengeklik ulang checkbox”. Ketika seseorang tidak sengaja mengeklik sesuatu tetapi tidak tahu persis di mana, dan tidak cukup mengenal aplikasinya untuk membatalkan dengan mudah hanya dari pesan, undo sangat berguna.

  • Dalam contoh spesifik ini, tombol undo sebenarnya sudah ada: checkbox itu sendiri. Masalahnya adalah statusnya tidak sesuai dengan keadaan persis yang seharusnya ditunjukkan checkbox. Saat dicentang, selama beberapa detik checkbox memang tercentang tetapi videonya belum tersimpan; saat dihapus centangnya, sampai toast muncul, penyimpanannya belum dibatalkan. Jika dicentang/dihapus centangnya berulang kali, kita tidak bisa tahu status akhirnya apa.
  • Saya pernah mengalami hal seperti itu di beberapa sistem. Saya tahu baru saja mengubah item yang salah, tetapi tidak tahu item yang mana dan tidak ada petunjuk. Ini terutama bermasalah ketika mungkin saja tidak ada yang berubah, tetapi kita tidak bisa yakin.
    Sebagai contoh ekstrem, bayangkan sebuah bola menggelinding jatuh dari rak dan mengenai keyboard saat Anda membelakangi layar. Apakah ada yang berubah? Apa yang berubah? Bagaimana memperbaikinya?

• Satu-satunya kasus ketika toast masuk akal adalah saat notifikasinya tidak terkait dengan tindakan pengguna saat ini. Mirip dengan notifikasi tipe OS yang dibuat oleh Growl yang kini sudah menghilang
  Umpan balik atas tindakan pengguna harus diberikan dalam konteks tindakan itu. Jika tindakannya asinkron, hal itu harus jelas, dan umpan balik harus segera menunjukkan bahwa tugas tersebut sudah masuk ke antrean pemrosesan. Dalam kasus ini, umpan balik harus menyediakan opsi untuk membatalkan, mengakses antrean, dan lebih baik lagi, melihat progresnya

  • Saya ingin menambahkan satu skenario lagi. Biasanya ini terjadi ketika elemen UI untuk memberikan umpan balik sudah dihapus, tetapi Anda tetap ingin menampilkan umpan balik
    Jika Anda menghapus tugas dari papan, Anda tidak bisa menampilkan cara untuk mengurungkannya di atas tugas tersebut. Memang bisa di-undo dengan pintasan keyboard, tetapi bagaimana pengguna mengetahuinya secara visual?
    Daftar tugas seharusnya hanya berisi tugas, jadi Anda tidak akan memasukkan catatan sebagai pengganti tugas. Anda juga tidak akan membuat semacam tugas turunan yang hanya menampilkan pesan. Itu sama saja menyuntikkan maksud tanpa fungsi ke dalam komponen tugas. Saya juga tidak suka jika pengguna sama sekali tidak diberi tahu. Bahwa tugas telah dihapus memang jelas, tetapi bagaimana cara membatalkan tindakan yang meresahkan dan terjadi hanya dengan satu klik itu tidak jelas. Namun saya juga tidak akan meminta konfirmasi yang merepotkan setiap kali sebelum menghapus tugas. Itu fungsi inti daftar tugas, jadi harus bisa dilakukan seketika dan dibatalkan seketika
    Akan ada banyak kasus khusus kecil seperti ini. Toast diciptakan karena ada alasannya. Fakta bahwa orang-orang menyalahgunakannya secara lucu bukan berarti ia tidak berguna secara spesifik dalam skenario tertentu
  • Dalam pekerjaan modal di mana setelah pengguna memulai suatu tugas, dalam 99% kasus mereka ingin mengirim tugas itu ke background dan mengerjakan hal lain, di mana umpan balik seperti itu harus diberikan?
  • Ada juga contoh yang terkait dengan tindakan pengguna saat ini, tetapi berada di luar area layar yang sedang terlihat. Misalnya ketika mencolokkan USB flash drive atau menjalankan fungsi lain yang terkait hardware
    Tindakan semacam ini tidak punya konteks di layar, dan sering kali memerlukan tindakan tambahan. Bahkan jika tidak ada tindakan tambahan, memastikan bahwa tindakan pengguna telah terdeteksi jelas berguna
  • Ini bukan berarti Growl yang menciptakan notifikasi tipe OS. Growl muncul pada 2004, sedangkan Windows XP sudah punya notifikasi pada 2001. Jika pesan Clippy dianggap sebagai notifikasi, jejaknya setidaknya bisa ditarik mundur sampai Microsoft Bob (1995)

• Untuk yang sempat bingung, tulisan ini membahas salah satu jenis widget UI [2], bukan roti panggang [1]
  [1] https://en.wikipedia.org/wiki/Toast_(food)
  [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

  • Ironis bahwa sebuah tulisan tentang paradigma komunikasi yang buruk justru tidak menjelaskan apa arti toast di sini
    Itu kata terpenting di halaman tersebut, tetapi jelas ada pembaca teknis sekalipun yang tidak memahami istilah khusus ini
    Meski begitu, mungkin keterlibatannya justru meningkat berkat pembaca yang tertarik pada baking dan resep sarapan

• Soal “tombol Undo pada toast tidak perlu karena pengguna tinggal mengeklik checkbox lagi”, saya sangat menghargai fitur ini. Sudah berkali-kali saya mengira telah mengarsipkan email, tetapi toast memberi tahu bahwa saya menekan tombol laporkan spam. Kalau tidak ada itu, saya sama sekali tidak akan tahu
  Masalah mendasar lain tentang toast yang terlewat oleh tulisan aslinya adalah bahwa operasi web bersifat asinkron. Kita tidak tahu apakah suatu tindakan berhasil, gagal, atau bahkan tercatat di server. Toast memberikan pembaruan asinkron tentang status server
  Tentu saja saya setuju bahwa sebagian toast menyebalkan, dan kadang menutupi konten UI penting tanpa bisa ditutup

  • Tulisan aslinya benar-benar melewatkan inti dari toast. Sebagian tindakan pengguna 1) bisa dilakukan secara tidak sengaja dan 2) sering dilakukan berulang kali, sehingga tidak cocok dengan kotak konfirmasi
    Jadi jika Anda tidak sengaja menekan sesuatu lalu email tiba-tiba menghilang dari kotak masuk, Anda membutuhkan toast dengan tombol undo. Jika Anda sedang diam saja lalu tubuh bersandar ke tombol dan toast tiba-tiba muncul, Anda akan merasa beruntung toast itu ada. Jika memungkinkan, harus ada penjelasan tentang tindakan yang dilakukan dan tombol undo
    Di Gimp, menekan Tab akan menyembunyikan seluruh UI, dan jika Anda tidak tahu pintasannya, tidak ada cara untuk mengembalikannya. Itu fitur yang bagus bagi seniman yang ingin fokus melihat gambar. Namun ketika saya tidak sengaja menekannya dan harus mencari “gimp how to fix interface disappeared”, saya tidak bisa mengungkapkan betapa saya sangat menginginkan toast dengan tombol undo. Saya bahkan tidak bisa membayangkan bagaimana reaksi orang yang tidak terbiasa dengan komputer

• Toast bisa menjadi UX yang buruk. Biasanya itu terjadi ketika toast menjadi satu-satunya umpan balik, tetapi jika digunakan bersama elemen lain, hasilnya sangat baik
  Toast konfirmasi yang muncul bersama redirect halaman bagus sebagai tanda tambahan bahwa pengiriman berhasil
  Toast peringatan atau error yang muncul bersama indikator validasi form standar menjadi indikator sekunder yang sangat baik bahwa pengguna perlu mengubah sesuatu
  Jika diimplementasikan sebagai penangan menyeluruh untuk error yang tidak ditentukan, status halaman pengguna bisa dipertahankan tanpa mengirim mereka ke halaman error
  Jika digunakan sebagai salah satu alat dalam kotak perkakas, bukan satu-satunya alat, toast adalah pilihan yang baik

• Ada hal yang lebih buruk daripada toast. Panel slide tersembunyi. Pada dasarnya ini toast yang disembunyikan, tetapi meski diperlukan untuk tindakan tertentu, sama sekali tidak intuitif dan tidak bisa dicari atau ditemukan. Pengalaman terburuk saya adalah saat memakai Waze di ponsel orang lain. Saya harus melakukan sesuatu, tetapi tidak ingat apa, dan hanya menatap layar sambil menebak-nebak apa yang harus dilakukan. Akhirnya orang itu mengambil ponselnya dan menunjukkan panel tersembunyi dengan menggesernya dari kanan
  Saya paham tujuannya menghemat ruang, tetapi ini benar-benar tidak masuk akal. Bagaimana seorang pakar UX bisa berharap pengguna menebaknya? Apakah UI zaman sekarang dibuat dengan asumsi orang akan menemukannya dengan menyentuh sana-sini seperti anak kecil?

  • Menurut saya UX membuka sidebar dengan slide kiri-kanan masih oke jika pengguna sudah tahu, dan jumlahnya tidak lebih dari 1 sidebar utama dan 2 sidebar samping
    Aplikasi mobile Discord dulu memakai cara ini untuk sidebar kiri dan kanan, tetapi pada suatu titik seseorang punya ide brilian bahwa gestur “geser untuk membalas” lebih penting daripada navigasi aplikasi, dan sekarang untuk melihat sidebar kanan harus menekan tombol kecil yang ambigu
  • Saya ingat begitu memasang Snapchat, saya langsung tahu betapa buruknya itu. Ada fungsi berbeda di sudut-sudut yang berbeda. Hal seperti ini seharusnya ilegal
  • Sepenuhnya setuju. iOS jelas penuh dengan hal seperti ini, bahkan di tablet yang ruang layarnya lapang
  • Sebagian besar “toast”—sekarang saya tahu istilahnya—menurut saya redundan dan tidak berguna. Biasanya saya melewatkannya sepenuhnya. Secara umum saya menganggapnya tidak berbahaya, tetapi jangan dipakai untuk menyampaikan informasi penting
    Untuk “panel tersembunyi”, saya selalu mengira itu bug, tetapi mungkin ada orang yang menganggapnya ide bagus
    Saya sering memakai aplikasi Apple Connect untuk mengelola aplikasi di App Store. Saat memakai iPad Mini dalam mode potret lalu memilih salah satu aplikasi saya, tombol kembali sering hilang. Akibatnya saya tidak bisa memilih akun lain atau memilih aplikasi lain di akun saat ini
    Begitu terus sampai saya memutar iPad secara fisik ke orientasi lanskap. Setelah itu navigator muncul di sebelah kiri, dan saya bisa memilih aplikasi lain atau berganti akun
    Sejujurnya saya cukup kecewa dengan keseluruhan UX backend Apple App Store. Frontend-nya juga tidak terlalu saya sukai, tetapi backend itulah yang selalu saya pakai. Mengingat mereka begitu banyak memperhatikan pengalaman pengguna di bagian lain platform, ini cukup mengejutkan