Mengampelas UI

 (blog.jim-nielsen.com)
2 poin oleh GN⁺ 2024-09-22 | 1 komentar | Bagikan ke WhatsApp
  • Tingkat penyelesaian UI tidak meningkat tepat setelah implementasi, melainkan lewat proses berulang untuk terus mengkliknya secara nyata; tulisan ini mengibaratkannya dengan pengampelasan dalam pekerjaan kayu
  • Transisi halaman dan navigasi harus diperiksa lewat berbagai jalur masuk, seperti klik, tombol kembali browser, “Back” lewat klik kanan, tombol kembali di dalam aplikasi, dan pintasan keyboard
  • Saat label dan input type="radio" disejajarkan dengan flexbox lalu diberi gap, area di antara tombol radio dan label ternyata menjadi dead zone yang tidak bisa diklik
  • Solusinya adalah menghapus gap dan memberi padding pada label; jarak visual tetap terjaga sambil memperluas area yang bisa diklik
  • Jika cacat interaksi kecil menumpuk, pengalaman pengguna akan terganggu; karena itu UI perlu digunakan berulang-ulang dan dipoles sampai tidak ada lagi “serpihan” yang terasa

Menemukan bagian kasar UI lewat klik berulang

  • Pekerjaan UI lebih mirip proses berulang: setelah membuat sesuatu, banyak mengkliknya, memperbaikinya, lalu mengklik lagi
  • Untuk transisi halaman, memeriksa satu alur saja tidak cukup; perlu kembali dengan berbagai cara dan meninjaunya
    • Setelah klik, gunakan tombol kembali browser
    • Setelah klik, gunakan “Back” dari menu konteks klik kanan
    • Gunakan navigasi kembali di dalam aplikasi
    • Gunakan pintasan keyboard untuk kembali
  • Proses ini mirip QA yang “mengklik untuk mencoba merusaknya”, tetapi lebih dekat dengan sensasi dalam pekerjaan kayu saat mengampelas sambil mencari bagian kasar dan serpihan
  • UI perangkat lunak bisa memiliki terlalu banyak state dan variabel, sehingga kita memolesnya lewat penggunaan berulang sampai tidak ada lagi “serpihan” yang terasa

Dead zone klik yang dibuat oleh gap flexbox

  • Dalam daftar opsi radio, <label> dan <input type="radio"> yang terhubung ditempatkan pada baris yang sama
  • CSS-nya berupa struktur sederhana yang menerapkan display: flex, flex-direction: row, align-items: center, dan gap: .5rem pada container
  • Saat mengklik berulang-ulang, ditemukan dead spot: jika ruang di antara tombol radio dan label ditekan, kontrol tidak ikut berubah
  • Penyebabnya adalah gap pada flexbox
    • gap memang memudahkan pembuatan jarak visual
    • tetapi tidak termasuk dalam area klik label atau elemen input, sehingga menjadi ruang kosong dalam interaksi
  • Solusinya adalah menghapus gap dan memberi padding pada label
    • Jarak tetap terjaga
    • Area label yang bisa diklik menjadi lebih luas, sehingga dead zone menghilang
  • Satu cacat kecil mungkin terlihat sepele, tetapi jika “serpihan kecil” seperti ini bertambah banyak, pengalaman UI bisa menjadi menyakitkan

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-22
Pendapat Hacker News

  • Jika pengembang juga merupakan pengguna yang sering memakai langsung produk yang sedang dibuat, mereka punya keunggulan besar dalam menemukan masalah-masalah kecil seperti ini
    Karena sebelum pengguna tersandung, pengembang bisa menemukan sendiri gangguan kecil itu, dan juga berada tepat di posisi untuk segera memperbaikinya
    Jadi tampaknya tim kecil dengan rasa kepemilikan yang kuat memang efektif. Jika ada rasa memiliki terhadap produk, ketidaknyamanan kecil yang dialami pengguna pun terasa seperti urusan sendiri, dan membuat UX sehalus mungkin menjadi soal harga diri

    • Itu juga alasan perusahaan melakukan dogfooding produk dan menjalankan beta internal jika memungkinkan
      Kecuali untuk kasus yang sulit dipakai secara internal seperti produk enterprise, meski rasa kepemilikan langsungnya lebih lemah, tetap muncul kepentingan terhadap keberhasilan produk

  • Saya penasaran UI mana yang paling dipoles
    Kalau sekelas FAANG, uangnya banyak, jadi UI/UX-nya mungkin cukup bagus, tetapi orang yang pernah memakai Amazon.com atau AWS, GCP, Azure akan merasa berbeda
    Secara pribadi, saya menganggap mcmaster.com sebagai UI/UX yang paling dipoles. Hal yang dibutuhkan bisa ditemukan dalam hitungan menit
    Sebaliknya, di situs toko besar seperti Home Depot atau Lowe’s, mencari sekrup atau kayu dengan ukuran yang tepat bisa memakan 10–15 menit, dan di mobile lebih parah lagi

    • RockAuto adalah situs web favorit saya
      Sangat sederhana dan praktis sampai sulit dipercaya, tetapi tetap cukup powerful. Komponen bisa dipersempit bertahap atau dicari, perbandingan harga dilakukan otomatis, dan kategori harga/kualitas juga dikelompokkan dengan berguna
      Setelah menemukan nomor komponen, kita bisa melihat kompatibilitas tahun/model pabrikan, deskripsi singkat, foto, dan apakah dikirim dari gudang yang sama dengan komponen lain di keranjang. Semua ini berjalan tanpa friksi di satu halaman, sangat cepat di platform apa pun
    • FastMail termasuk web app dengan feel terbaik yang pernah saya pakai
      Responsnya sangat cepat dan selama menggunakannya saya tidak pernah melihat bug. Itu menaikkan standar saya tentang sejauh mana web app bisa dibuat
    • Linear punya UI yang sangat dipoles
      Mereka bahkan pernah punya periode khusus untuk hanya memperbaiki masalah usability
      https://linear.app/changelog/2022-12-01-polishing-season-202...
      https://web.archive.org/web/20231003205004/https://linear.ap...
    • Di Facebook, saya bisa menyebutkan beberapa fitur yang sudah rusak berbulan-bulan
      Terutama foto profil sementara yang paling menyebalkan. Sejak hampir setahun lalu tidak berfungsi dengan benar, dan tidak kembali ke foto semula
      Sepertinya tidak ada siapa pun di sana yang memolesnya
    • Ini masa ketika semua orang bisa melihat bahwa craftsmanship tampak pada detail-detail kecil
      https://littlebigdetails.com persis tempat seperti itu

  • Solusi dasar untuk masalah spesifik ini adalah menaruh elemen input di dalam label

    • Bootstrap mengubah struktur radio/checkbox dari struktur 4.0 menjadi struktur lain di 5.0 [1]
      Saya sempat penasaran alasannya, dan mungkin karena penerapan tema menjadi lebih sederhana saat menyesuaikan posisi/padding label atau elemen input
      [1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
    • Meski dibuat bersarang, untuk aksesibilitas perangkat lunak perintah suara yang umum, atribut for/id tetap diperlukan: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
    • Itu juga yang pertama terlintas di pikiran saya
      Radio atau checkbox seharusnya tidak hanya bisa ditoggle dengan menekan kotak dan padding, tetapi juga dengan menekan seluruh label teks
    • Dulu entah kenapa saya mengira cara ini tabu, mungkin karena di XHTML label dan input dipaksa punya koneksi satu-ke-satu
      Flexbox terasa agak berlebihan. Meski memakai sintaks yang tidak bersarang, elemen-elemen itu akan tersusun inline, dan menurut saya cukup tambahkan padding dengan cara yang sama
    • Di framework seperti React, cara ini bisa menimbulkan error yang merambat saat memakai sesuatu seperti Google Translate di situs
      Untuk memitigasinya, Foo perlu dibungkus dengan elemen terpisah

  • Hal seperti ini sudah terlalu menghilang dari Agile
    Engineer seharusnya punya waktu untuk memoles produk, tetapi kenyataannya tidak ada. Kalau QA tidak membuat tiket untuk masalah jarak/spasi, itu tidak akan pernah diperbaiki
    Pelanggan mungkin menyadari hal-hal seperti ini, tetapi mereka mau melaporkannya saja sudah keajaiban, laporan itu akhirnya menjadi tiket juga keajaiban, dan ada orang yang memberi prioritas lalu memperbaikinya juga keajaiban lagi
    Pada praktiknya, kebanyakan issue board perusahaan terlalu tidak transparan dari sudut pandang pelanggan, jadi kalau menemukan masalah kecil atau bug, menyebalkan karena harus bolak-balik 50 jam untuk membuktikan bahwa itu bug dan memasukkan tiket ke pelacak

    • Saya tidak tahu apa hubungannya dengan Agile
      Apakah maksudnya model waterfall secara eksplisit memberi waktu untuk menguji dan memoles UI?
      Ini biasanya proses yang harus diprioritaskan oleh product manager dan ditangani bersama engineer atau desainer UX yang kompeten. Kalau mau, prioritas itu bisa dimasukkan ke metodologi pengembangan apa pun, jadi Agile tidak relevan di sini
    • Di Discord ada fitur posting yang bekerja seperti forum, dan saat menulis di sana tombol HOME/END berantakan, pemilihan teks dengan Shift juga tidak bisa, begitu pula navigasi per kata dengan Ctrl
      Saya sudah melaporkannya beberapa kali selama 3 tahun terakhir, karena mengedit teks saat menulis menjadi sangat sulit dan menyebalkan
      Sebagai web developer, saya penasaran bagaimana hal seperti ini bisa rusak sejak awal. Entah tingkat ketidakmampuan seperti apa yang dibutuhkan untuk merusak sesuatu yang secara default sudah bekerja. Perbaikannya seharusnya tidak mungkin memakan waktu lebih dari 30 menit dan akan membuat pengalaman pengguna semua orang 1000 kali lebih baik, tetapi 3 tahun setelah dilaporkan masih tetap sama
      Di Teams juga saya melaporkan bug bahwa tombol HOME/END tidak bisa dipakai di kolom input nomor telepon melalui Microsoft Premiere Support, dan jawabannya adalah “bekerja sesuai desain”
      Tidak heran pelanggan tidak lagi melaporkan bug seperti ini. Karena karyawan/developer maupun perusahaannya toh tidak peduli
    • Ini benar sekali
      Saya lead developer sebuah produk, dan ada banyak masalah kecil di sana-sini. Punya tanggung jawab atas sesuatu tetapi tidak punya wewenang untuk memperbaikinya jelas tidak terasa menyenangkan
      Dari sudut pandang bisnis, logikanya adalah kalau tidak berdampak pada pendapatan atau brand, kenapa harus menghabiskan waktu dan uang untuk memperbaikinya. Dalam jangka panjang memang akan memengaruhi brand, tetapi kebanyakan orang akan pindah peran atau perusahaan dalam 5 tahun, jadi mereka tidak peduli
    • Saya cukup sering melaporkan bug, tetapi banyak staf dukungan pelanggan tampaknya melihat pekerjaan mereka sebagai melindungi engineer dari laporan bug dan melempar tanggung jawab
      Kalau sampai mendapat balasan saja itu sudah termasuk kasus yang lumayan
    • Ide dari “Agile” adalah menyadari apa yang tidak berjalan dan memperbaikinya
      Jelas ada proses yang tidak memenuhi kebutuhan pelanggan, jadi perbaiki saja bersama tim
      Kalau ada ritual Scrum, hal itu bisa diangkat saat retrospektif, tetapi sebenarnya bisa kapan saja. Retrospektif hanyalah forum untuk secara sengaja meninjau beberapa minggu terakhir, dan hal yang disadari di tengah jalan seharusnya dicoba diselesaikan di tengah jalan juga

  • Orang yang punya kepekaan untuk melihat dan memperbaiki masalah UX kecil benar-benar penting
    Dalam desain UX, hal seperti ini sering dianalogikan sebagai luka sayatan kertas pada pengguna. Tidak fatal, tetapi mengikis kepuasan pengguna
    Menambahkan untuk penulis, radio button itu tidak mengikuti konvensi bahwa status terpilih memakai titik, bukan tanda centang. Pengguna bisa salah paham pada pandangan pertama bahwa beberapa opsi bisa dipilih sekaligus, atau tidak perlu memilih apa pun

    • Yang saya alami di GitHub dan Jira adalah masalah ketika memilih teks dengan menyeretnya di dialog, lalu melepas mouse di luar, popup-nya tertutup
      Kemungkinan besar itu efek samping dari fitur yang menutup dialog saat area luar diklik
    • Setuju
      Kalau ada “Papercuts” di sisi negatif, di sisi positif ada Juice, yang juga baru-baru ini dibahas di HN
      1. https://garden.bradwoods.io/notes/design/juice

  • Tulisan ini menunjukkan dengan baik kenapa saya tidak suka pemrograman UI
    Hal-hal yang tidak bisa diprediksi dan bisa meleset secara sepele melebihi batas kesabaran saya. Saya cukup menikmati memikirkan cara sesuatu bisa gagal dan menulis pengujian untuknya, tetapi mengklik secara asal untuk melihat apakah sesuatu rusak terasa mengalihkan perhatian dan menyebalkan
    Saya penasaran apakah implementasi UI memang secara inheren serumit ini, atau kita belum menemukan model pemrograman yang tepat. Kadang saya bertanya-tanya apakah berharap sesuatu terlihat dan bekerja sesuai niat sejak awal itu unreasonable?

    • Karena itulah ada design system
      Memoles UI hanya perlu dilakukan saat komponen pertama kali dibuat. Sesekali komponen mungkin perlu digabungkan dengan cara lain, atau perlu implementasi sekali pakai
      Jujur saja, kalau tahu apa yang dilakukan, itu tidak memakan waktu selama itu. Design engineer yang baik adalah spesialis untuk peran seperti ini
    • Ini bukan pemrograman UI, melainkan merancang UI di atas HTML dan CSS
      Terlalu banyak kebebasan, dan elemen dasar seperti form seharusnya bekerja dengan baik hanya dengan nilai default
    • Tidak serumit itu
      Cara mengekspresikan UI dengan baik melalui kode sudah ada. Masalahnya adalah permainan zero-sum dari sisi bisnis. UI lintas platform biayanya terlalu mahal kalau tidak dibuat dengan stack UI paling tidak enak dilihat, yaitu HTML/CSS/JS
    • Dulu ada platform-platform yang cukup bagus yang secara default mengurus detail-detail untuk kita
      Tetapi platform web, meski lumayan untuk dokumen, tidak memiliki tingkat abstraksi yang tepat untuk aplikasi. Karena itu UI web ditemukan ulang setiap tahun dengan abstraksi baru yang bocor
    • Untuk web, ini adalah akibat dari granularitas yang terlalu rendah tanpa perangkat yang membantu developer yang peduli pada UI yang benar
      Mengejar ketertinggalan saja sudah terlalu banyak pekerjaan
      Hal serupa juga terjadi di area lain. Kalau tidak ada cara mudah untuk mengirim request atau memasukkan parameter ke query, orang-orang, meski berusaha berhati-hati, akan terdorong secara alami untuk menciptakan berbagai cara setengah matang
      Platform web memang mutakhir di sisi grafis, tetapi benar-benar buruk sebagai UI. Namun tidak ada yang mau mengakui dan mengubahnya. Orang hanya percaya pada bagian depannya, sementara legacy dan kompleksitas browser menghalangi perubahan. Kalau dibuat sebagai library, karena bukan “standar”, tidak ada yang peduli

  • Di sisi lain, ada UI yang memakai kotak persegi untuk radio button
    Ada tombol yang disorot tetapi tidak aktif saat menekan tombol Enter
    Ada juga tiga menu yang tersembunyi di balik simbol yang berbeda-beda (elipsis, hamburger, kebab)
    Variasi kualitasnya besar. Orang-orang yang memoles UI benar-benar patut diapresiasi

    • Tombol untuk menjalankan tombol yang sedang fokus seperti klik biasanya menurut saya bukan Enter, melainkan Space
    • Radio button pun sekarang sepertinya mulai menuju standar berbentuk persegi atau persegi membulat
      Bahkan Apple pun melakukan ini :(

  • Saya tidak paham kenapa cara memasukkan elemen input ke dalam label tidak populer
    Dengan begitu masalahnya hilang sepenuhnya, dan tidak perlu membuat id unik untuk dipakai di for

    • Menurut saya justru kebalikannya, bukan “tidak populer”
      Hanya saja masih diketahui ada beberapa teknologi bantu yang belum bisa menafsirkan pola standar valid yang baru, jadi menjaga standar Zaman Perunggu menjadi praktik terbaik [1]

      Dragon Naturally Speaking untuk Windows dan Voice Control untuk macOS/iOS tidak mengenali asosiasi implisit, jadi [cara menumpuk input di dalam label tanpa referensi for-id eksplisit] tidak berfungsi
      Katanya Naturally Speaking telah diakuisisi oleh perusahaan bernama “Microsoft”, dan Voice Control terkait dengan perusahaan bernama “Apple”
      [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...

    • Kalau membuat checkbox dengan helper Rails, selalu ada hidden field bernilai “off” di sebelahnya supaya nilainya selalu terkirim lewat POST
      Framework lain sepertinya juga mirip. Kalau kedua field input itu dibungkus dengan elemen label, HTML-nya tidak lagi valid
      Untuk radio button ini bukan masalah, tetapi sebagian orang tampaknya pernah mengalaminya lalu melakukan itu “demi memastikan”. Mirip seperti menaruh titik koma di akhir baris JavaScript. Hampir tidak pernah diperlukan, tetapi karena tidak tahu persis kapan diperlukan, akhirnya dipasang di mana-mana
    • Saya sudah melakukan ini setidaknya 15 tahun, mungkin 20 tahun
      Untuk kasus penggunaan umum checkbox/radio button, sintaksnya juga jauh lebih rapi
      Bungkus elemen input dengan label, dan kalau ingin memberi gaya pada teks, masukkan teks ke dalam span. Anda bisa membuat label menjadi display:flex dan mengatur posisi teks dengan cara itu juga
    • Itu karena dogma web semantik

  • Di bug bash kami memakai cara ini, dan hasil tiketnya jauh lebih banyak daripada orang yang membuat kombinasi test case sebagai matriks produk Kartesius multidimensi
    Mengetahui test case seperti itu sebagai titik awal memang bagus, tetapi untuk menemukan masalah kecil, pengujian acak dengan cepat melampaui pengujian yang terencana
    Pengujian terencana biasanya berhenti di happy path atau error yang sudah diperkirakan. Cara memoles seperti ini menemukan bug di sudut-sudut jauh lebih cepat

    • Kadang-kadang, terutama saat terlalu lelah untuk mengerjakan seluruh fitur, saya mengklik secara acak di sana-sini dalam game dan mencoba hal-hal yang biasanya tidak saya lakukan
      Selalu saja menemukan masalah atau perbaikan kecil. Hal-hal yang kemungkinan besar tidak akan banyak muncul dari pengujian terencana

  • Saya sudah hampir 4 tahun memoles situs web pribadi saya (https://dustinbrett.com), dan rasanya ini bisa terus berlanjut tanpa akhir
    Untungnya saya menikmati mengerjakannya

    • Kalau mau jujur, saya penasaran berapa banyak dari waktu yang dihabiskan untuk ini terjadi selama jam kerja 9–5 dan dibayar dengan uang atasan
      Saya harap semuanya :-)
    • Yang seperti ini benar-benar bagus
      Saat melihat “OS desktop di atas halaman web”, kebanyakan terasa setengah jadi dan sejujurnya sudah terlalu umum, tetapi yang ini sebaliknya: sangat solid dan dipoles dengan baik
    • Menjelajahinya sangat menyenangkan
      Benar-benar dibuat dengan baik dan menginspirasi. Memikirkan bagaimana semua itu diimplementasikan juga cukup menyenangkan
    • Sangat mulus, dan menggaruk rasa ingin yang tidak saya sadari saya punya
      Ternyata itu keinginan untuk memakai OS berbasis jendela di ponsel
    • Kelihatannya benar-benar keren
      Kalau harus mencari satu yang kurang, itu adalah tidak bisa memakai mouse4/mouse5 di explorer. “Pemolesan” memang bisa terus berlanjut selamanya