26/2/2021 Tanpa judul

Halaman 1

Halaman 2

“ GUI Bloopers 2.0 adalah buku yang sangat berguna untuk semua pengembang perangkat lunak
atau desainer interaksi. Jika Anda tidak pernah melakukan kesalahan ini, itu
karena Anda belum pernah mendesain UI. Jika ada, blooper ini genap
lebih umum sekarang daripada saat versi 1.0 diterbitkan, jadi kebutuhan akan ekstensi
buku hanya meningkat. ”
—Jakob Nielsen
Kepala Sekolah Nielsen Norman Group
([Link])

“Ini adalah buku desain paling menghibur yang pernah saya baca. Jeff Johnson pernah sekali
sekali lagi melakukan pekerjaan luar biasa untuk mengingatkan kita tentang semua kesalahan desain yang konyol
kita dapat membuat dan memberi kita nasihat bagus tentang bagaimana menghindarinya dengan cara kita sendiri
desain. "
—Jared M. Spool
Prinsipal Pendiri, Rekayasa Antarmuka Pengguna
([Link])

“Edisi kedua GUI Bloopers adalah kelangkaan yang sebenarnya: sekuel dari sesuatu
hebat itu bahkan lebih baik dari aslinya. (Pikirkan Godfather II .) Sedangkan Jeff
bisa diselesaikan hanya dengan memperbarui contoh, sedekat yang saya tahu dia
menulis ulang hampir seluruh buku, dan itu terlihat. Organisasinya hebat, itu
wawasan lebih mudah dipahami, dan yang terpenting, tulisannya lebih ramping. Jika kamu pernah
mengambilnya di masa lalu dan akhirnya tidak menghabiskan uang Anda, defi-
lihat lagi. Itu berubah dari buku bagus menjadi sangat bagus. "
—Steve Krug
Akal Sehat Lanjutan
([Link])

Halaman 3

[Link] 1/315
26/2/2021 Tanpa judul

Halaman ini sengaja dikosongkan

Halaman 4

GUI Bloopers 2.0

Antarmuka Pengguna Umum
Larangan dan Anjuran Desain

[Link] 2/315
26/2/2021 Tanpa judul

Halaman 5

Seri Morgan Kaufmann dalam Teknologi Interaktif

Editor Seri:
■ Stuart Card, PARC
■ Jonathan Grudin, Microsoft
■ Jakob Nielsen, Grup Nielsen Norman

GUI Bloopers 2.0: Larangan dan Tindakan Desain Antarmuka Pengguna Umum
Jeff Johnson
Pemikiran Visual: Desain untuk Otak
Colin Ware
Uji Kegunaan Moderat: Prinsip dan Praktik untuk Berinteraksi
Joseph Dumas dan Beth Loring
Kisah Desain yang Berpusat pada Pengguna: Studi Kasus UCD Dunia Nyata
Carol Righi dan Janice James
Membuat Sketsa Pengalaman Pengguna: Mendapatkan Desain yang Tepat dan Desain yang Tepat
Bill Buxton
Sistem Entri Teks: Mobilitas, Aksesibilitas, Universalitas
Scott MacKenzie dan Kumiko Tanaka-ishi
Melepaskan Kata-Kata: Menulis Konten Web yang Berfungsi
Janice "Ginny" Kemerahan
Persona dan Pola Dasar Pengguna: Panduan Lapangan untuk Desainer Interaksi
Jonathan Pruitt dan Tamara Adlin
Kegunaan Pembenaran Biaya
Diedit oleh Randolph Bias dan Deborah Mayhew
Desain dan Evaluasi Antarmuka Pengguna
Debbie Stone, Caroline Jarrett, Mark Woodroffe, dan Shailey Minocha
Desain Kontekstual Cepat
Karen Holtzblatt, Jessamyn Burns Wendell, dan Shelley Wood
Desain Interaksi Suara: Membuat Sistem Pidato Percakapan Baru
Randy Allen Harris
Memahami Pengguna: Panduan Praktis untuk Persyaratan Pengguna: Metode, Alat, dan Teknik
Catherine Courage dan Kathy Baxter
Buku Pegangan Desain Aplikasi Web: Praktik Terbaik untuk Perangkat Lunak Berbasis Web
Susan Fowler dan Victor Stanwick
Koneksi Seluler: Dampak Ponsel pada Masyarakat
Richard Ling
Visualisasi Informasi: Persepsi untuk Desain, Edisi ke-2
Colin Ware
Desain Interaksi untuk Pemecahan Masalah Kompleks: Mengembangkan Perangkat Lunak yang Berguna dan Dapat Digunakan
Barbara Mirel
Kerajinan Visualisasi Informasi: Bacaan dan Refleksi
Ditulis dan diedit oleh Ben Bederson dan Ben Shneiderman
Model, Teori, dan Kerangka HCI: Menuju Ilmu Multidisiplin
Diedit oleh John M. Carroll
Bloopers Web: 60 Kesalahan Umum Desain Web, dan Cara Menghindarinya
Jeff Johnson
Mengamati Pengalaman Pengguna: Panduan Praktisi untuk Riset Pengguna
Mike Kuniavsky
Pembuatan Prototipe Kertas: Cara Cepat dan Mudah untuk Mendesain dan Memperbaiki Antarmuka Pengguna
Carolyn Snyder

[Link] 3/315
26/2/2021 Tanpa judul

Halaman 6

GUI Bloopers 2.0

Antarmuka Pengguna Umum
Larangan dan Anjuran Desain

Jeff Johnson
UI Wizards, Inc.

AMSTERDAM • BOSTON • HEIDELBERG • LONDON

NEW YORK • OXFORD • PARIS • SAN DIEGO

SAN FRANCISCO • SINGAPURA • SYDNEY • TOKYO

Morgan Kaufmann Publishers adalah jejak Elsevier

Halaman 7

Penerbit Denise EM Penrose

Editor eksekutif Diane Cerra
Manajer Layanan Penerbitan George Morrison
Editor Produksi Senior Dawnmarie Simpson
Asisten Editor Mary E. James
Asisten produksi Lianne Hong
Desain sampul Dennis Schaefer
Ilustrasi Sampul Melissa Walters
Komposisi SPi
Pemeriksa naskah Valerie Koval
Korektor Phyllis Coyne dkk. Layanan Proofreading
Pengindeks Manajemen Informasi Brokoli
Printer interior Buku Sheridan
Cover printer Phoenix Color, Inc.

[Link] 4/315
26/2/2021 Tanpa judul
Morgan Kaufmann Publishers adalah jejak Elsevier.
30 Corporate Drive, Suite 400, Burlington, MA 01803, AS

Buku ini dicetak di atas kertas bebas asam.

© 2008 oleh Elsevier Inc. Semua hak dilindungi undang-undang.

Sebutan yang digunakan oleh perusahaan untuk membedakan produk mereka sering kali diklaim sebagai merek dagang atau
merek dagang terdaftar. Dalam semua kasus di mana Penayang Morgan Kaufmann mengetahui suatu klaim,
nama produk muncul dengan huruf kapital awal atau semua huruf kapital. Pembaca, bagaimanapun, harus menghubungi
perusahaan yang sesuai untuk informasi lebih lengkap mengenai merek dagang dan pendaftaran.

Tidak ada bagian dari publikasi ini yang boleh direproduksi, disimpan dalam sistem pengambilan, atau dikirim dalam bentuk apapun
bentuk atau dengan cara apa pun — elektronik, mekanis, fotokopi, pemindaian, atau lainnya — tanpa
izin tertulis sebelumnya dari penerbit.

Izin dapat diminta langsung dari Departemen Hak Sains & Teknologi Elsevier di
Oxford, Inggris: telepon: (+44) 1865 843830, fax: (+44) 1865 853333, E-mail: permission@[Link].
Anda juga dapat menyelesaikan permintaan Anda secara online melalui beranda Elsevier ([Link]
dengan memilih "Dukungan & Kontak" lalu "Hak Cipta dan Izin" dan kemudian "Mendapatkan
Izin. "

Library of Congress Katalogisasi-dalam-Data Publikasi

Johnson, Jeff, Ph. D.
GUI bloopers 2.0: desain antarmuka pengguna umum yang dilarang dan dilakukan / Jeff Johnson.
p. cm.
Awalnya diterbitkan: San Francisco: Morgan Kaufmann Publishers, dengan judul: GUI bloopers, 2000.
Termasuk referensi bibliografi dan indeks.
ISBN 978-0-12-370643-0 (pbk.: Alk. Paper) 1. Antarmuka pengguna grafis (Sistem komputer)
I. Judul.
QA76.9.U83J63 2007
005.4'37 – dc22
2007012860
ISBN: 978-0-12-370643-0

Untuk informasi tentang semua publikasi Morgan Kaufmann, kunjungi situs Web kami di [Link] atau
[Link]

Dicetak di Amerika Serikat.

07 08 09 10 5 4 3 2 1

Halaman 8

Isi

Ucapan Terima Kasih xiii

pengantar 1

Bab 1 Prinsip Pertama 7

pengantar 8
Prinsip Dasar 1: Fokus pada pengguna dan tugas mereka, bukan
tentang teknologi 8
Prinsip Dasar 2: Pertimbangkan fungsi dulu, presentasi nanti 18
Prinsip Dasar 3: Sesuai dengan pandangan pengguna tentang tugas 26
Prinsip Dasar 4: Desain untuk kasus umum 32
Prinsip Dasar 5: Jangan mengalihkan pengguna dari tujuan mereka 35
Prinsip Dasar 6: Memfasilitasi pembelajaran 37
Prinsip Dasar 7: Menyampaikan informasi, bukan hanya data 41
Prinsip Dasar 8: Desain untuk daya tanggap 45
Prinsip Dasar 9: Cobalah pada pengguna, lalu perbaiki! 48

Bab 2 GUI Control Bloopers 51

pengantar 52
Menggunakan kontrol yang salah 53
Blooper 1: Kotak centang dan tombol radio yang membingungkan 53

[Link] 5/315
26/2/2021 Tanpa judul
Blooper 2: Menggunakan kotak centang untuk pengaturan non-ON / OFF 62
Blooper 3: Menggunakan tombol perintah sebagai matikan 65
Blooper 4: Menggunakan tab sebagai tombol radio 67
Blooper 5: Terlalu banyak tab 70
Blooper 6: Menggunakan kontrol input untuk data hanya-tampilan 77
Blooper 7: Menggunakan bidang teks secara berlebihan untuk input yang dibatasi 84
Menggunakan kontrol secara salah 88
Blooper 8: Menu dinamis 89
Blooper 9: Bidang data tidak toleran 94

vii

Halaman 9

viii Isi

Blooper 10: Input field dan kontrol tanpa default 96

Blooper 11: Default yang buruk 103
Blooper 12: Kotak centang negatif 105

Bab 3 Kesalahan Navigasi 107

pengantar 108
Tidak menunjukkan lokasi mereka kepada pengguna 108
Blooper 13: Jendela atau halaman tidak teridentifikasi 108
Blooper 14: Judul yang sama di jendela berbeda 112
Blooper 15: Judul jendela tidak cocok dengan perintah atau tautan 117
Menyesatkan pengguna dan tidak menunjukkan jalan 122
Blooper 16: Tombol dan tautan off-path yang mengganggu 122
Blooper 17: Tautan mandiri 126
Blooper 18: Terlalu banyak level kotak dialog 131
Navigasi pencarian yang buruk 138
Blooper 19: Kotak pencarian yang bersaing 139
Blooper 20: Penelusuran hasil penelusuran yang buruk 143
Blooper 21: Hasil pencarian yang berisik 145

Bab 4 Kesalahan Tekstual 151

pengantar 152
Teks tidak komunikatif 152
Blooper 22: Terminologi yang tidak konsisten 153
Blooper 23: Terminologi tidak jelas 161
Blooper 24: Tulisan yang buruk 165
Blooper 25: Terlalu banyak teks 169
Teks yang berpusat pada pengembang 173
Blooper 26: Berbicara Geek 173
Blooper 27: Memanggil pengguna ke "pengguna" di depan mereka 181
Blooper 28: Pesan kesalahan yang tidak jelas 184
Teks menyesatkan 189
Blooper 29: Pesan yang salah 189
Blooper 30: Teks masuk akal jika dipisahkan
tetapi menyesatkan di GUI 193
Blooper 31: Penyalahgunaan (atau nonuse) "..." di
label perintah 193

Halaman 10

[Link] 6/315
26/2/2021 Tanpa judul

Isi ix

Bab 5 Desain Grafis dan Tata Letak Bloopers 197

pengantar 198
Tata letak dan penempatan jendela yang buruk 198
Blooper 32: Informasi yang mudah terlewatkan 198
Blooper 33: Mencampur tombol kontrol kotak dialog dengan konten
tombol kontrol 208
Blooper 34: Menyalahgunakan kotak grup 212
Blooper 35: Tombol radio terlalu jauh 217
Blooper 36: Label terlalu jauh dari bidang data 220
Blooper 37: Penjajaran label tidak konsisten 226
Blooper 38: Lokasi jendela awal yang buruk 228
Tipografi yang merepotkan 232
Blooper 39: Font kecil 232

Bab 6 Interaksi Bloopers 239

pengantar 240
Menyimpang dari fokus tugas 241
Blooper 40: Mengekspos implementasi kepada pengguna 241
Blooper 41: Pembatasan yang tidak perlu 242
Blooper 42: Konsep yang membingungkan 246
Membutuhkan langkah-langkah yang tidak perlu 250
Blooper 43: Meminta pengguna untuk data yang tidak dibutuhkan 250
Blooper 44: Meminta pengguna untuk benih acak 256
Blooper 45: Pilihan tak berguna 258
Membebani memori pengguna 264
Blooper 46: Sulit untuk mengingat ID 264
Blooper 47: Instruksi panjang yang pergi terlalu cepat 267
Blooper 48: Mode yang tidak perlu atau ditandai dengan buruk 269
Mengambil kendali dari pengguna 277
Blooper 49: Pengaturan ulang tampilan secara otomatis 277
Blooper 50: Kotak dialog yang menjebak pengguna 281
Blooper 51: "Batal" tidak membatalkan 288

Bab 7 Responsiveness Bloopers 293

pengantar 294
Bloopers responsif umum 294

Halaman 11

x Isi

Blooper 52: Kursor tidak mengikuti 294

Blooper 53: Tombol di layar mengenali klik yang terlambat 294
Blooper 54: Menu, slider, dan scrollbar tertinggal 294
Blooper 55: Operasi pemindahan dan ukuran tidak mengikuti 295
Blooper 56: Aplikasi tidak menunjukkan bahwa sedang sibuk 295
Blooper 57: Aplikasi tidak responsif selama internal
Pembenahan 295
Blooper 58: Operasi lama tidak menampilkan kemajuan 295
Blooper 59: Operasi panjang tidak memberikan cara untuk membatalkan 295
Blooper 60: Aplikasi membuang waktu idle 295
Blooper 61: Aplikasi tidak memberikan umpan balik saat hang 295
Blooper 62: Situs web memiliki gambar dan animasi yang sangat besar 295
Blooper 63: Situs web selalu memuat ulang seluruh halaman
menanggapi pengeditan kecil 295
Alasan respons yang buruk 298
Alasan 1: Fakta tentang daya tanggap tidak banyak diketahui 298

[Link] 7/315
26/2/2021 Tanpa judul
Alasan 2: Desainer UI jarang mempertimbangkan daya tanggap
selama desain 299
Alasan 3: Pemrogram menyamakan daya tanggap dengan kinerja 300
Alasan 4: Pemrogram memperlakukan masukan pengguna seperti masukan mesin 301
Alasan 5: Pengembang menggunakan penerapan sederhana 301
Alasan 6: Alat, komponen, dan platform perangkat lunak GUI
tidak memadai 302
Alasan 7: Manajer mempekerjakan pemrogram GUI yang tidak memiliki ekstensi
keterampilan yang dibutuhkan 303
Menghindari kesalahan besar yang responsif: Prinsip desain 303
Responsiveness Prinsip 1: Responsiveness tidak sama dengan
kinerja 303
Prinsip Responsiveness 2: Memproses sumber daya
selalu terbatas 304
Prinsip Responsif 3: Antarmuka pengguna adalah a
antarmuka waktu nyata 304
Prinsip Responsiveness 4: Semua penundaan tidak sama: perangkat lunak
tidak perlu melakukan semuanya dengan segera 306
Prinsip Responsiveness 5: Software tidak perlu melakukan tugas di
urutan permintaan mereka 307
Prinsip Responsif 6: Perangkat lunak tidak perlu melakukan segalanya
itu diminta untuk dilakukan 307
Prinsip Responsif 7: Pengguna manusia bukanlah komputer
program 309

Halaman 12

Isi xi

Menghindari bloopers responsif: Teknik 309

Umpan balik tepat waktu 310
Solusi masalah paralel 317
Optimasi antrian 319
Manajemen waktu yang dinamis 320
Ringkasan teknik responsivitas 326
Kesimpulan 326

Bab 8 Manajemen Bloopers 329

pengantar 330
Sikap kontraproduktif 331
Blooper 64: Memperlakukan UI sebagai prioritas rendah 331
Blooper 65: Kesalahpahaman tentang apa yang dilakukan oleh para profesional antarmuka pengguna 337
Blooper 66: Mengurangi nilai pengujian dan desain berulang 341
Proses kontraproduktif 348
Blooper 67: Perkembangan anarkis 348
Blooper 68: Tidak ada keahlian tugas dalam tim 357
Blooper 69: Menggunakan alat dan blok bangunan yang buruk 365
Blooper 70: Memberi programmer komputer tercepat 370

Lampiran 373
Lampiran A: Daftar Istilah 373
Lampiran B: Bagaimana buku ini diuji kegunaannya 376
Lampiran C: Analisis tugas membuat presentasi slide — pertanyaan 379
Lampiran D: Mengilustrasikan kesederhanaan — matriks objek / tindakan 381
Lampiran E: Uji kegunaan untuk setiap waktu dan tujuan 383
Bibliografi 389
Indeks 397
tentang Penulis 407

Apendiks Web: Color Bloopers (kunjungi [Link]) 1

Blooper 71: Teks sulit dibaca di latar belakang 1
Blooper 72: Mengandalkan perbedaan warna yang halus 7

[Link] 8/315
26/2/2021 Tanpa judul

Halaman 13

Halaman ini sengaja dikosongkan

Halaman 14

Ucapan Terima Kasih

[Link] 9/315
26/2/2021 Tanpa judul

Saya tidak dapat menulis buku ini tanpa bantuan dan dukungan dari banyak orang lainnya
orang-orang.
Pertama, saya ingin berterima kasih kepada istri dan teman saya Karen Ande atas cinta dan kasihnya
dukungan saat saya mengerjakan buku ini.
Saya juga ingin berterima kasih kepada pengulas draf pertama, yang telah membantu-
komentar dan saran lengkap: Sara Bly, Bob Carpenter, Ed Chi, Susan Fowler,
Jesse Heines, Robin Kinkead, dan Innosanto Nagara. Banyak rekan yang dikirim
saya contoh blooper, terutama Tim Bell, Michael Bell, Cathy de Heer,
Roland Dumas, Simon Edwards, Susanne Jul, Ellen Isaacs, Victor Stanwick,
dan Marcin Wichary. Cathy de Heer juga membantu mengidentifikasi bagian-bagian
yang perlu diperbarui. Komentar tentang edisi pertama diposting oleh pembaca
di situs web penjual buku juga membantu memandu perubahan.
Buku itu juga sangat terbantu oleh perawatan, pengawasan, tata letak dan
nasihat organisasi, dukungan logistik, dan pengasuhan yang diberikan oleh staf di
Penerbit Morgan Kaufmann, terutama Diane Cerra, Dawnmarie Simpson,
Mary James, dan Valerie Koval.
Terakhir, saya ingin berterima kasih kepada klien dan mantan majikan saya. Tanpa
mereka, buku ini tidak akan mungkin… atau perlu.

xiii

Halaman 15

pengantar

Mengapa buku ini diperbarui?

Edisi pertama buku ini ditulis pada tahun 1998 dan 1999. Penggunaan umum
platform kation kemudian adalah MacOS9, Windows98, Windows NT, versi awal
Java Swing, dan Unix atau Linux dengan CDE / Motif. Meskipun banyak bloop-
Buku-buku yang tercakup dalam edisi pertama sama umum sekarang seperti di akhir-akhir ini
1990, buku itu mulai terlihat dari tanggal karena blooper contoh
semuanya dari abad terakhir. Agar terlihat mutakhir, buku tersebut membutuhkan contoh baru.
Alasan kedua untuk edisi baru adalah bahwa beberapa blooper yang
mon pada tahun 1999 telah menjadi kurang umum, dan blooper umum baru telah terjadi
menggantikan mereka. Proporsi aplikasi baru yang lebih tinggi saat ini adalah Web
berdasarkan, jadi membahas blooper yang umum di Web menjadi penting
aplikasi.
Motivasi ketiga untuk pembaruan adalah bahwa saya telah mengembangkan cara yang lebih baik
untuk menjelaskan beberapa kesalahan besar dan cara menghindarinya. Saya juga punya yang lebih jelas
pemahaman tentang prinsip desain UI dasar yang mendasari bloopers.

[Link] 10/315
26/2/2021 Tanpa judul
Alasan terakhir
memberikan banyakuntuk
umpanmerevisi buku ini
balik tentang apaadalah karena pembaca
yang mereka suka dan edisi
tidak pertama memilikinya
suka, dalam ulasan
artikel yang dipublikasikan di majalah, komentar diposting di grup diskusi online
dan di halaman buku di penjual buku online, dan email dikirimkan kepada saya dan ke
penerbit. Saya dan penerbit memutuskan sudah waktunya untuk mengembangkan edisi pertama
kekuatan dan koreksi beberapa kelemahannya (lihat Lampiran B: Bagaimana buku ini
telah diuji kegunaannya).

Mengapa buku ini dibutuhkan?

Di seluruh industri perangkat lunak, insinyur perangkat lunak mengembangkan antarmuka pengguna
dengan sedikit — terkadang tanpa — dukungan atau panduan dari desain UI profesional-
ers. Beberapa perangkat lunak dikembangkan oleh pemrogram lepas individu yang kurang
pelatihan dalam merancang GUI atau akses ke orang-orang yang memiliki pelatihan semacam itu. Bahkan dalam
organisasi pengembangan besar, mungkin tidak ada orang yang memiliki pelatihan desain UI.
Akhirnya, beberapa perusahaan memang memiliki profesional UI, tetapi tidak cukup
mencakup semua proyek pengembangan yang membutuhkan keterampilan mereka.

Halaman 16

2 pengantar

Pasar produk perangkat lunak, peralatan yang dikendalikan perangkat lunak, dan
Oleh karena itu, layanan online penuh dengan perangkat lunak yang dirancang sepenuhnya oleh orang-orang yang
adalah pengembang profesional, tetapi amatir UI. Perangkat lunak semacam itu merupakan hambatan di
kesuksesan seluruh industri.
Saya sering mereview atau menguji software yang dikembangkan oleh orang yang memiliki sedikit
Pengalaman desain UI. Perangkat lunak semacam itu biasanya penuh dengan kesalahan desain. Kebanyakan
kesalahan ini biasa terjadi.
Ini menyarankan agar sebuah buku fokus pada kesalahan desain dan bagaimana menghindarinya
mereka mungkin lebih efektif daripada buku desain UI lainnya, atau setidaknya
pelengkap yang berguna untuk buku-buku semacam itu. Sejalan dengan itu, buku ini menyajikan desain
pedoman secara terbalik: inilah kesalahan umum; berikut cara menghindarinya.
Tidak semua blooper yang mengganggu kegunaan perangkat lunak dibuat oleh pemrogram.
Banyak organisasi pengembangan perangkat lunak melakukan kesalahan dalam manajemen
tingkat yang berdampak negatif pada UI yang mereka kembangkan. Kesalahan manajemen ini adalah
dalam banyak hal lebih serius daripada kesalahan desain GUI konkret karena mereka mempengaruhi
lebih banyak proyek dan lebih sulit untuk diperbaiki. Dalam Bab 8, saya menjelaskan jenis-jenis itu
kesalahan dan jelaskan bagaimana menghindarinya.
Tujuan utama dari buku ini adalah untuk membantu para pengembang dan desainer GUI menjadi
lebih baik dalam menangkap kesalahan desain mereka sendiri dan menghindarinya sama sekali.

[Link] 11/315
26/2/2021 Tanpa judul

Halaman 17

Apa itu GUI blooper? 3

Akan lebih bagus jika dunia nyata memiliki kotak dialog kesalahan. Mereka akan meletus
di depan wajah Anda setiap kali Anda melakukan kesalahan. Mereka
akan menjadi cara yang bagus untuk melatih pengembang perangkat lunak dan manajer mereka untuk
menyamar ketika mereka telah melakukan, atau akan melakukan, blooper. Sejak
tidak ada kotak dialog kesalahan di dunia nyata, kita perlu memprogramnya
ke dalam kepala pengembang. Saya berharap buku ini akan membantu beberapa di antaranya
pemrograman.

Apa itu GUI blooper?

Buku ini menjelaskan "bloopers" (yaitu, kesalahan) yang dikembangkan perangkat lunak-
sering dibuat saat mendesain antarmuka pengguna grafis (juga dikenal
sebagai GUI). Bloopers dalam buku ini tidak mencakup semua kesalahan GUI
desainer bisa membuat, atau bahkan semua kesalahan yang saya lihat. Percayalah, masuk
Selama dua dekade bekerja sebagai profesional antarmuka pengguna, saya telah melihat beberapa
kesalahan desain yang benar-benar menakjubkan — "howler" yang sebenarnya, seperti beberapa kesalahan saya
rekan kerja memanggil mereka.
Untuk masuk ke dalam buku ini, tidak cukup hanya membuat kesalahan desain menjadi melolong.
Itu juga harus umum. Ada sedikit nilai dalam memperingatkan pengembang perangkat lunak
jauh dari kesalahan yang sangat jarang atau spesifik aplikasi, tidak peduli seberapa mengerikannya
kesalahannya mungkin. Di sisi lain, ada nilai besar dalam memperingatkan pengembang
Teks asli
jauh dari kesalahan yang dilakukan banyak pengembang.
software.
Bloopers bukan hanya contoh spesifik dari kesalahan desain yang pernah saya lihat
perangkat lunak. Bloopers adalah kesalahan yang dilakukan developer berulang kali
Sumbangkan terjemahan yang lebih baik
lagi. Contoh-contoh tersebut hanya berfungsi untuk mengilustrasikan bloopers — untuk membuatnya
lebih konkret.
Karenanya, buku ini bukan sekadar kumpulan "outtakes" UI — memalukan
kesalahan yang dilakukan pengembang perangkat lunak. Tujuan saya bukan untuk memberikan parade
Lolong UI yang mempermalukan pengembang mereka dan menyebabkan pembaca tertawa, goyang
kepala mereka, dan bertanya-tanya bagaimana desainer bisa begitu bodoh. Tujuan saya adalah untuk
membantu desainer dan pengembang GUI belajar menghasilkan GUI yang lebih baik.
Bloopers dalam buku ini dijelaskan dan, jika memungkinkan, diilustrasikan
menggunakan gambar layar yang diambil dari produk nyata dan layanan online, buatan tangan
gambar layar, dan cerita dari pengalaman saya. Dengan setiap kesalahan besar adalah desainnya
aturan yang harus diikuti developer untuk menghindari blooper. Seperti bloopers,
aturan desain sering diilustrasikan dengan contoh, baik nyata maupun buatan.
Bloopers dalam buku ini diklasifikasikan ke dalam tujuh kategori: Kontrol GUI,
navigasi, tekstual, interaksi, desain grafis dan tata letak, daya tanggap, dan
pengelolaan.
Gambar yang menunjukkan blooper ditandai dengan simbol “jempol ke bawah”. Itu
yang menunjukkan menghindari blooper yang ditandai dengan simbol "jempol". Gambar itu
tidak ada simbol yang netral, disediakan hanya sebagai informasi.

Halaman 18

4 pengantar

Bagaimana blooper dikompilasi?

Bloopers dalam buku ini diambil sampelnya dari lebih dari tiga dekade pengalaman-
ence merancang, mengkritik, dan menguji UI untuk produk perangkat lunak. Mereka
disusun dari ulasan UI, laporan pengujian kegunaan, dokumen pedoman desain,
dan kelas yang disiapkan untuk pemberi kerja dan klien konsultasi. Beberapa dikirim
oleh rekan kerja.
Sangat sedikit contoh yang mengidentifikasi produk atau perusahaan perangkat lunak yang berasal
klien konsultasi saya. Saya biasanya bekerja untuk klien di bawah persetujuan kerahasiaan-
masalah yang mencegah saya mengungkapkan detail tentang apa yang dikembangkan, bahkan untuk apa

[Link] 12/315
26/2/2021 Tanpa judul
perangkat lunak yang tidak pernah berhasil dipasarkan. Oleh karena itu, di sebagian besar cerita di
buku ini, nama perusahaan dan produk tertentu diubah atau dengan-
diadakan. Untuk alasan yang sama, sebagian besar gambar layar yang menampilkan blooper muncul
dari perangkat lunak yang tersedia secara komersial dan situs Web yang dikembangkan oleh perusahaan
selain klien saya. Namun, saya memang mendapatkan izin dalam beberapa kasus untuk menggunakan
nama asli dan gambar layar saat mendiskusikan perangkat lunak klien.
Terakhir, beberapa gambar layar yang mengilustrasikan blooper dalam buku ini adalah
dibuat-buat — dibuat khusus untuk buku ini untuk menggambarkan blooper tertentu
jelas.

Bagaimana buku ini diatur?

Bab 1, Prinsip Pertama, menyajikan sembilan prinsip desain UI dasar yang

berbohong baik blooper maupun aturan desain tentang cara menghindari blooper.
Bab selanjutnya menjelaskan dan mengilustrasikan perangkat lunak blooper yang umum
pengembang dan manajer mereka membuat perangkat lunak sulit digunakan. Setiap
bab berfokus pada jenis blooper yang berbeda: blooper kontrol GUI, naviga-
blooper tion, blooper tekstual, desain grafis dan layout blooper, interaksi
blooper, blooper responsif, dan blooper manajemen.

Siapa yang harus membaca GUI Bloopers 2.0

dan bagaimana mereka menggunakannya?

Sasaran utama buku ini adalah para pengembang yang mengembangkan perangkat lunak
atau situs web dengan sedikit atau tanpa panduan atau umpan balik dari para profesional UI. Untuk
pembaca yang demikian, buku ini dimaksudkan untuk berfungsi baik sebagai alat untuk pendidikan mandiri maupun
sebagai acuan. Ini dimaksudkan untuk melengkapi — bukan menggantikan — pedoman desain UI
untuk platform GUI tertentu.
Sasaran kedua adalah manajer tim pengembangan perangkat lunak. ini
untuk keuntungan mereka bahwa buku tersebut menyertakan bab tentang bloopers manajemen.

Halaman 19

[Link] 5

Target audiens ketiga adalah desainer UI, terutama mereka yang baru mengenal
profesi. Bagi mereka, buku ini melengkapi referensi standar dan teks-
buku tentang desain dan evaluasi UI dengan memperingatkan kesalahan desain umum,
dengan contoh nyata.
Tiga jenis pembaca yang berbeda mungkin menginginkan informasi yang berbeda
dari buku ini.
Pemrogram GUI mungkin ingin memulai dengan blooper tertentu: GUI
komponen, navigasi, tekstual, dan desain grafis dan tata letak. Anda bisa mulai
dengan Bab 1, Prinsip Pertama, sebelum membaca tentang bloopers, atau Anda bisa
kembali dan bacalah prinsip-prinsip yang relevan dengan Anda
bacaan. Setelah bab-bab itu, baca bab-bab tentang interaksi dan responsif-
ness bloopers. Anda dapat membaca bloopers dan lampiran manajemen jika Anda
punya waktu atau minat.
Untuk manajer perangkat lunak, bab tentang blooper manajemen adalah yang paling banyak
penting. Setelah itu, dalam urutan kepentingannya, ada blooper tekstual,
blooper responsif, dan blooper interaksi. Bab 1, Prinsip Pertama,
mungkin menarik jika Anda memiliki latar belakang atau minat dalam desain UI dan
interaksi manusia-komputer. Anda mungkin dapat melewati beberapa bab di GUI
kontrol, navigasi, dan desain dan tata letak grafis sepenuhnya. Anda bisa saja
beri tahu programmer dan desainer Anda untuk “membaca bagian itu dan melakukan apa
Johnson berkata. " :-)
Profesional UI baru harus mulai dengan membaca sekilas glosarium (Lampiran A)
dan membaca Bab 1, Asas-Asas Pertama. Kemudian baca sekilas bab tentang kontrol GUI,
navigasi, dan blooper tekstual terutama untuk melihat apa yang ada di dalamnya; Anda dapat mengunjungi kembali
blooper tertentu di bab tersebut nanti sesuai kebutuhan. Bab-bab tentang interac-
tion, responsiveness, dan management bloopers sangat direkomendasikan
profesional UI baru. Anda mungkin tertarik membaca Lampiran B untuk mengetahui caranya
buku ini ditingkatkan melalui pengujian kegunaan. Tabel I.1 merangkum ini
rekomendasi.

[Link]

[Link] 13/315
26/2/2021 Tanpa judul

Melengkapi buku ini adalah situs Web, [Link]. Disana kamu

akan menemukan:

■
GUI Bloopers 2 checklist: daftar singkat dari semua bloopers dalam buku, cocok
untuk dicetak. Gunakan untuk memeriksa perangkat lunak sebelum rilis.
■
Apendiks Web: Color Bloopers: dua blooper tentang penggunaan warna yang buruk
tidak dapat dimasukkan ke dalam buku karena tidak dicetak berwarna.
■
Lebih banyak bloopers: blooper tambahan tidak termasuk dalam buku, dimulai dengan bloop-
ers yang tidak cukup masuk dalam "potongan terakhir" buku. Koleksi ini dapat diperpanjang
dari waktu ke waktu berdasarkan kiriman dari pembaca (info@[Link]).

Halaman 20

6 pengantar

Tabel I.1 Jenis pembaca

Pemrogram GUI Profesional UI baru Manajer Pengembangan

(Prinsip Pertama) Lampiran A: Glosarium * Kesalahan Manajemen

Bloopers Kontrol GUI Prinsip Pertama Bloopers tekstual
Bloopers Navigasi Bloopers Kontrol GUI * Bloopers Responsif *
Desain Grafis dan Bloopers Navigasi * Interaksi Bloopers *
Bloopers Tata Letak
Bloopers tekstual Desain Grafis dan (Prinsip Pertama)
Bloopers Tata Letak *
Interaksi Bloopers Bloopers Tekstual * (Lampiran A: Glosarium)
Bloopers Responsif Interaksi Bloopers
(Kesalahan Manajemen) Bloopers Responsif
(Lampiran) Kesalahan Manajemen
(Lampiran)

Tanda kurung menunjukkan opsional.

*Meluncur.

■
Bab sampel: bab yang dipilih dari buku, tersedia untuk diunduh gratis.
■
Fungsi pembelian: cara untuk membeli buku dari penerbit.
■
Lebih banyak: konten tambahan mungkin disediakan, tergantung pada apa yang dibaca
permintaan dan penulis serta penerbit memutuskan untuk memberikan.

Halaman 21

[Link] 14/315
26/2/2021 Tanpa judul

Prinsip Pertama
pengantar

Prinsip Dasar 1: Fokus pada pengguna dan tugas mereka, bukan pada

teknologi

Prinsip Dasar 2: Pertimbangkan fungsi dulu, presentasi nanti

Prinsip Dasar 3: Sesuai dengan pandangan pengguna tentang tugas

Prinsip Dasar 4: Desain untuk kasus umum

Prinsip Dasar 5: Jangan mempersulit tugas pengguna

Prinsip Dasar 6: Memfasilitasi pembelajaran

Prinsip Dasar 7: Menyampaikan informasi, bukan hanya data

Prinsip Dasar 8: Desain untuk daya tanggap

Prinsip Dasar 9: Cobalah pada pengguna, lalu perbaiki!

Halaman 22

8 Bab 1 Prinsip Pertama

pengantar

Buku ini menjelaskan blooper antarmuka pengguna yang umum ditemukan di berbasis perangkat lunak
produk dan layanan dan memberikan aturan desain dan pedoman untuk menghindarinya
satu. Namun, pertama-tama, berguna untuk meletakkan dasar untuk pembahasan bloopers
dengan menjelaskan prinsip-prinsip dasar untuk merancang antarmuka pengguna yang efektif dan dapat digunakan.
Sembilan prinsip dasar dalam bab ini bukanlah aturan khusus untuk mendesain
antarmuka pengguna grafis (GUI). Bab ini tidak menjelaskan bagaimana mendesain
kotak dialog, menu, bilah alat, tautan Web, dll. Yang muncul nanti di buku ini, di
aturan untuk menghindari kesalahan besar.
Sembilan prinsip dasar mewakili kebijaksanaan kumulatif banyak orang,
disusun selama beberapa dekade pengalaman dalam merancang sistem interaktif
untuk orang-orang. Prinsip-prinsip tersebut juga didasarkan pada penelitian selama satu abad tentang manusia
belajar, kognisi, membaca, dan persepsi [Card et al., 1983; Norman dan
Draper, 1986; Rudisill et al., 1996]. Bab-bab selanjutnya dari buku ini mengacu pada ini
prinsip dasar untuk menjelaskan mengapa desain atau praktik pengembangan tertentu
blooper dan mengapa pengobatan yang disarankan lebih baik.

[Link] 15/315
26/2/2021 Tanpa judul

“Dapat digunakan” —tidak hanya mudah dipelajari

Istilah "dapat digunakan" berarti lebih dari sekadar mudah dipelajari. Kemudahan belajar adalah sebuah
komponen penting dari kegunaan, tetapi yang paling tidak penting dari tiga komponen
nents. Agar dapat digunakan, produk juga harus cepat digunakan dan relatif bebas kesalahan.
Yang terpenting, itu harus melakukan apa yang diinginkan pengguna . Ingatlah ini saat Anda membaca
buku ini. Kegunaan mengacu pada tiga komponen berbeda: produk melakukan apa
Anda memerlukannya untuk melakukannya, ia melakukannya dengan cepat dan aman, dan terakhir, mudah dipelajari. Biola
sulit untuk dipelajari, tetapi mereka telah bertahan selama ratusan tahun dengan sedikit perubahan
karena mereka menyediakan dua komponen kegunaan yang lebih penting.

Penjelasan yang lebih komprehensif tentang prinsip desain UI disajikan di

beberapa buku, misalnya, Smith dan Mosier [1986], Cooper, Reimann, dan Cronin
[2007], Isaacs dan Walendowski [2001], Raskin [2000], Shneiderman dan
Plaisant [2004], dan Tidwell [2005].

Prinsip Dasar 1: Fokus pada pengguna dan

tugas mereka, bukan pada teknologi

Inilah Prinsip Numero Uno, Prinsip Utama, ibu dari semua prinsip,
prinsip dari mana semua prinsip desain antarmuka pengguna lainnya diturunkan:

Fokus pada pengguna dan tugas mereka, bukan pada teknologi.

Halaman 23

Prinsip Dasar 1: Fokus pada pengguna dan tugas mereka, bukan pada teknologi 9

Sekarang setelah Anda membacanya, kita sudah selesai, bukan? Sekarang Anda tahu cara mendesain semuanya
perangkat lunak masa depan Anda, dan tidak ada lagi yang perlu dikatakan.
Saya harap! Sayangnya, banyak orang telah menyatakan prinsip ini sebelum saya, dan ternyata tidak
tampaknya telah melakukan banyak hal baik. Dan tidak heran: terlalu samar, terlalu terbuka
interpretasi, terlalu sulit untuk diikuti, dan terlalu mudah diabaikan saat menjadwalkan
dan sumber daya menjadi ketat. Oleh karena itu, prinsip yang lebih rinci, aturan desain,
dan contoh blooper diperlukan, serta saran tentang cara fokus
tentang pengguna, tugas, dan datanya.
Apa yang dimaksud dengan "fokus pada pengguna dan tugas mereka"? Itu berarti memulai soft-
proyek pengembangan ware dengan menjawab beberapa pertanyaan:

■
Untuk siapa perangkat lunak ini dirancang? Siapa pengguna yang dituju?
Siapa pelanggan yang dituju (belum tentu pengguna)?
■
Untuk apa software ini? Kegiatan apa yang dimaksudkan untuk didukung? Apa
masalah apakah itu akan membantu pengguna memecahkan? Nilai apa yang akan diberikannya?
■
Masalah apa yang dimiliki pengguna yang dituju sekarang? Apa yang mereka suka dan
tidak suka dengan cara mereka bekerja sekarang?
■
Apa keterampilan dan pengetahuan pengguna yang dituju? Apakah mereka termotivasi
untuk mempelajari? Bagaimana? Apakah ada kelas pengguna yang berbeda, dengan keterampilan yang berbeda,
pengetahuan, dan motivasi?
■
Bagaimana pengguna mengkonseptualisasikan data yang akan dikelola oleh perangkat lunak?
■
Apa cara kerja yang disukai pengguna yang dituju? Bagaimana
perangkat lunak cocok dengan cara-cara itu? Bagaimana itu akan mengubahnya?

Alangkah baiknya jika jawaban atas pertanyaan-pertanyaan ini jatuh dari langit
ke dalam pangkuan pengembang di awal setiap proyek. Tapi, tentu saja, mereka tidak mau.
Satu-satunya cara untuk menjawab pertanyaan-pertanyaan ini adalah untuk dibuat oleh tim pengembangan
upaya yang eksplisit dan serius untuk melakukannya. Itu membutuhkan waktu dan biaya, tetapi memang demikian
penting, karena biaya tidak menjawab pertanyaan-pertanyaan ini sebelum memulai
merancang dan mengembangkan perangkat lunak jauh lebih tinggi.

Pahami pengguna

Beberapa pertanyaan yang tercantum di atas adalah tentang pengguna yang dituju dari perangkat lunak
ware: Siapa mereka? Apa yang mereka suka dan tidak suka? Apa keahlian mereka,
pengetahuan, kosa kata, dan motivasi? Akankah mereka menjadi orang-orang yang membuat
keputusan untuk membeli perangkat lunak, atau akankah orang lain melakukannya? Pertanyaan-pertanyaan ini

[Link] 16/315
26/2/2021 Tanpa judul
paling baik dijawab
investigasi, menggunakan
dan sebagian proses
kolaborasi . yang merupakan keputusan bisnis sebagian , sebagian empiris

Halaman 24

10 Bab 1 Prinsip Pertama

Putuskan siapa pengguna yang dituju

Pada awal pengembangan, Anda perlu memutuskan siapa yang akan mengembangkan perangkat lunak tersebut
untuk. Sangat menggoda untuk mengatakan "semua orang": sebagian besar pengembang menginginkan posisi terluas
pasar sible. Tahan godaan itu! Perangkat lunak yang dirancang untuk semua orang mungkin
untuk tidak memuaskan siapa pun. Pilih populasi sasaran primer tertentu seperti yang diinginkan
basis pengguna untuk memfokuskan upaya desain dan pengembangan Anda, bahkan jika Anda
percaya bahwa perangkat lunak juga akan memiliki jenis pengguna lain.
Dalam mengambil keputusan penting ini, konfirmasikan bahwa basis pengguna target Anda adalah
selaras dengan tujuan strategis organisasi Anda. Carilah masukan dari pasar-
departemen ing dan penjualan, karena merekalah yang biasanya bertanggung jawab
mengidentifikasi dan mengkategorikan pelanggan. Namun, ingatlah Pemasaran itu
dan Penjualan berfokus pada pelanggan produk atau layanan, sedangkan Anda membutuhkannya
memahami pengguna . Pelanggan suatu produk dan penggunanya belum tentu
orang yang sama, atau bahkan jenis orang yang sama, jadi Pemasaran dan Penjualan '
Ide tentang siapa yang menjadi sasaran produk mungkin harus disaring atau ditambah
agar berguna bagi Anda.

Selidiki karakteristik pengguna yang dituju

Memahami pengguna juga membutuhkan investigasi . Ini berarti berusaha

untuk mempelajari karakteristik yang relevan dari calon pengguna. Survei calon pengguna
membantu Anda menemukan populasi tertentu yang
persyaratan dan demografi membuatnya
pasar sasaran yang menarik. Setelah mengidentifikasi
populasi pengguna target utama, pelajari sebagai
sebanyak mungkin tentang populasi itu.
Bagaimana Anda mengumpulkan informasi tentang
pengguna yang dituju? Dengan berbicara dengan mereka,
mengundang mereka untuk berpartisipasi dalam kelompok fokus,
mengamati mereka di lingkungan "alam" mereka.
ment, berbicara dengan manajer mereka, atau membaca
tentang bisnis mereka.

Pengguna: Bukan Hanya pemula

vs. berpengalaman

Pengembang perangkat lunak sering memikirkannya

pengguna yang dituju sebagai bervariasi dalam satu kontinum
dari komputer "pemula" menjadi "ahli". Orang-orang
yang belum pernah menggunakan komputer aktif
akhir pemula; komputer profesional
insinyur berada di ujung ahli. Dengan itu
asumsi, mencari tahu siapa penggunanya

Halaman 25

Prinsip Dasar 1: Fokus pada pengguna dan tugas mereka, bukan pada teknologi 11

untuk aplikasi tertentu sebagian besar masalah menentukan di mana mereka jatuh
di kontinum.

[Link] 17/315
26/2/2021 Tanpa judul
Namun,
tampilan kontinumnya
realistis salah.
dan berguna Tidakbahwa
adalah ada kontinum
penggunaseperti itu. A dapat
yang dituju lebih ditempatkan bersama tiga
dimensi pengetahuan independen:

■
Pengetahuan komputer umum: seberapa banyak yang mereka ketahui tentang komputer secara umum
■
Pengetahuan tugas : seberapa lancar mereka dalam melakukan tugas target, misalnya,
akuntansi
■
Pengetahuan tentang sistem: seberapa baik mereka mengetahui produk perangkat lunak tertentu,
atau yang seperti itu

Pengetahuan di salah satu dimensi ini tidak menyiratkan pengetahuan di dimensi lain.
Orang bisa menjadi tinggi atau rendah pada salah satu dimensi ini, secara mandiri. Ini
menjelaskan situasi seperti berikut:

■
Seorang programmer C ++ lama tidak tahu bagaimana memprogram DVR-nya.
■
Administrator sistem Linux yang berpengalaman berjuang dengan Microsoft Word,
sementara seorang sekretaris kantor yang belum pernah mendengar tentang Linux menangani Word
dengan mudah.
■
Para pemula dan ahli komputer sama-sama tersesat di biro perjalanan online
Situs web.
■
Seorang programmer tanpa pengalaman akuntansi mengalami kesulitan belajar menggunakan file
paket akuntansi, sedangkan akuntan berpengalaman tanpa pemrograman
pengalaman belajar dengan mudah.

Saat membuat profil pengguna, posisikan jenis pengguna target di sepanjang masing-masing
tiga dimensi, bukan pada satu skala pemula hingga ahli. Para pengguna
motivasi juga merupakan faktor: mengapa mereka belajar dan menggunakan perangkat lunak? Apakah itu
persyaratan pekerjaan, atau perangkat lunak untuk digunakan di rumah, digunakan di pelanggan
kebijaksanaan? Apakah ada alternatif lain?

Berkolaborasi dengan pengguna yang dituju untuk belajar

tentang mereka

Terakhir, memahami pengguna paling baik dicapai dengan bekerja bersama mereka
sebagai kolaborator . Jangan perlakukan pengguna hanya sebagai objek untuk dipelajari. Bawalah beberapa
mereka ke tim Anda. Perlakukan mereka sebagai ahli, meskipun jenisnya berbeda
daripada para pengembang. Mereka memahami pekerjaan, pengalaman, struktur manajemen mereka.
ture, suka dan tidak suka, dan motivasi. Mereka mungkin tidak mengerti pro-
tata bahasa dan desain antarmuka pengguna, tapi tidak apa-apa — orang lain di tim Anda melakukannya.
Slogan berguna yang perlu diingat saat merancang perangkat lunak adalah:

Perangkat lunak harus dirancang bukan untuk pengguna atau oleh mereka, melainkan dengan mereka.

Halaman 26

12 Bab 1 Prinsip Pertama

Menyatukan semuanya

Tujuan dari proses tiga bagian ini — keputusan, investigasi, dan kolaborasi-
tion — adalah untuk menghasilkan profil yang mendeskripsikan tujuan utama pengguna
perangkat lunak. Profil tersebut harus mencakup informasi seperti deskripsi pekerjaan, pekerjaan
senioritas, pendidikan, gaji, per jam versus gaji, bagaimana kinerja mereka
dinilai, usia, tingkat keterampilan komputer, dan karakteristik fisik atau sosial yang relevan-
tics. Dengan profil seperti itu, pengembang tahu apa yang mereka tuju.
Tanpa itu, mereka, seperti yang dikatakan Bickford [1997]: “target menembak dalam gelap
kamar."
Beberapa desainer melampaui pembuatan profil untuk pengguna yang dituju dari sebuah
aplikasi. Cooper [1999] menganjurkan membuat profil pengguna yang konkret oleh elabo-
menilai mereka menjadi persona yang sempurna: karakter dengan nama, panggilan, latar belakang
alasan, keluarga, hobi, keterampilan, gaya hidup, dan kompleksitas realistis. Ini adalah
serupa dengan praktik di antara novelis dan penulis naskah menulis "backsto-
ries ”untuk setiap karakter penting dalam sebuah buku, film, atau drama. Karakter
backstory membantu keputusan dasar tentang apa yang karakter itu akan dan akan lakukan
tidak lakukan. Demikian pula, persona dalam dasar bantuan metodologi desain Cooper
penilaian tentang desain yang menurut jenis pengguna tertentu mudah, sulit,
mengganggu, menyenangkan, berguna, tidak berguna, dll. Karena kebanyakan produk memiliki lebih dari satu
jenis pengguna, ini membantu untuk mengembangkan dan menggunakan berbagai persona yang paling banyak menutupi
jenis pengguna penting.
Caranya adalah dengan membangun profil dan persona dari data nyata yang diperoleh dari pro-
pengguna spektif. Profil dan persona pengguna berdasarkan spekulasi kursi berlengan murni
tidak akan membantu menginformasikan keputusan desain sehingga tidak akan menambah nilai.

[Link] 18/315
26/2/2021 Tanpa judul

Pahami tugasnya

Seperti halnya memahami pengguna Anda, seharusnya memahami tugas pengguna Anda
proses tiga bagian: sebagian keputusan bisnis , sebagian penyelidikan empiris , dan
sebagian kolaborasi .

Putuskan kumpulan tugas apa yang akan didukung

Memahami tugas yang dimaksudkan sebagian merupakan keputusan bisnis karena no

organisasi benar-benar berpikiran terbuka tentang aplikasi apa yang akan dikembangkan.
Tidak ada organisasi yang akan memilih sekelompok pelanggan potensial murni saat berlari-
dom, cari tahu apa yang mereka butuhkan, dan rancang produk untuk memenuhi kebutuhan itu. Sebagai gantinya,
keputusan tentang apa yang akan ditawarkan sangat dipengaruhi — bahkan bisa dikatakan
“Ditentukan sebelumnya” —oleh:

■
sasaran strategis organisasi, yang mencerminkan kepentingan para pendirinya, puncak
manajemen, dan pemegang saham;

Halaman 27

Prinsip Dasar 1: Fokus pada pengguna dan tugas mereka, bukan pada teknologi 13

■
keahlian karyawannya;
■
sejarah masa lalunya;
■
aset, proses, dan infrastrukturnya;
■
persepsinya tentang peluang dan ceruk pasar;
■
teknologi baru yang dikembangkan oleh para peneliti.

Peluru terakhir di atas, "teknologi baru yang dikembangkan oleh para peneliti," terutama
sangat penting. Dalam industri komputer dan perangkat lunak, keputusan tentang
produk atau layanan apa yang akan dibawa ke pasar seringkali lebih dipengaruhi
dengan "dorongan" teknologi daripada dengan "menarik" dari pasar [Johnson,
1996a]. Apakah ini baik atau buruk adalah topik perdebatan. Norman [1998]
berpendapat bahwa ini sering kali baik untuk pasar negara berkembang, tetapi biasanya buruk untuk pasar negara berkembang
satu.
Terlepas dari faktor mana yang berlaku untuk situasi Anda, Anda harus memutuskan
terlebih dahulu area aplikasi umum apa yang akan ditargetkan, seperti pembuatan dokumen
tion dan manajemen, pengambilan informasi, perbankan, musik, keuangan rumah,
atau reservasi maskapai penerbangan. Keputusan ini digabungkan dengan keputusan tentang
basis pengguna target utama untuk menghasilkan kategori produk yang cukup spesifik, seperti
perangkat lunak pengedit dokumen untuk penulis teknis atau perangkat lunak perbankan untuk bank
teller.
Seperti mengidentifikasi pengguna target, cari konfirmasi bahwa tugas target
domain produk atau layanan sejalan dengan tujuan strategis. Kamu lagi
harus mencari masukan dari bagian pemasaran dan penjualan, karena memang itulah mereka
yang biasanya bertanggung jawab untuk mengidentifikasi peluang pasar dan karena
mereka sering kali memiliki setidaknya pemahaman langsung tentang pekerjaan yang dimaksudkan
yang pengguna lakukan.

Selidiki tugas yang dimaksudkan

Setelah Anda memilih kategori produk, empiris investigasi bagian dari

"Memahami tugas" mulai berlaku. Sebelum mulai merancang atau menerapkan-
ment apa saja, pelajari sebanyak mungkin tentang persis bagaimana pengguna yang dituju
melakukan tugas-tugas yang seharusnya didukung oleh perangkat lunak. Ini disebut konduksi
sebuah "analisis tugas." Tujuan dari analisis tugas adalah untuk mengembangkan pemahaman yang menyeluruh
kedudukan aktivitas yang akan didukung perangkat lunak.
Cara terbaik untuk melakukan analisis tugas adalah untuk Anda dan anggota lainnya
tim pengembangan untuk berbicara dan mengamati orang-orang yang akan menjadi pengguna
atau mirip dengan pengguna yang dituju. Wawancara dan sesi observasi ini
biasanya berkaitan dengan pemahaman bagaimana orang melakukan tugas sebelumnya
produk atau layanan baru diperkenalkan. Beberapa produk baru berubah secara radikal
bagaimana orang melakukan tugas atau membuat yang benar-benar baru. Dalam kasus seperti itu, inter-
pemirsa menggambarkan dan / atau menunjukkan produk dan meminta peserta untuk berspekulasi pada
bagaimana mereka akan menggunakannya. Dalam kedua kasus tersebut, Anda dapat mewawancarai orang secara individu atau

[Link] 19/315
26/2/2021 Tanpa judul

Halaman 28

14 Bab 1 Prinsip Pertama

dalam kelompok, tatap muka atau melalui telepon atau email, dalam pengaturan penggunaan atau terpisah
dari itu.
Penting bagi pengguna wawancara dan mengamati mereka bekerja. Itu
dua teknik saling melengkapi. Wawancara dan kelompok fokus menyediakan
penjelasan, alasan, tujuan, dan informasi lain yang tidak bisa langsung
diamati. Namun, wawancara juga dapat memberikan informasi yang salah , seperti
bagaimana sebuah proses seharusnya (tetapi tidak) bekerja atau apa yang pengguna pikirkan tentang Anda
ingin mendengar. Pengamatan, di sisi lain, memungkinkan Anda melihat apa yang sebenarnya
terjadi, tetapi mengharuskan Anda untuk menafsirkan apa yang Anda lihat. Jika Anda tidak terbiasa
dengan domain tugas — dan Anda mungkin; jika tidak, Anda tidak perlu
untuk mempelajarinya — kemampuan Anda untuk menafsirkan dengan benar apa yang akan Anda amati
dibatasi.
Dimungkinkan untuk mewawancarai dan mengamati secara bersamaan: Anda bisa wawancara
calon pengguna di tempat kerja mereka, mendorong mereka untuk menjawab pertanyaan-
tidak hanya secara lisan, tetapi juga dengan mendemonstrasikan cara kerjanya. Ingatkan orang
untuk menjelaskan apa yang mereka lakukan saat mereka bekerja; jika tidak, mereka mungkin akan bekerja
diam-diam atau bergumam tanpa suara. Ajukan pertanyaan jika perlu.
Anda juga bisa mewawancarai manajer. Ini memberikan perspektif lain yang berguna
pada tugas yang sama. Namun, wawancara dengan manajer pengguna harus diinterpretasikan
hati-hati: manajer sering menggambarkan bagaimana pekerjaan seharusnya dilakukan
daripada bagaimana hal itu sebenarnya dilakukan.

Contoh pertanyaan analisis tugas

Untuk proyek penelitian, seorang kolega dan saya melakukan analisis tugas tentang bagaimana orang-
mohon persiapkan presentasi slide [Johnson dan Nardi, 1996]. Kami mewawancarai orang-
di kantor mereka, dorong mereka untuk membicarakan dan mendemonstrasikan caranya
mereka bekerja. Pertanyaan wawancara dikutip di bawah ini (dan disediakan secara lengkap
Lampiran C). Pewawancara membiarkan percakapan mengalir secara alami
daripada mengikuti daftar pertanyaan secara ketat, tetapi memastikan semua pertanyaan memiliki
telah dijawab.

1. Apa peran Anda dalam menghasilkan presentasi slide?

1.1 Apakah Anda membuat slide sendiri atau Anda mengawasi orang lain yang melakukannya?
1.2 Berapa banyak dari total pekerjaan Anda yang melibatkan pembuatan presentasi slide?
1.3 Untuk siapa Anda membuat presentasi slide ini?
1.4 Tingkat kualitas apa yang diperlukan untuk slide?
1.5 Apakah Anda (departemen Anda) mengikuti standar pemformatan slide?
2. Perangkat lunak apa yang Anda gunakan untuk membuat presentasi slide?
2.1 Siapa yang memutuskan perangkat lunak apa yang Anda gunakan untuk ini?
2.2 Apakah Anda menggunakan satu program atau kumpulan dari mereka?

Halaman 29

Prinsip Dasar 1: Fokus pada pengguna dan tugas mereka, bukan pada teknologi 15

2.3 Apakah Anda menggunakan perangkat lunak gambar untuk keperluan umum atau perangkat lunak pembuat slide
ware?
2.4 Apa yang Anda suka dan tidak suka dari setiap program yang Anda gunakan?
2.5 Perangkat lunak lain apa yang telah Anda gunakan, coba, atau pertimbangkan untuk dibuat
slide, baik di sini atau di pekerjaan sebelumnya?
3. Apa yang terlibat dalam pembuatan slide?
3.1 Jelaskan proses lengkap menghasilkan presentasi.
3.2 Apakah Anda menggunakan kembali slide lama dalam presentasi baru?
3.3 Bagaimana Anda (departemen Anda) mengatur dan melacak slide dan
presentasi?

[Link] 20/315
26/2/2021 Tanpa judul

Berkolaborasi dengan pengguna untuk mempelajari tentang tugas

Berkolaborasi dengan pengguna bahkan lebih penting untuk memahami tugas

daripada untuk memahami pengguna. Batasan wawancara dan
Pengamatan membuatnya berisiko untuk mengandalkan kesimpulan yang diperoleh dengan metode mana pun
sendirian. Keterbatasan ini dapat diatasi dengan memberikan umpan balik dua arah
ke dalam proses penemuan dan analisis tugas. Jangan hanya mengumpulkan data dari pengguna;
menyajikan analisis dan kesimpulan awal kepada mereka dan meminta reaksi mereka.
Dalam proses seperti itu, Anda tidak akan menjadi satu-satunya orang yang belajar; pengguna juga mendapatkan file
kesadaran yang lebih besar tentang bagaimana mereka bekerja dan tentang jenis teknologi apa yang mungkin digunakan
bantu mereka bekerja lebih baik. Sebagai imbalan atas usaha yang dibutuhkan untuk membangun sebuah kolaborasi-
tive hubungan kerja, Anda akan mendapatkan data yang lebih dapat diandalkan dari pengguna.
Nasihat terperinci tentang meminta bantuan pengguna untuk memahami tugas mereka dengan baik-
ter disediakan dalam artikel oleh Dayton et al. [1998] dan buku-buku oleh Greenbaum
dan Kyng [1991] dan Keberanian dan Baxter [2004].

Menyatukan semuanya

Untungnya, menganalisis tugas membutuhkan banyak aktivitas yang sama seperti menyelidiki
pengguna. Meskipun kedua investigasi dibahas secara terpisah di sini untuk
menjelaskan masing-masing dengan lebih baik, sebagian besar pengembang melakukannya pada waktu yang sama, di
sesi wawancara dan kolaborasi yang sama. Sinergi ini bermanfaat karena akses
untuk calon pengguna biasanya terbatas (Blooper 68, halaman 362).
Analisis tugas yang dilakukan dengan baik menjawab beberapa pertanyaan yang cukup rinci. Mereka:

■
Tugas apa yang dilakukan orang tersebut yang relevan dengan target aplikasi
area tugas?
■
Tugas mana yang umum, dan tugas mana yang jarang?
■
Tugas mana yang paling penting, dan mana yang paling tidak penting?
■
Apa langkah-langkah dari setiap tugas?

Halaman 30

16 Bab 1 Prinsip Pertama

■
Apa hasil dan keluaran dari setiap tugas?
■
Dari mana asal informasi untuk setiap tugas, dan bagaimana
informasi yang dihasilkan dari setiap tugas yang digunakan?
■
Orang mana yang melakukan tugas apa?
■
Alat apa yang digunakan untuk melakukan setiap tugas?
■
Masalah apa, jika ada, yang dimiliki orang untuk melakukan setiap tugas? Macam apa
kesalahan biasa terjadi? Apa penyebabnya? Seberapa merusakkah kesalahan?
■
Istilah apa yang digunakan orang-orang yang melakukan tugas-tugas ini?
■
Bagaimana tugas yang berbeda terkait?
■
Komunikasi apa dengan orang lain yang diperlukan untuk melakukan tugas?

Pertimbangkan konteks di mana perangkat lunak tersebut

akan berfungsi

Insinyur sering melihat apa yang mereka rancang seolah-olah itu satu-satunya yang masuk
alam semesta. Mereka tidak mempertimbangkan konteks di mana teknologi itu nantinya
digunakan atau pengalaman total pengguna dalam menggunakan teknologi di dalamnya
konteks.
Terkadang, bahkan orang yang membeli teknologi menjadi mangsa teknosentris
visi terowongan. Mereka memiliki masalah dan berharap itu, dengan memperoleh dan menggunakan
beberapa teknologi, mereka bisa memperbaikinya. Angan-angan sering mempengaruhi orang
untuk melihat masalah lebih sederhana dari yang sebenarnya, yaitu, mudah diperbaiki dengan
teknologi. Itu juga sering membuat mereka mudah tertipu dengan klaim yang sering dilebih-lebihkan
produsen dan vendor teknologi.
Insinyur dan konsumen teknologi mewujudkan visi terowongan teknosentris
hanya karena mereka manusia. Orang-orang fokus pada mereka sendiri (atau organisasinya-
tion's) tujuan dan keinginan dan sering gagal untuk memperhatikan hal-hal lain di lingkungan
yang mempengaruhi hasil penerapan teknologi pada suatu masalah.
Pertimbangkan seseorang yang merancang alarm mobil atau yang membelinya. Desainer
berfokus pada pembuatan perangkat yang memberi sinyal saat mobil sedang dibobol atau

[Link] 21/315
26/2/2021 Tanpa judul
dirusak. Konsumen berfokus untuk melindungi mobilnya. Tidak ada yang mempertimbangkan
bahwa alarm harus bekerja di lingkungan di mana banyak orang lain
memiliki alarm mobil dan hal-hal selain pembobolan yang memicu alarm.
Saat alarm berbunyi, sulit untuk mengetahui mobil siapa itu dan tidak mungkin
untuk mengetahui apakah itu menandakan pembobolan. Jarang terjadi pembobolan. Sebaliknya
Ide produk yang bagus gagal memberikan nilai karena desainer dan konsumen
tidak mempertimbangkan gambaran yang lebih besar.
Visi terowongan teknosentris, diterapkan ke kantor yang berisi komputer,
melihat kantor sebagai ruangan yang digelapkan dengan lampu sorot pada komputer (Gambar
1.1). Pengguna menjadi sorotan, menggunakan komputer, dan pergi, menghilang

Halaman 31

Prinsip Dasar 1: Fokus pada pengguna dan tugas mereka, bukan pada teknologi 17

Gambar 1.1

Melihat komputer sendiri, tanpa konteksnya.

kembali ke kegelapan. Hal-hal yang dilakukan orang dengan komputer dianggap sebagai
terputus, dan hal-hal yang mereka lakukan tanpanya tidak akan terlihat. Menggunakan
komputer, orang melihat, membuat, dan mengedit dokumen dan spreadsheet; Baca dan
mengirim email; mengunjungi atau membuat situs Web, dll. Dari mana masukan itu berasal?
Tidak penting. Untuk apa output digunakan? Tidak relevan.
Faktanya, komputer tertanam dalam konteks kerja. Cara yang lebih baik untuk melihat
sebuah kantor adalah sekumpulan jalur cahaya yang mengalir masuk, masuk, dan keluar
kantor (Gambar 1.2). Di setiap jalur cahaya ada seseorang. Beberapa jalur berpotongan
komputer; yang lainnya tidak. Jalan mewakili arus informasi,
komunikasi, dan pekerjaan; mereka menunjukkan dari mana asalnya dan kemana perginya.
Daripada bertanya "Apa yang harus dilakukan produk ini?" Anda harus bertanya, “Apa
kantor ini lakukan? " Bagaimana cara melakukannya? dan “Perangkat lunak apa yang akan mendukung dilakukannya
itu lebih baik?"
Ketika perancang aplikasi perangkat lunak tidak mempertimbangkan konteksnya
di mana aplikasi akan digunakan, sering ditemukan oleh pengguna aplikasi
sendiri mengetik data ke dalamnya yang baru saja keluar dari pro- komputer lain
gram. Desainer aplikasi tidak memikirkan kemana datanya
datang dari dan karenanya tidak merancang aplikasi mereka untuk menerima masukan langsung dari
program lainnya.
Untuk memahami konteks di mana aplikasi perangkat lunak yang direncanakan akan
digunakan, Anda harus mempelajari konteks itu. Itu berarti berbicara dengan calon atau
perwakilan pengguna, mengamati mereka, dan menganalisis data yang dikumpulkan. Nasihat
tentang cara melakukan ini disediakan oleh Holtzblatt et al. [2004].

Halaman 32

[Link] 22/315
26/2/2021 Tanpa judul

18 Bab 1 Prinsip Pertama

Gambar 1.2

Melihat komputer dalam konteksnya: kantor dan tugas yang digunakannya.

Prinsip Dasar 2: Pertimbangkan fungsi terlebih dahulu,

presentasi nanti

Banyak pengembang GUI — bahkan banyak perancang UI — mulai dengan memutuskan apa yang mereka miliki
UI aplikasi akan terlihat seperti ini. Beberapa desain sketsa di atas kertas atau dengan komputer
alat menggambar. Beberapa menggunakan alat pengembangan interaktif untuk mengatur tampilan dan
kontrol. Beberapa mulai meretas kode implementasi.
Jangan lakukan itu! Memulai dengan mengkhawatirkan penampilan meletakkan gerobak
sebelum kudanya. Memang menggoda, tetapi biasanya merupakan kesalahan. Ini menghasilkan produk yang
kekurangan fungsionalitas penting, mengandung fungsionalitas yang tidak dibutuhkan, dan sulit
untuk dipelajari dan digunakan.

Apa itu tidak berarti

Peringatan: “Mempertimbangkan fungsi dulu, presentasi nanti” tidak berarti

"Rancang dan terapkan fungsionalitasnya terlebih dahulu dan pikirkan tentang UI nanti".
Salah tafsir itu cocok dengan pendekatan yang digunakan banyak pengembang. Jarang
menghasilkan perangkat lunak yang sukses.

Halaman 33

Prinsip Dasar 2: Pertimbangkan fungsi dulu, presentasi nanti 19

UI aplikasi perangkat lunak tidak hanya tentang presentasi perangkat lunak.

Ini mewujudkan keputusan desain yang meluas jauh ke dalam arsitektur, seperti itu
sebagai konsep apa yang diekspos kepada pengguna, bagaimana informasi terstruktur, back-
fungsionalitas akhir, dan kemampuan penyesuaian. Antarmuka pengguna karena itu tidak bisa
berhasil ditempelkan pada akhir implementasi.

Apa yang dilakukannya berarti

Prinsip 2 harus ditafsirkan seperti ini: Sebuah aplikasi perangkat lunak mewujudkan
konsep dan hubungan tertentu antar konsep. Desainer harus sepenuhnya
tentukan konsep dan hubungannya sebelum mereka mendesain cara menyajikan
konsep kepada pengguna.
Dinyatakan lebih konkret: jangan langsung masuk ke tata letak GUI. Sebelum membuat sketsa
layar, memilih dan meletakkan kontrol, memotong prototipe busa, atau menulis
kode, pengembang harus fokus pada menjawab pertanyaan terkait tugas yang diberikan
di bawah Prinsip 1 dan kemudian pertanyaan-pertanyaan berikut:

[Link] 23/315
26/2/2021 Tanpa judul
Konsep apadari
mengenali yang akan terlihat
domain olehapakah
tugas, atau pengguna? Apakah
mereka baru?mereka konsep
Jika baru, yangmereka
bisakah diinginkan pengguna
disajikan sebagai perluasan dari konsep yang sudah dikenal, atau apakah itu konsep asing
diimpor dari ilmu komputer?
■
Data apa yang akan dibuat, dilihat, atau dimanipulasi oleh pengguna dengan perangkat lunak? Apa
informasi yang akan diambil pengguna dari data? Bagaimana? Langkah apa yang akan mereka lakukan
menggunakan? Dari mana asal data yang dibawa pengguna ke perangkat lunak, dan
dimana data yang dihasilkan di dalamnya akan digunakan?
■
Opsi, pilihan, pengaturan, dan kontrol apa yang akan disediakan aplikasi?
Ini bukan tentang bagaimana menampilkan kontrol (misalnya, sebagai tombol radio, menu,
slider). Ini tentang fungsi, tujuan, dan peran mereka dalam perangkat lunak (misalnya,
hari dalam seminggu, jumlah dolar, alamat email, tingkat volume). Ini adalah tentang
opsi apa yang disediakan perangkat lunak.

Kembangkan model konseptual

Setelah tim pengembangan menjawab pertanyaan di atas, itu penting

untuk menangkap dan mengatur pengetahuan itu dengan cara yang membantu desain UI. Sebuah rekomendasi
Cara diperbaiki adalah merancang model konseptual untuk perangkat lunak.

Apa model konseptual itu?

Model konseptual adalah model aplikasi yang diinginkan oleh perancang bagi pengguna
untuk mengerti. Dengan menggunakan perangkat lunak dan mungkin membaca dokumentasinya,
pengguna membangun model di benak mereka tentang cara kerjanya. Lebih baik jika model itu

Halaman 34

20 Bab 1 Prinsip Pertama

pengguna membangun dalam pikiran mereka seperti yang diinginkan desainer. Lebih dari itu
kemungkinan jika Anda merancang model konseptual yang jelas sebelumnya.
Mengembangkan model konseptual sebelum mendesain antarmuka pengguna itu sulit:
sangat menggoda untuk langsung membahas konsep antarmuka pengguna, seperti
panel kontrol, menu, dan tampilan data. Godaan diperburuk oleh
kecenderungan orang penjualan dan pemasaran untuk menyatakan persyaratan fungsional
dalam hal tata letak jendela dan klik mouse. Saat persyaratan pemasaran
dinyatakan dalam istilah UI, dengan anggun tapi tegas menolaknya, dan menuntut
persyaratan yang dinyatakan dalam tugas: masalah yang dihadapi pengguna dan
tujuan yang ingin mereka capai.
Model konseptual bukanlah antarmuka pengguna. Itu tidak diungkapkan dalam istilah
penekanan tombol, tindakan mouse, kotak dialog, kontrol, atau grafik layar. Saya t
dinyatakan dalam konsep tugas pengguna yang dituju: data
memanipulasi pengguna, bagaimana data diatur, dan apa yang dilakukan pengguna terhadap data.
Model konseptual menjelaskan, secara abstrak, fungsi perangkat lunak dan
konsep apa yang perlu diperhatikan orang untuk menggunakannya. Idenya adalah
bahwa dengan hati-hati menyusun model konseptual eksplisit, dan kemudian merancang a
Dari UI itu, software yang dihasilkan akan lebih bersih, simpel, dan mudah
memahami.

Sesederhana mungkin, tetapi tidak lebih sederhana— Albert Einstein

Satu tujuan, saat mengembangkan model konseptual untuk perangkat lunak yang direncanakan
aplikasi, adalah membuatnya sesederhana mungkin. Semakin sedikit konsep yang dimilikinya
pengguna untuk menguasai, semakin baik, asalkan menyediakan fungsionalitas yang diperlukan. Untuk
merancang perangkat lunak komputer, seperti dalam banyak hal, ingatlah ini:

Lebih sedikit lebih baik— Mies van der Rohe

Misalnya, dalam aplikasi yang memberikan petunjuk arah mengemudi, "belok timur laut"
dan “belok ke barat daya” diperlukan, atau apakah “belok kiri” dan “belok kanan” cukup?

Fokus pada tugas

Jaga agar model konseptual tetap fokus pada tugas, dengan konsep yang akan dikerjakan
akrab bagi pengguna. Tinggalkan konsep asing.
Semakin langsung pemetaan antara operasi sistem dan tugas
semakin besar kemungkinan model konseptual yang Anda inginkan
diadopsi oleh pengguna [Norman dan Draper, 1986]. Misalnya, bayangkan itu
Anda merancang perangkat lunak untuk membuat dan mengelola bagan organisasi. Aku s
bagan organisasi:

[Link] 24/315
26/2/2021 Tanpa judul

(A) struktur kotak, label kotak, tata letak kotak, dan garis konektor atau
(B) struktur organisasi, suborganisasi, dan karyawan?

Halaman 35

Prinsip Dasar 2: Pertimbangkan fungsi dulu, presentasi nanti 21

Model B memetakan lebih langsung ke tugas kebanyakan orang yang membuat dan menggunakan
bagan organisasi dan akan lebih mudah bagi mereka untuk menguasainya. Sebaliknya, Model
A berfokus pada tampilan grafik bagan organisasi, bukan pada
fungsi dan konten semantiknya. Model A mungkin model yang cocok untuk
desainer grafis, tetapi tidak akan cocok untuk orang lain.
Sistem berbasis komputer seringkali memberikan kemampuan baru. Ini biasanya benar
tugas yang sebelumnya tidak terkomputerisasi, tetapi bisa juga berlaku untuk itu
itu. Akibatnya, konsep asing kerap merayap ke dalam model konseptual.
Misalnya, buku janji temu kertas tidak dapat secara aktif mengingatkan pengguna tentang acara,
tetapi buku janji temu berbasis komputer bisa.
Namun, setiap konsep baru membutuhkan biaya tinggi, karena dua alasan:

■
Ini menambahkan konsep yang tidak akan dikenali oleh ahli tugas dan karenanya harus dipelajari.
■
Ini berpotensi berinteraksi dengan setiap konsep lain dalam perangkat lunak. Sebagai konsep
ditambahkan, kompleksitas sistem naik tidak linear, tetapi exponen-
tially !

Oleh karena itu, konsep tambahan harus ditolak, dan dimasukkan ke dalam
desain ceptual hanya jika memberikan manfaat tinggi dan biayanya diminimalkan
melalui desain UI yang bagus. Ingat: Lebih sedikit lebih baik!

Lakukan analisis objek / tindakan

Komponen terpenting dari model konseptual adalah objek / tindakan

analisis. Ini menentukan semua objek konseptual yang akan diekspos oleh aplikasi
kepada pengguna, tindakan yang dapat dilakukan pengguna pada setiap objek, atribut (pengguna-
pengaturan terlihat) dari setiap jenis objek, dan hubungan antar objek
[Kartu, 1996; Johnson dan Henderson, 2002].
Implementasi perangkat lunak dapat mencakup objek selain yang terdaftar di
model konseptual, tetapi jika demikian, objek tambahan tersebut harus tidak terlihat oleh pengguna.
Objek implementasi murni dan tindakan terkaitnya — seperti buffer teks,
tabel hash, atau record database — tidak termasuk dalam model konseptual.
Analisis objek / tindakan, oleh karena itu, adalah deklarasi konsep itu
diekspos ke pengguna. Ikuti aturan ini: "Jika tidak ada dalam analisis objek / tindakan,
pengguna seharusnya tidak mengetahuinya. ”

Contoh analisis objek / tindakan

Jika kami merancang perangkat lunak untuk mengelola rekening giro, objek /
analisis tindakan akan, jika berbasis tugas, termasuk objek seperti transaksi, cek,
dan akun . Itu akan mengecualikan objek yang tidak terkait dengan tugas seperti buffer, kotak dialog,
mode, database, tabel, dan string .
Model konseptual berbasis tugas akan mencakup tindakan seperti menulis dan kekosongan-
ing cek, penyetoran dan penarikan dana, dan menyeimbangkan account, sementara

Halaman 36

22 Bab 1 Prinsip Pertama

mengecualikan tindakan yang tidak terkait tugas seperti mengklik tombol, memuat database,
mengedit baris tabel, menyiram buffer, dan beralih mode.

[Link] 25/315
26/2/2021 Tanpa judul
Dalam model konseptual yang berfokus pada tugas, atributnya mungkin sebagai berikut:

■
Cek memiliki penerima pembayaran , nomor , teks memo , dan tanggal .
■
Akun memiliki pemilik dan saldo .
■
Transaksi (penyetoran dan penarikan) memiliki jumlah dan tanggal .

Model konseptual rekening giro di mana akun termasuk atribut

dari teknologi komputer, seperti jenis enkripsi, tidak akan fokus pada tugas.
Itu akan mengurangi kegunaan perangkat lunak, tidak peduli seberapa banyak
upaya dilakukan untuk merancang antarmuka pengguna.
Pertimbangkan bagaimana transaksi berulang ditangani di Quicken. 1 Percepat
desainer menyadari bahwa transaksi yang sering terjadi — seperti pembayaran
tagihan listrik setiap bulan — harus mudah dan cepat untuk dicatat. Dengan bijak, mereka tidak melakukannya
Puaskan ini dengan menambahkan konsep eksplisit template transaksi, dengan fasilitas
untuk membuat, mengelola, dan menggunakannya kembali. Sebagai gantinya, Quicken pengguna memasukkan
transaksi sebagai peristiwa satu kali, lalu beri tahu Quicken untuk menyimpannya di "Isi-cepat
Transaction ”daftar. Pengguna memasuki kembali transaksi berulang hanya dengan mengklik
mereka dalam daftar, lalu mengisi jumlah variabel. Jadi, desainer Quicken
menambahkan dukungan untuk transaksi berulang tanpa membebani UI dengan kelebihan
bagasi konseptual.
Objek, tindakan, dan atribut untuk memodelkan manajemen buku cek
mungkin tampak jelas, jadi mari pertimbangkan domain yang objek / tindakannya
analisis mungkin tampak kurang jelas: pelanggan memposting komentar tentang produk
di toko online. Objek yang sesuai di domain ini mungkin termasuk pelanggan,
produk, komentar pelanggan , dan tanggapan atas komentar. Tindakan pada produk
termasuk melihat dan menambahkan komentar . Tindakan atas komentar akan
termasuk melihat dan menanggapi dan, untuk komentar pengguna sendiri, mengedit . Itu
atribut komentar mungkin termasuk judul, nama pelanggan , dan
tanggal posting . Komentar tentang produk dapat diatur sebagai percabangan
struktur komentar dan tanggapan, tetapi itu mungkin lebih kompleks daripada
perlu; daftar komentar sederhana untuk produk tertentu mungkin cukup baik.
Masalah ini dapat diputuskan tanpa mengatakan apa pun tentang bagaimana GUI akan melakukannya
lihat atau bahkan apakah UI grafis atau ucapan.
Untuk diskusi tentang bagaimana analisis objek / tindakan membantu desainer mencapai
kesederhanaan desain, lihat Lampiran C.

Hubungan objek

Salah satu peran penting dari analisis objek / tindakan adalah untuk mendefinisikan dan merepresentasikan hubungan
antar objek. Objek konseptual mungkin terkait satu sama lain dalam beberapa cara.

1. Perangkat lunak manajemen rekening bank dari Intuit.

Halaman 37

Prinsip Dasar 2: Pertimbangkan fungsi dulu, presentasi nanti 23

Objek domain tugas biasanya membentuk hierarki tipe di mana beberapa

objek adalah tipe yang lebih spesifik dari yang lain. Misalnya, rekening koran
adalah salah satu jenis rekening bank, sebuah kamera digital adalah salah satu jenis kamera, dan
hipotek dengan suku bunga tetap adalah salah satu jenis hipotek . Membuat hierarki tipe jelas
dalam model konseptual membantu Anda memahaminya dan menentukan cara terbaik
menyajikannya kepada pengguna. Ini dapat membantu Anda melihat tindakan umum di seluruh objek,
yang dapat dirancang sebagai tindakan umum (lihat juga Prinsip Dasar 3). Ini,
pada gilirannya, membuat struktur perintah lebih mudah dipelajari oleh pengguna: daripada
sejumlah besar perintah khusus objek, sejumlah kecil generik
perintah berlaku di seluruh objek.
Misalnya, bayangkan aplikasi untuk menjadwalkan Rapat dan Pesta.
Jika Pesta adalah jenis Rapat khusus, UI untuk membuatnya harus
serupa atau identik, jadi setelah mempelajari cara membuat salah satunya, pengguna akan melakukannya
sudah tahu cara membuat yang lain. Demikian pula, penjadwalan ulang, pengeditan, penghapusan-
ing, pencetakan, dan fungsi lainnya mungkin memiliki UI yang serupa untuk kedua Rapat
dan Pesta.
Bergantung pada aplikasinya, objek mungkin juga terkait dengan sebagian / keseluruhan
hirarki, di mana beberapa objek adalah bagian dari orang lain, dan penahanan hierar-
cabai, di mana beberapa objek dapat menampung yang lain. Misalnya, heading adalah bagian
dari dokumen, dan album foto berisi foto.
Akhirnya, konsep dalam domain tugas bervariasi dalam kepentingannya : pertemuan pengguna
beberapa lebih sering dari yang lain. Misalnya, rekening giro
lebih umum daripada akun trust, dan mencatat transaksi di cek-
Akun jauh lebih umum daripada membuka akun baru. Rela-
Pentingnya konsep dapat digunakan untuk memfokuskan desain (lihat Dasar

[Link] 26/315
26/2/2021 Tanpa judul
Prinsip 4).
Mendaftar objek dan tindakan model konseptual menurut jenisnya,
bagian / keseluruhan, dan hierarki penahanan, serta kepentingan relatifnya,
sangat memudahkan desain dan pengembangan yang runtut, jelas, mudah dipelajari
antarmuka pengguna.

Kembangkan leksikon

Setelah analisis objek / tindakan, komponen terpenting berikutnya dari a

model konseptual adalah leksikon 2 yang mendefinisikan terminologi yang akan digunakan melalui-
keluar perangkat lunak dan dokumentasinya. Begitu tim sepakat apa masing-masing
konsep yang terlihat pengguna dalam perangkat lunak ini, tim juga harus menyetujui apa
untuk menyebut konsep itu.
Seluruh tim mengembangkan leksikon, tetapi paling baik dikelola dan
diberlakukan oleh penulis teknis tim. Siapapun yang mengelola leksikon
harus terus mencari inkonsistensi dalam hal-hal
dipanggil. Sebagai contoh:

2. Juga terkadang disebut nomenklatur atau kosakata .

Halaman 38

24 Bab 1 Prinsip Pertama

“Yo, Rajiv. Kami menyebutnya 'slot' di kotak dialog ini, tetapi kami menyebutnya 'sel'
di tempat lain. Nama resmi kami untuk mereka adalah 'sel', jadi kami perlu memperbaikinya
inkonsistensi. "

Perangkat lunak yang dikembangkan tanpa leksikon sering kali menderita dari dua pengguna umum
antarmuka "bloopers": (1) beberapa istilah untuk konsep tertentu dan (2) sama
istilah untuk konsep yang berbeda (Blooper 22, halaman 153).
Ini juga merupakan peran manajer leksikon untuk waspada agar dapat dilihat oleh pengguna
konsep dalam perangkat lunak atau dokumentasi yang tidak ada dalam leksikon, dan untuk
tahan mereka. Sebagai contoh:

“Hei Sue, saya melihat bahwa jendela ini mengacu pada 'hyperconnector'. Itu tidak ada di kami
model konseptual atau leksikon. Apakah itu hanya nama yang salah untuk sesuatu yang sudah kita lakukan
ada dalam model konseptual kita, atau apakah itu sesuatu yang baru? Dan jika itu sesuatu
baru, dapatkah kita menyingkirkannya, atau apakah kita benar-benar membutuhkannya? ”

Untuk detail lebih lanjut tentang cara membangun model konseptual, lihat Johnson dan
Henderson [2002]. Kebanyakan panduan gaya standar industri untuk GUI tertentu
platform juga memberikan saran dalam merancang model konseptual.

Tulis skenario tugas

Setelah model konseptual dibuat, pengembang dapat menulis kasus penggunaan

atau skenario tugas yang menggambarkan orang yang menggunakan aplikasi, hanya menggunakan termi-
nologi dari model konseptual. Skenario ini dapat digunakan di produk
dokumentasi, tinjauan fungsional produk, dan skrip uji kegunaan. Untuk
aplikasi buku cek, misalnya, pengembang dapat menulis skenario
seperti:

“John menggunakan program tersebut untuk memeriksa saldo rekening giro miliknya. Dia kemudian menyetor
cek ke rekening dan transfer dana ke rekening koran darinya
rekening tabungan."

Perhatikan bahwa skenario ini merujuk ke objek tugas dan tindakan saja, tidak spesifik
antarmuka pengguna apa pun. Skenario tidak menunjukkan apakah John sedang berinteraksi
dengan GUI di komputer pribadi, antarmuka berbasis pena pada PDA, atau suara-
antarmuka terkontrol melalui telepon.

Mendasarkan desain UI pada model konseptual

Antarmuka pengguna harus didasarkan pada model konseptual. Ini diterjemahkan

konsep abstrak dari model konseptual menjadi presentasi konkret,
kontrol, dan tindakan pengguna. Skenario kemudian dapat ditulis ulang di tingkat
desain antarmuka pengguna. Sebagai contoh:

[Link] 27/315
26/2/2021 Tanpa judul

Halaman 39

Prinsip Dasar 2: Pertimbangkan fungsi dulu, presentasi nanti 25

John mengklik dua kali pada ikon rekening giro untuk membukanya. Akun
ditampilkan, menunjukkan saldo saat ini. Dia kemudian mengklik di kolom entri kosong
di bawah entri terakhir yang tercatat dan masukkan nama dan jumlah cek dia
baru saja diterima. "

Analisis objek / tindakan dapat memulai pengembangan

Jika Anda seorang programmer, Anda mungkin telah memperhatikan kesamaan antara objek /
analisis tindakan dijelaskan di sini dan analisis berorientasi objek yang umum
langkah awal dalam rekayasa perangkat lunak. Meskipun analisis objek / tindakan dibatasi
untuk konsep yang dipahami pengguna , sedangkan analisis berorientasi objek tidak, pengembang
dapat memperlakukan analisis objek / tindakan sebagai desain awal untuk implementasi
model objek dan dapat mulai menerapkannya — bahkan sebelum antarmuka pengguna
ditentukan. Oleh karena itu, mengembangkan model konseptual tidak semata-mata merupakan biaya tambahan
untuk sebuah proyek; itu menghasilkan keluaran yang dapat menghemat biaya selama pengembangan.

Model konseptual memfokuskan proses desain

Karena hampir semua orang di tim pengembangan memiliki kepentingan dalam konseptual
model, berfungsi sebagai titik koordinasi untuk tim. Yang satu ini sangat kuat
implikasi:

■ Perubahan sepihak yang berdampak pada model konseptual sistem tidak

diizinkan.

Misalnya, jika seorang programmer percaya konsep baru perlu ditambahkan

perangkat lunak, pertama-tama dia harus membujuk tim untuk menambahkannya ke konseptual
model; hanya setelah itu seharusnya itu muncul di perangkat lunak. Begitu pula jika seorang dokumenter
merasa perlu untuk memperkenalkan konsep tambahan untuk menjelaskan sistem itu
perubahan harus direfleksikan terlebih dahulu dalam model konseptual resmi (dengan model tim
persetujuan); hanya setelah itu dapat muncul di dokumentasi.
Prosesnya tidak linier. 3 Sebagai hasil desain dari model konseptual ke
antarmuka pengguna untuk implementasi, upaya hilir hampir pasti akan terungkap
masalah dalam model konseptual yang harus diperbaiki. Produk awal dengan fidelitas rendah
totipe dan uji kegunaan ringan dapat mempercepat ini dengan memungkinkan evaluasi
dari model konseptual serta UI.
Tahan godaan untuk memperlakukan dokumen model konseptual sebagai "kuno
sejarah ”setelah UI awal dirancang darinya. Jika Anda tidak menyimpan file
dokumen model konseptual saat ini saat Anda meningkatkan desain, Anda akan menyesal
itu pada akhirnya, saat Anda tidak memiliki satu pun deskripsi tingkat tinggi yang koheren
yang menjadi dasar dokumentasi pengguna, pelatihan, dan peningkatan sistem selanjutnya.

3. Terlebih di era metode pengembangan Agile, yang menempatkan nilai pada yang sangat iteratif
desain-tes siklus.

Halaman 40

26 Bab 1 Prinsip Pertama

Ringkasan: Manfaat mengembangkan model konseptual

Memulai desain dengan merancang model konseptual memiliki beberapa keuntungan:

■ Fokus tugas : Merancang model konseptual memaksa desainer untuk mempertimbangkan

relevansi dengan tugas setiap konsep yang terlihat oleh pengguna dan hubungan
antar objek. Ketika masalah ini telah dipikirkan sebelumnya
UI dirancang, itu akan memetakan secara lebih alami ke tugas pengguna.
■
Konsistensi: Menghitung objek dan tindakan yang didukung aplikasi
tugas memungkinkan Anda untuk memperhatikan tindakan yang dibagikan oleh banyak objek. Desain

[Link] 28/315
26/2/2021 Tanpa judul
kemudian dapat menggunakan antarmuka pengguna yang sama untuk operasi di seluruh objek tersebut. Ini
membuat UI lebih sederhana dan lebih konsisten sehingga lebih mudah dipelajari.
■ Kegunaan: Mencantumkan semua konsep yang terlihat oleh pengguna memungkinkan Anda menilai kerabatnya
pentingnya. Ini berdampak pada desain UI dan prioritas pengembangan.
■
Leksikon: Model konseptual menyediakan leksikon produk, kamus istilah
untuk setiap objek dan tindakan yang terkandung dalam perangkat lunak. Ini memupuk
konsistensi terminologi, tidak hanya dalam perangkat lunak, tetapi juga dalam produk
dokumentasi.
■ Skenario: Model konseptual memungkinkan tim pengembangan untuk menulis tugas-
skenario tingkat domain dari produk yang digunakan. Skenario tersebut berguna dalam
memeriksa kesehatan desain dan juga dalam dokumentasi, secara fungsional
ulasan, dan sebagai skrip untuk uji kegunaan.
■
Kick-start development: Analisis objek / tindakan menyediakan objek awal
model — setidaknya untuk objek yang ditemui pengguna. Pengembang dapat memulai pengkodean
itu bahkan sebelum UI dirancang.
■ Tim fokus dan proses: Model konseptual berfungsi sebagai titik fokus untuk semua
anggota tim pengembangan dan pemangku kepentingan lainnya untuk berdiskusi dan terus menerus
mengevaluasi desain.

Prinsip Dasar 3: Sesuai dengan

pandangan tugas

Antarmuka pengguna perangkat lunak harus dirancang dari sudut pandang pengguna. Kamu
tidak bisa melakukan itu jika Anda tidak tahu apa sudut pandang pengguna. Terbaik
Cara untuk mengetahui sudut pandang pengguna adalah dengan mengikuti Prinsip Dasar 1: berbicara dengan
perwakilan pengguna, mengamati pekerjaan mereka, dan berkolaborasi dengan mereka untuk melakukan
analisis tugas.
Sesuai dengan tampilan pengguna memiliki beberapa prinsip.

Halaman 41

Prinsip Dasar 3: Sesuai dengan pandangan pengguna tentang tugas 27

Upayakan untuk menjadi alami

Analisis tugas memungkinkan Anda melihat apa yang "secara alami" termasuk dalam domain tugas target
dan aktivitas apa yang tidak relevan, artifisial, "tidak wajar".

Jangan membuat pengguna melakukan tindakan tidak wajar

Tindakan tidak wajar adalah langkah yang harus dilakukan pengguna yang tidak memiliki hubungan yang jelas
untuk tujuan mereka. Perangkat lunak yang membuat pengguna melakukan tindakan tidak wajar menyerang mereka sebagai
sewenang-wenang, tidak intuitif, dan amatir, karena tindakan yang tidak wajar sulit dilakukan
belajar, mudah lupa, memakan waktu, dan mengganggu. Terlalu banyak aplikasi perangkat lunak
kation memaksa pengguna untuk melakukan tindakan yang tidak wajar (Gambar 1.3).

Contoh: Bermain catur

Sebagai contoh bagaimana melakukan analisis tugas dapat membantu memperjelas tindakan apa
wajar, pertimbangkan permainan catur. Tindakan penting dalam bermain catur
sedang memindahkan bidak catur ke posisi papan baru. Untuk memindahkan sepotong, apa yang harus dilakukan
ditentukan? Pikirkan tentang ini selama beberapa detik. Jawab pertanyaan di
pikiran sendiri dulu, lalu baca terus.
Memindahkan bidak dalam permainan catur membutuhkan indikasi: (a) bidak mana yang akan menjadi
dipindahkan dan (b) ke mana harus dipindahkan. Saya tidak berbicara tentang antarmuka pengguna

Gambar 1.3

[Link] 29/315
26/2/2021 Tanpa judul

Memaksa pengguna melakukan tindakan tidak wajar.

Halaman 42

28 Bab 1 Prinsip Pertama

dari program catur. Saya sedang berbicara tentang tugas bermain catur, entah itu
dimainkan di komputer, di papan catur kayu, melalui surat, atau melalui Internet.
Dimanapun, kapanpun, dan bagaimanapun catur dimainkan, memindahkan bidak membutuhkan
menentukan bagian yang akan dipindahkan dan ke mana harus dipindahkan.
Sekarang, mari kita pertimbangkan program catur komputer. Jika program catur membutuhkan
pengguna untuk menentukan apa pun selain bagian yang akan dipindahkan dan tujuan
persegi, itu membutuhkan tindakan yang tidak wajar. Jenis tindakan tidak wajar apa yang mungkin a
program catur komputer membutuhkan? Berikut ini beberapa:

■
Beralih ke mode Pindah: Perangkat lunak mungkin memiliki mode untuk menentukan
bergerak dan mode untuk mengetik pesan ke pemain lain. Jika perangkat lunak
selalu dalam salah satu mode ini, pengguna akan sering lupa untuk beralih mode dan
akan mengetik gerakan saat dalam mode Pesan atau mengetik pesan saat masuk
Mode bergerak. (Untuk lebih lanjut tentang mode, lihat Blooper 48, halaman 269.)
■
Menetapkan nama pindah: Mungkin perangkat lunak mengharuskan pengguna untuk memberi nama masing-masing
pindahkan sehingga ada cara untuk merujuknya kembali nanti.
■
Menyatakan alasan pindah: Mungkin perangkat lunak meminta pengguna untuk merekam alasan mereka.
son untuk setiap gerakan, untuk memberikan catatan yang dapat digunakan di postmortem nanti
analisis hasil.
■
Menentukan untuk game mana langkah ini: Mungkin perangkat lunak mendukung permainan-
membuat banyak game sekaligus. Selain itu, pengguna harus mengidentifikasi game tersebut
potongan dan tujuan.

Memindahkan bidak catur seharusnya merupakan operasi yang sederhana, tetapi perangkat lunak dapat dengan mudah
memperumitnya dengan menambahkan langkah ekstra yang tidak wajar. Analisis serupa dapat dilakukan
dibentuk untuk operasi lain yang disediakan oleh program catur. Idealnya adalah untuk
semua operasi dalam program harus sebebas mungkin dari tindakan yang asing
untuk bermain catur.
Sebagai contoh lain, aplikasi manajemen foto akan
dengan kemampuan menyediakan setidaknya operasi berikut: mengunduh foto dari kamera,
meninjau inventaris foto, menampilkan foto, menghapus foto, membuat album foto, menyalin
foto ke dalam album. Operasi ini dapat dianalisis untuk menentukan apa yang mereka lakukan
Masukan "alami" adalah. Perancang perangkat lunak harus melakukan analisis ini pada semua
operasi penting dari setiap aplikasi yang mereka desain.

Menerapkan batasan sewenang-wenang

Cara lain di mana perangkat lunak dapat melanggar rasa kealamian pengguna dan
intuisi adalah dengan memberlakukan pembatasan yang sewenang-wenang atau tampaknya sewenang-wenang
pengguna. Contoh pembatasan tersebut meliputi:

■
membatasi nama orang hingga 16 karakter;
■
memungkinkan baris tabel diurutkan berdasarkan paling banyak tiga kolom;

Halaman 43

[Link] 30/315
26/2/2021 Tanpa judul

Prinsip Dasar 3: Sesuai dengan pandangan pengguna tentang tugas 29

■
menyediakan Urungkan hanya untuk tiga tindakan terakhir;
■
membutuhkan nomor fax di semua entri buku alamat meskipun beberapa pengguna
tidak memiliki mesin faks.

Pembatasan sewenang-wenang, seperti tindakan tidak wajar, sulit dipelajari, mudah dilupakan,
dan mengganggu. Produk dengan banyak batasan sewenang-wenang tidak akan memiliki banyak
pengguna yang puas. Jelas, batasan ukuran dan panjang lebih mengganggu
lebih banyak orang bertemu mereka. Jika batasnya begitu besar sehingga pengguna tidak pernah menemukannya,
itu sebenarnya bukan masalah. Untuk contoh blooper yang melibatkan pembatasan sewenang-wenang,
lihat Blooper 41, halaman 242.

Gunakan kosakata pengguna, bukan kosakata Anda sendiri

Aplikasi perangkat lunak terkenal karena penuh dengan technobabble: jargon that
insinyur komputer mengerti tetapi kebanyakan pengguna tidak. Bahkan saat istilah dalam
perangkat lunak komputer berasal dari kosa kata standar pengguna, istilahnya sering
didefinisikan ulang untuk memiliki arti teknis tertentu; pengguna tidak memahami ini
antara. Technobabble yang berlebihan adalah salah satu rasa malu abadi
industri (Gambar 1.4). Untuk lebih lanjut tentang masalah ini, lihat Blooper 26, halaman 173.
Saat menulis teks untuk perangkat lunak atau dokumentasinya, hindari komputer
jargon. Seperti yang dijelaskan dalam Prinsip Dasar 3, Anda harus membuat leksikon proyek.
Leksikon harus memberi nama setiap konsep (objek, tindakan, atau atribut) yang pengguna
bisa ditemui. Istilah dalam leksikon harus sesuai dengan istilah konvensional.
minologi dari domain tugas. Setelah leksikon dikembangkan, masukkan teks ke dalam
perangkat lunak atau dokumentasi harus benar-benar sesuai dengannya.

Gambar 1.4

Mengekspos pengguna pada technobabble.

Halaman 44

30 Bab 1 Prinsip Pertama

Simpan program internal di dalam program

Pengguna perangkat lunak tidak tertarik dengan cara kerja perangkat lunak. Mereka hanya ingin
untuk mencapai tujuan mereka. Rincian cara kerja internal perangkat lunak harus ada-
kedepan tetap internal — tidak terlihat dan di luar pikiran pengguna. Ini terdengar
wajar, tetapi sebenarnya mengekspos perangkat lunak internal kepada pengguna adalah hal yang sangat umum
blooper antarmuka pengguna (Blooper 40, halaman 241).
Sekarang Anda tahu bahwa Anda harus mengembangkan model konseptual sebelumnya
merancang antarmuka pengguna. Model konseptual menunjukkan konsep yang mana
mengekspos pengguna. Antarmuka pengguna suatu aplikasi harus mewakili hanya konteks
konsep yang diperlukan untuk mendukung tugas yang dimaksudkan. Sembunyikan semua konsep lainnya,
termasuk konsep teknologi komputer umum dan yang hanya berkaitan dengan
pelaksanaan.

Temukan titik yang benar pada kekuatan / kompleksitas

trade-off
[Link] 31/315
26/2/2021 Tanpa judul

Biasanya ada trade-off antara daya dan kegunaan. Setiap fitur, fungsi
tion, atau kemampuan dalam aplikasi membutuhkan cara bagi pengguna untuk dipanggil atau dikendalikan
saya t. Sayangnya, industri kami terlalu memperhatikan daftar fitur yang panjang
dan tidak cukup untuk harga yang harus dibayar untuk kekuasaan.
Pengembang perangkat lunak cenderung percaya "semakin banyak pilihan, semakin banyak kontrol,
semakin banyak tenaga, semakin baik ”(Gambar 1.5). Sebaliknya, kebanyakan orang yang menggunakan
perangkat lunak komputer hanya menginginkan fungsionalitas yang cukup untuk mencapai tujuan mereka — tidak
lebih, tidak kurang. Kebanyakan orang belajar menggunakan hanya sedikit dari fitur perangkat lunak
aplikasi dan abaikan sisanya. Beberapa fitur diabaikan karena terlalu banyak
rumit untuk dipelajari. Terkadang kendala bukanlah kerumitannya
dari fitur tertentu, melainkan kuantitas hal-hal yang harus dipelajari. Belaka
Kehadiran fitur yang kurang penting dapat mengurangi kemungkinan fitur yang lebih penting
untuk dipelajari dan digunakan.
Masalah yang Anda hadapi sebagai pengembang perangkat lunak adalah menemukan titik optimal
dalam pertukaran antara kekuatan dan kompleksitas. Untuk melakukan itu, Anda harus berbicara dengan
dan mengamati perwakilan pengguna, bahkan mungkin membawa beberapa ke tim Anda.
Jika tidak, Anda hanya menebak-nebak.
Setelah Anda mengetahui seberapa banyak fungsionalitas yang dibutuhkan pengguna, Anda juga dapat menggunakannya
atau lebih dari teknik desain berikut untuk mengurangi kompleksitas:

■ Default yang masuk akal: Pastikan bahwa setiap pengaturan dalam aplikasi memiliki file
nilai default. Pengguna harus dapat meninggalkan semua atau sebagian besar pengaturan di
nilai default mereka dan masih mendapatkan hasil yang wajar. Ini memungkinkan pengguna untuk
mengabaikan sebagian besar pengaturan di sebagian besar waktu.
■
Template atau solusi kalengan: Alih-alih membuat pengguna memulai setiap tugas
dari awal, berikan solusi parsial atau lengkap bagi pengguna untuk memulai

Halaman 45

Prinsip Dasar 3: Sesuai dengan pandangan pengguna tentang tugas 31

Gambar 1.5

Aplikasi perangkat lunak yang mencoba melakukan segalanya.

dan memodifikasi jika perlu untuk memenuhi tujuan spesifik mereka. Pendekatan ini memungkinkan
pengguna untuk melewati sebagian besar fungsionalitas perangkat lunak. Mereka bisa berguna
hasil tanpa mengetahui bagaimana menghasilkan hasil dari awal.
■
Guided paths – wizards: Pengguna baru sering kali mencari seseorang untuk memandu mereka
langkah-langkah tugas kompleks. Aplikasi dapat menyediakan ini dengan menawarkan
“Wizards”: urutan standar yang memandu pengguna langkah demi langkah
proses yang rumit, dengan instruksi yang jelas dan pilihan yang ditentukan terutama
melalui menu, bukan bidang teks. Selama pengguna menginginkan salah satu dari
penyihir menghasilkan, penyihir adalah cara yang bagus untuk mengurangi kerumitan.
■ Pengungkapan progresif: Sembunyikan detail dan kompleksitas hingga pengguna membutuhkannya.
Nonaktifkan kontrol dan sembunyikan menu bar 4 hingga relevan. Menyembunyikan
pengaturan yang jarang digunakan, atau kontrol yang membutuhkan pengetahuan lanjutan tentang
perangkat lunak, di bawah panel berlabel "Detail" atau "Lanjutan". Tetapkan nama untuk
kombinasi pengaturan, memungkinkan pengguna untuk bekerja dengan kombina-
tions alih-alih semua pengaturan individu. Misalnya, gaya paragraf dalam

[Link] 32/315
26/2/2021 Tanpa judul
editor dokumen memungkinkan pengguna untuk menentukan koleksi properti pemformatan
untuk menerapkan sekaligus ke paragraf teks.

4. Catatan: Sembunyikan menu, bukan item menu. Item menu yang menghilang adalah kesalahan (Blooper 8, halaman 89).

Halaman 46

32 Bab 1 Prinsip Pertama

■
Perintah umum: Gunakan sekumpulan kecil perintah untuk memanipulasi semua jenis
data. Sekumpulan perintah umum yang dipilih dengan cermat, dipetakan ke semua file
jenis data dalam suatu aplikasi, dapat mengurangi jumlah perintah yang dibutuhkan.
Sebagian besar dari apa yang dilakukan orang dengan komputer dapat diekspresikan dalam istilah ini
sembilan perintah umum: Buat, Buka, Pindahkan, Salin, Simpan, Hapus, Cetak, Tampilkan /
Edit Properti, dan Ikuti Tautan. Seperti yang dijelaskan dalam Prinsip Dasar 2, dimulai oleh
mengembangkan model konseptual dapat menunjukkan tindakan mana yang umum dilakukan
objek dan oleh karena itu dapat disediakan melalui perintah umum.
■
Desain khusus tugas : Mendukung serangkaian kecil tugas dengan sangat baik. Alih-alih menawarkan-
Pengguna program kaya fitur besar yang mencoba untuk mendukung berbagai macam
tugas, menawarkan mereka kumpulan program khusus kecil, masing-masing
mendukung satu tugas dengan sangat baik. Misalnya, alih-alih mengembangkan dosa-
gle editor dokumen umum yang dapat digunakan untuk membuat segala sesuatu dari
lirik lagu dan daftar tugas untuk laporan keuangan perusahaan dan presentasi slide-
tions, kembangkan beberapa editor sederhana khusus tugas. Pendekatan ini telah
berhasil digunakan untuk peralatan dan peralatan rumah tangga, termasuk informasi
peralatan tion. Ini lebih berhasil ketika aplikasi khusus tugas dan
peralatan dapat berbagi informasi. Untuk pembahasan lebih lengkap tentang
keuntungan dan kerugian dari aplikasi perangkat lunak khusus tugas, lihat
Nardi dan Johnson [1994] dan Johnson dan Nardi [1996].
■
Kemampuan Penyesuaian: Buat UI dapat disesuaikan, sehingga pelanggan dapat menyesuaikannya
tekankan fungsionalitas yang akan mereka gunakan dan kurangi atau sembunyikan sisanya.
Izinkan pengguna — atau pengembang lokal yang bertindak untuk pengguna — untuk menyetel default, tentukan
makro, buat template, dan sesuaikan perangkat lunak untuk mereka
persyaratan khusus. Misalnya, pengguna di perusahaan mungkin hanya membutuhkan 10
dari 50 kemungkinan tombol toolbar, sehingga sisanya dapat dihapus (dan dibiarkan sebagai menu
perintah). Namun, kemampuan penyesuaian berisiko: ia mencoba mentransfer beberapa file
tanggung jawab untuk menyederhanakan UI bagi pengguna. Upaya itu mungkin gagal: pengguna mungkin
tidak ingin melakukan itu. Bahkan ketika penyesuaian berhasil, jarang terjadi karena
pengguna merangkul dan memanfaatkannya. Sebagian besar pengguna mengabaikan kemampuan penyesuaian sepenuhnya.
Sebaliknya, biasanya karena pengecer nilai tambah, administrator sistem lokal,
atau beberapa power user menyesuaikan sistem untuk orang lain.

Prinsip Dasar 4: Desain untuk kasus umum

Di domain tugas apa pun, pengguna akan memiliki tujuan mulai dari yang umum hingga yang jarang. Rancangan
aplikasi Anda untuk mengenali rentang ini.

Buat hasil yang umum mudah dicapai

Jika tujuan pengguna dapat diprediksi dan umum, pengguna tidak perlu melakukan banyak hal
untuk mencapainya. Tujuan yang tidak biasa mungkin membutuhkan lebih banyak usaha untuk mencapainya. Dinyatakan lebih banyak

Halaman 47

Prinsip Dasar 4: Desain untuk kasus umum 33

formal: Jumlah yang harus ditentukan pengguna untuk mencapai yang diinginkan

[Link] 33/315
26/2/2021 Tanpa judul
hasil tidak dengan
sebanding boleh proporsional dengan
seberapa besar hasilkompleksitas hasil.
yang diinginkan Harus
menyimpang dari yang umum.
Jika seorang pria pergi ke restoran setiap hari untuk makan malam dan selalu memesan
hal yang sama, dia hanya bisa berkata, "Aku akan melakukan yang biasa." Mungkin dia biasanya memiliki file
daging panggang. Mungkin dia biasanya memiliki bayam layu dan salad endive Belgia di atasnya
dengan kari ayam kampung, keju kambing, kenari organik, dan kemangi – arti-
tersedak – saus mustard. Terlepas dari apakah makan malam biasanya sederhana atau
rumit, dia tinggal memesan "yang biasa". Jika pada hari tertentu dia menginginkan file
sedikit perubahan dari makanan biasanya, dia dapat menentukannya sebagai perubahan, misalnya,
"Aku akan mendapatkan yang biasa dengan saus di sampingnya." Namun, jika dia memutuskan untuk melakukannya
memesan sesuatu yang tidak biasa, dia harus memberi tahu pelayan item menu apa
dia menginginkan dan menunjukkan pilihannya untuk semua opsinya.
Kembali sekarang ke perangkat lunak komputer, misalkan seseorang sedang mempersiapkan file
presentasi dan keinginan slide yang berisi teks poin-poin dan bisnis sederhana
grafis, semuanya sesuai dengan format standar perusahaan. Persiapan slide-
Program tion harus membuatnya mudah — cukup tancapkan konten dan slide
selesai. Namun, ini mungkin membutuhkan pekerjaan yang signifikan — termasuk bantuan dari grafik
seniman — untuk menyiapkan presentasi yang berisi bagan yang mewah dan tidak biasa, larut,
animasi, atau efek visual lainnya atau yang menyimpang dari perusahaan
format standar.
Ada empat cara untuk mempermudah tugas umum. Semuanya disebutkan
di bawah Prinsip Dasar 3 sebagai cara untuk mengurangi kompleksitas UI: default yang masuk akal,
katalog template atau solusi "kalengan", panduan, dan kemampuan penyesuaian.
Intinya adalah bahwa pengguna harus bisa mendapatkan banyak tanpa menentukan
banyak. Lakukan sedikit; mendapatkan banyak. Itulah yang diinginkan pengguna.

Dua jenis "umum": "berapa banyak pengguna?" vs.

"seberapa sering?"

Sistem interaktif biasanya menawarkan banyak fitur — berbagai hal yang dapat dilakukan pengguna
melakukan. Saat mendesain antarmuka pengguna untuk suatu fitur, masuk akal untuk mempertimbangkan
tentang seberapa umum fitur tersebut digunakan. UI untuk yang sangat umum digunakan
fitur akan dirancang berbeda dari fitur yang jarang digunakan.
Tetapi apa arti "umum" untuk fitur perangkat lunak? Ini bisa berarti:

■
Berapa banyak pengguna yang membutuhkan fitur tersebut? Apakah akan digunakan oleh semua atau hampir semua
pengguna, mayoritas, minoritas signifikan, atau hampir tidak ada?
■
Seberapa sering pengguna membutuhkan fitur tersebut? Akankah orang-orang yang membutuhkan fitur tersebut
menggunakannya setiap beberapa detik, menit, jam, hari, minggu, bulan, atau tahun?

UI yang optimal untuk fitur bergantung pada kedua faktor: berapa banyak pengguna yang membutuhkannya
dan seberapa sering mereka membutuhkannya. Prinsip desain ini dijelaskan sepenuhnya oleh Isaacs

Halaman 48

34 Bab 1 Prinsip Pertama

dan Walendowski [2001], Bab 6. Demi kenyamanan, saya akan meringkas

aturan desain.

Semakin sering suatu fitur digunakan, file

lebih sedikit klik yang diperlukan

Fitur yang digunakan pengguna berulang kali dalam interval waktu yang singkat seharusnya tidak diperlukan
banyak masukan pengguna untuk dipanggil dan dikontrol. Mereka harus membutuhkan sangat sedikit kunci-
stroke dan klik. Beberapa fitur dibutuhkan begitu sering sehingga seharusnya
tidak membutuhkan klik. Misalnya, untuk memeriksa waktu saat menggunakan PC Anda, Anda
jangan klik apapun; Anda hanya perlu melihat tampilan jam. Sebaliknya, pengguna menolak
Hapus lebih banyak klik dan penekanan tombol untuk fitur yang lebih jarang mereka gunakan. Untuk
fitur yang digunakan orang sekali atau dua kali setahun — misalnya, mengatur instalasi atau
opsi figuration — meminimalkan penekanan tombol sama sekali tidak relevan dibandingkan
untuk memudahkan mengingat dan kejelasan instruksi.

Semakin banyak pengguna menggunakan fitur, semakin terlihat fitur tersebut

Semakin besar persentase pengguna yang membutuhkan suatu fungsi, semakin terlihat
dan harus menonjol untuk memastikan bahwa setiap orang menemukannya. Jika semua pengguna akan menggunakan
sebuah fitur, tidak masalah untuk mengambil ruang layar; itu harus tepat di depan.
Tindakan yang hanya dibutuhkan oleh sedikit pengguna bisa jadi kurang menonjol — mungkin hanya diisyaratkan di
UI; bahkan mungkin tersembunyi, misalnya, di balik sakelar "Advanced", fungsi khusus

[Link] 34/315
26/2/2021 Tanpa judul
tombol, atau kombinasi tombol.

Kombinasi: sering oleh banyak, sering oleh sedikit,

jarang oleh banyak orang, jarang oleh sedikit

Masalah desain yang menarik muncul ketika dua dimensi "kesamaan" itu
dipertimbangkan bersama. Untuk mempermudah, kami membagi setiap dimensi menjadi hanya dua
level: tinggi dan rendah. Bagaimana seseorang mendesain UI untuk fitur yang sering digunakan
oleh sebagian besar pengguna? Bagaimana jika dibandingkan dengan UI untuk fitur yang jarang digunakan
oleh sebagian besar pengguna, seringkali oleh sedikit pengguna, atau jarang oleh beberapa pengguna? Kita dapat membangun file
Matriks 2x2 yang memberikan pedoman desain untuk keempat kasus (Tabel 1.1).

Desain untuk kasus inti; jangan khawatirkan kasus "tepi"

Sel matriks yang “jarang oleh sedikit” mungkin tidak sepadan dengan membuang banyak upaya desain
di. Alan Cooper [1999] dengan tepat menyatakan hal itu. Dia menunjukkan bahwa programmer adalah
terlatih untuk menangani semua kasus yang dapat timbul dalam sistem perangkat lunak dan sering menghabiskan
banyak sekali waktu dan upaya merancang GUI yang mencakup kasus probabilitas rendah
serta probabilitas yang lebih tinggi. Itu, kata Cooper, merusak kegunaan dalam dua cara:

Halaman 49

Prinsip Dasar 5: Jangan mengalihkan pengguna dari tujuan mereka 35

Tabel 1.1 Karakteristik UI yang diinginkan untuk fitur bergantung pada frekuensi penggunaan dan jumlah pengguna

Lebih terlihat ↔ Kurang terlihat

Lebih sedikit klik Oleh sebagian besar Oleh sedikit

Sering Sangat terlihat; Hampir tidak terlihat;

↔ beberapa klik beberapa klik
Jarang Hampir tidak terlihat; Tersembunyi;
Lebih banyak klik lebih banyak klik OK lebih banyak klik

■ Dibutuhkan waktu pengembangan dan sumber daya untuk mendesain UI yang baik
kasus umum.
■
Ini membebani seluruh UI dengan harus mencakup kasus "edge" serta kompromi
mon yang.

Cooper merekomendasikan perancangan UI untuk mengoptimalkan kasus umum (untuk keduanya

definisi umum) dan kurang lebih mengabaikan ketidakmungkinan atau opsional
kasus. Untuk pengguna langka yang terkadang membutuhkan salah satu fungsi tersebut, file
UI ad hoc dapat diterapkan. Poin utamanya adalah memfokuskan sumber daya pembangunan
tentang fitur-fitur penting. Desainer UI Microsoft setuju:

Skenario inti — alasan utama orang menggunakan… program Anda — sangat jauh
lebih penting daripada skenario pinggiran — hal-hal yang mungkin dilakukan orang, tetapi mungkin
biasa. Paku dasarnya! (Dan jika Anda melakukannya, pengguna akan mengabaikan masalah pinggiran.) -
Pengalaman Pengguna Windows Vista [Microsoft Corporation, 2006]

Prinsip Dasar 5: Jangan ganggu pengguna

dari tujuan mereka

Pikiran manusia sangat pandai multitasking. Kami sering melakukan banyak tugas sekaligus,
Misalnya, berbicara di telepon sambil mengocok telur sambil berjaga-jaga
pada anak kami, sambil mengetuk satu kaki ke lagu yang kami dengar di radio sebelumnya
pagi ini.
Namun, kemampuan kami untuk melakukan banyak tugas terbatas terutama pada aktivitas yang ada
dipelajari dengan baik atau berdasarkan keterampilan persepsi dan motorik. Salah satu cara untuk mengkategorikan
aktivitas yang bisa kita multitugas adalah "hal yang sudah kita ketahui cara melakukannya". Di
Sebaliknya, mencari solusi untuk masalah baru adalah aktivitas yang manusiawi
pikiran tidak dapat melakukan banyak tugas secara efektif. Pemecahan masalah — hal-hal yang belum kami miliki
tahu bagaimana melakukannya — membutuhkan konsentrasi dan perhatian terfokus. Kami cantik
terbatas pada menyelesaikan satu masalah baru pada satu waktu.

[Link] 35/315
26/2/2021 Tanpa judul

Halaman 50

36 Bab 1 Prinsip Pertama

Sistem perangkat lunak tidak boleh mengalihkan pengguna dari tugas dan tujuan mereka sendiri.
Jangan membuat orang secara aktif memikirkan perangkat lunak yang mereka gunakan. Pengoperasian
perangkat lunak harus berada di latar belakang, bukan di latar depan, dari konteks pengguna.
sciousness. Antarmuka pengguna yang memaksa pengguna untuk berhenti memikirkan milik mereka sendiri
tujuan dan pikirkan tentang UI adalah kegagalan desain. Pedoman desain ini dinyatakan
baik dalam judul dan isi buku desain Web Steve Krug, Don't Make Me
Pikirkan [Krug, 2005]. Ini berlaku untuk aplikasi dan informasi desktop
peralatan seperti pada situs Web.
Kerusakan yang terjadi saat perangkat lunak mengalihkan perhatian pengguna dari tujuan utama mereka
lebih dari sekadar mengonsumsi bandwidth mental. Itu juga menarik pikiran pengguna
keluar dari konteks tugas awal, mengubahnya menjadi "mengoperasikan program"
konteks. Setelah pengguna memecahkan masalah perangkat lunak, merekonstruksi mental
konteks tugas awal dapat memakan waktu lama.

Jangan memberi pengguna masalah tambahan

Orang-orang memiliki banyak masalah mereka sendiri dalam domain pekerjaan mereka
hobi, dan kehidupan pribadi mereka. Itu sebagian mengapa mereka menggunakan produk komputer.
produk dan layanan: untuk membantu mereka memecahkan masalah tersebut dan mencapai tujuan mereka.
Mereka tidak perlu atau ingin dialihkan dari masalah dan tujuan tersebut
masalah ekstra yang disebabkan oleh produk dan layanan komputer. Sebagai contoh:

■
Seorang siswa ingin memasang gambar di situs webnya, tetapi gambar itu ada di TIFF
format daripada format grafis GIF atau JPEG yang diperlukan. Grafisnya
perangkat lunak tidak akan mengubah gambar dari TIFF ke GIF atau JPEG; itu hanya akan mengkonversi
dari format BMP ke GIF. Dia terjebak.
■
Seorang guru mencoba mencari fakta tentang pemerintahan negara bagian lain. Dia menunjuk
browser Web-nya ke situs Web resmi negara, tetapi ia mengatakan bahwa
situs membutuhkan browser yang berbeda dari yang dia miliki. Ini menyediakan tautan ke
unduh browser yang diperlukan, tetapi browser yang disediakan ada incompat-
ible dengan komputernya. Dia mulai bertanya-tanya apakah dia benar-benar membutuhkan fakta-fakta itu.

Perangkat lunak harus membiarkan pengguna memusatkan perhatian mereka pada masalah mereka sendiri dan
tujuan, apa pun itu: menganalisis data keuangan, mencari prospek pekerjaan
di Web, melacak ulang tahun teman, melihat liburan kerabat
foto, dan sebagainya. Perangkat lunak harus mendukung pemecahan masalah dalam tugas sasaran
domain, tetapi harus meminimalkan atau menghilangkan kebutuhan pengguna untuk menghabiskan waktu
pemecahan masalah dalam domain teknologi komputer .

Jangan membuat alasan pengguna dengan eliminasi

Meminimalkan kebutuhan untuk memecahkan masalah dalam domain teknologi komputer

ogy termasuk tidak mengharuskan pengguna untuk mencari tahu bagaimana perangkat lunak bekerja dengan suatu proses

Halaman 51

Prinsip Dasar 6: Memfasilitasi pembelajaran 37

eliminasi. Pengguna tidak harus melalui proses berpikir seperti

pengikut:

■
“Saya ingin nomor halaman dalam dokumen ini dimulai dari 23, bukan 1, tapi
Saya tidak melihat perintah untuk melakukan itu. Saya sudah mencoba pengaturan Page Setup, yaitu
Pengaturan Tata Letak Dokumen, dan perintah Lihat Header dan Footer,
tapi tidak ada. Yang tersisa hanyalah perintah Sisipkan Nomor Halaman ini. Tapi
Saya tidak ingin memasukkan nomor halaman: dokumen sudah memiliki nomor halaman-
bers. Saya hanya ingin mengubah nomor awal. Baiklah, saya akan mencoba Sisipkan Halaman

[Link] 36/315
26/2/2021 Tanpa judul
Angka karena itu satu-satunya yang belum saya coba. "
■
"Hmmm. Kotak centang ini berlabel 'Sejajarkan ikon secara horizontal'. Aku penasaran apa
terjadi jika saya tidak mencentangnya. Akankah ikon saya disejajarkan secara vertikal, atau akankah mereka
tidak sejajar? ”
■
“Layanan perbankan online ini meminta saya untuk 'PIN'. Tapi kartu yang mereka kirim
saya memiliki 'kata sandi'. Saya ingin tahu apakah itu saja? Mereka belum mengirimi saya apa pun
disebut 'PIN'. ”

Fungsi kontrol, perintah, dan pengaturan dalam antarmuka pengguna harus

jelas dan jelas. Mencari tahu bagaimana menggunakan perangkat lunak seharusnya tidak membutuhkan alasan-
ing dengan eliminasi.

Prinsip Dasar 6: Memfasilitasi pembelajaran

Keluhan umum tentang aplikasi perangkat lunak adalah sulit untuk dipelajari.
Belajar membutuhkan waktu; semakin banyak yang harus dipelajari pengguna untuk menggunakan suatu produk
atau layanan, semakin lama waktu sebelum pengguna tersebut dapat produktif. Waktu adalah
uang. Selanjutnya jika pengguna tidak dituntut untuk belajar menggunakan suatu aplikasi
(misalnya, karena pekerjaan mereka), mereka mungkin tidak peduli. Antarmuka pengguna harus
oleh karena itu dirancang untuk memfasilitasi pembelajaran. Antarmuka pengguna suatu aplikasi
dapat memfasilitasi pembelajaran dengan beberapa cara berbeda.

Pikirkan "di luar ke dalam", bukan "dari dalam ke luar"

Pengembang perangkat lunak sering merancang seolah-olah mereka berasumsi bahwa pengguna akan mengotomatiskan
tahu benar apa yang diinginkan pengembang. Ini adalah pemikiran luar dalam. Saat mengembangkan-
opers merancang perangkat lunak, mereka tahu cara kerjanya, informasi apa yang ditampilkan
di tempat apa dan kapan, apa arti semua yang ada di layar, dan bagaimana caranya
informasi yang ditampilkan oleh perangkat lunak terkait. Kebanyakan desainer berpikir dari dalam ke luar:
mereka menggunakan pengetahuan mereka sendiri tentang perangkat lunak untuk menilai apakah tampilan dan
kontrol masuk akal. Mereka berasumsi bahwa pengguna memahami dan memahami segalanya
cara desainer menginginkannya untuk dipahami dan dipahami.

Halaman 52

38 Bab 1 Prinsip Pertama

Masalahnya adalah, pengguna tidak tahu apa yang diketahui desainer tentang perangkat lunak
ware. Ketika orang pertama kali mulai menggunakan produk perangkat lunak, mereka hanya tahu sedikit
tentang cara kerjanya atau apa arti semua hal di layar itu.
Mereka tidak tahu niat sang desainer. Semua mereka harus mendasarkan di bawah
berdiri di atas adalah apa yang mereka lihat di layar dan, mungkin, apa yang mereka baca di layar
dokumentasi perangkat lunak.

Contoh: ambiguitas tekstual

Berpikir dari dalam ke luar adalah masalah yang tidak terbatas pada pengembang perangkat lunak.
Penulis berita utama surat kabar terkadang melakukan kesalahan yang sama saat gagal
untuk memperhatikan bahwa judul yang mereka tulis memiliki interpretasi selain yang satu
mereka bermaksud. Beberapa contoh:
Massa Bergegas untuk Melihat Paus Menginjak-injak 6 hingga Mati

Mabuk Mendapat Sembilan Bulan dalam Kasus Biola

Pita Merah Menahan Jembatan

Perawat Membantu Korban Gigitan Anjing

Vaksin Baru Mungkin Mengandung Ebola

Dua Kapal Bertabrakan, Satu Mati

Bill Petani Meninggal di Rumah

Contoh: Label tombol ambigu

Gambar 1.6 Contoh terkenal ambiguitas tekstual dalam sistem komputer — dan luar dalam
yang dipikirkan oleh para desainer — adalah workstation LISP, sekitar tahun 1985, yang memiliki kunci
keyboardnya berlabel "Lakukan", seperti dalam "lakukan". Kunci itu diberi label sans serif
font, di mana karakter huruf "L" dan huruf besar "I" tampak sama (Gambar
Kunci ambigu 1.6). Para perancang keyboard ini rupanya berasumsi bahwa pengguna akan membaca
label: "Lakukan" atau label seperti yang diinginkan, tetapi dapat diprediksi, beberapa pengguna membacanya sebagai "Dolt" dan tidak akan

[Link] 37/315
26/2/2021 Tanpa judul
"Orang tolol"? bingung mengapa ada orang yang menekan tombol itu.
Gambar 1.7
Contoh: Ambiguitas grafis

Desainer grafis berpikir luar dalam jika mereka menganggap itu sebagai ikon
digambar akan "secara alami" menyampaikan makna yang dimaksudkan kepada pengguna. Desainer di
salah satu perusahaan klien saya terkejut ketika pengujian kegunaan menunjukkan hal itu
sebagian besar peserta tes mengira simbol antena untuk fungsi Transmit adalah
gelas martini dengan tongkat swizzle di dalamnya (Gambar 1.7).
Demikian pula, seorang kolega memberi tahu saya: “Ada ikon di Lotus Notes yang dimiliki semua orang
Grafis
kemenduaan:
di perusahaan saya mengacu pada 'the lollipop.' ”Sebuah studi kasus desainer salah
antena atau sangat mengharapkan pengguna untuk langsung mengenali dan memahami ikon yang dibuat untuk a
gelas martini? permainan komputer dijelaskan oleh Johnson [1998].

Halaman 53

Prinsip Dasar 6: Memfasilitasi pembelajaran 39

Cara yang tepat untuk mendesain: Berpikirlah dari luar ke dalam

Berpikir di luar saat mendesain UI berarti memastikannya masuk akal

orang yang tidak tahu semua yang Anda ketahui tentang itu. Ini tidak berarti kamu
harus menganggap pengguna itu bodoh. Mereka mungkin tahu lebih banyak daripada yang Anda ketahui
tugas perangkat lunak yang didukung. Yang tidak diketahui pengguna adalah niat Anda . Mereka
tidak tahu arti yang dimaksudkan dari berbagai bagian layar. Mereka
tidak tahu apa yang tergantung pada apa.
Jika pengguna yang Anda tuju salah memahami atau salah memahami desain Anda, mereka mungkin
memiliki masalah langsung, tetapi Anda akan memiliki masalah yang lebih serius dan lebih lama
masalah jangka: pengguna yang tidak puas dan penjualan yang berkurang. Karena itu Anda harus membuatnya
yakin UI masuk akal, bukan untuk Anda, tetapi bagi mereka .

Konsistensi, konsistensi, konsistensi

Antarmuka pengguna harus mendorong perkembangan kebiasaan penggunaan . Saat menggunakan inter-
perangkat lunak aktif dan peralatan elektronik, pengguna ingin jatuh pingsan
kebiasaan secepat mungkin. Mereka ingin dapat mengabaikan perangkat lunak atau
perangkat dan fokus pada pekerjaan mereka. Semakin konsisten perangkat lunaknya, semakin mudah
bagi pengguna yang melakukan itu.

Konsistensi menghindari "gotcha"

Software yang penuh dengan inkonsistensi, bahkan yang kecil sekalipun, memaksa pengguna untuk tetap menyimpannya
memikirkannya, mengurangi perhatian yang dapat mereka curahkan untuk tugas mereka.
Perangkat lunak semacam ini penuh dengan "gotcha": terus-menerus mengatakan kepada pengguna "Aha!
Kena kau! Tetap waspada, buster, atau aku akan getcha lagi. ” Anda harus mencoba untuk mini-
sesuaikan jumlah “gotchas” dengan berjuang untuk antarmuka pengguna tingkat tinggi
konsistensi.
Saat memulai desain, kembangkan model konseptual dan lakukan
objek / analisis tindakan untuk mengekspos operasi yang umum untuk banyak perbedaan
jenis benda yang berbeda. Hal ini memungkinkan desain untuk menggunakan kom-
mands (lihat Prinsip Dasar 3) atau setidaknya menggunakan UI yang sangat mirip untuk yang serupa
tapi fungsinya berbeda. Saat menambahkan fitur baru ke aplikasi, gunakan kembali
antarmuka pengguna dari bagian lain daripada menciptakan yang baru untuk masing-masing
fitur baru.
Alternatifnya adalah menyediakan berbagai cara yang membingungkan
melakukan hal yang kurang lebih sama dalam konteks yang berbeda. Misalnya, pengguna
antarmuka untuk menghapus item seringkali berbeda-beda tergantung pada apa yang akan dihapus
(Gambar 1.8).

Bahaya konsistensi naif

Mendesak pengembang perangkat lunak untuk membuat antarmuka pengguna "konsisten"

agak berisiko: itu bisa merugikan dan juga baik. Mengapa? Karena, terdiri-

Halaman 54

[Link] 38/315
26/2/2021 Tanpa judul

40 Bab 1 Prinsip Pertama

Gambar 1.8

Berbagai perintah Hapus.

ency adalah konsep yang lebih kompleks daripada yang disadari banyak orang. Khususnya,
konsistensi adalah:

■
Sulit untuk didefinisikan: Banyak ahli telah mencoba tetapi tidak berhasil.
■
Multidimensi: Item yang konsisten dalam satu dimensi (misalnya fungsi)
mungkin tidak konsisten di tempat lain (misalnya, lokasi).
■
Tunduk pada interpretasi: Apa yang tampak konsisten bagi satu orang mungkin tampak
tidak konsisten dengan yang lain.

Beberapa desainer juga tidak menyadari bahwa pengguna mungkin melihat sesuatu secara berbeda
atau yakin bahwa mereka dapat menentukan konsistensi bagi pengguna. Beberapa mengherankan
desain yang buruk telah diproduksi atas nama konsistensi. Contoh
termasuk aplikasi perangkat lunak di mana semuanya dikendalikan oleh data-
formulir entri, atau menurut hierarki menu, meskipun bentuk atau menu mungkin
bukan cara terbaik untuk mengontrol semua fungsi. Grudin [1989] bahkan menyarankan
Gest bahwa konsistensi sangat tidak jelas dan mudah disalahgunakan sehingga seharusnya
ditinggalkan sebagai prinsip desain UI.

Konsistensi itu bagus

Konsistensi tentu saja dapat salah diterapkan dalam desain UI, tetapi bukan berarti kami
harus meninggalkan konsep tersebut. Hanya karena kami tidak memiliki definisi formal
konsistensi tidak berarti bahwa konsep tersebut tidak berguna. Jelas ada nilainya
pengguna perangkat lunak, meskipun gagasan mereka tentang apa yang konsisten dan tidak konsisten mungkin tidak
cocok dengan desainer UI. Pengguna mencari konsistensi di sepanjang dimensi
yang relevan bagi mereka. Mereka sangat ingin melepaskan kesadaran mereka
pikiran dari tugas mengendalikan komputer — membebaskannya untuk fokus pada mereka sendiri
masalah — bahwa mereka membuat konsistensi meskipun tidak ada.
Misalnya, pemrogram mungkin membantah: "Ya, sebagian besar item di komputer ini
ter dibuka dengan klik dua kali, tetapi aplikasi ini berbeda karena item
hanya dapat dibuka, tidak dipilih, jadi satu klik akan membukanya. ” Begitu
mereka merancangnya seperti itu, dan pengguna tetap mengklik dua kali untuk membuka item dan juga
secara tidak sengaja membuka item (dengan satu klik) yang tidak dimaksudkan untuk dibuka.

Halaman 55

Prinsip Dasar 6: Memfasilitasi pembelajaran 41

Pengguna komputer dengan senang hati mengerahkan upaya fisik untuk menyimpan upaya mental
mengerjakan tugas mereka sendiri. Misalnya, seorang peserta uji kegunaan pernah berkata,
setelah menyelesaikan tugas:

"Saya sedang terburu-buru jadi saya melakukannya jauh-jauh hari."

Membuat konsistensi berpusat pada pengguna

Alih-alih mengabaikan konsistensi sebagai tujuan desain UI, kita harus membuatnya lebih baik
berpusat pengguna . Saat mewawancarai atau mengamati pengguna, coba tentukan caranya
mereka merasakan konsistensi. Aspek apa dari alat mereka saat ini yang tampak konsisten
dan tidak konsisten dengan mereka?
Uji sketsa atau prototipe lain pada perwakilan pengguna, dan perhatikan
aspek UI yang dianggap tidak konsisten oleh pengguna. Konsistensi pengguna
antarmuka harus dievaluasi tidak berdasarkan seberapa "logis" tampaknya bagi desainer
dan pengembang, melainkan tentang seberapa mudah diprediksi hal itu bagi pengguna .

[Link] 39/315
26/2/2021 Tanpa judul

Sediakan lingkungan berisiko rendah

Orang-orang membuat kesalahan. Aplikasi perangkat lunak yang berisiko untuk digunakan adalah aplikasi yang masuk
yang terlalu mudah bagi pengguna untuk membuat kesalahan, tidak memungkinkan pengguna untuk
memperbaiki kesalahan, atau membuatnya mahal atau memakan waktu lama untuk memperbaiki kesalahan. Orang-orang
tidak akan produktif dalam menggunakannya; mereka akan membuang-buang waktu terlalu banyak
memperbaiki kesalahan. Perangkat lunak semacam itu tidak akan populer.
Yang lebih penting daripada dampak pada waktu adalah dampak pada pembelajaran. SEBUAH
situasi berisiko tinggi, di mana kesalahan mudah dilakukan dan mahal, membuat patah semangat
eksplorasi: orang akan cenderung berpegang pada jalur yang sudah dikenal dan aman. Saat eksplorasi
putus asa, pembelajaran sangat terhambat. Situasi berisiko rendah, di mana
kesalahan sulit dilakukan atau mudah diperbaiki, mengurangi stres dan memberi semangat
eksplorasi, dan karenanya sangat membantu perkembangan pembelajaran. Dalam situasi seperti itu, pengguna tidak
jadi ragu-ragu untuk mencoba jalur baru: “Hmmm, saya bertanya-tanya apa yang . tidak”

Prinsip Dasar 7: Menyampaikan informasi,

bukan hanya data

Komputer menjanjikan sumber informasi, tetapi hanya memberikan banyak data…

kebanyakan tidak berguna. Data bukanlah informasi. Orang mengekstrak informasi dari data.
Jika saya ingin tahu apakah kolega saya ada di kantornya, yang saya inginkan hanyalah satu
sedikit informasi: ya atau tidak, benar atau salah, 1 atau 0. Tetapi saya bisa mendapatkan jawabannya
berbagai cara, yang melibatkan transfer data dalam jumlah yang sangat berbeda.
Saya bisa:

Halaman 56

42 Bab 1 Prinsip Pertama

■
mengiriminya email dan menunggu untuk melihat apakah dia membalas (beberapa ratus byte,
termasuk header email),
■
hubungi dia di telepon dan dengarkan apakah dia menjawab (kilobyte audio),
■
kunjungi situs webnya dan lihat gambar dari kamera web di kantornya (mega-
byte), atau
■
ketuk dinding antara kantor kita dan dengarkan apakah dia mengetuk kembali
(Sinyal analog).

Terlepas dari metode yang digunakan dan jumlah data yang ditransfer, saya terima
hanya sedikit informasi, dengan asumsi bahwa yang saya pedulikan adalah apakah Bill ada atau tidak
kantornya.
Aplikasi perangkat lunak sering memperlakukan data seolah-olah itu adalah informasi. Mereka meletakkan semuanya
di wajah Anda dan membuat Anda mencari tahu apa artinya. Perangkat lunak harus memfokuskan pengguna
memperhatikan data penting dan membantu mereka mengekstrak informasi darinya.

Desain ditampilkan dengan hati-hati; dapatkan bantuan profesional

Prinsip Dasar 2 mengatakan, "Pertimbangkan fungsi dulu, presentasi nanti," tapi di sana
Ada saatnya dalam setiap upaya pengembangan perangkat lunak yang harus Anda pertimbangkan
bagaimana menyajikan kontrol dan status perangkat lunak serta data pengguna.
Ketika saatnya tiba, Anda harus mempertimbangkan desain layar dengan serius dan
hati-hati. Tujuan Anda:

■
Urutan visual dan fokus pengguna: UI yang sukses tidak hanya hadir. Ini mengarahkan
perhatian pengguna terhadap apa yang penting. Misalnya, temukan teks yang dipilih
di setiap layar komputer pada Gambar 1.9. Jumlah kontras yang besar

Gambar 1.9

[Link] 40/315
26/2/2021 Tanpa judul

Jumlah kontras yang tinggi pada layar dapat mempersulit atau memudahkan untuk menemukan yang dipilih
teks.

Halaman 57

Prinsip Dasar 7: Menyampaikan informasi, bukan hanya data 43

di layar banyak sistem komputer (layar kiri) menyulitkan

pengguna untuk melihat informasi penting. Pilihan saat ini haruslah
fokus utama pengguna; itu adalah objek dari operasi selanjutnya. Layar di
kanan menunjukkan bagaimana tampilan Apple Macintosh meminimalkan kontras
layar untuk memusatkan perhatian pada pilihan saat ini.
■
Kemampuan memindai: Pengguna komputer jarang membaca layar dengan cermat; mereka biasanya
pindai dengan cepat untuk mencari apa pun yang cocok dengan tujuan mereka. Karena itu, desain
layar agar mudah dipindai. Alih-alih paragraf panjang teks prosa,
memecah informasi menjadi judul, poin, daftar, dan tabel. Layar
informasi secara grafis jika memungkinkan. Pertahankan agar label tautan tetap pendek.
■
Cocokkan medianya: Salah satu tanda dari UI yang dirancang dengan buruk adalah gagal untuk mencocokkan
desain dengan batasan media presentasi. Contoh: jendela
sistem untuk layar 2 inci, metafora visual disajikan secara aurial melalui a
telepon, arahkan-dan-klik GUI pada perangkat yang hanya memiliki tombol panah, halus
warna pada tampilan yang tidak dapat menampilkannya dengan baik. Antarmuka pengguna yang dirancang dengan baik
cocok dengan media tempat mereka disajikan.
■
Perhatian terhadap detail: Sukses ada di detail. Tidak ada yang lebih benar dari ini
dalam desain tampilan informasi. Mempekerjakan UI dan desainer grafis mungkin
tampak mahal, tetapi mereka memperhatikan detail yang hanya dimiliki oleh beberapa pengembang lain
dapat menyediakan dan dengan demikian membayar kembali biaya mereka. Dalam kasus di mana programmer harus
desain tanpa dukungan spesialis desain, setidaknya menetapkan UI ke
orang yang sangat memperhatikan detail. Alternatifnya adalah banyak blooper
dijelaskan dalam buku ini, tampilan yang tidak koheren, inkonsistensi desain, ketidaktepatan
simbol pherable, dan penampilan yang umumnya tidak profesional, yang mungkin
menghasilkan produk yang kurang sukses.

Manajer pengembangan harus mendapatkan orang yang tepat untuk pekerjaan itu. Anda tidak akan mempekerjakan
seorang tukang ledeng — bahkan yang terampil — untuk memperbaiki mobil Anda. Belum banyak pengembangan perangkat lunak
tim mengharapkan programmer GUI untuk mendesain layar serta mengimplementasikan GUI.
Banyak yang menugaskan pemrograman GUI untuk siswa magang dan karyawan baru dan menggunakan grafik
dibuat oleh programmer atau manajer. Masalahnya bisa seperti pemotongan sudut
penyebabnya, dan cara menghindarinya, dijelaskan secara rinci pada Blooper 64, halaman 331.

Layar itu milik pengguna

Pada awal sejarah GUI, peneliti menemukan bahwa ini biasanya ide yang buruk
agar perangkat lunak dapat secara sepihak memindahkan kontrol dan data di sekitar layar. Ini
termasuk memiliki perangkat lunak:

■
lompat atau "lengkungkan" penunjuk mouse ke posisi baru,
■
pindahkan kontrol ke penunjuk,
■
memposisikan ulang, meregangkan, atau mengecilkan jendela.

Halaman 58

44 Bab 1 Prinsip Pertama

Upaya seperti itu untuk membantu dan efisien membuat pengguna bingung dan lebih frustrasi

[Link] 41/315
26/2/2021 Tanpa judul
daripada mereka membantu. Mereka mengganggu persepsi pengguna tentang layar
di bawah kendali mereka sendiri .
Prinsip GUI yang bekerja adalah "Layar adalah milik pengguna". Grafis
antarmuka pengguna seharusnya didasarkan pada manipulasi data secara langsung oleh
pengguna, dan itulah yang diharapkan pengguna. Ketika perangkat lunak berubah terlalu banyak
inisiatif sendiri, pengguna menjadi bingung dan kesal.
Pertimbangkan penunjuk layar. Menggerakkannya membutuhkan koordinasi tangan-mata.
Setelah seseorang belajar menggunakan mouse atau touchpad, gerakkan pointer
menjadi refleks — lebih dikendalikan oleh "memori otot" daripada oleh kesadaran
kesadaran. Pikiran sadar pengguna dibebaskan untuk memikirkan tugas-tugas mereka
mencoba untuk mencapai. Gerakan penunjuk secara otomatis dan sepihak oleh
perangkat lunak mengganggu koordinasi tangan-mata, menyebabkan disorientasi dan sentakan
kesadaran pengguna kembali ke tugas mengendalikan penunjuk. Pengguna tidak
yakin gerakan penunjuk mana yang dihasilkan dari tindakan mereka versus gerakan penunjuk
komputer.
Prinsipnya mencakup lebih dari sekadar penunjuk layar, jendela, dan kontrol.
Ini termasuk ikon desktop, daftar item, dan jenis data orang lain
memanipulasi. Perangkat lunak tidak boleh “membantu” pengguna dengan mengatur ulang datanya
mereka. Ini harus memungkinkan pengguna mengatur dan mengelola data mereka sendiri. Bloopers
disebabkan oleh pelanggaran prinsip ini, dan bagaimana menghindarinya, dibahas di bawah
Blooper 49, halaman 277.

Pertahankan inersia tampilan

Berhubungan erat dengan prinsip bahwa layar milik pengguna adalah prinsip
dari layar inersia .
Ketika perangkat lunak mengubah tampilan untuk menunjukkan efek tindakan pengguna, itu
harus mencoba meminimalkan apa yang berubah. Perubahan data yang kecil dan terlokalisasi
seharusnya hanya menghasilkan perubahan kecil yang dilokalkan pada tampilan. Saat pengguna
mengubah sesuatu di layar, sebanyak mungkin tampilan yang seharusnya
tetap tidak berubah.
Gagal membatasi pembaruan tampilan pada apa yang sebenarnya telah berubah dapat menyebabkan disorientasi
pengguna. Misalnya, jika seseorang mengedit nama file yang tercantum dalam folder, itu
akan sangat membingungkan dan mengganggu jika file terus-menerus berpindah-pindah
ke posisi alfabet yang berbeda saat nama sedang diedit. Karena itu,
sebagian besar pengelola file meninggalkan file untuk sementara di tempatnya sampai pengguna menunjukkannya
mereka selesai dengan menekan Enter atau memindahkan pilihan ke tempat lain.
Demikian pula, jika pengguna mengedit bidang di formulir Web atau kata di halaman Wiki, itu
akan menjadi desain UI yang buruk untuk memuat ulang seluruh halaman, mungkin di-scroll ke file
posisi berbeda di browser. Pengguna harus memeriksa perawatan halaman-
sepenuhnya untuk konfirmasi bahwa apa yang mereka edit adalah satu-satunya hal yang berubah.

Halaman 59

Prinsip Dasar 8: Desain untuk daya tanggap 45

Masalah ini dulunya umum di Web, tetapi untungnya, masalah ini mendominasi
UI Web berbasis AJAX 5 mengurangi frekuensinya setiap hari.
Saat perubahan besar pada tampilan diperlukan (seperti pemberian tag ulang
atau menukar posisi cabang dalam diagram), seharusnya tidak
seketika. Sebaliknya, mereka harus diumumkan dengan jelas dan dilaksanakan
cara yang:

■
mendorong persepsi dan pemahaman pengguna tentang perubahan dan
■
meminimalkan gangguan pada kemampuan pengguna untuk terus bekerja.

Prinsip Dasar 8: Desain untuk daya tanggap

Selama empat dekade terakhir, banyak bukti terkumpul yang menunjukkan hal itu
daya tanggap — kemampuan aplikasi perangkat lunak untuk mengikuti pengguna dan bukan
membuat mereka menunggu-adalah yang paling faktor penting dalam menentukan kepuasan pengguna.
Bukan hanya satu dari factors- penting yang paling dalam faktor yang paling penting. Belajar
setelah penelitian menemukan ini [Miller, 1968; Thadhani, 1981; Barber dan Lucas,
1983; Lambert, 1984; Shneiderman, 1984; Carroll dan Rosson, 1984; Rushinek
dan Rushinek, 1986]. Temuan dari semua studi ini dirangkum dengan baik oleh
Peter Bickford dalam bukunya Desain Antarmuka [1997]:

Banyak survei telah mencoba untuk menentukan apa itu tentang komputer yang membuatnya
pengguna senang. Berkali-kali, ternyata faktor terbesar dalam kepuasan pengguna

[Link] 42/315
26/2/2021 Tanpa judul
isfaction bukanlah keandalan komputer, kompatibilitasnya dengan platform lain,
jenis antarmuka pengguna yang dimilikinya, atau bahkan harganya. Apa yang tampaknya diinginkan pelanggan
kebanyakan adalah kecepatan. Ketika datang ke komputer, pengguna benci menunggu lebih dari mereka
seperti yang lainnya.

Bickford selanjutnya menjelaskan bahwa yang dimaksud dengan "kecepatan", yang ia maksud adalah kecepatan yang dirasakan , bukan
kecepatan sebenarnya:

Komputer sebenarnya memiliki dua jenis kecepatan:… kecepatan (mesin) nyata dan…
kecepatan yang dirasakan. Dari keduanya, yang paling penting adalah kecepatan yang dirasakan. Untuk
Misalnya, program rendering 3-D yang menghemat beberapa saat dengan tidak menampilkan
hasil sampai gambar selesai pasti akan terlihat lebih lambat dari a
program yang memungkinkan pengguna melihat gambar saat berkembang. Alasannya adalah saat itu
pengguna program terakhir sedang menonton bentuk gambar, pengguna program pertama
menatap jam dengan tidak sabar, memperhatikan setiap detik berlalu. Pengguna akan
mengatakan bahwa program pertama berjalan lambat hanya karena menunggu lebih menyakitkan.

5. Asynchronous Javascript dan XML: teknik implementasi yang memungkinkan update ke bagian-bagian kecil
halaman Web.

Halaman 60

46 Bab 1 Prinsip Pertama

Penelitian juga menunjukkan bahwa meningkatkan daya tanggap perangkat lunak tidak hanya
meningkatkan kepuasan pengguna, juga dapat meningkatkan produktivitas pengguna [Brady, 1986]
(Gambar 1.10).

Apa itu responsivitas?

Daya tanggap terkait dengan kinerja, tetapi berbeda. Perangkat lunak interaktif
dapat memiliki daya tanggap tinggi meskipun kinerja rendah, dan dapat memiliki daya respons rendah
responsivitas meski berkinerja tinggi. Kinerja diukur dari segi
perhitungan per satuan waktu. Responsivitas diukur dalam hal kepatuhan
cocok dengan kebutuhan waktu manusia dan, pada akhirnya, kepuasan pengguna.
Perangkat lunak responsif mengikuti pengguna meskipun tidak dapat memenuhi permintaan mereka
segera. Ini memberikan umpan balik untuk memberi tahu pengguna apa yang mereka lakukan dan
apa yang dilakukannya dan memprioritaskan umpan balik berdasarkan persepsi manusia ,
motorik, dan tenggat waktu kognitif.
Perangkat lunak yang memiliki respons yang buruk tidak melakukan hal-hal ini. Tidak
mengikuti perkembangan pengguna. Itu tidak memberikan umpan balik yang tepat waktu untuk tindakan pengguna, jadi
pengguna tidak yakin apa yang telah mereka lakukan atau apa yang dilakukannya. Itu membuat pengguna
menunggu pada waktu yang tidak dapat diprediksi dan untuk periode yang tidak dapat diprediksi. Itu membatasi — beberapa-
kali dengan parah — kecepatan kerja pengguna. Berikut adalah beberapa contoh orang miskin
responsivitas:

■
Umpan balik yang tertunda untuk penekanan tombol, gerakan scrollbar, atau objek
manipulasi
■
Operasi yang menghabiskan waktu yang memblokir aktivitas lain dan tidak dapat dibatalkan
■
Tidak memberikan petunjuk berapa lama operasi yang berlangsung lama

Gambar 1.10

Produktifitas
pengguna ahli

pengguna rata-rata

.1 .2 .3 .4 0,5 .6 .7 .8 .9 1.0 1.1 1.2 1.3

Waktu Respons Sistem (detik)

Pengaruh waktu respon terhadap produktivitas pengguna [Brady, 1986].

[Link] 43/315
26/2/2021 Tanpa judul

Halaman 61

Prinsip Dasar 8: Desain untuk daya tanggap 47

■
Animasi tersentak-sentak, sulit diikuti
■
Mengabaikan masukan pengguna saat melakukan tugas "tata graha" yang tidak dilakukan pengguna
permintaan

Masalah-masalah ini menghambat produktivitas pengguna dan membuat mereka frustrasi dan kesal.
Sayangnya, meskipun semua penelitian menunjukkan bahwa daya tanggap itu penting
untuk kepuasan pengguna dan produktivitas, banyak perangkat lunak di pasar saat ini
memiliki daya tanggap yang buruk.

Responsivitas di Web: Buruk tapi membaik

Munculnya Web pada awal 1990-an merupakan lompatan besar dalam

munication dan perdagangan, tapi lompatan besar ke belakang dalam respon.
Hal ini sebagian disebabkan oleh komunikasi yang terbatas antara browser Web dan
server. HTML biasa hanya dapat memperbarui seluruh halaman dalam satu waktu dan lambat
melakukannya, sangat membatasi kemampuan Webware untuk memberikan umpan balik yang tepat waktu bagi pengguna
tindakan. Misalnya, formulir Web statis tidak dapat memeriksa validitas pengguna
masukan sesering mungkin dalam bentuk aplikasi desktop, sehingga sulit untuk
vide pesan kesalahan tepat waktu. Memberikan umpan balik yang lebih halus dan langsung
memerlukan kode Java atau bahasa skrip di sisi browser, yang bisa jadi
mahal untuk dikembangkan.
Daya tanggap yang buruk dari Webware juga sebagian disebabkan oleh ketidaktahuan di antara mereka
Desainer dan pengembang web tentang perlunya daya tanggap dan caranya
untuk mencapainya di Web. Pada akhir 1990-an dan awal 2000-an, didorong oleh Web
guru desain (misalnya, Flanders dan Willis [1998], Nielsen [1999d], King [2003]),
banyak desainer Web belajar untuk meningkatkan kinerja dan daya tanggap
situs dan aplikasi mereka menggunakan berbagai metode, yang dijelaskan
di Bab 7 (Responsiveness Bloopers).
Namun, bahkan dengan metode peningkatan kinerja yang direkomendasikan,
Webware sampai saat ini tidak dapat mendekati responsivitas dan interaksi
produktivitas aplikasi perangkat lunak desktop atau bahkan dari sebagian besar klien era sembilan puluhan
aplikasi server. Ini sangat tidak memuaskan karena Web publik
sangat kompetitif. Pengguna aplikasi komputer desktop agak
"Tawanan" karena biaya dan upaya untuk mendapatkan dan menginstal aplikasi.
Pengguna aplikasi Web intranet sepenuhnya “tertahan” karena harus menggunakannya
apapun yang diberikan majikan mereka. Sebaliknya, di Web publik, pengguna adalah
jarang tertawan. Jika mereka merasa frustasi dengan responsivitas dari sebuah e-commerce
Situs web, mereka baru saja menekan Kembali dan pergi, mungkin ke pesaing.
Peningkatan dalam komunikasi browser-server, bersama dengan program-
teknik ming yang memanfaatkannya (secara kolektif disebut sebagai Asynchronous
Javascript dan XML — AJAX), menutup celah responsivitas antara Web
aplikasi dan aplikasi desktop [Garrett, 2005]. Namun, sampai AJAX
metode disempurnakan dan diadopsi secara luas, kesenjangan akan tetap ada.

Halaman 62

48 Bab 1 Prinsip Pertama

Merancang untuk responsif

Agar dianggap responsif oleh pengguna, perangkat lunak interaktif harus:

■ mengakui tindakan pengguna secara instan, meskipun perlu mengembalikan jawaban

waktu;
■
beri tahu pengguna saat sedang sibuk dan saat tidak;
■ bebaskan pengguna untuk melakukan hal lain sambil menunggu fungsi selesai;

[Link] 44/315
26/2/2021 Tanpa judul
■
menghidupkan gerakan dengan lancar dan jelas;
■ memungkinkan pengguna untuk membatalkan operasi panjang yang tidak mereka inginkan;
■
memungkinkan pengguna untuk menilai berapa banyak waktu yang dibutuhkan untuk operasi;
■ melakukan yang terbaik untuk memungkinkan pengguna mengatur kecepatan kerja mereka sendiri.

Untuk blooper yang melukai respons, dan prinsip serta teknik untuk menghindari-
melihat blooper tersebut, lihat Bab 7.

Prinsip Dasar 9: Cobalah pada pengguna, lalu perbaiki!

Kebanyakan orang di industri komputer telah mendengar pepatah “Uji lebih awal dan
sering." Meskipun ada banyak jenis pengujian komputer yang berbeda
perangkat lunak dan perangkat keras dapat diatur, jenis yang relevan dengan buku ini
adalah pengujian kegunaan — mencoba produk atau layanan pada orang-orang yang seperti itu
pengguna yang dimaksudkan untuk melihat masalah apa yang mereka miliki dalam mempelajari dan menggunakannya. Seperti itu
pengujian sangat penting untuk menentukan apakah suatu desain berhasil,
yaitu, apakah itu membantu pengguna lebih dari sekadar menghalangi mereka.

Hasil pengujian bahkan dapat mengejutkan desainer berpengalaman

Pengembang dapat mempelajari hal-hal mengejutkan dari uji kegunaan. Terkadang

hasil dapat mengejutkan bahkan ahli antarmuka pengguna.
Saya biasanya meninjau UI produk atau layanan perangkat lunak sebelum mengujinya
pada pengguna. Meninjau UI sebelumnya memberi saya gambaran tentang cara mendesain
tes, masalah apa yang harus dicari, dan bagaimana menafsirkan masalah I
lihat yang dimiliki pengguna. Namun, melakukan pengujian hampir selalu menunjukkan kegunaan
masalah yang tidak saya antisipasi.
Misalnya, sebuah perusahaan sedang mengembangkan perangkat lunak untuk menganalisis kinerja
kekuatan cluster server. Perangkat lunak dapat memplot kinerja file
cluster server sebagai fungsi dari jumlah pengguna secara bersamaan. Pengguna
dapat menentukan jenis plot yang mereka inginkan: batang, garis, dll. Gambar kecil
mewakili jenis plot yang saat ini dipilih. Anehnya, uji kegunaan

Halaman 63

Prinsip Dasar 9: Cobalah pada pengguna, lalu perbaiki! 49

menunjukkan bahwa banyak pengguna mengira gambar thumbnail kecil dari jenis plot
adalah plot data yang sebenarnya! Itu selalu berguna untuk menguji; kamu tidak pernah tahu apa
Anda akan belajar, tetapi Anda akan mempelajari sesuatu yang akan membantu Anda meningkatkan
perangkat lunak.

Jadwalkan waktu untuk memperbaiki masalah yang ditemukan oleh tes

Tentu saja, tidak cukup hanya menguji kegunaan suatu produk atau layanan.
Pengembang juga harus menyediakan waktu dalam jadwal pengembangan untuk mengoreksi
masalah yang ditemukan dengan pengujian. Jika tidak, mengapa menguji?

Pengujian memiliki dua tujuan: Informasi dan sosial

Pengujian kegunaan memiliki dua tujuan penting tetapi berbeda: satu informasional, file
sosial lainnya.

Tujuan informasional

Tujuan informasi dari pengujian kegunaan adalah yang paling banyak diketahui orang
dengan: temukan aspek antarmuka pengguna yang menyebabkan kesulitan pengguna, dan penggunaan
sifat sebenarnya dari masalah untuk menyarankan perbaikan. Tujuan ini bisa jadi
dicapai dengan berbagai macam pengujian dan metode pengumpulan data, beberapa
mahal dan memakan waktu, sebagian murah dan cepat.

Tujuan sosial

Tujuan sosial dari pengujian kegunaan setidaknya sama pentingnya dengan informasi
tujuan. Ini untuk meyakinkan pengembang bahwa ada masalah desain yang perlu
mengoreksi. Pengembang sering menolak saran untuk perubahan, sebagian karena
waktu dan tenaga yang dibutuhkan dan sebagian karena kebutuhan untuk memperbaiki suatu desain

[Link] 45/315
26/2/2021 Tanpa judul
menunjukkan bahwa siapa pun yang merancangnya melakukan pekerjaan yang buruk. Untuk mencapai sosial pengujian
Tujuannya, akan paling efektif jika pengembang menonton uji kegunaan, baik secara langsung
atau di video.
Pengembang bisa menjadi gelisah saat melihat pengguna yang mengalami masalah
dengan perangkat lunak (Gambar 1.11). Oleh karena itu, saat pengembang mengamati pengujian dalam
orang, penting untuk menjelaskan kepada mereka perlunya mengamati secara pasif .
Menekankan tujuan sosial dari pengujian kegunaan memiliki manfaat lebih
meyakinkan pengembang untuk memperbaiki masalah kegunaan. Itu juga membuat pengembang
lebih menerima gagasan bahwa pengujian kegunaan adalah pengembangan penting
alat daripada cara untuk mengevaluasi pengembang GUI. Pemrogram yang awalnya
menolak pengujian kegunaan sering menjadi "orang yang bertobat" setelah menyaksikan beberapa (rasa sakit-
ful) tes. Dalam proyek selanjutnya, mereka secara aktif meminta uji kegunaan sebagai cara untuk mendapatkannya
umpan balik.

Halaman 64

50 Bab 1 Prinsip Pertama

Gambar 1.11
TIDAK!
Bukan begitu
kamu seharusnya
untuk menggunakannya!

Pengembang menonton rekaman video uji kegunaan.

Ada ujian untuk setiap waktu dan tujuan

Banyak orang di industri komputer memiliki kesan keliru bahwa menggunakan

pengujian bility dilakukan ketika produk perangkat lunak atau alat hampir siap
untuk mengirim, menggunakan fasilitas dan peralatan pengujian yang rumit. Sebenarnya ada banyak
cara untuk melakukan uji kegunaan, masing-masing memiliki kelebihan dan kekurangan.
Uji kegunaan dapat dikategorikan dalam dua dimensi independen: (1)
titik dalam pengembangan di mana pengujian terjadi dan (2) formalitas file
metode pengujian (lihat Lampiran E). Tes dapat dilakukan sebelum kode apa pun
tertulis, jika perangkat lunak hanya diterapkan sebagian, atau setelah
perangkat lunak hampir selesai. Metode pengujian bisa informal, kuasi-formal, atau
resmi. Wawancara, survei, observasi naturalistik, dan studi lapangan
Informal. Pengujian di mana pengguna melakukan tugas yang ditentukan dan di mana keduanya
data kualitatif dan kuantitatif yang dikumpulkan bersifat "kuasi-formal". Studi mengukur
memastikan terutama data kuantitatif dan membutuhkan analisis statistik (sering kali
mengupas desain yang berbeda) bersifat "formal". Kombinasi implementasi apa pun
panggung dan formalitas dimungkinkan.

Halaman 65

[Link] 46/315
26/2/2021 Tanpa judul

Kontrol GUI
Bloopers
pengantar

Menggunakan kontrol yang salah

Menggunakan kontrol secara salah

51

Halaman 66

52 Bab 2 GUI Control Bloopers

pengantar

Sebagian besar aplikasi perangkat lunak dan banyak situs Web dibangun menggunakan pengguna grafis
alat pengembangan antarmuka (GUI). Alat semacam itu menyediakan sekumpulan kontrol — juga
dikenal sebagai widget —untuk membuat GUI. Kontrol tersebut mencakup teks dan angka
bidang, kotak centang, tombol radio, slider, menu, scrollbar, tombol, kenop,
dial, meter, dan berbagai jenis jendela.
Alat GUI seharusnya mempermudah dan mempercepat pemrogram
mengembangkan GUI. Namun, bantuan yang mereka berikan dibatasi oleh beberapa kekurangan:

■ Level terlalu rendah: Toolkit GUI menyediakan blok penyusun level rendah untuk memungkinkan maks-
fleksibilitas imum dalam apa yang dapat dibangun. Tapi itu salah arah: itu membuat
mengembangkan aplikasi yang membosankan, memakan waktu, dan rawan kesalahan. Saya t
umum, UI biasa sama sulitnya diimplementasikan dan sangat tidak biasa
yang; kasus umum menderita untuk memungkinkan kasus langka. Beberapa toolkit

[Link] 47/315
26/2/2021 Tanpa judul
rendah karena pengembang
atau keterampilan toolkit kekurangan
untuk merancang waktu,
blok penyusun motivasi,
tingkat tinggi yang mencakup kisaran yang diinginkan
GUI.
■
Terlalu tidak terarah: Toolkit GUI memungkinkan pemrogram membangun GUI yang melanggar
pedoman desain. Mereka tidak membantu membimbing pemrogram menuju kebaikan
desain. Kebanyakan toolkit mengklaim mendukung standar GUI — seperti Windows
atau MacOS — tetapi buatlah melanggar standar semudah mematuhinya
saya t. Mereka memungkinkan desainer untuk membuat pilihan yang buruk, seperti menggunakan kontrol yang salah
untuk sebuah pengaturan. Kontrol mungkin terlihat bagus, tapi itu detail kecil jika itu
kontrol yang salah atau berperilaku tidak terduga.
■ Terlalu fokus pada penampilan: Sebagian besar alat GUI mengharuskan pengembang untuk mengeluarkan uang
terlalu banyak waktu untuk mengutak-atik tampilan dan tata letak GUI mereka. Adalah
label untuk pengaturan disejajarkan dengan benar? Haruskah suatu nomor disajikan sebagai
pembacaan digital atau posisi pada dial? Haruskah pilihan disajikan sebagai
tombol radio atau menu? Font apa yang harus digunakan dalam bidang teks? Ini
hanyalah masalah presentasi — bagian desain GUI yang "low-order". Itu
masalah penting adalah semantik UI, seperti apakah pengaturan itu
a date, sebuah nama file, sebuah tingkat volume, atau pilihan antara font. Keputusan
tentang presentasi akan berubah dari hari ke hari atau bahkan jam ke jam
sebagai desain berkembang dan seharusnya tidak memerlukan pengodean ulang. Mengubah
presentasi pilihan dari tombol radio ke menu dropdown harus
hanya perlu mengubah atribut, bukan merobek kode tombol radio dan
menggantinya dengan kode menu dropdown. Waktu yang dihabiskan untuk mengutak-atik presentasi
tasi akan lebih baik dihabiskan untuk mempelajari tentang pengguna, tugas, dan alur kerja
dan merencanakan fungsionalitas yang sesuai.

Keprimitifan sebagian besar alat GUI menjadi masalah karena banyak GUI yang bermasalah
tidak dirancang oleh profesional UI. Sebaliknya, mereka dengan cepat dirakit dengan ketat
tenggat waktu oleh pemrogram yang tidak memiliki keahlian UI yang diperlukan untuk mengimbanginya
karena kurangnya panduan dari toolkit.

Halaman 67

Menggunakan kontrol yang salah 53

Hasilnya adalah banyak GUI yang penuh dengan kesalahan desain. Beberapa kesalahan adalah seman-
tic dan hanya dapat dideteksi oleh orang yang memahami target aplikasi
pengguna dan tugas. Namun, banyak kesalahan desain GUI akan mudah dideteksi oleh
sebagian besar profesional UI, bahkan mereka yang tidak terbiasa dengan pengguna dan tugas. Seperti itu
kesalahan adalah kesalahan besar kontrol GUI. Mereka terbagi dalam dua kategori:

1. Menggunakan kontrol GUI yang salah

2. Menggunakan kontrol secara tidak benar

Kesalahan kontrol GUI merusak kegunaan. Mereka juga memberi kesan pada pelanggan
produk yang jelek dan tidak profesional, terutama jika GUI memiliki banyak produk.
Untungnya, mereka cukup mudah dikenali oleh para ahli kegunaan. Mereka juga
konkret dan relatif mudah dijelaskan. Akhirnya, mereka biasanya mudah dikoreksi
kecuali karena keterbatasan alat GUI yang digunakan untuk membangun perangkat lunak.
Bab ini menjelaskan blooper kontrol GUI yang paling umum, dengan desain
aturan untuk menghindarinya.

Menggunakan kontrol yang salah

Kategori pertama dari kesalahan besar kontrol GUI menyangkut situasi di mana kontrol
terdiri dari UI bukanlah yang tepat.

Blooper 1: Kotak centang dan tombol radio yang membingungkan

Semua toolkit GUI menyediakan kontrol untuk memilih salah satu dari beberapa kemungkinan nilai,
misalnya, Font Teks: { Times, Helvetica, Courier, New York }. Salah satu kontrol tersebut
disebut "tombol pilihan" atau "tombol radio". Opsi tampilan tombol radio
sebagai susunan tombol. Ketika pengguna memilih satu dengan mengklik tombolnya, itu benar
disorot. Hanya satu opsi yang dapat dipilih dalam satu waktu; mengklik opsi lain
menyoroti itu dan membatalkan pilihan sebelumnya. Kontrol ini disebut radio
tombol karena mereka seperti tombol pada radio mobil yang memilih salah satu dari tujuh
stasiun eral. Di komputer, tombol radio biasanya muncul sebagai sekelompok berlabel
titik bulat. Satu tombol disorot sebagai opsi setelan saat ini.
Beberapa toolkit GUI memperlakukan setiap tombol radio individu dalam pilihan sebagai
rate control, membutuhkan programmer untuk "menghubungkan" mereka bersama-sama sehingga memilih
seseorang membatalkan pilihan sebelumnya. Toolkit lain menangani satu set tombol radio

[Link] 48/315
26/2/2021 Tanpa judul
sebagai satu kontrol, dipersiapkan untuk menjadi eksklusif satu sama lain.
Toolkit GUI juga menyediakan kontrol untuk On / Off sederhana, True / False, atau Yes / No
setelan, misalnya, Pemeriksaan ejaan otomatis: { OFF, ON }. Paling com-
mon ini adalah "checkbox": kotak yang kosong saat OFF dan berisi
tanda centang atau X saat AKTIF. Mengklik kotak centang akan mengalihkannya antara AKTIF dan
MATI. Setiap kotak centang adalah kontrol terpisah. Kotak centang dapat dikelompokkan, tetapi
setiap kotak centang harus terpisah satu sama lain.

Halaman 68

54 Bab 2 GUI Control Bloopers

Gambar 2.1

Jendela Preferensi Pratinjau Apple: tombol radio dan kotak centang.

Contoh tombol radio dan kotak centang disediakan oleh

Jendela Preferensi perangkat lunak Pratinjau Apple (Gambar 2.1).
Kesalahan umum yang umum terjadi adalah mengacaukan kotak centang dan tombol radio. Beberapa GUI
toolkit memperlakukan kotak centang dan tombol radio sebagai varian dari satu jenis kontrol—
tombol sakelar — berdasarkan penampilannya yang agak mirip. Tombol sakelar
kontrol diubah menjadi tombol radio atau kotak centang dengan mengatur atribut. Jika kamu
lupa untuk menyetel atribut atau menyetelnya secara tidak benar, GUI akan memiliki con-
trol. Namun, pemrogram membingungkan tombol radio dan kotak centang bahkan ketika
perangkat mereka memperlakukan mereka sebagai sesuatu yang berbeda. Apapun alasannya, kebingungan antara
tombol radio dan kotak centang memanifestasikan dirinya dalam tiga cara berbeda.

Variasi A: Tombol radio tunggal

Variasi paling umum dari kesalahan besar ini adalah tombol radio tunggal — radio
tombol disalahgunakan sebagai kotak centang. Contohnya berasal dari formulir online untuk
mendaftar untuk kursus di Forrester Research (Gambar 2.2).
Kesalahan "tombol radio tunggal" terjadi karena empat alasan berbeda:

1. Seorang programmer yang tidak berpengalaman tidak mengetahui perbedaan antara radio
tombol dan kotak centang.
2. Toolkit GUI menyediakan tombol sakelar umum dan set pemrogram
atributnya salah.

Halaman 69

Menggunakan kontrol yang salah 55

Gambar 2.2

[Link] 49/315
26/2/2021 Tanpa judul

[Link]/events/register: Halaman pendaftaran kursus Forrester Research memiliki satu radio

tombol. Juga, biaya yang ditunjukkan salah.

3. Beberapa opsi dalam serangkaian tombol radio dihilangkan karena adanya perubahan
persyaratan fungsional. Hanya satu pilihan yang tersisa, tetapi tidak ada yang mendesain ulang
UI untuk mencerminkan itu.
4. Jumlah opsi dalam pilihan bervariasi tergantung pada keadaan.
Perangkat lunak tidak memperlakukan kasus "satu opsi" sebagai khusus.

Agen perjalanan online [Link] menunjukkan Alasan 4. Jika pelanggan memesan

penerbangan terlalu dekat dengan tanggal keberangkatan untuk memungkinkan konfirmasi dikirimkan kepada mereka,
Travelocity hanya menawarkan satu opsi tiket, elektronik, tetapi tetap menampilkannya sebagai
sebuah "pilihan" dari satu opsi (Gambar 2.3).
Apa pun alasannya, satu tombol radio adalah desain yang salah.

Variasi B: Kotak centang sebagai tombol radio

Menggunakan kotak centang di mana tombol radio harus digunakan hampir sama biasa.
Formulir aplikasi online Long Island University biasanya memiliki kotak centang
tempat yang seharusnya memiliki tombol radio. Pelamar bisa melamar lebih dari satu
istilah sekolah secara bersamaan dan menjawab "Ya" dan "Tidak" untuk pertanyaan
(Gambar 2.4).

Halaman 70

56 Bab 2 GUI Control Bloopers

Gambar 2.3

[Link]: ketika hanya satu opsi yang tersedia, itu disajikan sebagai "pilihan" dari satu.

Gambar 2.4

[Link] 50/315
26/2/2021 Tanpa judul

[Link]: kotak centang yang disalahgunakan sebagai tombol radio.

Gambar 2.5

[Link] dan [Link]: kotak centang yang disalahgunakan sebagai tombol radio.

Baru-baru ini, [Link] mengirimkan survei [Link] ke

anggota yang satu pertanyaannya salah menggunakan kotak centang, bukan radio
tombol (Gambar 2.5). Seseorang di Earthwatch, dalam mengembangkan survei menggunakan
Alat SurveyMonkey, memilih kontrol yang salah untuk pertanyaan ini.
Alasan utama untuk variasi blooper ini adalah ketidaktahuan:
ers tidak tahu perbedaan antara kotak centang dan tombol radio atau bagaimana caranya
untuk menampilkan tombol radio.

Variasi C: Kotak centang yang saling eksklusif

Variasi ketiga dari kesalahan besar ini adalah kotak centang "kabel" jadi hanya satu
dapat AKTIF sekaligus, membuatnya berperilaku seperti tombol radio (Gambar 2.6).

Halaman 71

Menggunakan kontrol yang salah 57

Gambar 2.6
ATM di Toko: Uang Kembali

Berapa banyak uang kembali yang Anda inginkan?

$ 20

X $ 40

$ 60

$ 80

$ 100

baik Membatalkan Tolong

Blooper: kotak centang yang saling eksklusif.

Kesalahan ini dapat terjadi ketika GUI toolkit memperlakukan tombol radio dan kotak centang
sebagai varian dari kontrol tombol sakelar generik. Penampilan default biasanya
kotak centang. Seorang programmer dapat menghubungkan tombol-tombol itu bersama-sama menjadi satu sama lain
eksklusif, tetapi lupa untuk mengatur atribut agar muncul sebagai tombol radio.
Kesalahan juga dapat terjadi jika pemrogram mengubah ON / OFF independen
pengaturan menjadi saling eksklusif untuk mengakomodasi perubahan dalam perangkat lunak
persyaratan fungsional, tetapi mengabaikan untuk mengubah kotak centang menjadi radio tetapi-
ton. Ini lebih mungkin terjadi pada toolkit yang menangani tombol radio dan kotak centang
sebagai kontrol yang berbeda .
Pengembang juga dapat melakukan kesalahan ini karena konteks implementasi.
strain. Aplikasi bagan medis mungkin dapat menunjukkan delapan kategori
data pasien, tetapi hanya satu kategori pada satu waktu yang muat di layar kecilnya.
Pengembang mungkin menampilkan ini sebagai delapan kotak centang "tampilkan / sembunyikan" —satu untuk
setiap kategori data. Dengan layar yang lebih besar, kotak centang dapat berdiri sendiri.
ent, tetapi dengan layar kecil, mereka mungkin "disambungkan" sehingga hanya satu yang bisa
AKTIF pada suatu waktu.
Di kontrol font Microsoft Word dan PowerPoint (untuk MacOS X)
beberapa kotak centang berperilaku normal, sementara yang lain berperilaku seperti tombol radio.
Kotak centang Superskrip dan Subskrip sebenarnya adalah satu setelan: pemeriksaan
satu menghapus centang yang lain (Gambar 2.7). Di Word, huruf kecil dan huruf besar semua
kotak centang juga tidak independen.
Ada dua kemungkinan alasan untuk desain ini:

1. Para desainer mungkin lebih mementingkan penampilan daripada pada

kegunaan dan kebenaran fungsional. Panel terlihat lebih baik ketika semua set-
tings adalah kotak centang daripada jika panel memiliki tombol radio dan

[Link] 51/315
26/2/2021 Tanpa judul

Halaman 72

58 Bab 2 GUI Control Bloopers

Gambar 2.7

Beberapa pasangan kotak centang tidak independen. (A) PowerPoint. (B) Kata.

kotak centang. Ini adalah alasan yang buruk: kejelasan antarmuka pengguna lebih penting
dari beberapa gagasan estetika yang sederhana. Seberapa baik UI menyampaikan fungsinya
tion kepada pengguna adalah bagian dari nilai estetika.
2. Pengaturan Huruf kecil / huruf besar semua benar-benar memiliki tiga opsi: huruf kecil,
huruf besar semua, dan tidak keduanya . Ini dapat diwakili oleh dua tombol radio,
keduanya awalnya NONAKTIF, tetapi itu tidak memungkinkan pengguna untuk kembali ke "tidak keduanya".
Mewakili tiga opsi dengan benar membutuhkan tiga tombol radio. Itu
desainer mungkin menggunakan dua kotak centang untuk menghindari tiga radio
tombol. Hal yang sama berlaku untuk kotak centang Superskrip / Subskrip. Itu
Masalah dengan alasan ini adalah bahwa dua kotak centang tidak secara akurat mewakili
membenci tiga pilihan juga. Pengguna mengharapkan kotak centang menjadi mandiri,
jadi sepasang kotak centang mewakili empat opsi, yang keempat adalah "keduanya".
Oleh karena itu, gunakan kotak centang untuk menghindari serangkaian tombol radio yang canggung
hanya mengganti satu masalah desain GUI dengan yang lain. Selanjutnya,
kotak centang nonindependen adalah blooper yang lebih buruk daripada tombol radio itu
tidak memiliki nilai default.

Apa pun alasannya, kotak centang "kabel" menjadi saling eksklusif

kelompok salah.

Menghindari Blooper 1

Kotak centang dan tombol radio disesuaikan untuk berbagai jenis pengaturan.

Halaman 73

Menggunakan kontrol yang salah 59

Tombol radio

Tombol radio untuk menampilkan pilihan satu-dari- N . Mereka paling cocok saat
dua kondisi berlaku:

1. Jumlah opsi tetap dan kecil: antara dua dan delapan. 1

2. Ruang yang cukup tersedia pada panel untuk menampilkan semua opsi.

[Link] 52/315
26/2/2021 Tanpa judul
Tombol radio selalu muncul dalam set setidaknya dua; satu tombol radio tidak
kontrol yang valid.
Long Island University baru-baru ini merevisi formulir aplikasi online mereka. Sepanjang
dengan perubahan lain, mereka mengganti kotak centang yang salah dengan tombol radio
(Gambar 2.8).

Gambar 2.8

Menghindari blooper: aplikasi online [Link], dikoreksi untuk menggunakan tombol radio.

Kontrol pilihan lainnya

Tombol radio membutuhkan banyak ruang karena semua opsinya ditampilkan. Paling
Toolkit GUI dan Web juga menyediakan kontrol pilihan yang membutuhkan lebih sedikit ruang. Yang
satu yang terbaik tergantung pada jumlah opsi.

■ Menu tarik-turun: juga disebut menu "opsi". Mereka menunjukkan nilai dan
menyajikan menu nilai yang mungkin ketika diklik (Gambar 2.9). Dropdown
Menu berbeda dengan menu “pulldown”, yaitu menu yang terdiri
terutama perintah yang diakses dari batang menu. Menu dropdown adalah yang terbaik
cocok jika ruang terbatas dan jumlah opsi lebih besar dari
delapan atau perubahan saat runtime.

Gambar 2.9

Menu tarik-turun. (A) Microsoft Windows Vista. (B) MacOS X.

1. Meskipun, dalam kasus khusus, susunan tombol radio yang dirancang dengan cermat dapat digunakan untuk menyajikan lebih banyak
pilihan.

Halaman 74

60 Bab 2 GUI Control Bloopers

■ Kotak daftar gulir: Ini menampilkan daftar opsi dan memungkinkan pengguna untuk memilih salah satu
atau lebih (Gambar 2.10). Seperti tombol radio, kotak daftar gulir memakan banyak hal
ruang, tetapi kemampuan gulirnya memungkinkan lebih banyak opsi daripada yang dapat dengan nyaman
dikirim dengan tombol radio. Seperti menu dropdown, kotak daftar gulir berguna
ketika daftar opsi bisa berubah.

Gambar 2.10

Kotak daftar gulir. (A) Microsoft Word, ukuran font. (B) [Link], pemilih negara bagian.

■
Kotak putar: juga dikenal sebagai "tombol siklus". Mereka menampilkan opsi saat ini dan
beralih ke opsi berikutnya ketika diklik (Gambar 2.11). Tombol siklus adalah
cocok untuk menyajikan pilihan dalam ruang terbatas dengan sedikit pilihan

[Link] 53/315
26/2/2021 Tanpa judul

Gambar 2.11

Microsoft Word: tombol siklus, alias "spin box", di kotak dialog Paragraph Format.

Halaman 75

Menggunakan kontrol yang salah 61

Kotak centang

Kotak centang menunjukkan pengaturan ON / OFF (Gambar 2.12A). Mereka harus independen.
independen satu sama lain. Kotak centang dapat dikelompokkan untuk menampilkan ON / OFF terkait
pengaturan (Gambar 2.12B).
Kadang-kadang kotak centang digunakan dalam kelompok untuk menampilkan kontrol untuk pilih-
mengambil subset terbatas dari opsi yang tersedia (Gambar 2.13). Kasus-kasus tersebut menghadirkan a
dilema: kotak centang seharusnya independen, namun kelompok check-
kotak harus membatasi jumlah opsi yang dipilih.
Dua solusi telah ditemukan dalam uji kegunaan untuk bekerja, dengan yang pertama
menjadi lebih disukai:

■
Tolak untuk MENGAKTIFKAN opsi jika itu melebihi jumlah maksimum grup.
Beri tahu pengguna dengan bip, menampilkan pesan kesalahan, atau keduanya.
■
Memungkinkan pengguna untuk mengubah sejumlah item ON, dan menginformasikan mereka kemudian bahwa
jumlah opsi yang dipilih melebihi jumlah maksimum. Misalnya, tampilan
pesan kesalahan ketika pengguna mengklik OK atau Terapkan pada dialog yang melampirkan
kotak.

Pendekatan yang pasti tidak berhasil adalah menghapus centang yang sudah dicentang
opsi ketika pengguna memilih salah satu yang akan melebihi maksimum. Di antara yang lain
banyak hal, pengguna akan bertanya-tanya: “Mengapa ini MENONAKTIFKAN yang satu itu, bukan yang lain
satu?"

Gambar 2.12

Kotak centang yang bagus. (A) Dialog Apple Preview Print. (B) Preferensi MacOS X.

Gambar 2.13
Pilih hingga empat kandidat: GW Shrub

Sally Bleedinghart

John Q. Redneck

Lucille Incumbente

Estelle Radical

Leroy Middleroad

Sekelompok kotak centang terkait yang dapat dicentang dalam jumlah terbatas.

Halaman 76
[Link] 54/315
26/2/2021 Tanpa judul

62 Bab 2 GUI Control Bloopers

Saran untuk memilih toolkit GUI

Saat memilih toolkit GUI, pengembang harus mencari yang:

■ perlakukan kotak centang dan tombol radio sebagai jenis kontrol yang berbeda;
■
perlakukan sekelompok tombol radio yang merepresentasikan pilihan sebagai kontrol tunggal;
■ perlakukan set tombol radio, menu dropdown, dan daftar gulir sebagai perbedaan
presentasi jenis kontrol pilihan satu-dari- N [Johnson, 1992]
(Blooper 69, halaman 365).

Blooper 2: Menggunakan kotak centang untuk pengaturan non-ON / OFF

Kotak centang terkadang digunakan untuk menampilkan pilihan di antara dua pilihan itu
tidak jelas berlawanan. Asumsikan pengaturan warna memiliki dua kemungkinan nilai: merah dan
hijau. Beberapa pengembang mungkin menampilkan ini sebagai kotak centang karena mudah dan
menghemat ruang (Gambar 2.14). Masalahnya adalah pengguna tidak tahu apa yang tidak dicentang
kotak itu berarti.
Seorang programmer di salah satu perusahaan klien saya melakukan pendekatan yang lebih halus
sion dari kesalahan ini. Aplikasi yang dia kembangkan memiliki toolbar perintah.
Program dapat menampilkan bilah alatnya secara horizontal di bawah batang menu atau vertikal.
dihabiskan di sepanjang tepi kiri jendela. Dia mempresentasikan pilihan menggunakan cek-
kotak (Gambar 2.15). Secara default, program menampilkan toolbar horizontal, jadi
kotak centang telah dicentang. Programmer berasumsi bahwa pengguna akan menyadari
yang menghapus centang itu akan menampilkan bilah alat secara vertikal. Programmer itu tahu
apa pilihannya, tetapi pengguna mungkin tidak tahu dan dapat dengan mudah berasumsi bahwa
menghapus centang pada kotak centang akan menyembunyikan toolbar. Mereka mungkin akan belajar pada akhirnya
apa yang dilakukan menghapus centang pada kotak, tetapi pengguna tidak harus mencari tahu caranya
perangkat lunak bekerja dengan proses eliminasi (Prinsip Dasar 5, halaman 35).

Gambar 2.14
Warna: X Merah

Blooper: kotak centang untuk pilihan dua nilai yang tidak berlawanan.

Gambar 2.15
X Bilah Alat Horizontal

Blooper: kotak centang untuk pilihan dua nilai yang tidak berlawanan.

Halaman 77

Menggunakan kontrol yang salah 63

Lebih atau kurang blooper yang sama terjadi di PowerBuilder Sybase, sebuah interaktif
Alat pembuat GUI (Gbr 2.16). Ironisnya, PowerBuilder menyalahgunakan kotak centang
terjadi di panel untuk mengatur properti tombol radio di GUI.
Sebagian besar kotak centang di panel ini baik-baik saja. Jelas apa yang sebaliknya
dari "Terlihat" adalah. Namun, yang berlabel "LeftText" seharusnya tidak menjadi kotak centang
karena tidak jelas apa kebalikannya — bisa jadi "LeftGraphics". Ini
kotak centang tidak jelas meskipun pengguna tahu bahwa itu mengontrol penempatan
label di tombol radio. Jika "LeftText" dicentang, label tombol radio akan
berada di sebelah kiri, tetapi apa fungsinya dengan menghapus centang ? Pengguna PowerBuilder harus tahu
bahwa PowerBuilder menempatkan label hanya di kiri atau kanan tombol radio.
Contoh yang lebih membingungkan dari kotak centang yang disalahgunakan berasal dari
aplikasi yang saya ulas. Label memberi nama kedua opsi (Gambar 2.17). Tidak boleh
beri tahu opsi mana yang dipilih saat Anda menghapus centang atau mencentang kotak.

Gambar 2.16

[Link] 55/315
26/2/2021 Tanpa judul

Sybase Powerbuilder: kotak centang “LeftText” tidak jelas sebaliknya. (A) Tidak dicentang. (B) Dicentang.

Halaman 78

64 Bab 2 GUI Control Bloopers

Gambar 2.17 Mode Ketik: X Sisipkan vs. Overstrike

Blooper: kotak centang untuk pilihan dua nilai yang tidak berlawanan.

Menghindari Blooper 2

Kotak centang tidak cocok untuk setelan yang memiliki dua nilai tidak berlawanan. Menggunakan
mereka hanya untuk pengaturan biner yang kedua nilainya natural, jelas
berlawanan, seperti On / Off, True / False, Color / B & W, atau Present / Absent. Bahwa
caranya, satu label memberi label pada seluruh pengaturan, memberi label nilai ON, dan memperjelas
apa nilai kebalikannya .

Contoh

Penggunaan kotak centang yang benar dapat dilihat di kotak dialog Cetak Pratinjau Apple
(Gambar 2.18). Jelas apa kebalikan dari masing-masing: " Jangan gambar tengah"
dan " Jangan diskalakan agar sesuai."
Jika pengaturan dua nilai tidak sesuai dengan kriteria untuk disajikan sebagai a
kotak centang, itu harus disajikan sebagai tombol radio atau menu dropdown, jadi
pengguna dapat melihat kedua nilai tersebut. Pengaturan orientasi toolbar pada Gambar 2.15 seharusnya
Ada dua tombol radio. Adobe Photoshop melakukan persis seperti itu di New
Kotak dialog panduan: pengguna memilih apakah garis panduan akan dihamparkan pada
gambar horizontal atau vertikal (Gambar 2.19).

Gambar 2.18

Kotak dialog Apple Preview Print: kotak centang dengan kebalikan yang jelas.

Gambar 2.19

[Link] 56/315
26/2/2021 Tanpa judul
Photoshop: pilihan dua nilai disajikan sebagai tombol radio, sehingga kedua nilai tersebut terlihat.

Kotak centang "LeftText" yang membingungkan dari PowerBuilder

Pengaturan kotak centang PowerBuilder pada Gambar 2.16 akan lebih jelas jika demikian
sepasang tombol radio atau menu dropdown (Gambar 2.20).

Halaman 79

Menggunakan kontrol yang salah 65

Gambar 2.20
Posisi label: Kiri Baik

Posisi label: Kiri dari kotak centang

Pengaturan "Teks Kiri" PowerBuilder (Gambar 2.16) harus berupa tombol radio atau menu tarik-turun.

Blooper 3: Menggunakan tombol perintah sebagai matikan

Kebanyakan toolkit GUI menyediakan kontrol tombol perintah (juga disebut aksi tetapi-
ton ). Tombol perintah meminta tindakan atau memicu peristiwa.
Tombol perintah terkadang disalahgunakan sebagai kontrol sakelar. Mendorong
tombol sekali untuk mengaktifkan sesuatu atau beralih ke mode alternatif; mendorongnya
sekali lagi matikan sesuatu atau kembali ke mode aslinya. Tombol perintah
toggle adalah desain UI yang buruk: mereka menyesatkan pengguna. Pengguna tidak dapat memprediksi dengan melihat
mereka bagaimana mereka akan berperilaku; mereka harus mencobanya (Gambar 2.21).
Tombol perintah yang berfungsi sebagai matikan biasanya tidak menunjukkan statusnya saat ini.
Pengembang mungkin berpikir bahwa kontrol tidak perlu menunjukkan statusnya jika status ditampilkan
di tempat lain di UI, misalnya, tombol "Tampilkan Riwayat Medis" dan medis
sejarah ditampilkan atau tidak.
Pertimbangkan toolbar dari jendela utama musik pengiring
Program Band dalam Kotak (Gambar 2.22). Sebagian besar tombol pada bilah alat ini memulai-
makan perintah, tetapi tombol "Lirik" beralih antara menampilkan atau menyembunyikan a
kolom bagi pengguna untuk mengetik lirik, dan tombol "Notasi" beralih di antaranya
menampilkan lagu sebagai not musik atau bagan akor. Tak satu pun dari keduanya tapi-
ton label berubah saat toggled.
Tombol-tombol ini terlihat seperti perintah, tetapi merupakan tombol matikan. Perilaku mereka
tidak terduga dan begitu juga fakta sewenang-wenang tentang Band in a Box yang harus pengguna
belajar.
Anda mungkin setuju bahwa sakelar tombol perintah dengan label statis itu buruk, tetapi
merasa bahwa sakelar tombol perintah OK ketika labelnya berubah untuk menunjukkan
negara mereka. Misalnya, tombol berlabel "Tampilkan Data" dapat berubah menjadi "Sembunyikan

Gambar 2.21
Tampilkan / Sembunyikan Resep Wajah berani

Blooper: tombol perintah disalahgunakan sebagai matikan (saklar ON / OFF).

Gambar 2.22

Pita dalam Kotak: Tombol "Lirik" dan "Notasi" adalah tombol perintah yang disalahgunakan sebagai sakelar.

Halaman 80

66 Bab 2 GUI Control Bloopers

[Link] 57/315
26/2/2021 Tanpa judul
Gambar 2.23

Kodak Picture Disk: Tombol "Dua Halaman" adalah sebuah toggle. Mengklik mengubah label menjadi "Satu Halaman".

Data ”setelah didorong. Ini tidak membantu. Banyak pengguna tidak akan melihat labelnya
perubahan. Lebih penting lagi, mengganti label memaksa pengguna untuk mencari tahu apakah
label menunjukkan status saat ini atau status yang akan dihasilkan saat tombol tersebut berada
didorong. Misalnya, di pembangkit listrik tenaga nuklir, jika tombol perintah beralih
berbunyi “Fuel batang DI,” adalah batang bahan bakar, atau akan mengklik tombol menempatkan para
batang bahan bakar? Jika batang bahan bakar tidak terlihat dari ruang kontrol, pengguna kebingungan
tentang arti label tombol sangat mungkin dan bisa menyebabkan bencana.
Jendela Pratinjau Cetak Disk Gambar Kodak memiliki tombol perintah
toggle yang mengubah labelnya (Gambar 2.23). Di toolbar jendela, sebagian besar
tombol memanggil perintah, tetapi tombol "Dua Halaman" mengubah tampilan
antara menampilkan satu halaman (foto) pada satu waktu dan menampilkan dua halaman secara berdampingan
sisi. Label tombol menunjukkan mode apa yang akan diubah ketika diklik. Kapan
Pratinjau Cetak menunjukkan satu halaman, tombol berlabel "Dua Halaman"; kapan
Pratinjau Cetak menampilkan dua halaman, tombolnya berlabel "Satu Halaman". Bersih?
Sepasang tombol radio akan membuat pengaturan lebih jelas.
Toolkit GUI yang lebih primitif digunakan, semakin terbatas pilihannya.
jenis kontrol bawaan. Ini memberi lebih banyak tekanan pada pemrogram untuk menggunakannya
tombol perintah untuk semua jenis kontrol, yang pada akhirnya dapat disalahgunakan
mereka lebih mungkin.

Menghindari Blooper 3

Kontrol tombol perintah di toolkit GUI adalah untuk menjalankan perintah atau memulai
acara ing. Mereka tampak ditekan hanya sebentar, tetapi kembali ke tampilan tak tertekan-
ance. Mereka tidak memiliki status persisten (Gambar 2.24).
Pengaturan ON / OFF harus disajikan dengan menggunakan kotak centang atau jenis lainnya
kontrol sakelar. Beberapa toolkit GUI menyediakan kontrol sakelar tujuan khusus
(Gambar 2.25), seperti sakelar Perluas / Kontrak untuk membuka dan menutup aux-
panel data atau sakelar rocker yang terlihat seperti sakelar lampu fisik.
Beberapa toolkit memungkinkan pengembang menentukan varian kontrol bawaan yang mempertahankan
perilaku kontrol tetapi memiliki penampilan yang berbeda. Ini bisa digunakan untuk
buat tombol sakelar tujuan khusus.

Gambar 2.24
Mencetak... Tempel Menyusun

Tombol perintah.

Halaman 81

Menggunakan kontrol yang salah 67

Gambar 2.25
berubah menjadi berubah menjadi

Tombol sakelar khusus.

Blooper 4: Menggunakan tab sebagai tombol radio

Banyak toolkit GUI menyediakan kontrol panel tab (juga disebut panel tab atau
notebook) untuk kasus di mana GUI memiliki lebih banyak pengaturan atau tampilan data daripada yang bisa
ditampilkan sekaligus. Panel tab mensimulasikan kartu tab seperti yang ada di resep
kotak. Mereka terdiri dari panel yang dilapiskan, ditampilkan satu per satu, dengan label
tab di sepanjang satu sisi yang sesuai dengan panel. Saat pengguna mengklik tab, file
panel yang sesuai muncul di "depan" tumpukan. Panel tab adalah salah satu caranya
untuk mengatur banyak informasi dan kontrol ke dalam ruang yang relatif padat.

Blooper itu

Tab sering disalahgunakan sebagai tombol radio: untuk menampilkan pilihan yang mempengaruhi
aplikasi akan melakukannya, bukan hanya memilih panel mana yang akan ditampilkan.
Misalnya, Anda sedang mendesain kotak dialog untuk editor dokumen

[Link] 58/315
26/2/2021 Tanpa judul
Fungsi Save As (Gambar 2.26). Kotak dialog Save As meminta pengguna untuk des-
tination nama file dan parameter lainnya dan, ketika pengguna mengklik OK, menyimpan file

Gambar 2.26
Documaster: Simpan Sebagai ...

Dir: C: \ MyDocs \ Business \ Money Format:

.. DocuMaster HTML RTF Teks

Laporan 3Q99
Laporan. 2Q99
Laporan. 1Q99
Laporan. 4Q98 Versi: kapan: 7.3

Kata kunci: keuangan, status, triwulanan

Buat Salinan Cadangan

File: Report.4Q99

baik Membatalkan Tolong

Blooper: tab disalahgunakan sebagai pengaturan nilai, bukan hanya untuk navigasi.

Halaman 82

68 Bab 2 GUI Control Bloopers

dokumen. Kotak dialog ini memungkinkan pengguna memilih format untuk menyimpan dokumen:
format editor dokumen sendiri, HTML, Rich Text Format, atau teks biasa. Kamu
mungkin mendesain kotak dialog Save As untuk menampilkan satu set panel tab — satu untuk
setiap format data yang tersedia. Anda mungkin mengharapkan pengguna untuk mengklik tab yang diinginkan
format, atur pengaturan khusus format panel itu, dan kemudian klik tombol "OK".
Masalahnya, desain ini melanggar ekspektasi pengguna bahwa ada tab
hanya untuk beralih antar panel. Di kotak dialog ini, format yang digunakan untuk menyimpan
dokumen tergantung pada panel tab mana saja yang berada "di depan" saat
pengguna mengklik OK. Sebagian besar pengguna akan bingung dan kesal dengan ini. Beberapa
mungkin mengklik tab, melihat pengaturan di sana dan mengatur beberapa, lalu klik
tab lain, lihat pengaturan di sana, putuskan untuk tidak melakukan apa pun pada tab itu
panel, lalu klik OK, dan kecewa ketika program menggunakan format file
sesuai dengan panel tab terakhir yang dilihat. Pengguna juga pasti kesal
data yang mereka masukkan di salah satu panel tab diabaikan hanya karena itu
panel tidak ada di depan saat mereka mengklik OK.

Alasan umum

Alasan umum untuk menggunakan tab sebagai pengaturan adalah kontrol pilihan lain, seperti itu
karena tombol radio dan menu tarik-turun, digunakan untuk navigasi dan data
pengaturan. Ini adalah kasus di mana mengubah tombol radio atau menu tarik-turun
nilai menyebabkan pengaturan lain muncul atau hilang (Gambar 2.27). Berdasarkan
alasan ini, tab hanyalah pengaturan pilihan lain.
Ya, tombol radio dan menu dropdown terkadang mengontrol keberadaan atau
tidak adanya pengaturan lain. Ya, tab adalah semacam pengaturan pilihan. Namun, menggunakan
tab untuk lebih dari navigasi melanggar harapan pengguna, dan itu adalah orang-orang expecta-
tions itu penting. Pengguna tidak suka saat mengubah tab mengubah data atau memengaruhi
perilaku aplikasi. Mereka tidak suka jika pengaturan pada panel tab masuk
berpengaruh hanya karena mereka beralih ke panel lain. Harapan pengguna tentang radio
tombol dan menu lebih fleksibel dari yang diharapkan tentang panel tab.

Navigasi vs. pengungkapan progresif

Tombol radio atau menu yang mempengaruhi visibilitas pengaturan lain tidak terutama
navigasi. Mereka adalah contoh dari prinsip desain UI yang mapan

Gambar 2.27
Ukuran huruf: 8 10 12 16 18 Lain:

Ukuran huruf: 8 10 12 16 18 Lain:

Bidang teks "Lainnya" hanya muncul saat tombol radio disetel ke "Lainnya".

[Link] 59/315
26/2/2021 Tanpa judul

Halaman 83

Menggunakan kontrol yang salah 69

"Pengungkapan progresif": menyembunyikan detail hingga relevan (Prinsip Dasar 3,

halaman 26).
Misalnya, pertimbangkan kotak dialog untuk mengatur properti font teks. Font
ukuran dapat diatur dengan tombol radio atau menu dropdown. Pilihannya
mungkin menyertakan "Lainnya" dengan bidang teks sehingga pengguna dapat menentukan font yang tidak terdaftar
ukuran. Bidang teks itu dapat disembunyikan hingga pilihan ukuran font disetel ke
"Lain." Pengaturan ukuran font ini bukan untuk navigasi; itu adalah sebuah aplikasi
pengaturan. Ini memiliki efek samping mengubah visibilitas teks "Lainnya"
bidang.

Menghindari Blooper 4

Tab adalah kontrol navigasi murni . Mereka mempengaruhi di mana pengguna berada di aplikasi-
tion: pengaturan mana yang terlihat. Mereka tidak seharusnya menjadi pengaturan. Memilih
satu panel dari satu set panel tab untuk ditampilkan seharusnya tidak mempengaruhi aplikasi
data atau memiliki konsekuensi untuk perilaku selanjutnya. Penggunaan tab yang benar
panel ditampilkan di kotak dialog Properti Mouse dari Microsoft Windows
(Gambar 2.28).
Kotak dialog Save As… yang dibahas sebelumnya (Gambar 2.26) akan dibuat
lebih masuk akal bagi pengguna jika tab diganti dengan menu tarik-turun atau
tombol radio, dengan kotak grup berlabel untuk menampilkan format tertentu
pengaturan (Gambar 2.29). Pengguna akan cenderung menafsirkan
pilihan Format sebagai pengaturan aplikasi yang menentukan bagaimana file tersebut
diselamatkan.

Gambar 2.28

Properti Mouse Microsoft Windows Vista: tab yang digunakan hanya untuk navigasi.

Halaman 84

70 Bab 2 GUI Control Bloopers

Gambar 2.29
Documaster: Simpan Sebagai ...

Dir: C: \ MyDocs \ Business \ Money Format: Documaster

.. Rincian Format Documaster

Laporan 3Q99
Laporan. 2Q99
Laporan. 1Q99
Laporan. 4Q98 Versi: kapan: 7.3

[Link] 60/315
26/2/2021 Tanpa judul

Kata kunci: keuangan, status, triwulanan

Buat Salinan Cadangan

File: Report.4Q99

baik Membatalkan Tolong

Menu yang digunakan untuk menavigasi di antara berbagai grup setelan.

Blooper 5: Terlalu banyak tab

Tujuan penting dari panel tab adalah untuk menghemat ruang dengan cara melapisi yang berbeda
panel kontrol atau informasi sehingga mereka berbagi bidang layar yang sama. Tab
panel menyediakan antarmuka pengguna untuk ini yang memanfaatkan keakraban pengguna
dengan lembar tab, buku catatan, dan folder.
Namun, tab itu sendiri membutuhkan ruang yang signifikan. Tidak perlu banyak
tab sebelum ruang yang tersedia di sepanjang salah satu tepi (biasanya bagian atas) dari tumpukan
panel sudah penuh. Bloopers terjadi saat tab "diskalakan" di luar batas itu. Sana
bukanlah solusi yang baik, meski sudah banyak yang mencoba.

Variasi A: Mengibaskan anjing

Salah satu solusi palsu adalah memperluas panel untuk memungkinkan lebih banyak tab. Tapi masing-masing tab
panel hanya memiliki sejumlah kontrol atau data untuk ditampilkan, sehingga memperluas
ruang panel dapat menghasilkan ruang yang terbuang pada banyak panel di set (Gambar
2.30). Jika Anda melakukannya, Anda telah melewati batas dari menggunakan tab untuk menghemat ruang
membuang-buang ruang untuk menggunakan tab. Ekornya mengibas-ngibaskan anjing.

Variasi B: Tab di sebelah kiri kita, tab di sebelah kanan

dari kita, tab di sekitar kita!

Solusi palsu kedua adalah meletakkan tab di lebih dari satu sisi, misalnya, di bawah
sisi kiri atau kanan panel. Dan mengapa berhenti di situ? Mengapa tidak lari mereka melintasi
bawah juga (Gambar 2.31)! Orang tidak pernah melihat ini di dunia fisik, tetapi siapa
kekuatiran? Ini adalah layar komputer; kita bisa melakukan apapun yang kita mau, bukan?

Halaman 85

Menggunakan kontrol yang salah 71

Gambar 2.30
WriteMaster: Default

Pencetakan Format Memeriksa Toolbar Makro

Orientasi: Potret Pemandangan

Kualitas: Minuman Normal Mewah

Warna Tinta: Hitam

baik Membatalkan Tolong

Terlalu banyak tab membuat setiap panel lebih lebar dari yang dibutuhkan isinya, membuang-buang ruang.

Gambar 2.31
WriteMaster: Default

Pencetakan Format Memeriksa Tabel

Orientasi: Potret Pemandangan

Kualitas: Minuman Normal Mewah

Warna Tinta: Hitam

Toolbar Makro
baik Membatalkan Tolong

[Link] 61/315
26/2/2021 Tanpa judul

Terlalu banyak tab, jadi tab ditempatkan di atas dan di bawah panel tab.

Masalahnya adalah bahwa pengguna menganggap panel seperti itu sebagai hierarki, dengan ekstensi
tab di bagian atas sebagai kategori utama dan di bagian bawah atau samping sebagai
subkategori. Mereka akan. Cobalah. Selain masalah kegunaan itu, tampilan-
Tab di beberapa tepi panel terlihat buruk.

Variasi C: Shrt lbls

Beberapa desainer mengurangi lebar setiap tab dengan menyingkat label tab,
misalnya, menggunakan "PS" daripada "Postscript" (Gambar 2.32). Pengorbanan ini

Halaman 86

72 Bab 2 GUI Control Bloopers

Gambar 2.32
GraphPro: Opsi

EFX Jml PS DVL LX FOO

Terlalu banyak tab, sehingga label tab disingkat; pengguna harus mempelajari apa yang mereka maksud.

kejelasan untuk mencapai tab yang lebih sempit dan begitu juga kasus lain dari ekor yang mengibas-ngibaskan
anjing. Ini juga mungkin tidak berfungsi dalam semua bahasa.
Cara lain untuk mempersempit tab adalah dengan memecah labelnya menjadi dua baris (Gambar
2.33). Ini tidak terlalu buruk, tetapi beberapa toolkit GUI hanya mendukung tab satu baris
label. Pendekatan ini juga bekerja hanya jika label memiliki lebih dari satu kata;
memecah kata menjadi dua baris membuatnya sulit dibaca. Ini juga mungkin tidak berhasil
dalam semua bahasa. Akhirnya, campuran label satu baris dan dua baris terlihat buruk.

Variasi D: Tab menari

Solusi palsu paling populer adalah menampilkan beberapa baris tab. Seolah-olah
pengguna melihat ke laci file folder manila tab, melihat file
tab di bagian atas semua folder dari depan ke belakang laci. Itu bagus
ide, tetapi memiliki cacat serius.
Saat tab berada dalam beberapa baris, memilih tab dari baris mana pun selain
baris pertama tidak hanya menampilkan panelnya tetapi juga biasanya menggeser baris tab itu jadi itu
sekarang baris tab pertama . Jika Anda mengklik tab di baris kedua, baris itu langsung
memindahkan — langsung dari bawah penunjuk Anda — ke baris pertama. Sementara itu,
baris tab yang pertama kali bertukar dengan baris yang Anda klik atau geser ke
baris belakang.
Jendela Opsi Microsoft Windows Media Player memiliki dua baris tab.
Ketika tab Rip Music ditampilkan, tab Privacy ada di baris belakang (Gambar
2.34A). Mengeklik tab Privasi membawa barisnya ke depan, memindahkan baris lainnya
baris ke belakang (Gambar 2.34B).
Ini secara singkat membingungkan pengguna. Mereka mengklik tab dan sepertinya tab itu lenyap.
Secara sadar, mereka tahu apa yang terjadi, tetapi pikiran bawah sadar mereka hanya sebentar

Gambar 2.33
StockMinder: Tampilkan Saham - JCPenny

Harga tanggal Pasar Komisi

Sejarah Batasan Membeli Peringkat sions Catatan

Terlalu banyak tab, sehingga beberapa label tab dibuat menggunakan dua baris.

[Link] 62/315
26/2/2021 Tanpa judul
Halaman 87

Menggunakan kontrol yang salah 73

Gambar 2.34

SEBUAH B

Windows Media Player: tab menari. Mengklik tab Privacy menukar dua baris tab.

bingung dan mata mereka berputar tanpa sadar. Setelah setengah detik, mereka
pikiran sadar masuk dan mereka menemukan tab itu lagi.
Pengguna tidak bisa melupakan disorientasi singkat yang disebabkan oleh tab menari. Mereka
pengalaman sebelumnya dan berkelanjutan dengan satu baris tab (serta dengan
tab di dunia fisik) mendukung harapan mereka bahwa tab tetap ada saat
terpilih. Tidak ada pertanyaan: orang tidak menyukai banyak baris tab.
Jika tab menari membingungkan pengguna, sepertinya Anda bisa memperbaikinya dengan
tidak hanya memindahkan baris tab yang dipilih ke depan. Namun, kemudian tab
tidak akan terlihat terhubung ke panel yang ditampilkan, sehingga menyulitkan pengguna untuk melihatnya
tab mana yang dipilih.

Menghindari Blooper 5

Untuk menghindari kesalahan besar ini, ikuti aturan praktis berikut.

Pertahankan jumlah tab kecil

Jika Anda memiliki begitu banyak panel sehingga tabnya tidak muat dalam satu baris, sebenarnya
Masalahnya adalah Anda memiliki terlalu banyak panel. Atur ulang menjadi lebih sedikit panel,
membutuhkan lebih sedikit tab.
Situs Web [Link] menggunakan panel tab. Banyaknya informasi
Mation yang tersedia di situs telah diatur menjadi sejumlah
panel tab (Gambar 2.35).

Halaman 88

74 Bab 2 GUI Control Bloopers

Gambar 2.35

[Link]: satu baris tab.

Gunakan kontrol lain sebagai pengganti tab

[Link] 63/315
26/2/2021 Tanpa judul

Cara lain untuk menghindari terlalu banyak tab adalah dengan tidak menggunakan tab. Gunakan tombol radio,
menu dropdown, atau daftar gulir untuk beralih di antara alternatif yang ditampilkan
panel.
Pada tahun 1999 [Link] mengelompokkan semua produknya ke dalam satu baris tab
(Gambar 2.36), tetapi akhirnya jumlah kategori bertambah terlalu banyak untuk tab
menjadi cara yang baik untuk mempresentasikannya.
Pada akhir 2006, Amazon memiliki 35 kategori produk, terlalu banyak untuk disajikan
untungnya sebagai tab. Sebaliknya, halaman beranda mereka memiliki tiga tab, salah satunya membaca
“Lihat Semua 35 Kategori Produk” (Gambar 2.37). Saat penunjuk berada di atas ini
tab, jendela pop-up muncul dengan tautan untuk semua kategori. Mengklik
Tab membawa pengguna ke halaman yang menampilkan semua kategori.
Pada akhir 2003, banyak fungsi NetScanTools 8.0, admin jaringan-
produk registrasi, diatur ke dalam deretan tab menari yang mengerikan
(Gambar 2.38A). Tiga tahun kemudian, versi 10.0 menampilkan fungsinya sebagai a
daftar gulir yang jauh lebih masuk akal (Gambar 2.38B).

Gambar 2.36

[Link] (1999): banyak produk situs diatur ke dalam delapan kategori, ditampilkan sebagai tab.

Halaman 89

Menggunakan kontrol yang salah 75

Gambar 2.37

SEBUAH

B
[Link] (2006). (A) 35 kategori — terlalu banyak untuk tab. (B) Kategori di pop-up, bukan tab.

Perlebar panel sedikit

Jika sekumpulan tab sedikit terlalu lebar untuk dimasukkan dalam satu baris di seluruh ruang yang tersedia,
Anda dapat memperluas seluruh panel, dengan mengorbankan sebagian ruang itu
tab dimaksudkan untuk menyimpan. Pendekatan ini harus digunakan hanya sebagai pilihan terakhir
untuk alasan yang dijelaskan di bawah Variasi A (di atas) dan kemudian hanya jika ekstra
ruang horizontal yang dibutuhkan sangat kecil.

Jangan pernah menggunakan tab menari

[Link] 64/315
26/2/2021 Tanpa judul

Beberapa baris tab, dengan baris tab yang tidak dapat dihindarkan, seharusnya tidak pernah
digunakan. Mereka melanggar dua prinsip desain GUI lama yang terpisah: (1) file
layar milik pengguna dan (2) mempertahankan inersia layar (Prinsip Dasar 7,
halaman 41, dan Blooper 49, halaman 277).

Halaman 90

76 Bab 2 GUI Control Bloopers

Gambar 2.38

NetScanTools. (A) Versi 8 (2003), diatur oleh tab. (B) Versi 10 (2006), diorganisir oleh
daftar gulir.

Halaman 91

Menggunakan kontrol yang salah 77

[Link] 65/315
26/2/2021 Tanpa judul
Blooper 6: Menggunakan kontrol input untuk data hanya-tampilan

Kesalahan besar yang menjadi umum dalam beberapa tahun terakhir menggunakan kontrol masukan — periksa-
kotak, tombol radio, kolom teks, dll — untuk menampilkan data yang tidak dapat diubah oleh pengguna. Ini mengacu
ke kontrol yang tidak pernah bisa diedit , bukan ke kontrol yang sementara tidak aktif (berwarna abu-abu).
Formulir "Email Us" situs lelang [Link] melakukan kesalahan besar dua kali
(Gambar 2.39). Pertama, ini menggunakan kotak centang untuk menandai bidang "Wajib". Pengguna tidak bisa

Gambar 2.39

[Link]: kontrol input yang disalahgunakan untuk menampilkan data yang tidak dapat diedit. Tanda kotak centang diperlukan
bidang. Area teks "Instruksi Khusus" menampilkan instruksi yang tidak dapat diedit.

Halaman 92

78 Bab 2 GUI Control Bloopers

ubah kotak centang ini; mereka hanya indikator. Lebih jauh ke bawah formulir adalah a
kotak teks berlabel "Instruksi Khusus". Ini adalah instruksi untuk mengisi
untuk m. Mereka berada dalam kotak entri teks seperti yang ada di bawahnya, tetapi tidak dapat diedit.
Sebagian dari masalahnya adalah bahwa beberapa toolkit GUI memungkinkan kontrol diatur ke
“Tidak bisa diedit.” Ini mendorong pengembang untuk menyalahgunakan kontrol yang tampak dapat diedit
untuk menampilkan data yang tidak dapat diedit.

Bidang teks yang tidak dapat diedit

Bidang teks adalah kontrol masukan yang paling sering disalahgunakan untuk menyajikan noned-
data yang layak. Contoh terjadi di Regional dan Bahasa Microsoft Windows
jendela preferensi. Bidang teks "Sampel" menunjukkan format data untuk
bahasa dan wilayah saat ini ditampilkan pada menu (Gambar 2.40).

Alasan terjadinya blooper

Pengembang GUI biasanya melakukan kesalahan besar ini untuk salah satu dari beberapa yang berbeda
alasan:

Gambar 2.40

[Link] 66/315
26/2/2021 Tanpa judul

Opsi Regional dan Bahasa Microsoft Windows memiliki bidang teks yang tidak dapat diedit.

Halaman 93

Menggunakan kontrol yang salah 79

1. Mengatur kemampuan edit tetapi bukan penampilan . Kontrol masukan di sebagian besar perangkat GUI
memiliki atribut yang mengontrol kemampuan editnya. Sayangnya, banyak toolkit
tidak secara otomatis mengubah tampilan kontrol yang tidak dapat diedit: mereka
terus terlihat dapat diedit kecuali programmer secara eksplisit mengatur tampilan
atribut, seperti visibilitas batas atau warna latar interior. Dapat diprediksi,
programmer sering mengatur kontrol ke noneditable dan tidak mengubah tampilannya-
atribut ance. Hasilnya adalah kesalahan besar ini.
2. GUI toolkit membiarkan saya melakukannya, jadi itu harus baik-baik saja . Banyak programmer tidak melakukannya
tahu pedoman (karena mereka belum pernah melihatnya) dan berasumsi bahwa jika a
Toolkit GUI memungkinkan mereka melakukan sesuatu, itu harus baik-baik saja. Asumsi buruk!
3. Tapi saya membuatnya tidak aktif . Kebanyakan toolkit GUI memungkinkan kontrol disetel ke inac-
tive: mereka tidak menanggapi tindakan pengguna sampai mereka kembali ke aktif .
Kontrol yang tidak aktif tampak berwarna abu-abu. Namun, data yang tidak dapat diedit berbeda
dari kontrol masukan tidak aktif dan akan terlihat berbeda. Saat GUI toolkit
menyediakan atribut aktif / tidak aktif dan atribut yang dapat diedit
pada kontrol, beberapa programmer tidak tahu mana yang harus digunakan dan digunakan
salah satu.
4. Label hanya untuk label, bukan? Alasan keempat berasal dari menyesatkan
nama kontrol. Kebanyakan toolkit GUI memiliki kontrol untuk menampilkan noneditable
teks pada panel. Sayangnya, banyak toolkit menyebutnya sebagai "label". Ini menunjukkan itu
kontrol harus digunakan hanya untuk teks yang memberi label sesuatu. Itu, pada gilirannya,
menyarankan bahwa teks yang tidak berfungsi sebagai label, seperti data hanya-baca,
harus ditampilkan menggunakan kontrol lain . Satu-satunya kandidat lainnya untuk
menampilkan teks adalah bidang teks yang tidak dapat diedit. Makanya, blooper. Di beberapa GUI
toolkit, kontrol teks yang tidak dapat diedit memiliki nama yang lebih baik: "item teks", "statis
teks, "atau" teks ".
5. Itu harus terlihat sama dengan layar yang dapat diedit . Aplikasi mungkin menampilkan
data yang sama di beberapa tempat, tetapi hanya dapat diedit di beberapa tempat. Sedemikian
kasus, pengembang terkadang menampilkan semua nilai sebagai bidang teks untuk "con-
sistency. ” Ini adalah konsistensi dari sudut pandang pengembang. Untuk pengguna itu
secara konsisten.
6. Hal ini tidak secara langsung dapat diedit-hanya-pengguna . Mungkin pengguna bisa mengedit data, tapi
hanya dengan memunculkan jendela Edit, bukan dengan mengklik dan mengetik di bidang
diri. National Geographic Trip Planner memberikan contoh (Gambar 2.41).

Gambar 2.41

Perencana Perjalanan National Geographic: bidang Asal dan Tujuan perjalanan terlihat seperti secara langsung
teks yang dapat diedit, tetapi hanya dapat diedit secara tidak langsung melalui tombol "Pilih Kota ..." dan kotak dialog.

[Link] 67/315
26/2/2021 Tanpa judul

Halaman 94

80 Bab 2 GUI Control Bloopers

7. Datanya bervariasi . Alasan terakhir untuk data yang tidak dapat diedit di editable-
melihat kontrol adalah bahwa data dalam kontrol bervariasi. [Link]
Halaman "Email Us" digunakan untuk beberapa tujuan: meminta Pelanggan
Dukungan, melaporkan masalah situs Web, dll. Bidang yang wajib diisi dan
instruksi khusus bervariasi antara berbagai penggunaan formulir. Karena
tentang hal ini, perancang halaman ini mungkin merasa tidak masalah untuk menggunakannya
kotak centang yang tidak dapat diedit pengguna untuk menandai bidang wajib dan non-
area teks yang dapat diedit pengguna untuk memuat instruksi khusus. Salah!
Hanya karena datanya bervariasi tidak memaafkan penggunaan kontrol itu
menyesatkan pengguna.

Menghindari Blooper 6

Data yang tidak dapat diedit tidak boleh ditampilkan dalam kontrol yang terlihat dapat diedit atau
dapat dioperasikan.
Kotak centang, tombol radio, menu, slider, dan sejenisnya tidak boleh ada
digunakan untuk data yang tidak dapat diedit karena terlihat dapat dioperasikan. Bahkan jika mereka tidak aktif
(berwarna abu-abu), mereka terlihat seperti dapat diaktifkan, dan pengguna akan sia-sia
waktu mencoba melakukannya.
Hindari bidang teks yang tidak dapat diedit kecuali mereka dapat ditampilkan tanpa batas,
seperti label (Gambar 2.42). Pengguna tidak membedakan teks berbatasan yang tidak dapat diedit
bidang dari yang dinonaktifkan sementara. Ketika data tekstual hanya untuk tampilan, itu
harus ditampilkan menggunakan kontrol teks (label).

Gambar 2.42

Nama Keluarga: Johnson Bidang teks aktif

SEBUAH

Nama Keluarga: Johnson Bidang teks tidak aktif

Nama Keluarga: Johnson Teks yang tidak dapat diedit

Bidang teks aktif, tidak aktif, dan tidak dapat diedit.

Halaman 95

Menggunakan kontrol yang salah 81

Beberapa contoh menghindari blooper

Sedikit pengeditan gambar menunjukkan bagaimana [Link] (Gambar 2.43A) dan Windows
Jendela Regional and Language Options (Gambar 2.43B) akan terlihat jika digunakan
kontrol teks statis daripada tombol radio dan bidang teks yang tidak dapat diedit.

[Link] 68/315
26/2/2021 Tanpa judul

Gambar 2.43

Koreksi blooper di [Link] dan di Microsoft Windows Regional & Language

Pilihan. (A) Formulir uBid yang dikoreksi memiliki tanda centang teks dan teks instruksi yang tidak dapat diedit
langsung di latar belakang.
(Lanjutan )

Halaman 96

82 Bab 2 GUI Control Bloopers

Gambar 2.43
(Lanjutan )

(B) Dalam opsi Wilayah dan Bahasa Windows, bidang teks diganti dengan "label" teks.

Aplikasi Microsoft Office memiliki jendela yang menampilkan properti dokumen.

[Link] 69/315
26/2/2021 Tanpa judul
erties. Beberapa
menampilkan properti
properti dapat
yang diedit
dapat dandalam
diedit beberapa tidak.
bidang teksKantor dengan
(Gambar benar
2.44A) dan data yang tidak dapat diedit
sebagai teks “label” (Gambar 2.44B).

Kejahatan yang diperlukan: menggulir kotak teks lama

teks yang tidak dapat diedit

Satu situasi di mana bidang teks yang tidak dapat diedit tampak sebagai kejahatan yang diperlukan adalah kapan
teks panjang harus disajikan pada layar perangkat lunak atau halaman Web yang relatif pendek.
Contoh umumnya adalah:

■
menerima pesan email yang ditampilkan oleh perangkat lunak email;
■ perjanjian lisensi perangkat lunak ditampilkan selama instalasi desktop
perangkat lunak;

Halaman 97

Menggunakan kontrol yang salah 83

Gambar 2.44

Properti Dokumen Microsoft Office: data yang ditampilkan dengan benar. (A) Dapat diedit. (B) Tidak dapat diedit.

■
kebijakan penggunaan, perjanjian pengguna, kontrak, dan dokumen hukum lainnya dis-
dimainkan oleh situs web keanggotaan dan e-commerce.

Dalam semua kasus ini, teks terlalu panjang untuk muat ke jendela atau halaman, jadi itu harus
ditampilkan dalam kontrol gulir. Contohnya datang dari situs Web Lego
(Gambar 2.45).
Perjanjian lisensi perangkat lunak, kontrak layanan, dan dokumen hukum lainnya
sangat jelas tidak dapat diedit sehingga hanya sedikit orang yang mencoba mengetikkannya. Namun,
hampir setiap pengguna komputer mencoba mengedit pesan email yang diterima. Itu
Program email Eudora menampilkan pesan kesalahan saat pengguna mencoba melakukan itu
tanpa terlebih dahulu membuat pesan tersebut dapat diedit.
Ini dapat diterima karena mencoba mengetik ke dalam pesan email yang diterima atau
perjanjian lisensi bukanlah "kesalahan" yang mahal bagi pengguna: umpan balik — tidak ada pengaruh
mengetik atau pesan kesalahan — langsung dan tidak menyakitkan. Di sisi lain, a
panel kontrol atau formulir entri data yang penuh dengan bidang teks yang tampak tidak dapat diedit
menampilkan teks pendek tidak dapat diterima: ini berpotensi menipu banyak pengguna
kali per halaman, dan untuk apa?

[Link] 70/315
26/2/2021 Tanpa judul
Halaman 98

84 Bab 2 GUI Control Bloopers

Gambar 2.45

L [Link]: area teks bergulir menampilkan dokumen hukum panjang yang tidak dapat diedit.

Blooper 7: Menggunakan bidang teks secara berlebihan untuk input yang dibatasi

Bidang teks adalah kontrol interaktif yang paling banyak digunakan di GUI. Ini sudah berakhir-
bekas. Pengguna aplikasi desktop dan situs Web e-commerce sering kali dipaksa
untuk menggunakan bidang teks untuk memasukkan data yang sangat terbatas seperti waktu, volume
level, tanggal, nomor telepon, kode pos, jumlah uang, dan nomor
anak tanggungan.
Bidang teks terlalu tidak terstruktur untuk data yang dibatasi. Mereka memberi pengguna sedikit
panduan tentang format data yang valid dan memarahi pengguna untuk nilai yang tidak valid setelahnya
nilai telah dimasukkan. Pesan kesalahan tidak akan diperlukan jika input
kontrol mengizinkan pengguna untuk memasukkan hanya data yang valid.
Formulir pendaftaran pelanggan di [Link] dan [Link] tanyakan reg-
istran untuk negara bagian atau provinsi asalnya. Alih-alih menyediakan menu AS
negara bagian dan provinsi Kanada, keduanya menggunakan bidang teks untuk data itu (Gambar
2.46), hampir menjamin kesalahan entri.

Mitos: Bidang teks lebih mudah dikodekan

Alasan umum untuk menggunakan bidang teks adalah karena lebih mudah dikodekan daripada data-
kontrol masukan jenis khusus. Bahkan mengabaikan masalah kemudahan program-
ming tidak boleh memprioritaskan kemudahan penggunaan, alasannya buruk karena memang demikian
salah.
Menggunakan bidang teks untuk data terstruktur mengharuskan Anda menemukan atau menulis pengurai untuk
bidang untuk memeriksa apakah nilai yang dimasukkan valid. Pengurai mungkin menerima variasi
format atau mungkin hanya menerima satu format (Blooper 9, halaman 94). Namun, jika file
kontrol dikhususkan untuk jenis masukan, tidak diperlukan pengurai.

Halaman 99

Menggunakan kontrol yang salah 85

Gambar 2.46

[Link] 71/315
26/2/2021 Tanpa judul

Formulir pendaftaran menggunakan bidang teks untuk negara bagian / provinsi. (A) [Link]. (B) [Link].

Banyak pemrogram yang cenderung langsung memikirkan data apa pun

masalah masukan dalam hal bidang teks dan parser. Ini karena kebanyakan pro-
para ahli tata bahasa mempelajari keahlian mereka di sekolah dengan menulis program pemrosesan teks — bukan
Program GUI — sebagai tugas kelas.

Sumber utama blooper: konversi TTY-ke-GUI

Penggunaan berlebihan bidang teks sangat umum terjadi pada perangkat lunak yang diubah menjadi
gaya antarmuka GUI dari perangkat lunak pra-GUI yang lebih lama yang memiliki antarmuka pengguna
berdasarkan petunjuk tekstual, perintah yang diketik, dan argumen baris perintah.
Antarmuka pra-GUI semacam itu biasanya disebut pengguna "teletipe kaca" atau "TTY"
antarmuka. Sayangnya, tidak semua konversi TTY-ke-GUI dilakukan dengan hati-hati.
Beberapa telah dilakukan dengan sangat cepat, dengan sedikit pertimbangan bagaimana GUI-nya
harus berbeda dari antarmuka pengguna TTY.
Hasilnya adalah "TTY GUI": antarmuka pengguna yang pada dasarnya membuat ulang gelas
Teletype UI menggunakan kontrol GUI. Ini terdiri dari panel bidang teks di mana
data tipe pengguna (Gambar 2.47). Di mana antarmuka pengguna TTY memiliki prompt data
(misalnya, "Masukkan nama aplikasi:"), GUI memiliki bidang teks berlabel. Di TTY GUI, file
bidang teks berkuasa; Kontrol GUI lainnya — slider, tombol radio, dan sebagainya
pada — jarang muncul. TTY GUI kehilangan inti dari GUI.

Halaman 100

86 Bab 2 GUI Control Bloopers

Gambar 2.47 UI berbasis prompt lama GUI TTY baru

Panggilan pengguna Ditampilkan saat
% Buat Janji Temu Buat Janji Temu
fungsi. perintah dipanggil

Masukkan appt. nama>

Janji:
Masukkan waktu mulai> Perintah muncul
satu per satu
Waktu mulai:
Masukkan durasi> setelah tipe pengguna
Durasi:
Menanggapi
Masuk pengingat> prompt sebelumnya
Lokasi:
dan menekan
Masukkan waktu tunggu pengingat>
KEMBALI. Peringatan:
Masukkan terlihat oleh>
Pengingat Waktu Pimpin:
Sinyal fungsi
Janji dibuat. itu sudah selesai.
Dapat dilihat oleh:
%
baik Membatalkan

Blooper: konversi TTY-ke-GUI yang berpikiran sederhana sering kali menghasilkan GUI yang terlalu banyak menggunakan bidang teks.

Menghindari Blooper 7

Gunakan bidang teks dengan hemat

Bidang teks harus digunakan hanya untuk data yang benar-benar tidak terstruktur, dalam bentuk bebas
teks. Contoh teks seperti itu adalah nama orang, kata sandi yang ditentukan pengguna, com-
ments, dan alasan transaksi. Contoh data yang tidak sepenuhnya gratis-
bentuknya adalah nomor telepon, nomor jaminan sosial, tanggal, negara bagian, kota, dan
keluarga font.

Alternatif untuk bidang teks

Sebagian besar perangkat GUI menyediakan kontrol masukan khusus yang dapat Anda gunakan sebagai gantinya
bidang teks untuk pengumpulan data yang sangat dibatasi dari pengguna. Anda juga bisa
membangun kontrol khusus input dari yang lebih sederhana.
Banyak anjungan tunai mandiri (ATM) di Amerika Serikat menggunakan mesin khusus
Kontrol entri "jumlah dolar" untuk menentukan penarikan, setoran, atau trans-
fers. Pengguna ATM yang ingin menyetor $ 35.75 tidak perlu mengetik "$ 35.75" atau
bahkan "35.75". Mereka hanya mengetik "3575" dan ATM memasukkan koma desimal

[Link] 72/315
26/2/2021 Tanpa judul
tempat yang tepat. Digit pertama, “3”, muncul sebagai 0,03 hingga digit berikutnya “5” adalah
masuk, dll. Ini berhasil.
Pendekatan lainnya adalah dengan menggunakan beberapa bidang teks — satu untuk setiap bagian
data. Ini menghilangkan kebutuhan pengguna untuk mengetik karakter tanda baca dan
mengurangi kemungkinan kesalahan sintaks. Misalnya, kolom nomor telepon bisa
dipecah menjadi beberapa bidang: kode negara, kode area, pertukaran, dan angka akhir.
Tanggal dapat dibagi menjadi hari, bulan, dan tahun. Label antar bidang
dapat memberikan tanda baca "built-in" (Gambar 2.48). Agar pendekatan ini berhasil, file

Halaman 101

Menggunakan kontrol yang salah 87

Gambar 2.48 Dari pada: Menggunakan:

Bulan Hari Tahun
Tanggal lahir: 4/21/52 Tanggal lahir: 4 21 52

Nomor telepon: (415) 555-1212 Telepon: (415) 555 - 1212

Untuk data terstruktur, gunakan kolom teks terstruktur (tersegmentasi).

detailnya harus tepat. Tombol Tab tentu saja memajukan fokus input ke
bidang berikutnya. Spasi mundur ke bidang sebelumnya juga harus diperbolehkan. Umumnya,
fokus masukan akan maju secara otomatis setelah karakter yang cukup
dimasukkan, tetapi ini mungkin bukan yang diharapkan pengguna di beberapa aplikasi.
Situs web Southwest Airlines menggunakan pendekatan ini untuk meningkatkan peluang mereka
mendapatkan alamat email yang valid dari pelanggan (Gambar 2.49).
Alternatif yang lebih canggih, tetapi lebih disukai, untuk bidang teks adalah dengan menggunakan data-
jenis kontrol khusus yang cocok dengan struktur data dan membatasi input
ke nilai yang valid. Anda dapat menggunakan penggeser untuk angka antara 1 dan 100, digital
jam untuk suatu waktu, tombol radio untuk sejumlah kecil seperti jumlah tanggungan,
atau menu gulir negara bagian untuk bidang Negara (Gambar 2.50). Bagaimanapun, "G" di
"GUI " adalah singkatan dari "grafis", bukan "tekstual".

Gambar 2.49

[Link]: bidang masukan tersegmentasi untuk alamat email.

Gambar 2.50

Untuk data terstruktur, gunakan kontrol terstruktur, yang dengannya pengguna hanya dapat memasukkan data yang valid.

Halaman 102

88 Bab 2 GUI Control Bloopers

[Link] 73/315
26/2/2021 Tanpa judul

Gambar 2.51

Kontrol masukan terstruktur untuk memasukkan data terstruktur. (A) [Link]. (B) [Link].

Formulir pendaftaran pelanggan di [Link] (Gambar 2.51A) dan penerbangan

formulir pencarian di [Link] (Gambar 2.51B) menggunakan kontrol khusus untuk struktur
tured data daripada memaksa pengguna untuk mengetik data ke dalam bidang teks.

Menggunakan kontrol secara salah

Tujuh kesalahan besar pertama adalah kasus penggunaan kontrol yang salah. Lima berikutnya
adalah kasus penggunaan kontrol yang buruk: kontrol tersebut mungkin sesuai, tetapi beberapa-
ada yang salah dengan fungsinya.

Halaman 103

Menggunakan kontrol secara salah 89

Blooper 8: Menu dinamis

Di sebagian besar aplikasi berbasis GUI, bar menu menampilkan sebagian besar atau semua aplikasi
perintah tion, diatur berdasarkan kategori, misalnya, File, Edit, View, Tools, Window,
Tolong. Di MacOS, bilah menu untuk aplikasi yang sedang aktif ada di bagian atas
di layar. Di Windows dan kebanyakan sistem jendela berbasis Unix, setiap aplikasi
batang menu kation ada di bagian atas jendela utamanya.
Pengembang GUI terkadang mencoba mengurangi ukuran dan kompleksitas menu-
menu bar dengan menambah dan menghapus item berdasarkan status aplikasi.
Perintah hanya ditampilkan di menu jika dapat diterapkan. Gambar 2.52
menunjukkan menu Edit program email hipotetis di mana perintah-perintah itu
bergantung pada aktivitas pengguna saat ini.
Ini mungkin tampak membantu, tetapi sebenarnya tidak. Ini membingungkan pengguna: jika mereka memindai file
menu pada waktu yang berbeda, mereka akan menemukan item menu yang berbeda. Jika pengguna belum
mempelajari perangkat lunak dengan sangat baik dan tidak tahu apa yang bergantung pada apa
jika tidak, mereka mungkin tidak mengerti mengapa beberapa perintah ada di beberapa
kali tetapi tidak yang lain. Mereka mungkin awalnya bahkan tidak menyadari bahwa menunya
perubahan.
Pengguna sering dihadapkan dengan aplikasi perangkat lunak yang melakukan kesalahan ini
mendengar keluhan saat mereka mencari dengan sia-sia melalui menu: “Di mana sih
apakah itu perintah Edit Formula? Saya tahu saya melihatnya di sini di suatu tempat. "

[Link] 74/315
26/2/2021 Tanpa judul

Gambar 2.52

Menu dinamis: item pada menu muncul dan menghilang tergantung pada pilihan saat ini.

Halaman 104

90 Bab 2 GUI Control Bloopers

Misalnya, uji kegunaan aplikasi klien menghasilkan yang berikut ini

pengamatan:

Beberapa peserta tes bingung dengan fakta bahwa Results —View

pilihan menghilang dari menu View ketika tidak ada Project yang terbuka. Demikian pula,
ada label menu tingkat atas yang muncul dan menghilang tergantung pada
tampilan apa yang dipilih.

Produk yang melakukan kesalahan besar ini adalah PowerBuilder Sybase, sebuah inter-
alat pembuat GUI yang aktif. Menu File memiliki lebih banyak item saat Database
Alat pembaca sedang digunakan (Gambar 2.53).
Microsoft Office terkenal karena menambahkan dan menghapus perintah dari
menu berdasarkan seberapa sering perintah telah digunakan baru-baru ini (Gambar
2.54). Sebagian besar pengguna Office MENONAKTIFKAN fitur ini jika mereka dapat mengetahui caranya.
Menu dinamis adalah gejala kesalahan yang lebih umum pada banyak perangkat lunak
pengembang membuat: berpikir dari dalam ke luar, bukan dari luar ke dalam (Prinsip Dasar 6,
halaman 37). Berpikir dari dalam ke luar adalah menggunakan pengetahuan sendiri tentang perangkat lunak

Gambar 2.53

Sybase PowerBuilder: item menu muncul dan menghilang tergantung pada status program.

[Link] 75/315
26/2/2021 Tanpa judul

Halaman 105

Menggunakan kontrol secara salah 91

Gambar 2.54

Microsoft Office: fitur "menu pintar" menambah dan menghapus item menu berdasarkan penggunaan terkini.

untuk menilai apakah tampilan dan kontrol masuk akal. Berpikir di luar ke dalam
membutuhkan pemikiran seperti pengguna: menilai arti dari tampilan dan kontrol
berdasarkan apa yang pengguna dapat diasumsikan tahu. Menu dinamis didasarkan pada
asumsi bahwa pengguna mengetahui atau mempelajari dengan cepat bagaimana dan mengapa item menu
muncul dan menghilang. Anggapan itu salah.

Sebagian besar aplikasi

Aplikasi yang tidak mendukung aplikasi plug-in atau dokumen majemuk memiliki
tidak ada alasan bagus untuk memiliki menu dinamis. Ini adalah aplikasi yang:

■
memiliki mode, dengan perintah menubar yang berbeda tersedia dalam berbagai cara
mode, atau
■ mendukung beberapa tipe data built-in yang berbeda, dengan perintah berbeda tersedia
dapat bergantung pada jenis data yang saat ini dipilih.

Pengembang aplikasi semacam itu bermaksud baik: mereka mencoba membantu pengguna dengan membatasi-
ing perintah apa yang tersedia dalam situasi yang berbeda. Masalahnya adalah add-
ing dan menghapus perintah menu membingungkan pengguna. Ini jauh lebih tidak membingungkan
untuk mengaktifkan dan menonaktifkan perintah, mengubah perintah yang saat ini tidak aktif
berlaku.

Halaman 106

92 Bab 2 GUI Control Bloopers

Aplikasi dokumen majemuk

Aplikasi yang mendukung plugin atau dokumen gabungan — menggunakan CORBA,

.NET, atau protokol JavaEE — memiliki alasan untuk menu dinamis:
ers tidak tahu sebelumnya apa semua perintah itu. Beberapa perintah
disediakan oleh plugin untuk mengedit jenis data tertentu. Inilah mengapa dinamis
menu biasa digunakan dalam aplikasi yang mengizinkan plug-in atau dokumen majemuk.

[Link] 76/315
26/2/2021 Tanpa judul
ments. Namun demikian, ada alternatif (lihat di bawah), jadi menu dinamis adalah a
blooper bahkan untuk aplikasi yang mengizinkan plug-in atau dokumen majemuk.

Menghindari Blooper 8

Menu menu harus stabil. Pengguna mulai mempelajari aplikasi dengan scan-
ning the menubar, melihat di mana dan berapa banyak perintah yang ada.
Menu dinamis menggagalkan strategi ini. Alih-alih menggagalkan pembelajaran yang bermanfaat ini
strategi, desain GUI harus mendukungnya. Oleh karena itu, perintah tidak boleh datang
dan pergi dari menu menubar. Nonaktifkan (abu-abu) perintah yang tidak dapat diterapkan
daripada menghapusnya (Gambar 2.55).

Gambar 2.55

Menu non-dinamis: item pada menu diaktifkan dan dinonaktifkan tergantung pada pilihan saat ini.

Halaman 107

Menggunakan kontrol secara salah 93

Tambah dan hapus menu, bukan item menu

Sebuah aplikasi dapat menambah dan menghapus seluruh menu menu saat pengguna berubah
seleksi. Mungkin jendela atau jenis konten tertentu memiliki perintah itu
berlaku hanya untuk itu. Saat pengguna bekerja dengan jendela atau konten itu, bukan
menambahkan perintah ke menu, ia dapat menambahkan menunya sendiri ke bilah menu. Kapan
jendela atau konten kehilangan fokus, menu menghilang dari bilah menu
(Gambar 2.56).
Pengguna dapat melihat menu tambahan muncul dan menghilang sebagai pilihan
perubahan. Sebaliknya, ketika item dalam menu muncul dan menghilang, perubahannya
tidak terlihat, jadi pengguna mempelajari dependensi secara perlahan, jika ada. Oleh karena itu, menambah
dan menghapus menu dari bilah menu adalah pendekatan yang disukai dalam aplikasi
yang mendukung plugin atau dokumen gabungan. Microsoft menggunakan pendekatan ini
banyak di versi Vista dari aplikasi Office-nya.
Menambah dan menghapus seluruh menu pada satu waktu mengharuskan Anda untuk berpikir keras
tentang apa yang masuk ke menu apa. Anda harus memilih dan mendesain menu
hati-hati untuk menghindari anomali seperti menu dengan nama atau menu yang sama
hanya satu item.
Jika Anda tidak ingin menambah dan menghapus menu, Anda dapat meminta plugin untuk
Tipe data "asing" untuk menggunakan perintah umum. Ini memungkinkan perintah sudah
dalam menu reguler aplikasi (seperti Buat, Pindahkan, Salin, Hapus) ke
berlaku untuk objek apa pun, dengan arti yang tepat dari sebuah perintah bergantung pada
objek. Ketika pemilihan berubah dari satu tipe data ke tipe lainnya, a
Perintah hapus pada menu dapat diubah untuk menunjuk ke tipe data baru
Hapus metode. Dari sudut pandang pengguna, menunya stabil, tetapi dari
dari sudut pandang perangkat lunak, satu perintah jenis tertentu telah diganti
oleh yang lain.

[Link] 77/315
26/2/2021 Tanpa judul

Gambar 2.56

Menu tabel muncul jika tabel dipilih.

Pengecualian: daftar "pilihan cepat"

Banyak aplikasi GUI memiliki menu yang menampilkan file yang baru saja diedit
membuka jendela, dan membookmark dokumen. Daftar pilihan cepat ini berubah
lembur. Selama perubahan menu menu dibatasi untuk pilih cepat
daftar, Anda tidak melanggar aturan desain.

Halaman 108

94 Bab 2 GUI Control Bloopers

DILBERT | © Scott Adams / Dist. oleh United Feature Syndicate, Inc.

Blooper 9: Bidang data tidak toleran

Jika aplikasi atau situs Web Anda berisi teks atau bidang tipe angka, itu harus
tentu saja periksa apa yang diketik orang untuk memastikannya valid. Bersikap ramah
dan bermanfaat, Anda harus mentolerir variasi yang wajar dalam jenis orang.
Sayangnya, bidang teks di banyak aplikasi dan situs Web tidak toleran.

Mudah dikodekan, sulit untuk dimasukkan

[Link] menolak nomor Frequent Flier yang dimasukkan dengan spasi — formatnya
United menggunakan kartu Frequent Flier dan pernyataan jarak tempuh (Gambar 2.57). Ini
tidak diragukan lagi membuat kode yang memeriksa angka-angka lebih mudah untuk ditulis, tetapi itu membuatnya
hidup sulit bagi pelanggan mereka.
Demikian pula, [Link] menolak nomor kartu kredit yang diketik dengan spasi (Gambar
2.58). Terakhir, terkadang penginstal perangkat lunak desktop dan fungsi registrasi
membutuhkan kode registrasi untuk dimasukkan secara berbeda dari kode yang muncul di
kemasan produk dan tanda terima unduhan.
Spasi ada di angka-angka itu karena suatu alasan . Mereka membuatnya lebih mudah untuk dipindai dan
periksa nomornya. Perangkat lunak harus memungkinkan pengguna memasukkannya.

Haruskah kita begitu tidak toleran?

Mengapa situs Web ini begitu tidak toleran dan tidak kooperatif? Mengapa mereka begitu
khususnya tentang tipe orang apa? Mengapa mereka bahkan tidak dapat menerima data dalam bentuk kom-
format mon — bahkan hanya satu — atau dalam format yang digunakan oleh perusahaan itu sendiri
di tempat lain?
Alasan yang umum adalah sulitnya menulis perangkat lunak untuk ditafsirkan dan diterima
data diketik dalam berbagai format. Mungkin, tapi pertimbangkan berapa jam pengguna
terbuang percuma untuk setiap programmer-hour yang dihemat. Kemudian pertimbangkan pendapatan yang hilang karena
bentuk intoleran dan mengganggu. Pertimbangkan kesan yang Anda berikan kepada pelanggan Anda
ketika situs Web atau aplikasi Anda menolak nomor yang diketik persis seperti yang muncul
dalam kemasan dan literatur Anda sendiri.

[Link] 78/315
26/2/2021 Tanpa judul
Halaman 109

Menggunakan kontrol secara salah 95

Gambar 2.57

SEBUAH

[Link]: menolak nomor Frequent Flier dengan spasi, format yang digunakan United di tempat lain.

Gambar 2.58

[Link]: menolak nomor kartu kredit dengan spasi.

Menghindari Blooper 9

Menyediakan kolom tipe-in yang ramah pengguna dan toleran tidaklah sulit:

■
Cocokkan panjang bidang dengan data: Panjang bidang yang terlihat harus menunjukkan
panjang data yang akan diketik. Tidak perlu persis, karena itu pasti
membuat formulir tampak compang-camping dan toh tidak layak karena variabel-
tipografi lebar. Yang penting adalah bahwa bidang harus: (a) cukup panjang untuk dipegang
data mereka dan (b) tidak lebih lama dari itu.

Halaman 110

96 Bab 2 GUI Control Bloopers

Gambar 2.59

[Link]: memberikan pola; tanggal segmen menjadi subbidang.

■
Terima format umum: Jika data memiliki format yang umum dan diterima, bolehkan
saya t. Jika ada beberapa format umum, izinkan sebanyak mungkin. SEBUAH
Bidang waktu dapat menerima waktu dalam salah satu format berikut: 12:30,
12:30, 12:30, 00:30, 00:30.
■ Terima format Anda sendiri: Terima data dalam format yang Anda gunakan di tempat lain.

[Link] 79/315
26/2/2021 Tanpa judul
Jika kode
bidang lisensi
kode dalamperangkat lunak
perangkat Anda
lunak terlihat
Anda dan diseperti "ZX-4563-33-QR,"
situs Web maka semua
Anda harus menerima lisensilisensi-
kode dalam format yang sama persis.
■
Waspadai menolak data yang sah: Pikirkan baik-baik tentang siapa yang mungkin menggunakan
formulir Anda. Pelanggan dari Kanada atau Inggris Raya, melalui pos
kode termasuk huruf, akan sangat kesal pada formulir pemesanan itu
membutuhkan "Kode Pos" tetapi huruf yang ditolak.
■ Buat huruf besar kecil tidak relevan: Jika Anda mengharapkan pengguna untuk mengetik kode yang menyertakan
huruf, dan jika kasus huruf tidak signifikan untuk data, izinkan pengguna untuk mengetik
baik huruf besar atau kecil ke dalam bidang.
■
Berikan pola: Berikan contoh format yang valid, misalnya, “DD / MM / YYYY”
atau “Contoh Serial #: QP-00275-5559.” Letakkan di dekat bidang: atas, bawah,
di samping, atau di dalam (abu-abu). [Link] memberikan contoh bidang data
diberi label dengan pola (Gambar 2.59).
■ Bidang teks struktur: Kecuali Anda harus menerima yang berbeda — mungkin internasional
tional — format, buat format yang Anda inginkan ke dalam formulir dengan menyusun
Lapangan. Misalnya, jika Anda yakin hanya nomor telepon AS
akan dimasukkan ke dalam formulir, Anda dapat menyusunnya menjadi bidang untuk kode area
dan nomor, seperti di [Link] (Gambar 2.59). Jika Anda mengelompokkan bidang teks menjadi
subbidang, Anda harus memudahkan pengguna untuk berpindah antarbidang. Itu
Tombol tab harus selalu memindahkan titik penyisipan dari satu bidang ke
lanjut. Formulir dapat secara otomatis memindahkan titik penyisipan ke bidang berikutnya
ketika jumlah karakter yang dibutuhkan telah diketik.

Blooper 10: Bidang input dan kontrol

tanpa default

Seperti dijelaskan di Bab 1, semakin sedikit pengguna yang harus menentukan untuk mendapatkan apa yang mereka inginkan,
lebih baik (Prinsip Dasar 4, halaman 32). Oleh karena itu, jika memungkinkan, bidang data

Halaman 111

Menggunakan kontrol secara salah 97

dan pilihan harus memiliki default. Defaultnya harus val-

ues. Ini memungkinkan pengguna memindai pengaturan, mengubah beberapa, dan melanjutkan.
Sayangnya, prinsip desain penting ini tidak diikuti secara luas. Banyak
aplikasi dan situs Web memiliki pengaturan tanpa default. Paling banter, kekuatan ini
pengguna untuk membuat keputusan dan pilihan eksplisit, menghabiskan waktu mereka. Lebih buruk,
pengguna mungkin tidak memperhatikan pengaturannya, mencoba melanjutkan, dan dimarahi
menghilangkan informasi yang diperlukan atau berakhir dengan hasil yang tidak diinginkan.

Alasan untuk menghilangkan default

Tentu saja, beberapa pengaturan tidak dapat menawarkan nilai default. Ada dua alasan
untuk ini:

■
Tidak ada default yang masuk akal: Misalnya, formulir pendaftaran situs Web mungkin
memiliki menu bagi pelamar untuk menunjukkan jenis kelamin mereka (pria atau wanita). Beberapa
organisasi akan memiliki dasar untuk menetapkan gender default. Demikian pula, orang-
ayo bergabung dengan suatu organisasi dapat ditanyakan tentang negara bagian asalnya. Jika organisasi
zasi nasional, seperti American Civil Liberties Union, ada
tidak ada dasar untuk menjadikan salah satu dari 50 Amerika Serikat sebagai default. Namun, jika file
organisasi adalah bab ACLU San Francisco, bidang Negara bagian harus default
ke California.
■ Persyaratan sosial, politik, atau hukum: Dalam beberapa situasi, desainer UI harus melakukannya
hindari menyinggung siapa pun dengan bersikap sombong. Bayangkan masalahnya a
Situs web pemerintah Kanada akan masuk jika, menawarkan pengunjung pilihan
Bahasa Inggris vs. Prancis, defaultnya ke bahasa Inggris. C'est un faux pas, n'est ce pas pas?

Meskipun demikian, sebagian besar pengaturan harus memiliki default. Mari kita periksa kontrolnya
yang seharusnya memiliki default tetapi seringkali tidak.

Bidang teks dan angka tanpa default

Mengisi bidang teks atau angka biasanya membutuhkan beberapa klik dan tombol-
stroke: satu untuk meletakkan fokus penyisipan ke dalam bidang dan lainnya untuk memasukkan
data. Terkadang Anda dapat menyimpan ketukan pengguna dengan memberikan default: kemungkinan atau
nilai yang baru saja dimasukkan.
Lipat gandakan beberapa ketikan yang disimpan dengan beberapa ribu — atau jutaan — pengguna
dan itu menghemat banyak penekanan tombol dan waktu. Dalam formulir yang berisi banyak bidang,

[Link] 80/315
26/2/2021 Tanpa judul
upaya yang disimpan bahkan bisa menjadi signifikan untuk satu pengguna. Untuk memesan barang dari a
katalog, seseorang tidak harus mengisi jumlah nol (0) untuk semua item
seseorang tidak mau. Sebaliknya, kuantitas untuk semua item harus diinisialisasi
nol — atau setidaknya respons kosong harus dianggap nol.
Survei pelanggan Northwest Airlines baru-baru ini menanyakan berapa banyak perjalanan
telah dibawa ke berbagai belahan dunia tetapi mengharuskan pelanggan untuk memasukkan nol
semua tempat yang belum pernah mereka kunjungi (Gambar 2.60). Ini tidak diragukan lagi mengurangi
jumlah survei diselesaikan.

Halaman 112

98 Bab 2 GUI Control Bloopers

Gambar 2.60

[Link]: survei mengharuskan pengguna memasukkan nol secara manual untuk semua tempat yang belum pernah mereka kunjungi.

Tombol radio tanpa nilai awal

Terkadang pilihan tombol radio dimulai dengan tidak ada tombol yang dipilih.
Pemrogram sengaja merancang tombol radio dengan cara ini, untuk:

■
menghindari praduga apa pun tentang apa yang akan dipilih pengguna,
■ memaksa pengguna untuk memilih secara eksplisit, atau
■
izinkan pengguna untuk tidak memilih (alasan ini jauh lebih jarang daripada dua yang pertama).

Tombol radio tanpa default terkadang dapat dibenarkan, tetapi memang ada
biaya kegunaan, yang setidaknya harus Anda ketahui:

1. Mereka melanggar ekspektasi pengguna tentang cara kerja tombol radio.

2. Mereka tidak dapat dikembalikan ke keadaan awal yang tidak disetel setelah pilihan telah dibuat.
3. Mereka melanggar pedoman desain UI itu, dalam kasus di mana tidak ada default yang dibuat
rasa, menu lebih disukai daripada tombol radio (lihat di bawah).
4. Mereka melanggar prinsip desain UI yang membiarkan pengguna melakukan sesedikit mungkin
untuk mendapatkan apa yang mereka inginkan.

Oleh karena itu, desainer harus memiliki alasan kuat untuk menghadirkan radio tetapi-
ton tanpa nilai default.
[Link] memiliki formulir bagi pengunjung untuk mengirimkan komentar tentang situs Web
(Gambar 2.61A). Dalam kebanyakan kasus, tidak ada tanggapan yang diperlukan atau diharapkan. Meskipun demikian, file
formulir tidak hanya tidak menyediakan default untuk pilihan ini, tetapi juga membutuhkan pilihan. Pengguna tidak bisa
kirimkan komentar tanpa menentukan apakah mereka menginginkan tanggapan. Demikian pula dengan

Halaman 113

Menggunakan kontrol secara salah 99

[Link] 81/315
26/2/2021 Tanpa judul

Gambar 2.61

Tombol radio tanpa default, meskipun satu opsi lebih mungkin. (A) Agilent.
com. (B) Penginstal Windows Medial Player.

Installer Wizard untuk Windows Media Player menampilkan tombol radio untuk memilih file
Penginstalan "Express" atau penginstalan "Kustom", tetapi pilihannya tidak default
“Ekspres,” yang merupakan pilihan yang jauh lebih umum (Gambar 2.61B).

Menu tarik-turun tanpa default

Menu tarik-turun tanpa default lebih umum daripada tombol radio dengan
tidak ada default. Ini biasanya tidak masalah, karena dua alasan:

Halaman 114

100 Bab 2 GUI Control Bloopers

Gambar 2.62

Tolong pilih...
Iya
Tidak
B

[Link]: menu tarik-turun tanpa nilai default dan pelabelan yang buruk.

1. Menu tanpa nilai lebih alami daripada pilihan tombol radio tanpa nilai.
“Tidak ada nilai” pada tombol radio berarti ini disetel ke tidak ada nilai yang memungkinkan. Di
Sebaliknya, "tidak ada nilai" pada menu adalah item pada menu: baik bersifat sementara
prompt kepada pengguna (misalnya, "Pilih topping") atau opsi "tidak ada" eksplisit.

[Link] 82/315
26/2/2021 Tanpa judul
2. Menu dapat menampilkan lebih banyak opsi daripada tombol radio. Tombol radio adalah
terbaik untuk dua hingga delapan opsi. Menu dapat menyajikan lusinan pilihan, membuat
kecil kemungkinan salah satunya adalah default yang sesuai.

Meskipun demikian, menu dropdown harus memiliki default yang berguna jika memungkinkan. Jika
tidak mungkin, label dan prompt harus menjelaskan pilihannya. Jika tidak,
pengguna harus membuka menu hanya untuk melihat apa pilihannya.
Hingga saat ini, pelanggan di situs Web Toko Buku Universitas Stanford,
setelah mengklik link untuk pergi ke halaman checkout, dihadapkan pada menu
dengan label sepanjang paragraf yang diinisialisasi menjadi "Silakan pilih" (Gambar 2.62). Itu
menu hanya memiliki dua kemungkinan nilai— “Ya” dan “Tidak” —tetapi untuk mengetahui bahwa Anda
harus membukanya. Selain itu, bahkan mengetahui opsi menu tidak memperjelas
pilihan; Anda harus membaca label sepanjang paragraf untuk mencari tahu apa "Ya" dan
“Tidak” artinya. Tentu saja hanya sedikit orang yang membaca label panjang pada awalnya. Lebih buruk lagi, membuat
sebuah pilihan diperlukan: Anda tidak dapat memeriksa sampai Anda menjawabnya. Itu
Stanford Bookstore baru-baru ini memperbaiki kesalahan besar ini.

Menghindari Blooper 10

Tugas perancang UI adalah membuatnya semudah mungkin bagi pengguna untuk menyelesaikannya
tujuan. Salah satu cara untuk melakukannya adalah dengan menyediakan default untuk banyak bidang entri data dan
pilihan sebanyak mungkin, sehingga pengguna dapat fokus hanya pada hal-hal yang perlu mereka ubah.

Halaman 115

Menggunakan kontrol secara salah 101

Gambar 2.63

[Link]: Bidang masukan pencarian menyediakan menu entri terbaru yang cocok dengan jenis pengguna.

Bidang teks dan angka

Jika ada nilai yang mungkin untuk bidang teks atau angka, gunakanlah. Jika tidak, desain
bidang untuk mengingat apa yang telah diketik di dalamnya, sehingga dapat menggunakan karakter pertama
bertindak sebagai tipe pengguna untuk memunculkan menu yang cocok dengan entri terbaru, sebagai milik Google
kolom input pencarian tidak (Gambar 2.63).

Tombol radio

Tombol radio tanpa nilai awal harus dihindari. Gunakan hanya jika Anda punya
pembenaran yang kuat.
Satu set tombol radio yang terhubung, dari sudut pandang pengguna, adalah satu
pengaturan yang menyajikan pilihan satu-dari- N . Ini mewakili variabel diskrit dengan
N kemungkinan nilai. Tidak wajar jika tidak memiliki nilai. Karena itu, kebanyakan radio
tombol harus memiliki nilai default (Gambar 2.64).
Jika aplikasi harus mengizinkan pengguna untuk menunjukkan bahwa mereka tidak menginginkannya
keju di pizza mereka, maka set tombol radio harus menyertakan eksplisit
nilai: “Tidak Ada” (Gambar 2.65).

Gambar 2.64
Keju: Keju mozzarella MendongkrakSwiss

Tombol radio dengan nilai default.

Gambar 2.65
Keju: Keju mozzarella Mendongkrak
Swiss Tidak ada

Tombol radio dengan nilai “tidak ada” ekstra sebagai default.

[Link] 83/315
26/2/2021 Tanpa judul

Halaman 116

102 Bab 2 GUI Control Bloopers

Gambar 2.66
Keju: Keju mozzarella Mendongkrak
Swiss

Tombol radio dengan kotak centang ON / OFF terkait.

Gambar 2.67
Bagaimana buku ini? Belum ada opini
Bagus!
baik
Mengerikan!

Tombol radio dalam survei dengan nilai default yang tidak bias.

Atau, seluruh pengaturan dapat memiliki kotak centang yang mengaktifkan dan
menonaktifkan pilihan tombol radio (Gambar 2.66). Jika Anda melakukan ini, lakukan itu terdiri-
seluruh aplikasi Anda, sehingga pengguna akan mempelajari apa artinya.
Demikian pula, jika Anda merancang kuesioner online dan tidak mau
biaskan jawaban pengguna dengan memberikan default, tambahkan opsi "tidak ada pendapat" yang eksplisit
dan menjadikannya default (Gambar 2.67).

Menu tarik-turun

Menu, seperti tombol radio, harus memiliki default jika memungkinkan. Jika salah satu pilihan
jauh lebih mungkin daripada yang lain, menginisialisasi menu ke opsi itu (Gambar
2.68). Jika sebuah menu dapat mengingat pilihan terakhir pengguna, jadikan itu sebagai default.

Jika tidak ada default yang dapat diasumsikan, menu lebih baik
daripada tombol radio

Terkadang Anda tidak dapat memberikan nilai default untuk sebuah pilihan, seperti saat menanyakan
jenis kelamin pengguna. Dalam kasus seperti itu, gunakan menu daripada tombol radio, karena
menu tanpa default lebih alami daripada tombol radio tanpa default,
bahkan ketika pilihan hanya memiliki dua pilihan.

Gambar 2.68

Microsoft Office: Kotak dialog cetak memiliki tombol radio dan pilihan menu, keduanya dengan default.

Halaman 117

Menggunakan kontrol secara salah 103

Blooper 11: Default yang buruk

Nilai default yang sepertinya tidak diinginkan pengguna lebih berbahaya daripada tidak sama sekali
default. Pengguna yang mengabaikan kontrol yang tidak memiliki default sering kali mendapatkan error
pesan, tetapi mengabaikan default yang buruk dapat menghasilkan hasil yang tidak diinginkan.
Satu "alasan" untuk default yang buruk adalah bahwa kontrol pilihan terkadang default

[Link] 84/315
26/2/2021 Tanpa judul
nilai pertama yang mungkin jika pengembang tidak menginisialisasi mereka. Sebuah ujian-
ple berasal dari situs Web Toko Buku Universitas Stanford. Memesan buku
membutuhkan menunjukkan negara asal Anda. Menu Negara secara default adalah Alabama
(Gambar 2.69) —secara alfabet pertama — meskipun sebagian besar pelanggan situs ini
berada di California. Oleh karena itu, sebagian besar pelanggan harus mengubah pengaturan Status.
Default buruk serupa terjadi di [Link], situs Web untuk menemukan
hotel di Seattle. Pengguna menentukan tanggal untuk hotel yang mereka butuhkan, tetapi menunya
untuk menentukan default tahun ke 2004, bahkan pada akhir 2006 (Gambar 2.70). Alasannya"
adalah bahwa halaman tersebut dibuat pada tahun 2004, sehingga daftar menu tahun mulai dan default

Gambar 2.69

[Link]: Menu negara bagian secara default ke Alabama, untuk pelanggan Stanford
Toko Buku Universitas, yang ada di California.

Gambar 2.70

[Link]: Tahun menu default ke 2004, bahkan di akhir 2006.

Halaman 118

104 Bab 2 GUI Control Bloopers

Gambar 2.71

SEBUAH

Microsoft Office: mencetak ke file PDF tidak memiliki ekstensi file keluaran default ke .pdf yang diperlukan.

ke tahun pertama dalam daftar. Pengguna sekarang harus mengubah tahun — dengan asumsi mereka menyadarinya
salah. Mencari pemesanan hotel di masa lalu menghasilkan pesan kesalahan.
Default yang buruk juga terjadi pada perangkat lunak desktop. Contoh datang dari
Microsoft Office (untuk Macintosh OS X). “Mencetak” dokumen ke file PDF
meminta pengguna untuk memberi nama file PDF, yang ekstensinya harus .pdf.
Sayangnya, Office tidak secara otomatis mengatur ekstensi file PDF menjadi .pdf;

[Link] 85/315
26/2/2021 Tanpa judul
itu menggunakan ekstensi asli dokumen. Jika pengguna tidak mengubah ekstensi-
sion ke .pdf, hasil pesan error (Gambar 2.71).

Menghindari Blooper 11

Pilih nilai default dengan menggambar pada sumber informasi ini:

■
Akal sehat: Seringkali, akal sehat sederhana berhasil. Di formulir untuk menulis
seorang senator California, kemungkinan besar pengirimnya dari California, jadi
itu adalah default yang masuk akal untuk pengaturan State (Gambar 2.72).
■
Logika bisnis: Jika default pabrik tidak sesuai dengan yang biasanya dibutuhkan pengguna Anda,
mengubahnya untuk menghemat pekerjaan bagi pengguna.
■
Pengalaman dan data situs: Jika akal sehat tidak menyarankan default,
pengamatan pelanggan atau log Web akan menunjukkan opsi yang umum dipilih.
■
Data pengguna individu: Jika tidak ada satu pun default yang cocok untuk semua pengguna, gunakan
default yang berbeda berdasarkan apa pun yang Anda ketahui tentang pengguna tertentu.

Halaman 119

Menggunakan kontrol secara salah 105

Gambar 2.72

[Link]: dalam bentuk untuk menghubungi Senator Boxer, Negara bagian default ke California, negara bagian
Boxer mewakili.

■
Pilihan sewenang-wenang: Akhirnya, jika tidak ada pilihan tertentu tampaknya lebih mungkin daripada
selain itu, terkadang tidak ada salahnya menyatakan salah satunya sebagai
default.

Blooper 12: Kotak centang negatif

Kotak centang negatif adalah kotak yang menonaktifkan fitur atau atribut
dicentang dan nyalakan saat tidak dicentang. Mereka “terbelakang” dari apa
yang diharapkan pengguna. Jika pengguna tidak membaca label dengan cermat, mereka dapat menyetel kotak centang
berlawanan dengan apa yang mereka inginkan. Setidaknya, centang kotak "berfungsi kembali-
ward ”membuat pengguna berhenti dan berpikir tentang cara mengaturnya, melanggar desain
prinsip “jangan mengalihkan pengguna dari tujuan mereka” (Prinsip Dasar 5, halaman 35).
SmartDraw, program menggambar, menyertakan kotak centang "negatif" dalam Bentuknya
Kotak dialog properti (Gambar 2.73).
[Link], layanan email opt-in, mengizinkan administrator email untuk
mengatur izin akses pengguna administratif baru, tetapi menggunakan tanda centang "negatif "-
kotak serta yang positif (Gambar 2.74).

Gambar 2.73

SmartDraw: kotak centang negatif — mencentangnya akan MENONAKTIFKAN pemeriksaan ejaan.

Gambar 2.74

[Link]: setelan izin pengguna menyertakan kotak centang yang "menghapus" izin.

[Link] 86/315
26/2/2021 Tanpa judul

Halaman 120

106 Bab 2 GUI Control Bloopers

Menghindari Blooper 12

Kotak centang harus berfungsi dengan cara yang positif: kotak centang harus membalikkan keadaan
AKTIF saat dicentang dan MATIKAN jika tidak dicentang. Itulah pengguna
mengharapkan.
Contoh kotak centang positif disediakan oleh Apple's Preview Print
kotak dialog dan kotak dialog Preferensi MacOS X (Gambar 2.75).

Gambar 2.75

Kotak centang positif. (A) Dialog Apple Preview Print. (B) Preferensi MacOS X.

Halaman 121

Navigasi
[Link] 87/315
26/2/2021 Tanpa judul

Bloopers
pengantar

Tidak menunjukkan lokasi mereka kepada pengguna

Menyesatkan pengguna dan tidak menunjukkan jalan

Navigasi pencarian yang buruk

107

Halaman 122

108 Bab 3 Kesalahan Navigasi

pengantar

Masalah yang paling sering dihadapi pengguna perangkat lunak adalah navigasi: pencarian
jalan mereka menuju apa yang mereka cari. Ini terutama karena navigasi yang tidak memadai
isyarat — setara dengan tanda yang buruk di jalur pendakian, jalan kota, atau gedung
lorong.
Menurut analis kegunaan Jakob Nielsen [1999d], navigasi berhasil
isyarat agar orang tahu:

■ di mana mereka,
■
kemana saja mereka,
■ kemana mereka bisa pergi.

Kepada mereka, saya akan menambahkan:

■ apakah tujuannya dekat atau jauh.

Sayangnya, banyak produk perangkat lunak dan situs Web melakukan pekerjaan yang buruk dalam menyediakan
mencari petunjuk ini, sehingga orang sering tidak menemukan apa yang mereka cari. Terkadang mereka bahkan
Enyah.
Bab ini menjelaskan kelemahan paling umum yang menghalangi, mengalihkan, dan
memblokir pengguna perangkat lunak untuk menemukan konten yang mereka cari dan menjelaskan caranya
hindari kekurangan itu.

Tidak menunjukkan lokasi mereka kepada pengguna

Orang-orang menggunakan petunjuk lingkungan untuk melihat di mana mereka berada. Jika Anda melihat kompor, pemanggang roti,
panci, dan wajan, Anda tahu Anda berada di dapur, sementara sofa, meja kopi, dan
stereo menunjukkan bahwa Anda berada di ruang tamu.
Pernahkah Anda mencoba berkeliling di kota atau bangunan yang tidak dikenal, tetapi
menemukan diri Anda terhalang oleh kurangnya tanda atau tanda yang sulit dibaca? Kapan
sulit untuk melihat di mana Anda berada, mudah tersesat. Bahkan jika Anda tidak bertindak-
sekutu tersesat, Anda mungkin merasa tersesat, menurunkan kepercayaan diri Anda bahwa Anda sedang maju
menuju tujuan Anda.

[Link] 88/315
26/2/2021 Tanpa judul
Tiga kesalahan besar navigasi pertama adalah kasus tidak adanya isyarat yang akurat,
menghalangi kemampuan pengguna untuk melihat di mana mereka berada dan apakah mereka berada di jalur yang benar
tujuan mereka.

Blooper 13: Jendela atau halaman tidak teridentifikasi

Beberapa aplikasi atau situs Web gagal memberikan tanda di mana pun pengguna berada.

Halaman 123

Tidak menunjukkan lokasi mereka kepada pengguna

109

Aplikasi desktop: Tanpa judul jendela

Jendela aplikasi mengidentifikasi dirinya dengan judul di batang judulnya. Jendela

tubuh juga dapat mengidentifikasi aplikasi tersebut. Beberapa aplikasi tidak memberi judul pada jendelanya.
Aplikasi transfer file Fetch tidak menampilkan judul pada beberapa kotak dialog,
misalnya, Hapus File (Gambar 3.1). Ini mengharuskan pengguna Fetch untuk mengingat
fungsi apa yang mereka panggil, dibantu sedikit oleh prompt di badan jendela.
Contoh yang lebih halus dari blooper terjadi di Mozilla Firefox. Preferensi
jendela memiliki judul, tetapi judul tidak memberi nama jendela. Sebaliknya, itu terlihat
kategori preferensi mana yang sedang ditampilkan (Gambar 3.2). Itu bukan jendela yang mana
titlebars untuk.

Gambar 3.1

Ambil: Kotak dialog Hapus File tidak memiliki judul jendela di bilah judul.

Gambar 3.2

Firefox: Judul jendela preferensi menunjukkan kategori preferensi saat ini, bukan jendela.

Halaman 124

Bab 3 Kesalahan Navigasi

[Link] 89/315
26/2/2021 Tanpa judul
110

Gambar 3.3

[Link]: halaman saat ini tidak ditunjukkan. Ini adalah halaman "Tentang KBS".

Di Web: Halaman tidak teridentifikasi

Perangkat lunak web dapat mengidentifikasi halaman saat ini dengan menandai item saat ini
di bilah navigasi atau menampilkan judul halaman secara mencolok pada halaman. Banyak
jangan lakukan keduanya, memaksa pengunjung untuk menebak halaman mereka.
Salah satu contohnya adalah [Link], situs web Koehler-BrightStar (Gambar 3.3).
Bilah navigasi di bagian atas setiap halaman tidak menyorot halaman saat ini dan
halaman tidak menyertakan judul.
Beberapa situs Web mencoba menunjukkan halaman saat ini dengan menggunakan HTML <TITLE>
tag untuk menampilkan judul halaman di bilah judul browser . Ini tidak berhasil: orang
jarang memperhatikan apa yang ada di bilah judul browser, terutama setelah mereka sudah melakukannya
di situs Web. Situs harus menetapkan judul untuk browser, tetapi yang paling utama adalah
jendela mengidentifikasi dirinya sendiri saat diminimalkan ke bilah tugas di bagian bawah
layar.

Menghindari Blooper 13

Aplikasi desktop harus memberi judul pada semua jendela, termasuk kotak dialog. Gunakan ini
format:

<Application name>: <window title> (misalnya, PageDesigner: Import Image)

Pratinjau Apple mengidentifikasi jendela Preferensi dengan baik, meskipun itu

tidak mengikuti format yang direkomendasikan dengan tepat (Gambar 3.4).
Perangkat lunak web dapat menunjukkan halaman saat ini dengan dua cara. Situs yang dirancang dengan baik
gunakan salah satu atau keduanya di setiap halaman.

Halaman 125

Tidak menunjukkan lokasi mereka kepada pengguna

111

Gambar 3.4

Pratinjau Apple: jendela aplikasi teridentifikasi dengan baik.

■
Bilah navigasi: menandai item halaman saat ini di bilah navigasi situs
■
Judul halaman: menempatkan judul halaman secara mencolok, di dekat bagian atas konten halaman

[Link] 90/315
26/2/2021 Tanpa judul

Situs Web IBM menampilkan dua judul halaman pada setiap halaman (Gambar 3.5). Situs ini melakukannya
tidak menandai halaman saat ini di bilah navigasi, tapi tidak apa-apa karena
judul halaman ditampilkan dengan jelas.
[Link] menyoroti halaman saat ini di bilah navigasinya tetapi tidak
tidak menampilkan judul halaman terpisah (Gambar 3.6). Ini juga berhasil.
Jika menandai bilah navigasi membantu dan menunjukkan judul halaman membantu, lakukan
keduanya sekaligus harus benar-benar jelas. [Link] (Gambar 3.7) melakukan ini.

Gambar 3.5

[Link]: halaman saat ini yang ditunjukkan dengan judul halaman yang terpisah dari bilah navigasi.

Halaman 126

112 Bab 3 Kesalahan Navigasi

Gambar 3.6

[Link]: halaman saat ini disorot di kolom navigasi; tidak ada halaman terpisah
judul.

Gambar 3.7

[Link]: halaman saat ini yang ditunjukkan pada bilah navigasi dan dengan judul.

Blooper 14: Judul yang sama di jendela berbeda

Terkadang jendela atau halaman web yang berbeda memiliki judul yang sama persis. Ini bisa
menyesatkan pengguna tentang di mana mereka berada. Kesalahan semacam itu memiliki empat penyebab umum.

Variasi A: Aplikasi nama judul jendela saja

Pada variasi pertama, semua jendela aplikasi memiliki nama yang sama: yaitu
aplikasi (Gambar 3.8). Ini bisa terjadi jika programmer mengasumsikan pengguna
secara otomatis akan mengenali fungsi dari setiap jendela atau mengingat yang mana
fungsi menampilkannya. Sayangnya, mereka tidak mau.
Aplikasi Windows XP Paint mengalami masalah ini: jendela Bantuannya adalah

[Link] 91/315
26/2/2021 Tanpa judul
berlabel "Paint" (Gambar 3.9).

Halaman 127

Tidak menunjukkan lokasi mereka kepada pengguna

113

Gambar 3.8
Desainer Pizza Desainer Pizza

Topping: Kerak:

Keju: Keju mozzarella Ukuran: Sml Med Lrg

Adonan: Reg Asam WW

Daging: Ssg daging Ikan teri

Sayuran: Bawang Pepr Tom Ketebalan: Tipis Med Tebal

Mshrm Bawang putihSeni

baik Membatalkan Tolong
baik Membatalkan Tolong

Judul jendela hanya mengidentifikasi aplikasi, bukan jendela tertentu.

Gambar 3.9

Microsoft Windows XP Paint: Hanya aplikasi nama judul jendela bantuan.

Variasi B: Programmer menyalin kode tetapi lupa

untuk mengedit judul

Pemrogram sering menambahkan jendela baru ke aplikasi dengan menyalin kode

dari jendela serupa yang ada dan mengeditnya dengan benar. Halaman web baru
sering dikloning dari yang lama. Mudah untuk lupa mengubah detail di
menyalin, sehingga perangkat lunak berakhir dengan beberapa halaman atau jendela dengan yang sama
nama. Ini benar-benar bug, bukan cacat desain, tapi tetap saja buruk.
Ini mungkin penyebab judul halaman duplikat di [Link]: the
Halaman "Search" diberi label sebagai halaman "Help and Accessibility" (Gambar 3.10).

Halaman 128

114 Bab 3 Kesalahan Navigasi

Gambar 3.10

[Link] 92/315
26/2/2021 Tanpa judul

[Link]: Judul halaman “Help and Accessibility” juga muncul di halaman “Search”.

Variasi C: Programmer tidak tahu judulnya

sedang digunakan di tempat lain

Tim pengembang sering kali menetapkan bagian yang berbeda dari aplikasi atau situs Web
programmer yang berbeda. Ketika programmer tidak berkomunikasi, duplikat
judul jendela dapat terjadi.

Halaman 129

Tidak menunjukkan lokasi mereka kepada pengguna

115

Bahkan seorang programmer yang bekerja sendiri dapat melupakan bahwa judul tertentu adalah
sudah digunakan. Judul jendela, tidak seperti variabel program atau nama prosedur, adalah
tidak diperiksa oleh kompiler untuk keunikan, jadi memastikan keunikan adalah kom-
sepenuhnya terserah pengembang.

Variasi D: Programmer menganggap judul cocok untuk keduanya

Pemrogram dapat menetapkan dua jendela judul yang sama karena mereka menganggap file
name cocok untuk kedua fungsi jendela dan tidak dapat memikirkan judul yang lebih baik untuk keduanya
jendela. Dalam kebanyakan kasus, satu atau kedua judul tidak cukup tepat. Untuk
Misalnya, berikut adalah kutipan dari review aplikasi untuk dua klien
perusahaan:

Perusahaan 1: Tombol “Jaringan…” di jendela Utama menampilkan kotak dialog

bernama Control Network, dan tombol “Select…” menampilkan dialog yang berbeda
kotak juga bernama Control Network. Rekomendasi: Seharusnya tidak ada dua perbedaan
jendela ferent dengan nama yang sama. Ganti nama satu.

Perusahaan 2: Jendela Execution Monitor yang dapat ditampilkan dari

Jendela Investasi Saya adalah jendela Monitor Eksekusi yang berbeda dari yang satu
tersedia dari jendela Utama. Rekomendasi: Kedua jendela ini seharusnya
digabungkan. Jika tidak memungkinkan, mereka harus memiliki nama yang berbeda.

Gambar 3.11 menunjukkan dua jendela dengan judul identik dari sebuah gen hipotetis-
aplikasi alogy. Sedangkan judul “Show Family” adalah wajar untuk masing-masingnya
windows, dua jendela berbeda dengan judul yang sama akan membingungkan pengguna.
Ketika judul jendela duplikat diperhatikan, mereka sering dianggap sebagai file
masalah dengan prioritas rendah yang membosankan untuk diperbaiki. Oleh karena itu, duplikat jendela
judul dalam produk perangkat lunak terkadang bertahan sampai ke pasar.

[Link] 93/315
26/2/2021 Tanpa judul

Gambar 3.11
Silsilah Pro: Tampilkan Keluarga Silsilah Pro: Tampilkan Keluarga

Keluarga: Johnson Keluarga: Johnson

foto
foto

foto foto

baik Membatalkan Tolong baik Membatalkan Tolong

Blooper: jendela berbeda dengan judul fungsional yang sama.

Halaman 130

116 Bab 3 Kesalahan Navigasi

Menghindari Blooper 14

Dengan mengikuti aturan ini, pengembang perangkat lunak dapat menghindari jendela duplikat atau
judul halaman.

Setiap jendela atau halaman Web harus memiliki judul yang unik

Setiap jendela atau halaman Web terkait dengan fungsi berbeda dari suatu aplikasi
tion harus memiliki judul yang unik. Judul dari dua dialog hipotetis
kotak pada Gambar 3.12 dengan jelas membedakan kedua jendela.

File pesan dapat membantu

Tempatkan semua teks yang ditampilkan oleh perangkat lunak, termasuk judul jendela, ke dalam pesan
file, daripada menyebarkannya melalui kode program (Blooper 22, halaman
153). Ini mengurangi kemungkinan nama jendela duplikat.
Namun, jika judul dari dua jendela berbeda mengarah ke teks yang sama di file
file pesan, duplikasi tidak akan terlihat. Jenis duplikasi seperti itu akan
harus dilihat oleh pemrogram dalam kode atau tinjauan UI.

Kasus khusus

Dua kasus khusus dari judul jendela duplikat perlu disebutkan:

■
Beberapa jendela mewakili fungsi yang sama yang diterapkan pada data yang berbeda . Ini
dapat terjadi di jendela editor teks yang melihat file atau pasar saham yang berbeda
monitor menunjukkan aktivitas untuk berbagai saham. Duplikasi ini bisa jadi
dicegah dengan memasukkan nama data di batang judul, misalnya, “StockWatcher:
Tampilkan Aktivitas — Google (GOOG). ”
■ Beberapa jendela mewakili fungsi atau data yang sama dengan opsi pengguna yang berbeda.
Beberapa program aplikasi memungkinkan pengguna untuk memunculkan beberapa contoh file

Gambar 3.12
Desainer Pizza: Pilih Topping Desainer Pizza: Pilih Crust

Topping: Kerak:

Keju: Keju mozzarella Ukuran: Sml Med Lrg

Adonan: Reg Asam WW

Daging: Ssg daging Ikan teri

Sayuran: Bawang Pepr Tom Ketebalan: Tipis Med Tebal

Mshrm Bawang putihSeni

baik Membatalkan Tolong
baik Membatalkan Tolong

Menghindari blooper: jendela berbeda dengan judul berbeda.

[Link] 94/315
26/2/2021 Tanpa judul

Halaman 131

Tidak menunjukkan lokasi mereka kepada pengguna

117

Jendela "sama" untuk memungkinkan pengguna menyetel opsi berbeda di setiap jendela. Sebuah pabrik
alat monitor memungkinkan pengguna menampilkan beberapa jendela memantau pabrik
output, setiap polling instrumen telemetri pabrik pada kecepatan yang berbeda. Sedemikian
kasus, konvensi untuk judul jendela diakhiri dengan integer (dipisahkan dari
judul dengan titik dua) menunjukkan kemunculan jendela mana masing-masing. Untuk
contoh: "Monitor Pabrik", "Monitor Pabrik: 2", "Monitor Pabrik: 3."

Blooper 15: Judul jendela tidak cocok dengan perintah atau tautan

Saat orang-orang berpindah-pindah dalam aplikasi atau situs Web, mereka membutuhkan kepastian
bahwa mereka mendapatkan apa — atau di mana — yang mereka coba dapatkan. Blooper yang sangat umum
di desktop dan perangkat lunak Web adalah pemetaan sembarangan antar perintah
atau tautan dan jendela atau halaman yang ditampilkannya.

Kesalahan dalam perangkat lunak desktop

Microsoft Windows XP mengalami masalah ini (Gambar 3.13). Mengklik "Ubah ..."
tombol di Hubungan yang Tepat Sistem Control Panel menampilkan kotak dialog berjudul
Perubahan Nama Komputer, yang tidak hanya tidak cocok dengan perintah pemanggilan
mand sangat baik, itu juga ambigu secara tata bahasa.
Ketidakcocokan ini tidak kecil atau sepele. Pengguna komputer sangat literal — sering kali
sangat mencengangkan — dalam interpretasi mereka terhadap label dan alat bantu navigasi lainnya
layar. Jika dua frasa berbeda, meskipun hanya sedikit, pengguna biasanya berasumsi
mereka memiliki arti yang berbeda. Ketika seseorang memilih perintah Ubah…

Gambar 3.13

Windows XP: Tombol "Ubah ..." menampilkan kotak dialog Ubah Nama Komputer.

Halaman 132

118 Bab 3 Kesalahan Navigasi

Gambar 3.14

[Link] 95/315
26/2/2021 Tanpa judul

SEBUAH B

Microsoft Excel: Perintah Insert => Function… menampilkan kotak dialog Paste Function.

dan jendela yang muncul diberi label "Computer Name Changes," yang pertama
kesan bahwa mereka tidak mendapatkan apa yang mereka inginkan. Ini terutama benar
penutur asli bahasa yang ditampilkan oleh perangkat lunak.
Contoh yang lebih serius datang dari Excel. Di menu Sisipkan,
perintah (Sisipkan) Fungsi ... menampilkan jendela bernama "Fungsi Tempel"
(Gambar 3.14). "Tempel" menyiratkan "Potong" sebelumnya, sedangkan "Sisipkan" tidak, jadi begini
ketidakcocokan akan menyebabkan kesalahpahaman.

Penyebab umum blooper

Blooper ini terjadi ketika New <object>… atau Create <object>… com-
Perintah menampilkan kotak dialog berjudul Edit <object> atau <object> Properties.
Atribut yang ditentukan pengguna untuk membuat objek baru biasanya sama dengan
yang diedit di objek yang ada, sehingga pemrogram GUI sering menggunakan satu kotak dialog
untuk kedua fungsi tersebut. Itu masuk akal bagi pengembang, tetapi tidak bagi pengguna. Jika
kotak dialog memiliki judul statis, judul tidak akan cocok dengan salah satu dari dua perintah itu
menampilkan kotak dialog. Misalnya, tombol "Grup Baru ..." Adobe Reader's
menampilkan kotak dialog Edit Grup (Gambar 3.15).

Blooper di Web

Ketidakcocokan pelabelan serupa terjadi di Web. Aplikasi WebMail di

Layanan ".mac" Apple memiliki tautan untuk menambahkan folder email, tetapi ini menampilkan Kelola
Jendela folder (Gambar 3.16).
Ketidakcocokan yang lebih serius terjadi di Portal Dr. Dobb, [Link]. Angkatan laut
Link "Subscribe" dari gation bar menampilkan halaman berjudul "Dr. Cetak Jurnal Dobb
Layanan Langganan ”(Gambar 3.17A). Tidak bagus, tapi tidak buruk. Namun,
link yang berbeda pada bilah navigasi— “Newsletters” —menampilkan halaman berjudul
"Berlangganan" (Gambar 3.17B). Itu akan membingungkan orang.

Halaman 133

Gambar 3.15

SEBUAH B
Adobe Reader: Tombol “Grup Baru…” menampilkan kotak dialog Edit Grup.

Gambar 3.16

SEBUAH

[Link] 96/315
26/2/2021 Tanpa judul

B
[Link] WebMail: mengklik "Tambahkan folder" akan menampilkan jendela berjudul "Kelola Folder."

Halaman 134

120 Bab 3 Kesalahan Navigasi

Gambar 3.17

SEBUAH

[Link]: Tautan bilah navigasi tidak cocok dengan judul halamannya. (A) "Berlangganan".
(B) Tautan "Buletin".

Menghindari Blooper 15

Judul jendela atau halaman Web harus mencerminkan perintah yang ditampilkan
saya t. Ini menunjukkan kepada pengguna bahwa mereka menekan tombol atau item menu yang ingin mereka tekan.
Anda dapat melakukan ini dengan membuat judul jendela atau halaman identik dengan nama
perintah yang memanggil mereka. Karena label perintah harus berupa frasa kata kerja,
judul-judul jendela akan, sebagian besar, juga berupa frase kata kerja.
Meskipun menu "Sisipkan" Microsoft Excel memberikan contoh kesalahan besar,
ini juga memberikan contoh pencocokan tepat. Perintah (Sisipkan) Hyperlink
menampilkan kotak dialog dengan kata-kata yang sama persis dengan judulnya (Gambar 3.18).

Pencocokan tidak tepat tidak masalah jika bekerja untuk pengguna

Selama pengguna melihat koneksi, perintah dan judul tidak perlu diidentifikasi.
kal. Perbedaan antara "Show Order Status" dan "Status of Order 6823"

Halaman 135

[Link] 97/315
26/2/2021 Tanpa judul
Tidak menunjukkan lokasi mereka kepada pengguna
121

Gambar 3.18

SEBUAH B

Microsoft Excel: Perintah Insert => Hyperlink… menampilkan kotak dialog Insert Hyperlink.

mungkin cukup kecil sehingga tidak akan membingungkan siapa pun. Namun, para penggunanya
adalah penilai apakah perintah dan judul jendela yang dihasilkan serupa
cukup, bukan pengembangnya. Setiap perintah dan jendela hasil yang diberi nama
berbeda adalah masalah kegunaan potensial dan harus dihindari jika memungkinkan dan
diuji pada pengguna jika tidak dapat dihindari. Sebagian besar perbedaan — bahkan yang kecil sekalipun — akan menyebabkan
pengguna untuk bertanya-tanya setidaknya secara singkat tentang apakah mereka menekan tombol atau tautan kanan.

Solusi yang berguna: Izinkan perintah untuk mengatur judul jendela

Alasan umum untuk perbedaan antara nama perintah dan judul

dari jendela yang dihasilkan adalah bahwa perintah yang berbeda menampilkan jendela yang sama.
Tiga kasus tipikal:

1. Buka…, Simpan Sebagai…, Impor…, dan Ekspor… perintah semua memunculkan dialog
kotak berjudul File Chooser.
2. Buat Akun dan Edit Akun perintah keduanya memunculkan jendela berjudul
Mengedit akun.
3. Perintah View Graph dan Edit Graph akan menampilkan jendela berjudul Graph.

Dalam ketiga kasus tersebut, ketidaksesuaian label perintah dapat dihilangkan dengan mengizinkan
perintah dan tautan untuk mengatur judul jendela atau halaman yang ditampilkan. Dalam hal
1, yang biasanya dilakukan: komponen pemilih file memungkinkan kode panggilan untuk menyetel
judul kotak dialog, jadi pemrogram biasanya memberikan perintah khusus pemilih file
nama seperti "Simpan Sebagai". Oleh karena itu, kasus 1 dari blooper cukup jarang terjadi. Kasus 2
dan 3 tidak jarang, meskipun solusi yang sama akan berhasil untuk mereka.

Halaman 136

122 Bab 3 Kesalahan Navigasi

Menyesatkan pengguna dan tidak

menunjukkan jalan

Pirolli dan Card [1999] menunjukkan bahwa orang

ikuti informasi "aroma" untuk tujuan mereka.
Aroma ini berasal dari isyarat di antarmuka pengguna.
wajah yang menyarankan tindakan apa yang dilakukan atau di mana
mereka pergi. Jika seseorang menggunakan pengeditan foto
perangkat lunak dan ingin mencerahkan foto yang gelap,
kata "meringankan" atau "kecerahan" di mana saja
perintah atau link "berbau" seperti pengguna
tujuan. Pengguna pergi ke arah yang memancarkan
aroma terkuat dari tujuan mereka.
Oleh karena itu, perangkat lunak seharusnya tidak hanya ditampilkan
pengguna di mana pun mereka berada, itu juga harus menyediakan
isyarat — aroma — yang memandu pengguna menuju mereka
tujuan. Paling tidak, isyarat tidak boleh mengalihkan
© 2007; Dicetak ulang atas izin Bunny Hoest dan Parade
Majalah. pengguna jauh dari tujuan mereka. Bagian ini
memeriksa blooper yang gagal mengarahkan pengguna
tujuan atau bahkan menuntun mereka menjauh darinya.

[Link] 98/315
26/2/2021 Tanpa judul

Blooper 16: Tombol dan tautan off-path yang mengganggu

Aplikasi perangkat lunak atau situs Web dirancang untuk mendukung tujuan pengguna tertentu. Itu
antarmuka pengguna perangkat lunak harus memandu pengguna menuju tujuan tersebut. Sayangnya,
banyak aplikasi dan situs Web memunculkan gangguan yang mengalihkan pengguna
mencapai tujuan mereka.
Situs web Institute of Electrical and Electronics Engineers (IEEE.
org) memiliki halaman "Perpanjang Keanggotaan". Di tengah atas halaman adalah sebuah link
“Mulai Pembaruan Keanggotaan” (Gambar 3.19). Anggota IEEE tiba di sini dengan
tujuan pembaruan, jadi tautan ini tampak jelas. Namun, di tempat lain di halaman ini
adalah tautan yang tampaknya dapat diterapkan juga. Jika pengguna membaca halaman dengan cermat, mereka
akan tahu bahwa mereka harus mengklik "Mulai Pembaruan Keanggotaan" untuk memperbarui, tetapi
beberapa pengguna akan membaca dengan seksama. Sebagian besar akan dengan cepat memindai halaman dan mengklik link apa pun
itu sepertinya relevan.
Pemindaian cepat menunjukkan bahwa siswa mungkin harus mengikuti pembaruan yang berbeda
instruksi. Hanya membaca dengan cermat menjelaskan bahwa siswa menggunakan hal yang sama
terhubung seperti orang lain. Tautan "Menggunakan koneksi aman" (tepat di bawah "Mulai
Pembaruan Keanggotaan ”) dapat disalahartikan sebagai titik awal alternatif
untuk memperbarui menggunakan koneksi aman , seolah-olah tautan pembaruan utama bukan
aman. Namun, tautan "koneksi aman" hanya melompati halaman ke
penjelasan tentang "aman vs. tidak aman". Singkatnya, halaman ini setidaknya akan menyebabkan banyak
pengguna merasa ragu, tidak yakin apa langkah pertama yang benar, dan mungkin memikat beberapa pengguna
melacak ketika mereka mengeklik tautan lain dan harus menemukan jalan kembali ke sini.

Halaman 137

Menyesatkan pengguna dan tidak menunjukkan jalan 123

Gambar 3.19

[Link]: Halaman "Perpanjang Keanggotaan" memiliki banyak tautan yang mengganggu.

Terpikat keluar jalur. Tidak bisa kembali. Ack!

Ketika seorang pelanggan mencari penerbangan di situs Web Southwest Airlines, itu mendaftar
penerbangan yang sesuai dengan kriteria pelanggan (Gambar 3.20). Daftar ini memiliki tautan untuk menjelaskan
negara dari berbagai kategori tarif Southwest. Dengan sendirinya, ini OK; kebanyakan pelanggan
Tomers akan memahami bahwa tautan ini hanyalah penjelasan, bukan di jalan
menuju pemesanan penerbangan.
Masalahnya adalah apa yang terjadi jika pelanggan mengikuti salah satu dari penjelasan ini
tautan. Daftar penerbangan menghilang dan diganti dengan halaman berjudul “Southwest
Airlines Fare Information, yang memberikan informasi tentang banyak hal,
termasuk kebijakan pengembalian dana Southwest. Bagaimana pelanggan kemudian kembali
daftar penerbangan? Tidak ada link kembali yang disediakan. Pelanggan harus mengklik "Kembali"
tombol untuk kembali ke daftar penerbangan. Beberapa pelanggan, melihat navigasi
bar di bagian atas halaman informasi tarif, akan mengklik link "Reservasi",
percaya bahwa itu akan membawa mereka kembali ke reservasi penerbangan mereka. Tapi dari
Tentu saja tautan itu tidak akan membawa mereka kembali ke daftar penerbangan. Ini menempatkan mereka kembali
awal dari proses reservasi. Potensi penjualan tertunda, bahkan mungkin kalah jika
pengguna cukup frustrasi.

Posisi promosi yang buruk memikat pelanggan keluar jalur

Pengguna komputer tidak membaca layar dengan cermat; mereka memindai dengan cepat mencari-
hal yang sesuai dengan tujuan mereka. Dalam masyarakat Barat, orang biasanya memindai dari atas

[Link] 99/315
26/2/2021 Tanpa judul
kiri ke kanan bawah. Setelah memasukkan data ke dalam formulir, pengguna dengan cepat memindai ke

Halaman 138

124 Bab 3 Kesalahan Navigasi

Gambar 3.20

SEBUAH

B
[Link]: halaman penjelasan tarif menggantikan halaman hasil penerbangan, tetapi tidak menyediakan rute kembali.

kanan bawah untuk tombol atau link untuk mengirimkan formulir. Di [Link], banyak pengguna
yang telah mengisi formulir pendaftaran pelanggan baru akan melakukan itu dan tempat
apa yang mereka cari: tautan berlabel "Lanjutkan" (Gambar 3.21). Mereka akan mengklik
itu dan menemukan diri mereka menatap pada bentuk yang tidak terkait — mungkin tidak diinginkan — dengan
berlangganan email promosi produk. Ups, tautan salah.
Lebih buruk lagi, ketika orang menyadari bahwa mereka berakhir di tempat yang salah,
mereka akan menekan KEMBALI, tetapi akan menemukan bahwa formulir pendaftaran sekarang kosong. Mereka
harus mendaftar lagi. Atau (grrrr) tidak.

Halaman 139

Menyesatkan pengguna dan tidak menunjukkan jalan 125

Gambar 3.21

[Link] 100/315
26/2/2021 Tanpa judul

SEBUAH

[Link]: formulir pendaftaran — pengguna tidak boleh melihat tombol "Kirim Informasi" dan mengklik
"Lanjutkan" untuk bentuk yang berbeda.

Menghindari Blooper 16

Jangan mengalihkan pelanggan dari tugas mereka. Bantu orang menyelesaikan tugas utama
aplikasi atau situs Web Anda dirancang untuk mendukung.
Setelah orang memulai jalur tugas, jangan alihkan perhatian mereka dari
menyelesaikannya. Buat "corong proses" yang memandu pengguna menuju tujuan mereka dan
menjaga mereka tetap di jalur untuk mencapainya [Van Duyne et al., 2002]. Menarik
tombol dan tautan yang keluar dari jalur mengurangi kemungkinan pengguna untuk menyelesaikannya
tugas, terutama jika sulit bagi pengguna untuk kembali ke jalur tugas.

Halaman 140

126 Bab 3 Kesalahan Navigasi

Gambar 3.22

[Link]: penjelasan tarif muncul di jendela terpisah untuk mempertahankan konteks tugas.

Pastikan tombol atau label tautan di luar jalur tidak menipu pengguna dengan berpikir mereka
berada di jalur tugas. Tautan yang menjelaskan detail, syarat, dan ketentuan harus
muncul di jendela terpisah sehingga tidak menyebabkan pengguna kehilangan tempat mereka
adalah. Misalnya, hasil pencarian penerbangan di [Link], seperti di [Link],
menyertakan tautan ke penjelasan kategori tarif United. Namun, di United,
penjelasannya muncul di jendela kecil yang terpisah, dengan tombol "Tutup" untuk
membantu pelanggan kembali memesan penerbangan mereka (Gambar 3.22).
Namun, bahkan tautan yang memunculkan penjelasan dapat memperlambat pengguna, mengganggu
mereka, dan buang waktu mereka, jadi Anda harus menggunakannya dengan hemat.

Blooper 17: Tautan mandiri

[Link] 101/315
26/2/2021 Tanpa judul
Kesalahan navigasi yang sangat umum adalah untuk halaman Web yang menyertakan file
tautan aktif ke dirinya sendiri. Mengklik tautan seperti itu hanya memuat ulang halaman. Ini bukan
hanya membuang-buang waktu orang saat halaman dimuat ulang, itu bisa membingungkan: pengguna mungkin
tidak mengenali halaman yang ditampilkan ulang seperti sebelumnya. Bagaimana? Seperti ini:

■
Pengguna mengklik tautan mandiri saat menggulir ke bawah halaman, tapi itu ditampilkan ulang
di atas. Pengguna mungkin belum pernah melihat bagian atas halaman karena
tiba dari tempat lain melalui tautan langsung ke titik jangkar di tengah jalan
halaman.
■ Halaman memiliki gambar yang berubah setiap kali ditampilkan.
■
Halaman tersebut berisi animasi, applet, atau konten dinamis lainnya yang dibutuhkan
waktu untuk memulai, sehingga pengguna tidak dapat langsung melihat halaman apa itu.

Tautan mandiri terselubung juga dapat menyebabkan pengguna kehilangan data yang mereka masukkan
formulir di halaman. Blooper ini memiliki beberapa variasi, tergantung di mana
self-link aktif diposisikan di halaman.

Halaman 141

Menyesatkan pengguna dan tidak menunjukkan jalan 127

Variasi A: Tautan mandiri di bilah navigasi

Variasi ini terjadi ketika semua tautan di bilah navigasi situs aktif di semua
halaman. [Link] memiliki kolom navigasi (di sebelah kiri) tempat link berada
aktif di halaman mereka sendiri (Gambar 3.23). Halaman yang ditampilkan adalah halaman beranda, di
di mana tautan "Beranda" di kolom navigasi aktif.
Variasi ini sangat umum karena kode HTML untuk navigasi
bilah sering disalin ke setiap halaman situs, jadi setiap tautan bilah navigasi adalah
aktif di setiap halaman. Butuh lebih banyak pekerjaan untuk mengubah kode untuk setiap halaman sehingga
item bilah navigasi halaman itu sendiri tidak aktif.
Seberapa berbahaya ini? Itu tergantung pada seberapa jelas bagi pengguna bahwa tautan tersebut
tautan mandiri. Jika halaman saat ini sangat teridentifikasi dan cocok dengan label link,
pengguna mungkin tahu bahwa tautan tersebut adalah tautan mandiri. Jika halaman saat ini tidak jelas
diidentifikasi atau link tidak cocok dengan judul halaman, pengguna mungkin tidak menyadari bahwa
tautan adalah tautan mandiri dan dapat mengekliknya.
Halaman muka FannieMae tidak menunjukkan bahwa ini adalah halaman muka. Pengunjung
mungkin mengira beranda adalah laman yang berbeda , klik "Beranda" untuk pergi ke sana, dan
menemukan bahwa mereka sudah ada di sana.

Variasi B: Halaman muka mana?

Di situs besar yang memiliki banyak subsitus (mis., Untuk negara berbeda atau
wilayah tempat mereka berbisnis) dan karenanya banyak halaman rumah, situs visi-
Tor dapat dengan mudah kehilangan jejak di situs mana mereka berada. Sub situs tentu saja mendukung
vide link ke situs induk dan subsitus lain. Namun, saat subsitus

Gambar 3.23

[Link]: link di kolom navigasi kiri tetap aktif, bahkan di halamannya sendiri.

[Link] 102/315
26/2/2021 Tanpa judul

Halaman 142

128 Bab 3 Kesalahan Navigasi

Gambar 3.24

[Link]: Halaman beranda Amerika Serikat memiliki tautan mandiri aktif "Amerika Serikat" di kiri atas.

memiliki tautan aktif ke dirinya sendiri, yang dapat membingungkan pengunjung. Rumah AS
halaman situs Web PriceWaterhouseCoopers ([Link]) memberikan contoh:
link "Amerika Serikat" (kiri atas) menampilkan kembali halaman yang sama ini (Gambar 3.24).

Variasi C: Tautan mandiri di breadcrumb navigasi

Alat bantu navigasi yang sering digunakan dalam perangkat lunak Web adalah "remah roti" atau "roti-
jalur remah. " Ini menunjukkan posisi halaman saat ini dalam hierarki halaman menurut
mencantumkan halaman di jalur paling langsung dari halaman beranda ke halaman saat ini
halaman. Namanya berasal dari gagasan menjatuhkan remah roti di tanah
saat melintasi lanskap, untuk menunjukkan jalan pulang. Contoh roti-
remah adalah:

Beranda> Tentang Kami> Orang

Ini akan menunjukkan bahwa halaman "Orang" saat ini ditampilkan dan tercapai
dari "Tentang Kami", yang dapat diakses dari beranda.
Kesalahan umum yang umum adalah pada runut tautan untuk menampilkan laman saat ini sebagai
link aktif, misalnya:

Beranda> Tentang Kami> Orang

Halaman 143

Menyesatkan pengguna dan tidak menunjukkan jalan 129

Gambar 3.25

[Link] 103/315
26/2/2021 Tanpa judul

Item terakhir di jalur runut tautan adalah tautan aktif (sendiri). (A) [Link]. (B) [Link].

[Link] dan [Link] keduanya memiliki blooper ini (Gambar 3.25): semua item dalam
kedua jalur runut tautan adalah tautan aktif, termasuk yang terakhir. ColumbiaSC.
remah roti bersih lebih cenderung membingungkan pengguna karena judul halaman tidak
cocokkan item remah roti terakhir.

Variasi D: Tautan mandiri di tempat lain

Tautan mandiri yang tidak ada dalam tautan navigasi formal cenderung lebih bermasalah
daripada yang ada di bilah navigasi. Pengguna situs sering tidak tahu apakah tautan tersebut
kembali ke halaman saat ini. Pengguna yang mengklik link seperti itu mungkin tidak pada awalnya
menyadari bahwa halaman yang sama telah ditampilkan ulang.
Dalam dokumentasi produk online Sun Microsystem, semua referensi ke Sun.
dokumen produk online adalah tautan — bahkan referensi ke dokumen yang dibaca pengguna
(Gambar 3.26). Pengguna mungkin tidak mengenali ini sebagai tautan mandiri dan dapat mengekliknya
dan menemukan diri mereka — setelah penundaan muat ulang — kembali ke awal dokumen
mereka sedang membaca.

Halaman 144

130 Bab 3 Kesalahan Navigasi

Gambar 3.26

[Link]: dalam dokumen online, referensi ke semua dokumen adalah link, bahkan ke dokumen yang sama.

Menghindari Blooper 17

Nielsen dan Tahir [2001] memberikan aturan desain sebagai berikut:

Jangan menyertakan tautan aktif ke beranda di beranda.

Aturan ini dapat digeneralisasi untuk halaman manapun:

Jangan menyertakan link aktif ke halaman saat ini di halaman saat ini.

Tautan mandiri di bilah navigasi: Sulit dihindari?

Tautan mandiri di bilah navigasi biasa terjadi karena lebih mudah menggunakan persisnya
kode bar navigasi yang sama pada setiap halaman daripada untuk mengubah kode untuk masing-masing
halaman. Pengembang web terkadang berpendapat bahwa sulit untuk mengimplementasikan naviga-
bilah tion di mana item halaman saat ini bukan link aktif. Tidak sulit.
Ini hanya perlu mengedit kode untuk setiap halaman dan menghapus kode tautan untuk
item halaman saat ini di bilah navigasi. [Link] dan [Link] menghindari

[Link] 104/315
26/2/2021 Tanpa judul
tautan mandiri
Jika di bilah
kode bar navigasi
navigasi (Gambar
dibuat 3.27). maka pastikan saja
secara dinamis,
perangkat lunak yang membuatnya menekan tautan pada item bilah navigasi untuk
halaman saat ini.

Menghindari remah roti ke "di sini"

Tautan mandiri dalam remah roti mudah dihindari: item untuk halaman saat ini
seharusnya tidak menjadi tautan. Desain "praktik terbaik" ini dapat dilihat di [Link]
(Gambar 3.28).

Halaman 145

Menyesatkan pengguna dan tidak menunjukkan jalan 131

Gambar 3.27

Bilah navigasi menghindari tautan ke halaman saat ini. (A) [Link]. (B) [Link].

Gambar 3.28

[Link]: item terakhir (untuk halaman saat ini) di jalur runut tautan bukanlah sebuah tautan.

Blooper 18: Terlalu banyak level kotak dialog

Pengembang sering kali begitu terfokus pada mendesain jendela atau halaman Web
jangan mundur untuk melihat gambaran yang lebih besar. Berapa banyak jendela atau halaman
di sana, dan seberapa mudah bagi pengguna untuk menemukan jalannya? Banyak produk perangkat lunak
Produk dan situs Web memiliki terlalu banyak jendela atau halaman, atau memiliki jendela / halaman
hierarki di mana pengguna mudah tersesat. "Dimana saya? Bagaimana saya bisa sampai di sini? Bagaimana
cara kembali ke tempat saya dulu? Di mana pengaturan Lebar Garis itu? Apa yang saya lakukan
sebelum telepon berdering? ”

Halaman 146

[Link] 105/315
26/2/2021 Tanpa judul
132 Bab 3 Kesalahan Navigasi

Membuat representasi dari keseluruhan jendela perangkat lunak atau struktur halaman
ture dapat menunjukkan kepada pengembang "gambaran besar". Representasi terbaik adalah bagan
(Gambar 3.29).
Beberapa aplikasi dan situs Web memiliki begitu banyak jendela atau halaman
bagan tidak praktis karena akan menutupi seluruh dinding atau memang seharusnya begitu
kekacauan kotak-kotak dan garis-garis yang tidak akan membantu. Dalam kasus seperti itu, gunakan file
garis besar sebagai gantinya (Gambar 3.30).
Membuat bagan atau garis besar yang menjabarkan seluruh jendela atau struktur halaman
Gambar sebuah aplikasi atau situs Web menunjukkan di mana strukturnya mungkin terlalu dalam.

Contoh nyata dari blooper tersebut

Di Final Cut Pro Apple, mengekspor gambar dari video, dioptimalkan untuk streaming-
ing, membutuhkan navigasi melalui lima tingkat kotak dialog:

1. Save As menampilkan kotak dialog Save (Gambar 3.31A). Masukkan nama file, set
format ke "Gambar Diam" dan, karena tidak ada pengaturan pada dialog ini
kotak untuk mengoptimalkan gambar untuk streaming, klik "Opsi ...."

Gambar 3.29

Grafik hierarki jendela untuk aplikasi manajemen buku cek.

Halaman 147

Menyesatkan pengguna dan tidak menunjukkan jalan 133

Gambar 3.30
Hirarki jendela buku cek

• Buku Cek MainWindow

• Buat Akun
• Buat Daftar Penerima Pembayaran yang Sering
• Edit Opsi CheckRegister
• Tambahkan Transaksi
• Tampilkan Detail
• Edit Komentar
• Edit Transaksi
• Tampilkan Detail
• Edit Komentar
• Temukan Transaksi
• Transaksi Impor
• Filechooser
• Transaksi Ekspor
• Filechooser
• Analisis Transaksi
• Analisis Arus Kas
• Ringkasan Kategori
• Analisis Pajak

[Link] 106/315
26/2/2021 Tanpa judul
• Tentukan Pendapatan Eksternal
• Tentukan Beban Eksternal
• Buku Cek Saldo
• Edit Transaksi
• Tampilkan Detail
• Edit Komentar

Garis besar hierarki jendela untuk aplikasi manajemen buku cek.

2. Kotak dialog Export Image Sequence Settings muncul (Gambar 3.31B).

(Judul jendela tidak menyebutkan "Opsi"; Blooper 15, halaman 117.)
Masih belum ada pengaturan di sini untuk mengoptimalkan gambar untuk streaming, jadi klik
"Pilihan…."
3. Kotak dialog QuickTime Image Options muncul (Gambar 3.31C). Seperti ini
kotak dialog masih tidak memiliki pengaturan langsung untuk mengoptimalkan gambar untuk streaming,
sekali lagi klik "Opsi…."
4. Kotak dialog Pengaturan Kompresi muncul (Gambar 3.31D). (Catat lagi
ketidakcocokan antara label tombol dan judul jendela.) Sekali lagi
klik “Opsi….”
5. Kotak dialog Photo JPEG Options muncul (Gambar 3.31E). Akhirnya, satu set-
ting untuk mengoptimalkan gambar untuk streaming. Klik, lalu klik OK di sini
kotak dialog, lalu OK di keempat, lalu OK di ketiga, lalu OK di
kedua, lalu OK di awal.

Halaman 148

134 Bab 3 Kesalahan Navigasi

Sekarang, apa yang kita lakukan?

Hierarki kotak dialog yang dalam buruk karena dua alasan: (1) mereka mengalihkan
pengguna dari tujuan awal mereka dan (2) pengguna kehilangan jejak "Oke" yang mana
dan tombol "Batal" adalah tombol yang sekarang. Orang tidak menangani hierarki yang dalam
informasi terstruktur dengan baik; ketika mereka lebih mengikuti hierarki
dari beberapa level, mereka cenderung lupa di mana mereka berada, apa yang mereka lakukan,
dan bagaimana untuk kembali.

Gambar 3.31

SEBUAH

Apple FinalCut Pro: mengekspor gambar dari video, dioptimalkan untuk streaming,
membutuhkan (A), (B), (C), (D), dan (E).

[Link] 107/315
26/2/2021 Tanpa judul
(Lanjutan)

Halaman 149

Menyesatkan pengguna dan tidak menunjukkan jalan 135

Gambar 3.31
(Lanjutan)

Contoh lainnya

Kutipan dari dua ulasan perangkat lunak menunjukkan situasi lain di mana blooper tersebut
terjadi:

■
Garis besar hierarki menunjukkan bahwa area tertentu dari hierarki jendela StockUp
archy terlalu dalam, misalnya, hierarki di bawah berbagai Monitor
jendela (lima tingkat) dan di bawah jendela Analisis (enam tingkat).
Penyederhanaan StockUp membutuhkan perataan area hierarki yang dalam ini.
■ Grafik tersebut menunjukkan bahwa perhatian para desainer terhadap hierarki terlalu dalam
sebagian besar tidak beralasan. Satu-satunya area di mana hierarkinya tampak terlalu dalam
adalah dalam fungsi pemantauan dan pemeliharaan jaringan, yang paling banyak
pengguna tidak akan menggunakan.

Halaman 150

136 Bab 3 Kesalahan Navigasi

Menghindari Blooper 18

Aturan umumnya adalah: Hindari lebih dari dua tingkat kotak dialog. Kotak dialog
dapat memunculkan yang lain, tetapi di luar itu, pengguna mungkin tersesat.

[Link] 108/315
26/2/2021 Tanpa judul
Namun, dan
diklarifikasi aturan ini terlalu disederhanakan dan mudah disalahartikan. Itu perlu
berkualitas.

Kualifikasi 1: Ini hanya berlaku untuk kotak dialog

Kotak dialog adalah jendela sementara yang memungkinkan pengguna menentukan argumen untuk file
fungsi, mengatur atribut untuk objek data, atau mengakui telah melihat pesan.
Sebagian besar aplikasi perangkat lunak menampilkan jendela utama, berbagai kotak dialog,
dan beberapa jendela utama tambahan. Fungsi jendela primer seperti pos terdepan
dasar operasi dan navigasi; mereka berfungsi sebagai “rumah yang jauh dari
rumah." Oleh karena itu, mereka tidak dihitung terhadap batas kedalaman dua level.
Jendela utama sebaiknya hanya berasal dari jendela utama lainnya. Dialog
kotak seharusnya tidak menampilkan jendela utama. 1 Tidak jelas apa yang akan terjadi
terjadi pada jendela utama ketika pengguna menutup kotak dialog yang menampilkan
memainkannya. Dalam hierarki jendela aplikasi, tidak ada cabang yang boleh memiliki file
jendela utama di bawah kotak dialog. Setiap baris yang dilacak di hierarki
harus memiliki beberapa jendela utama, diakhiri dengan paling banyak dua dialog
kotak. Dalam praktiknya, jumlah level jendela utama juga harus
tetap rendah untuk menghindari pengguna yang bingung, tetapi tidak ada aturan desain yang digunakan secara luas.
Kualifikasi yang sama berlaku untuk situs Web dan aplikasi Web, tetapi sedikit
lebih rumit karena ambiguitas tentang apa yang memenuhi syarat sebagai kotak dialog di Web
lingkungan Hidup. Ada tiga cara berbeda untuk menampilkan "kotak dialog" di Web:

■
Kotak dialog yang benar: Browser web dapat menampilkan kotak dialog yang terpisah
dari jendela browser. Kotak dialog seperti itu persis seperti yang ada di
perangkat lunak desktop. Browser web menyediakan beberapa tipe kotak dialog, masing-masing
untuk tujuan tertentu, seperti kesalahan, peringatan, informasi, dan pemilih file.
■ Jendela browser terpisah: Aplikasi web terkadang menampilkan informasi-
kontrol atau kontrol di jendela browser pop-up (kecil). Beberapa browser pop-up
windows berfungsi sebagai kotak dialog: mereka menampilkan pesan atau pengaturan dengan
Tombol “OK” dan “Cancel” (atau serupa) di bagian bawah.
■
Halaman seperti kotak dialog: Beberapa aplikasi Web berisi halaman normal itu
berfungsi sebagai kotak dialog meskipun tidak membuka jendela terpisah.
Mereka menampilkan pesan atau pengaturan dengan tombol navigasi di bagian bawah.
Mereka bersifat sementara; pengguna melihatnya sebentar, mungkin mengedit beberapa pengaturan,
klik OK atau Batal, dan kembali ke halaman sebelumnya.

"Kotak dialog" web, terlepas dari bagaimana mereka ditampilkan, semuanya tunduk pada
batas dua tingkat. Di sisi lain, mereka juga tunduk pada Kualifikasi 2.

1. Dengan pengecualian browser dokumen Bantuan.

Halaman 151

Menyesatkan pengguna dan tidak menunjukkan jalan 137

Kualifikasi 2: Beberapa jenis kotak dialog tidak dihitung

Beberapa kotak dialog menyediakan fungsi yang sangat sederhana, idiomatis, dan familiar
bahwa kehadiran mereka tidak akan mengganggu atau membingungkan pengguna. Oleh karena itu, mereka dikecualikan
dari batas dua tingkat.
Misalnya, banyak aplikasi berisi fungsi yang mengharuskan pengguna untuk melakukannya
tentukan nama file. Mereka menampilkan kotak dialog pemilih file, dan pengguna mengetik
nama file atau telusuri hierarki file untuk memilih file. Pemilih file
sangat umum sehingga sebagian besar pengguna tahu apa yang harus dilakukan dengannya. Pengguna tidak menganggap
mereka sebagai "tempat" dalam aplikasi, melainkan hanya sebagai mekanisme pilihan.
Parafrase Gertrude Stein, "tidak ada " dalam pemilih file. Pemilih file
tidak menambahkan kerumitan yang terlihat pada aplikasi. Oleh karena itu, meskipun pemilih file
adalah kotak dialog tingkat ketiga, itu tidak akan melanggar maksimum dua tingkat. Ini
pengecualian mencakup kotak dialog "pemilih" sederhana dan umum lainnya juga,
seperti pemilih warna dan tanggal.
Jenis kotak dialog lain yang harus dikecualikan saat menghitung dialog
tingkat kotak adalah pesan kesalahan yang hanya menerima satu tanggapan: "Oke, saya melihat
pesan." Seperti pemilih, alasan pengecualian kotak dialog kesalahan sederhana
adalah bahwa mereka tidak benar-benar menambahkan "tempat" navigasi ke aplikasi dan begitu juga
tidak terlalu meningkatkan kerumitan navigasi di dalamnya.
Kotak dialog yang dikecualikan dari batas dua tingkat tidak menampilkan dia-
kotak kayu mereka sendiri. Dengan kata lain, mereka adalah titik akhir dalam hierarki.
Ini sangat penting. Setiap kotak dialog yang dapat menampilkan kotak dialog lain,
terlepas dari jenisnya, harus diperhitungkan terhadap batas dua tingkat.

Buat bagan atau garis besar hierarki jendela

[Link] 109/315
26/2/2021 Tanpa judul
Pengembang tidak dapat mengetahui apakah perangkat lunak mereka melanggar atau sesuai dengan
aturan dua tingkat kecuali mereka mengetahui struktur jendela perangkat lunak, yang biasanya
sekutu membutuhkan merepresentasikannya sebagai bagan atau garis besar. Banyak pengembang tidak melakukannya
ini dan berakhir dengan hierarki yang terlalu dalam. Anda harus membuat dan memelihara
representasi dari struktur jendela sebagai bagian dari proses desain Anda. Ini
juga dapat digunakan dalam dokumentasi pengguna.
Saat membuat representasi dari hierarki jendela, hilangkan pemilih
dan kotak dialog kesalahan. Memasukkannya membuat bagan atau garis besar terlalu berat.

Cara untuk memotong level berlebih

Jika hierarki jendela atau halaman untuk suatu aplikasi terlalu dalam di beberapa tempat, apa
bisa kamu lakukan Itu tergantung pada mengapa Anda memiliki pengaturan pada jendela terpisah.

■
Beberapa GUI menggunakan jendela tambahan untuk menyediakan pengungkapan progresif — sembunyikan
detailnya hingga pengguna meminta untuk melihatnya. Jika demikian, Anda dapat menggunakan "Detail"
panel alih-alih jendela terpisah.

Halaman 152

138 Bab 3 Kesalahan Navigasi

Gambar 3.32

Mengajukan Sunting Melihat Format Jendela Tolong

Membuka

Memotong
Edit menu Salinan
saat pengguna Tempel
menulis Ubah Kasus Kalimat
email Menghapus huruf kecil
pesan Hapus semua HURUF BESAR
Temukan... Kasus Judul
Menggantikan... tOOGLE cASE
Periksa ejaan...

(A) Kotak dialog Perubahan Kata Kasus. (B) Opsi kasus di menu bertingkat alih-alih kotak dialog.

■ Beberapa kotak dialog menyediakan opsi pada perintah. Misalnya, Microsoft

Fungsi Ubah Kasus Word menampilkan kotak dialog yang menawarkan beberapa cara untuk
mengubah kasus teks yang dipilih (Gambar 3.32A). Kotak dialog ini tidak
tertanam dalam level yang berlebihan, tetapi jika demikian, seorang desainer dapat menghilangkannya
meletakkan pilihan dalam menu berjenjang (Gambar 3.32B).

Navigasi pencarian yang buruk

Salah satu cara bagi pengguna sistem interaktif untuk menemukan jalan ke tujuan mereka adalah dengan
menggunakan fungsi Pencarian. Namun, tidak semua fungsi Pencarian dibuat sama.
Beberapa membuat pencarian menjadi mudah, sementara yang lain mempersulit. Beberapa fungsi Pencarian
tions memperumit tahap masukan-pencarian dengan menyediakan terlalu banyak cara untuk mencari
tanpa panduan yang cukup tentang kapan harus menggunakan yang mana. Fungsi Pencarian lainnya
tions memperumit tahap hasil penelusuran dengan menampilkan hasil yang menyulitkan
untuk menemukan item yang benar-benar relevan. Bagian terakhir bab ini membahas umum
cara fungsi Penelusuran memperumit dalam menavigasi ke arah tujuan pengguna.
Bloopers terkait Penelusuran lainnya dijelaskan dalam Bloopers Web [Johnson, 2003].

[Link] 110/315
26/2/2021 Tanpa judul

Halaman 153

Navigasi pencarian yang buruk 139

Blooper 19: Kotak pencarian yang bersaing

Saat pengguna dihadapkan pada beberapa kotak telusur, mereka sering bertanya-tanya: “Yang mana
yang harus saya gunakan? ” Apakah mereka berbeda? “Apakah mereka menelusuri data yang sama?” Nya
desain buruk yang mengalihkan pengguna dari tujuan mereka sendiri dan membuat mereka berpikir
tentang perangkat lunak [Krug, 2005].

Variasi A: Ups! Pencarian salah!

Terkadang kotak pencarian yang berbeda pada halaman mencari hal yang berbeda, tetapi pengguna
mungkin tidak tahu itu. Situs Web Universitas Canterbury Selandia Baru
([Link]) memberikan contoh. Situs "Kursus, Subjek, dan
Halaman Kualifikasi ”memiliki dua kotak pencarian (Gambar 3.33). Banyak yang beranggapan demikian
kedua kotak dapat mencari di katalog Kursus untuk kursus tertentu. Faktanya,
hanya kotak di sebelah kiri yang melakukannya. Kotak di sebelah kanan untuk menelusuri situs
itu sendiri — baik seluruh situs atau hanya bagian Kursus. Diberikan kode kursus,
itu tidak akan menemukan daftar kursus; hanya artikel dan halaman yang menyebutkan saja.
Namun, sebagian besar pengguna melihat kotak pencarian di sebelah kanan terlebih dahulu karena memang demikian
posisi standar situs untuk kotak pencarian. Hal ini menyebabkan banyak siswa yang melakukannya
coba pada awalnya untuk mencari informasi kursus menggunakan kotak pencarian yang salah .

Variasi B: Dua kotak pencarian yang identik. Bagaimana memilih?

Variasi kedua dari blooper adalah ketika situs atau aplikasi memiliki dua hal yang identik
atau kotak telusur yang tampak sangat mirip di halaman yang sama. Pengguna mungkin berasumsi seperti itu
jika ada dua, mereka pasti berbeda. Bahkan jika pengguna mengetahui pencarian itu

Gambar 3.33

[Link]: dua kotak telusur di halaman. Yang mana mencari kursus?

Halaman 154

140 Bab 3 Kesalahan Navigasi

Gambar 3.34

[Link] 111/315
26/2/2021 Tanpa judul

[Link]: dua kotak telusur yang identik di halaman. Pengguna harus memilih salah satu secara sewenang-wenang.

kotaknya sama, mereka harus memilih salah satu… secara sewenang-wenang. Sebuah contoh terjadi
di [Link] (Gambar 3.34).

Variasi C: Hmm. Mana yang terbaik?

[Link], telah dikutip di atas untuk melakukan Variasi A, juga com-

cocok dengan variasi ketiga. Halaman pencarian situs menawarkan tiga kotak pencarian — empat
jika kita menghitung kotak pencarian utama di kanan atas halaman (Gambar 3.35).
Halaman ini memiliki tiga masalah:

■ Pengguna situs mungkin tidak menyadari bahwa ada kotak pencarian di kanan atas dan
“UC Search” sama. Mereka harus mempelajari ini. Bahkan setelah mereka melakukannya, kami
memiliki Variasi B.
■
"Pencarian Lanjutan" menggunakan mesin pencari yang sama dengan "Pencarian UC" tetapi pro-
memberikan lebih banyak kontrol. Perbedaan dalam kontrol kecil, tidak seperti beberapa
situs, di mana pencarian lanjutan memiliki banyak kontrol tambahan. Untuk ini
perbedaan kecil, kotak terpisah "Penelusuran Lanjutan" tampaknya tidak beralasan.
Selain itu, beberapa pengguna mungkin berasumsi bahwa "Pencarian Lanjutan" menggunakan kata yang berbeda
mesin pencari.
■ "Google Search" menggunakan mesin pencari Google dan menyarankan bahwa "ini
paling baik untuk penelusuran banyak kata. " Ini membuat pengguna berpikir: “Haruskah saya menggunakan
kotak telusur lain untuk penelusuran satu kata? Apakah Google lebih buruk untuk dosa-
pencarian kata gle? Mengapa saya harus menggunakan 'UC Search' dan 'Advanced Search'
sama sekali?"

Halaman 155

Navigasi pencarian yang buruk 141

Gambar 3.35

[Link] 112/315
26/2/2021 Tanpa judul

[Link]: empat kotak telusur di halaman, tetapi tidak jelas bagaimana pengguna memilih satu.

Menghindari Blooper 19

Desainer GUI mungkin memiliki alasan untuk menyediakan beberapa kotak pencarian yang bersaing
di halaman. Namun, melakukan itu memiliki biaya yang harus dipertimbangkan terhadap keuntungannya.
efits. Biayanya menjadi seperti ini: kotak pencarian bersaing untuk mendapatkan perhatian.

Halaman 156

142 Bab 3 Kesalahan Navigasi

Jika kotak pencarian yang bersaing mewakili fungsi Pencarian yang berbeda , seperti pada
contoh dari [Link], salah satu biayanya adalah orang mungkin menggunakan file
salah satu. Mereka mungkin memperhatikan yang salah terlebih dahulu dan menggunakannya, mengabaikan
yang benar. Bahkan jika mereka melihat keduanya, mereka mungkin tidak tahu bagaimana perbedaannya — atau
meskipun mereka berbeda — dan memilih yang salah untuk pencarian yang mereka maksudkan.
Jika kotak pencarian untuk fungsi Pencarian yang sama , seperti di [Link], pengguna
harus memutuskan mana yang akan digunakan. Menurut Raskin [2000], pemberian multipel
cara di UI untuk melakukan hal yang sama menghabiskan waktu pengguna dan mengalihkan perhatian mereka dari cara mereka
tugas pokok.

Kurang itu lebih

Untuk fungsi Search, seperti untuk antarmuka pengguna secara umum, less is more. Faktanya, untuk
kotak telusur pada suatu halaman, angka terbaik adalah 1. Lebih dari satu menyebabkan kebingungan,
penundaan, dan kesalahan.
Jika Anda mempertimbangkan untuk meletakkan dua atau tiga salinan dari kotak pencarian yang sama
pada halaman karena Anda tidak yakin di mana pengunjung akan melihat, jangan lakukan itu. Tempat
hanya satu kotak telusur yang mencolok, di salah satu tempat standar: kiri atas di bawah
logo, kanan atas, atau kiri bawah di bawah kolom navigasi. Pastikan pengguna
kenali itu sebagai kotak pencarian.
Jika Anda berencana menyertakan kotak untuk mencari seluruh Web, perhatikan nasihat ini
dari Nielsen dan Tahir [2001]:

Jangan menawarkan fitur untuk "Search the Web"… Pengguna akan menggunakan pencarian favorit mereka
mesin untuk melakukan itu, dan opsi ini membuat pencarian lebih kompleks dan rawan kesalahan.

Jika Anda ingin menyediakan fungsi Pencarian yang berbeda untuk mencari data yang berbeda
sumber, seperti konten situs umum vs. artikel berita vs. harga saham, desain
agar terlihat sangat berbeda. Rancang setiap kotak telusur agar terlihat spesifik
domain pencariannya sendiri. Tidak satu pun dari kotak telusur tujuan khusus harus terlihat
seperti kotak pencarian umum (Gambar 3.36A). Sebuah fungsi untuk mencari harga saham
dapat berukuran agar hanya sesuai dengan simbol saham, dan tombolnya dapat diberi label "Dapatkan
Kutipan ”bukan“ Pencarian ”(Gambar 3.36B).
Halaman beranda [Link] dan [Link] memiliki
fungsi pencarian yang terlihat pada halaman yang sama (Gambar 3.37).
Terakhir, jika halaman memiliki dua kotak pencarian untuk memungkinkan pengguna memilih di antara pencarian
mesin memiliki karakteristik yang berbeda, tanyakan apakah itu alasan sebenarnya. Jika nyata

Gambar 3.36

Kotak telusur untuk tujuan yang berbeda terlihat berbeda. (A) Pencarian situs utama. (B) Pencarian harga saham.

Halaman 157

[Link] 113/315
26/2/2021 Tanpa judul

Navigasi pencarian yang buruk 143

Gambar 3.37

Kotak telusur untuk tujuan yang berbeda terlihat berbeda. (A) [Link]. (B) [Link].

alasannya adalah bahwa pengembang tidak dapat memutuskan antara mesin pencari, pilih
satu dan pertimbangkan yang lainnya "pengembangan eksplorasi". Jika berniat memberi
pilihan pengguna adalah tulus, tanyakan apakah pengguna benar-benar peduli. Bahkan jika mereka melakukannya, jangan
tawarkan pilihan di beranda Anda. Halaman beranda harus memiliki satu jenderal
kotak telusur, titik. Opsi harus dibatasi pada halaman "Pencarian Lanjutan".
Bahkan di sana, pilihannya harus menjadi opsi yang memengaruhi satu kotak pencarian
daripada beberapa pesaing lainnya.

Blooper 20: Penelusuran hasil penelusuran yang buruk

Bayangkan Anda baru saja menggunakan fungsi Pencarian situs Web. Anda sekarang terlihat-
mempelajari hasilnya. Menjelajahi hasil pencarian sering kali termasuk melihat melalui sev-
halaman hasil akhir untuk item yang relevan. Banyak tampilan hasil pencarian tidak menyediakan
cara mudah bagi pengguna untuk menavigasi halaman klik. Banyak daftar hit masuk
tumpukan sebanyak apa pun yang muat di layar dan membuat pengguna mengklik "Berikutnya" berulang kali
untuk membuka halaman lebih dari yang pertama.
Di [Link], mencari "komputer tablet" menghasilkan 138.039 klik, dalam daftar
10 per halaman (Gambar 3.38). Halaman hasil hanya menyediakan satu cara untuk bergerak
melalui halaman hasil: halaman demi halaman menggunakan link "Berikutnya" dan "Kembali" di
bagian bawah halaman (Gambar 3.38), menunggu pemuatan halaman setiap kali. Tidak ada
cara mudah untuk sampai ke halaman terakhir, atau yang keenam.
Fungsi Pencarian Produk di [Link], sebuah elektronik online
menyimpan, melakukan bentuk yang lebih buruk dari kesalahan ini. Ini mencantumkan produk 20 sekaligus
dengan hanya "Berikutnya" dan "Kembali" untuk berpindah antar halaman, tetapi juga tidak menunjukkan
catat jumlah total produk yang ditemukan. Jika ditemukan lebih dari 20, halaman pertama
dari hits memiliki tombol "Next" (Gambar 3.39). Jika ditemukan lebih dari 40, yang kedua
halaman memiliki tombol "Berikutnya", dan seterusnya. Hanya dengan "BERIKUTNYA" yang membosankan ke
Halaman terakhir pengguna dapat mempelajari berapa banyak produk yang ditemukan.

Halaman 158

144 Bab 3 Kesalahan Navigasi

Gambar 3.38

[Link] 114/315
26/2/2021 Tanpa judul
[Link]: hasil pencarian sulit untuk dijelajahi karena hanya "Berikutnya" dan "Kembali" yang disediakan.

Gambar 3.39

[Link]: hasil penelusuran tidak memberikan jumlah klik dan hanya memberikan "Berikutnya" dan "Kembali".

Halaman 159

Navigasi pencarian yang buruk 145

Gambar 3.40

[Link]: link untuk semua halaman hit mendukung penjelajahan hasil pencarian yang mudah.

Menghindari Blooper 20

Hasil pencarian seharusnya tidak hanya mengingatkan pengguna apa istilah pencarian itu dan
menunjukkan jumlah hit [Johnson, 2003], mereka juga harus membuatnya mudah
bagi pengguna untuk menelusuri hit. Jika sejumlah besar klik ditampilkan di
serangkaian halaman, harus jelas berapa banyak halaman hasil yang ada, dan itu
seharusnya bisa sampai ke halaman hasil manapun dengan satu atau dua klik.
[Link] memudahkan pengguna untuk menelusuri halaman hasil pencarian
(Gambar 3.40).

Blooper 21: Hasil pencarian yang berisik

Bahkan jika hasil pencarian memungkinkan pengguna untuk menavigasi halaman-halaman hit, masih ada
masalah tentang betapa mudahnya menemukan hit yang benar-benar relevan di antara yang lainnya.
Pertimbangkan bagaimana Anda melakukannya. Apakah Anda membaca dengan cermat setiap hit, meneliti setiap
detail? Apakah Anda mengklik setiap pukulan satu per satu? Tentu saja tidak! Anda dengan cepat memindai
daftar beberapa hit yang tampak menjanjikan.
Sekarang bayangkan Anda adalah seorang desainer web yang jahat. Anda ingin mempersulit
orang untuk melihat item yang menjanjikan di hasil pencarian. Bagaimana Anda bisa melakukan itu?
Sederhana:

1. Mengubur perbedaan kebisingan . Sertakan gobbledygook yang berlebihan di setiap item

jadi item sulit dibedakan. Paksa orang untuk memeriksa masing-masing dengan cermat

[Link] 115/315
26/2/2021 Tanpa judul
untuk melihat tentang apa dan perbedaannya dari item lain. Anda bisa memuat
setiap hit dengan hype pemasaran, link navigasi, atau output database
sama untuk setiap hit. Itu akan memperlambat mereka!

Halaman 160

146 Bab 3 Kesalahan Navigasi

2. Paksa pengguna untuk mengklik klik . Bahkan lebih baik lagi, buat hit terlihat persis sama.
Maka satu-satunya cara untuk memeriksa relevansinya adalah dengan benar-benar mengkliknya,
menjumlahkan waktu berharga pengguna saat browser memuat halaman.

Banyak fungsi Penelusuran Web menggunakan "teknik" ini dengan sangat baik, tampaknya begitu
telah dirancang oleh desainer jahat yang berusaha mempersulit pencarian
pengunjung.
Contoh mengubur perbedaan kebisingan berasal dari fungsi Pencarian
di situs web Federal Reserve Bank of Minneapolis. Setiap klik di
hasil pencarian mencakup tiga bagian konten berulang (Gambar 3.41):

■
Tautan teratas pada setiap item dimulai dengan teks “Federal Reserve Bank of
Minneapolis. "
■
Teks yang dikutip dari halaman biasanya dimulai dengan “Saya di>>>>
Artikel Publikasi Artikel Kotak Alat () ”- mungkin tautan navigasi
umum untuk kebanyakan halaman.
■
URL ditampilkan secara jelas untuk setiap klik, termasuk bagian yang menunjukkan-
bahwa item tersebut ditemukan di [Link] yaitu
jelas, karena itulah situs yang dicari.

Gambar 3.41

[Link]: konten yang diulang dalam klik membuat hasil "berisik" dan sulit dipindai.

Halaman 161

Navigasi pencarian yang buruk 147

Pengulangan ini tidak memberikan nilai apa pun pada daftar hasil; itu hanya menambahkan gangguan visual,
sehingga membuat hasil sulit dipindai dengan cepat.
Bagaimana dengan teknik jahat kedua: memiliki pukulan yang terlihat sangat mirip dengan
satu-satunya cara untuk memeriksa relevansinya adalah dengan mengekliknya? Pada awal 2006, AS

[Link] 116/315
26/2/2021 Tanpa judul
Situs web Departemen Luar Negeri ([Link]) memiliki fungsi Pencarian yang ditampilkan
judul yang sama untuk beberapa klik berturut-turut, seperti yang ditunjukkan oleh hasil pencarian
untuk "Colin Powell" (Gambar 3.42). Itu juga secara mencolok menampilkan lokasi
setiap klik dalam hierarki halaman situs. Lokasi kemungkinan besar sama
atau sangat mirip untuk klik berurutan, jadi tidak terlalu berguna untuk mengevaluasi dan
membedakan hit.
Pada akhir 2006, Departemen Luar Negeri telah mendesain ulang hasil pencarian mereka menjadi
jauh lebih mudah untuk memindai dan mengevaluasi, sebagai hasil dari pencarian terbaru untuk “Colin
Powell ”menunjukkan (Gambar 3.43).
Contoh lain datang dari [Link], situs Web Yale
Ikatan Alumni Universitas (Gambar 3.44). Setiap klik menunjukkan tautan navigasi
yang sama untuk semua klik.
Dengan hasil seperti ini, pengguna mungkin berasumsi bahwa mesin pencari salah
mengembalikan beberapa tautan ke item yang sama. Ada perbedaan antara
hit, tetapi sulit dikenali dan tidak berguna untuk memutuskan hit mana
relevan.

Gambar 3.42

[Link] (Jan 2006): data yang ditampilkan untuk setiap klik sebagian besar tidak berguna untuk membedakannya.

Halaman 162

148 Bab 3 Kesalahan Navigasi

Gambar 3.43

[Link] (Okt 2006): data yang ditampilkan untuk setiap klik lebih mudah dipindai dan dievaluasi.

[Link] 117/315
26/2/2021 Tanpa judul

Menghindari Blooper 21

Desainer mana pun ingin pengguna perangkat lunak mereka dapat memindai hasil pencarian
dengan cepat dan temukan item yang relevan. Bagaimana Anda bisa menghindari perancang jahat
dalam diri Anda berkompromi dengan niat baik Anda? Mudah: balikkan desainer jahat
aturan:

1. Tunjukkan dan tekankan data penting . Minimalkan pengulangan di antara klik. Paling
dari setiap item harus ada informasi yang memungkinkan orang membedakan item dari
satu sama lain. Data pembeda untuk setiap item harus ditekankan.
Informasi yang berulang harus dihilangkan atau dikurangi. Kurangi gangguan visual
dan memfokuskan perhatian pengguna pada informasi di setiap item.
2. Minimalkan kebutuhan untuk mengklik . Orang harus mengklik klik hanya untuk bertindak
sekutu mendapatkan item (beli, baca). Mereka tidak harus mengikuti tautan saja
untuk melihat mana yang relevan.

Halaman 163

Navigasi pencarian yang buruk 149

Bandingkan hasil pencarian yang buruk yang ditampilkan oleh situs Web Alumni Yale (Gambar
3.44) dengan hasil yang jauh lebih berguna yang ditampilkan oleh situs utama Yale (Gambar
3.45). Dalam kedua contoh tersebut, penelusurannya adalah "chemistry". Perhatikan bagaimana utamanya
situs meminimalkan pengulangan antara klik dan secara visual menghilangkan penekanan URL klik,
yang tentu saja mirip.

Gambar 3.44

[Link]: banyak hits yang terlihat hampir identik.

[Link] 118/315
26/2/2021 Tanpa judul

Halaman 164

150 Bab 3 Kesalahan Navigasi

Gambar 3.45

[Link]: hasil penelusuran mudah dipindai dan dievaluasi.

Halaman 165

[Link] 119/315
26/2/2021 Tanpa judul

Bloopers tekstual
pengantar

Teks tidak komunikatif

Teks yang berpusat pada pengembang

Teks menyesatkan

151

Halaman 166

152 Bab 4 Kesalahan Tekstual

pengantar

Satu ironi dari antarmuka pengguna grafis adalah bahwa sebagian besar tidak terlalu grafis. Itu
GUI tipikal berisi banyak teks:

■ Label untuk perintah dalam menu atau tombol sebagian besar berupa teks.
■
Instruksi hampir selalu berupa teks.
■ Sebagian besar input pengguna terdiri dari mengetik atau memilih kata dan angka.
■
Label pada sebagian besar kontrol dan bidang formulir adalah teks.
■ Nama yang ditetapkan pengguna ke file data dan objek data lainnya selalu menggunakan tex-
tual.
■
Pesan kesalahan dan peringatan sebagian besar bersifat tekstual, meskipun disorot dengan a
warna atau simbol.

Oleh karena itu, jangan meremehkan pentingnya teks dalam GUI.

Perancang perangkat lunak mungkin mencoba meminimalkan penggunaan teks dalam perangkat lunak, tetapi
banyak konsep tidak dapat diungkapkan tanpa teks. Pepatah “Sebuah gambar
bernilai seribu kata ”adalah penyederhanaan yang berlebihan: terkadang hanya beberapa kata
lebih berharga daripada sejumlah gambar.
Misalnya, perancang game film interaktif menginginkan
Kontrol navigasi game menjadi murni grafis, tetapi dirasa perlu
untuk menambah banyak simbol dengan teks untuk memperjelas artinya [Johnson,
1998].
Bahkan dalam antarmuka pengguna yang paling grafis, teks biasanya berperan.
Aplikasi Creative's Surround Mixer lebih grafis daripada kebanyakan (Gambar 4.1).
Meskipun demikian, ini menggunakan teks: logo perusahaan, judul aplikasi, file
menu, dan tooltips untuk kontrol.
Masalah kegunaan tekstual biasanya mudah dan murah untuk diperbaiki. Di
di sisi lain, mereka sering memiliki akar penyebab dalam proses pengembangan atau organisasi.
zation. Memperbaiki itu, tentu saja, tidak mudah atau murah.
Karena teks memainkan peran penting dalam antarmuka pengguna, ada banyak cara
untuk menggunakannya dengan buruk. Ini adalah blooper tekstual. Bab ini menjelaskan tiga katego-

[Link] 120/315
26/2/2021 Tanpa judul
ries dari blooper
memberikan tekstual,
nasihat menjelaskan
tentang mengapa pengembang terkadang melakukannya, dan
cara menghindarinya.

Teks tidak komunikatif

Empat blooper tekstual pertama disebabkan oleh tulisan yang buruk. Mereka sering kali menghasilkan
dari menugaskan penulisan teks di GUI kepada orang-orang yang tidak ahli di
bahwa.

Halaman 167

Teks tidak komunikatif 153

Blooper 22: Terminologi yang tidak konsisten

Salah satu blooper tekstual yang paling umum adalah menjadi sembarangan dan tidak konsisten-
ent tentang istilah mana yang digunakan untuk konsep apa. Ini membuat banyak perangkat lunak
lebih sulit untuk dipelajari.
Banyak tim pengembangan tidak menyadari bahwa terminologi yang tidak konsisten itu buruk,
jadi mereka tidak berusaha memastikan bahwa terminologi mereka konsisten. Apa
dimulai sebagai cacat dalam proses pengembangan berubah menjadi cacat dalam produk mereka :
pemetaan many-to-one dan one-to-many antara istilah dan konsep.

Pembuka mata: Cantumkan semua istilah

Ini berguna untuk membuat tabel yang menunjukkan istilah-istilah yang digunakan dalam aplikasi dan
manualnya untuk dilihat oleh setiap pengguna konsep. Hasilnya biasanya membuka mata
kepada manajer pengembangan: “Saya tidak tahu! Tidak heran pengguna mengalami kesulitan
belajar menggunakan produk kami! ” Sayangnya, reaksi khas dari program-
mers adalah "Jadi apa? Kami memiliki masalah yang lebih penting untuk dikhawatirkan daripada
apakah kami menggunakan istilah yang sama persis dari satu layar ke layar berikutnya. ”
Ada dua cara berbeda agar terminologi menjadi tidak konsisten.

Variasi A: Istilah berbeda untuk konsep yang sama

Variasi yang lebih umum adalah perangkat lunak menggunakan beberapa istilah untuk satu
konsep. Ini mungkin merujuk pada "hasil" di satu jendela dan "keluaran" di jendela lain,
Padahal maksudnya sama. Jika Anda mencoba membingungkan pengguna, ini
akan menjadi salah satu cara terbaik.

Gambar 4.1

Mixer Surround Creative: sangat grafis, tetapi seperti kebanyakan GUI, menyertakan teks.

Halaman 168

[Link] 121/315
26/2/2021 Tanpa judul

154 Bab 4 Kesalahan Tekstual

Berikut ini adalah contoh istilah yang digunakan secara bergantian di dunia nyata
aplikasi:

■
Properti, atribut, parameter, pengaturan, sumber daya
■
Jendela selamat datang, jendela pengenalan
■
Versi, revisi
■
FAQ (pertanyaan yang sering diajukan), QNA (pertanyaan dan jawaban)
■
Temukan, cari, kueri, pertanyaan
■
Server, layanan
■
Keluar, keluar
■
Ukuran pesanan, jumlah pesanan
■
Simbol saham, ID instrumen, instrumen, ID instrumen
■
Tugas, langkah
■
Tentukan tujuan, tentukan tujuan

Terminologi yang tidak konsisten dapat terjadi akibat perubahan nama selama pengembangan
yang tidak diperbaiki di mana pun dalam perangkat lunak dan dokumentasi. Bisa
juga hasil dari tidak membuat dan menggunakan leksikon produk selama pengembangan.
Terkadang istilah yang tidak konsisten disebabkan oleh kurangnya komunikasi atau a
kurangnya kesepakatan antar programmer. Pemrogram juga mungkin tidak punya
menganggap penggunaan nama yang konsisten itu penting, mengingat tekanan waktu mereka
berada di bawah. Semua penyebab ini berasal dari Blooper 67: Perkembangan anarkis
(halaman 348).
Kasus yang sangat umum dari banyak istilah untuk sebuah konsep adalah ketika pesan kesalahan
gunakan nama internal bidang formulir daripada labelnya di formulir. Contoh
berasal dari [Link], [Link], dan [Link] (Gambar 4.2).
Ketika kata-kata berbeda digunakan untuk menggambarkan hal yang sama, pengguna mungkin tidak
menyadari bahwa. Pengguna terutama memikirkan tentang tujuan yang ingin mereka capai dan
data yang mereka buat dan manipulasi (Prinsip Dasar 5, halaman 35). Mereka
tidak memikirkan sama sekali tentang antarmuka pengguna, seperti apakah "ID Pengguna" adalah
hal yang sama dengan "Alias". Terminologi yang tidak konsisten menyebabkan pengguna salah membuat
kesalahan atau menghabiskan upaya mental untuk mencari tahu bagaimana istilah berhubungan.

Variasi B: Istilah yang sama untuk konsep yang berbeda

Kesalahan sebaliknya hampir sama umum: menggunakan satu istilah untuk lebih dari satu
konsep, juga dikenal sebagai membebani kata. Misalnya, ini banyak
hal-hal yang dimaksud dengan "Tampilan" dalam satu aplikasi:

■
Jendela tampilan data, misalnya, Memahami Tampilan, Tampilan Evaluasi,
Tampilan Peringkat Bidang

Halaman 169

Teks tidak komunikatif 155

Gambar 4.2

ID pengguna diberi nama berbeda dalam pesan kesalahan. (A) [Link]. (B) [Link]. (C) [Link].

[Link] 122/315
26/2/2021 Tanpa judul
■
Berbagai cara memfilter Tampilan Pemahaman, mis., Tampilan Wajib,
Tampilan Spesifik
■
Tindakan yang mempengaruhi diagram aliran data, misalnya, Shrink View, Enlarge View
■
Menu View, yang mengontrol tampilan bagian lain dari aplikasi
■
Beberapa item dalam menu View memperlakukan "View" sebagai kata kerja (misalnya, "View →
Hasil ”) sementara yang lain memperlakukannya sebagai kata benda (misalnya,“ Lihat → Perbesar ”).

Menggunakan istilah yang sama untuk hal yang berbeda biasanya tidak disengaja; itu terjadi
karena pengembang tidak memikirkannya. Dalam percakapan normal, orang menggunakan
kata-kata yang memiliki banyak arti, dan pendengar menyelesaikan ambiguitas baik dari
konteks di mana kata itu digunakan atau dengan meminta pembicara menjelaskan.
Komunikasi manusia-komputer kurang memaafkan ambiguitas. Itu tidak pro-
vide banyak konteks percakapan. Permintaan klarifikasi hanya satu arah:
perangkat lunak dapat meminta penggunanya untuk mengklarifikasi masukan, tetapi pengguna tidak dapat meminta perangkat lunak untuk
memperjelas arti sebuah kata. Oleh karena itu, kata-kata yang berlebihan kurang dapat diterima
dalam antarmuka pengguna daripada dalam komunikasi antar orang.
Microsoft Word memiliki istilah yang berlebihan. Menu Sisipkan Word menyertakan file
Perintah Sisipkan Objek… dan perintah Sisipkan Gambar… (Gambar 4.3). Memasukkan
Objek menyisipkan berbagai tipe objek, termasuk Persamaan, kerja Excel-
lembar, dokumen Word, dan gambar Word. Pengguna mungkin mengharapkan Sisipkan Objek
dengan Word Picture sebagai tipe objek untuk melakukan hal yang sama seperti Sisipkan Gambar.
Salah! Menyisipkan Gambar Word menggunakan Sisipkan Objek menyisipkan bingkai grafik
untuk membuat gambar garis. Sebaliknya, Sisipkan Gambar menampilkan pemilih file itu
memungkinkan pengguna mengimpor file gambar yang dibuat secara eksternal.

Halaman 170

156 Bab 4 Kesalahan Tekstual

Gambar 4.3

Microsoft Word: istilah overloaded "Gambar" berarti file gambar dan area gambar garis.

Seringkali istilah yang sama berarti objek dan bagian dari objek. Dalam sebuah
program email, kata "pesan" terkadang berarti keseluruhan file
diterima dari pengguna lain, termasuk header, badan pesan, dan lampiran.
Di lain waktu, kata "pesan" mungkin hanya berarti konten teks. Ambi-
guity akan membingungkan pengguna baru, memperlambat pembelajaran mereka.
Istilah yang umumnya kelebihan muatan adalah "pilih". Ini sering digunakan untuk kedua arti: (a)
mengklik objek untuk menyorotnya dan (b) menambahkan objek ke daftar. Mempertimbangkan,
misalnya, kotak dialog Pembaruan Tersedia dari Adobe Reader (Gambar 4.4).
Daftar di sebelah kanan diberi label "Dipilih". Tombol "Tambah" menambahkan item dari
daftar kiri ke daftar kanan. Item yang ditambahkannya adalah item yang disorot di sebelah kiri
daftar. Apa yang kita sebut barang itu? The dipilih item, tentu saja.
Saat Anda memberikan arti tambahan untuk "memilih", Anda membuka pintu untuk membingungkan-
instruksi seperti:

Untuk memilih pembaruan yang ingin Anda instal, pertama-tama pilih pembaruan tersebut di daftar Tersedia
dan klik tombol "Tambah", yang menambahkan mereka ke daftar yang Dipilih.

Jendela Preferensi Cetak & Faks di MacOS X juga menyalahgunakan "pilih"

[Link] 123/315
26/2/2021 Tanpa judul
(Gambar 4.5). Yang pertama dari dua pengaturan mengacu pada printer "yang dipilih", berarti-
menggunakan printer default . (Kami akan menyimpan untuk nanti kesalahan mengekspos GUI
istilah toolkit "dialog" untuk pengguna.)

Halaman 171

Teks tidak komunikatif 157

Gambar 4.4

Adobe Reader: salah menggunakan istilah khusus "dipilih".

Gambar 4.5

MacOS X: "dipilih" disalahgunakan sebagai default .

Kebingungan antara istilah "kursor", "titik penyisipan teks", dan "layar

pointer ”adalah sumber ambiguitas lainnya. Sebelum GUI, tidak ada hal seperti itu
sebagai penunjuk layar, dan titik penyisipan teks serta kursor adalah sama
benda. Sekarang ini adalah konsep yang berbeda, tetapi "kursor" terkadang berarti
titik penyisipan teks dan terkadang berarti penunjuk layar.

Halaman 172

158 Bab 4 Kesalahan Tekstual

Menghindari Blooper 22

Pengguna perangkat lunak mencoba mencari jalan di aplikasi yang tidak dikenal.

[Link] 124/315
26/2/2021 Tanpa judul
Mereka
databasetidak tahu bahwa
"membuat query"pemrogram
sedangkanjendela utamasebagian
programmer memanggil pencarian
besar dialog
Box menyebutnya "menentukan pertanyaan." Mereka tidak tahu bahwa "karyawan"
dan "record" adalah hal yang sama atau bahkan "record" adalah kata benda dalam hal ini
program.
Selain itu, pengguna komputer tidak ingin mengetahui hal-hal tersebut. Mereka hanya
ingin melakukan pekerjaan mereka. Mereka tidak tertarik dengan komputer dan perangkat lunaknya
sendiri. Mereka tidak peduli bagaimana pengembang melihat perangkat lunak tersebut. Mereka seringkali begitu
fokus pada pekerjaan mereka jika mereka mencari fungsi Pencarian tetapi itu
berlabel "Kueri" di sini, mereka mungkin melewatkannya. Oleh karena itu, rancanglah terminologi dalam a
UI seolah-olah pengguna akan menafsirkannya dengan sangat harfiah.

Satu nama per konsep

Caroline Jarrett, otoritas GUI dan desain bentuk, menyatakan aturan ini untuk ter-
minologi dalam perangkat lunak dan situs web:

Nama yang sama, hal yang sama; nama berbeda, hal berbeda — Caroline Jarrett, www.
[Link]

Istilah dalam perangkat lunak harus memetakan secara ketat 1: 1 ke konsep. Bahkan istilah itu
ambigu di dunia nyata seharusnya hanya berarti satu hal dalam perangkat lunak .
Jika tidak, kegunaan perangkat lunak akan terganggu.

Buat leksikon produk

Di awal pengembangan, Anda harus menentukan konsep yang akan diekspos oleh perangkat lunak
kepada pengguna. Ini disebut mengembangkan "model konseptual" (Prinsip Dasar 2,
halaman 18). Dari situ tim Anda harus mengembangkan "leksikon" produk. 1 Ini daftar
nama dan definisi untuk setiap konsep yang akan ditampilkan kepada pengguna di
produk dan dokumentasinya. Itu harus memetakan istilah 1: 1 ke konsep. Saya t
tidak boleh menetapkan istilah yang berbeda untuk satu konsep atau satu istilah untuk dif-
konsep yang berbeda.
Istilah dalam leksikon harus berasal dari tugas yang didukung perangkat lunak , bukan
implementasinya. Persyaratan harus sesuai dengan vocabu- tugas normal pengguna
lary, bahkan jika mereka baru. Biasanya, desainer UI, pengembang, penulis teknis,
manajer, dan pengguna semua membantu membuat leksikon.

1. Juga disebut "nomenklatur", "kosakata", "kamus", "standar terminologi".

Halaman 173

Teks tidak komunikatif 159

Gunakan istilah standar industri untuk konsep umum

Konsep tertentu di GUI memiliki nama standar industri. Ini adalah GUI
setara dengan "kata-kata yang dipesan" dalam bahasa pemrograman. Jika Anda mengganti nama
konsep tersebut atau memberikan arti baru pada nama standar, Anda akan mempertimbangkan
pengguna sekering.
Satu istilah yang dipesan adalah "pilih". Ini berarti mengklik suatu objek untuk disorot
itu, menandainya sebagai objek untuk tindakan di masa depan. Kata "pilih" tidak seharusnya
digunakan untuk tujuan lain dalam GUI, misalnya, menambahkan item ke daftar atau koleksi
tion. Adobe Reader dapat menghindari kesalahan besar dengan menggunakan label "To Be Installed"
alih-alih menyalahgunakan kata "pilih" (Gambar 4.6).
Istilah standar dan definisinya diberikan dalam panduan gaya platform, seperti
seperti yang untuk Windows [Microsoft Corp., 2006], Macintosh [Apple Computer,
2006], dan Java [Sun Microsystems, 2001]. Anda harus menggunakan standar industri
Kosakata GUI untuk platform target Anda.

Terapkan leksikon

Leksikon produk harus diikuti secara konsisten di seluruh perangkat lunak,

manual pengguna, dan literatur pemasaran. Untuk memastikan ini, seseorang harus menegakkannya
leksikon. Ini dapat berupa arsitek informasi proyek atau kepala
penulis teknis. Pelaksana mengingatkan pengembang untuk menggunakan yang telah disepakati
istilah untuk konsep atau petisi untuk mengubah leksikon .

[Link] 125/315
26/2/2021 Tanpa judul
Gambar 4.6

Adobe Reader dapat menghindari penyalahgunaan "yang dipilih" dengan memberi label ulang pada daftar yang benar "Untuk Dipasang".

Halaman 174

160 Bab 4 Kesalahan Tekstual

"Penegak" memunculkan gambar pria kekar yang membawa kotak biola, tapi ternyata itu
lebih baik jika penegaknya ramah. Inilah satu sisi percakapan telepon
antara penegak leksikon dan programmer:

“Hei, Anoop, ini Sergei. Sebentar? Di halaman Anda di layanan pelanggan kami
Situs web, Anda menggunakan istilah "laporan bug" untuk saat pelanggan mengajukan masalah.
Tapi istilah yang kita sepakati adalah "permintaan tindakan," ingat? Itulah yang ada di
kamus. Dimana leksikonnya? Di situs Web Intranet proyek. Dapatkah kamu
ubah "laporan bug" menjadi "permintaan tindakan" di semua halaman Anda? Kami menjalankan kegunaan
tes pada hari Kamis, jadi saya berharap Anda dapat membuat perubahan ini pada hari Rabu.
Kamu akan? Terima kasih banyak!"

Leksikon harus diperlakukan sebagai dokumen hidup: ia berubah sebagai produk

berevolusi berdasarkan wawasan desain baru, perubahan fungsionalitas, uji kegunaan
hasil, dan umpan balik pasar.

Uji leksikon pada pengguna

Saat leksikon dikembangkan, itu harus diuji pada orang-orang yang tipikal
perangkat lunak itu ditujukan kepada pengguna untuk melihat apakah itu cocok dengan kosakata pengguna. Jika
tidak, ubahlah.
Terminologi dapat diuji sebelum perangkat lunak diimplementasikan atau bahkan
dirancang sepenuhnya. Pengguna bisa diperlihatkan istilah dan diminta menjelaskan apa masing-masing
istilah berarti bagi mereka. Mereka juga dapat diminta untuk mencocokkan istilah dengan deskripsi-
tions dengan menyusun kartu 3 × 5 atau dengan menggambar garis antara suku dan
deskripsi dicetak di atas kertas. Akhirnya, terminologi dapat diuji lebih awal
mock-up.

Gunakan file pesan

Sebelum rilis, tinjauan sistematis terhadap semua teks dapat mengungkap kedua variasi
blooper ini: istilah berbeda untuk konsep yang sama dan istilah yang sama untuk perbedaan-
konsep ent. Namun, jika satu-satunya cara untuk meninjau pesan program, label,
dan instruksi adalah dengan mengoperasikan program atau mencari melalui sumbernya
kode, pengawasan mungkin.
Jika teks yang ditampilkan oleh program ada dalam file pesan, 2 mereview dan
memeriksa adanya konflik dan inkonsistensi jauh lebih mudah. Itu hanya satu
dari sekian banyak keuntungan menggunakan file pesan.
Ketika bagian yang berbeda dari perangkat lunak perlu mengacu pada konsep yang sama atau
menyajikan pesan yang sama, mereka harus mereferensikan string teks yang sama
di file pesan. Itu mengurangi kemungkinan melakukan Variasi A dari
blooper: istilah berbeda untuk konsep yang sama.

2. Sering disebut "file sumber daya".

[Link] 126/315
26/2/2021 Tanpa judul

Halaman 175

Teks tidak komunikatif 161

File pesan juga memudahkan untuk menghindari Variasi B dari blooper: file
istilah yang sama untuk konsep yang berbeda. Saat file pesan ditinjau, duplikat
string teks di dalamnya adalah salah satu dari dua kemungkinan:

1. String teks yang berlebihan yang seharusnya satu: Ini adalah kesalahan. Meninggalkan mereka
terpisah memungkinkan seseorang akan mengubah satu dan mengabaikan
mengubah yang lain, menyebabkan perangkat lunak mewujudkan Variasi A dari blooper.
Semua kecuali satu contoh string harus dihapus, dan semua referensi ke
string itu harus menunjuk ke satu contoh itu.
2. String teks untuk situasi berbeda yang sama: Ini mungkin
kesalahan, sehingga memunculkan Variasi B dari kesalahan besar tersebut. Mereka harus disusun ulang
sehingga mereka berbeda (sambil tetap setia pada leksikon produk). Beberapa seperti itu
duplikasi mungkin homonim atau heteronim yang sah, misalnya, program
mungkin menggunakan kata kerja "menolak", yang berarti "menolak", dan kata benda "menolak",
artinya "sampah". Dalam kasus seperti itu, pertimbangkan untuk mengubah salah satu istilah, untuk
Misalnya, menggunakan kata "sampah", bukan kata benda "menolak". Ketika trans-
terkait dengan bahasa lain, kata-kata yang dieja dengan sama mungkin adalah
diterjemahkan ke kata-kata yang berbeda pula; misalnya, kata kerja "refuse" trans-
Terjemahan bahasa Jerman menjadi "ablehnen," sedangkan kata benda "menolak" diterjemahkan
menjadi "Abfall."

Menggunakan file pesan tidak hanya meningkatkan konsistensi tekstual, tetapi juga menyediakannya
satu tempat bagi penulis teknis untuk memeriksa teks dan sangat menyederhanakan
terjemahan ke bahasa lain.

Blooper 23: Terminologi tidak jelas

Bahkan ketika perangkat lunak menggunakan istilah secara konsisten, terminologinya masih belum jelas
dan rentan salah tafsir. Ini dapat terjadi dengan tiga cara berbeda.

Variasi A: Istilah ambigu

Istilah itu berarti hanya satu hal dalam perangkat lunak yang masih bisa rancu. SEBUAH
istilah mungkin memiliki arti lain di luar perangkat lunak. Pengguna kemudian memiliki
untuk mengabaikan apa yang mereka ketahui tentang istilah tersebut dan mempelajari artinya di
perangkat lunak .
“Enter” sering digunakan dalam perangkat lunak komputer yang berarti mengetik data ke dalam
komputer. Namun, "masuk" juga berarti "masuk ke". Dalam perangkat lunak komputer dan
terutama di situs Web, arti "masuk" mungkin masuk akal
kepada pengguna sebagai arti "tipe data". Desainer sering kali terlalu fokus pada desain mereka
memiliki makna yang dimaksudkan dari suatu istilah sehingga mereka gagal untuk menyadari bahwa istilah tersebut memiliki yang lain
arti yang sama tepat.

Halaman 176

162 Bab 4 Kesalahan Tekstual

Satu aplikasi memiliki layar splash dengan tombol berlabel grafis itu
di atas mouse ditampilkan teks tooltip ini:
Klik di sini untuk masuk ke aplikasi.

Mengklik tombol akan menampilkan jendela utama aplikasi. Namun, nov-

pengguna es dapat salah mengartikan tooltip sebagai arti mengklik tombol
akan menampilkan kotak teks di mana mereka dapat memasukkan nama perangkat lunak
aplikasi.
Ambiguitas tekstual bisa menjadi lebih buruk ketika kata kerja digunakan sebagai kata benda. Lembut-
perusahaan ware mengembangkan alat pengembangan aplikasi untuk C ++ pro-
tata bahasa. Bar menu utama menyertakan perintah Build Window. Itu

[Link] 127/315
26/2/2021 Tanpa judul
pengembang bermaksud ini menjadi frasa kata benda: jendela untuk bangunan
sebuah program — menyusun dan menghubungkan berbagai modul program
bersama-sama — Jendela Bangun . Sayangnya, pengguna — hard-core C ++ pro-
grammers — bertahan dalam membaca perintah sebagai frase kata kerja: Build
Jendela . Interpretasi alternatif ini — membangun jendela — setidaknya dibuat
masuk akal dalam alat pengembangan aplikasi sebagai inter-
pretasi melakukannya. Itu adalah kejutan bagi para desainer yang akan ditafsirkan oleh siapa pun
perintah seperti itu.
Masalah yang disebabkan oleh perubahan kata kerja menjadi kata benda akan dibahas lebih lengkap di
Blooper 26 (halaman 173).

Variasi B: Istilah untuk konsep yang berbeda

tumpang tindih dalam arti

Pemrogram terkadang menggunakan sinonim untuk menamai konsep yang berbeda: misalnya,
"Hapus" untuk menghapus teks dan "hapus" untuk menghapus file. Ketika dua berbeda
fungsi memiliki nama yang biasanya sinonim, pengguna harus mempelajari yang mana
sinonim artinya konsep yang mana.
MacOS Apple menggunakan kata "copy" untuk menyalin konten dokumen
menggunakan "duplikat" untuk menyalin file dokumen. Pengguna harus mempelajari sewenang-wenang ini
perbedaan.
Program email Eudora (Gambar 4.7) memberikan contoh lain. Itu
Menu “Special” (nama yang tidak jelas dan umum) berisi menu cascading Find
dengan perintah untuk mencari pesan email yang disimpan. Menu Temukan memiliki
dua perintah Temukan dan Pencarian, yang melakukan hal berbeda. Temukan pencarian
header pesan di folder dan sorotan email yang saat ini terbuka
pesan pertama yang cocok. Pencarian mencari satu atau beberapa folder email
pesan yang berisi teks tertentu di bagian mana pun dan mencantumkan semua yang cocok
pesan.
Berikut adalah dua contoh dunia nyata:

■
Fasilitas pencarian Web Intranet menyediakan dua fungsi berbeda untuk
mencari informasi yang berhubungan dengan pencarian sebelumnya. Salah satunya adalah Find Related

Halaman 177

Teks tidak komunikatif 163

Gambar 4.7

Eudora untuk Mac: pengguna harus mempelajari perbedaan sewenang-wenang antara Temukan dan Pencarian.

Konsep; yang lainnya adalah Find Related Terms. Banyak pengguna tidak memahami
berdiri perbedaan antara kedua fungsi ini, dan beberapa bahkan tidak
menyadari bahwa mereka berbeda.
■
Sebuah perusahaan mengembangkan situs Web untuk orang yang ingin membeli rumah di
Amerika Serikat. Pengguna yang sudah masuk dapat menyimpan dua jenis catatan untuk digunakan di masa mendatang:
(1) preferensi untuk rumah, seperti kisaran harga, ukuran, jumlah kamar, dan
(2) daftar rumah beranotasi yang sedang mereka pertimbangkan. Kedua jenis
catatan terpisah, tetapi memiliki nama yang mirip: catatan tentang tujuan membeli rumah
ada di "Personal Planner", sementara catatan tentang rumah yang menarik ada di
sebuah "Jurnal Pribadi." Tidak mengherankan, pengujian menemukan bahwa pengguna bingung
dua ini.

Variasi C: Konsepnya terlalu mirip

Dalam Variasi B, sulit untuk mengatakan apakah istilahnya terlalu mirip, konsepnya
terlalu mirip, atau keduanya. Terkadang, konsep dalam aplikasi sangat mirip
yang membingungkan pengguna, apa pun namanya. Ini bukan nama-

[Link] 128/315
26/2/2021 Tanpa judul
ing masalah,
dibahas melainkan
sepenuhnya lebih
dalam Babdalam, masalah
6, Interaksi desain konseptual.
Bloopers (Blooper 42,Karena itu,246).
halaman memang demikian
Untuk
sekarang, cukup untuk mengatakan bahwa konsep yang tumpang tindih membuat aplikasi menjadi sulit
untuk mempelajari.

Menghindari Blooper 23

Kesalahan besar ini dihasilkan dari memahami UI dari perspektif desainer—

yang bias dengan mengetahui arti segala sesuatu di UI — bukan
dari perspektif pengguna (Prinsip Dasar 3, halaman 26). Istilah untuk a

Halaman 178

164 Bab 4 Kesalahan Tekstual

produk perangkat lunak harus mencerminkan perspektif pengguna dan harus dirancang
agar mudah dipelajari dan diingat (Prinsip Dasar 6, halaman 37). Tiga aturan akan
membantu Anda mencapai itu.

Hindari sinonim

Jangan gunakan kata-kata yang biasanya sinonim untuk arti yang berbeda dalam
perangkat lunak. Pastikan istilah perangkat lunak untuk berbagai konsepnya jelas
dibedakan satu sama lain. Berbeda dengan aplikasi GMail Google
Eudora, hanya menggunakan satu istilah untuk pencarian: "pencarian" (Gambar 4.8).

Hindari istilah yang ambigu

Hindari menggunakan istilah yang ambigu di dunia nyata atau di dunia nyata
arti yang bisa disalahartikan dengan artinya di perangkat lunak. Jangan
berasumsi bahwa hanya karena Anda telah mendefinisikan sebuah kata untuk memiliki arti tertentu,
pengguna akan menafsirkannya dengan cara yang sama. Pertimbangkan bagaimana pengguna akan menafsirkan kata-kata tersebut
Anda telah memilih.

Uji terminologi pada pengguna

Pengembang perangkat lunak terkadang berkata: “Istilah itu tidak membingungkan. Sudah jelas
apa artinya!" Apakah suatu istilah membingungkan bukan untuk pengembang perangkat lunak
untuk menilai sendiri; itu harus ditentukan dengan mengamati dan bertanya kepada pengguna.
Oleh karena itu, tidak cukup hanya menghasilkan model konseptual dan leksikon produk.
Leksikon harus diuji pada pengguna perwakilan, seperti dijelaskan di bawah
bagaimana menghindari Blooper 22. Jika pengujian mengidentifikasi istilah yang membingungkan pengguna
yang lain, ubahlah.

Gambar 4.8

Gmail: satu istilah untuk menelusuri: "penelusuran".

Halaman 179

[Link] 129/315
26/2/2021 Tanpa judul

Teks tidak komunikatif 165

Jika pengguna salah menafsirkan terminologi yang digunakan dalam perangkat lunak Anda, itu bukan istilah mereka
masalah; itu Anda masalah. Mereka akan menggunakan sesuatu yang lain yang tidak menyesatkan atau
membingungkan mereka. Oleh karena itu, berusaha keras untuk menemukan terminologi yang tidak menyesatkan atau
membingungkan pengguna Anda.

Blooper 24: Tulisan yang buruk

Sekalipun perangkat lunak menggunakan istilah secara konsisten, tidak mendefinisikan ulang kata-kata umum, dan
menghindari jargon programmer, istilah kode, dan kata-kata ambigu, tulisan bisa
masih belum memadai untuk pasar komersial. Ini dapat bervariasi dalam gaya
satu label ke label lainnya. Itu bisa menggunakan ejaan dan tata bahasa yang buruk. Itu bisa salah
huruf besar. Singkatnya, itu bisa menjadi tulisan yang buruk.
Sekalipun tidak mengganggu kegunaan, tulisan yang buruk memberi tahu pelanggan: "Kami luar biasa
teurs! Kami tidak tahu cara menghasilkan produk yang dipoles! " Kesalahan besar ini terjadi
dalam dua variasi.

Variasi A: Gaya penulisan tidak konsisten

Banyak aplikasi menunjukkan ketidakkonsistenan gaya dalam teks instruksi built-in

tions, nama perintah (dalam menu dan tombol), label pengaturan, jendela
judul, dan sebagainya. Inkonsistensi umum meliputi:

■
memberi nama beberapa perintah setelah tindakan (kata kerja) tetapi yang lain setelah objek
(kata benda), misalnya, Show Details vs. Properties;
■
menggunakan bahasa "telegraf" yang singkat untuk beberapa label pengaturan atau pesan (mis.,
“Masukkan tanggal pengiriman”) tetapi bahasa bertele-tele untuk orang lain (misalnya, “Harap sebutkan
tanggal pesan akan dikirim ”);
■
menggunakan kapitalisasi judul (mis., Keamanan Database) untuk beberapa judul tapi
kapitalisasi kalimat (mis., Keamanan database) untuk orang lain;
■
mengakhiri beberapa tapi tidak semua kalimat (misalnya, dalam instruksi atau pesan kesalahan)
dengan periode.

Berikut beberapa contoh dari perangkat lunak yang telah saya ulas:

■
Di kotak dialog Startup, dua pilihan diberi label "Buat Studi Baru"
dan "Buka Studi yang Ada". Hanya yang kedua yang memuat artikel "An".
■
Beberapa bidang untuk memasukkan nama diberi label "Nama X" sementara yang lain diberi label
berlabel "X", misalnya, "Nama Tabel:" vs. "File:". Keduanya harus menyertakan kata
"Nama" atau tidak keduanya.
■
Menu Grafik pada bilah menu berisi huruf besar yang tidak konsisten
perintah: “Tambahkan Pengukur…,” “Pengukur cetak…,” “Tambahkan Grafik…,” dan “Cetak
grafik…. ” Mungkin programmer yang berbeda menerapkan Add and Print
fungsi, dan tidak ada manajer atau penulis teknis yang memeriksa perintah mereka
label untuk konsistensi.

Halaman 180

166 Bab 4 Kesalahan Tekstual

Halaman "Search" dari situs Web Association for Computing Machinery

([Link]) memiliki contoh gaya penulisan yang tidak konsisten. Ini menawarkan lima yang berbeda
pencarian. Tiga mengatakan mereka mencari “sekarang” (Gambar 4.9). Pengguna mungkin bertanya-tanya jika ini
berarti dua pencarian lainnya nanti . Tiga dari tautan tersebut menyebutkan ACM. Pengguna bisa
anggap ini berarti yang lain untuk organisasi lain. Faktanya, semua lima tautan
adalah untuk ACM, dan kelima pencarian sekarang. Opsi diberi label tidak konsisten.
Ini menunjukkan kurangnya standar dan karena itu amatiran. Itu juga bisa menyebabkan
kebingungan.

Variasi B: Diksi yang buruk, tata bahasa, ejaan,

dan tanda baca

Banyak aplikasi perangkat lunak mengalami kesalahan ejaan dan penulisan. Meskipun
dokumentasi pengguna biasanya ditulis oleh penulis teknis, teks yang muncul
di software biasanya di tulis oleh programmer. Pemrogram dilatih untuk
tulis kode, bukan teks prosa, dan itu terlihat dalam kualitas tulisan dalam banyak hal
program.
Dua contoh mahal dari penulisan yang buruk dalam perangkat lunak disediakan oleh dua

[Link] 130/315
26/2/2021 Tanpa judul
perusahaan perangkat
Masing-masing lunak
memiliki timSilicon Valley berukuranaplikasi
yang mengembangkan sedang desktop
yang tidak akan
besar disebutkan
untuk namanya.
Microsoft
Sistem operasi Windows. Pada kedua proyek tersebut, para insinyur bertanggung jawab

Gambar 4.9

[Link]: bahasa tidak konsisten. Beberapa tautan menyertakan ACM, yang lainnya tidak. Beberapa diakhiri dengan
"sekarang"; yang lainnya tidak.

Halaman 181

Teks tidak komunikatif 167

untuk semua teks yang ditampilkan oleh perangkat lunak, tidak ada satupun yang ditinjau oleh teknis
penulis. Faktanya, salah satu dari dua tim bahkan tidak memiliki penulis teknis.
Meskipun perangkat lunak itu ditujukan untuk pelanggan berbahasa Inggris, tidak ada
pengembang di kedua tim adalah penutur asli bahasa Inggris. Keduanya
perusahaan mempekerjakan sebagian besar programmer mereka dari luar negeri, terutama India,
Taiwan, dan Rusia. Sementara para insinyur di kedua tim sangat kompeten.
pemrogram tenda, upaya mereka untuk menulis nama perintah, label pengaturan,
pesan kesalahan, dan instruksi berbatasan dengan lucu. Namun, potensi
pelanggan tidak terhibur. Manajemen di masing-masing dua perusahaan ini
mungkin berpikir bahwa praktik perekrutan mereka menyediakan programmer terampil di a
diskon, tetapi mereka gagal mengantisipasi bahwa praktik-praktik itu juga akan menambah
meninjau dan menulis ulang biaya atau mengurangi penjualan produk.
Contoh terbaru dari teks yang ditulis dengan buruk disediakan oleh Adobe Reader dan
[Link] (Gambar 4.10). Kemungkinan besar tidak ada pesan kesalahan yang ditulis oleh a
penulis terlatih bahasa Inggris atau bahkan oleh seseorang yang fasih berbahasa Inggris.
Tidak semua contoh tulisan yang buruk cukup serius untuk merusak pemahaman-
ing. Terkadang mereka hanya kesalahan ketik sederhana yang tidak tertangkap.
Kesalahan tipografi dalam perangkat lunak memberi pengguna kesan pekerja yang ceroboh-
kapal dan amatir. Contoh kesalahan seperti itu terjadi di situs Web
Foto / Video / Audio B&H. Formulir pemesanan (Gambar 4.11) memiliki tipografi
kesalahan. Bisakah kamu menemukannya? Seharusnya sudah ditangkap sebelum dilepaskan.

Gambar 4.10

[Link] 131/315
26/2/2021 Tanpa judul

Bahasa Inggris yang buruk. (A) Adobe Reader. (B) [Link].

Halaman 182

168 Bab 4 Kesalahan Tekstual

Gambar 4.11

[Link]: kesalahan ketik di situs Web e-commerce.

Menghindari Blooper 24

Dengan mengikuti aturan ini, pengembang perangkat lunak dapat memastikan bahwa teks ditampilkan
oleh perangkat lunak mereka menyampaikan kesan profesionalisme dan perhatian.

Gunakan orang-orang yang ahli menulis

Jika pengembang perangkat lunak ingin produk dan layanan mereka profesional, mereka
perlu mendapatkan profesional untuk semua pekerjaan yang terlibat dengan pengembangan perangkat lunak.
Pemrogram profesional dalam menulis kode. Mereka adalah amatir dalam menulis prosa.
Pemrogram tidak boleh menulis teks yang muncul di perangkat lunak. Arsip informasi-
tects dan penulis teknis adalah profesional yang tepat untuk pekerjaan itu.
Semua teks dalam aplikasi — instruksi, peringatan, pesan kesalahan, pengaturan
label, label tombol — harus ditinjau oleh arsitek informasi,
editor teknis, dan penulis teknis. Ini tidak hanya meningkatkan kualitas
teks yang ditampilkan oleh perangkat lunak, ini membantu memastikan konsistensi dengan panduan pengguna.
Hingga saat ini, situs web [Link] memberikan contoh
gaya penulisan yang tidak konsisten. Formulir pendaftaran pelanggan situs meminta tiga
potongan informasi — nama, kode pos, dan alamat email — menggunakan tiga
bentuk label yang berbeda: pertanyaan, label satu kata, dan perintah (Gambar 4.12A).
Baru-baru ini, halaman tersebut direvisi untuk memperbaiki ketidakkonsistenan (Gambar 4.12B) dan
jadi sekarang sampaikan kesan yang lebih profesional.

Gambar 4.12

[Link]. (A) Label formulir tidak konsisten. (B) Konsisten.

Halaman 183

Teks tidak komunikatif 169

Periksa ejaan semua teks

Semua teks yang muncul dalam aplikasi harus diperiksa ejaannya. Lulus pertama

[Link] 132/315
26/2/2021 Tanpa judul
akan menggunakan perangkat lunak pemeriksa ejaan. Kecerdikan mungkin diperlukan untuk mendapatkan
perangkat lunak pemeriksa ejaan untuk memeriksa file pesan. Teks juga harus diperiksa
oleh editor atau penulis teknis manusia.

Blooper 25: Terlalu banyak teks

Jenis tulisan buruk yang penting adalah terlalu banyak teks. Teks yang tidak perlu itu buruk
kapan saja [Strunk and White, 1999], tetapi sangat buruk dalam perangkat lunak. Kapan
menavigasi ke apa yang mereka inginkan, pengguna perangkat lunak tidak membaca; mereka memindai apapun-
hal yang sesuai dengan tujuan mereka [Krug, 2005]. Sayangnya, teks yang tidak perlu
sangat umum di Web dan cukup umum di aplikasi desktop.

Verbose instruksi dan label

Label dan instruksi yang bertele-tele, jika tidak diabaikan, "mengubur" informasi penting
mation dan memperlambat pengguna. Bayangkan diri Anda mencoba mengatur gambarnya
Aplikasi Properti Entri Teks SmartDraw (Gambar 4.13).

Gambar 4.13

SmartDraw: instruksi dan label yang terlalu bertele-tele.

Halaman 184

170 Bab 4 Kesalahan Tekstual

Gambar 4.14

[Link] 133/315
26/2/2021 Tanpa judul

[Link]: instruksi bertele-tele. (A) halaman "Permintaan Layanan". (B) Login / registrasi
halaman.

Demikian pula, teks "selamat datang" yang tidak diperlukan dan instruksi yang terlalu bertele-tele akan diterima
dengan cara pengguna situs web pemerintah kota Columbia, Carolina Selatan
(Gambar 4.14).

Tautan panjang

Tautan tekstual di situs Web, jika terlalu panjang dan terutama jika ada dalam daftar, adalah
sulit untuk dipindai. Jika teks diulang di antara link, scannability dan legibility cukup
lebih banyak lagi. Daftar panjang link dari California Department of Motor
Situs Web Kendaraan menunjukkan hal ini (Gambar 4.15). Judul juga terlalu bertele-tele, misalnya,
duplikat pertama "Informasi Surat Izin Mengemudi" dari judul tepat di atasnya.

Halaman 185

Teks tidak komunikatif 171

Gambar 4.15

[Link]: tautan teks yang bertele-tele dan berulang-ulang sulit dipindai.

Menghindari Blooper 25

Gunakan teks tidak lebih dari yang diperlukan untuk menyampaikan informasi yang dimaksudkan.

■
Hindari paragraf prosa yang panjang.
■
Gunakan judul, frasa pendek, poin-poin.
■
Pertahankan agar tautan tetap pendek, satu hingga tiga kata; jelaskan dengan teks nonlink.
■
Hindari pengulangan dalam daftar tautan; potong teks berulang atau pindahkan ke judul.

Penulis kegunaan Jakob Nielsen [1999d], Steve Krug [2005], dan Ginny Redish
[2007] semua mendukung singkatnya. Krug memperingatkan bahwa bagian prosa yang panjang tidak akan dibaca
dan menyarankan:

Singkirkan separuh kata di setiap halaman, lalu singkirkan separuh lagi.

[Link] 134/315
26/2/2021 Tanpa judul

Halaman 186

172 Bab 4 Kesalahan Tekstual

Contoh memotong teks yang tidak perlu

[Link] menunjukkan bagaimana teks dapat dipotong. Pada akhir 2002, mereka menyederhanakan verbose mereka
Halaman “Find A Dealer” (Gambar 4.16A): paragraf panjang dipotong menjadi satu kalimat
dan tiga langkah berpoin (Gambar 4.16B). Mereka juga menyadari bahwa mereka tidak membutuhkannya
baik kode pos maupun negara bagian. Baru-baru ini, mereka menyederhanakannya lebih jauh, menjadi enam kata,
termasuk label (Gambar 4.16C).

Gambar 4.16

[Link]: instruksi bertele-tele dipotong menjadi beberapa peluru, lalu menjadi enam kata. (A) Awal 2002. (B)
Akhir 2002. (C) 2007.

Halaman 187

Teks yang berpusat pada pengembang

173

Tujuannya: scannability, clarity, simplity

Singkatnya hanyalah alat untuk mencapai tujuan yang sebenarnya: kemudahan pemahaman dan navigasi,
scannability, kejelasan, kesederhanaan. Pengguna tidak membaca; mereka memindai. Singkatnya membantu mereka
pahami dan navigasi dengan memindai.
Jika Anda melupakan ini dan berusaha singkat demi kepentingannya sendiri, kegunaan bisa menderita
[Raskin, 2000]. Membatasi tombol atau label tautan yang tidak perlu ke satu kata dapat terlihat
bagi pengguna seperti kode rahasia yang harus mereka pelajari.

Teks yang berpusat pada pengembang

[Link] 135/315
26/2/2021 Tanpa judul
Tiga blooper berikutnya adalah kasus teks yang menggunakan jargon komputer dan presentasi
sudut pandang pengembang.

Blooper 26: Berbicara Geek

Misalkan Anda menginstal beberapa perangkat lunak baru di komputer Anda, tetapi ketika Anda mencoba
untuk menggunakannya, Anda menemukan bahwa entah bagaimana Anda telah memperoleh ver- bahasa asing
bagian dari perangkat lunak. Anda akan membuangnya dan mencoba mendapatkan versi yang ada di dalamnya
bahasa Anda sendiri.
Bagi banyak orang, bahasa "asing" yang ditampilkan perangkat lunak mereka adalah technobab-
Ble, juga dikenal sebagai Geek. Namun, orang yang perangkat lunaknya berbicara tentang Geek lebih buruk
off daripada mereka yang perangkat lunaknya menggunakan bahasa asing karena mereka tidak bisa mendapatkannya
versi pengganti dalam bahasa yang mereka pahami. Ada beberapa perbedaan
cara untuk berbicara Geek.

BEETLE BAILEY © RAJA FITUR SYNDICATE

Variasi A: Menggunakan jargon programmer

Sebagian besar profesi dan hobi memiliki jargon — kosakata khusus itu
memungkinkan praktisi untuk berkomunikasi dengan lebih tepat dan efisien. Menggunakan spe-
jargon khusus itu baik ketika Anda berkomunikasi dengan orang lain yang berbagi
spesialisasi Anda: meningkatkan efisiensi dan kejelasan. Namun, menggunakan khusus
jargon saat berkomunikasi dengan orang yang tidak berbagi keistimewaan tersebut
buruk: menghalangi efisiensi dan kejelasan. Saat berkomunikasi dengan orang-orang
di sisi bidang keahlian Anda, Anda harus mematikan jargon.

Halaman 188

174 Bab 4 Kesalahan Tekstual

Banyak pengembang perangkat lunak tidak mematikan jargon mereka saat menulis teks
yang muncul di perangkat lunak yang ditujukan untuk non pemrogram. Mengapa?
■
Kurangnya kesadaran bahwa mereka menggunakan jargon
■
Ketidakmampuan untuk menonaktifkan jargon meskipun mereka menyadarinya
Gunakan
■
Keyakinan bahwa jika orang ingin menggunakan komputer, mereka perlu memahami
jargon komputer
■
Tenggat waktu yang ketat dan dukungan penulis yang tidak memadai, ditambah dengan asumsi-
Karena seseorang akan memeriksa dan memperbaiki kata-katanya nanti
■
Sebuah desain yang mengekspos konsep teknis dan detail implementasi itu
tidak relevan dengan tugas pengguna (Blooper 40, halaman 241)

Karena alasan ini, banyak perangkat lunak menggunakan akronim seperti "USB" dan "PDF",
komputer murni seperti "driver perangkat" dan "memori flash", kata-kata itu
jarang digunakan dalam bahasa Inggris standar seperti "mode" dan "buffer," frasa itu
ubah kata kerja menjadi kata benda seperti "lakukan perbandingan" dan "selesaikan pengeditan", dan istilah
yang mencerminkan sudut pandang pengembang daripada pengguna seperti "pengguna
default. " Efeknya pada pengguna berkurang pemahaman dan memperlambat pembelajaran.
Banyak pesan kesalahan yang ditampilkan oleh program email Eudora ada di Geek.
Saat pengguna login dengan kata sandi yang tidak valid, Eudora memunculkan pesan kesalahan
yang menjelaskan protokol komunikasi antara Eudora dan server email
(Gambar 4.17A). Kesalahan di hadapan umum! Mungkin pengembang dan administrator jaringan Eudora
peduli dengan komunikasi klien-server, tetapi sebagian besar pengguna Eudora tidak.
Eudora menampilkan pesan kesalahan yang lebih culun saat mencoba mengambil
email baru gagal karena server nama domain tidak merespons (Gambar 4.17B). Ini
pesan samar bahkan untuk pengguna Eudora yang tahu apa itu server nama domain.

Gambar 4.17

[Link] 136/315
26/2/2021 Tanpa judul

Eudora: pesan kesalahan technobabble. (A) Kata sandi salah. (B) Server tidak merespons.

Halaman 189

Teks yang berpusat pada pengembang

175

Contoh software berbahasa Geek

■ Contoh 1: Aplikasi Web mengharuskan pengguna untuk masuk, tetapi menyebutnya "mengautentikasi".
Halaman login diberi label "Otentikasi Pengguna". Ini buruk karena: (1)
pengguna tidak tahu apa artinya "otentikasi" dan (2) kata "pengguna" itu
jargon pengembang perangkat lunak; pengguna tidak mengidentifikasi dengan istilah itu. Lebih buruk lagi, jika menjadi pengguna
membiarkan aplikasi tidak digunakan selama lebih dari 15 menit, bagian belakang aplikasi
pengguna log off, tetapi aplikasi di browser Web pengguna terus
muncul saat pengguna meninggalkannya. Pengguna yang mengganggu penggunaan aplikasi mereka-
tion untuk melakukan sesuatu yang lain akan sering kembali ke aplikasi, menemukannya sebagaimana mereka
diharapkan, coba lakukan sesuatu, dan tiba-tiba dapatkan pesan berikut:
Sesi Anda telah berakhir.
Harap autentikasi ulang.
[BAIK]
Saat pengguna mengklik "Oke", mereka akan dibawa ke halaman "Autentikasi Pengguna".
Saya menyarankan untuk menyingkirkan kata "pengguna", menggantikan "otentikasi" dengan "masuk",
dan meningkatkan batas waktu auto-logoff (karena mereka tidak dapat menghilangkannya).
■ Contoh 2: Sebuah perusahaan mengembangkan aplikasi e-commerce untuk jaringan
PC. Aplikasi ini memungkinkan pengguna membuat dan menyimpan template untuk transaksi umum
tions. Ini memberi pengguna opsi untuk menyimpan templat baik di PC mereka sendiri atau
di server jaringan. Template yang disimpan di server dapat diakses oleh orang lain
pengguna; template yang disimpan di PC bersifat pribadi. Masalahnya adalah soft-
ware mengacu pada dua opsi penyimpanan sebagai "database" dan "lokal". The devel-
opers menggunakan "database" untuk template di server karena mereka disimpan
dalam database. Pengembang menggunakan "lokal" untuk template milik pengguna
PC karena itulah yang dimaksud dengan "lokal" bagi mereka. Saya merekomendasikan agar mereka menggunakan
“Shared” atau “public” bukan “database” dan “private” bukan “local.”

Beberapa aplikasi perangkat lunak dan situs Web menyertakan nama perangkat GUI
kontrol dalam label atau instruksinya. Dua contoh berasal dari situs Web
Departemen Pengembangan Pekerjaan Negara Bagian California dan Northwest
Maskapai (Gambar 4.18).
Salah satu aplikasi bisnis menampilkan struktur data aplikasi menggunakan
kontrol pohon Windows. Masalahnya adalah aplikasi tersebut menyebutnya sebagai “pohon
kontrol." Tidak mengherankan, pengujian menunjukkan bahwa banyak pengguna tidak mengetahui apa itu
istilah berarti. Beberapa orang mungkin bertanya-tanya apa hubungan perangkat lunak dengan pohon.
Juga umum adalah pesan kesalahan yang berisi bit kode perangkat lunak yang sebenarnya.
Sebagian besar pengguna komputer telah melihat pesan kesalahan seperti yang ditampilkan oleh [Link]
(Gambar 4.19), yang mencampur kutipan kode dengan informasi yang dapat dipahami pengguna
stand: "Ada kesalahan dalam memproses permintaan Anda." Kutipan kode
mungkin berguna bagi pemrogram saat situs sedang di-debug, tetapi
seharusnya sudah dihapus sebelum situs ditayangkan.

Halaman 190

[Link] 137/315
26/2/2021 Tanpa judul

176 Bab 4 Kesalahan Tekstual

Gambar 4.18

SEBUAH

B
Mengekspos nama kontrol toolkit GUI. (A) [Link]. (B) [Link].

Gambar 4.19

[Link]: menampilkan kode dalam pesan kesalahan.

Terkadang pengguna dihadapkan pada istilah implementasi karena operasi

sistem menampilkan pesan kesalahan sendiri alih-alih meneruskannya ke aplikasi.
Untuk pembahasan yang lebih lengkap tentang situasi seperti itu, lihat Blooper 28 (halaman 184).

Variasi B: Mengubah kata-kata umum menjadi

jargon programmer

Pemrogram sering kali mendefinisikan ulang kata-kata umum untuk memiliki arti tertentu
perangkat lunak. Jika Anda mendefinisikan ulang kata-kata umum dan mengharapkan pengguna beradaptasi dengannya,
Anda memberikan beban tambahan pada pengguna dan melakukan kesalahan besar.
Dalam bahasa Inggris umum "dialog" berarti percakapan, tetapi dalam GUI-program-
mer jargon ini adalah singkatan dari "kotak dialog". Pemrogram dan desainer UI

Halaman 191

Teks yang berpusat pada pengembang

177

lupakan bahwa "dialog" memiliki arti yang sama dan, bahkan dalam jargon GUI, memang demikian
steno. Ketika perangkat lunak memperlihatkan arti jargon kepada pengguna, seperti dalam Adobe
InDesign (Gambar 4.20), ini adalah kesalahan besar.
Bagi programmer, kata “string” berarti data tekstual dalam perangkat lunak. Untuk
nonprogrammers, string adalah untuk mengikat berbagai hal menjadi satu. Contoh mengekspos file
arti jargon perangkat lunak bagi pengguna berasal dari perangkat lunak desktop Jam dan
Lacak dan situs web penerbit [Link] (Gambar 4.21). Penggunaan "string" ini
tidak boleh muncul di UI yang ditujukan untuk non-pemrogram.
Bagi kebanyakan penutur bahasa Inggris, argumen adalah perselisihan verbal. Untuk programmer,
argumen adalah masukan untuk fungsi perangkat lunak. Beberapa dari [Link]
pengguna mungkin ingin berdebat dengan desainer Pencarian situs
fungsi (Gambar 4.22).

Gambar 4.20

[Link] 138/315
26/2/2021 Tanpa judul

Adobe InDesign: menampilkan istilah jargon GUI "dialog".

Gambar 4.21

Pesan kesalahan mengekspos istilah perangkat lunak "string". (A) Aplikasi Jam dan Trek. (B)
[Link].

Halaman 192

178 Bab 4 Kesalahan Tekstual

Gambar 4.22

[Link]: menampilkan kata jargon perangkat lunak "argumen" dalam instruksi.

Dia melakukan apa yang dikatakannya

Seorang sekretaris menelepon hotline dukungan pelanggan Compuserve untuk mengatakan hal itu
meskipun dia melakukan apa yang diperintahkan perangkat lunak padanya, tampaknya itu tidak berhasil. Comp-
perangkat lunak userve telah menampilkan kotak dialog kesalahan yang berisi pesan:
Jenis tidak cocok
Sekretaris berkata bahwa ketika dia melihat pesan ini, dia mengetik "tidak cocok"
beberapa kali, tetapi tidak membantu. [Dari Interface Hall of Shame, http: // homepage.
[Link]/bradster/iarchitect/[Link]]

Kata-kata lain yang sering didefinisikan ulang adalah "sumber daya", "objek", dan "klien". Satu
Aplikasi web memiliki halaman login yang berjudul "Thin-Client Login". Beberapa pengguna
mungkin terkejut dan senang karena mereka menawarkan halaman login untuk Thin
klien, bukan alternatifnya.

Variasi C: Mengubah kata kerja menjadi kata benda

Jenis jargon lain adalah kata kerja yang digunakan sebagai kata benda. Ini tidak terbatas pada komputer.
ter perangkat lunak; itu terjadi di banyak bidang. Pialang saham menggunakan "beli" dan "jual" sebagai
kata benda saat membahas transaksi saham, pilot pesawat mengacu pada "lepas landas",
para nelayan berbicara tentang “tangkapan” hari itu, dan pengulas buku menjelaskan buku-buku mereka
seperti sebagai "bacaan yang berharga". Programer mengatakan "kompilasi gagal", "mulai
membangun, "" membandingkan, "" menyelesaikan pengeditan. " Ini bagus saat berkomunikasi dengan
programmer lain, tapi buruk saat berkomunikasi dengan nonprogrammer.
National Geographic Trip Planner menyertakan buku panduan dengan informasi
tentang rute dan tujuan. Buku panduan memiliki fungsi Find sehingga pengguna bisa
cari itu. Pengguna dapat mengatur preferensi tentang cara kerja Find. Perintah yang harus dilakukan
yaitu Temukan Preferensi (Gambar 4.23).

Gambar 4.23

[Link] 139/315
26/2/2021 Tanpa judul

National Geographic Trip Planner: Perintah Temukan Preferensi adalah frasa kata benda.

Halaman 193

Teks yang berpusat pada pengembang

179

Kata kerja untuk kata benda

Berikut adalah dua contoh lagi programmer yang mengubah kata kerja menjadi kata benda:
■ Dalam aplikasi penambangan data, satu fungsi disebut "Jelajahi Data". Itu
pemrogram memanggil menggunakan fungsi itu "melakukan Jelajahi". Sebuah pembantu
fungsi memprediksi waktu dan sumber daya yang diperlukan untuk "melakukan Penjelajahan". Dulu
bernama "Jelajahi Prediksi," frasa kata benda. Fungsi lain membandingkan dua
file data. Menggunakannya disebut "melakukan Perbandingan". Fungsi tambahan ditentukan
perbandingan yang dapat dijalankan berulang kali pada data yang berbeda. Dulunya disebut
"Bandingkan Definisi," frase kata benda lainnya.
■
Sebuah aplikasi menyediakan “wizard” (kotak dialog beberapa langkah) untuk membuat data
benda. Tombol yang memulai wizard ini diberi label “Buat Objek
Penyihir." Para pengembang bermaksud untuk label ini yang berarti "mulai (Buat
Object). ” Namun, pengguna membacanya sebagai frase kata kerja, "buat (Objek)
penyihir, ”dan bertanya-tanya apa itu penyihir“ Objek ”dan mengapa mereka melakukannya
ingin membuatnya.

Menghindari Blooper 26

Geek-speak harus pergi.

Saat mobil komersial pertama kali diperkenalkan dan selama sekitar 40 tahun
Setelah itu, mengoperasikan satu membutuhkan penguasaan banyak teknik otomotif
jargon: tersedak, RPM, tekanan oli, tegangan generator. Sekarang sebagian besar jargon itu
hilang. Aplikasi komputer mulai muncul pada akhir 1970-an. Tiga puluh tahun
telah berlalu sejak itu. Dalam 10 tahun lagi, apakah pengguna perangkat lunak Anda akan tetap memilikinya
waspada terhadap modem, file startup, driver perangkat, dan RAM? Semoga tidak.
Jangan menunggu 10 tahun lagi; mari kita raih tujuan itu sekarang.
Bagaimana cara pengembang menghindari Geek-speak? Dengan mengikuti langkah-langkah berikut.

Kenali penggunamu

Pelajari tentang pengguna Anda. Kunjungi mereka, amati mereka, wawancarai mereka, undang mereka
ke kelompok fokus. Minta mereka untuk mendeskripsikan bagaimana mereka bekerja, apa yang mereka sukai dan
tidak suka dengan peralatan mereka saat ini, dan apa masalah mereka yang paling serius.
Dapatkan ide mereka tentang bagaimana pekerjaan mereka dapat ditingkatkan. Kumpulkan daftar semua
konsep yang disebutkan pengguna yang dimaksud dalam deskripsi pekerjaan mereka.
Berikan perhatian khusus pada objek (kata benda), tindakan pada objek (kata kerja), dan
atribut objek (kata sifat) yang mereka sebutkan.

Kembangkan leksikon produk berdasarkan pengguna

kosa kata tugas

Gunakan informasi yang dikumpulkan dari pengguna yang dituju untuk mengembangkan konseptual
model untuk produk atau layanan perangkat lunak yang direncanakan (Prinsip Dasar 2, halaman 18).

Halaman 194

180 Bab 4 Kesalahan Tekstual

Model konseptual akan mencakup analisis objek / tindakan dan leksikon. Itu
leksikon harus mencantumkan semua konsep (objek, tindakan, atribut) yang perangkat lunak-
ware menghadapkan ke pengguna dan menunjukkan nama untuk setiap konsep. Jika memungkinkan,

[Link] 140/315
26/2/2021 Tanpa judul
gunakan nama standar industri.
Tujuannya agar antarmuka pengguna dan dokumentasi menggunakan kosakata
yang konsisten, baik secara internal dengan perangkat lunak maupun dengan standar industri
untuk platform, dan juga berpijak pada tugas dan kosakata
pengguna yang dituju (Prinsip Dasar 3, halaman 26). Untuk itu, kembangkan dan
memelihara leksikon produk dan menegakkan kepatuhan padanya. Semua teks ditampilkan
dalam perangkat lunak harus ditulis atau setidaknya ditinjau oleh penulis teknis,
dan semua Geek-speak harus disaring. Label dan pesan harus
dalam file pesan, dipisahkan dari kode program, untuk memfasilitasi tinjauan dan
terjemahan.
Beberapa orang berpendapat bahwa UI dan istilah yang digunakannya harus cocok
implementasi, sehingga UI tidak menyesatkan pengguna tentang bagaimana aplikasi
tion bekerja. Ya, tetapi cara yang tepat untuk melakukannya adalah dengan mendesain UI terlebih dahulu
dan kemudian menyesuaikan implementasinya — struktur, konsep, dan terminologi — dengan
bahwa.

Biarkan nama komponen GUI keluar dari GUI

Jangan menyertakan nama perangkat GUI dari kontrol di judul atau label untuk kontrol.
Gambar 4.24A menunjukkan contoh label culun: mereka menyertakan jargon GUI toolkit.
Gambar 4.24B menunjukkan label yang baik untuk pengaturan yang sama. Label yang bagus dihilangkan
kata-kata yang tidak perlu serta Geek-berbicara.

Gambar 4.24
Cetak Dialog

Nama String: Menu Font: Helvetica

SEBUAH
Mencetak

Nama: Font: Helvetica

(A) Label yang menyertakan jargon toolkit GUI. (B) Label yang ditingkatkan.

Halaman 195

Teks yang berpusat pada pengembang

181

Blooper 27: Memanggil pengguna ke "pengguna" di depan mereka

Terkait berbicara Geek adalah blooper memanggil pengguna Anda "pengguna" di UI.
“Pengguna” adalah apa yang kita — pengembang perangkat lunak dan Web — memanggil orang yang menggunakan
sistem kami. Ini adalah istilah yang bagus untuk digunakan saat kita berbicara dengan desainer lain
dan pengembang. Itu bagian dari jargon profesional kita — cara kita berkomunikasi
secara ringkas dengan rekan-rekan. Namun “pengguna” bukanlah apa yang digunakan orang-orang yang berbasis komputer
produk dan layanan menyebut dirinya sendiri.
Hanya dua industri yang menyebut pelanggan mereka "pengguna". Salah satu industri tersebut adalah milik kami:
perangkat lunak komputer. Tahukah Anda apa itu industri lainnya? 3
Aplikasi perangkat lunak, situs Web, dan perangkat elektronik harus dirancang
dari sudut pandang orang yang menggunakannya , bukan dari sudut pandang
perancang atau pengembang sistem. Orang-orang yang menggunakan produk berbasis komputer
Produk dan layanan melihat dirinya sebagai pelanggan, pengunjung situs, anggota, tamu,
dll — bukan "pengguna". Oleh karena itu, sistem interaktif yang memanggil pengguna "pengguna" ke mereka
wajah melakukan kesalahan besar.
National Geographic Trip Planner memungkinkan pengguna untuk membuat anotasi dan
lokasi terang di peta program yang menarik bagi mereka, tetapi menggunakan istilah tersebut
“Label Pengguna” dan “Sorotan Pengguna” (Gambar 4.25A). Microsoft Windows XP
Panel kontrol "Aksesibilitas" menunjukkan dua sudut pandang secara bersamaan: panggilan itu
lembar gaya yang ditentukan pengguna "Lembar gaya pengguna" dalam satu label dan "lembar gaya saya"
di tempat lain (Gambar 4.25B).
[Link] dan [Link] tidak hanya menyebut pengguna sebagai "pengguna"; mereka
membuat pengguna menyebut dirinya seperti itu (Gambar 4.26).

[Link] 141/315
26/2/2021 Tanpa judul
Gambar 4.25

SEBUAH

Microsoft menyebut pengguna "pengguna". (A) Perencana Perjalanan National Geographic. (B) Windows XP.

(Lanjutan)

3. Petunjuk: heroin, kokain, metamfetamin.

Halaman 196

Gambar 4.25
(Lanjutan)

Gambar 4.26

Membuat pengguna menyebut dirinya "pengguna". (A) [Link]. (B) [Link].

[Link] 142/315
26/2/2021 Tanpa judul

Halaman 197

Teks yang berpusat pada pengembang

183

Gambar 4.27 Pengguna Kembali

ID PAMFOnline

Kata sandi

Masuk

Lupa kata sandi atau ID Anda?

Pengguna Pertama Kali

Kode Akses Dapatkan Kode Akses

[Link]: tombol di halaman "Terima / Tolak Tautan" memaksa pengguna untuk menyebut dirinya "pengguna".

Kasus yang berpotensi ambigu terjadi di [Link] (Gambar 4.27), sebuah medis
klinik. Dalam konteks tersebut, "pengguna" dapat diartikan sebagai "pengguna narkoba".
Menyebut pengguna "pengguna" di depan mereka adalah kesalahan yang mudah dilakukan: "pengguna" adalah
jargon pengembang untuk orang yang menggunakan situs Web. Jika tim pengembangan
tidak secara eksplisit memikirkan hal ini dan memilih kata yang lebih sesuai, "pengguna"
adalah kata yang akan digunakan. Itulah mengapa kesalahan besar ini sangat umum.

Menghindari Blooper 27

Semudah membuat blooper ini, sama mudahnya dengan menghindarinya. Menggunakan non-
istilah yang berfokus pada pengembang seperti "pengunjung", "pelanggan", atau "anggota", bukan "pengguna"
hampir tidak ada biaya. Ini hanya membutuhkan kesadaran dan pikiran beberapa saat.
Tiga situs Web yang menunjukkan bukti kesadaran dan pemikiran seperti itu adalah Yale
[Link], [Link], dan Apple [Link] (Gambar 4.28).

Gambar 4.28

Tidak menyebut pengguna "pengguna". (A) Yale [Link]. (B) [Link]. (C) Apple [Link].

Halaman 198

184 Bab 4 Kesalahan Tekstual

Blooper 28: Pesan kesalahan yang tidak jelas

Kesalahan yang terkait dengan Speak Geek menampilkan pesan kesalahan yang mengumumkan
kondisi kesalahan umum yang tidak jelas alih-alih memberi pengguna informasi yang bermanfaat dan berorientasi tugas
informasi tentang apa yang terjadi dan apa yang harus dilakukan. Ini terjadi karena tiga alasan.

Variasi A: Pesan yang ditampilkan oleh kode level rendah

Terkadang fungsi layanan tingkat rendah mendeteksi kesalahan dan menampilkan pesan kesalahan
diri. Fungsi tingkat tugas yang dijalankan pengguna secara eksplisit — misalnya, Simpan — bisa

[Link] 143/315
26/2/2021 Tanpa judul
mengungkapkan kesalahan dalam istilah terkait tugas, tetapi fungsi layanan tingkat rendah — misalnya, file.
Open () - tidak bisa.
Di browser Web Safari Apple, misalkan pengguna mencoba mengunjungi Web toko bunga
halaman. Jika laman memiliki kode JavaScript bermasalah yang mencoba menetapkan nilai null ke
variabel, interpreter JavaScript Safari menampilkan kesalahan: “TypeError — Null
nilai ”(Gambar 4.29).
Reaksi pengguna mungkin akan seperti ini: “Hah? Saya hanya ingin
kirim beberapa bunga untuk ibuku. Apa ini tentang JavaScript, kesalahan ketik, dan
nilai nol? " Jika pengguna lebih paham komputer, dia mungkin berkata: “Kamu bodoh
browser — Saya tidak menulis kode JavaScript yang salah. Tunjukkan kesalahan ke situs
pengembang, bukan untuk penggunanya! ”

Pesan kesalahan ditampilkan oleh kode tingkat rendah

Seorang programmer terkemuka telah beremigrasi ke Amerika Serikat. Bahasa Inggrisnya yang buruk
bukan masalah karena dia menulis kode driver perangkat tingkat rendah yang tidak memiliki
UI. Dia diminta untuk menulis driver untuk tampilan baru. Tidak ada yang memeriksa pekerjaannya
karena pengemudi seharusnya tidak terlihat oleh pengguna. Dan itu… hampir. Sudah
bug yang terkadang menyebabkannya mencapai batas memori dan menampilkan pesan ini:
Level sarang terlalu rendah.
Pesan kesalahan ini dan kode yang menampilkannya telah dibakar
ke ROM dan dikirimkan dengan ribuan konsol di seluruh dunia. Masalah utama
dengan pesan kesalahan bukanlah kesalahan ejaan kata "dalam", tetapi hanya itu
ditampilkan oleh firmware layar. Pengguna layar tidak akan tahu
tentang apa pesan itu atau apa yang harus dilakukan tentang itu.

Gambar 4.29

Browser Apple Safari: pesan kesalahan dari juru bahasa JavaScript.

Halaman 199

Teks yang berpusat pada pengembang

185

Variasi Blooper 27 ini seringkali sulit untuk diperbaiki. Kode tingkat rendah
yang mendeteksi kesalahan dan menampilkan pesan kesalahan yang tidak membantu mungkin tidak ada
aplikasi itu sendiri, tetapi dalam sistem operasi tempat aplikasi tersebut berada
berlari. Jika aplikasi Anda memanggil fungsi utilitas sistem operasi dan
fungsi terkadang menampilkan pesan kesalahan yang buruk, Anda mungkin tidak akan bisa
untuk memperbaiki pesan karena bukan dari kode Anda. Meskipun demikian, pengguna Anda akan melakukannya
lihat pesan tersebut berasal dari aplikasi Anda. Jika pesannya serius
menyesatkan, Anda tidak punya pilihan selain mengubah kode jadi tidak
menggunakan fungsi utilitas sistem operasi.

Variasi B: Alasan kesalahan tidak diberikan

kode tingkat yang lebih tinggi

Terkadang aplikasi menampilkan pesan kesalahan yang tidak jelas karena komunikasi yang buruk
komunikasi antara fungsi layanan tingkat rendah dan fungsi tingkat tugas
pengguna dieksekusi. Misalnya, saat pengguna mencoba membuka presentasi PowerPoint
tetapi PowerPoint tidak dapat membukanya, pesan kesalahan muncul mencantumkan tiga kemungkinan
alasan kegagalan (Gambar 4.30). Layanan ini berfungsi untuk panggilan PowerPoint
membuka dan memuat presentasi tampaknya tidak memberikan cukup detail pada PowerPoint
tentang mengapa mereka gagal mengizinkannya untuk mengidentifikasi penyebab pasti dari kegagalan tersebut.
Pengguna dibiarkan tidak tahu harus berbuat apa, karena solusi untuk ketiganya
kemungkinan penyebabnya sangat berbeda.
Salah satu aplikasi menampilkan pesan kesalahan ini saat pengguna mencoba memuat file
file data yang tidak ada:
Terjadi kesalahan saat mengurai datafile. Data tidak diurai.

Pesan itu benar — tidak ada data yang diurai — tetapi menyesatkan. Masalah nyata
lem adalah bahwa file data tidak ditemukan. Setelah mencoba memuat file, kode tersebut melakukannya
tidak memeriksa apakah operasi beban berhasil; itu baru saja melewati buffer data kosong
ke prosedur parsing, yang melaporkan bahwa itu tidak dapat mengurai data.

Variasi C: Komponen pesan umum

Penyebab umum lainnya dari pesan kesalahan yang tidak jelas adalah pesan kesalahan umum

[Link] 144/315
26/2/2021 Tanpa judul
komponen. Untuk menghemat upaya pengembangan, pengembang terkadang membuat generik
pesan untuk menutupi seluruh kategori kesalahan dan menggunakannya bahkan ketika file
perangkat lunak dapat memberikan umpan balik yang lebih spesifik kepada pengguna.

Gambar 4.30

Microsoft PowerPoint: pesan kesalahan mencantumkan tiga kemungkinan masalah.

Halaman 200

186 Bab 4 Kesalahan Tekstual

Gambar 4.31

[Link]: pesan kesalahan yang tidak jelas. Spesifik di URL, di mana hanya sedikit pengguna yang akan melihatnya.

[Link] menampilkan pesan kesalahan yang tidak jelas saat pengguna memperbarui kon-
informasi bijaksana tetapi menghilangkan nomor telepon (Gambar 4.31). Ia sebenarnya "tahu" itu
masalahnya adalah nomor telepon yang hilang; Anda dapat melihatnya di URL — tetapi normal
pengguna konsumen tidak akan melihat ke sana. Namun pesan kesalahan yang ditampilkannya bersifat umum.
Satu aplikasi investasi saham memungkinkan investor membeli atau menjual saham.
Pengguna sering mendapatkan pesan kesalahan ini saat mereka memesan:
Ukuran pesanan tidak banyak dari unit perdagangan.

Jumlah saham yang dibeli atau dijual harus kelipatan dari "unit perdagangan".
Unit perdagangan berbeda untuk setiap saham, tetapi pesan kesalahan tidak menyebutkan apa
unit perdagangannya. Unit perdagangan juga tidak ditampilkan di mana pun dalam pemesanan
layar. Pengguna hanya perlu mengetahui, atau menebak, apa unit perdagangan untuk saham tersebut
mereka ingin membeli atau menjual. Pengguna tidak hanya membuang waktu mencoba mencari perdagangan
unit untuk sebuah saham, mereka terkadang memulai transaksi yang tidak mereka inginkan.

Contoh pesan kesalahan umum

Berikut ini adalah contoh software yang ditampilkan generik, tidak informatif
pesan kesalahan.
■ Contoh 1: Pengguna mencoba memberi objek data nama yang tidak mengandung karakter
diperbolehkan dalam nama:
Nama mengandung karakter yang tidak valid .
Hebat. Berdoa, katakan, karakter mana yang mungkin? Perangkat lunak tahu,
tapi tidak mau bilang.
■ Contoh 2: Pesan kesalahan ditampilkan ketika pengguna mencoba untuk mengimpor file data:
File hilang atau Anda tidak memiliki akses.
Pesan ini tidak jelas: tidak disebutkan yang mana dari dua masalah yang sangat berbeda
telah terjadi. Pesan tersebut tidak menyebutkan nama file yang dibicarakannya.

Halaman 201

[Link] 145/315
26/2/2021 Tanpa judul

Teks yang berpusat pada pengembang

187

Gambar 4.32

Windows Media Player (untuk Mac): pesan kesalahan tidak jelas.

Dan pemenangnya adalah …

Induk dari semua pesan kesalahan umum dan tidak informatif — pesan yang,
jika ada hadiah untuk ketidakjelasan, akan menjadi pemenangnya — pasti kesalahan
pesan yang ditampilkan oleh Windows Media Player untuk Mac (Gambar 4.32). Apa
apa yang harus dilakukan pengguna dengan ini?

Menghindari Blooper 28

Ekspresikan kesalahan dalam hal tugas

Pesan kesalahan yang baik menjelaskan masalah dalam istilah yang terkait dengan tugas
pengguna coba lakukan. Jika pengguna baru saja memberikan perintah untuk menempelkan gambar
ke dalam dokumen dan perangkat lunak mengalami kesalahan, pesannya harus seperti itu
diekspresikan dalam hal menempelkan gambar, bukan dalam fungsi sistem operasi.
tions, tipe data implementasi, kode pengecualian program, atau aplikasi yang tidak relevan
konsep kation.

Jangan hanya mengidentifikasi masalahnya; menyarankan solusi

Pesan kesalahan yang baik juga memberikan informasi yang cukup sehingga pengguna dapat melihat caranya
untuk memperbaiki kesalahan tersebut. Itu berarti memberikan detail yang cukup sehingga pengguna dapat menentukan
apa yang dia lakukan untuk menyebabkan masalah atau, jika masalahnya bukan kesalahan pengguna,
apa yang menyebabkannya dan mengapa. Seorang teman programmer saya berkata seperti ini:

“Pesan kesalahan harus fokus pada solusi. Geeks senang mendeskripsikan masalahnya. "

Halaman 202

188 Bab 4 Kesalahan Tekstual

Untuk melawan kecenderungan itu, pesan kesalahan harus selalu berisi hal-hal berikut:

Simbol kesalahan; Solusi masalah

Contoh perangkat lunak yang mengikuti pedoman ini adalah [Link], situs Web
Southwest Airlines (Gambar 4.33).
Tabel 4.1 menunjukkan perbaikan yang disarankan untuk pesan kesalahan buruk yang dibahas
atas.

Gambar 4.33

[Link] 146/315
26/2/2021 Tanpa judul

[Link] (Southwest Airlines): pesan kesalahan yang sangat baik.

Tabel 4.1 Pesan kesalahan yang buruk dan lebih baik

Pesan kesalahan yang buruk Pesan kesalahan yang ditingkatkan

[Link] () gagal. [ Pengguna mencoba Pesan tidak dapat disimpan

untuk menyimpan pesan email, tapi ke dalam folder Terkirim. Silahkan
menentukan folder Terkirim sebagai coba Menyimpan ke folder lain.
tujuan karena kesalahan .]
Kesalahan Jenis JavaScript: Peringatan: Halaman berisi pengkodean
Nilai nol kesalahan. Konten mungkin tidak ditampilkan
sebagaimana dimaksud [ atau tidak ada pesan ].
Level sarang terlalu rendah. [ Tidak ada pesan. Konsol baru saja dimulai ulang
jika perlu .]
Nama berisi tidak valid Nama < Object-type > tidak boleh
karakter. berisi '-', '/', '@', '#',
atau karakter '&'.
File hilang atau Anda tidak [ Pesan terpisah untuk keduanya
memiliki akses. jenis kesalahan: ] File < nama file >
tidak ditemukan. Anda tidak punya
akses ke file < nama file >.
Ukuran pesanan tidak banyak Maaf: < stockname > stock harus
dari unit perdagangan. diperdagangkan dalam kelipatan
Saham < unit perdagangan >.

Halaman 203

Teks menyesatkan 189

Teruskan kesalahan ke kode yang dapat menerjemahkannya untuk pengguna

Low-tingkat layanan rutin dan platform perangkat lunak aplikasi harus tidak pernah dis-
putar pesan kesalahan secara langsung. Mereka harus selalu memberikan kesalahan ke aplikasi
sehingga dapat menanganinya dengan cara yang tepat.
Ketika aplikasi menerima pemberitahuan kesalahan dari prosedur tingkat yang lebih rendah-
Tentu, itu harus meneruskan kesalahan ke tumpukan panggilan ke kode yang dapat menangani kesalahan
dengan cara yang relevan dengan tugas. Kode itu harus:

■
terjemahkan kesalahan menjadi istilah yang bermakna bagi pengguna dan tampilkan
terjemahan dengan saran tentang cara memperbaiki masalah atau
■ asumsikan bahwa penyebab kesalahan hanya sementara dan coba operasi lagi.

Rancang pesan dan komponen pembawa pesan

untuk menerima detail pada waktu proses

Pesan kesalahan dan komponen kotak dialog kesalahan yang mencakup banyak situasi
harus dirancang untuk memungkinkan detail — nama objek, batasan, bidang data
nama, dll — untuk dimasukkan ke dalamnya. Ini akan, misalnya, memungkinkan terjadinya kesalahan
pesan untuk mengatakan file mana yang tidak bisa dibaca, tunjukkan karakter mana yang tidak
diperbolehkan, atau menunjukkan data yang diperlukan tidak diberikan.

Jenis pesan yang berbeda memiliki audiens yang berbeda pula

Terakhir, ketahuilah bahwa pesan kesalahan yang ditampilkan oleh perangkat lunak memiliki tiga kemungkinan.
fungsi sible, masing-masing memiliki audiens yang berbeda:

■
Menunjukkan kesalahan pengguna: untuk pengguna akhir
■ Aktivitas pencatatan: untuk administrator sistem di situs pengguna
■
Memfasilitasi debugging dan tracing: untuk developer

Pada saat perangkat lunak siap untuk dikirimkan, pengembang harus memastikannya masing-masing
jenis pesan hanya dilihat oleh audiens yang dituju.

Teks menyesatkan

Tiga kesalahan besar tekstual terakhir berkaitan dengan pesan kesalahan dan label yang menyesatkan
pengguna.

Blooper 29: Pesan yang salah

[Link] 147/315
26/2/2021 Tanpa judul

Tidak ada yang membingungkan dan membuat marah pengguna perangkat lunak lebih dari instruksi dan kesalahan
pesan yang salah. Mereka membuang waktu dan tenaga dengan mengarahkan pengguna ke bawah
jalan yang salah, mungkin mengarah pada kesalahan yang merugikan.

Halaman 204

190 Bab 4 Kesalahan Tekstual Teks yang berpusat pada pengembang

190

Pelanggan United Airline, saat meninjau akun jarak tempuh frequent-flier mereka
di [Link], dapat meminta situs untuk mencantumkan aktivitas akun yang terjadi antara
tanggal tertentu. Jika pengguna menentukan tanggal di masa depan, situs tersebut bisa dengan lembut
katakan itu, atau abaikan saja kesalahannya dan gunakan hari ini sebagai batas tanggal atas. Sebagai gantinya,
[Link] dengan kasar memberi tahu pengguna bahwa mereka telah membuat "Entri Tanggal Tidak Valid"
dan memberi tahu mereka untuk memeriksa apakah mereka memasukkan tanggal yang tidak ada, seperti 31 Juni
(Gambar 4.34). Perbaikan yang disarankan tidak terkait dengan kesalahan pengguna yang sebenarnya.
Lebih buruk lagi adalah pesan kesalahan palsu ketika pengguna bahkan tidak membuat kesalahan. Jika
pelanggan email web Earthlink mencoba masuk pada saat perusahaan
server nama domain sedang down, email web Earthlink menampilkan pesan kesalahan
memberi tahu pengguna bahwa nama domain yang ditentukan "tidak valid" (Gambar 4.35). Itu
nama domain tidak valid; server tidak dapat mengotentikasi domain apa pun
nama saat ini. Pesan ini akan menyebabkan pemborosan pelanggan Earthlink
waktu memeriksa dan mengetik ulang alamat email mereka dengan sia-sia.

Gambar 4.34

SEBUAH

[Link]: pesan kesalahan salah. Pengguna memasukkan tanggal yang akan datang, tetapi pesan menyesatkan.

Halaman 205

Teks menyesatkan 191

Gambar 4.35

[Link] 148/315
26/2/2021 Tanpa judul

[Link]: pesan kesalahan salah. Nama domain valid, tetapi server nama sedang down.

Lebih buruk lagi adalah pesan kesalahan yang membuat takut pengguna dengan mengumumkannya
sesuatu yang mengerikan ketika tidak ada yang salah. Microsoft Windows untuk Pocket
PC terkadang secara tidak dapat dijelaskan menampilkan pesan kesalahan sistem yang benar-benar menakutkan
sage (Gambar 4.36). Kotak dialog kesalahan melakukan kesalahan besar lainnya juga,
menjebak pengguna dengan menampilkan opsi yang tidak jelas (Blooper 50, halaman 281), tapi
Kesalahan utama pesan ini adalah kesalahannya. Terlepas dari apakah pengguna
mengklik Ya atau Tidak, Pocket PC terus beroperasi secara normal dan tidak ada
terhapus.
Akhirnya, kami memiliki teks yang salah karena kecerobohan. Masalah ini bisa
sering terlihat di situs Web yang mencantumkan harga, peristiwa, atau katalog produk
tidak selalu diperbarui atau dengan cara lain tidak sesuai dengan kenyataan.
Teks yang salah juga dapat ditemukan di perangkat lunak desktop. Berbasis web
Program email TrueDesk memungkinkan penggunanya membuat daftar "Pengirim Aman" -
alamat email yang dipercayai — dan “Pengirim yang Diblokir” —e-mail
alamat dari mana e-mail diblokir. Namun, "Pengirim yang Diblokir"
deskripsi mengatakan bahwa email yang diblokir akan pergi tepat ke tempat email tepercaya pergi:
ke dalam Kotak Masuk pengguna (Gambar 4.37). Ini pasti salah. Siapapun yang menciptakan ini
halaman tampaknya menyalin teks dari deskripsi "Pengirim Aman" ke
"Pengirim yang Diblokir" dan gagal mengeditnya. Tetapi pengguna mungkin tidak mengetahui hal ini
segera.

Halaman 206

192 Bab 4 Kesalahan Tekstual

Gambar 4.36

Microsoft Pocket PC Windows: pesan kesalahan palsu. Tidak ada yang salah.

Gambar 4.37

[Link] 149/315
26/2/2021 Tanpa judul

TrueDesk: Tab Anti-Spam memiliki label yang salah.

Menghindari Blooper 29

Sangat buruk bagi perangkat lunak untuk berbohong kepada penggunanya. Itu bisa membuang waktu berharga pengguna
dan usaha serta menyebabkan mereka membuat kesalahan yang tidak dapat diperbaiki.
Pesan kesalahan yang memarahi pengguna karena kesalahan yang salah atau kesalahan yang tidak mereka lakukan
komit, dan instruksi yang salah, adalah kekurangan perangkat lunak — bug. Mereka seharusnya
diperiksa selama pengujian jaminan kualitas perangkat lunak dan dilaporkan serta dilacak
dengan mekanisme manajemen bug. Mereka harus memiliki prioritas tinggi untuk perbaikan
ini, karena dampaknya pada pengguna tinggi: mereka mengalihkan pengguna dari pencapaiannya
tujuan, terkadang menyebabkan kehilangan data (atau, dalam kasus sistem misi kritis,
jenis kerugian lainnya), dan mereka benar-benar menurunkan kepuasan pelanggan.

Halaman 207

Teks menyesatkan 193

Blooper 30: Teks masuk akal dalam isolasi tetapi masuk akal
menyesatkan di GUI

Jakob Nielsen telah menunjukkan (di [Link]) bahwa perangkat lunak dan pengembang Web
sering kali menulis label, judul, deskripsi, dan instruksi tanpa mempertimbangkan
bagaimana pengguna mungkin menafsirkan teks dalam konteks semua informasi lainnya
sistem ditampilkan. Ini sering kali menghasilkan teks yang mungkin masuk akal jika dipisahkan
tetapi tidak begitu jelas di GUI.
Sebagian besar pembeli Web terhalang oleh situs Web e-niaga yang menemukan
mainkan deskripsi serupa untuk item yang berbeda. Bayangkan Web vendor printer
situs di mana empat printer berbeda digambarkan sebagai "sempurna untuk printer kecil Anda
bisnis ”atau katalog online filter plugin PhotoShop yang semuanya menjanjikan
untuk "membantu Anda membuat gambar yang terlihat profesional". Manajer pemasaran
yang bertanggung jawab atas setiap produk tentu ingin membuatnya terdengar semenarik mungkin
mungkin, tetapi hal itu dapat menyulitkan pelanggan untuk memilih.
Sama seperti kesamaan yang tidak direncanakan antara label item dapat menimbulkan kebingungan, begitu pula halnya
perbedaan yang tidak diinginkan . Situs web dukungan pelanggan satu perusahaan menyertakan a
halaman tambalan perangkat lunak yang dapat diunduh dan dipasang pelanggan untuk memperbaikinya
bug yang diketahui dalam perangkat lunak perusahaan. Sebuah bagian dari halaman "Patch" tinggi-
tambalan menyala yang sangat disarankan oleh perusahaan kepada pelanggan
Install. Bagian itu diberi label:
Patch yang Direkomendasikan

Tambalan ini telah diuji dan akan menjaga workstation Perusahaan X Anda tetap berjalan
lancar.

Ini mungkin menunjukkan kepada beberapa pelanggan bahwa tambalan lainnya belum ada
diuji dan tidak direkomendasikan. Orang yang menulis label bagian memiliki
hanya mempertimbangkan bagaimana label tersebut sesuai dengan bagiannya sendiri, bukan apa yang tersirat tentang
sisa halaman tempat iklan tersebut muncul.

Menghindari Blooper 30

Saat menulis teks yang mendeskripsikan suatu item, pertimbangkan bagaimana orang yang tidak terlalu akrab
akrab dengan item akan menafsirkannya. Juga, jangan hanya mempertimbangkan setiap bagian
teks dalam isolasi. Lihatlah dalam semua konteks di mana itu akan muncul, dan pastikan
ia menyampaikan makna yang dimaksudkan di setiap tempat tersebut. Jika ragu, ujilah
pengguna.

Blooper 31: Penyalahgunaan (atau nonuse) dari “…” pada label perintah

Pada awal 1980-an, para perancang komputer Lisa Apple (pendahulu dari
Macintosh) menemukan cara untuk membedakan perintah yang langsung dieksekusi
dari orang yang pertama kali meminta informasi lebih lanjut. Perintah yang membutuhkan lebih banyak

[Link] 150/315
26/2/2021 Tanpa judul

Halaman 208

194 Bab 4 Kesalahan Tekstual

informasi memiliki "..." (elipsis) di akhir label perintah, misalnya,

Perintah “Save As…” yang dijalankan segera tidak diakhiri dengan “…”. Ini con-
vention adalah untuk label perintah, apakah itu muncul di menu atau di tombol.

Elipsis menjadi standar

Sangat membantu bagi pengguna untuk mengetahui sebelumnya apakah sebuah perintah dijalankan
segera atau meminta informasi lebih lanjut. Lebih aman mengklik yang tidak dikenal
perintah jika pengguna tahu bahwa mereka hanya memunculkan kotak dialog.
Seiring waktu, konvensi tersebut menyebar ke luar Macintosh ke komputer lain
platform, seperti Microsoft Windows dan berbagai desktop berbasis Unix
sistem operasi. Saat ini, sangat luas bahwa perangkat lunak tidak mengikuti ini
risiko konvensi menyesatkan pengguna.

Beberapa pengembang tidak tahu standarnya

Sayangnya, pelanggaran terhadap konvensi ini menjadi lebih umum. Beberapa berkembang-
opers tidak menyadarinya. Yang lain tahu ada konvensi tetapi salah paham-
tahan.

Variasi A: Menghilangkan “…”

Kesalahan yang paling umum adalah menghilangkan “…” pada perintah yang membutuhkannya: tidak
perintah memiliki "...". Pengguna menebak atau belajar dari pengalaman yang
mands membutuhkan lebih banyak masukan dan mana yang tidak. Microsoft Outlook "Ubah
Kata sandi ”menampilkan kotak dialog untuk memeriksa sandi pengguna saat ini-
kata dan dapatkan yang baru (Gambar 4.38). Label tombol harus diakhiri dengan
“…”, Tapi tidak.

Gambar 4.38

SEBUAH B

Microsoft Outlook: kehilangan “…” pada tombol “Change Password”.

Halaman 209

Teks menyesatkan 195

Gambar 4.39

[Link] 151/315
26/2/2021 Tanpa judul

SEBUAH B

Adobe Reader: Tentang Adobe Reader 7.0… perintah salah menyertakan “…”.

Variasi B: Penggunaan “…” secara berlebihan

Kesalahan paling umum berikutnya adalah menambahkan elipsis ke label perintah yang seharusnya
tidak memilikinya. Desainer yang melakukan variasi blooper ini memiliki generalisasi yang berlebihan
konvensi. Mereka mengira "..." adalah untuk setiap perintah yang membuka jendela baru. Jika sebuah
Show Graph… perintah hanya menampilkan grafik dan tidak membutuhkan informasi lebih lanjut
sebelum itu terjadi, label perintah tidak boleh diakhiri dengan “…”.
Di menu Bantuan Adobe Reader's, menu perintah Tentang Adobe Reader 7.0 ...
memainkan layar pembuka yang menampilkan versi program dan informasi lainnya (Gambar
4.39). Tidak perlu masukan tambahan dari pengguna. Kata "..." menyesatkan.

Menghindari Blooper 31

Elipsis menunjukkan bahwa perintah menampilkan kotak dialog sebelum mengeksekusi.

Ini menunjukkan bahwa akan ada peluang untuk membatalkan.

Bukan untuk perintah apa pun yang membuka jendela

"..." bukan untuk perintah yang hanya membuka jendela. Misalnya, Show
Jaringan mungkin membuka jendela untuk menampilkan status jaringan komputer.
Perintah seperti itu tidak boleh memiliki "..." di akhir labelnya.
Mozilla Firefox menggunakan "..." dengan benar di menu Bantuan dan di tempat lain. Itu
Help and Release Notes perintah membuka jendela yang menampilkan informasi

Halaman 210

196 Bab 4 Kesalahan Tekstual

Gambar 4.40

Mozilla Firefox: penggunaan yang benar — dan tidak digunakan — dari “…”.

dan jadi jangan diakhiri dengan “…”. Laporkan Situs Web Rusak… dan Periksa
Updates… perintah membuka kotak dialog yang meminta input pengguna yang diperlukan
selesaikan perintah tersebut dan akhiri dengan "..." (Gambar 4.40).

Standar di semua platform

Semua panduan gaya platform GUI utama menyatakan aturan yang sama:

■
Panduan Tampilan dan Nuansa Java [Sun Microsystems, 2001]
■
Panduan Pengalaman Pengguna Windows Vista [Microsoft Corp., 2006]
■
Panduan Antarmuka Manusia Apple [Apple Computer, 2006]

Bagaimana dengan label tombol grafis?

Banyak tombol diberi label secara grafis daripada secara tekstual. Tanda elipsis
tidak berfungsi untuk label grafis. Solusinya adalah dengan memasukkan elipsis pada
teks tooltip tombol, yang muncul saat penunjuk layar ditahan di atas
tombol.

[Link] 152/315
26/2/2021 Tanpa judul

Halaman 211

Desain Grafis
dan Tata Letak
Bloopers
pengantar

Tata letak dan penempatan jendela yang buruk

Tipografi yang merepotkan

197

Halaman 212

[Link] 153/315
26/2/2021 Tanpa judul

198 Bab 5 Desain Grafis dan Tata Letak Bloopers

pengantar

Setelah Anda memiliki kontrol GUI yang sesuai untuk perangkat lunak Anda dan Anda
memberi label mereka dengan baik dan menulis instruksi yang diperlukan, Anda harus memutuskan
pada detail presentasi: tata letak, warna, dan font teks. Prinsip dasar
yang harus memandu desain grafis dan keputusan tata letak di GUI tercakup dalam
Bab 1 (Prinsip Dasar 7, halaman 41). Biasanya tidak mengikuti prinsip-prinsip itu
menyebabkan kesalahan umum tertentu: blooper "desain grafis dan tata letak".
Desain grafis dan kesalahan tata letak pasti mengurangi persepsi perangkat lunak
kualitas. Hanya perlu sedikit untuk membuat produk terlihat amatir dan tidak dapat dipercaya.
Desain grafis dan tata letak yang buruk juga dapat menurunkan kemampuan dan motivasi pengguna
untuk menyerap informasi atau konten apa pun yang ditawarkan perangkat lunak.
Pengembang perangkat lunak sebagian besar berasal dari teknik dan tidak melihat seberapa miripnya
industri mereka telah menjadi salah satu yang menghasilkan majalah, surat kabar,
buku, acara TV, dan film. Sebagian besar pengembang perangkat lunak belum mempelajarinya
mengembangkan dan mengikuti standar ketat untuk tata letak dan desain grafis dan membayar sesuai
perhatian terhadap detail seperti yang dilakukan penerbit tradisional dan studio media. Sebagai
Akibatnya, desain grafis dan tata letak blooper sering mendapatkan pesan “Siapa peduli? Sepertinya oke
untuk saya!" reaksi dari pengembang.
Untungnya, blooper desain dan tata letak grafis mudah dikenali begitu Anda
tahu apa yang harus dicari dan cukup mudah untuk dihindari atau diperbaiki. Menunjukkan caranya
adalah tujuan dari bab ini. Karena buku ini tidak dicetak berwarna, dua
kesalahan besar tentang penggunaan warna yang buruk tidak dapat disertakan. Mereka ada di Web
lampiran di situs Web buku: [Link].

Tata letak dan penempatan jendela yang buruk

Sebagian besar desain grafis dan layout blooper yang umum berkaitan dengan tata letak
informasi dan kontrol pada jendela, formulir, dan halaman web dan tempat-
jendela di layar.

Blooper 32: Informasi yang mudah terlewatkan

Pengembang perangkat lunak sering berasumsi bahwa jika informasi ditampilkan, pengguna akan melakukannya
lihat itu. Tidak begitu!

Orang menyaring informasi

Orang terus-menerus kehilangan informasi. Sistem persepsi kami memfilter lebih banyak
daripada yang diizinkan. Itu bukan bug; itu sebuah fitur! Jika kami tidak bekerja seperti ini, kami
tidak dapat berfungsi di dunia yang berkembang pesat, berdengung, dan berubah dengan cepat ini. Kami akan
kelebihan beban.

Halaman 213

Tata letak dan penempatan jendela yang buruk 199

Jutaan tahun evolusi merancang kita untuk mengabaikan sebagian besar dari apa yang sedang terjadi
di sekitar kita dan untuk memusatkan perhatian kita pada apa yang penting. Saat pra-
nenek moyang bersejarah berburu di padang rumput Afrika Timur, yang penting
adalah apa yang bergerak dan apa yang tampak berbeda dari latar belakang berumput.
Mungkin hewan yang mereka anggap sebagai makanan… atau hewan yang menganggapnya sebagai
makanan.
Di zaman modern, ketika pilot memindai tampilan kokpit, yang penting
adalah apa yang tidak normal, apa yang berubah, dan bagaimana hal itu berubah. Ketika sebuah bisnis-
ness eksekutif menyiapkan presentasi, yang penting presentasi
konten dan apa pun yang sepertinya akan membantunya mempersiapkan presentasinya
tepat waktu. Segala sesuatu yang lain tidak relevan dan diabaikan.

Kelemahan desain yang umum: tidak memfokuskan perhatian pengguna

Desain yang baik memusatkan perhatian pengguna pada apa yang penting dengan mengambil keuntungan dari
tage tentang bagaimana persepsi manusia bekerja. Sayangnya, banyak aplikasinya

[Link] 154/315
26/2/2021 Tanpa judul
dan situs Web mencapai hal sebaliknya: detail yang tidak
jauhpenting menarik
dari yang perhatian pengguna
penting
informasi.
Sepanjang sejarah, de-
tanda telah menyebabkan orang ketinggalan
informasi penting dan buat
kesalahan — terkadang yang serius
[Norman, 1983]. Ini termasuk
posisi pengaman pada senjata,
posisi perpindahan gigi di kendaraan
cles, lampu peringatan tentang nuklir
panel kontrol pembangkit listrik, teletype
hasil cetak dari pemantauan jaringan
sistem, pengukur bahan bakar dan lampu oli
di dalam kendaraan dan pesawat terbang, dan stasiun
garis tus dalam perangkat lunak.
Jenis informasi yang sering
yang terlewat adalah:

■
Indikator status: misalnya,
apakah kekuatan pemutar DVD
dan disk di dalamnya, halaman
sedang ditampilkan di Web
browser, atau jumlah file
fungsi transfer file tersisa
salinan
BIZARRO (BARU) © DAN PIRARO. FITUR RAJA SYNDICATE.

Halaman 214

200 Bab 5 Bloopers Desain Grafis dan Tata Letak

■
Indikator mode: misalnya, mode Caps Lock di editor dokumen
(Blooper 48, halaman 269)
■
Anjuran untuk masukan: misalnya,

Kata sandi: atau Hapus Semua? Membatalkan baik

■
Hasil: misalnya,

50
30 70
%
10 90

Perkiraan Pembayaran: $ 1530.34 atau Tekanan Kabin:

■
Pesan kesalahan dan status: Misalnya,
Tidak dapat mengimpor '[Link]': format file tidak dikenal

■
Kontrol: Misalnya, tombol, penggeser, menu, dan bidang data

Pengguna sering melewatkan barang-barang penting ini karena beberapa kesamaan yang berbeda
kesalahan desain.

Variasi A: Terlalu kecil atau polos

Beberapa perangkat lunak menampilkan informasi penting dalam ukuran yang mungkin kecil
juga tidak berada di sana. Jika sebuah indikator adalah gambar 16 × 16-piksel pada 1200 × 900-
tampilan piksel, akan mudah terlewat kecuali jika sangat terang atau bergerak. Ini adalah
terutama benar jika indikator dikelilingi oleh data lain atau berada di tepi
bidang visi pengguna.
Beberapa aplikasi perangkat lunak dan situs Web menampilkan informasi penting dalam
font teks (kecil) yang sama seperti yang lainnya. Dalam banyak aplikasi kantor, data
bidang masukan dan bidang hasil terlihat hampir sama: bidang hasil tidak memiliki
pemformatan atau penyorotan khusus untuk menarik perhatian pengguna.

Variasi B: Bukan di mana pengguna melihat

Indikator status dan informasi penting lainnya sering muncul di luar

lokasi jalan, di mana banyak pengguna tidak akan menyadarinya. Ketajaman visual manusia
terbaik di area kecil di tengah bidang penglihatan, yang disebut "fovea". Kami

[Link] 155/315
26/2/2021 Tanpa judul
kemampuan membedakan warna juga terbatas terutama pada fovea. Di luar
fovea, kami memiliki ketajaman visual dan penglihatan warna yang buruk. Benda diam itu
tidak tepat di tempat yang kita cari mudah terlewat atau salah dikenali.
Misalnya, pertimbangkan halaman "Login" dari aplikasi Web sebuah perusahaan
dikembangkan beberapa tahun yang lalu. Jika pengguna mengetik ID atau PIN yang tidak valid, halaman

Halaman 215

Tata letak dan penempatan jendela yang buruk 201

Gambar 5.1

Aplikasi Web Klien: pesan kesalahan mudah terlewatkan. Lihat itu?

Gambar 5.2

Masuk Mac: pesan kesalahan mudah terlewatkan, meskipun ditampilkan dalam warna oranye.

muncul kembali menampilkan pesan kesalahan (Gambar 5.1). Penempatan pesan

(pojok kiri atas), ukuran, dan warna membuatnya mudah terlewat. Setelah memasukkan file
ID dan PIN dan mengklik "Masuk", pengguna melihat di tengah bawah
halaman. Pengguna yang salah mengetik ID atau PIN mereka sering menghabiskan beberapa detik
bertanya-tanya mengapa layar "Login" baru saja ditampilkan kembali. Seringkali mereka akan mencoba
lagi, hanya untuk kembali ke sini lagi, sampai akhirnya mereka melihat pesan kesalahan.
Dalam layanan online ".Mac" Apple Computer, memasukkan informasi login yang tidak valid
menyebabkan pesan kesalahan muncul di sudut kiri atas (Gambar 5.2). Bahkan
meskipun pesannya berwarna oranye, ukurannya yang kecil dan lokasinya yang terpencil
mungkin ketinggalan.

Variasi C: Dikubur dalam "noise"

Informasi penting terkadang terkubur dalam lautan kesamaan atau visual

"kebisingan." Komputer hebat dalam menghasilkan pengulangan. Komputer itu hebat
dalam menghasilkan pengulangan. Komputer hebat dalam menghasilkan pengulangan. Lihat?
Terkadang ini bagus, tetapi saat Anda mencoba memastikan pengguna menerimanya

Halaman 216

202 Bab 5 Bloopers Desain Grafis dan Tata Letak

informasi penting, itu buruk. Repetisi dan gangguan visual menempatkan persepsi kita

[Link] 156/315
26/2/2021 Tanpa judul
sistem untuk tidur, menyebabkan
Pertimbangkan dua petunjuk kita
ini: kehilangan hal-hal penting saat hal itu datang.
Masukkan nama file dan tekan ENTER

Masukkan nama pengguna dan tekan ENTER

Satu-satunya perbedaan adalah kata kedua. Itulah satu-satunya informasi; sisanya

kebisingan. Kata yang menggunakan huruf besar menarik perhatian kita, tetapi hanya kebisingan. Jika perangkat lunak dis-
memainkan dua petunjuk ini, terkadang pengguna bingung dengan dua petunjuk dan
ketik tanggapan yang tidak pantas. Berikut dua petunjuk yang lebih mudah dibedakan:
Nama file:

Nama pengguna:

Tampilan status adalah tempat masalah umum lainnya. Pertimbangkan ini:

Tangki penampung: normal Katup tekanan: normal

Batang bahan bakar: abnormal Pompa pembuangan: normal

Dalam pesan-pesan ini, informasi penting terkubur oleh pengulangan dan

presentasi yang buruk.
Halaman informasi SIM di California Department of Motor
Situs Web Kendaraan memiliki daftar tautan yang bertele-tele dan berulang-ulang (Gambar 5.3). Sulit untuk melakukannya
pindai daftar dengan cepat untuk menemukan tautan yang Anda butuhkan.
Tampilan hasil adalah situasi lain di mana informasi sering terkubur
lautan kebisingan. Perangkat lunak sering kali mengeluarkan sekam yang berulang dan tidak informatif
yang harus disaring pengguna untuk menemukan beberapa butir gandum. Sebagaimana dinyatakan dalam Bab 1,
“Komputer menjanjikan sumber informasi, tetapi memberikan banyak data.”
Hasil penting pencarian sering kali terkubur dalam pengulangan dan visual
kebisingan. Masalahnya di sini bukanlah seberapa baik atau buruk mesin pencari dalam menemukan rel-
barang evant; ini adalah bagaimana hasil ditampilkan.
Pada tahun 1999, layanan pencarian Web [Link] menampilkan hasil pencarian dengan buruk
(Gambar 5.4). Baris pertama untuk setiap item adalah posisinya di kategori Lycos
hirarki. Dalam hasil pencarian, item yang berurutan cenderung memiliki kategori yang sama
ries, jadi desain ini menghasilkan pengulangan. Dalam hasil ini, empat kata pertama masuk
setiap item yang ditemukan adalah sama dan begitu pula kebisingan, bukan informasi. Informasi-
tion adalah dalam perbedaan antara item, tapi Lycos 1999 hasil menekankan
persamaan antara item lebih dari perbedaan.

Gambar 5.3

[Link]: tautan bertele-tele dengan teks berulang membuat daftar sulit dipindai dengan cepat.

Halaman 217

Tata letak dan penempatan jendela yang buruk 203

Gambar 5.4

[Link] (1999): hasil penelusuran untuk "gitar akustik". Berisik, sulit memindai item yang relevan.

Gambar 5.5

[Link] 157/315
26/2/2021 Tanpa judul

[Link] (2007): hasil penelusuran untuk “gitar akustik”. Tidak terlalu berisik, lebih mudah dipindai
item yang relevan.

Bandingkan dengan bagaimana [Link] menampilkan hasil di awal 2007: jauh lebih sedikit
berisik dan lebih mudah bagi pengguna untuk memindai dengan cepat (Gambar 5.5).
Meskipun ada perbaikan dalam hasil pencarian Web, banyak pencarian khusus situs
fungsi masih menampilkan hasil yang buruk. Blooper 21 (halaman 145) menampilkan beberapa Web
situs yang menghasilkan hasil pencarian yang tidak dapat digunakan.

Pesan yang tidak akan mati

Salah satu cara agar pengguna melewatkan pesan penting adalah dengan menampilkan pesan baru
lebih dari yang lama serupa.
Microsoft Office memungkinkan Anda mencari Galeri Klipnya untuk menemukan seni untuk ditambahkan ke
ment. Anda memasukkan kata kunci; itu mencari clip art yang diberi tag dengan kata kunci tersebut.
Jika Anda mencari "dial", Anda mendapatkan pesan yang mengatakan tidak menemukan apa-apa (Gambar 5.6A).
Jika Anda mengubah kata kunci menjadi "gauge" dan menelusuri lagi, pesannya tetap ada
(Gambar 5.6B). Apakah ia juga tidak menemukan apa pun untuk "gauge" atau masih mencari? Tidak boleh
menceritakan. Menghapus hasil pencarian sebelumnya atau pesan ketika pengguna memasukkan yang baru
istilah pencarian akan memperbaiki ini.

Halaman 218

204 Bab 5 Bloopers Desain Grafis dan Tata Letak

Gambar 5.6

Pencarian Galeri Klip Microsoft Office meninggalkan pesan kesalahan lama dan menampilkan yang baru
atas mereka.

Menghindari Blooper 32

Berikut adalah pedoman untuk membuat informasi sulit dilewatkan oleh pengguna.

Bangun hierarki visual

Atur tampilan informasi menjadi potongan, subchunks, subchunks, dll., Begitu

pengguna dapat dengan cepat menemukan bagian yang tepat, lalu sub-bagian yang tepat di bagian tersebut,
dll Yang memungkinkan pengguna mengabaikan potongan yang tidak relevan dan menemukan apa yang mereka inginkan banyak
lebih cepat daripada jika mereka harus memindai — atau lebih buruk lagi, membaca — semua yang ada di
layar. Jendela di komputer menyediakan chunking tingkat tinggi, tetapi terserah
Anda untuk membagi informasi di jendela atau halaman perangkat lunak Anda.

Memperbesar informasi penting

Lampu rem belakang dan lampu sein pada mobil masa kini lebih besar dari
mereka ada di tahun 1980. Ini bukan hanya mode; itu membuat cahayanya lebih terlihat.
Ukuran itu penting, terutama untuk indikator yang harus diperhatikan sekalipun
tidak berada di tengah bidang visual pemirsa.
Hal yang sama berlaku untuk informasi di layar, apakah itu kontrol, simbol,
teks, atau area warna. Semakin besar indikatornya, semakin banyak sel retina citranya
selimut dan semakin sulit untuk dilewatkan.
Namun, jika semua yang ada di layar besar, tidak ada yang menonjol. Ukuran relatif
adalah yang paling penting.

Letakkan informasi penting di tempat yang dilihat pengguna

Menempatkan informasi lebih dekat ke tengah bidang visual pemirsa meningkatkannya

visibilitas dan keterbacaan. Penglihatan perifer buruk dan semakin buruk seiring bertambahnya usia.
Menempatkan indikator di kursor adalah strategi yang baik untuk yang kecil, kritis
indikator karena di situlah pengguna biasanya melihat. Menampilkan penting
pesan dalam baris pesan di bagian bawah jendela aplikasi hanya berfungsi jika
Anda melakukan sesuatu yang istimewa untuk menarik perhatian pengguna ke pesan tersebut.

[Link] 158/315
26/2/2021 Tanpa judul

Halaman 219

Tata letak dan penempatan jendela yang buruk 205

Gunakan warna untuk menyorot

Warna yang kontras dapat menarik perhatian pada informasi. Dalam masyarakat Barat, merah
secara tradisional menunjukkan ada sesuatu yang salah, dan itu adalah warna yang bagus untuk kesalahan
pesan. Gunakan warna merah oranye daripada merah murni untuk visibilitas maksimum.
Dalam sistem misi kritis (misalnya, sistem kendali lalu lintas udara, perawatan intensif
sistem pemantauan medis, dan panel kontrol pembangkit listrik), pesan darurat
orang bijak ditampilkan dengan warna merah. Kuning sering digunakan untuk memperingatkan atau menunjukkan kehati-hatian.
Formulir pendaftaran akun email [Link] menggunakan warna merah untuk menarik perhatian. Jika
seseorang mencoba untuk mendaftar tetapi menghilangkan data yang diperlukan, pesan kesalahan merah muncul
di bagian atas dan semua bidang wajib diisi diberi label merah (Gambar 5.7).
Untuk benar-benar menarik perhatian pengguna, Anda dapat mengubah warna secara real time. Sebagai contoh,
pesan kesalahan bisa bergantian sekali antara merah dan kuning lalu tetap merah.
Satu aplikasi menampilkan pesan kesalahan pada baris pesan di bagian bawah
dari jendela aplikasi. Untuk diperhatikan, pesan muncul sebentar dengan warna merah,
kemudian berubah menjadi hitam setelah satu detik. Itu tidak hanya menarik perhatian pengguna, tapi juga
juga menunjukkan apakah sebuah pesan baru atau tersisa dari kesalahan sebelumnya.

Cara lain untuk menonjolkan informasi

Selain ukuran, posisi, dan warna, Anda juga dapat menggunakan:

■
Keberanian, kerapatan, warna, saturasi: Teks tebal tampak menonjol. Grafik bisa
memiliki garis yang lebih tebal atau lebih gelap dan warna isian. Gambar berwarna bisa dibuat lebih banyak
jenuh. Namun, ketebalan, kepadatan, dan saturasi harus digunakan dengan
pengekangan. Itu tidak sedikit atau tidak ada yang baik untuk membuat teks tebal jika sebagian besar teks
sekitarnya adalah berani.
■
Grafik dan simbol: Grafik, ikon, dan simbol dapat menarik perhatian pengguna
tion, terutama jika sebagian besar tampilan adalah teks. Pesan kesalahan merah di AOL.
com (Gambar 5.7) akan lebih terlihat jika dimulai dengan warna merah besar
X, tanda berhenti, atau tanda seru besar. Seperti halamannya, yang paling menarik
objek adalah simbol seseorang.

Artileri berat: gunakan dengan hemat dan hati-hati

Jika informasi atau petunjuk benar-benar kritis (misalnya, berpotensi menimbulkan bencana
masalah di pembangkit listrik tenaga nuklir), ada tiga teknik yang bisa dilakukan
pesan atau prompt hampir tidak mungkin untuk diabaikan:

1. Kotak dialog dan pop up: Bisa jadi pesan kesalahan, peringatan, dan prompt
ditampilkan di kotak dialog, yang keluar dari browser dan masuk ke "di
wajah pengguna. ” Kotak dialog dapat menjadi modal, memblokir pengguna dari melakukan apa pun-
hal lain dengan aplikasi (atau dalam beberapa kasus, dengan komputer mereka) hingga
mereka mengakui atau mengabaikan kotak dialog, atau mereka bisa nonmodal. REI.
com, tidak seperti [Link], menggunakan kotak dialog untuk memberi tahu pengguna bahwa data yang diperlukan adalah
hilang dari formulir (Gambar 5.8).

Halaman 220

206 Bab 5 Bloopers Desain Grafis dan Tata Letak

Gambar 5.7

[Link] 159/315
26/2/2021 Tanpa judul

Merah

[Link]: formulir akun email menyoroti pesan kesalahan dan label data yang tidak lengkap
bidang berwarna merah.

Gambar 5.8

[Link]: formulir aplikasi pelanggan baru menunjukkan bidang data yang tidak lengkap dalam kesalahan
kotak dialog.

Halaman 221

Tata letak dan penempatan jendela yang buruk 207

2. Suara: Pesan baru, batas terlampaui, atau kesalahan terdeteksi dapat terjadi
diumumkan dengan suara. Bunyi bip sederhana biasanya cukup jika jelas
di mana mencari detailnya. Beberapa mobil baru memainkan "barump, barump,
barump ”terdengar saat mobil mulai keluar dari jalurnya. Seperti huruf tebal,
suara dapat dengan mudah digunakan secara berlebihan. Orang tidak bisa membedakan lebih dari beberapa
suara sewenang-wenang. Ini juga tidak akan berfungsi jika ada banyak kebisingan sekitar atau
tempat orang bekerja dalam jarak dekat.
3. Getaran dan animasi: Penglihatan periferal untuk objek alat tulis sedang
buruk, tetapi sangat pandai memperhatikan gerakan atau perubahan. Kami dengan cepat
lihat apa pun yang menarik perhatian kita, jadi kedipan atau gerakan bisa
menarik perhatian ke data penting. Namun, mereka mengganggu dan
menjengkelkan jika terus menerus, dan desainer Web telah menyalahgunakannya untuk mendapatkannya
orang untuk melihat iklan. Banyak desainer, seperti Flanders
dan Willis [1998], sekarang melarang penggunaannya. Jika Anda menggunakan animasi atau
berkedip, pastikan berhenti dengan cepat. Jika Anda tidak bisa menghentikannya, jangan gunakan .
Sayangnya, banyak situs Web yang melanggar aturan ini. Beranda dari
[Link], sebuah toko perlengkapan kolam ikan, memiliki beberapa animasi itu
berjalan terus-menerus (Gambar 5.9).

Jangan mengubur gandum dengan sekam

Perangkat lunak harus menyampaikan informasi, bukan hanya data (Prinsip Dasar 7, halaman 41).
Oleh karena itu, hindari menampilkan data yang tidak membawa informasi berguna, khususnya
data noninformatif, berulang. Tekankan informasi penting menggunakan
metode yang diberikan di atas.
Alih-alih menampilkan hasil yang dihitung sebagai deskripsi teks prosa, tampilkan
mereka dalam tabel, bagan, dan grafik [Tufte, 1990, 2001]. Banyak hasil pencarian Web
akan lebih baik disajikan dalam tabel.
Jika teks nontabular tidak dapat dihindari, minimalkan verbiage. Pengguna mencari-
ing untuk gandum, dan teks yang tidak mengandung informasi adalah sekam yang tidak berguna. Format
teks untuk memusatkan perhatian pengguna pada informasi yang berguna.

[Link] 160/315
26/2/2021 Tanpa judul
Gambar 5.9

[Link]: animasi konstan dan tidak berguna yang mengalihkan perhatian dari konten penting.

Halaman 222

208 Bab 5 Bloopers Desain Grafis dan Tata Letak

Menampilkan informasi secara grafis, bukan secara tekstual

Program instruksi musik RhythmTutor membantu orang belajar membaca musik

dengan memberikan latihan membaca notasi ritme — durasi catatan dan istirahat.
RhythmTutor melakukan latihan dengan menunjukkan notasi musik dan membunyikan met-
nada ronome. Anda "memainkan" musik dengan menekan bilah Spasi untuk setiap not di
tempo metronom. Di akhir setiap latihan, RhythmTutor memberi peringkat
kinerja, menunjukkan berapa banyak catatan yang Anda lewatkan, berapa banyak catatan tambahan Anda
dimainkan, dan apakah not dimulai dan diakhiri terlambat, lebih awal, atau tepat waktu.
Rilis beta RhythmTutor menyajikan semua umpan balik secara numerik, disematkan di
teks prosa (Gambar 5.10A). Dalam produk yang dirilis, tanggapan pengguna sangat banyak
lebih mudah dipahami (Gambar 5.10B).

Gambar 5.10

Dari 45 nada: 1 terlewatkan - ada 0 pukulan ekstra

perhatikan bias onset = 0 Catatan dimulai tanpa bias

catatan kesalahan onset = 9 Catatan dimulai dengan sangat konsisten
catatan bias rilis = –13 Catatan dirilis terlalu dini
catatan rilis kesalahan = 6 Catatan dirilis dengan sangat konsisten

Skor Keseluruhan = 69%

SEBUAH

Catatan Onset Catatan Rilis

131 Catatan Total

TERLALU DINI
5 Catatan Terlewatkan
6 Pukulan Ekstra BENAR
SANGAT TERLAMBAT

Skor Keseluruhan = 69%

B
Tampilan skor RhythmTutor. (A) Sebelum mendesain ulang: tekstual. (B) Setelah: lebih grafis.

Blooper 33: Mencampur tombol kontrol kotak dialog

dengan tombol kontrol konten

Banyak kotak dialog menempatkan tombol standar "OK", "Terapkan", "Tutup", "Batal",
dan "Bantuan" di tempat yang sama dengan tombol yang mengontrol data atau pengaturan tertentu.
Bayangkan Anda sedang membuat aplikasi untuk melacak harga saham. Di dia-
kotak log untuk menambahkan saham yang akan dilacak, tombol "Tambah" dan "Hapus" akan
biarkan pengguna mengelola daftar "Pelacakan". Anda dapat meletakkan "Tambah" dan "Hapus" di
bagian bawah kotak dialog, di samping "OK", "Batal", dan "Bantuan" (Gambar 5.11),
karena bagian bawah adalah tempat yang nyaman untuk meletakkan semua tombol.

Halaman 223

[Link] 161/315
26/2/2021 Tanpa judul

Tata letak dan penempatan jendela yang buruk 209

Gambar 5.11
Investor: Edit Daftar Pelacakan Saham

Tersedia Pelacakan

ASE Trst ATT

Accel HWP
ActVoic Orcl
Adaptec SunW
UdaraC SWA
AppleC
ATT
Mencegah
BOK
BnkPlus
BestSft
Comdial

baik Membatalkan Tolong MenambahkanMenghapus

Tombol pengatur jendela tak lepas dari tombol pengatur konten.

Itu akan menjadi kesalahan desain karena dua alasan:

1. Menempatkan tombol khusus data jauh dari data yang mereka kontrol akan menyulitkan
lihat hubungan antara tombol dan data.
2. Tidak ada perbedaan visual antara tombol yang mengontrol keseluruhan dialog
kotak dan mereka yang mengontrol data tertentu di dalamnya.

Dalam kotak dialog Levels PhotoShop, "OK" dan "Batal" tutup jendela; yang lain
empat tombol mempengaruhi atau menyimpan histogram kecerahan (Gambar 5.12A). Di Outlook's Move
Kotak dialog Item, tombol "Baru ..." membuat folder baru, sedangkan "OK" dan "Batal"
tutup kotak dialog (Gambar 5.12B). Pada keduanya, itu bagus bahwa kontrol konten tetapi-
ton berada di dekat konten, tetapi tombol kontrol kotak dialog itu juga buruk.

Gambar 5.12

Tombol kontrol jendela pencampuran dan kontrol konten. (A) Adobe PhotoShop. (B) Microsoft Outlook.
(Lanjutan)

Halaman 224

210 Bab 5 Desain Grafis dan Tata Letak Bloopers

Gambar 5.12

(Lanjutan)

[Link] 162/315
26/2/2021 Tanpa judul

Menghindari Blooper33

Tombol yang memengaruhi seluruh kotak dialog— "Oke", "Terapkan", "Tutup", "Batal",
“Bantuan” —harus dipisahkan dari yang mengontrol data atau pengaturan tertentu.
Tombol "Tambah" dan "Hapus" harus berada di antara daftar gulir yang mereka pengaruhi,
membuat fungsinya lebih jelas dan memesan baris paling bawah dari kotak dialog
“OK,” “Cancel,” dan “Help” (Gambar 5.13). Garis membantu memisahkan kontrol konten
tombol dari tombol kontrol kotak dialog, tetapi dengan jarak yang memadai tidak
perlu.

Gambar 5.13
Investor: Edit Daftar Pelacakan Saham

Tersedia: Terpilih:

ASE Trst ATT

Accel HWP
ActVoic Orcl
Adaptec SunW
Menambahkan
UdaraC SWA
AppleC
ATT
Mencegah
BOK Menghapus
BnkPlus
BestSft
Comdial

baik Membatalkan Tolong

Tombol kontrol konten dipisahkan dari tombol kontrol jendela.

Halaman 225

Tata letak dan penempatan jendela yang buruk 211

Dua contoh tata letak tombol yang baik berasal dari kotak dialog dua email
program: Mozilla Thunderbird dan Microsoft Outlook (Gambar 5.14). Outlook
kotak dialog menggunakan pemisah untuk membedakan tombol kontrol kotak dialog dari
istirahat, sedangkan kotak dialog Mozilla melakukan hal yang sama hanya dengan pemosisian yang baik dan
jarak.

Gambar 5.14

[Link] 163/315
26/2/2021 Tanpa judul

Jendela terpisah dan tombol kontrol konten. (A) Mozilla Thunderbird. (B) Microsoft
Pandangan.

Halaman 226

212 Bab 5 Bloopers Desain Grafis dan Tata Letak

Blooper 34: Menyalahgunakan kotak grup

Kebanyakan toolkit GUI menyediakan kotak grup 1 untuk menempatkan batas yang terlihat di sekitarnya
kontrol terkait. Kotak grup memiliki slot untuk label, biasanya di kiri atas
tepi. Penggunaan klasik kotak grup yang bagus dapat dilihat di Microsoft Internet
Kotak dialog Aksesibilitas Penjelajah (Gambar 5.15).

Variasi A: Kelompokkan kotak di sekitar satu pengaturan

Kesalahan tata letak yang umum adalah menempatkan kotak grup di sekitar satu setelan.
Biasanya ini dilakukan untuk menggunakan label bawaan kotak grup untuk memberi label pada pengaturan. Untuk
Misalnya, satu perusahaan secara teratur menempatkan kotak grup di sekitar area teks bergulir
dan panel tab untuk memberi label (Gambar 5.16).
Menggunakan kotak kelompok hanya sebagai tempat label mengabaikan tujuan sebenarnya—
mengelompokkan berbagai hal — dan mengacaukan tampilan tanpa perlu. Ini juga sering berlebihan:
banyak kontrol GUI, misalnya tabel, daftar gulir, menu opsi, dan bidang teks,
memiliki batasnya sendiri.
Kotak dialog Pengontrol Game Kustom Microsoft Window dan Buku Panduan
jendela Perencana Perjalanan National Geographic memiliki blooper. The Custom
Kotak dialog Game Controller memiliki tiga kotak grup, dua di antaranya berada di sekitar
item tunggal (Gambar 5.17A). Di Trip Planner, kotak grup mengelilingi bagian atas
daftar gulir Topik Buku Panduan (Gambar 5.17B). Di keduanya, kotak grup adalah
hanya pemegang label.

Gambar 5.15

Microsoft Internet Explorer: penggunaan klasik kotak grup untuk mengatur pengaturan.

1. Di beberapa toolkit GUI, ini disebut "perbatasan".

Halaman 227

Tata letak dan penempatan jendela yang buruk 213

Gambar 5.16
Keluarga Font Bookmark

[Link] 164/315
26/2/2021 Tanpa judul
Pencari Kode Pos USPS
Helvetica
Kalkulator Perangko USPS
Pedoman Netiket IETF
Nama [Link]
[Link]
John Smith [Link]
Dukungan Pelanggan MegaTech
Kondisi Jalan Raya Area Teluk
Status [Link]

KRITIS

Kelompokkan kotak di sekitar satu kontrol, disalahgunakan sebagai tempat label.

Gambar 5.17

Kelompokkan kotak di sekitar satu item. (A) Microsoft Windows. (B) Perencana Perjalanan National Geographic.

Variasi B: Kelompokkan kotak di dalam kotak kelompok

Variasi kedua dari kesalahan besar ini adalah menyarangkan kotak grup di dalam kotak grup.
Hal ini membuat tampilan menjadi berantakan (Gbr 5.18).
Menunjukkan bahwa kehidupan nyata bisa lebih aneh daripada fiksi, SmartDraw memiliki dialog
kotak dengan kotak kelompok bersarang tiga dalam (Gambar 5.19). Ini juga memiliki kotak grup
di sekitar item tunggal, berfungsi sebagai pemegang label.

Halaman 228

214 Bab 5 Desain Grafis dan Tata Letak Bloopers

Gambar 5.18 Info kontak Aktiva

Nama Gaji Perumahan
<= 20K Rumah
Pertama: John
> 20-40K Persewaan
Terakhir: Abercrombe > 40-60K
Tanah pertanian
> 60-80K
Alamat > 80K Lain
Jumlah: 123
Bank

Jalan: Pleasant St. Nama: Tepi Barat

Kota: Cleveland Akun

Memeriksa: $ 2.500,24
Negara: OH
Tabungan: $ 52.465,37
Kode Pos: 12345

Kelompokkan kotak di dalam kotak kelompok, menyebabkan kekacauan yang tidak perlu.

Gambar 5.19

[Link] 165/315
26/2/2021 Tanpa judul

SmartDraw: kotak grup bersarang dua dan tiga dalam. Beberapa hanya pemegang label.

Variasi C: Satu kotak grup di jendela

Penyalahgunaan ketiga dari kotak kelompok adalah meletakkan satu di sekeliling semuanya di jendela.
Kotak tersebut mungkin mengelompokkan beberapa pengaturan, tetapi tidak memisahkan pengaturan tersebut dari
yang lainnya. Dengan demikian, kotak grup tidak diperlukan.

Halaman 229

Tata letak dan penempatan jendela yang buruk 215

Seorang pengembang dapat melakukan ini untuk menahan judul jendela (Gambar 5.20). Namun,
judul harus ada di batang judul jendela, misalnya, “Investor: Edit Pelacakan Saham
Daftar." Alternatifnya, pengembang mungkin menggunakan kotak grup untuk memisahkan bagian bawah
deretan tombol kontrol dari yang lainnya. Namun, ada cara yang lebih baik untuk melakukannya
lakukan itu, seperti yang dijelaskan di bawah cara menghindari Blooper 33.
Kotak dialog di SoundBlaster Wave Studio dan Windows Media Player
menunjukkan variasi penyalahgunaan kotak kelompok (Gambar 5.21). Keduanya, bagian luar
kotak grup hanya menambah kekacauan.

Gambar 5.20
Investor

Edit Daftar Pelacakan Stok

Tersedia: Terpilih:

ASE Trst ATT

Accel HWP
ActVoic Orcl
Adaptec SunW
Menambahkan
UdaraC SWA
AppleC
ATT
Mencegah
BOK Menghapus
BnkPlus
BestSft
Comdial

baik Membatalkan Tolong

Kelompokkan kotak di sekitar semuanya, menyebabkan kekacauan yang tidak perlu.

Gambar 5.21

Kotak grup tak berlabel di sekeliling semuanya. (A) SoundBlaster Wave Studio. (B) Jendela
Pemutar Media.

[Link] 166/315
26/2/2021 Tanpa judul

Halaman 230

216 Bab 5 Desain Grafis dan Tata Letak Bloopers

Menghindari Blooper34

Kotak grup sesuai dengan namanya: tinju grup pengaturan terkait .

Kontrol penampung seperti tabel, daftar gulir, dan bidang teks yang dapat diedit disediakan
batas bawaan mereka sendiri dan tidak membutuhkan batas tambahan.
Beri label satu pengaturan tanpa meletakkan kotak kelompok di sekitarnya, menggunakan Label atau
Kontrol Teks Statis. Label harus berada di atas atau di kiri item — mana saja
lebih baik untuk tata letak keseluruhan. Dialog Properti Mouse Microsoft Windows
kotak memanfaatkan kotak kelompok dengan baik (Gambar 5.22). Tidak perlu grup
kotak di sekitar daftar Kustomisasi: ia memiliki batasnya sendiri.
Kotak kelompok harus digunakan dengan hemat. Menempatkan kotak kelompok dalam kelompok
kotak mengacaukan tampilan. Penspasian dan pelabelan yang cermat dapat memperjelas
zasi panel kontrol sambil meminimalkan kekacauan. Windows Media Player
Kotak dialog Ubah Lokasi Musik Rip tidak menggunakan kotak grup sama sekali (Gambar 5.23).
Jika jarak saja tidak cukup, pemisah dapat membantu memberikan keteraturan visual.
Set tombol radio adalah kasus khusus: meskipun satu pengaturan, itu
terkadang membantu menempatkan kotak kelompok di sekelilingnya untuk memisahkannya dari yang lain
pengaturan radio-button terdekat, seperti pada SoundBlaster Wave Studio (Gambar 5.21A).
Namun, pengaturan tombol radio dapat dipisahkan menggunakan garis atau spasi kosong, seperti
dalam kotak dialog dari Microsoft Word dan Apple Preview (Gambar 5.24).

Gambar 5.22

Jendela Properti Microsoft Windows Mouse: penggunaan kotak grup dengan baik.

Halaman 231

Tata letak dan penempatan jendela yang buruk 217

Gambar 5.23

[Link] 167/315
26/2/2021 Tanpa judul

Microsoft Windows Media Player: Kotak dialog Ubah Lokasi Musik Rip tidak memiliki kotak grup.

Gambar 5.24

Tombol radio diberi label tanpa kotak grup di sekelilingnya. (A) Microsoft Word. (B) Apel
Pratinjau.

Blooper 35: Tombol radio terlalu jauh

Terkadang tombol radio sangat jauh sehingga tidak terlihat seperti satu pengaturan
(Gambar 5.25).
Masalah dalam contoh hipotetis adalah jarak horizontal yang berlebihan.
Formulir di situs Web [Link] menunjukkan bahwa jarak vertikal yang berlebihan bisa
membuat tombol radio terlihat tidak terhubung (Gambar 5.26) juga.

Halaman 232

218 Bab 5 Desain Grafis dan Tata Letak Bloopers

Gambar 5.25
Tampilan: Ringkasan Detail

Jarak tombol radio terlalu jauh untuk dianggap terkait.

Gambar 5.26

[Link]: tombol radio berjarak terlalu jauh untuk dianggap terkait.

Jika grup tombol radio berbeda bersebelahan, pengguna dapat melakukannya

salah paham bagaimana mereka dikelompokkan. Ini dapat terjadi jika grup tombol radio

[Link] 168/315
26/2/2021 Tanpa judul
diletakkan secara
kelompok lain horizontal,
selain tombol dengan tombol dimereka
dalam kelompok setiap grup lebih
sendiri dekat ke
(Gambar tombol
5.27). dalam adalah
Tombolnya
dalam baris, namun tampak dikelompokkan berdasarkan kolom.
Pengguna mungkin dapat mengetahui dari pelabelan bagaimana tombol tersebut
dikelompokkan, tetapi pengguna tidak harus berhenti dan berpikir tentang bagaimana UI itu
terorganisir. Juga terkadang label tidak membantu (Gambar 5.28).

Gambar 5.27
Keju: Keju mozzarella Mendongkrak Swiss
Daging: Sosis daging Peperoni
Kepedasan: Ringan Medium Panas
Kerak: Gandum utuh putih Penghuni pertama

Tombol radio di setiap grup yang dituju lebih jauh satu sama lain daripada yang ada di
kelompok yang berdekatan.

Halaman 233

Tata letak dan penempatan jendela yang buruk 219

Gambar 5.28
Frekuensi: 1000 10000 100000 Rendah Sedang Tinggi
Intensitas Gema: 500 1500 2500 Kejenuhan:
Kontras:
Tingkat putaran: 1 2 3
Frekuensi:
Penundaan Sinyal: 10 100 1000 Amplitudo:

SEBUAH B
Tombol radio muncul dikelompokkan dalam kolom daripada baris yang dimaksudkan.

Gambar 5.29

Wisaya penginstal rahasia: tombol radio muncul dikelompokkan dalam kolom daripada di
baris yang dimaksudkan.

Contoh nyata terjadi pada halaman pemilih komponen Perangkat Lunak Rahasia
wizard untuk menginstal produk perusahaan dari CD (Gambar 5.29).

Menghindari Blooper35

Pengaturan tombol radio harus diatur sehingga pengguna dapat melihat sekilas bagaimana keadaan mereka
dikelompokkan. Salah satu cara untuk melakukannya adalah dengan kotak kelompok atau pemisah (Gambar 5.30).
Pendekatan lain adalah dengan menggunakan ruang kosong. Jika jarak antar kelompok adalah
lebih besar dari ruang rata-rata antara tombol dalam grup (termasuk tombol
label), pengguna akan melihat pengelompokan yang dimaksudkan (Gambar 5.31).
Pada Gambar 5.32, radio button diatur dalam matriks yang rapi. Jika nomornya
opsi bervariasi dari grup ke grup atau jika label opsi dalam grup berbeda
panjangnya bervariasi, lebih baik memberi jarak yang rapat pada setiap grup, meskipun demikian

Halaman 234

[Link] 169/315
26/2/2021 Tanpa judul

220 Bab 5 Bloopers Desain Grafis dan Tata Letak

Gambar 5.30 Keju

Keju mozzarella Mendongkrak Swiss
Daging
Sosis daging Peperoni
Kepedasan
Ringan Medium Panas
Kerak
Putih Gandum Utuh Penghuni pertama

SEBUAH

Keju: Keju mozzarella Mendongkrak Swiss

Daging: Sosis daging Peperoni

Kepedasan: Ringan Medium Panas

Kerak: Gandum utuh putih Penghuni pertama

B
Grup tombol radio dipisahkan sehingga pengguna melihat pengelompokan yang diinginkan. (A) Kotak grup. (B) Pemisah.

Gambar 5.31
Keju: Keju mozzarella Mendongkrak Swiss

Daging: Sosis daging Peperoni

Kepedasan: Ringan Medium Panas

Kerak: Gandum utuh putih Penghuni pertama

Kelompok tombol radio diberi jarak sehingga pengguna melihat pengelompokan yang dimaksudkan.

Gambar 5.32
Frekuensi: 1.000 hz 10.000 hz 100.000 hz

Warna latar belakang: Merah jeruk hijau Biru Nila Ungu

Putar Sumbu: X Y Z

Model Estimasi: Linear Kuadrat Eksponensial Spline

Set tombol radio diberi jarak rapat dan tidak teratur sehingga pengguna melihat pengelompokan yang benar.

merusak susunan matriks yang rapi (Gambar 5.32). Sebuah tata letak yang tidak teratur mungkin
mengganggu kepekaan estetika Anda, tetapi tugas Anda adalah menghindari pengguna yang membingungkan.

Blooper 36: Label terlalu jauh dari bidang data

Pengembang GUI biasanya di bawah tekanan untuk menghasilkan UI dengan cepat. Mereka sering
memasukkan kontrol dan label secepat mungkin tanpa mengkhawatirkan mereka

Halaman 235

Tata letak dan penempatan jendela yang buruk 221

penempatan yang tepat dan asumsikan bahwa penempatan dapat disempurnakan suatu saat
masa depan ketika ada lebih banyak waktu. Sayangnya, saat itu jarang tiba.
Ini menghasilkan GUI di mana label terlalu jauh dari kontrol yang mereka beri label,
sehingga menyulitkan pengguna untuk melihat sekilas label mana yang sesuai dengan kontrol mana.
Kesalahan besar ini memiliki dua variasi umum.

Variasi A: Label di paling kiri; bidang data di paling kanan

Cacat spasi label yang paling umum terjadi dalam formulir online. Cara mudah untuk melakukannya
Lay out form adalah dengan menempatkan label field pada kolom yang ditempelkan di tepi kiri dan
bidang data dalam kolom yang dilampirkan di tepi kanan. Hal ini sering kali memberi label demikian
jauh dari bidang datanya sehingga pengguna tidak dapat dengan mudah melihat koneksi. Sebuah klasik
contohnya terjadi di situs web Asosiasi Penjual Buku Online Internasional
(Gambar 5.33).

[Link] 170/315
26/2/2021 Tanpa judul

Gambar 5.33

Formulir pendaftaran [Link]: label terlalu jauh dari bidang datanya. (A) Browser lebar.
(B) Browser sempit.

Halaman 236

222 Bab 5 Bloopers Desain Grafis dan Tata Letak

Gambar 5.34

Formulir asuransi pengangguran [Link]: Tombol radio “Ya” / “Tidak” terlalu jauh dari mereka
label.

Contoh yang lebih halus terjadi dalam formulir asuransi pengangguran di

situs Web Negara Bagian California, [Link]. Pilihan Ya / Tidak adalah tombol radio
menempel di tepi kanan, jauh dari pertanyaan mereka (Gambar 5.34).
Blooper ini diperparah oleh layout lebar-variabel di mana dis-
jarak antara label dan bidang data bergantung pada seberapa luas pengguna membuat
jendela.

Variasi B: Label lebih mirip dengan pengaturan selain pengaturannya sendiri

Cacat penempatan label kedua yang paling umum adalah label properti
lebih dekat ke bidang data lain daripada ke bidang yang mereka beri label. Contoh yang sempurna
terjadi di [Link] (Gambar 5.35).
Seberapa dekat objek satu sama lain menentukan persepsi kita tentang bagaimana objek tersebut
dikelompokkan. Oleh karena itu, penempatan label yang buruk bukan hanya masalah estetika; saya t
dapat mengurangi kegunaan perangkat lunak.
Mengapa ada orang yang memposisikan label seperti di [Link]? Desainer dan
pengembang biasanya berada di bawah tekanan waktu yang besar. Mereka juga mungkin tidak tahu caranya
penempatan label sangat mempengaruhi kegunaan formulir.
Alasan ketiga adalah bahwa dari perspektif pengembang, label mungkin tidak

[Link] 171/315
26/2/2021 Tanpa judul
menjadi jauh dari bidang data. Asumsikan bahwa formulir memiliki dua bidang teks dan menu.
Pengembang mungkin membuat label lebih lebar dari yang diminta teksnya, mungkin untuk
menyesuaikan terjemahan ke dalam bahasa lain. Pada Gambar 5.36, label hipotetis meliputi
ponents dibalik untuk menunjukkan batasnya. Dari sudut pandang pengembang
lihat, label berada di samping pengaturannya; dari sudut pandang pengguna, mereka
tidak.

Halaman 237

Tata letak dan penempatan jendela yang buruk 223

Gambar 5.35

[Link]: Label negara bagian dan ZIP lebih dekat ke bidang data sebelumnya daripada miliknya.

Gambar 5.36

[Link]: komponen label hipotetis terbalik untuk menunjukkan lebar penuhnya.

Menghindari Blooper36

Pengguna tidak harus mengamati formulir atau panel kontrol dengan cermat untuk mencari
mengetahui bagaimana kontrol dan bidang data diberi label. Pemindaian cepat sudah cukup.
Oleh karena itu, letakkan label di dekat objeknya. Ikuti empat aturan sederhana ini.

Aturan 1: Jangan lampirkan label dan bidang data ke

tepi berlawanan dari formulir atau panel kontrol

Jika kolom dari tabel yang tidak terlihat digunakan untuk meletakkan label dan bidang data pada formulir
atau kotak dialog, kedua kolom harus berdekatan. Mereka harus melekat pada masing-masing
lainnya, tidak berlawanan dengan tepi formulir. Sebagai alternatif, label dapat dilampirkan secara langsung
ke bidang datanya dalam baris, dengan spasi dikalibrasi sehingga label dan bidang sejajar.
Di MacOS, Linux / Unix, Web, Anda dapat meratakan label ke kanan untuk diletakkan di dekat
bidang mereka. Pada beberapa platform — seperti Microsoft Windows — konvensi
adalah label rata kiri. Dengan label rata kiri, sangat penting untuk meminimalkan
kesenjangan antara label dan bidang data [Penzo, 2006].

Aturan 2: Jangan biarkan beberapa label panjang mendikte

keselarasan seluruh formulir

Terkadang formulir memiliki satu bidang dengan label yang lebih panjang dari yang lain-
ers. Menyelaraskan semua label dan bidangnya dengan label panjang dan bidangnya terbuang percuma
banyak ruang (Gambar 5.37). Dengan perataan kiri, ini juga menempatkan label yang lebih pendek
terlalu jauh dari ladang mereka.
Salah satu solusinya adalah membungkus label panjang menjadi beberapa baris, seperti yang ditunjukkan oleh a
formulir di [Link] (Gambar 5.38). Solusi lain adalah menyingkat label panjang,
selama itu tidak mengganggu pemahaman atau kemudahan terjemahan.
Jika tidak mungkin membungkus atau menyingkat label panjang dengan cara yang membuatnya
Bagi pengguna, Anda dapat dengan mudah mengatur bidang yang memiliki label panjang secara terpisah
dari yang lain (Gambar 5.39).

Halaman 238

224 Bab 5 Bloopers Desain Grafis dan Tata Letak

Gambar 5.37

[Link] 172/315
26/2/2021 Tanpa judul
Catatan Pasien: Tambahkan Pasien Catatan Pasien: Tambahkan Pasien

Nama: Nama:

Tanggal lahir: Tanggal lahir:

Telepon: Telepon:

Dikurangkan dari Asuransi Kesehatan: Dikurangkan dari Asuransi Kesehatan:

Dokter: Dokter:

baik Membatalkan baik Membatalkan

Masalah label panjang: dengan rata kiri atau kanan, label yang sangat panjang merupakan masalah.

Gambar 5.38

[Link]: label yang panjang dapat dibungkus sehingga label yang lebih pendek tidak terlalu jauh dari bidangnya.

Gambar 5.39
Catatan Pasien: Tambahkan Pasien Catatan Pasien: Tambahkan Pasien

Nama: Nama:

Tanggal lahir: Tanggal lahir:

Telepon: Telepon:

Dikurangkan dari Asuransi Kesehatan: Dikurangkan dari Asuransi Kesehatan:

Dokter: Dokter:

baik Membatalkan baik Membatalkan

Solusi label panjang: sejajarkan label dan bidang yang lebih pendek, dan letakkan label panjang secara terpisah.

Halaman 239

Tata letak dan penempatan jendela yang buruk 225

Gambar 5.40
Ulang: Mingguan Sampai: 21/4/99

Label lebih dekat ke bidang datanya sendiri daripada ke yang lain.

Aturan 3: Label harus lebih dekat dengan bidangnya sendiri

dibandingkan ke bidang lain

Ketika beberapa bidang berlabel diposisikan secara horizontal, kedekatannya harus

menunjukkan pasangan label yang diinginkan dengan bidang. Jarak antar label
dan bidang data yang terkait harus kurang dari jarak antara perbedaan-
pengaturan ent (Gambar 5.40). Ada dua cara untuk melakukannya:

■
Label pengaturan rata kanan. Ini hanya dapat dilakukan pada platform yang hak-
label selaras dapat diterima (mis., MacOS atau Web). Itu tidak layak di bawah
Microsoft Windows, di mana konvensi adalah untuk label pengaturan rata kiri.
■
Sesuaikan lebar label dengan panjang teks. Jika label tidak berubah, tentukan
lebarnya selama desain. Jika label bisa berubah — misalnya, kapan perangkat lunaknya
dilokalkan untuk bahasa lain — posisi label dapat ditentukan
secara otomatis saat instalasi atau runtime.

Aturan 4: Letakkan label di atas bidang

[Link] 173/315
26/2/2021 Tanpa judul
Menempatkan label ini
bidang. Pendekatan tepat di atassemakin
menjadi bidang adalah cara
populer, yang baik
sebagian untuk
karena menyimpan label di sampingnya
berhasil
baik untuk formulir yang tersedia dalam beberapa bahasa. Situs web United Airlines
memberikan contoh (Gambar 5.41).

Gambar 5.41

[Link]: label di atas bidang.

Halaman 240

226 Bab 5 Bloopers Desain Grafis dan Tata Letak

Blooper 37: Penjajaran label tidak konsisten

Saat label ditempatkan di sebelah kiri bidang datanya, label dapat di kiri-
rata atau rata kanan. Kesalahan besar yang sangat umum adalah menyelaraskan label
kontrol atau bidang data tidak konsisten: rata kiri di beberapa tempat, rata kanan-
ment pada orang lain. Contohnya dapat dilihat di dua kotak dialog dari WebMail
aplikasi di University of Canterbury (Gambar 5.42).
Blooper ini bahkan lebih umum di situs Web daripada di aplikasi. Saya t
muncul dalam formulir online di [Link] (Gambar 5.43).

Gambar 5.42

University of Canterbury WebMail: label rata kiri dan kanan dalam aplikasi yang sama.

[Link] 174/315
26/2/2021 Tanpa judul

Halaman 241

Tata letak dan penempatan jendela yang buruk 227

Gambar 5.43

[Link]: label formulir rata kiri dan kanan di situs Web yang sama.

Terkadang Anda menemukan perataan label yang tidak konsisten dalam satu jendela atau Web
halaman. Di kotak dialog Print Microsoft Office untuk Mac (Gambar 5.44), bagian atas
dua bidang data disediakan oleh MacOS, sedangkan bidang lainnya berasal dari Office.
Itu menjelaskan ketidakkonsistenan, tapi bukan alasannya. Ini adalah MacOS
versi Office, jadi seluruh kotak dialog harus menggunakan konvensi MacOS:
perataan kanan.

Gambar 5.44

Microsoft Office untuk MacOS: perataan label tidak konsisten dalam satu kotak dialog.

Halaman 242

228 Bab 5 Bloopers Desain Grafis dan Tata Letak

Menghindari Blooper37

Dalam aplikasi atau rangkaian aplikasi terkait, penyelarasan label

harus konsisten. Beberapa desainer UI merekomendasikan penyelarasan kanan karena
itu menempatkan label dekat dengan pengaturan, membuat hubungan antara label dan mereka
pengaturan mudah dilihat. Desainer lain merekomendasikan perataan kiri, dengan alasan itu
label rata kanan membuat margin kiri tidak rata yang membuat formulir sulit dipindai.
Tidaklah penting dengan siapa Anda setuju. Penting untuk memilih

[Link] 175/315
26/2/2021 Tanpa judul
standar — lebih disukai praktik yang dominan untuk platform target Anda — dan gunakan itu
secara konsisten di seluruh aplikasi, rangkaian aplikasi, atau lini produk Anda. Di
pada platform Microsoft Windows, standar dominan adalah label rata kiri. Di
MacOS, praktik yang dominan adalah meratakannya ke kanan. Di Linux- dan berbasis Unix
platform, tidak ada standar: aplikasi bebas menentukan sendiri. Itu
Web juga tidak memiliki standar untuk pelurusan label; setiap situs membuatnya sendiri.

Blooper 38: Lokasi jendela awal yang buruk

Sebagian besar aplikasi memiliki jendela utama dan sejumlah jendela lainnya. Dimana
haruskah jendela aplikasi ditempatkan? Setelah jendela muncul, pengguna
seharusnya dapat memindahkannya ke mana saja, tetapi di mana harus muncul pertama kali ?
Banyak aplikasi menampilkan jendela di lokasi yang tidak membantu. Blooper ini
memiliki beberapa variasi.

Variasi A: Menampilkan semua jendela pada koordinat yang sama

Bentuk umum dari blooper adalah aplikasi untuk menampilkan semua atau sebagian besar
jendelanya pada posisi layar yang sama. Posisi jendela ditentukan
diposisikan oleh koordinat layar dari sudut kiri atas, jadi jendela posisi
di lokasi yang sama berarti sudut kiri atas mereka bertepatan. Ini mudah
programmer: mereka tidak harus memikirkan ke mana harus pergi setiap jendela.
Namun, ini memaksa pengguna untuk memindahkan jendela agar data penting tetap terlihat.
Kasus khusus adalah ketika program GUI membuka semua jendela baru dalam posisi layar
tion [0, 0], sudut kiri atas layar (Gambar 5.45). Biasanya begitu
lokasi default pengelola jendela jika tidak ada lokasi yang ditentukan. Mengambil
default mudah dari sudut pandang pemrograman, tetapi memberikan kesan kepada pengguna
dari implementasi yang buruk.
Hingga saat ini, Microsoft PowerPoint menampilkan dialog Hyperlink ke Slide
kotak di atas kotak dialog Pengaturan Tindakan induknya (Gambar 5.46). Ini, plus
tata letak kotak dialog, menyebabkan kebingungan tentang tombol "OK" / "Batal" yang mana
klik, seperti yang dijelaskan rekan kerja:

Saya selalu mengklik tombol OK yang salah. Meskipun saya sering melakukan ini, katakan 30
kali dalam 3 menit, saya tidak dilatih sampai ke-25 kalinya atau lebih. Dan jika saya lakukan
lagi setelah selang waktu 5–10 menit, saya lupa dan langsung kembali mengklik
tombol yang salah.

Halaman 243

Tata letak dan penempatan jendela yang buruk 229

Gambar 5.45

Jendela 4

Jendela 3

Jendela 2

Jendela 1

Layar

Blooper: semua jendela aplikasi terbuka pada posisi [0, 0].

Gambar 5.46

[Link] 176/315
26/2/2021 Tanpa judul
PowerPoint: Kotak dialog Pengaturan Tindakan Hyperlink membuka kotak dialog Hyperlink ke Slide di
posisi teratas yang sama, membingungkan pengguna tentang tombol "OK" / "Batal" mana yang harus diklik
selesai dengan kotak dialog kedua.

Variasi B: Menampilkan jendela subordinate dalam

tengah orang tua

Strategi lain adalah dengan memusatkan setiap jendela anak di atas jendela induknya.
Memusatkan satu jendela ke jendela lainnya hanya membutuhkan sedikit lebih banyak perhitungan daripada
menempatkan sudut kiri atas di tempat yang sama. 2

2. Rumus untuk menghitung koordinat jendela yang akan dipusatkan (Jendela Baru) adalah:

NewWindow.x = ParentWindow.x + ([Link] - [Link]) / 2,

NewWindow.y = ParentWindow.y + ([Link] - [Link]) / 2.

Halaman 244

230 Bab 5 Bloopers Desain Grafis dan Tata Letak

Gambar 5.47

Perencana Perjalanan National Geographic: legenda peta terbuka di atas peta, membuat pengguna memindahkannya.

Memusatkan jendela anak di atas orang tuanya memiliki masalah yang sama dengan membuka
semua jendela di [0, 0]: semuanya muncul di atas satu sama lain. Namun, sebagian besar aplikasi
tions memiliki hierarki jendela: beberapa jendela dapat menampilkan win-
dows. Mendistribusikan lokasi awal jendela anak ke beberapa induk
windows mengurangi sedikit masalah "semua di atas satu sama lain", tetapi beberapa
masalah tetap:

1. Semua jendela anak dari jendela induk tertentu masih terbuka satu sama lain.
Untuk jendela induk dengan banyak jendela anak, kita kembali ke "semua di atas
masalah satu sama lain.
2. Jendela anak yang terbuka di atas orang tuanya mungkin mencakup konten penting
di orang tua. National Geographic Trip Planner melakukan ini: Map Legend-nya
jendela menutupi peta (Gambar 5.47).
3. Terkadang jendela anak lebih besar dari orang tuanya. Dalam kasus seperti itu, par-
ent benar-benar tersembunyi saat anak itu muncul. Pengguna mungkin lupa itu ada.
4. Pada sebagian besar platform GUI, aplikasi dapat menampilkan jendela bawahan
baik sebagai jendela "eksternal", yang berada di luar jendela induk, atau sebagai "antar-
nal ”, yang berada di dalam jendela induknya. Ketika jendela anak
berpusat langsung di atas induknya dan lebih kecil dari induknya, pengguna tidak bisa
beri tahu (tanpa mencoba memindahkannya) apakah itu eksternal atau internal.

Karena masalah ini, aplikasi yang menampilkan semua jendela bawahan

berpusat pada orang tua mereka melakukan variasi Blooper 35.

Variasi C: Menampilkan jendela subordinate

rahasia

Lokasi jendela awal yang paling tidak disukai oleh pengguna adalah di luar layar, jadi pengguna
bahkan tidak akan tahu mereka ada di sana. Beberapa aplikasi benar-benar melakukan ini!

Halaman 245
[Link] 177/315
26/2/2021 Tanpa judul

Tata letak dan penempatan jendela yang buruk 231

Satu perusahaan memiliki alat investasi saham yang menampilkan Monitor Perdagangan
Kotak dialog ringkasan tepat di atas jendela utama. Jika kemenangan utama-
dow dimaksimalkan atau ditempatkan di bagian atas layar, kotak dialog terbuka
di bagian atas layar — tidak terlihat. Pengguna baru sering mengeluhkan hal itu
kotak dialog Trade Monitor Summary tidak ditampilkan. Sebagai tanggapan,
pengembang menarik jendela utama ke bawah untuk menunjukkan bahwa Monitor Perdagangan
Kotak dialog ringkasan ada di sana ... di luar layar. Para pengguna bodoh itu ...
selalu mengeluh!
Aplikasi perusahaan lain terkadang menampilkan jendela sebagian mati-
layar, seperti yang dijelaskan dalam kutipan ini dari tinjauan UI produk:

Kotak dialog yang terbuka dari jendela utama muncul dengan kiri atasnya
sudut berpusat di atasnya. Karena jendela utama berukuran kecil, jika berada di tepi
layar, kotak dialog besar muncul sebagian di luar layar.

Menghindari Blooper 38

Panduan berikut akan membantu Anda menghindari tumpukan jendela di atasnya

lain.

Tentukan di mana setiap jendela muncul

Seseorang harus memutuskan di mana setiap jendela baru akan muncul pada awalnya. Jangan
melepaskan tanggung jawab ini dengan menggunakan aturan penempatan yang sederhana, seperti open-
ing semua jendela pada posisi layar [0, 0].

Posisi optimal tergantung pada jenis jendela

Sebagian besar aplikasi perangkat lunak menampilkan berbagai jenis jendela: win-
dows, jendela utama bawahan, kotak dialog properti objek, perintah
kotak dialog, kotak dialog kesalahan, kotak dialog peringatan, dialog konfirmasi
kotak, dan sebagainya. Posisi awal terbaik dari sebuah jendela bergantung setidaknya sebagian
pada jenis jendelanya.
Kesalahan, peringatan, dan kotak dialog konfirmasi akan muncul menonjol
lokasi, untuk menarik perhatian pengguna. Posisi terbaik untuk itu adalah ke tengah
jendela di posisi kursor. Hampir sama baiknya dengan menampilkan dialog
kotak di dekat perintah yang memunculkan pesan tersebut. Jika tidak, gunakan
tengah layar. Kotak dialog properti objek akan muncul di dekat file
objek yang mereka wakili.
Jendela utama dan jendela utama bawahan dapat muncul hampir
di mana saja di layar pada awalnya, selama tidak semuanya muncul di tempat yang sama.
Ketika pengguna memindahkan jendela ke lokasi baru, perangkat lunak harus ingat
lokasi itu dan menampilkan jendela itu di tempat yang sama di lain waktu.

Halaman 246

232 Bab 5 Bloopers Desain Grafis dan Tata Letak

Heuristik umum

Di luar aturan desain penempatan yang bergantung pada jenis jendela, di sini
adalah aturan untuk semua jendela:

■
Windows harus selalu terbuka sepenuhnya di layar. Jika perlu, sesuaikan
posisi jendela yang relatif terhadap lokasi objek lain, seperti
kursor atau perintah atau data yang sesuai.
■
Atur posisi jendela berurutan dengan jenis yang sama Masing-masing muncul
sedikit lebih jauh ke kanan dan ke bawah dari yang terakhir.
■
Jendela anak eksternal seharusnya hanya sebagian tumpang tindih dengan induknya sehingga pengguna bisa
pastikan bahwa mereka tidak bersifat internal bagi orang tua.
■
Pastikan jendela anak tidak mencakup informasi penting di orang tua mereka.
Misalnya, kotak dialog Temukan / Ganti Microsoft Word selalu ditempatkan demikian
bahwa teks yang ditemukan di dokumen terlihat.

[Link] 178/315
26/2/2021 Tanpa judul
■
Jangan letakkan jendela tepat di atas satu sama lain. Bahkan jendela acak
penempatan lebih baik daripada selalu menggunakan lokasi [0, 0].

Tipografi yang merepotkan

Desain grafis dan tata letak blooper terakhir menyangkut tipografi.

Blooper 39: Font kecil

Banyak aplikasi perangkat lunak dan situs Web menampilkan teks dalam ukuran font yang sesuai
terlalu kecil. Masalah utama dengan teks dalam font kecil adalah orang yang memiliki
gangguan penglihatan tidak bisa membacanya. Itu mencakup hampir semua orang yang berusia di atas 45 tahun.
Pikirkan perusahaan startup yang dipenuhi dengan pengembang berusia dua puluh tahun
visi luar biasa yang menghasilkan situs Web investasi untuk orang-orang yang mendekat
pensiun, dan Anda akan mulai memahami masalahnya.
Bilah navigasi di situs web Federal Reserve Bank of
Minneapolis diberi label dengan font yang sangat kecil — mungkin 8 poin 3 (Gambar 5.48).
Selanjutnya, ini ditampilkan sebagai gambar, sehingga pengguna tidak dapat menyesuaikan ukuran fontnya
di browser mereka. Banyak pengguna akan kesulitan membaca bilah.
Font yang lebih kecil digunakan pada peta rute online Frontier Airlines (Gambar
5.49). Sekali lagi, peta ini adalah gambar, jadi pengguna tidak dapat menyesuaikan ukuran font. Jika mereka
tidak bisa membaca nama kota atau teks di bawah peta, mereka kurang beruntung… atau
mungkin Frontier Airlines.

3. Gambar layar di bagian ini ditampilkan dalam ukuran penuh; mereka belum menyusut untuk buku ini.

Halaman 247

Tipografi yang merepotkan 233

Gambar 5.48 [Link]: font kecil yang tidak dapat disesuaikan di bilah navigasi.

Pelabuhan
Gambar 5.49

Calgary

Seatte / Tacoma Spokane

Portland Boise
Billings

Minneapolis / St. Paul

Milwaukee
Detroit
Salt Lake City

New York
Reno / Tahoe Chicago
Akron (Cleveland) Philadelphia
Omaha Indianapolis
Sacramento Dayton
Denver Baltimore
San Fransisco San Jose
Washington DC
St. Louis
Fresno Kota Kansas

Las Vegas
Nashville
Los Angeles
Orange County San Diego
Albuquerque
Tulsa
Phoenix
kota Oklahoma Atlanta
Tucson
EI Paso Batu kecil
Dallas / Fort Worth

Austin
Houston
San Antonlo Tampa Orlando

Ft. Myers Ft. Lauderdale

Mazatlan
Cabo San Lucas Cancun

Cozumel
Penerbangan Frontier Airlines, Inc.
Puerto Vallarta Guadalajara
Penerbangan Frontier JetExpress
dioperasikan oleh Horizon Air.
Ixtapa / Zihuatanejo
Frontier Airlines, Inc. dan Frontier
Acapulco
JetExpress dioperasikan oleh Horizon Air.
Layanan Domestik
Layanan Internasional Berdasarkan jadwal November 2006.
San Francisco ke Las Vegas dimulai 12/14/06.
Layanan musiman ke Anchorage dilanjutkan 5/5/07.
San Diego ke Cancun dan Kansas City ke Cabo San Lucas mulai 12/16/06.
San Francisco - Los Angeles ke Cabo dimulai 12/09/06.
Denver ke Guadalajara mulai 12/22/06.
Semua menunggu persetujuan pemerintah.
Layanan musiman ke Acapulco dilanjutkan 12/20/06 dan Ixtapa / Zihuatanejo dilanjutkan 11/18/06.
Rute dapat berubah tanpa pemberitahuan.

[Link]: font kecil dan tidak bisa disesuaikan.

[Link] 179/315
26/2/2021 Tanpa judul
Ini bukan hanya masalah Web
Kutipan dari ulasan kegunaan menunjukkan bahwa font kecil muncul di aplikasi desktop
serta situs web:

■
Sebagian besar font dalam aplikasi terlalu kecil dan tidak dapat disesuaikan (bahkan
lebih kecil dari produk saat ini, yang sudah berbatasan dengan keberadaan

Halaman 248

234 Bab 5 Bloopers Desain Grafis dan Tata Letak

terlalu kecil). Anda membuat font lebih kecil agar lebih pas, tetapi lebih pas
tidak berguna jika orang tidak bisa membaca teks.
■
Font teks default perangkat lunak terlalu kecil untuk pengguna berusia di atas 45 tahun
bisa membaca dengan nyaman. Pertimbangkan untuk mengubah ke font default yang lebih besar, dan
pastinya memudahkan pengguna untuk memperbesar ukuran font.
■
Label pada tombol papan angka terlalu kecil. Banyak pengguna tidak mau
dapat membaca label ini dengan nyaman. Ada banyak ruang di kunci
untuk label yang lebih besar.

Alasan umum untuk font kecil

Pengembang memiliki banyak alasan untuk menggunakan font kecil. Berikut ini contoh, dengan
tanggapan yang sesuai:

■
“Saya bisa membacanya. Apa masalahnya? ”- Masalahnya adalah pengguna tidak dapat membacanya.
■
“Kami membutuhkan semua informasi ini di sini.” - Jika pengguna tidak dapat membacanya, sebenarnya tidak
disana, apakah itu?
■
“Saya baru saja menggunakan ukuran font default toolkit.” Jangan gunakan default, atau ubah
default ke font yang lebih besar.
■
"Ini bukan salahku: teksnya ada dalam gambar." - Kirim gambar kembali ke
artis dan minta mereka untuk memperbesar teks pada gambar. Lebih baik: tanyakan pada mereka
untuk mengirimi Anda teks secara terpisah daripada menyematkannya di gambar.
Tampilkan teks di atas gambar dan izinkan pengguna menyesuaikan ukurannya.
■
"Ini cukup besar dalam resolusi rendah." - Berapa persen pelanggan menggunakan
monitor resolusi? Tanpa mengetahui itu, alasan itu tidak berdasar.

Memo dari Bos Besar

Memo
Dari: Bos Besar
Kepada: Semua karyawan
Subjek: Ukuran font
Tanggal: 1 April 2009

Efektif segera, semua karyawan diminta untuk menggunakan font teks terkecil
tersedia di semua dokumen. Departemen MIS telah memberi tahu saya bahwa file server kami-
ers semakin kenyang. Mereka meminta saya mengalokasikan dana untuk membeli lebih banyak disk drive,
tetapi permintaan itu datang pada saat kita perlu menghemat biaya. Itu terjadi
bagi saya bahwa dengan menggunakan font yang lebih kecil, kami dapat menghemat banyak ruang disk, mengurangi file
kebutuhan untuk drive disk tambahan.
Dengan semua kerja sama Anda, kita akan sukses di Kuartal ke-2.
Terima kasih.

Halaman 249

Tipografi yang merepotkan 235

[Link] 180/315
26/2/2021 Tanpa judul
Menghindari Blooper 39
Anda ingin pengguna perangkat lunak Anda dapat membaca teks. Pengikut
pedoman akan membantu Anda memastikan bahwa mereka bisa.

Faktor yang mempengaruhi ukuran teks

Dua faktor yang memengaruhi ukuran absolut teks yang ditampilkan di layar komputer:

■
Resolusi layar: resolusi maksimum yang mampu dilakukan oleh sebuah layar dan
pengaturan resolusi dalam sistem operasi pengguna, misalnya 800 × 600, 1024
× 768, 1280 × 854. Semakin tinggi resolusinya, semakin kecil teks a
ukuran font yang diberikan muncul.
■ Ukuran layar: jika layar 15 inci dan layar 24 inci disetel sama
resolusi (mis., 1024 × 768), teks 12-titik akan tampak lebih besar pada yang lebih besar
layar.

Selain itu, ukuran teks yang terlihat tergantung pada jarak pandang pengguna.
Teks yang cukup besar untuk seseorang yang bekerja di PC kantor mungkin terlalu kecil
untuk pengguna yang melihat tampilan status yang dipasang di dinding.
Poin utamanya adalah bahwa desainer tidak memiliki kendali penuh atas seberapa besar atau
teks kecil terlihat bagi pengguna. Tantangannya adalah memastikan bahwa semua orang yang Anda inginkan
membaca teks bisa.

Ukuran poin font minimum adalah 10; 12 lebih baik

Jangan pernah menggunakan font layar yang lebih kecil dari 10 poin. Pernah. Sepuluh poin harus menjadi
minimum. Bahkan 10 poin adalah batas. Pada resolusi layar tinggi (di atas
1000 × 700), 10 poin mungkin terlalu kecil. Agar aman, gunakan 12 poin
font.

Pilih ukuran font yang sesuai untuk tampilan resolusi tinggi

Jika desainer membuat font di aplikasi atau situs Web mereka cukup besar
terbaca oleh pengguna yang dituju ketika pada resolusi layar tertinggi, akan ada
tidak ada masalah pada resolusi yang lebih rendah.

Izinkan pengguna menyesuaikan ukuran font

Ukuran font harus disesuaikan oleh pengguna. Ini berlaku untuk teks konten dan
ke teks yang merupakan bagian dari GUI.
Menyediakan ukuran font yang dapat disesuaikan dalam aplikasi desktop biasanya membutuhkan
kerja. Namun, ada pengguna, mungkin di pasar sasaran Anda, yang tidak bisa
lihat teks yang lebih kecil dari 24 poin. Anda bisa membuat semua teks menjadi 24 poin,

Halaman 250

236 Bab 5 Bloopers Desain Grafis dan Tata Letak

atau Anda dapat memiliki teks default ke 12 poin untuk sebagian besar pengguna dan biarkan mereka yang
perlu teks yang lebih besar, sesuaikan. Jika Anda tidak melakukannya, Anda kehilangan pelanggan.

Kontrol font di Web: serahkan kepada pengguna

Ukuran font yang dapat disesuaikan pengguna jauh lebih mudah dilakukan di Web daripada di
perangkat lunak desktop. Semua pengembang Web harus lakukan adalah tidak menentukan ukuran font atau
tentukan dalam unit relatif (mis., 1,5 em) daripada unit absolut (mis., 18 pt).
Di Web, Anda harus melakukan lebih banyak pekerjaan untuk melakukan blooper daripada melakukan
hal yang benar. Di Web, tidak ada alasan untuk font yang tidak bisa disesuaikan.
Dalam buku Web Pages That Suck [Flanders dan Willis, 1998], penulis bersama
Vincent Flanders mengoceh tentang pengembang Web yang membuat kode keras untuk ukuran font
halaman, mencegah pengguna menyesuaikan ukuran:

Ada banyak hal yang tidak saya mengerti: teori atom, Eksistensialisme,…
dan mengapa desainer Web menggunakan tag <FONT> dan argumen WAJAH untuk membuatnya
halaman yang tidak dapat dibaca. … Memang, saya berusia 49 tahun dan memiliki penglihatan yang buruk, tapi tetap saja
kawan-kawan… jika teksnya terlalu sulit untuk dibaca oleh kebanyakan orang, mereka akan berhasil
tombol Kembali lebih cepat dari Larry King menikah.

Kata-kata kasar Flanders bahkan lebih tepat sekarang daripada saat dia menulisnya,
karena cascading style sheets (CSS) telah menggantikan HTML presentasi sebagai
cara terbaik untuk mengatur gaya teks di situs Web dan aplikasi berbasis browser. CSS

[Link] 181/315
26/2/2021 Tanpa judul
memudahkan pengembang Web untuk menentukan ukuran font secara relatif, bukan
absolut, unit.

Desain untuk mengakomodasi font yang lebih besar

Tidak ada gunanya mengizinkan pengguna menyesuaikan aplikasi atau ukuran font situs Web
jika tata letak rusak saat pengguna benar - benar memperbesar font. Pencarian penerbangan
hasil di [Link] ditampilkan dalam font kecil, tetapi jika pengguna bertambah
ukuran font, tata letak tabel berantakan (Gambar 5.50).

Uji pada pengguna

Baik Anda mengembangkan perangkat lunak untuk Web, PC, atau peralatan konsumen,
uji ukuran font Anda! Pada pengguna nyata, tidak hanya pada pengembang berusia dua puluhan
di bilik berikutnya. Lebih disukai sebelum rilis.

Halaman 251

Tipografi yang merepotkan 237

Gambar 5.50

[Link]: hasil pencarian penerbangan. (A) Pada ukuran font default. (B) Pada ukuran font yang lebih besar.

[Link] 182/315
26/2/2021 Tanpa judul

Halaman 252

238 Bab 5 Bloopers Desain Grafis dan Tata Letak

Atas kebaikan Jen Sorensen, [Link] © 2004.

Halaman 253

[Link] 183/315
26/2/2021 Tanpa judul

Interaksi
Bloopers
pengantar

Menyimpang dari fokus tugas

Membutuhkan langkah-langkah yang tidak perlu

Membebani memori pengguna

Mengambil kendali dari pengguna

239

Halaman 254

240 Bab 6 Interaksi Bloopers

pengantar

Bloopers yang dibahas di bab sebelumnya — Kontrol GUI, navigasi, tekstual,

serta desain dan tata letak grafis — cukup mudah dikenali dalam ulasan kegunaan dan
tes.
Namun, ada gunanya untuk menggali lebih dalam: lebih banyak blooper terletak di bawah permukaan. Beberapa
memperhatikan seberapa baik aplikasi mendukung tugas, bukan hanya seberapa baik khususnya
jendela atau halaman dirancang. Yang lain memperhatikan bagaimana desain UI berinteraksi
persepsi dan kognisi manusia.
Ini adalah kesalahan besar "interaksi". Bloopers yang lebih dalam ini bukanlah biola-
panduan tampilan-dan-nuansa, melainkan pelanggaran desain UI dasar
prinsip. Prinsip-prinsip tersebut muncul dari penelitian tentang kinerja manusia.
persepsi, membaca, pemrosesan informasi, pemecahan masalah, dan motivasi
tion, serta dari pengalaman puluhan tahun dengan komputer interaktif
aplikasi.
Blooper interaksi lebih penting daripada kontrol GUI, navigasi,
tekstual, dan desain grafis dan tata letak bloopers karena:

■ Mereka lebih besar cakupannya. Blooper interaksi sering kali merupakan generalisasi
blooper tampilan dan nuansa yang lebih spesifik. Misalnya, Blooper 26 (Speaking
Geek, halaman 173) hanyalah salah satu masalah yang disebabkan oleh Blooper 40, eksposur-
menerapkan implementasinya kepada pengguna (di bawah). Oleh karena itu, mengenali dan
menghilangkan kesalahan interaksi tunggal dapat mengakibatkan koreksi
puluhan kontrol GUI, navigasi, tekstual, dan desain dan tata letak grafis
bloopers.
■
Mereka lebih sulit untuk diidentifikasi. Blooper interaksi biasanya tidak secara langsung
ible dalam tampilan perangkat lunak. Untuk menemukannya, Anda harus mengetahui desain dasarnya
aturan. Pengamat yang kurang berpengalaman cenderung fokus pada konkret dan terlihat
masalah kegunaan, seringkali kehilangan yang lebih dalam.

[Link] 184/315
26/2/2021 Tanpa judul
■
Mereka lebih sulit untuk dihindari. Blooper interaksi sering kali merupakan hasil dari keputusan
yang dibuat jauh di dalam implementasi produk atau bahkan di plat-
bentuk dan lingkungan: perangkat GUI, sistem operasi, atau komunikasi
jaringan tion. Jika blooper dibangun ke dalam toolkit GUI dan aplikasi
programmer kekurangan waktu atau keahlian untuk membuat kode di sekitarnya, blooper
akan ada di aplikasi. Bahkan saat kesalahan interaksi sepenuhnya bersifat lokal
untuk aplikasi, itu mungkin hasil dari trade-off desain atau pelanggan
permintaan.
■
Mereka lebih sulit untuk diperbaiki. Mengoreksi kesalahan interaksi dapat berarti
memperbaiki semua blooper tampilan dan nuansa yang dihasilkan lebih spesifik. Jika
interaksi blooper hasil dari keputusan implementasi yang dalam, memperbaikinya
dapat memerlukan implementasi ulang yang ekstensif kecuali ditemukan sangat awal
pengembangan.

Halaman 255

Menyimpang dari fokus tugas 241

Menyimpang dari fokus tugas

Tiga blooper interaksi pertama menyangkut antarmuka pengguna yang buruk

difokuskan pada tugas-tugas yang dimaksudkan untuk didukung oleh perangkat lunak. Beberapa UI tidak perlu
mengekspos implementasi, memaksakan batasan yang tidak perlu, atau kendala saat ini
konsep yang dapat digabungkan, mengalihkan pengguna dari tujuan mereka dan menghambat pembelajaran mereka
dari perangkat lunak.

Blooper 40: Mengekspos implementasi kepada pengguna

Pengembang terkadang mengizinkan implementasi aplikasi — pekerjaan dalamnya-

ings — untuk "bocor" ke antarmuka pengguna. Seringkali masalahnya hanya pada UI
mengekspos persyaratan implementasi kepada pengguna (Blooper 26, halaman 173). Namun, beberapa
aplikasi memaparkan tidak hanya istilah, tetapi struktur internal dan konsep yang ada
tidak terkait dengan tugas dan tujuan pengguna.
Contoh diberikan oleh grafik dari aplikasi yang dikembangkan oleh a
perusahaan perangkat lunak (Gambar 6.1). Sumbu horizontal grafik memiliki inter-
vals — 1.0, 105.4, 209.8, dll — daripada interval yang lebih alami
lebih masuk akal bagi pengguna — misalnya, 0, 100, 200, 300, dll. Pengembang dipertahankan
desain, dengan alasan bahwa lebih mudah bagi mereka untuk membuat kode grafik dengan membagi
panjang plot terpanjang sebesar 10 dan membiarkan intervalnya jatuh di mana pun mereka
melakukan. Mereka membiarkan implementasinya bocor ke GUI, merusak
kegunaan.

Gambar 6.1 100.0

90.0

80.0

70.0

60.0

50.0

40.0

30.0

20.0

10.0

0.0

1.0 105.4 209.8 314.2 418.6 523.0 627.4 731.8 836.2 940.6 1045.0

Interval horizontal grafik dirancang untuk kenyamanan pemrogram, bukan pengguna.

[Link] 185/315
26/2/2021 Tanpa judul
Halaman 256

242 Bab 6 Interaksi Bloopers

Memaksa pengguna untuk berpikir seperti seorang programmer

Satu prototipe aplikasi Web memiliki kotak dialog untuk setiap fungsi. Satu tetes-
pengaturan menu bawah muncul di beberapa kotak dialog. Mengubahnya dalam satu dialog
kotak mengubahnya di tempat lain juga. Pengguna biasanya mengharapkan menu tetap seperti
mereka disetel saat terakhir kali pengguna menggunakan kotak dialog itu, tetapi dalam situasi tertentu
setelan yang berubah di mana saja mungkin masuk akal bagi pengguna.
Ketika diminta untuk menjelaskan mengapa menu itu bekerja seperti itu, programmer itu berkata
dia memutuskan bahwa tidak efisien untuk meletakkan salinan menu di setiap tempat
dibutuhkan, jadi dia menulis kodenya sehingga hanya ada satu menu, yang muncul di
banyak kotak dialog. Seorang pengguna jawaban -centered akan menjelaskan bahwa studi
telah menunjukkan bahwa pengguna mengharapkan menu berubah di mana saja saat mereka berubah
itu di satu tempat.
Pemrogram membuat keputusan, murni berdasarkan pertimbangan implementasi
tions, yang mengakibatkan perilaku yang mungkin tidak sesuai dengan harapan pengguna. Itu
programmer mengekspos implementasinya kepada pengguna.

Menghindari Blooper 40

Fokuskan antarmuka pengguna hanya pada tugas

Rancang antarmuka pengguna aplikasi Anda sesuai dengan model konseptual itu
hanya menyertakan objek, tindakan, dan atribut dari tugas target aplikasi
(Prinsip Dasar 2, halaman 18). Waspadai konsep asing yang merayap ke
UI. Buat, pertahankan, dan terapkan leksikon produk untuk mengungkap perbedaan
antara UI dan model konseptual.

Desain untuk kenyamanan pengguna, bukan pengembang

Buat komitmen yang kuat untuk merancang antarmuka pengguna demi kenyamanan
dari pengguna, bukan programmer. Pengembang cenderung mendesain untuk kon-
venience. Apa yang membedakan desainer dan pengembang UI luar biasa dari kebanyakan
adalah komitmen untuk mengatasi kecenderungan itu — mengutamakan persyaratan pengguna.
Manajemen tentu saja dapat membantu.

Blooper 41: Pembatasan yang tidak perlu

Perangkat lunak dapat melanggar rasa kealamian dan intuisi pengguna dengan memaksakan
batasan yang sewenang-wenang dan tidak perlu. Pembatasan yang tidak perlu, seperti tindakan yang tidak wajar
sulit dipelajari, mudah lupa, dan mengganggu (Prinsip Dasar 3, halaman 26).
Ketika stereo saya rusak, saya membawanya ke bengkel. Teknisi bengkel mengisi
formulir pesanan perbaikan, menggunakan komputer. Setelah mengetik informasi kontak saya dan
merek dan model stereo, dia meminta saya untuk menjelaskan masalahnya. Saat saya berbicara
dan dia mengetik, ekspresi khawatir muncul di wajahnya. Dia menyela saya:

Halaman 257

Menyimpang dari fokus tugas 243

Teknisi: “Um… bisakah Anda menjelaskan masalahnya… lebih pendek?”

Saya: “Biar saya tebak: Anda memiliki 64 karakter untuk menjelaskan apa yang salah
dengan stereo saya. "

Teknisi (mata terlihat melebar): “Tiga puluh dua, tapi bagaimana kabarmu
tahu?"

Deskripsi perangkat lunak bengkel terbatas hingga 32 karakter. Batasannya adalah

mungkin dipaksakan oleh database aplikasi yang digunakan. Apapun alasannya
batasnya, itu membuat penggambaran masalah stereo lebih sulit.
Aplikasi perangkat lunak, layanan online, dan peralatan penuh dengan batasan seperti itu-
tions: bidang kartu kredit yang tidak membolehkan spasi, nama login dibatasi hingga delapan
karakter, bidang nama perusahaan yang hanya mengizinkan huruf atau angka ("AT&T"
ditolak), spreadsheet yang dapat memiliki
hanya 256 kolom, pengenal data itu

[Link] 186/315
26/2/2021 Tanpa judul
harus
[Link]
Semuadalam UPPERCASE
contoh ini adalah untuk menjadi
nyata.
Sejak diperkenalkan di
pertengahan 1980-an, Microsoft Excel telah membatasi
ited spreadsheet menjadi 256 kolom.
Pada 1980-an, batasan itu diberlakukan
oleh memori pribadi yang terbatas
komputer. PC hari ini memiliki tentang
500.000 kali lebih banyak memori
tahun 1980-an, jadi Excel 256-
batas kolom adalah buatan dan tidak
essary. Untuk membuat spreadsheet ke
mencatat harga saham setiap hari selama a
tahun, akan wajar untuk menetapkan a
kolom untuk setiap hari. Tidak ada yang bisa dilakukan dengan
Excel: Anda kehabisan kolom
13 September (Gambar 6.2).
Excel memiliki gangguan kedua
pembatasan: pengguna tidak dapat membuka dua
Diterbitkan ulang atas izin, Andrew Toos.
file spreadsheet yang sama
nama (Gambar 6.3). Jika Anda memiliki file
cadangan spreadsheet di tempat lain
folder, Anda tidak dapat membukanya dan yang asli secara bersamaan untuk membandingkannya.
Microsoft Word tidak memiliki batasan seperti itu.
Contoh terakhir kami tentang pembatasan yang menjengkelkan adalah dari DVD Apple Macintosh
pemain. DVD diberi kode untuk wilayah dunia tempat pembuatannya. Untuk
memutar DVD, drive DVD Mac harus diatur ke kode wilayah yang sama dengan
DVD. Sangat menjengkelkan bahwa pengguna harus menyetel ini; pemain harus mengatur dirinya sendiri.
Tapi itu kecil dibandingkan dengan masalah kode wilayah drive DVD

Halaman 258

244 Bab 6 Interaksi Bloopers

Gambar 6.2

Microsoft Excel: Batas 256 kolom adalah buatan dan mencegah pembuatan spreadsheet yang berguna.

Gambar 6.3

Microsoft Excel: memblokir membuka dua file dengan nama yang sama.

dapat diubah hanya lima kali selama masa pakai drive (Gbr 6.4). Setelah
lima perubahan, pengaturan wilayah menjadi permanen. Hah? Orang yang bepergian
antar wilayah tidak dapat memutar DVD lokal?

Beberapa batasan lebih buruk dari yang lain

Pembatasan terburuk adalah yang terus-menerus ditemui pengguna, seperti

deskripsi yang harus lebih pendek dari 32 karakter. Batasan seperti itu memaksa pengguna—
berulang kali — untuk membuang waktu memikirkan cara mengungkapkan apa yang mereka butuhkan
ekspresikan dalam batas.
Batasan yang hanya sesekali dicapai pengguna mungkin tampak tidak terlalu merepotkan. Faktanya,
hampir seburuk batas yang sering dicapai pengguna, tetapi karena alasan yang berbeda:

[Link] 187/315
26/2/2021 Tanpa judul
pengguna yang mengalami batasan seperti itu tidak akan memiliki banyak pengalaman untuk mencari tahu caranya
untuk mengatasi mereka.

Memberlakukan batasan yang merupakan kekuatan 2: Kutu buku

Batasan numerik yang diberlakukan oleh perangkat lunak komputer seringkali menjadi kekuatannya
2: angka seperti 8, 16, 32, 64,…, 1024. Komputer mewakili angka dan

Halaman 259

Menyimpang dari fokus tugas 245

Gambar 6.4

Pemutar DVD Macintosh (OS X): kode wilayah hanya dapat diubah lima kali.

alamat memori dalam angka biner (basis 2), jadi programmer terbiasa
bilangan biner dan menganggapnya sebagai "normal".
Sebagian besar pengguna perangkat lunak tidak melihat kekuatan 2 sebagai "normal". Mereka belajar melakukan
aritmatika dalam basis 10 dan digunakan untuk pangkat 10. Bagi mereka, bilangan biner
sewenang-wenang dan culun.

Intinya

Produk dengan banyak batasan arbitrer tidak akan memuaskan pengguna. Banyak
pembatasan perangkat lunak disebabkan oleh prioritas yang salah dari pengembang (termasuk-
ing manajemen). Pengembang sering tidak menyadari berapa jam pengguna bisa
diselamatkan oleh satu jam programmer ekstra yang dihabiskan untuk mengatasi gangguan
larangan.
Pertimbangkan total waktu yang terbuang di seluruh dunia antara tahun 1975 (bila bersifat pribadi
komputer pertama kali memasuki pasar) dan 1995 (ketika Windows 95 dirilis) oleh
jutaan pengguna komputer mencoba membuat nama file yang bermakna tidak lagi
dari delapan karakter. Kesalahan besar itu menghabiskan jutaan jam pengguna.

Menghindari Blooper 41

Jangan memaksakan batasan numerik, jika memungkinkan. Anda dapat menghilangkannya dengan mengalokasikan-
menyimpan penyimpanan data secara dinamis pada waktu proses, sesuai kebutuhan, bukan secara statis di
Kode sumber. Jika batasan tidak dapat dihindari, buat batasan tersebut sangat tinggi sehingga pengguna jarang melakukannya
atau tidak pernah bertemu mereka.
Ketika batasan tidak dapat dihindari dan pengguna akan menemukannya, gunakan kekuatan
dari 10, bukan kekuatan 2. Meskipun batas adalah kekuatan 2, Anda dapat memberi tahu pengguna
mereka adalah kekuatan 10, seperti yang dilakukan MacOS untuk opsi warna-tinggi pada Warna-warnanya
menu (Gambar 6.5).

Halaman 260

246 Bab 6 Interaksi Bloopers

[Link] 188/315
26/2/2021 Tanpa judul
Gambar 6.5

MacOS X: opsi "jumlah warna" yang lebih tinggi dinyatakan sebagai pangkat 10.

Blooper 42: Konsep yang membingungkan

Semua aplikasi perangkat lunak menampilkan model konseptual (Prinsip Dasar 2, halaman 18).
Model terdiri dari objek yang dibuat dan dimanipulasi pengguna, tindakan pengguna
tampil pada objek, dan atribut objek yang terlihat oleh pengguna. Dari konseptual
model yang disajikan dalam UI dan manual aplikasi, pengguna membentuk model mental
tentang cara kerja aplikasi. Model mental mereka membantu mereka mengoperasikannya. Kompleks
dan model konseptual yang membingungkan menimbulkan model mental yang membingungkan.
Salah satu cara model konseptual aplikasi dapat membingungkan adalah dengan memasukkan
konsep yang tumpang tindih dalam arti atau fungsionalitas.
Situs web dukungan pelanggan satu perusahaan menyajikan empat konsep bahwa
menurut pengembang cukup berbeda:

■
Keanggotaan: apakah perusahaan telah membayar layanan dukungan pelanggan
■
Langganan: apakah perusahaan telah berlangganan dukungan pelanggan
buletin
■
Akses: area mana dari pengguna situs Web dukungan pelanggan di sebuah perusahaan
dapat mengakses
■
Hak: layanan yang disediakan untuk setiap tingkat keanggotaan

Pengguna bingung keempat konsep ini. Mereka perlu digabung menjadi satu konsep
atau, setidaknya, kurang dari empat.
Perusahaan lain mengembangkan situs Web untuk orang yang ingin membeli rumah.
Ada dua cara untuk mencari rumah: (a) sebutkan negara bagian, kabupaten, atau kota atau
(b) menunjuk ke suatu lokasi di peta. Pengguna harus memilih apakah mereka mau
temukan rumah "menurut lokasi" atau "menurut peta". Tes kegunaan menemukan yang berikut:

Banyak pengguna tidak membedakan antara menemukan rumah "menurut peta" vs. "menurut lokasi".
Keduanya benar-benar berdasarkan lokasi; mereka hanya berbeda dalam cara menentukan lokasi.

Desainer situs ini membuat perbedaan buatan, mengharapkan pengguna untuk melakukannya
mengerti dan menerimanya. Mereka tidak melakukannya.
Layanan online .Mac Apple Computer membingungkan pelanggan dengan dua perbedaan
ferent halaman "rumah". Yang pertama adalah halaman portal tempat pelanggan diarahkan
setelah masuk ke [Link] (Gambar 6.6A). Tautannya di navigasi .Mac
bar adalah ikon rumah. Yang kedua adalah halaman pengguna untuk menerbitkan dokumen,
foto, dan file lain ke Internet (Gambar 6.6B). Pelanggan sudah diambil

Halaman 261

Menyimpang dari fokus tugas 247

Gambar 6.6

[Link] 189/315
26/2/2021 Tanpa judul
Layanan online Apple .[Link]: dua halaman "beranda" yang berbeda.

di sana dulu jika mereka masuk ke [Link]. Tautannya di .Mac's naviga-

bilah tion adalah "HomePage". Kedua halaman tersebut berisi beberapa elemen yang sama,
seperti daftar file yang diterbitkan. Beberapa pelanggan .Mac tidak memahami
perbedaan.
Jika implementasi baru dari suatu fungsi diperkenalkan, tetapi implementasi lama
tasi masih ada, pengguna dihadapkan pada dua implementasi yang bersaing
dari fungsi yang sama. Ini tampaknya menjadi alasan untuk konsep yang membingungkan di
Apple MacOS X dan Microsoft Windows Vista.
MacOS X menawarkan dua implementasi Catatan Tempel: widget Perekat baru
untuk memposting catatan di Dashboard dan aplikasi Stickies yang lebih lama untuk posting-
membuat catatan di Desktop (Gambar 6.7). Saya telah mengamati pengguna Mac yang kesulitan
memposting catatan tempel Dasbor di Desktop mereka, karena mereka melakukannya dengan ekstensi
Aplikasi perekat yang mereka gunakan sebelumnya. Pengguna Mac akan bingung dengan kedua Sticky ini
Catat penerapannya hingga Apple memutuskan mana yang akan disimpan dan dihapus
lain.
Microsoft Windows selalu menyediakan fungsi untuk menangkap layar
gambar, menggunakan tombol Print Screen (Gambar 6.8A). Windows Vista memperkenalkan file

Halaman 262

248 Bab 6 Interaksi Bloopers

Gambar 6.7

SEBUAH B
MacOS X: dua implementasi perekat yang berbeda. (A) Di Dasbor. (B) Di Desktop.

cara baru untuk menangkap gambar layar: Snipping Tool (Gambar 6.8B). Kebingungan
akan menghasilkan.
Baik MacOS dan Microsoft Windows adalah platform terbuka untuk pengembangan
opers dapat mengembangkan berbagai aplikasi, jadi sesekali duplikasi fungsi
ketegangan tidak mengherankan. Tetapi platform terbuka itu sendiri tidak menyebabkan blooper.
Banyak pengguna komputer memiliki lebih dari satu browser Web di komputer mereka
tetapi tidak bingung dengan itu. Setiap browser memiliki merek yang bagus, jadi penggunanya juga baik
menyadari perbedaannya, dan ini membantu banyak pengguna memasang alis ekstra-
ers sendiri. Sebaliknya, dua implementasi Catatan Tempel MacOS X dan
Dua metode pengambilan layar Windows Vista dikemas dengan operasinya
menggunakan sistem, tanpa merek atau penjelasan — bahkan tidak dalam file Bantuan — ke
membedakan mereka.

[Link] 190/315
26/2/2021 Tanpa judul

Halaman 263

Menyimpang dari fokus tugas 249

Gambar 6.8

Windows Vista: dua cara untuk menjepret layar. (A) Print Screen (lama). (B) Snipping Tool (baru).

Menghindari Blooper 42

Hindari konsep yang tumpang tindih. Pikirkan baik-baik tentang model konseptual sebelum
dikirim oleh produk Anda. Apakah konsep di dalamnya jelas berbeda, atau apakah mereka terlalu
lap dalam arti dan / atau fungsi? Apakah pengguna cenderung membingungkan mereka? Menghapus
area apa pun yang tumpang tindih untuk membuat konsep lebih berbeda. Lebih baik, gabungkan keduanya
konsep menjadi satu, menyederhanakan model konseptual.
Saat Anda memperkenalkan implementasi baru dari fungsi yang sudah ada, pikirkan
membahas tentang apakah pengguna Anda benar-benar membutuhkan yang baru. Apakah itu memecahkan a
masalah yang mereka hadapi dengan implementasi lama atau apakah itu hanya sesuatu yang
pengembang membuat dan ingin mencoba? Jika Anda memberikan versi baru,
hapus yang lama. Jika Anda berpikir Anda perlu mempertahankan keduanya untuk mengumpulkan pasar
umpan balik, pikirkan lagi. Umpan balik dari pasar sulit untuk ditafsirkan dan
ambigu. Jika Anda membutuhkan umpan balik pelanggan untuk memutuskan implementasi mana
untuk menyimpan, kumpulkan sebelum rilis produk, menggunakan uji kegunaan dan pelanggan
grup fokus. Jika Anda memutuskan untuk memberikan dua implementasi yang bersaing dari a
konsep, padukan dengan membuatnya bekerja sama. Jika gagal, temukan jalan
untuk memperjelas perbedaannya.

Halaman 264

250 Bab 6 Interaksi Bloopers

Membutuhkan langkah-langkah yang tidak perlu

Sebuah UI harus dirancang sedemikian rupa sehingga tugas yang paling umum adalah perangkat lunak
dimaksudkan agar dukungan cepat dan mudah dilakukan (Prinsip Dasar 4, halaman 32). Bahwa
berarti meminimalkan langkah-langkah yang diperlukan untuk melakukan tugas tersebut.
Jika pengguna harus melakukan langkah-langkah yang tidak perlu untuk menyelesaikan tugas mereka, itu adalah file

[Link] 191/315
26/2/2021 Tanpa judul
kesalahan di hadapan umum. Bagian ini menjelaskan tiga kesalahan besar seperti itu.

Blooper 43: Meminta pengguna untuk data yang tidak dibutuhkan

Salah satu cara yang pasti bagi perangkat lunak untuk mengganggu penggunanya adalah dengan meminta data perangkat lunak tersebut
jelas tidak perlu.

Variasi A: Kami lupa. Beritahu kami lagi.

Bentuk blooper yang paling mengganggu pengguna ini adalah meminta mereka untuk masuk kembali
data yang sudah mereka masukkan.
Pelanggan [Link] yang terdaftar dapat memiliki situs untuk memantau harga tiket
untuk perjalanan tertentu dan beri tahu mereka bila tersedia tarif bagus. Jika pengguna,
dalam menentukan asal dan tujuan perjalanan, beri nama kota yang memiliki beberapa
bandara, Travelocity mencantumkan bandara dan meminta pengguna untuk memilihnya. Ini bisa
menjengkelkan: sering kali harus jelas bandara mana yang dimaksud (Blooper 45,
halaman 258). Namun, yang sangat mengganggu adalah Travelocity membutuhkan pengguna
untuk memilih kembali bandara yang dimaksud di kota multiairport setiap kali diperbarui
aspek apa pun dari monitor tarif mereka (Gambar 6.9).

Variasi B: Pertanyaan yang tidak perlu

Cara kedua untuk meminta data yang tidak dibutuhkan adalah dengan meminta data yang mungkin diperlukan pengguna
disimpulkan dari masukan lain. Situs web Dewan Perwakilan Rakyat AS
memiliki halaman "Tulis Perwakilan Anda". Ini mengharuskan warga untuk masuk ke keduanya
negara bagian mereka dan kode pos mereka untuk mengarahkan email ke Perwakilan mereka
(Gambar 6.10A), meskipun status dapat disimpulkan dari kode pos. Dalam kontra
Trast, kotak Find Your Representative di halaman muka hanya membutuhkan kode pos
(Gambar 6.10B).
Dalam formulir asuransi pengangguran online California (Gambar 6.11), satu
Pertanyaan meminta pelamar untuk membuat daftar majikan baru-baru ini, termasuk tanggal
pekerjaan. Pertanyaan yang sama kemudian menanyakan pengusaha mana yang terdaftar
pelamar bekerja paling lama, meski itu bisa dihitung
dari tanggal kerja. Pertanyaan selanjutnya menanyakan berapa lama pelamar
bekerja untuk majikan terlama mereka, yang juga dapat dihitung dari
tanggal kerja.

Halaman 265

Membutuhkan langkah-langkah yang tidak perlu

251

Gambar 6.9

[Link] 192/315
26/2/2021 Tanpa judul

[Link]: mengharuskan pengguna untuk membedakan bandara setiap kali FareWatcher diperbarui.

Halaman 266

252 Bab 6 Interaksi Bloopers

Gambar 6.10 Untuk menghubungi Perwakilan Anda:

1. Pilih lokasi Anda dari daftar di bawah ini:

Daftar alfabetis negara bagian dan teritori

2. Masukkan kode ZIP dan 4 digit ekstensi kode ZIP Anda.

94112 -

3. Klik tombol "Hubungi Perwakilan Saya".

Hubungi Perwakilan Saya

Tidak ada Negara Bagian yang dipilih.

Silakan gunakan kemampuan BACK browser web Anda untuk kembali ke halaman utama Tulis Perwakilan Anda untuk memilih Negara Bagian Anda.

SEBUAH

B
[Link]. (A) Menulis halaman Representatif membutuhkan negara bagian dan kode pos. (B) Halaman beranda
hanya membutuhkan kode pos.

Gambar 6.11

[Link]: formulir meminta pengguna untuk data yang dapat disimpulkan.

[Link] 193/315
26/2/2021 Tanpa judul
Halaman 267

Membutuhkan langkah-langkah yang tidak perlu

253

Variasi C: Membutuhkan data yang seharusnya opsional

Beberapa formulir online menunjuk bidang data tertentu sebagai "wajib" untuk alasan yang tidak baik.
putra. Misalnya, banyak formulir pendaftaran situs Web yang membutuhkan judul
(Bapak, Ibu, Ibu, Dr., dll.).
Formulir [Link] untuk mengirimkan pertanyaan atau komentar tentang situs
termasuk pengaturan Negara dan memperlakukannya sesuai kebutuhan (Gambar 6.12). Kenapa harus
pengguna menentukan negara hanya untuk berkomentar di situs Web? Mungkin mengetahui a
negara asal pengirim membantu master Web menafsirkan komentar mereka, tetapi
itu seharusnya tidak diperlukan .

Variasi D: Memerlukan login berulang dalam satu sesi

Banyak sistem online membutuhkan login berulang kali. [Link] memberikan ujian-
ple. Jika pelanggan frequent flier United sudah masuk dan bertanya untuk melihat a
ringkasan aktivitas di akun jarak tempuh mereka, mereka diminta untuk masuk lagi
(Gambar 6.13). United mungkin berpendapat bahwa ini adalah tindakan pengamanan, tetapi itu akan
masuk akal hanya jika login kedua diperlukan setelah batas waktu (karena

Gambar 6.12

[Link]: menuntut lebih banyak data daripada yang dibutuhkan. Formulir komentar membutuhkan negara tanpa perlu.

Halaman 268

254 Bab 6 Interaksi Bloopers

Gambar 6.13

[Link]: halaman ringkasan mileage mengharuskan pengguna yang sudah login untuk login kembali.

[Link] 194/315
26/2/2021 Tanpa judul

pelanggan mungkin telah meninggalkan terminal umum) atau jika yang kedua
login membutuhkan ID login yang berbeda. Tak satu pun dari itu yang terjadi.
Kemungkinan penyebab dari login redundan adalah halaman "Ringkasan Mileage"
dapat diakses dari beberapa tempat, ada yang dibalik login dan ada yang
tidak. Tetapi itu adalah alasan lemah untuk mengganggu puluhan ribu pelanggan.
Asosiasi Perpustakaan Digital Mesin Komputasi ([Link]) adalah
contoh lain. Setiap kali Anda meminta artikel yang berbeda, Anda harus login
lagi. Mengapa?

Menghindari Blooper 43

Jadikan prioritas tinggi untuk tidak meminta pengguna memasukkan data berulang kali. Di sini adalah
beberapa cara:

■
Mintalah hanya data yang benar-benar Anda butuhkan. Jika Anda tidak yakin dengan apa yang akan Anda lakukan
sepotong data, Anda tidak membutuhkannya.
■
Tetap berpegang pada transaksi saat ini. Data yang Anda inginkan untuk tujuan lain,
seperti pemasaran atau menjalin hubungan dengan pengguna, seharusnya
diminta di area terpisah dan opsional perangkat lunak.
■
Jangan membuat data "diperlukan" kecuali Anda benar-benar tidak dapat melanjutkan tanpanya.
■
Jangan memerlukan data yang tidak akan dimiliki beberapa pelanggan: Anda hanya akan memaksa mereka
untuk memperbaikinya… atau membawa bisnis mereka ke tempat lain.
■
Ketika seseorang memberi Anda informasi, simpulkan sebanyak mungkin informasi darinya.
Gunakan apa yang Anda ketahui untuk mengisi bidang data lainnya.

Meminta data yang tidak perlu membuat takut pelanggan yang menghargai privasi mereka,
mencegah pelanggan mencapai tujuan mereka, membuat frustrasi mereka yang tidak memilikinya
informasi yang Anda butuhkan, dan memperlambat throughput.

Halaman 269

Membutuhkan langkah-langkah yang tidak perlu

255

Pada awal 2006, [Link] mewajibkan pelanggan memasukkan alamat, kota,

dan kode pos untuk mencari lokasi FedEx di dekat mereka (Gambar 6.14A). Pada awal
2007, pelanggan dapat mencari dengan memberikan kode pos atau alamat dan kota mereka
(Gambar 6.14B).
Sulit untuk menghindari meminta data berulang kali, tetapi perangkat lunak
opers bisa melakukan lebih baik dari yang mereka miliki. 1 Beberapa aplikasi dan situs Web lebih baik
daripada yang lain dalam mengingat apa yang sudah dimasukkan pengguna. Jika Anda meremehkan masalah ini
untuk menghemat waktu atau biaya pengembangan, Anda membuat yang penting — mungkin
buruk — keputusan bisnis.
Untuk menghindari kebutuhan login berulang kali, aplikasi dan situs Web harus membuatnya
status login pengguna dapat diakses oleh semua bagian perangkat lunak. Jangan berasumsi seperti itu
pengguna yang tiba di bagian tertentu sudah masuk atau harus masuk
masuk. Sebaliknya, bagian mana pun yang memerlukan pengguna untuk masuk harus diperiksa
status login pengguna dan merespons sesuai.
Situs Jaringan Penyintas Kanker Masyarakat Kanker Amerika, [Link],
menghindari login berulang. Fungsi tertentu di situs dibatasi untuk masuk
anggota, tetapi ke mana pun anggota membuka situs, mereka tidak pernah ditanya
untuk masuk lebih dari sekali.
Beberapa layanan online memerlukan beberapa tingkat keamanan. Seorang pengguna dapat masuk
untuk mengakses area keamanan rendah, lalu masuk lagi untuk mengakses area keamanan yang lebih tinggi.
Login keamanan yang lebih tinggi harus memerlukan informasi pengenal yang berbeda dari
keamanan yang lebih rendah; jika tidak, itu bukan keamanan yang lebih tinggi.

Gambar 6.14

[Link] 195/315
26/2/2021 Tanpa judul

[Link]: Formulir Pencarian Lokasi FedEx. (A) Pada awal 2006, diperlukan alamat, kota, dan kode pos
kode. (B) Pada awal 2007, diperlukan kode pos, atau alamat dan kota, tetapi tidak ketiganya.

(Lanjutan)

1. Metode untuk menyebarkan data antar formulir di situs Web dijelaskan di Bloopers Web
[Johnson, 2003].

Halaman 270

256 Bab 6 Interaksi Bloopers

Gambar 6.14
(Lanjutan)

Blooper 44: Meminta pengguna untuk benih acak

Kasus khusus meminta pengguna untuk data yang tidak dibutuhkan terjadi dalam perangkat lunak yang menggunakan
nomor acak untuk sampel data, menjalankan simulasi, membuat karakter bergerak
tak terduga, buat nama file unik, atau buat kunci unik. Acak
generator nomor harus "diunggulkan" dengan nilai awal yang unik; jika tidak
mereka menghasilkan angka "acak" yang sama setiap saat.
Beberapa aplikasi mendapatkan nilai awal mereka dengan meminta nomor pengguna — apa saja
nomor — atau teks — teks apa saja. Meminta masukan acak dari pengguna adalah ganda
blooper: meminta data yang tidak dibutuhkan dan mengekspos implementasinya. Memulai
generator nomor acak adalah masalah perangkat lunak internal, tidak berarti apa-apa
pengguna. Pengguna tidak suka memasukkan nilai yang tidak berarti; itu mengalihkan mereka dari mereka
kerja.
Orang juga buruk dalam bersikap acak. Minta beberapa orang untuk "acak
number ”antara 1 dan 100, dan Anda akan mendapatkan serangkaian angka yang tidak acak.
Anda akan mendapatkan sebagian besar angka ganjil karena angka genap tidak tampak "acak".
Jumlah yang biasanya diberikan orang adalah 37.
Satu perusahaan sedang mengembangkan perangkat lunak untuk analisis statistik bisnis.
Perangkat lunak mengambil sampel data secara acak dari database. Untuk mendapatkan acak yang berbeda
sampel untuk setiap analisis, perangkat lunak meminta pengguna untuk "Sampler
Benih ”setiap kali. Diberikan benih yang sama dua kali, perangkat lunak akan mengekstrak file
sampel "acak" yang sama. Namun, pengguna tidak suka harus menyediakan benih. Mereka
tidak bisa mengingat benih apa yang mereka gunakan sebelumnya.

Halaman 271

Membutuhkan langkah-langkah yang tidak perlu

257

[Link] 196/315
26/2/2021 Tanpa judul

Menghindari Blooper 44

Perangkat lunak tidak boleh meminta benih acak dari pengguna. Jika program Anda membutuhkannya,
itu harus mendapatkan satu untuk dirinya sendiri.

Dasarkan benih pada interval variabel

Metode penyemaian diri tradisional adalah mendapatkan waktu atau tanggal dari
sistem operasi dan menggunakannya sebagai benih, tetapi sekarang benih seperti itu dipertimbangkan
tidak cukup acak. Aplikasi modern menumbuhkan dirinya sendiri menggunakan waktu variabel
interval antara kejadian yang dibuat pengguna, seperti waktu antara penekanan tombol.

Beri pengguna kontrol yang mereka butuhkan saja

Jika pengguna Anda biasanya ingin perangkat lunak dijalankan secara berbeda setiap saat, tetapi terkadang-
kali ingin mengulang proses sebelumnya, beri mereka cara untuk menentukan adil
bahwa. Sediakan tombol — diberi label untuk mencocokkan maksud pengguna — yang membuat
ware reseed sendiri (Gambar 6.15A). Atau, berikan pengguna tombol untuk berbelok
reseeding otomatis ON dan OFF (Gambar 6.15B), default ke ON.
Rancang perangkat lunak untuk merekam benih yang digunakan untuk menghasilkan benih beserta hasilnya
mereka. Kemudian Anda dapat mengizinkan pengguna untuk menentukan proses sebelumnya secara opsional
cocok.
Namun, pastikan Anda memahami persyaratannya. Mengapa pengguna menginginkan
mengulang perjalanan sebelumnya? Jika mengulang sebuah proses hanya menghasilkan keluaran yang sama, satu-satunya
alasan untuk melakukannya adalah karena pengguna kehilangan output sebelumnya dan perlu
membuatnya kembali. Alih-alih menyediakan cara untuk mengulang lari sebelumnya, mungkin lebih baik melakukannya
menyediakan cara yang lebih baik untuk mengelola file keluaran sehingga pengguna tidak kehilangannya.

Game tidak meminta benih acak dari pengguna

Banyak game komputer menyediakan lawan bawaan yang pergerakannya harus sesuai
tidak dapat diprediksi. Mesin judi elektronik harus melakukan simulasi lemparan dadu,
menarik tuas mesin slot, menangani kartu, dan memutar roda roulette. Semua
ini harus berperilaku berbeda setiap saat.

Gambar 6.15
Gunakan sampel acak yang berbeda lain kali atau Kocok Deck

SEBUAH

Contoh acak: Sama setiap saat Berbeda setiap saat

Cara yang berfokus pada tugas agar pengguna dapat mengontrol penyemaian. (A) Perintah. (B) Sakelar ON / OFF.

Halaman 272

258 Bab 6 Interaksi Bloopers

Perangkat lunak permainan dan mesin judi elektronik tidak pernah meminta pengguna
nilai benih. Pengembang game tahu bahwa pasar mereka tidak akan mentolerir ini
kesalahan di hadapan umum. Software game membuktikan bahwa mengharuskan pengguna untuk memasukkan nomor secara acak
dalam perangkat lunak apa pun tidak diperlukan.

Blooper 45: Pilihan tak berguna

Kasus khusus kedua yang mengharuskan pengguna memasukkan data yang tidak perlu ada-
menarik pengguna dengan pilihan yang tidak perlu. Ada empat variasi umum dari ini
kesalahan di hadapan umum:

Variasi A: Tidak ada perbedaan

Beberapa situs Web menghadapkan pengguna dengan pilihan-pilihan di mana opsi-opsi yang tersedia tersedia
semuanya pada dasarnya sama. Memilih di antara mereka adalah pemborosan yang tidak ada gunanya dan mengganggu
waktu.
[Link] adalah situs Web pencarian bed-and-breakfast di Selandia Baru. Jika
seorang pengguna menelusuri Rosecroft B&B di "Christchurch", situs tersebut mengembalikan no
B&B tetapi lebih tepatnya empat lokasi di Selandia Baru di mana B&B Rosecroft sebelumnya
ditemukan, memaksa pengguna untuk memilih satu sebelum mencapai daftar B&B
(Gambar 6.16). Dua lokasi pertama adalah kota Christchurch, sedangkan

[Link] 197/315
26/2/2021 Tanpa judul
dua yang kedua jauh dari Christchurch. Mengapa tidak mencantumkan nama B&B saja
“Rosecroft” di Christchurch?

Variasi B: Pengguna tidak tahu

Ketika opsi tidak ada artinya, pengguna tidak memiliki dasar untuk memilih di antara
mereka. Jika perangkat lunak tidak membiarkan pengguna mengabaikan pilihan, mereka harus menebak.

Gambar 6.16

[Link]: mencari B&B “rosecroft” di “christchurch” menghasilkan dua lokasi yaitu

baik di kota Christchurch, plus dua lokasi yang tidak relevan.

Halaman 273

Membutuhkan langkah-langkah yang tidak perlu

259

Gambar 6.17

[Link]: pengguna tidak memiliki dasar untuk memilih di antara server unduhan.

[Link] memungkinkan pelanggan mengunduh perangkat lunak. Namun, situs tersebut

membuat pelanggan memilih dari tiga server mana yang akan diunduh (Gambar
6.17). Salah satu dari server ini akan berfungsi, jadi mengapa pengguna harus memilih satu?
Juga server diberi label dengan sangat samar sehingga pengguna tidak akan tahu
yang mana yang harus dipilih. Opsi ini hanya masuk akal bagi karyawan Sibelius
yang mengelola server unduhan.

Variasi C: Jawaban yang jelas

Beberapa aplikasi dan situs Web membuat pengguna memilih meskipun sudah jelas
opsi mana yang benar. Pilihan yang jelas dapat didasarkan pada data frekuensi,
akal sehat, atau masukan pengguna sebelumnya di sesi saat ini. Saat perangkat lunak
mengabaikan yang sudah jelas, memaksa pengguna untuk memilih yang tidak perlu.
Misalkan Anda menelusuri situs web United Airlines untuk penerbangan dari San
Francisco (SFO) ke Auckland, Selandia Baru, memberikan "Auckland" sebagai desain Anda
tination. Situs tersebut menjawab “Ada beberapa bandara di kota yang Anda masukkan.
Silakan pilih… ”(Gambar 6.18). Ini mencantumkan Oakland, San Francisco, San Jose, dan
Auckland. Itu semua bandara di Auckland? Yang Anda beri nama, Auckland,
bahkan bukan yang pertama atau default. Lebih aneh lagi, satu tujuan yang terdaftar adalah Anda
bandara keberangkatan .
Pencarian di [Link] untuk penerbangan dari SFO ke Montreal menghasilkan hal yang serupa
hasil: pilihan antara bandara Monterey Peninsula (default), Montrose
Bandara County, bandara kota Montreal (YMQ), bandara utama Montreal
(Pierre Trudeau Int'l, YUL), dan bandara Monterey. Hanya dua di antaranya yang sebenarnya
sekutunya di Montreal, dan dari keduanya, hanya YUL yang dilayani oleh United. Pilihan ini
benar-benar membuang-buang waktu pengguna.
Itu tidak seberapa dibandingkan dengan hasil pencarian [Link]
penerbangan dari SFO ke Denver. Pesan "beberapa bandara" yang sama muncul, ikuti
dicantumkan oleh "daftar" dari satu bandara: DEN (Gambar 6.19). Situs ini membuang-buang waktu pengguna
dengan langkah "pilihan" yang sama sekali tidak berguna ini.

[Link] 198/315
26/2/2021 Tanpa judul

Halaman 274

260 Bab 6 Interaksi Bloopers

Gambar 6.18

SEBUAH

B
[Link]: mencari penerbangan dari SFO ke Auckland menghasilkan pilihan yang tidak perlu.

Gambar 6.19

SEBUAH

B
[Link]: mencari penerbangan dari SFO ke Denver menghasilkan "pilihan" yang tidak perlu.

Halaman 275

Membutuhkan langkah-langkah yang tidak perlu

261

Gambar 6.20

[Link] 199/315
26/2/2021 Tanpa judul

SEBUAH

B
[Link]: mencari hotel di “minneapolis, minn” menghasilkan “pilihan” satu.

[Link] memiliki blooper yang sama. Jika Anda mencari hotel di “min-
neapolis, minn, ”tanggapan situs tersebut“ Pencarian Anda untuk minneapolis, minn cocok
satu atau lebih kota kita. Silakan pilih… ”dan memberi Anda menu
mengandung tepat satu kota: Minneapolis, Minnesota (Gambar 6.20).

Variasi D: Pilihan salah

Sayangnya, variasi blooper yang paling membuang-buang waktu telah menjadi

sangat umum di situs Web e-commerce. Perusahaan memotong biaya dengan membeli-
menggunakan layanan back-end pihak ketiga generik alih-alih mengembangkannya sendiri
bisnis khusus. Database umum bandara atau kota, untuk ujian-
mohon, jangan mencerminkan penawaran produk atau layanan perusahaan tertentu yang sebenarnya-
ings dan dapat menyebabkan situs Web perusahaan menawarkan pilihan yang tidak ada
pelanggan.

Halaman 276

262 Bab 6 Interaksi Bloopers

Contoh jelas dari "pilihan salah" berasal dari pencarian bed and breakfast
Situs web dibahas di bawah Variasi A. Tidak hanya [Link] hadir
pengguna dengan pilihan yang tidak perlu, keempat "lokasi" yang tercantum dalam hasil ternyata
tidak mengandung apa-apa (Gambar 6.21).
Situs web American Airlines, [Link], memiliki "jawaban yang jelas" dan
varian "pilihan salah" dari "pilihan tidak berguna". Mencari penerbangan dari SFO
ke hasil Houston “Kami tidak dapat menentukan dari bandara yang Anda inginkan
entri Anda. Silakan pilih… ”dengan daftar lima“ bandara ”, salah satunya adalah bus
stasiun (Gambar 6.22A). Memilih salah satu dari dua daftar Houston dalam bahasa Inggris
Columbia (Kanada) mengungkapkan bahwa American Airlines tidak menyediakan layanan
di sana — tidak ada penerbangan, tidak ada bus — tidak ada (Gambar 6.22B). Seharusnya tidak
telah terdaftar.

Gambar 6.21

[Link] 200/315
26/2/2021 Tanpa judul

[Link]: mencari B&B “rosecroft” di “christchurch” menghasilkan empat pilihan lokasi

di mana tidak ada B & B yang ditemukan.

Halaman 277

Membutuhkan langkah-langkah yang tidak perlu

263

Gambar 6.22

SEBUAH

B
[Link]: mencari penerbangan dari SFO ke Houston menampilkan pilihan ekstra yang tidak ada gunanya
beberapa opsi sebenarnya tidak ada.

Menghindari Blooper45

Bagaimana menghindari penyajian pilihan yang tidak perlu tergantung pada mengapa pilihan tersebut
tidak perlu.

Jika pilihan tidak membuat perbedaan, jangan tawarkan

Meminta pengguna untuk memilih di antara opsi yang tidak membuat perbedaan signifikan
apa yang mereka dapatkan hanya membuang-buang waktu mereka.
Bagaimana Anda menemukan bahwa situs Anda menyajikan pilihan yang tidak masuk akal dan identik? Uji
saya t! Anda mungkin bisa menggunakan anggota tim Anda sendiri sebagai subjek, tapi tetaplah
ingat bahwa pengembang, saat menguji perangkat lunak mereka sendiri, mengabaikan banyak gangguan-
Ances. Lebih baik mengamati orang-orang yang seperti pengguna situs yang dituju.
Bahkan jika mereka tidak secara eksplisit mengeluh tentang pilihan yang tidak perlu, Anda akan lebih
mungkin menemukan masalahnya.

[Link] 201/315
26/2/2021 Tanpa judul
Halaman 278

264 Bab 6 Interaksi Bloopers

Jika pengguna tidak memahami pertanyaannya, jangan tanya

Pertimbangkan apakah pilihan yang diminta perangkat lunak Anda kepada pengguna masuk akal. Jika
mereka tidak tahu apa yang diminta perangkat lunak, Anda akan mengganggu mereka dan tidak akan mendapatkannya
tanggapan yang berguna. Jika Anda belum memberikan default, pengguna hanya akan menebak-nebak. Jika kamu
telah menyediakan default, seperti [Link], pengguna mungkin akan meninggalkannya begitu saja
apa adanya, apakah itu tepat untuk situasi mereka atau tidak.
Untuk mengetahui apakah pilihan yang disajikan oleh perangkat lunak Anda bermakna bagi pengguna,
menguji. Uji kegunaan tidak perlu — dan tidak boleh — menunggu hingga perangkat lunak selesai
akan segera dirilis. Mereka dapat dilakukan lebih awal dan murah, menggunakan kertas atau
Prototipe HTML.

Jika ada opsi yang jelas, pilihlah

Terkadang pilihan yang benar sudah jelas berdasarkan akal sehat, normal
pola penggunaan, atau masukan pengguna sebelumnya. Perangkat lunak yang tidak memanfaatkannya
"Pengetahuan" membuang-buang waktu pengguna.

Jangan menawarkan pilihan yang salah

Jika seorang karyawan perusahaan Anda menawarkan pilihan pelanggan yang sebenarnya tidak
tersedia, pelanggan akan mempertimbangkan karyawan tersebut, dan perusahaan Anda
salah informasi dan tidak kompeten atau sengaja berbohong dan tidak dapat dipercaya.
Ketika perangkat lunak Anda mencantumkan produk atau layanan yang "tersedia", mereka harus tersedia.
Anda dapat membuat daftar item yang stoknya habis atau tanggal yang dipesan sehingga pelanggan dapat melihatnya,
tetapi mereka harus ditandai sebagai tidak tersedia sehingga pelanggan tidak akan berusaha
memerintahkan mereka hanya untuk menemukan beberapa langkah kemudian bahwa mereka membuang-buang waktu.

Membebani memori pengguna

Berikutnya adalah tiga blooper interaksi yang memberikan beban yang tidak perlu pada orang-orang
memori, mempersulit orang untuk mengingat apa yang mereka lakukan atau rencanakan
melakukan.

Blooper 46: Sulit untuk mengingat ID

Cara paling jelas untuk membebani memori pengguna adalah dengan meminta otentikasi
identifikasi yang tidak dapat mereka ingat.

Variasi A: Kata sandi yang ditetapkan dan tidak dapat diubah

Dari semua organisasi, orang akan berpikir bahwa Asosiasi Profesional Kegunaan
(UPA) akan tahu lebih baik daripada membebani ingatan orang. Namun, mereka melakukannya

Halaman 279

Membebani memori pengguna 265

hanya saja: mereka menetapkan nama akun dan sandi sewenang-wenang untuk anggota dan
tidak menyediakan cara untuk mengubahnya.
Anggota UPA menerima surat yang mengundang mereka untuk menggunakan layanan online UPA dan
memberi mereka ID Pengguna dan kata sandi. ID Pengguna adalah angka empat digit,
sedangkan kata sandinya adalah nama keluarga anggota. Sebagai contoh:

■
ID Pengguna: 4567
■
Kata sandi (peka huruf besar-kecil): Flintstone

UPA tidak memberikan cara untuk mengubahnya menjadi sesuatu yang lebih mudah diingat. Anggota
yang, meskipun demikian, ingin menggunakan layanan online UPA harus menghafalnya
ID pengguna dan kata sandi atau tuliskan, yang tidak aman. Skema UPA
juga menggunakan nomor untuk ID dan teks untuk kata sandi, yang mundur,
tidak umum, dan mudah membingungkan.

[Link] 202/315
26/2/2021 Tanpa judul

Variasi B: Pembatasan kata sandi yang tidak masuk akal

Beberapa aplikasi dan situs Web memungkinkan pengguna untuk membuat dan mengubah pengguna mereka
nama dan kata sandi, tetapi memberlakukan persyaratan yang begitu ketat sehingga tidak ada yang bisa
mengingat ID mereka tanpa menuliskannya dan menyimpannya bersama mereka.
Satu aplikasi memungkinkan pengguna untuk mengubah identifikasi pribadinya
nomor (PIN) "ke nomor yang mudah… diingat," tetapi kemudian dikenakan
batasan yang tidak memungkinkan untuk melakukannya (Gambar 6.23). Baris terakhir dari
instruksi akan menjadi lucu jika tidak begitu mengganggu.

Variasi C: Pertanyaan keamanan yang tidak berfungsi

ID yang sulit diingat muncul saat situs Web meminta pengguna untuk memilih keamanan
pertanyaan tantangan, tetapi berikan pilihan terbatas dan jangan biarkan pengguna membuat
up sendiri.
Di [Link], untuk membeli perangkat lunak, Anda harus mendaftar. Anda dapat memilih
memiliki nama akun dan kata sandi sendiri, dan batasannya tidak buruk. Kamu bisa
daftarkan "petunjuk kata sandi" sehingga situs dapat mengingatkan Anda jika Anda lupa sandi Anda-
kata. Ini semua baik-baik saja.

Gambar 6.23

Aplikasi Web Klien: pembatasan mencegah pengguna membuat PIN yang mudah diingat.

Halaman 280

266 Bab 6 Interaksi Bloopers

Gambar 6.24

[Link]: pertanyaan keamanan terbatas — pengguna mungkin tidak memiliki jawaban yang unik dan mudah diingat untuk setiap pertanyaan.

Masalah terjadi saat situs meminta Anda untuk "Pilih pertanyaan keamanan…."
Anda tidak dapat menentukannya; Anda memilih dari menu (Gambar 6.24). Bagaimana jika Anda tidak bisa
menjawab salah satu pertanyaan? Mungkin ayahmu tidak punya nama tengah. Mungkin
Anda memiliki beberapa teman masa kecil. Bahkan kota kelahiran seseorang bisa menjadi ambigu
orang yang lahir di pedesaan. Beberapa pertanyaan dapat memiliki beberapa kemungkinan jawaban.
Anda harus memilih pertanyaan dan kemudian mengingat jawaban mana yang Anda berikan
Intuit.

Menghindari Blooper46

Berikut adalah pedoman tentang bagaimana merancang langkah-langkah keamanan yang tidak membebani
memori pengguna:

■
Biarkan pengguna membuat nama pengguna, sandi, dan PIN mereka sendiri. Menghindari
bentrokan di mana banyak pengguna menginginkan nama pengguna yang sama dan harus menggunakan
yang sulit diingat seperti "Freddy54321", biarkan orang lain menggunakannya
alamat email (termasuk domain, mis. fred@[Link]) sebagai pengguna
nama; itu akan menjadi unik.

[Link] 203/315
26/2/2021 Tanpa judul
■
Jangan memaksakan batasan sewenang-wenang dan tidak perlu pada kata sandi atau PIN.
Biarkan pengguna membuat yang bisa mereka ingat. Pass yang rumit, "sangat aman"
kata-kata yang tidak dapat diingat orang sebenarnya tidak terlalu aman, karena
orang hanya menuliskannya dan membawanya ke mana-mana.
■
Izinkan pengguna untuk mengubah sandi dan PIN mereka.
■
Sertakan cara bagi pengguna yang lupa sandi atau PIN mereka untuk mendapatkan atau menyetel ulang.
Mengirimkan kata sandi, petunjuk kata sandi, atau tautan setel ulang kata sandi ke pengguna

Halaman 281

Membebani memori pengguna 267

alamat email terdaftar akun adalah cara yang baik untuk melakukannya jika Anda semua pengguna
memiliki alamat email.
■
Jika Anda menggunakan pertanyaan tantangan, berikan pilihan yang baik, dan berikan
Opsi "Lainnya" sehingga pengguna dapat menentukan pertanyaan mereka sendiri.

Blooper 47: Instruksi panjang yang pergi terlalu cepat

Desainer UI baru terkadang membuat instruksi beberapa langkah yang sebelumnya hilang
semua langkah selesai. Ini bisa disebut "pintu helikopter"
blooper karena beberapa helikopter yang digunakan Angkatan Darat AS dalam Perang Vietnam
seharusnya memiliki serangkaian langkah untuk evakuasi tercetak di bagian dalam
pintu. Langkah pertama adalah meledakkan pintu. Saat mencoba untuk bail out dari a
jatuh 'helikopter, tentara seharusnya membaca semua instruksi,
tiup pintunya, dan ingat cukup banyak instruksi untuk menyelesaikannya
evakuasi.
Contoh perangkat lunak klasik berasal dari Microsoft Windows. Sebagai bagian dari
proses menghubungkan komputer ke jaringan rumah nirkabel, tampilan Windows
memainkan kotak dialog yang memberikan instruksi beberapa langkah untuk mengkonfigurasi komputer.
Langkah pertama adalah "klik OK untuk menutup dialog ini" (Gambar 6.25). Lalu …
apa lagi instruksi-instruksi itu?
Contoh yang lebih halus dari blooper "pintu helikopter" berasal dari National
Perencana Perjalanan Geografis. Ini memiliki Notebook di mana pengguna dapat menyimpan catatan
tentang lokasi yang mereka temukan. Pertama kali pengguna membuka Notebook, a
kotak dialog muncul menjelaskan tiga metode berbeda untuk memasukkan catatan, masing-masing
dengan beberapa langkah (Gambar 6.26). Instruksi tidak mengatakan bahwa dialog
kotak harus ditutup terlebih dahulu, tetapi ini adalah modal, jadi harus ditutup sebelum pengguna bisa
ikuti petunjuk.
Seringkali blooper ini terjadi karena developer terlambat mengetahui perkembangannya
bahwa satu fungsi terlalu sulit untuk digunakan, tetapi terlambat atau terlalu mahal untuk didesain ulang
fungsinya. Mereka menempelkan instruksi di awal fungsi dan berharap pengguna
dapat mengingatnya sepenuhnya.

Gambar 6.25

Microsoft Windows: instruksi panjang hilang setelah langkah pertama.

Halaman 282

268 Bab 6 Interaksi Bloopers

[Link] 204/315
26/2/2021 Tanpa judul

Gambar 6.26

Perencana Perjalanan National Geographic: tiga opsi, masing-masing dengan beberapa langkah.

Situasi terkait adalah ketika aplikasi menggabungkan fungsi 2 eksternal

itu tidak bisa diubah. Untuk membantu pengguna menggunakan fungsi eksternal, aplikasi
menampilkan instruksi sebelum fungsi eksternal dijalankan. Tidak apa-apa, tapi
ketika instruksi hilang sebelum pengguna menjalankan semua langkah di dalamnya, itu a
kesalahan di hadapan umum.

Menghindari Blooper 47

Instruksi rinci harus tetap ditampilkan saat pengguna mengikuti

mereka. Perancang perangkat lunak — seperti perancang helikopter — seharusnya tidak mengharapkan pengguna
untuk membaca instruksi beberapa langkah dan kemudian mengingatnya setelah instruksi
hilang.
Saat pengguna membutuhkan bantuan dalam melakukan tugas beberapa langkah, jangan tampilkan semua
langkah-langkah di awal dan berharap pengguna mengingatnya. Sebaliknya, lakukan salah satu dari
pengikut:

■
Sediakan wizard. Tampilkan kotak dialog multi halaman di mana setiap halaman mewakili
membenci sebuah langkah dan menyajikan instruksi untuk langkah itu. Ini yang ideal
desain, tetapi tidak selalu layak.

2. Dikembangkan sebelumnya (alias "warisan") atau dibeli dari perusahaan lain.

Halaman 283

Membebani memori pengguna 269

Gambar 6.27

Microsoft Office: instruksi panjang yang tetap ditampilkan saat dijalankan.

[Link] 205/315
26/2/2021 Tanpa judul

■
Pertahankan instruksi. Pertahankan instruksi ditampilkan selama pengguna mengikuti-
merendahkan mereka. Jendela Bantuan Microsoft Office (Gambar 6.27) melakukan ini.
■ Bungkus fungsi eksternal. Jika Anda memasukkan fungsi eksternal ke dalam file
aplikasi dan tidak dapat mengubahnya agar cocok dengan UI aplikasi Anda, "bungkus"
itu dalam kode baru yang menampilkan instruksi dan membuatnya tetap ditampilkan sementara
pengguna mengerjakan langkah-langkah tersebut.

Blooper 48: Mode yang tidak perlu atau ditandai dengan buruk

Ketika perangkat lunak melakukan sesuatu yang tidak diharapkan dan tidak diinginkan oleh penggunanya, file
Masalahnya sering kali perangkat lunak itu dalam mode yang berbeda dari apa yang pengguna
pikir itu masuk Beberapa contoh berikut:

■
Anda menggunakan program menggambar untuk mengedit ilustrasi. Anda ingin pindah
persegi panjang ke lokasi baru. Anda mencoba menyeret persegi panjang, tetapi
hitung gambar persegi panjang baru sebagai gantinya. Ups! Programnya di Draw
Mode persegi panjang, bukan mode Pilih.
■ Anda mencetak halaman Web, tetapi halaman mencetak dalam format lanskap, memotong
dari bawah. Ups! Lupa menyetel Orientasi Halaman kembali ke Potret setelah
mencetak halaman lanskap kemarin.

Halaman 284

270 Bab 6 Interaksi Bloopers

■
Di situs Web investasi saham, Anda membuat pesanan saham dan menyimpannya, berniat-
ingin mengirimkannya nanti, tetapi pesanan segera dikirimkan. Argh! Lupa
untuk mematikan mode Kirim Otomatis setelah menunjukkan kepada seseorang cara kerjanya.

Apa itu mode, dan mengapa itu menjadi masalah?

Perangkat lunak memiliki mode jika tindakan pengguna memiliki efek yang berbeda dalam situasi yang berbeda.
Untuk memprediksi efek apa yang akan dimiliki tindakan tertentu, pengguna harus mengetahui mode apa
aplikasi masuk Misalnya, efek mengklik tombol pada aplikasi
Jendela kation mungkin bergantung pada bagaimana opsi perangkat lunak tertentu ditetapkan. Itu
mode masalah kegunaan penyebab sudah lama dikenal:

Setiap… status di mana operasi tertentu oleh pengguna diinterpretasikan secara berbeda
oleh program ini disebut mode perintah. Lebih banyak mode dalam satu perintah
bahasa, semakin besar kemungkinan pengguna membuat kesalahan dengan melupakan mode yang mana
dia masuk [Newman dan Sproull, 1979]

Pengamatan saya terhadap sekretaris yang belajar menggunakan… editor teks… meyakinkan saya
bahwa komputer kesayangan saya sebenarnya adalah monster yang tidak bersahabat, dan itu adalah milik mereka
taring paling tajam adalah mode yang selalu ada. [Tesler, 1981]

Pengguna editor teks membingungkan mode, terutama ketika pengguna menghabiskan waktu lama di
mode selain mode "normal". [Thimbleby, 1982]

Kesalahan mode sering terjadi dalam sistem yang tidak memberikan umpan balik yang jelas
keadaan mereka saat ini. [Norman, 1983]

Mode memaksa pengguna untuk melacak mode perangkat lunak yang digunakan. Mode membatasi
tindakan pengguna terhadap apa yang diizinkan dalam mode saat ini. Mereka memungkinkan,
terkadang bahkan mungkin, bahwa pengguna akan melakukan tindakan yang tidak mereka inginkan atau
mencoba tindakan yang tidak valid. Beberapa kesalahan mode sepele dan mudah dilakukan
benar, tetapi yang lainnya serius.
Kecelakaan maskapai besar sepenuhnya disebabkan oleh kesalahan mode. Pilot itu menyesuaikan diri
putaran autopilot untuk menetapkan ketinggian target 1700 meter, tetapi dial berada di a
Mode Rate of Descent, jadi pesawat malah kehilangan ketinggian di 1.700 meter per
menit, menabrak lereng gunung.
Kebanyakan mode tidak perlu atau tidak sesuai; desain yang lebih hati-hati bisa
singkirkan mereka. Bahkan perangkat lunak yang membutuhkan mode sering kali memberikan umpan balik yang buruk
tentang mode apa itu.

GUI yang dimodifikasi

Earthlink WebMail memiliki GUI yang dimodifikasi sehingga mudah untuk melupakan mode apa
itu masuk dan membuat kesalahan mode. Aplikasi ini memiliki folder email Tersangka
yang mengkarantina email dari pengirim yang tidak dikenal. Anda dapat melihat ke dalamnya untuk melihat apakah
pesan apa pun yang dikarantina adalah yang Anda inginkan. Anda dapat melakukan empat hal untuk quar-
pesan antined. Anda dapat memindahkannya ke Kotak Masuk dengan atau tanpa menambahkan

[Link] 206/315
26/2/2021 Tanpa judul

Halaman 285

Membebani memori pengguna 271

Gambar 6.28

Earthlink WebMail: efek tombol "Mulai" bergantung pada tindakan yang disetel oleh menu.

pengirim ke Buku Alamat Anda. Anda dapat menghapusnya atau melaporkannya sebagai spam
(Gambar 6.28).
Alih-alih menyediakan empat tombol perintah terpisah atau menu empat
perintah, WebMail hanya menyediakan satu tombol "Go" dengan menu mode itu
set yang mana dari empat tindakan "Mulai" yang akan dijalankan. Pengguna WebMail sering memilih
beberapa pesan dikarantina dan klik "Go" tanpa menyadari bahwa mode tersebut
menu tidak disetel seperti yang mereka inginkan. Karena mode default adalah Pindah ke Kotak Masuk dan Tambah
Kontak dan tindakan paling umum pada pesan yang dikarantina adalah melaporkan
mereka sebagai spam, kesalahan mode yang paling umum adalah memilih sekumpulan spam
pesan dan secara tidak sengaja memindahkannya ke Kotak Masuk Anda dan menambahkan pelaku spam
alamat ke Buku Alamat Anda. Ups!

Mode yang kurang berbahaya: Kotak dialog Modal

Semua mode tidak sama. Beberapa tidak berbahaya dibandingkan yang lain. Dalam jumlah sedang dan
dengan umpan balik mode yang baik, mode bahkan dapat membantu.
Penggunaan mode yang umum adalah untuk menampilkan kotak dialog modal, yang memblokir
pengguna berinteraksi dengan jendela lain di aplikasi atau secara keseluruhan
layar. Mereka disebut "modal" karena mereka menempatkan komputer ke mode masuk
yang hanya menerima masukan ke kotak dialog.
Kotak dialog dapat menunjukkan tingkat modal-ness yang berbeda:

■
Modal induk: Blokir interaksi dengan jendela induknya sendiri tetapi izinkan
interaksi dengan jendela lain dari aplikasi yang sama atau dari yang lain
aplikasi.
■ Modal aplikasi: Blokir interaksi dengan semua bagian lain dari aplikasi yang sama.
kation, tetapi mengizinkan pengguna untuk berinteraksi dengan aplikasi lain.
■
Modal atau modal sistem: Blokir semua interaksi selain dengan modal
kotak dialog.

Tujuan dari kotak dialog modal adalah untuk memaksa pengguna untuk memperhatikan, membaca, dan
menanggapi mereka sebelum melakukan apa pun. Ini diperlukan ketika:

Halaman 286

272 Bab 6 Interaksi Bloopers

■
Ada masalah serius yang membutuhkan perhatian pengguna. Jika dialog error
kotak bukan modal, pengguna bisa melewatkannya dan mengklik jendela lain, menyebabkan
kotak dialog kesalahan menghilang di balik jendela lain.
■
Perubahan lain pada aplikasi tidak diperbolehkan saat kotak dialog ditampilkan.
dimainkan. Jika kotak dialog mengumpulkan input untuk operasi pada objek data,
aplikasi mungkin perlu memblokir pengguna dari menghapus atau mengubah objek

[Link] 207/315
26/2/2021 Tanpa judul
sampai operasi selesai.

Kesalahan mode karena kotak dialog modal cukup tidak berbahaya: pengguna mencoba
untuk mengklik sesuatu yang lain tetapi komputer hanya berbunyi bip. Namun, bisa jadi
frustasi untuk diblokir dari melakukan hal lain saat kotak dialog modal ada
ditampilkan, terutama jika kotak dialog mengatakan sesuatu yang mengerikan seperti:

Kehabisan memori. Semua data Anda akan hilang. [BAIK]

Pengaturan mode tidak berbahaya, terutama jika pengguna tidak pernah mengubahnya

Microsoft Word penuh dengan mode. Ini hanya beberapa (dengan default
mode dalam huruf miring):

■
Tampilan: Normal , Outline, Page Layout, Master Document
■
Koreksi otomatis: Hidup , Mati
■
Pelacakan revisi: Aktif, Nonaktif
■
Repaginasi latar belakang: Aktif , Nonaktif
■
Simpan otomatis: Aktif , Nonaktif
■
Pemilihan kata otomatis: Aktif , Nonaktif
■
Potong-dan-tempel cerdas: Nyala , Mati
■
Pengeditan teks tarik dan lepas: Aktif , Nonaktif
■
Teks yang disisipkan menimpa: Aktif, Nonaktif

Sebagian besar mode ini tidak menyebabkan kesalahan mode. Mengapa? Alasannya bukan itu
nilai saat ini dari mode ini ditunjukkan dengan jelas sehingga pengguna tidak bisa
merindukan mereka. Kebanyakan dari mereka hampir tidak ditunjukkan sama sekali. Alasannya sangat luas
mayoritas pengguna Word tidak pernah mengubah pengaturan ini dari default. Banyak
Pengguna Word bahkan tidak tahu bahwa pengaturan ini ada di Word. Jika pengaturan mode
tidak pernah berubah, secara efektif hanya memiliki satu nilai. Seperti yang dikatakan Larry Tesler [1981]:
“Satu mode tidak ada mode sama sekali.”
Salah satu modus pengaturan di Word bahwa sebagian besar pengguna melakukan perubahan adalah View (Normal,
Garis Besar, Tata Letak Halaman, Dokumen Induk). Oleh karena itu terkadang menyebabkan
kesalahan mode, seperti tidak sengaja mengedit dokumen dalam tampilan Garis Besar dan
bertanya-tanya mengapa formatnya aneh.
Mode Tampilan lain — yang tidak berbahaya — ada di folder file Microsoft Windows.
Folder dapat diatur untuk menampilkan file dalam lima cara (Gambar 6.29). Satu-satunya eksplisit

Halaman 287

Membebani memori pengguna 273

Gambar 6.29

Folder Windows Mode tampilan: tidak mungkin menyebabkan kesalahan mode.

Indikator mode Tampilan saat ini ada di menu Tampilan folder, yaitu
biasanya ditutup. Tidak apa-apa karena pengguna dapat melihat mode tampilan saat ini dengan caranya
folder mencantumkan file.

Mode dengan nama buruk

Beberapa setelan mode menyertakan "mode" dalam namanya; beberapa tidak. Nama untuk
pengaturan mode sering istimewa dan juga tidak konsisten: apa pun
opers kebetulan memikirkan saat mereka menambahkan pengaturan, tanpa
mempertimbangkan pengaturan lain dan namanya.
Terkadang setelan mode hanya diberi nama "Mode", karena tidak ada yang bisa
pikirkan nama yang lebih deskriptif. Jendela Opsi CorelDraw menyediakan file
contoh (Gambar 6.30).

Mode pemanggang roti

[Link] 208/315
26/2/2021 Tanpa judul

Pemanggang roti memiliki mode. Pengaturan Darkness adalah satu. Kesalahan mode menyebabkan terbakar atau
Roti panggang "mentah".
Kontrol Kegelapan seharusnya memungkinkan Anda mengatur pemanggang roti untuk preferensi Anda.
Jika memang untuk itu, Anda akan menyetelnya sekali dan tidak akan pernah mengubahnya kecuali
Anda membuat roti panggang untuk orang lain. Kesalahan mode jarang terjadi.
Namun, kontrol Kegelapan disalahartikan: mengatur waktu bersulang, bukan bersulang
kegelapan. Untuk jenis roti tertentu, waktu memanggang lebih lama berarti roti lebih gelap,
tetapi pengaturan yang sama yang mengubah roti Prancis menjadi karbon berasap hampir tidak menghangat
Vollkornbrot Jerman. Kontrol Kegelapan benar-benar untuk berbagai jenis roti,
bukan pengguna yang berbeda. Sebagian besar kesalahan mode terjadi saat Anda lupa menyetel ulang pemanggang roti
saat memanggang roti yang berbeda dari sebelumnya.
Untuk menghilangkan kesalahan mode pemanggang roti, kita dapat membuat model pemanggang roti dengan
ing Anda mengatur waktu setiap waktu. Kedengarannya membosankan sampai Anda menyadari bahwa mikro-
oven gelombang melakukan persis seperti itu. Desainer pemanggang roti berasumsi bahwa pengguna tetap menggunakannya
jenis roti, sementara desainer oven microwave berasumsi bahwa pengguna memanaskan suatu variasi
makanan dalam urutan yang tidak dapat diprediksi.

Halaman 288

274 Bab 6 Interaksi Bloopers

Gambar 6.30

CorelDraw: opsi menggambar yang secara kolektif disebut "Mode".

Menghindari Blooper48

Mode merusak kegunaan perangkat lunak dalam tiga cara:

1. Mereka meminta pengguna untuk mengerahkan upaya mental untuk melacak arus
mode.
2. Mereka menyebabkan pengguna melakukan kesalahan mode.
3. Mereka membatasi tindakan pengguna yang valid dalam mode saat ini.

Dua yang pertama jelas merupakan masalah. Yang ketiga bisa jadi masalah atau a
fitur, tergantung pada niat desainer dan kebutuhan pengguna.

Hilangkan mode dengan menghapus pengaturan mode

Rancang UI aplikasi Anda untuk meminimalkan jumlah setelan mode — mungkin

hilangkan sama sekali. Rencanakan alternatif modeless. Anda mungkin harus menambahkan tetapi-
ton atau menu untuk melakukan ini, tetapi itu akan terbayar. Kecelakaan pesawat yang dijelaskan di atas
tidak akan terjadi jika autopilot memiliki dua dial: satu untuk rate of
keturunan dan lainnya untuk ketinggian target.

[Link] 209/315
26/2/2021 Tanpa judul

Halaman 289

Membebani memori pengguna 275

Satu kasus menggambarkan bagaimana moda dapat dihindari atau dampaknya dikurangi.
Sebuah perusahaan sedang mengembangkan browser untuk data bisnis. Data ditampilkan
di tingkat tinggi, dalam tabel. Pengguna dapat memindai tabel, memilih kolom yang menarik,
baris, atau sel, dan "lihat perincian" untuk melihat detailnya.
Pengembang ingin pengeboran menjadi mudah, jadi mereka membuat
mengklik kolom atau baris menelusuri ke dalamnya. Mereka juga menginginkannya
mudah bagi pengguna untuk mengebor hingga -untuk kembali ke yang lebih tinggi pandangan tingkat data. Mereka
membuat klik dua kali lakukan itu juga, dan termasuk mode arah bor untuk mengontrol
apakah klik dua kali dibor ke bawah atau ke atas. Tombol pada bilah alat browser
mengubah mode arah latihan antara "atas" dan "bawah".
Mode arah latihan sangat buruk. Pengguna tidak ingat mode mana
browser aktif, meskipun ditampilkan di bilah alat. Mereka sering mengebor
cara yang salah: “Ups! Saya ingin turun, bukan naik. ”
Untuk menghilangkan kesalahan mode pengguna, ada dua alternatif:

1. Klik dua kali selalu bor ke bawah. Untuk pengeboran, letakkan tombol KEMBALI, menu
tingkat di atas yang sekarang, atau jalur runut tautan navigasi di
toolbar.
2. Klik dua kali bor ke bawah, tetapi Shift – klik dua kali latihan ke atas. Ini membuat
mode kontrol taktil dan pegas, sangat mengurangi kemungkinan a
kesalahan mode.

Minimalkan penggunaan dan dampak kotak dialog modal

Gunakan kotak dialog modal dengan hemat. Jangan batasi tindakan pengguna saat berdialog
kotak ditampilkan kecuali sangat penting bahwa pengguna tidak berinteraksi dengan hal-hal lain di
pajangan. Setiap batasan harus dibuat sesempit mungkin; jangan blokir pengguna
akses ke data atau kontrol yang tidak relevan dengan kotak dialog. Gunakan berbagai
jenis modal-an sebagai berikut:

■
Bukan modal: sebagian besar waktu
■
Modal induk: sesuai kebutuhan
■
Modal aplikasi: sesekali
■
Modal atau modal sistem: hampir tidak pernah

Hindari urutan paksa atau pembatasan sementara pada tindakan pengguna

Hindari meminta pengguna untuk melakukan berbagai hal dalam urutan yang telah ditentukan sebelumnya. Hindari sementara
membatasi tindakan yang valid.
Fungsi Pindah dapat diubah atau dimodelkan. Dengan fungsi Pindah yang dimodifikasi
Saat ini, pengguna mengindikasikan "Pindahkan ini ke sana, " dengan perangkat lunak dalam satu mode
sementara itu menunggu ini dan yang lainnya sementara itu menunggu di sana . Itu
Bentuk “sorot, seret, dan lepas” dari Pindah dimodifikasi, tetapi hampir tidak terlihat.
Kemampuan Pindah modeless menggunakan perintah Potong dan Tempel terpisah, dengan no
mode intervensi.

Halaman 290

276 Bab 6 Interaksi Bloopers

Mode sulit dihindari

Sebagian besar aplikasi perangkat lunak memiliki beberapa jenis mode. Hampir tidak mungkin
untuk merancang perangkat lunak yang sepenuhnya modeless. Mode biasanya memiliki kelebihan
serta kekurangannya, jadi keputusan apakah akan memiliki mode sering a
desain trade-off [Johnson, 1990].

Keuntungan mode

Mode memungkinkan pengguna menentukan informasi sebelumnya. Menggunakan perintah dalam aplikasi
membutuhkan (a) memilih perintah yang diinginkan dan (b) menyetel perintah itu
pilihan. Tanpa prespecification — tanpa mode — memilih perintah dan
pengaturan opsi yang diinginkan dapat memerlukan input verbose, vocab perintah besar
ularies, atau banyak tombol dan kontrol. Dengan membiarkan pengguna menentukan perintah sebelumnya,

[Link] 210/315
26/2/2021 Tanpa judul
options, atau key interpretations, moded user interface memungkinkan untuk:

■ Kontrol terser: Opsi yang seharusnya harus ditentukan pengguna berulang kali
dapat ditentukan sebelumnya sekali dalam mode, yang berlaku untuk tindakan selanjutnya
sampai mode diubah.
■
Kosakata perintah yang lebih kecil dan susunan kontrol: Perintah yang sama
atau kontrol dapat memiliki efek berbeda dalam mode berbeda.
■ Lebih banyak panduan untuk pengguna: Software dapat mengarahkan pengguna melalui yang telah ditentukan sebelumnya
urutan di mana hanya tindakan tertentu yang mungkin di setiap langkah. Modal
kotak dialog adalah kasus khusus: hanya ada satu langkah, tetapi ini adalah salah satu langkah
desainer benar-benar ingin pengguna mengambil.
■
Keamanan: Mode dapat digunakan untuk mengunci fungsi tertentu untuk mencegah kecelakaan
penggunaan gigi. Kunci pemicu pada senjata dan panel peluncuran rudal nuklir adalah
contoh kontrol mode keamanan.
■ Mengenali operasi luar biasa: Banyak UI dirancang seolah-olah semuanya berfungsi
tions yang mereka berikan sama pentingnya atau mungkin. Mode dapat membantu membuatnya
jelas di UI bahwa operasi tertentu luar biasa.

Kekurangan mode

Meskipun moda memiliki kelebihan, mereka juga memiliki biaya, yang ditanggung oleh
pengguna. Ketika produk atau layanan perangkat lunak memiliki mode, penggunanya harus:

■ Pengaturan mode preplan: Sebelum Anda membutuhkan mode, Anda harus memikirkannya
atur itu.
■
Mode pengaturan : Mode pengaturan memerlukan tindakan ekstra yang asing bagi
tugas yang didukung perangkat lunak. Ini bisa membosankan dan mengganggu jika perangkat lunak
sering kali tidak dalam mode yang Anda butuhkan.
■ Ingat mode saat ini: Anda harus melacak mode apa itu
perangkat lunak dalam.

Halaman 291

Mengambil kendali dari pengguna 277

■
Pulihkan dari kesalahan mode: Jika Anda gagal melakukan salah satu dari tiga item pertama
dan membuat kesalahan, Anda harus membersihkannya sesudahnya.
■
Menghasilkan kendali perangkat lunak : Ketika perangkat lunak "mendorong" suatu tugas, membatasi
apa yang dapat Anda lakukan di setiap langkah, Anda harus menerimanya, meskipun Anda mungkin
lebih suka menjadi orang yang memegang kendali.

Buat indikator mode sulit untuk dilewatkan

Jika suatu aplikasi memiliki mode, itu harus menunjukkan mode saat ini dengan jelas,
seperti yang direkomendasikan dalam dua buku pegangan desain UI klasik dan berpengaruh:

Penunjuk Mode. INDIKATOR MODE TAMPILAN — Saat sistem beroperasi

dalam mode khusus yang memiliki sekumpulan perintah atau aturan sintaks yang berbeda
efek, memberi pengguna indikator yang membedakan mode ini dari yang lain
mode. Berikan perbedaan dalam tajuk, format, atau petunjuknya, dan gunakan label untuk
mengingatkan pengguna tentang mode yang berlaku. [Brown, 1988]

Tampilan Mode Operasi —Ketika konteks untuk kontrol urutan ditetapkan

dalam hal mode operasional yang ditentukan, ingatkan pengguna tentang mode saat ini….
[Smith dan Mosier, 1986]

Indikator mode terbaik adalah pegas: selama pengguna memegang kunci atau
pedal turun, mode alternatif sedang berlaku. Saat pengguna melepaskan, mode
kembali ke "normal". Mode pegas yang umum adalah Shift dan Kontrol
tombol pada keyboard komputer dan pedal Sustain pada piano. Dengan musim semi-
mode dimuat, pengguna merasakan mode apa yang sedang berlaku.
Sebaliknya, tombol Caps Lock pada keyboard tidak pegas: itu tombol-
pada mode toggle-off. Jika indikator mode tidak memiliki pegas, keduanya juga harus
ditempatkan tepat di tempat pengguna atau menjadi besar dan menarik perhatian. Tidak berhasil
untuk meletakkan indikator mode kecil di sudut layar: tidak ada yang akan melihatnya.

Mengambil kendali dari pengguna

Tiga kesalahan besar interaksi terakhir adalah cara perangkat lunak mengambil kendali
pengguna.

[Link] 211/315
26/2/2021 Tanpa judul
Blooper 49: Pengaturan ulang tampilan secara otomatis

Bayangkan editor dokumen yang secara otomatis menggulir dokumen Anda

baris yang Anda edit berada di tengah layar. Jika Anda meletakkan kursor
pada baris di dekat bagian bawah layar dan mulai mengetik, dokumen akan melakukannya
bergeser sehingga garis yang Anda ketikkan berada di tengah layar. Kebanyakan orang
akan menganggap ini mengganggu dan membingungkan. Dua variasi dari kesalahan ini adalah
umum.

Halaman 292

278 Bab 6 Interaksi Bloopers

Variasi A: Cara mengganggu pengguna: mengatur ulang data mereka

Editor dokumen yang dijelaskan di atas memindahkan data pengguna sendiri

prakarsa. Berapa lama Anda akan sering mentolerir Windows, MacOS, atau Linux
mengatur ulang ikon desktop untuk Anda? Tidak lama! Ketika perangkat lunak melakukan ini, pengguna
lupa di mana mereka berada dan apa yang baru saja mereka lakukan. Itu juga mengganggu mereka.
Pengguna lebih bingung saat tampilan diatur ulang dengan sangat cepat.
Ketika perubahan besar terjadi dalam sekejap mata, pengguna tidak yakin apa yang terjadi
menulis. Di sisi lain, jika tampilan diperbarui terlalu lambat, mereka menjadi frustrasi
karena harus menunggu. Ketika desainer UI mencoba mengatur ulang data pengguna untuk mereka, mereka
sedang memasuki bidang ranjau antarmuka pengguna.
Banyak perancang dan pengembang masuk ke bidang tambang ini dan berakhir dengan
blooper ini. Ini biasa terjadi dalam aplikasi yang memanipulasi kompleks, terstruktur
data. Berikut beberapa contohnya:

■
Browser kelas Java menampilkan grafik pohon dari hierarki kelas. Kapan
Anda mengganti nama kelas, seluruh pohon ditampilkan kembali, disusun ulang sehingga kelas tersebut
cabang masih dalam urutan abjad (Gambar 6.31). Menambah atau menghapus
kelas juga mengatur ulang pohon.
■
Prosesor garis besar atau browser direktori file dapat memperluas atau mengontrak item
untuk menampilkan atau menyembunyikan subitem. Beberapa berkembang dan menyusut saat Anda mengeksekusi
perintah yang tidak terkait dengan perluasan atau penyusutan. Misalnya, jika Anda mengatur
gaya font untuk item level 3 secara garis besar, prosesor garis besar mungkin
secara otomatis memperluas keseluruhan garis ke tingkat 3. Jika Anda menyeret
item dari satu folder ke folder lain dalam hierarki file, beberapa browser file
secara otomatis memperluas folder tujuan agar Anda dapat melihat apa yang ada di dalamnya.
■
Program menggambar sering kali memungkinkan objek grafik dibuat berlapis. Dalam beberapa undian-
menggunakan program, cukup mengubah atribut objek grafis, seperti warna,
lebar garis, atau pola isian, menyebabkannya dipindahkan ke lapisan atas. Ini adalah
biasanya bukan yang Anda inginkan.

Gambar 6.31
X Node F diganti namanya menjadi A X

C F SEBUAH C

saya J K L M K L M saya J

Hierarki kelas, sebelum dan sesudah kelas F diganti namanya menjadi A: subpohon ditukar secara otomatis.

Halaman 293

Mengambil kendali dari pengguna

[Link] 212/315
26/2/2021 Tanpa judul
279

Gambar 6.32 Setelah

Sebelum
Skala ulang

Maksimum lama
Maksimum lama Maksimum baru

Titik data maksimum baru muncul

Grafik mengubah skala sumbu vertikal secara otomatis ketika titik data tiba atau pergi.

■
Fungsi grafik data menunjukkan bagaimana nilai berubah seiring waktu. Grafik seperti itu
biasanya menambahkan titik data baru secara berkala di salah satu ujung dan menggulir grafik
perlahan menuju ujung lainnya. Beberapa secara otomatis menskalakan sumbu vertikal untuk diisi
tinggi jendela (Gambar 6.32). Ini mungkin tampak membantu, tetapi membingungkan
enting jika grafik secara otomatis mengubah skala ketika titik data baru yang mewakili
maksimum baru muncul atau ketika maksimum yang ada bergeser ke luar layar.

Aplikasi memindahkan dan mengatur ulang data pengguna karena dua alasan yang sangat berbeda:

1. Pengembang yang bermaksud baik tetapi naif: Pengembang mungkin percaya bahwa pengguna
akan mengatur ulang data, jadi mengatur ulang secara otomatis menyimpan
mereka masalah. Salah!
2. Penerapan yang terlalu sederhana: Pengembang mungkin tidak punya waktu untuk memikirkan caranya
untuk membatasi pembaruan hanya pada apa yang diubah oleh pengguna. Mereka mengkodekan tampilan untuk merekomendasikan
pute, format ulang, dan tampilkan kembali sepenuhnya ketika ada perubahan.

Variasi B: Kontrol bergerak

Variasi kedua dari kesalahan besar terjadi ketika perangkat lunak bergerak secara otomatis
Kontrol GUI di sekitar layar. Saat kontrol bergerak sendiri,
pengguna tidak yakin di mana menemukannya. Kontrol bergerak juga mengurangi perasaan pengguna
memegang kendali. Jenis umum dari kontrol yang bergerak secara otomatis adalah:

■
Jendela otonom: Windows dipindahkan atau diubah ukurannya oleh perangkat lunak.
■ Kursor melengkung: Kursor tiba-tiba melompat ke posisi baru.
■
Tab menari: Baris tab bertukar tempat saat pengguna mengklik tab di baris belakang.
■ Menu dinamis: Perintah dalam menu muncul dan menghilang, seringkali secara misterius.

Kontrol yang bergerak secara otomatis adalah blooper kontrol GUI serta interac-
si blooper.

Halaman 294

280 Bab 6 Interaksi Bloopers

Gangguan terkait: Posisi kontrol bervariasi antar panel

Beberapa tahun yang lalu, papan pesan Yahoo memasang tautan tertentu di tempat yang berbeda
halaman yang berbeda. Setiap halaman pesan memiliki iklan spanduk di bagian atas. Tautan
ke posting berikutnya dan sebelumnya dalam topik berada di bawah iklan. Iklannya bervariasi
tinggi, sehingga tautan navigasi bergerak ke atas dan ke bawah dari satu halaman ke halaman berikutnya. Kamu
tidak bisa begitu saja menempatkan kursor di atas "Berikutnya" dan mengklik pesan untuk menemukan
yang menarik. Anda harus melihat di mana tautan berada di setiap halaman. Lebih buruk lagi, itu
iklan dipilih secara acak saat halaman ditampilkan, jadi "Berikutnya" dan "Sebelumnya"
bahkan tidak berada di tempat yang sama ketika Anda mengunjungi kembali halaman (Gambar 6.33).
"Blooper" Yahoo mungkin disengaja, untuk memaksa pengguna untuk melihatnya
halaman dan melihat iklan di sana sebelum mengklik ke pesan berikutnya. Tapi jika memang begitu
benar, Yahoo tidak akan memperbaiki masalah ini, seperti yang mereka lakukan di rilis selanjutnya
(Gambar 6.34).
Tampilan atau kontrol informasi harus berada tepat di tempat yang sama pada masing-masing
halaman, sehingga pengguna tahu di mana menemukannya.

Gambar 6.33

[Link] 213/315
26/2/2021 Tanpa judul

[Link] (2000): posisi link "Sebelumnya" dan "Berikutnya" berubah antar halaman.

Gambar 6.34

[Link] (2006): posisi tautan “Sebelumnya” dan “Berikutnya” selalu sama.

Halaman 295

Mengambil kendali dari pengguna 281

Menghindari Blooper49

Kesalahan besar ini melanggar dua prinsip GUI: "layar milik pengguna" dan
“Pertahankan kelembaman tampilan” (Prinsip Dasar 7, halaman 41).

Layar itu milik pengguna

Pengguna berharap tampilan berada di bawah kendali mereka. Ketika perangkat lunak berubah juga
dengan sendirinya, pengguna menjadi bingung, frustrasi, dan jengkel. Ini adalah
terutama berlaku untuk aktivitas yang membutuhkan koordinasi tangan-mata, seperti bergerak
menggunakan kursor atau mengubah ukuran jendela. Ini juga berlaku untuk mengatur data pengguna,
seperti tata letak ikon di desktop, urutan file atau pesan email di
folder, pemformatan teks atau grafik, atau tingkat perluasan garis besar.
Jangan mencoba terlalu membantu: jangan mengatur ulang tampilan untuk pengguna; biarkan mereka
mengatur tampilan. Berikan perintah "mengatur ulang" atau "memformat ulang" yang eksplisit
pengguna memulai. Contoh dari perintah tersebut adalah MacOS Clean-up Desktop
perintah dan fungsi Balance atau Align dari editor grafis. Sebaliknya,
Pemformatan ulang teks otomatis Microsoft Word sangat mengganggu banyak pengguna
matikan jika mereka tahu caranya.

Pertahankan inersia tampilan

Mempertahankan inersia tampilan berarti bahwa saat pengguna mengubah sesuatu, sebagian besar
tampilan harus tetap tidak berubah. Perubahan data yang kecil dan terlokalisasi
seharusnya hanya menghasilkan perubahan kecil yang dilokalkan pada tampilan.
Ketika perubahan besar atau nonlokal pada tampilan diperlukan (seperti repag-
menginasi dokumen atau menukar posisi cabang pohon keluarga),
mereka tidak boleh seketika. Mereka harus diumumkan dengan jelas dan diumumkan
selesai jadi pengguna:
■
melihat dan memahami perubahan dan
■
dapat terus bekerja.
Animasi bisa membantu. Ini memberikan kontinuitas visual: pengguna melihat satu objek
berubah daripada objek baru menggantikan yang lama. Namun, menganimasikan perubahan
tidak berarti memaksa pengguna untuk menunggu yang lambat dan menjengkelkan selesai. Orang-orang
dapat merasakan gerakan halus bahkan jika itu terjadi dalam sepersekian detik.
Perilaku default saat penskalaan ulang harus menjaga grafik tetap sama
skala hingga pengguna meminta perangkat lunak untuk mengubah skala. Penskalaan otomatis bisa menjadi
pilihan, tetapi seharusnya bukan perilaku default.

Blooper 50: Kotak dialog yang menjebak pengguna

[Link] 214/315
26/2/2021 Tanpa judul
Kotak dialog
tidak mau terkadang
pergi. tidakbesar
Kesalahan memberikan
ini hadir jalan
dalamkeluar selain arahan
lima variasi [Link] digunakan pengguna

Halaman 296

282 Bab 6 Interaksi Bloopers

Variasi A: Tidak Ada "Batal"

Apakah Anda pernah memulai operasi, tetapi ketika Anda melihat apa yang terjadi,
kamu ingin menghentikannya? Jika perangkat lunak tidak memberi Anda cara untuk membatalkan operasi,
itu menunjukkan variasi pertama dari kesalahan "pengguna menjebak".
Di Adobe PhotoShop, jika Anda mencoba mencetak gambar tetapi printer yang dipilih
tidak cocok dengan pengaturan cetak, muncul peringatan yang menjelaskan ketidakcocokan tersebut.
Tanggapan umum dalam situasi ini adalah: "Uh, oh! Ini akan menjadi printer yang salah.
Saya ingin printer Postscript. ” Sayangnya, kotak dialog peringatan tidak memiliki cara untuk
cel Cetak (Gambar 6.35).

Variasi B: Semua jalur salah

Beberapa kotak dialog menyediakan lebih dari satu opsi, mungkin termasuk cara untuk
batalkan, tetapi hilangkan satu atau beberapa opsi yang diinginkan beberapa pengguna.
Jika pengguna Macintosh mencetak dokumen tetapi printer kehabisan kertas,
MacOS menampilkan peringatan yang menawarkan beberapa opsi (Gambar 6.36). Mereka semua
melibatkan penghentian atau penghapusan pekerjaan cetak. Printer sudah berhenti; menunggu-
mencari lebih banyak kertas. Mengapa pengguna tidak bisa memuat lebih banyak kertas ke dalam printer dan
terus?

Variasi C: Tombol yang diperlukan tidak aktif

Kotak dialog tidak dapat memberikan jalur yang diinginkan pengguna karena beberapa opsinya
tidak aktif. Saat iPhoto Apple mengalami masalah yang ingin dilaporkan
ke Apple, ini menampilkan jendela dan meminta Anda untuk menjelaskan apa yang Anda lakukan
saat masalah terjadi, kirimkan laporan ke Apple. "Kirim ke Apple"
tombol awalnya tidak aktif dan seharusnya aktif saat Anda mengetikkan deskripsi
, tetapi seringkali tetap tidak aktif sehingga Anda tidak dapat mengirimkan laporan (Gambar 6.37).

Variasi D: Pilihan tidak jelas

Beberapa kotak dialog menyediakan pilihan yang diperlukan, tetapi sangat membingungkan pengguna
merasa terjebak atau harus berhenti dan berpikir keras tentang pilihan mana yang mereka pilih
ingin.

Gambar 6.35

Adobe PhotoShop: Peringatan pengaturan cetak tidak memberikan "Batal".

Halaman 297

Mengambil kendali dari pengguna 283

Gambar 6.36

[Link] 215/315
26/2/2021 Tanpa judul
Apple MacOS X: Peringatan "Kehabisan Kertas" printer tidak memberikan cara untuk memuat kertas dan melanjutkan.

Gambar 6.37

Apple iPhoto: Tombol "Kirim ke Apple" di jendela Laporan Masalah tetap tidak aktif.

Saat Anda menginstal versi baru klien Skype, Skype menampilkan

kotak dialog sekering (Gambar 6.38). Sebagian besar pengguna dihentikan sementara oleh
kurangnya korespondensi antara pertanyaan dan tombol respons.
Jika kita "mengizinkan versi baru untuk mengakses rantai kunci yang sama", itu adalah perubahan
atau tidak? Juga, mengapa opsi perubahan berlabel "Ubah Semua", bukan hanya
"Perubahan?"
Kotak dialog untuk membatalkan sesuatu — janji temu, transaksi, reservasi-
tions — sering kali membingungkan. Tombol mana yang membatalkan pembatalan dan yang mana
tombol menyelesaikan pembatalan?
Dua contoh klasik adalah halaman "Batalkan Janji Temu" dari Palo Alto
Sistem janji temu online Yayasan Medis (Gambar 6.39A) dan Batal
Kotak dialog pembayaran dari sistem perbankan online Wells Fargo (Gambar 6.39B).
Anda menyuruhnya untuk membatalkan sesuatu — janji temu atau pembayaran — dan itu
memainkan kotak dialog Pembatalan. Petunjuk di kotak dialog mengatakan bahwa "Kirim"
menjalankan pembatalan dan "Batal" membatalkan pembatalan, tetapi komputer
pengguna tidak membaca, mereka memindai, jadi sebagian besar tidak akan melihat petunjuknya.

Halaman 298

284 Bab 6 Interaksi Bloopers

Gambar 6.38

Skype: kotak dialog membingungkan — pertanyaan dan tombol menggunakan istilah yang berbeda.

Gambar 6.39

SEBUAH B
Dialog Batal: "Kirim" membatalkan dan "Batal" membatalkan pembatalan. (A) [Link]: batal
janji. (B) Wells Fargo online: batalkan pembayaran.

Aplikasi perdagangan saham memiliki salah satu dari Pembatalan Pembatalan yang membingungkan ini
kotak dialog. Para pengembang berpendapat bahwa itu logis dan konsisten

[Link] 216/315
26/2/2021 Tanpa judul
kotak dialog lainnya: "'OK' menyetujui operasi saat ini, yang terjadi pada
menjadi operasi Batal, dan 'Batal' membatalkannya. ” Akhirnya, mereka mengakui itu
pengguna mungkin bingung tentang tombol mana yang harus ditekan. Karena itu adalah saham
aplikasi perdagangan, penting untuk menghilangkan kebingungan tentang yang mana
tombol dibatalkan dan mana yang tidak. Dalam versi rilis, tombol
diberi label "Batalkan Pesanan" dan "Lanjutkan Pesanan".

Variasi E: Tidak, tidak OK

Ada kotak dialog yang mengumumkan bahwa sesuatu yang buruk telah terjadi,
atau akan terjadi, dan menanyakan apakah itu OK (Gambar 6.40). Semua yang bisa Anda lakukan
adalah desahan (atau kutukan), OK pesannya, dan mulai lagi. Bahkan ketika kasus seperti itu terjadi
sebenarnya tidak dapat dihindari, memberi label pada tombol pengakuan "OK" begitu saja
garam di lukamu. Tidak, ini tidak baik.
Adobe InDesign (Gambar 6.41) membuat blooper yang sama, tetapi setidaknya Anda bisa
memulihkan pekerjaan yang hilang.

Halaman 299

Mengambil kendali dari pengguna 285

Gambar 6.40

Pesan kesalahan menjebak pengguna. Tidak ada pilihan selain mengklik "OK" dan kehilangan data.

Gambar 6.41

Adobe InDesign: pesan kesalahan menjebak pengguna. Tidak ada pilihan selain mengklik "Oke".

Contoh yang kompleks, dibedah

Beberapa kotak dialog mencampurkan variasi blooper. Di sini, kami memeriksanya

detail, untuk lebih memahami kesalahan besar ini dan bagaimana hal itu merusak kegunaan.
Jika Anda mencoba membuka dokumen Microsoft Word yang sudah terbuka, file
kotak dialog menanyakan apakah Anda ingin kembali ke versi dokumen yang disimpan
(Gambar 6.42). Hah?
Anda bisa tiba di sini dengan salah satu dari tiga tujuan:

1. Anda tidak tahu bahwa dokumen itu sudah dibuka. Membukanya dua kali adalah sebuah
kecelakaan. Anda ingin membatalkan pembukaan kedua. Itu tidak jelas,
tetapi untuk melakukannya, Anda mengklik "Tidak."
2. Anda tahu dokumen itu sudah terbuka dan ingin mengganti versinya
Anda sedang mengedit dengan versi terakhir yang disimpan. Untuk melakukan itu, Anda klik "Ya".
3. Anda tahu dokumen itu sudah terbuka, tapi ingin membuka yang terakhir disimpan
versi di jendela terpisah untuk membandingkan keduanya. Kamu tidak boleh melakukan itu.

Satu masalah dengan kotak dialog ini adalah hanya menyediakan dua dari tiga kotak
tujuan pengguna. Jika Anda memiliki tujuan ketiga, itu melakukan kesalahan besar yang menjebak Anda:
tidak ada opsi yang Anda inginkan.
Masalah yang lebih buruk dengan kotak dialog adalah pelabelannya yang tidak jelas. Jelas
bahwa "Ya" sesuai dengan tujuan 2 (kembali ke versi sebelumnya), tetapi itu
tidak jelas apa artinya "Tidak". Ini mirip dengan Blooper 2 (halaman 62): ini
sulit untuk menyimpulkan arti dari respon "negatif" dari itu
Yang "positif".
Jika pengguna tiba di kotak dialog ini dengan tujuan 1 atau 3, mereka akan menatap dialog tersebut
kotak untuk sementara waktu, membaca dan membacanya kembali sampai mereka yakin akan hal itu

[Link] 217/315
26/2/2021 Tanpa judul

Halaman 300

286 Bab 6 Interaksi Bloopers

Gambar 6.42

Microsoft Word: upaya untuk membuka dokumen yang sudah terbuka menampilkan kebingungan
kotak dialog.

Gambar 6.43

Kotak dialog Excel untuk membuka kembali file hanya sedikit lebih baik daripada Word.

kebalikan dari "kembali ke simpanan" adalah apa yang mereka inginkan, dan terakhir klik "Tidak." Jika mereka
ingin membatalkan operasi Terbuka (gol 1), mereka akan beruntung karena itu
apa yang dilakukan "Tidak". Mereka membuang-buang waktu, tetapi setidaknya mereka mendapatkan apa yang mereka inginkan.
Pengguna yang ingin membuka versi tersimpan dokumen dalam baru -menang
dow (sasaran 3) akan sangat bingung dengan apa yang terjadi ketika mereka mengeklik "Tidak":
tidak ada. Mereka mungkin berasumsi bahwa jendela baru terbuka di atas yang lama dan
geser jendela ke samping untuk melihat apa yang ada di bawahnya. Mereka mungkin akan mencoba lagi di
asumsi bahwa ada yang tidak beres pertama kali. Mereka mungkin akan tahu
tujuan 3 itu tidak didukung. Bagaimanapun, mereka akan membuang-buang waktu untuk berpikir
tentang perangkat lunak. Sebagian besar pengguna akan jarang menemukan kotak dialog ini, jadi selanjutnya
saat itu terjadi, mereka tidak akan mengingat apa yang “Tidak” lakukan, jadi mereka akan melakukannya
semuanya lagi.
Perancang kotak dialog ini berasumsi bahwa pengguna tahu kebalikannya
dari "kembali ke disimpan" adalah. Mungkin tidak terpikir oleh perancang bahwa pengguna mungkin
tiba di kotak dialog dengan tujuan 3.
Kotak dialog "dokumen sudah terbuka" Microsoft Excel hanya sedikit lebih baik.
Ada baiknya itu dimulai dengan mengatakan bahwa file yang Anda coba buka sudah terbuka
(Gambar 6.43). Namun, untuk mengetahui apa yang dilakukan "Tidak" dan "Ya", Anda harus membaca
cetakan kecil. Sebagian besar pengguna tidak akan; mereka akan melompat ke tombol sampai mereka menyadarinya
bahwa mereka tidak tahu fungsi tombolnya. Juga, "Ya" (buang perubahan) sebagai a
default salah.

Menghindari Blooper50

Sediakan alternatif yang memadai bagi pengguna agar mereka tidak merasa terjebak. Beri label
pilihan dengan jelas sehingga jelas apa pilihannya.

Halaman 301

Mengambil kendali dari pengguna 287

Analisis itu! Bandingkan opsi yang tersedia dengan kemungkinan sasaran pengguna

Lakukan analisis seperti di atas: buat daftar semua sasaran yang dapat dimiliki pengguna saat
kotak dialog muncul. Mengetahui tujuan yang mungkin membantu Anda memberikan hak
opsi dan beri label dengan jelas. Kotak dialog Excel dapat diubah urutannya
menjadi sebening kristal (Gambar 6.44).
Bahkan dengan instruksi dan label yang sangat jelas, kotak dialog tetap dihilangkan
satu tujuan yang mungkin: membuka dokumen di jendela baru. Idealnya, Word dan
Excel harus menyediakan opsi itu, tetapi sebenarnya tidak, sehingga kotak dialog tidak bisa menawarkan
saya t. Pelabelan harus menjelaskan pilihan apa yang ditawarkan, sehingga pengguna yang menginginkan file
pilihan yang hilang tidak akan percaya salah satu yang ditawarkan itu.

Kemudian uji!

[Link] 218/315
26/2/2021 Tanpa judul

Uji kotak dialog untuk memastikan pengguna memahaminya dan semua yang diperlukan
pilihan disediakan. Kotak dialog dapat diuji secara informal jauh sebelumnya
diimplementasikan dengan menunjukkan sketsa yang digambar tangan kepada pengguna, menjelaskan kapan
kotak dialog ditampilkan, dan meminta pengguna untuk menafsirkan pesan dan apa
maksud tombolnya. Jika mereka harus berhenti dan berpikir, desain ulang kotaknya. Kapan lagi
perangkat lunak telah dirancang, kotak dialog dapat diuji dalam konteksnya
aplikasi menggunakan gambar layar tercetak atau prototipe yang berfungsi. Akhirnya,
mereka dapat diuji di produk yang sedang berjalan sebelum rilis.

Buruk: “Pekerjaan Anda akan hilang. [BAIK?]"

Pengembang perangkat lunak harus berusaha keras untuk menghindari situasi di mana hanya satu
pilihan yang tidak menyenangkan tersedia. Seringkali, ini hanya masalah memastikan itu
aplikasi menangkap semua kondisi kesalahan yang bisa muncul, sehingga penanganannya
mereka tidak didelegasikan ke sistem operasi.
Jika hanya ada satu pilihan tidak menyenangkan yang tersedia, jangan berpura-pura bahwa itu adil
pengumuman yang ramah. Secara teknis, baik “Anda memiliki email baru” dan “Pro-
gram jatuh dan kehilangan semua pekerjaan Anda yang belum disimpan ”adalah pengumuman fakta, tapi
pengguna menganggapnya berbeda. Beri label tombol pengakuan "OK" untuk
sebelumnya, tapi sesuatu seperti "Diakui" atau "Dimengerti", atau bahkan "Sigh…
Aku benci komputer! ” untuk yang terakhir.

Gambar 6.44

Kotak dialog Excel yang ditulis ulang: tidak membuat pengguna berpikir.

Halaman 302

288 Bab 6 Interaksi Bloopers

Blooper 51: "Batal" tidak membatalkan

Kotak dialog memungkinkan pengguna melihat dan mengatur opsi perintah dan properti objek.
Mereka harus memiliki setidaknya dua tombol:

■ Terapkan perubahan, tutup kotak dialog, dan lanjutkan dengan perintah (jika ada)
■
Buang pengaturan yang diubah dan tutup kotak dialog

Tombol pertama biasanya diberi label "OK," tetapi terkadang diberi label dengan
perintah yang menampilkan kotak dialog, misalnya "Cetak". Tombol kedua adalah
biasanya berlabel "Batal".
Pengguna mengharapkan "Batal" untuk "melupakan" semua perubahan yang mereka buat dalam dialog
kotak sejak mereka membukanya atau mengklik tombol "Terapkan" (jika tersedia). Tapi
beberapa tombol "Batal" tidak membatalkan. Jika "Batal" tidak membatalkan,
Tombol “OK” dan “Cancel” memiliki arti yang sama: tutup kotak dialog
dan pertahankan perubahannya. Itu blooper.
Blooper tidak ada dalam kode yang dijalankan saat pengguna mengklik "Batal",
yang biasanya hanya menutup kotak dialog. Masalahnya ada pada apa yang terjadi
sebelumnya , ketika pengguna mengedit pengaturan di kotak dialog.

Variasi A: Kotak dialog langsung mengedit data aplikasi

Terkadang blooper disebabkan oleh implementasi yang sederhana: kotak dialog

langsung mengedit data aplikasi, bukan salinannya . Membatalkan seperti itu
perubahan tidak mungkin terjadi kecuali mekanisme Urung yang canggih telah dibangun
ke dalam aplikasi, yang jarang terjadi.
Kesalahan ini sangat umum terjadi ketika kotak dialog memanipulasi kompleks
data aplikasi, seperti tabel. Pemrogram sering kali tidak repot-repot menyalin
struktur data plex ke dalam kotak dialog, sehingga perubahan pada kotak dialog mempengaruhi
data aplikasi secara langsung.
Blooper ini juga terlihat ketika tindakan di kotak dialog memiliki efek samping
di luar aplikasi, seperti membuat atau menghapus file disk.

Variasi B: Beralih antar panel tab menyimpan perubahan

[Link] 219/315
26/2/2021 Tanpa judul
Tombol
mengubah "Batal" yangtab
dari satu tidak membatalkan
ke tab sering muncul
lainnya menerapkan di kotak
perubahan dialog
yang Andabertab:
buat dihanya
panel pertama
sebelum beralih ke yang baru, seolah-olah Anda mengeklik "Terapkan". Pada saat Anda mengklik
"Batal," perubahan telah disimpan. Pemrogram sering menerapkan
panel tab dengan cara ini untuk menghindari penyimpanan data untuk satu panel saat menampilkan
lain. Apa pun alasannya, itu tetaplah blooper.
Pengguna menganggap tab sebagai mekanisme navigasi (Blooper 4, halaman 67). Mereka
jangan berharap berpindah tab untuk mengubah data aplikasi. Mereka tidak akan mengerti
mengapa beberapa pengaturan yang diubah dibatalkan dan beberapa tidak; mereka akan berasumsi
bahwa mereka menemukan bug.

Halaman 303

Mengambil kendali dari pengguna 289

Variasi C: Wizard memiliki efek samping yang tidak dibatalkan "Batal"

Wizard adalah kotak dialog multi halaman. Penyihir mengarahkan pengguna menuju tujuan, pecahkan
pilihan dan keputusan turun ke dalam urutan langkah-langkah sederhana, dengan instruksi
sepanjang jalan.
Setiap halaman wizard harus memiliki tombol "Batal" selain "Berikutnya"
dan kembali." Mengklik "Batal" menutup wizard dan membatalkan operasi.
Namun, beberapa penyihir tidak membatalkan semua yang dilakukan pengguna sebelum mengeklik
"Membatalkan."
Pertimbangkan seorang wizard untuk membuat situs Web. Setiap langkah menawarkan opsi atau pengumpulan
konten untuk situs, dan setelah wizard selesai, situs dibuat. Jika kamu
batalkan wizard lebih awal, tidak ada situs atau situs yang dibangun sebagian yang tersisa. Jika dibatalkan
penyihir meninggalkan perubahan, itu blooper.

Variasi D: Kotak dialog bertingkat

Beberapa aplikasi memiliki beberapa tingkat kotak dialog. Jika kotak dialog A ditampilkan
kotak dialog B dan Anda mengedit kotak dialog B dan klik tombol "OK", lalu batalkan
kotak dialog A, apa yang terjadi dengan pengaturan yang Anda ubah di kotak dialog B?
Kotak dialog B bertindak sebagai perpanjangan dari A. Pengaturannya bisa, dalam berbagai cara
desain, telah diletakkan langsung di kotak dialog A, bukan yang terpisah. Jika
dirancang seperti itu, membatalkan kotak dialog akan membatalkan perubahan apa pun.
Mengapa perilaku harus berbeda untuk properti yang disetel dalam dialog terpisah
kotak? Dengan alasan ini, membatalkan kotak dialog A harus membatalkan semua perubahan
dibuat di B. Namun, dalam banyak aplikasi, perubahan sudah dilakukan
efek dan tidak dapat dibatalkan. Itu blooper.

Menghindari Blooper 51

Perubahan dalam kotak dialog tidak boleh diterapkan sampai pengguna mengklik "OK" atau
"Menerapkan." Tidak ada tindakan lain yang menyebabkan data aplikasi diperbarui.
Saat pengguna mengklik "Batal," aplikasi harus persis seperti sebelumnya
saat kotak dialog dibuka atau pengguna terakhir mengklik "Terapkan". Jika dialog
kotak mengubah apa pun di aplikasi atau lingkungan saat terbuka,
"Batal" entah bagaimana harus membatalkan perubahan itu.

Kotak dialog menampilkan salinan pengaturan aplikasi

Kotak dialog harus dimulai dengan salinan pengaturan aplikasi dan biarkan pengguna
edit itu, jadi "Batal" bisa membuang salinannya. “OK” dan “Apply” harus
perbarui data aplikasi dengan data dari kotak dialog. Ini seharusnya
benar terlepas dari kompleksitas data yang dimanipulasi oleh kotak dialog
(Gambar 6.45). Bahkan saat kotak dialog membuka kotak dialog lainnya, setiap tingkat
kotak dialog harus dibatalkan tanpa mempengaruhi data dalam dialog induk
kotak atau aplikasi.

Halaman 304

[Link] 220/315
26/2/2021 Tanpa judul
290 Bab 6 Interaksi Bloopers

Gambar 6.45

"Batal" membatalkan semua perubahan yang dibuat sejak kotak dialog dibuka.

Tab, wizard, dan kotak dialog multilevel tidak

alasan untuk blooper tersebut

Beralih di antara tab hanyalah navigasi; itu seharusnya tidak memperbarui data aplikasi.
Setiap panel harus mempertahankan statusnya hingga kotak dialog ditutup. Tidak ada pengaturan pada
panel apa pun harus diterapkan ke aplikasi sampai pengguna memerintahkannya secara eksplisit.
Anggap saja seperti ini: tab mengatur pengaturan ke dalam kategori. Jika pengaturan
semua dalam satu panel, dikelompokkan dengan kotak kelompok, itu jelas salah
untuk menerapkan perubahan dalam satu kotak grup saat pengguna hanya menggerakkan kursor ke a
kelompok pengaturan yang berbeda. Jika salah untuk kasus itu, itu juga salah untuk disimpan
berubah ketika pengguna beralih tab.
Penyihir yang dibatalkan seharusnya tidak meninggalkan apa pun. Jika seorang penyihir mengatur segalanya
sepotong demi sepotong saat pengguna melakukan langkah-langkah, "Batal" harus menghapus apa pun
telah dibuat dan membatalkan perubahan lainnya. Lebih baik jika seorang penyihir mengumpulkan
masukan pengguna hingga akhir, menyimpan semua perubahan aktual hingga selesai. Dengan begitu,
"Batal" bisa menutup wizard.
Ketika sebuah aplikasi memiliki beberapa tingkat kotak dialog, membatalkan par-
Kotak dialog ent harus membatalkan perubahan yang dibuat dan diterapkan di salah satu
kotak dialog anaknya. Seperti yang dikemukakan sebelumnya, ini masuk akal karena dialog anak
box adalah perpanjangan dari induknya.
Microsoft Outlook Express memiliki kotak dialog untuk menyetel dan mengubah file
properti identitas email pengguna (Gambar 6.46A). Kata sandi identitas disetel
dengan mengklik tombol "Ubah Kata Sandi". Tombol membuka level kedua
kotak dialog untuk mengumpulkan kata sandi baru (Gambar 6.46B). Setelah masuk baru

Halaman 305

Mengambil kendali dari pengguna 291

Gambar 6.46

SEBUAH B
Microsoft Outlook: membatalkan kotak dialog (A) membatalkan perubahan OK di kotak dialog (B).

sandi, Anda mengklik "Oke" atau "Batal". Misalkan Anda setuju dengan dia-
kotak log, lalu batalkan yang pertama. Haruskah identitas email memiliki kata sandi baru
atau tidak?
Outlook melakukan hal yang benar: membatalkan kotak dialog Properti Identitas

[Link] 221/315
26/2/2021 Tanpa judul
membatalkan perubahan kata sandi apa pun OK di kotak dialog Ubah Kata Sandi Identitas.

Halaman 306

Halaman ini sengaja dikosongkan

[Link] 222/315
26/2/2021 Tanpa judul

Halaman 307

Responsivitas
Bloopers
pengantar

Bloopers responsif umum

Alasan respons yang buruk

Menghindari kesalahan besar yang responsif: Prinsip desain

Menghindari bloopers responsif: Teknik

Kesimpulan

293

Halaman 308

294 Bab 7 Responsiveness Bloopers

pengantar

Responsiveness sangat penting dalam menentukan kegunaan perangkat lunak (Basic

Prinsip 8, halaman 45). Itu adalah "daya tanggap", bukan "kinerja" atau "kecepatan".

[Link] 223/315
26/2/2021 Tanpa judul
Bab ini terbatas.
kinerja menjelaskan perbedaan dan cara mencapai ketanggapan saat
Perangkat lunak yang sangat responsif:

■ memberi tahu Anda segera bahwa penekanan tombol Anda, perangkat penunjuk bergerak-
uang, dan klik diterima;
■
memperkirakan berapa lama operasi akan berlangsung;
■ membebaskan Anda untuk melakukan hal-hal lain sambil menunggu;
■
mengelola acara antri dengan cerdas;
■ melakukan pekerjaan rumah tangga dan prioritas rendah di latar belakang;
■
mengantisipasi permintaan Anda.

Daya tanggap berbeda dengan kinerja. Performa adalah seberapa cepat file
perangkat lunak menghitung dan menampilkan hasil . Perangkat lunak berperforma tinggi memberi Anda
hasil dengan cepat; perangkat lunak berkinerja rendah lambat dalam memberikan hasil.
Perangkat lunak dapat menjadi responsif meskipun kinerjanya lambat. Namun,
banyak perangkat lunak di pasar saat ini memiliki kinerja yang lambat dan juga rendah
responsivitas, kombinasi yang buruk.
Kebanyakan blooper responsif tidak dapat diilustrasikan dengan layar perangkat lunak
gambar karena mereka memperhatikan apa yang terjadi seiring waktu. Bab ini menggambarkan
mereka terutama dengan skenario yang menggambarkan komunitas manusia-manusia yang disfungsional.
kation, bersama dengan beberapa contoh visual dan studi kasus.

Bloopers responsif umum

Bloopers responsif semuanya terkait erat, jadi mereka tercantum di sini dan
dibahas bersama, bukan satu per satu. Contoh dari beberapa blooper
ikuti daftarnya.

■
Blooper 52: Cursor tidak mengikuti Anda; itu melompat-lompat saat operat-
Sistem memproses gerakan mouse 1 dan terus bergerak setelah Anda melakukannya
hentikan mouse
■ Blooper 53: Tombol di layar mengenali klik yang terlambat atau tidak sama sekali
■
Blooper 54: Menu, slider, dan scrollbar tertinggal di belakang tindakan Anda, hancurkan-
koordinasi tangan-mata diperlukan untuk operasi yang sukses

1. Dalam bab ini, "mouse" berarti semua alat penunjuk: trackball, touchpad, joystick, dll.

Halaman 309

Bloopers responsif umum 295

■
Blooper 55: Operasi pemindahan dan ukuran tidak mengikuti tindakan Anda
dan tidak memberikan masukan "karet gelang" sementara
■ Blooper 56: Aplikasi tidak menunjukkan bahwa ia sedang sibuk; itu hanya mengabaikan Anda
■
Blooper 57: Aplikasi kadang-kadang — dan tidak terduga — tidak responsif
sementara itu melakukan pembenahan internal
■ Blooper 58: Operasi lama tidak menampilkan kemajuan
■
Blooper 59: Operasi panjang tidak memberikan cara untuk membatalkan
■ Blooper 60: Aplikasi membuang waktu idle, dan ketika Anda akhirnya memberikan
perintah yang dapat diktekan, butuh waktu lama untuk menyelesaikannya
■
Blooper 61: Aplikasi tidak memberikan umpan balik saat hang, tanpa indikasi-
tion tentang apa yang sedang atau tidak terjadi
■ Blooper 62: Situs web memiliki gambar dan animasi yang sangat besar, jadi hanya dapat dilihat
dengan koneksi internet berkecepatan super tinggi
■
Blooper 63: Situs web selalu memuat ulang seluruh halaman sebagai tanggapan atas pengeditan kecil

Contoh: Daya tanggap yang buruk adalah komunikasi yang buruk

Kurangnya responsivitas dari banyak aplikasi akan dianggap disfungsi-

tional, bahkan tak tertahankan, jika terjadi dalam komunikasi antarmanusia. Angka
7.1 memberikan tiga contoh responsivitas komputer yang buruk, digambarkan sebagai buruk
komunikasi orang ke orang. Apakah ada yang mengingatkan Anda tentang perangkat lunak yang Anda gunakan?

Gambar 7.1
J: Saat aplikasi sibuk, pengguna tidak mendapat respon sama sekali.
"Fred, apa rencana kita akhir pekan ini?"
(Tulisan sibuk; tidak ada jawaban)

[Link] 224/315
26/2/2021 Tanpa judul
"Hei! Apa kau tahu kalau kita punya rencana untuk akhir pekan ini?"
(Masih tidak ada jawaban)
"Bumi ke Fred! Bumi ke Fred! Apakah kamu mendengarku?"
Selesai menulis) "Oke, selesai." (Mencari) "Apakah Anda mengatakan sesuatu?"

B: Peserta tidak mengkomunikasikan persyaratan dan perkiraan waktu.

"Saya ingin kamera ini diperbaiki." (Tidak mengatakan bahwa dia membutuhkannya dalam dua minggu
untuk pernikahan)
Tentu. Setelah saya mendapatkan informasi Anda dan deposit $ 25, saya dapat memperbaiki pekerjaan kami
antrean teknisi. "(Tidak mengatakan bahwa teknisi sedang berlibur dan tidak akan kembali
selama tiga minggu)

C: Kedua peserta dikunci dalam satu proses serial.

"Halo. Saya ingin terbang dari San Francisco ke New York Kamis depan, kembali hari Minggu
malam, semurah mungkin. "
"Oke, saya akan periksa penerbangan dan tarifnya. Saya tidak tahu berapa lama, tapi Anda harus tinggal
di telepon, tidak melakukan apa pun, sampai saya menemukan jawabannya. Jika Anda menutup telepon, saya akan lupa
tentang permintaan Anda. "

Daya tanggap yang buruk disajikan sebagai komunikasi orang-orang yang disfungsional.

Halaman 310

296 Bab 7 Responsiveness Bloopers

Gambar 7.2

Tidak ada bilah kemajuan untuk operasi lama. (A) Apple iPhoto. (B) Microsoft Font Navigator.

Contoh: Operasi lama tidak menampilkan bilah kemajuan

Saat Apple iPhoto dijalankan, ia memuat database dari semua foto pengguna.
Jika Anda memiliki ribuan foto, memuat dapat memakan waktu beberapa menit. Selama
saat itu, iPhoto tidak menunjukkan indikasi kemajuannya dalam memuat foto;
hanya indikator "sibuk" (Gambar 7.2A). Begitu pula dengan Microsoft Windows Font
Navigator membutuhkan beberapa menit untuk mencari font di hard disk Anda, tetapi selama
waktu itu hanya menunjukkan di mana ia sedang mencari dan berapa banyak fontnya
telah ditemukan (Gambar 7.2B). Tidak ada program yang memberi tahu Anda berapa lama Anda harus melakukannya
Tunggu.

Contoh: Operasi panjang menampilkan bilah kemajuan palsu

Bilah kemajuan palsu tampak seperti bilah kemajuan nyata: bilah dengan
mation menunjukkan aktivitas. Namun, dalam bilah kemajuan palsu, file
bilah tidak menunjukkan kemajuan operasi. Beberapa bilah kemajuan palsu ditampilkan
"kemajuan" perangkat lunak untuk setiap item dalam daftar item; mereka terisi sekali
untuk setiap item, mulai lagi untuk item berikutnya. Yang lain hanya mengisi secara siklikal
korespondensi dengan tidak ada secara khusus atau tampilan bergerak "tiang pangkas"
pola. Bilah kemajuan palsu hanyalah indikator sibuk yang mewah.
Penginstal Microsoft Windows XP menampilkan bilah kemajuan palsu saat diinstal
aplikasi (Gambar 7.3A). Bilah terisi, kosong, terisi lagi, kosong, dll.,
untuk masing - masing dari beberapa langkah dalam penginstalan. Di MacOSX, membakar acara CD
progress bar palsu: akan terisi beberapa kali saat CD dibakar — sekali per tahap
(Gambar 7.3B). Tampilan ini tidak berguna bagi pengguna yang perlu tahu berapa lama
seluruh operasi akan memakan waktu.

Contoh: Operasi lama tidak memberikan cara untuk membatalkan

Layanan penyimpanan online iDisk Apple menampilkan bilah kemajuan palsu saat Anda
salin file besar ke iDisk Anda (Gambar 7.4). Bilah terisi dalam waktu kurang dari satu detik,

[Link] 225/315
26/2/2021 Tanpa judul

Halaman 311

Bloopers responsif umum 297

Gambar 7.3

Bilah kemajuan palsu yang terisi berulang kali. (A) Penginstal Windows. (B) Utilitas CD MacOS.

Gambar 7.4

Salinan file iDisk Apple: bilah kemajuan palsu, tidak ada perkiraan waktu, dan tombol batal dinonaktifkan.

kemudian menampilkan animasi tiang pangkas selama 2-20 menit, tergantung pada filenya
ukuran. Terburuk dari semuanya, kotak dialog tidak memberikan perkiraan waktu dan batal tetapi-
ton ("X") dinonaktifkan.
Setidaknya kotak dialog iDisk memiliki tombol batal. Ketika MacOS mengonversi file
File postscript ke file PDF, yang dapat memakan waktu beberapa menit, tergantung pada
ukuran file. Selama waktu itu, ini akan menampilkan kotak dialog kemajuan palsu dengan no
tombol batal (Gambar 7.5).

Gambar 7.5

MacOS: bilah kemajuan palsu tanpa tombol batal.

Halaman 312

298 Bab 7 Responsiveness Bloopers

Contoh: Tombol tidak responsif dan tidak sibuk

atau indikator kemajuan

Kutipan dari ulasan UI dari tiga produk perangkat lunak:

■
Produk 1: Saat Generate Declarations diklik, dibutuhkan hingga lima
detik agar jendela muncul, selama tidak ada umpan balik yang diberikan
bahwa segala sesuatu sedang terjadi. Banyak pengguna akan mengklik lagi, dan (akhirnya)
dapatkan dua jendela Generate Declarations. Rekomendasi: Ketika but-
ton diklik, kursor akan segera berubah menjadi kursor tunggu dan
tombolnya harus dinonaktifkan.
■
Produk 2: Setelah login, jendela utama muncul dan program con-

[Link] 226/315
26/2/2021 Tanpa judul
terhubung ke servernya
Tombol jendela dan mengunduh
utama segera data.
muncul aktif danIni dapat
siap, memakan
tetapi abaikanwaktu 10-20 detik. Itu
semua klik sampai inisialisasi selesai. Selama inisialisasi, program
menampilkan pesan "menghubungkan ke ..." dan "memuat ..." di bagian bawah
jendela, tetapi sebagian besar pengguna tidak akan menyadarinya. Rekomendasi: Terbaik: Jangan
buka jendela utama sampai inisialisasi selesai; menampilkan sementara
Kotak dialog “Memuat — harap tunggu” dengan bilah kemajuan, sehingga pengguna dapat memperkirakan
sobat berapa lama waktu yang dibutuhkan untuk memuat. Alternatif: Menampilkan jendela utama
segera, tetapi nonaktifkan tombolnya dan tampilkan kursor tunggu sampai
inisialisasi selesai.
■
Produk 3: Setelah Buat Grafik diklik, dibutuhkan 10–60 detik untuk
Buat kotak dialog Grafik untuk muncul, tanpa umpan balik. Tombolnya tidak
bahkan mendaftarkan pers. Pengguna sering mengkliknya beberapa kali, mendapatkan (dan menunggu-
ing untuk) beberapa jendela Buat Grafik. Rekomendasi: Saat diklik,
tombol harus tidak aktif dan menampilkan kursor tunggu.

Alasan respons yang buruk

Aplikasi perangkat lunak dan situs Web menunjukkan ketanggapan yang buruk untuk tujuh orang
alasan.

Alasan 1: Fakta tentang daya tanggap tidak banyak diketahui

Meskipun sikap tanggap telah berulang kali terbukti menjadi yang paling penting
faktor tant dalam menentukan kepuasan pengguna (Prinsip Dasar 8, halaman 45), sedikit
pengembang tahu itu.
Karena sebagian besar pengembang dan manajer pengembangan tidak tahu caranya
daya tanggap yang penting adalah, tidak mengherankan jika mereka terus berputar
perangkat lunak tidak responsif. Begitu pula jika pelanggan tidak sepenuhnya memahami
dampak daya tanggap pada kegunaan, mereka tidak akan menuntutnya dari perangkat lunak
vendor.

Halaman 313

Alasan respons yang buruk 299

Alasan 2: Desainer UI jarang mempertimbangkan

responsivitas selama desain

Banyak blooper responsif adalah kesalahan perancang GUI, bukan kesalahan program-
mers. Desainer jarang mempertimbangkan masalah kinerja dan daya tanggap
merancang perangkat lunak. Mereka biasanya tidak menentukan dalam dokumen desain mereka apa
waktu respons diinginkan, dapat diterima, dan tidak dapat diterima, tetapi anggap saja
bahwa fungsi yang ditentukan akan cukup cepat. Yang terpenting, mereka tidak melakukannya
pertimbangkan bagaimana desain terbaik mungkin bergantung pada waktu respons apa yang dicapai-
sanggup. Jika tanggapannya panjang, desain yang berbeda akan dibutuhkan daripada jika mereka
pendek atau variabel.
Pertimbangkan scrollbar: mereka biasanya menampilkan "elevator" untuk menunjukkan bagian mana
seluruh dokumen terlihat, seperti yang diilustrasikan oleh scrollbar dari Apple
Macintosh dan Microsoft Windows (Gambar 7.6). Meski mereka dangkal
perbedaannya, keduanya memiliki "elevator".
Masalah responsivitas dengan scrollbar adalah bagaimana perpindahan elevator dihubungkan
untuk memperbarui (yaitu, menggulir) konten jendela. Masalahnya adalah apakah gulungan-
bar memperbarui tampilannya saat atau setelah konten jendela bergulir. Ada
dua desain umum:

■ Sedangkan: Posisi elevator sangat terikat dengan jendela con-

tenda, jadi lift tidak bergerak sampai kontennya bergulir.
■
Sesudah: Lift mengikuti kursor ke tempat pengguna menyeretnya, lalu,
ketika pengguna melepaskan elevator, konten jendela akan bergulir ke elevator yang baru
posisi.

Gambar 7.6

[Link] 227/315
26/2/2021 Tanpa judul

Scrollbar menampilkan "elevator". (A) Macintosh OSX. (B) Windows Vista.

Halaman 314

300 Bab 7 Responsiveness Bloopers

Desain mana yang lebih baik tergantung pada apakah mahal secara komputasi
atau murah untuk menggulir konten dokumen ke posisi baru. Jika menggulir
isi jendela mudah dan cepat, metode pertama lebih baik karena disimpan
konten jendela disinkronkan dengan lift dan menyediakan lebih banyak
umpan balik yang akurat. Jika menggulir konten jendela mahal dan lambat, file
Metode operasi kedua lebih disukai karena, dengan metode pertama,
elevator akan sering tertinggal di belakang kursor pengguna, membuat elevator menjadi sulit
posisi sesuai keinginan.
Jika desainer UI belum menentukan waktu respons pengguliran apa yang diterima-
dapat atau tidak dapat diterima, pemrogram GUI tidak dapat disalahkan karena memilih
bentuk operasi scrollbar yang paling mudah dikodekan.
Daya tanggap yang buruk dapat membuat fitur yang bagus tidak berguna. Itu
pasar perangkat lunak penuh dengan fitur bagus yang tidak berguna karena buruk
responsivitas. Contoh fitur seperti itu diberikan dalam daftar common
blooper responsif.

Alasan 3: Pemrogram menyamakan daya tanggap

dengan kinerja

Ketika produk perangkat lunak tidak cukup responsif, pemrogram cenderung melakukannya
menyalahkan algoritma yang buruk dan implementasi yang tidak efisien. Mereka mencoba untuk berkembang
algoritme dan menyesuaikan kinerja fungsi aplikasi. Mereka
idealnya adalah bahwa semua fungsi harus dijalankan sedekat mungkin dengan
sible. Hal ini menyebabkan penundaan pada tanggal rilis sementara pemrogram mencoba mempercepat
up produk yang "lambat" tidak dapat diterima. Perangkat lunak ini akhirnya sering dirilis
meskipun masih lebih lambat dari yang dimiliki pengembang, manajer, dan pelanggan
berharap.
Pemrogram juga sering menyalahkan respon yang buruk pada komputer yang lambat
ware. Menurut pandangan ini, responsivitas yang buruk merupakan masalah yang sepele karena
komputer berkinerja tinggi akan segera tersedia, dan memutakhirkannya
akan menyelesaikan masalah. Pandangan ini mengabaikan sejarah: dalam 25 tahun terakhir, komputasi
Kekuatan dan kecepatannya telah meningkat dengan faktor beberapa ratus atau lebih, namun
daya tanggap masih menjadi masalah seperti sebelumnya.
Menyalahkan respon yang buruk pada kebutuhan untuk meningkatkan ke perangkat keras yang lebih cepat
mengabaikan dunia nyata. Pelanggan biasanya memiliki komputer yang kurang kuat dan
koneksi internet yang lebih lambat daripada yang dimiliki pengembang perangkat lunak (Blooper 70,
halaman 370). Perusahaan komputer merilis setiap model baru yang lebih kuat
tahun, tetapi pelanggan tidak sering meningkatkan. Komunikasi programmer yang lebih cepat
puter dan koneksi Internet mungkin membutuhkan waktu bertahun-tahun untuk muncul dalam jumlah yang signifikan.
bers di pasar. Selain itu, pelanggan sering kali menjalankan perangkat lunak di bawah
beban yang lebih tinggi daripada yang diantisipasi oleh pengembang (Prinsip Responsiveness 2,
halaman 304).

Halaman 315

[Link] 228/315
26/2/2021 Tanpa judul
Alasan respons yang buruk 301

Alasan 4: Pemrogram memperlakukan masukan pengguna seperti masukan mesin

Pemrogram sering berasumsi bahwa orang mengontrol perangkat lunak dengan cara yang sama
perangkat lunak itu mengontrol perangkat lunak lain. Beberapa aplikasi tidak membedakan
dioperasikan oleh seseorang karena didorong oleh program lain. Gambar 7.7
menyajikan contoh, digambarkan sebagai komunikasi orang-ke-orang yang buruk. Melakukan
Anda mengenali aplikasi apa pun yang Anda gunakan?
Menyamakan masukan manusia dengan masukan dari perangkat lunak lain mengarah pada naif
aturan desain. Satu aturan naif adalah input pengguna, seperti itu dari mesin,
harus diproses sesuai pesanan yang diterima (Responsiveness Principle 5, halaman
307). Aturan naif lainnya adalah bahwa semua masukan pengguna itu penting; tidak ada yang seharusnya
hilang atau diabaikan. Terkadang masukan pengguna harus diabaikan (Responsiveness
Prinsip 7, halaman 309).
Salah satu alasan programmer sering memperlakukan interaksi dengan pengguna manusia seperti
interaksi dengan perangkat lunak lain adalah bahwa mereka dan manajer mereka lebih memilih
ple, implementasi yang mudah dikodekan (lihat Alasan 5). Program lainnya adalah-
mers memahami karakteristik perilaku komputer dan perangkat lunak
jauh lebih baik daripada karakteristik persepsi, motorik, dan kognitif
pengguna manusia, sehingga mereka lebih memperhatikan persyaratan program-
kontrol matic.

Alasan 5: Pengembang menggunakan penerapan sederhana

Pengembang sering kali menggunakan algoritme sederhana, struktur data, arsitektur, dan
protokol untuk meminimalkan risiko jadwal dan biaya pemeliharaan. Mereka menyukai
implementasi yang mudah untuk diprogram, misalnya, single-threaded dan synchro-
akal. Manajer mereka mendukung mereka dalam hal ini. Hal ini seringkali menghalangi tujuan dari
membuat perangkat lunak responsif. Gambar 7.8 menyajikan contoh penerapan sederhana
sebutan yang merugikan daya tanggap, menyamar sebagai orang-ke-orang yang buruk
komunikasi.
Saya pernah menemukan mesin faks dengan implementasi yang naif. Saya dimuat
dokumen, menekan nomor, dan menyuruhnya untuk dikirim. Faks berkedip

Gambar 7.7 Antrean acara adalah yang pertama masuk pertama keluar. Operator manusia memperhatikan
umpan balik eksternal, bukan jumlah perintah yang mereka keluarkan.
"OK, back '' er up juuust a tad. Sedikit lagi ... ... lagi ... ... lagi ... ... lagi ... ...
lagi ... ... lagi ... ... lagi ... ... lagi ... ... sedikit lagi ... ... OK, hentikan. Berhenti! BERHENTI!"
(CRRRRUNNNNCH !!!)
"Aw, man! Kenapa kamu tidak berhenti saat aku bilang 'berhenti'?"
"Karena saya ketinggalan 'adat istiadat' dan masih harus memproses beberapa sebelumnya
Aku mendapatkan perintah Berhenti Anda.

Komunikasi manusia-manusia yang menggambarkan perangkat lunak yang memperlakukan input manusia seperti input mesin.

Halaman 316

302 Bab 7 Responsiveness Bloopers

Gambar 7.8
J: Dialog sinkron; permintaan yang sepenuhnya independen satu sama lain;
tidak ada antisipasi untuk kemungkinan permintaan di masa mendatang.
“Halo, Toyota Prius '07 saya butuh peredam kejut baru. Apakah Anda menjual guncangan Acme? ”
“Entahlah. Saya akan memeriksa gudang. Mohon tunggu."
(pemanggil drum jari di atas meja selama dua menit)
(salesman kembali ke telepon) "Ya."
“Berapa biayanya?” “Tunggu. Akan saya periksa."
(pemanggil drum jari untuk satu menit lagi)
“Mereka masing-masing $ 55 terpasang.” “Bagaimana dengan kejutan Excelsior?”
“Entahlah. Saya akan memeriksa gudang. Mohon tunggu..."

B: UI mengabaikan bobot operasi: tidak memberikan umpan balik yang ringan dan cepat.
“Ayo coba letakkan piano di sini.”
(penggerak memindahkan piano ke lokasi yang ditunjukkan)
“Tidak, itu tidak berhasil. Bagaimana kalau di dekat jendela? ”
(penggerak bergerak piano)
“Itu lebih buruk. Ayo coba di sini ... "

C: Antrian acara adalah yang pertama masuk pertama keluar. Tidak ada pengakuan yang mengatur ulang tugas
bisa menghemat pekerjaan.
(Seorang penjaga gedung apartemen memulai harinya) “Mari kita lihat. Untuk apa pertama dalam daftar saya
hari ini? Sapu lantai lorong. Oke, ayo kita lakukan! ”
(menyapu lantai)
“Oke, selesai. Apa berikutnya? Papan pinggir pasir di lorong. BAIK..."

[Link] 229/315
26/2/2021 Tanpa judul

Daya tanggap yang buruk akibat penerapan yang naif dan sederhana.

“Tambahkan toner.” Saya berpikir, “Hah? Seharusnya tidak perlu toner untuk mengirimkannya. ” Saya sudah menunggu.
Itu bersikeras bahwa saya menambahkan toner. Saya tidak tahu bagaimana, jadi saya meminta bantuan seseorang,
yang menjelaskan bahwa faks tidak akan dikirim saat kehabisan toner atau kertas,
karena mencetak konfirmasi setelah selesai. Tugas saya diblokir karena
faks tidak dapat mencetak konfirmasi yang tidak saya inginkan. Pengembang memilih file
implementasi sederhana untuk meminimalkan risiko mereka. Pengguna faks membayar biayanya
pilihan itu.

Alasan 6: Alat perangkat lunak GUI, komponen, dan

platform tidak memadai

Karena daya tanggap sangat penting untuk kepuasan pengguna, ini mungkin tampak aneh
bahwa pengembang perangkat lunak memilih penerapan yang terlalu sederhana yang menghalangi
responsivitas. Tidakkah mereka tahu bahwa mereka membatasi permintaan untuk mereka
produk?
Seringkali, mereka tahu, tetapi alat mereka tidak memberikan dukungan yang mereka butuhkan
buat perangkat lunak responsif. Kebanyakan toolkit GUI (untuk Windows, MacOS, Linux,
dan Java) mempersulit penulisan perangkat lunak yang memenuhi tenggat waktu waktu nyata dan
memprioritaskan tugas pada waktu proses.

Halaman 317

Menghindari kesalahan besar yang responsif: Prinsip desain 303

Bahkan peningkatan daya tanggap yang seharusnya mudah pun sulit.

Menampilkan kursor sibuk di Java atau Windows membutuhkan penulisan multithread
kode, meskipun tidak ada hal lain dalam aplikasi yang membutuhkan banyak utas. Ini
sangat meningkatkan tingkat kerumitan pemrograman. Tidak heran beberapa
pengembang tidak perlu repot menampilkan kursor yang sibuk.

Alasan 7: Manajer mempekerjakan pemrogram GUI

kurang keterampilan yang dibutuhkan

Berkontribusi pada kurangnya respon dalam perangkat lunak berbasis GUI adalah kurangnya UI
keterampilan dan pengalaman di antara pemrogram GUI (Blooper 64, halaman 331). Ini
hampir menjamin aspek halus dari desain dan implementasi GUI, seperti itu
sebagai daya tanggap, akan berkurang.
Masalah ini diperburuk oleh fakta bahwa menulis perangkat lunak responsif
sering kali membutuhkan pemrograman real-time dan multithread. Seperti yang dijelaskan di bawah
Alasan 6, perangkat lunak GUI, komponen, dan platform memberikan dukungan yang buruk
untuk itu, menempatkan beban pada programmer. Seorang manajer pengembangan perangkat lunak
dan programmer menjelaskan:

Aplikasi multithread itu sulit. Mereka membutuhkan mempekerjakan pengembang senior yang mahal
opers dan seringkali membutuhkan waktu lama untuk men-debug dan memelihara.

Tentu saja, beberapa pengembang berhasil menulis perangkat lunak waktu nyata. Itu
perangkat lunak di pesawat tempur, rudal, robot pabrik, pembangkit listrik tenaga nuklir,
dan pesawat ruang angkasa sangat berorientasi pada kepuasan real-time con-
strain. Masalahnya bukanlah tidak ada yang tahu cara menulis perangkat lunak waktu-nyata.
ware. Sebaliknya, masalahnya adalah ekonomi desktop dan Web
industri perangkat lunak, bersama dengan kurangnya pemahaman antar perangkat lunak
pengembang tentang pentingnya daya tanggap, mencegah pembangunan
manajer dari mempekerjakan programmer yang memiliki keterampilan menulis responsif
aplikasi.

Menghindari kesalahan besar yang responsif: Prinsip desain

Bagian ini menjelaskan dan mengilustrasikan tujuh prinsip desain responsif,

yang menjelaskan apa artinya bersikap responsif dan menyarankan cara mencapainya.

Responsiveness Prinsip 1: Responsiveness adalah

tidak sama dengan performa

[Link] 230/315
26/2/2021 Tanpa judul

Perangkat lunak dapat responsif meskipun lambat. Jika Anda menelepon seseorang untuk mengajukan pertanyaan-
Jika tidak menjawab pertanyaan Anda dengan segera:

Halaman 318

304 Bab 7 Responsiveness Bloopers

dia bisa menerima pertanyaan itu dan berjanji untuk menelepon kembali. Dia bisa seimbang
lebih responsif dengan mengatakan kapan dia akan menelepon kembali.
Sebaliknya, perangkat lunak dapat memiliki daya tanggap yang buruk meskipun cepat.
Bahkan jika tukang jam tangan sangat cepat dalam memperbaiki jam tangan, dia tidak responsif
jika Anda masuk ke tokonya dan dia mengabaikan Anda sampai dia selesai bekerja
jam tangan lain. Dia tidak responsif jika Anda menyerahkan arloji Anda dan dia
diam-diam pergi tanpa mengatakan apakah dia akan memperbaikinya sekarang atau
pergi makan siang. Bahkan jika dia mulai mengerjakan jam tangan Anda segera, dia tetap bekerja
tidak responsif jika dia tidak memberi tahu Anda apakah perbaikan akan memakan waktu lima menit
atau lima jam.
Komputer pribadi saat ini jauh lebih cepat daripada 20 tahun
lalu, tapi kami pengguna masih menunggu lama dan bertanya-tanya apa yang terjadi, jadi kecepatannya
jelas bukan keseluruhan cerita. Saat ini sebagian besar penantian kita adalah untuk jaringan
penundaan dan transfer data besar-besaran.

Prinsip Responsif 2: Pemrosesan

sumber daya selalu terbatas

Semakin cepat komputer digunakan, semakin banyak perangkat lunak yang dimuat ke dalamnya:
aksesoris meja, beberapa aplikasi, aplikasi klien pesan instan,
tions. Selain itu, semakin cepat komputer mendapatkan, semakin banyak pengguna akan mencoba untuk memilikinya
komputer melakukan sekaligus: memutar musik sambil mengedit dokumen, unduh-
mengambil data atau perangkat lunak saat menjelajah halaman Web, mencetak dokumen panjang
saat melakukan pekerjaan lain. Peter Bickford menjelaskannya seperti ini dalam bukunya, Interface
Desain [1997]:

Pengguna Macintosh II senang dengan komputer yang bekerja secara efektif empat kali lipat
kecepatan Macintosh Plus, dan kemudian dengan rela melepaskan banyak potensi
peningkatan kecepatan untuk berjalan dalam warna. Saat mesin terus menjadi lebih bertenaga,
pengguna menambahkan video 24-bit, berbagi file, input dan output suara, film desktop,
dan seterusnya. Tidak ada akhir nyata dari tren ini yang terlihat.

Juga, seperti yang dinyatakan sebelumnya, pelanggan mungkin memiliki komputer yang lebih lambat daripada
para pengembang memiliki. Bahkan memiliki komputer model terbaru tidak berarti demikian
lebih banyak sumber daya komputasi akan tersedia untuk aplikasi tertentu.

Prinsip Responsif 3: Antarmuka pengguna

adalah antarmuka waktu nyata

Seperti perangkat lunak yang mengendalikan pesawat, perangkat lunak yang berinteraksi dengan manusia juga perlu
memenuhi kendala waktu nyata. Tiga konstanta waktu dalam perilaku manusia menetapkan tujuan
bahwa perangkat lunak harus memenuhi agar dianggap responsif [Nielsen, 1993;
Robertson et al., 1989, 1993]:

Halaman 319

Menghindari kesalahan besar yang responsif: Prinsip desain 305

■
0,1 detik: Ini adalah batas persepsi sebab-akibat antara
acara. Jika perangkat lunak menunggu lebih lama dari 0,1 detik untuk menunjukkan tanggapan
tindakan Anda, sebab-akibat rusak: reaksi perangkat lunak tidak akan
tampaknya hasil dari tindakan Anda. Oleh karena itu, tombol di layar memiliki 0,1

[Link] 231/315
26/2/2021 Tanpa judul
kedua untuk"ditarik"
objek yang menunjukkan bahwa mereka
oleh pengguna telahlebih
tertinggal diklik;
darijika
0,1tidak,
detik pengguna akan mengklik lagi. Jika
di belakang
kursor, pengguna akan kesulitan menempatkannya. Batas waktu 0,1 detik ini adalah apa
Peneliti HCI, Stuart Card, menyebut "momen" perseptual. Itu juga dekat
hingga batas persepsi animasi halus: 0,063 detik / bingkai (16
bingkai / detik).
■
1 detik: Ini adalah perkiraan panjang celah normal dalam percakapan.
Jika jarak lebih dari 1 detik, salah satu peserta akan mengatakan sesuatu untuk dipertahankan
percakapan berjalan, meskipun hanya "uh" atau "uh-huh." Demikian pula dengan perangkat lunak
sekitar 1 detik untuk melakukan apa yang diminta pengguna atau menunjukkan berapa lama waktu yang dibutuhkan
mengambil; jika tidak, pengguna menjadi tidak sabar. Satu detik juga merupakan perkiraan
waktu respons minimum untuk bereaksi terhadap peristiwa yang tidak terduga, seperti saat a
anak tiba-tiba berlari di depan mobil pengemudi. Dalam interaksi manusia-komputer
Saat informasi tiba-tiba muncul di layar, pengguna mengambil setidaknya
sedetik untuk bereaksi.
■
10 detik: Ini adalah perkiraan unit waktu yang biasanya digunakan orang
memecah perencanaan dan pelaksanaan tugas yang lebih besar. Kartu dan kol- nya
liga menyebutnya sebagai konstanta waktu "tugas unit". Ini adalah jumlah perkiraan
waktu orang dapat berkonsentrasi secara eksklusif pada satu tugas. Setiap 10 detik
atau lebih, orang melihat dari tugas mereka, menilai kembali status tugas dan tugas mereka
lingkungan sekitar, santai, dan sebagainya. Setelah 10 detik, pengguna ingin menandai sebuah unit
tugas selesai dan lanjutkan ke tugas berikutnya. Konstanta waktu ini telah
diamati di berbagai tugas, seperti menyelesaikan satu edit dalam teks
editor, memasukkan cek ke dalam program rekening koran, dan menjalankan a
manuver dalam pertempuran udara di pesawat. Dalam interaksi manusia-komputer, 10 detik-
onds kira-kira adalah jumlah waktu yang bersedia dihabiskan pengguna untuk menyiapkan
Operasi "kelas berat" seperti transfer file atau pencarian — lebih lama dan
pengguna mulai kehilangan kesabaran. Menghitung hasilnya bisa memakan waktu lebih lama jika
umpan balik kemajuan diberikan.

Masing-masing konstanta waktu ini merupakan perkiraan dari beberapa kondisi waktu yang tepat.
stants diamati dalam tugas persepsi, motorik, dan kognitif manusia. 2 Sebenarnya
konstanta waktu lebih tepat daripada yang dibutuhkan untuk desain UI. Tiga perkiraan-
konstanta waktu tiruan ditetapkan agar mudah diingat (Tabel 7.1).

2. Interval antar frame maksimum untuk animasi halus adalah kurang dari 0,1 detik: 0,063 detik
(16 bingkai / detik). Waktu reaksi rata-rata tanpa persiapan dalam mengemudi adalah kurang dari 1 detik:
itu adalah 0,7 detik. Konstanta waktu 10 detik adalah perkiraan dari beberapa waktu psikologis
konstanta mulai dari 5 hingga 30 detik.

Halaman 320

306 Bab 7 Responsiveness Bloopers

Tabel 7.1 Tiga konstanta waktu untuk interaksi manusia-komputer [dari Robertson et al.,
1989, 1993]

Aspek perilaku manusia Relevansi dalam manusia-komputer

Konstanta waktu itu berlaku untuk interaksi

0,1 detik ■ Persepsi berturut-turut ■ Umpan balik untuk tangan-mata yang sukses
acara koordinasi, misalnya, penunjuk
■ Persepsi sebab-akibat gerakan, gerakan jendela
■ Fusi perseptual, dan ukuran, operasi menggambar
misalnya, persepsi halus ■ Umpan balik bahwa tombol telah

animasi * diklik
■ Menampilkan indikator "sibuk"
■ Interval maksimum antar animasi
bingkai *

1 detik ■ Giliranpercakapan, ■ Menampilkan indikator kemajuan

misalnya, jeda di antara ■ Menyelesaikan sebagian besar permintaan pengguna

ucapan operasi misalnya, membuka a

■ Waktu respons minimum, kotak dialog
untuk kejadian tak terduga ■ Menyelesaikan operasi yang tidak diminta,
misalnya, penyimpanan otomatis

10 detik ■ Konsentrasi yang tidak terputus ■ Menyelesaikan satu langkah a

dalam sebuah tugas tugas multistep, misalnya, satu edit
■ Tugas unit: menyelesaikan satu di editor teks, memasukkan a
Tugas "unit" dalam tugas yang lebih besar periksa ke pemeriksaan
program akun
■ Melengkapi input pengguna ke sebuah

operasi
■ Menyelesaikan satu langkah dalam a
wizard (kotak dialog multi halaman)

[Link] 232/315
26/2/2021 Tanpa judul

* Sebenarnya 0,063 detik.

Prinsip Responsif 4: Semua penundaan tidak sama:

perangkat lunak tidak perlu melakukan semuanya dengan segera

Beberapa acara membutuhkan umpan balik segera; beberapa tidak. Karena itu perangkat lunak bisa
memprioritaskan penanganannya atas kejadian pengguna untuk memberikan umpan balik tepat waktu di mana itu
dibutuhkan dan menunda tugas lainnya.
Seperti yang dijelaskan di atas, untuk tugas koordinasi tangan-mata, tingkat gerakan tombol
kembali harus segera agar efektif. Pembukuan internal, memperbarui area
layar tempat pengguna tidak bekerja, hasil dari kalkulasi yang diminta secara eksplisit-
tions atau pencarian tidak perlu segera.
Buku pegangan desain UI klasik Desain Antarmuka Manusia-Komputer
Pedoman [Brown, 1988] menggunakan konsep tugas "penutupan" untuk menentukan kapan
penundaan respons perangkat lunak dapat diterima atau tidak dapat diterima:

Halaman 321

Menghindari kesalahan besar yang responsif: Prinsip desain 307

Faktor kunci yang menentukan penundaan respons yang dapat diterima adalah tingkat penutupan.…
Penundaan setelah menyelesaikan unit pekerjaan utama mungkin tidak mengganggu pengguna atau merugikan
mempengaruhi kinerja. Penundaan antara langkah-langkah kecil dalam unit kerja yang lebih besar, bagaimana-
pernah, dapat menyebabkan pengguna melupakan langkah-langkah berikutnya yang direncanakan. Secara umum, tindakan
dengan tingkat penutupan yang tinggi, seperti menyimpan dokumen yang telah selesai ke file, are
kurang sensitif terhadap penundaan waktu respons. Tindakan di tingkat penutupan terendah,
seperti mengetik karakter dan melihatnya bergema di layar, merupakan hal yang paling sensitif
untuk menanggapi penundaan waktu.

Mencoba membuat semua respons sistem sama cepatnya tidak akan berhasil. Segala sesuatu
tidak bisa terjadi sekaligus dan bahkan jika bisa, pengguna tidak bisa melihat semuanya.
Tanggapan instan untuk tindakan pengguna tertentu bahkan bisa jadi tidak diinginkan . Lebih cepat
tidak selalu lebih baik. Pengguna tidak mempercayai penelusuran atau penghitungan yang rumit
selesai terlalu cepat. Mungkin ada sedikit penundaan, kedipan, animasi, atau umpan balik lainnya
diperlukan saat tampilan berubah untuk membuat pengguna memperhatikan atau percaya
pekerjaan itu telah selesai. Banyak game komputer lama tidak bisa dimainkan hari ini
komputer karena dioptimalkan untuk kecepatan maksimum pada komputer lambat
dan berlari terlalu cepat pada yang lebih baru. Dengan demikian, tenggat waktu yang diberikan untuk berbagai jenis
umpan balik tidak hanya maksimal, mereka adalah tujuan.

Prinsip Responsif 5: Perangkat lunak tidak perlu melakukan tugas

dalam urutan permintaannya

Lain halnya dengan petugas kebersihan yang mula-mula menyapu lalu mengampelas (Gambar 7.8C), tampil
tugas dalam urutan yang naif, pertama masuk pertama keluar dapat menciptakan pekerjaan ekstra, melukai tanggapan
siveness.
Mengurutkan ulang tugas secara cerdas dalam antrian seseorang dapat menghemat pekerjaan dan waktu,
meningkatkan daya tanggap. Tugas harus diatur ulang sehingga menjadi tugas dengan prioritas tinggi
dihadiri pertama.

Prinsip Responsif 6: Perangkat lunak tidak perlu

melakukan semua yang diminta untuk dilakukan

Terkadang operasi yang Anda minta tidak diperlukan. Misalkan Anda sedang mengedit
dokumen dan memberitahu perangkat lunak untuk menyimpannya. Jika Anda belum mengubah apa pun
sejak terakhir kali Anda menyimpan, tidak ada alasan untuk membuang perangkat lunak
waktu menyimpannya. Sebaliknya, perangkat lunak hanya dapat menunjukkan bahwa file tersebut telah disimpan.
Banyak aplikasi melakukan itu, tetapi beberapa menyimpan dokumen setiap kali Anda memberi tahu mereka
untuk. Itu bisa mengganggu jika Anda memiliki kebiasaan menekan "Simpan" setiap beberapa
menit untuk mencegah kerusakan perangkat lunak, terutama jika dokumen membutuhkan waktu
waktu lama untuk menabung.
Jika tugas antrian menjadi diperdebatkan sebelum perangkat lunak dimulai, di sana
tidak ada alasan untuk melakukannya; itu dapat dengan mudah dijatuhkan. Gambar 7.9 menyajikan contoh
orang melakukan pekerjaan yang tidak perlu karena mereka memulai tugas antrian tanpa terlebih dahulu

[Link] 233/315
26/2/2021 Tanpa judul

Halaman 322

308 Bab 7 Responsiveness Bloopers

Gambar 7.9 J: Menangani tugas yang besar dan sulit berdasarkan instruksi sebelumnya, tanpa
memeriksa kembali validitasnya sebelum memulai.
"Ini dia! Saya menunda liburan keluarga saya dan bekerja lembur sepanjang minggu untuk membuatnya
tentu saya menyelesaikan proposal Smith tepat waktu. ”
“Oh? Apakah tidak ada yang memberitahumu? Kami telah memutuskan untuk tidak mengejar kontrak Smith. ”

B: Menangani tugas yang besar dan sulit berdasarkan asumsi default, bukan
mengetahui sampai terlambat bahwa tugas tersebut diperdebatkan.
“Yah, kalau bukan pemilik baru! Masuklah!"
Kami hanya mampir untuk melakukan beberapa pengukuran.
"Betulkah? Anda beruntung. Kami baru saja selesai mengukur seluruh tempat. Sebisa kamu
lihat, kami memasang karpet baru yang kami janjikan dalam perjanjian penjualan.
Kami bermaksud untuk menggantinya sebelum kami memasarkan rumah, tetapi tidak berhasil
sekitar untuk itu. "
“Oh? Nah, jangan repot-repot. Kami menyukai lantai kayu keras, jadi kami berencana untuk merobeknya
karpet."

Respon yang buruk karena kegagalan untuk memeriksa apakah tugas antrian diperdebatkan.

memeriksa apakah masih diinginkan. Jika tugas menjadi diperdebatkan saat sedang berlangsung
dieksekusi, itu bisa dibatalkan.
Jika dapat diprediksi sebelum tugas dimulai yang tidak dapat diselesaikan tepat waktu,
mungkin tidak ada alasan untuk melakukannya. Gambar 7.1B menggambarkan dua pihak yang masuk
transaksi tanpa mengkomunikasikan persyaratan waktu dan perkiraan, malapetaka
membuat diri mereka gagal.
Beberapa permintaan sembrono dan menguap sepenuhnya saat terungkap
bahwa memenuhinya tidaklah gratis. Memenuhi permintaan seperti itu sama sekali hanya membuang-buang waktu
dan sumber daya. Gambar 7.10 menyajikan contoh menghilangkan permintaan oleh
menjelaskan berapa biayanya.
IMovie Apple terkadang tidak mengikuti prinsip ini. Saat Anda menyuruhnya
menyimpan film yang telah Anda edit, ini akan menampilkan kotak dialog yang menunjukkan kemajuan
dari operasi penyimpanan. Itu bagus. Ini juga bagus yang disediakan kotak dialog
tombol "Batal". Yang buruk adalah tombol "Batal" mengabaikan Anda sampai
penyimpanan selesai. Rupanya, perintah Batal tidak bisa sampai ke depan
antrean saat penyimpanan sedang berlangsung.

Gambar 7.10 Beberapa permintaan sembrono, dan menguap saat terungkap

Memenuhi mereka tidaklah gratis.
“Bisakah Anda mencetak dokumen ini dengan warna?”
“Ya, tapi akan memakan waktu satu jam (atau biayanya $ 100).”
“Ack! Lupakan! Aku tidak terlalu menginginkannya. "

Menghemat pekerjaan yang tidak perlu dengan mengkomunikasikan biaya dan keengganan untuk membayarnya.

Halaman 323

Menghindari bloopers responsif: Teknik 309

Prinsip Responsif 7: Manusia adalah pengguna

bukan program komputer

Pengguna mengoperasikan perangkat lunak secara berbeda dari program komputer. Mereka tidak bisa
mencapai tingkat input yang tinggi untuk waktu yang lama. Mereka mungkin dapat membuat sistem sibuk
selama beberapa detik (sekitar 10, maksimum), tetapi kemudian mereka berhenti sejenak untuk berpikir atau beristirahat.
Orang bukanlah perangkat input / output saluran tunggal. Orang bisa melakukan beberapa
hal-hal secara paralel:

■
Bacalah buku sambil bersenandung
■ Dengarkan stasiun di radio dengan satu tangan sambil mengemudikan mobil dengan tangan lainnya

[Link] 234/315
26/2/2021 Tanpa judul
■
Mainkan melodi pada keyboard organ dengan tangan mereka saat memainkan bass
berbaris di pedal organ dengan kaki mereka
■ Berjalan dan mengunyah permen karet pada saat bersamaan (yah, beberapa orang)
■
Ketik teks atau putar musik sambil membaca teks atau musik berikutnya
■ Bicaralah di telepon sambil membuat makan malam

Pengguna perangkat lunak melihat hasil tindakan mereka dengan mata dan telinga mereka
mereka mengoperasikan perangkat lunak dengan tangan mereka. Seperti yang diilustrasikan oleh contoh tentang
kendaraan mundur (Gambar 7.7), pengguna memperhatikan terutama pada umpan balik
yang mereka terima dari perangkat lunak, alih-alih melacak tindakan yang mereka miliki
dilakukan. Mereka tidak tahu berapa kali mereka menekan tombol Bawah atau Berikutnya atau
berapa inci mereka telah menggerakkan mouse. Mereka menonton layar dan pangkalan
keputusan mereka tentang apakah akan melanjutkan apa yang mereka lihat di sana. Saat sekarang
sor atau scrollbar belum mencapai tujuannya, mereka terus bergerak. Saat tombol tidak
mengakui klik segera, pengguna menganggap mereka melewatkan dan mengklik lagi.
Sebaliknya, perangkat lunak yang mengontrol aplikasi tidak dapat melihat layar. Semua
ia tahu perintah apa yang dikeluarkannya. Karena persyaratan manusia dan perangkat lunak-
kontrol ware aplikasi sangat berbeda, antarmuka yang sama tidak dapat melayani keduanya.

Menghindari bloopers responsif: Teknik

Memahami prinsip saja tidak cukup. Untuk menghasilkan perangkat lunak yang responsif, Anda
membutuhkan teknik dan metode implementasi. Bagian ini menjelaskan beberapa.
Mulai dari yang sederhana dan statis hingga yang kompleks dan dinamis. Mereka dikelompokkan
menjadi empat kategori:

■
Umpan balik tepat waktu
■ Solusi masalah paralel
■
Optimasi antrian
■ Manajemen waktu yang dinamis

Halaman 324

310 Bab 7 Responsiveness Bloopers

Kebanyakan dari teknik ini adalah cara untuk mengatur waktu dan dapat diterapkan
domain selain perangkat lunak. Orang-orang mengatakan bahwa mereka telah menemukan beberapa
teknik-teknik ini berguna untuk mengatur waktu sendiri dan profesional
dan kehidupan pribadi. Ini bukan buku self-help, tapi jika menurut Anda berguna, bagus!

Umpan balik tepat waktu

Teknik tanggap pertama adalah tentang memenuhi tenggat waktu waktu nyata
yang menentukan apakah UI dianggap responsif atau tidak.

Akui masukan pengguna segera

Sekalipun perangkat lunak tidak dapat bertindak berdasarkan masukan pengguna dengan segera, setidaknya itu harus
akui menerimanya. Ini berarti memberikan umpan balik untuk mouse dan tombol-
tindakan tingkat stroke dalam 0,1 detik. Jika tidak, persepsi pengguna tentang penyebabnya
dan efek rusak dan mereka menganggap tindakan mereka tidak diterima. Terlambat
pengakuan atas tindakan pengguna hampir sama buruknya dengan tidak adanya pengakuan.
Gambar 7.11 menunjukkan contoh pendekatan ini, yang diekspresikan sebagai manusia-ke-manusia
komunikasi. Bandingkan ini dengan Fred yang tidak responsif pada Gambar 7.1A.
Contoh perangkat lunak yang sudah dikenal adalah tombol yang langsung mengenali
diklik dengan mengubah tampilan atau warna atau dengan membuat suara. Memang
tidak peduli bahwa perintah tombol mungkin membutuhkan waktu lama untuk dijalankan. Kapan
tombol mendeteksi bahwa itu telah diklik, prioritas tertingginya adalah untuk mengetahuinya
bahwa. Semua tanggung jawab tombol lainnya dapat ditunda.
Poor Responsiveness Reason 2 (halaman 299) menjelaskan contoh lain dari
segera mengakui masukan pengguna: jika konten jendela lambat ditampilkan, gunakan
scrollbar yang tidak menggulir konten jendela hingga pengguna berhenti bergerak
scrollbar. Dalam kasus seperti itu, adalah kesalahan untuk menggunakan scrollbar "langkah kunci"
yang pertama menggulung konten jendela dan hanya memperbarui posisi "elevator"
setelah konten diperbarui. Scrollbar "Lock-step" baik-baik saja jika kontennya
dapat menggulir dalam 0,1 detik, tetapi jika tidak, sebaiknya gunakan bilah gulir yang terhubung secara longgar.
Toolkit GUI harus membiarkan pemrogram menentukan protokol mana yang akan digunakan.
Mengingat kecepatan komputer saat ini, tidak ada alasan untuk komponen GUI.
nents yang tidak dapat menerima input pengguna dalam 0,1 detik. Komputer hari ini
menjalankan puluhan juta instruksi dalam jumlah waktu itu. Jika sebuah benda

[Link] 235/315
26/2/2021 Tanpa judul
tidak dapat mengakui tindakan pengguna dalam 0,1 detik, artinya itu — atau

Gambar 7.11
Terima masukan segera
“Fred, apa rencana kita akhir pekan ini?”
"Sebentar. Saya mencoba untuk menuliskan ide ini di atas kertas. "
"BAIK."
(akhirnya selesai menulis) “OK… selesai. Rencana kita akhir pekan ini? Ayo lihat..."

Mengakui masukan dengan segera, meskipun menghasilkan jawaban membutuhkan waktu.

Halaman 325

Menghindari bloopers responsif: Teknik 311

aplikasi yang menampilkannya atau sistem operasi yang mengirimkan tindakan ke

aplikasi — membuang-buang waktu menjalankan jutaan instruksi yang tidak penting
pada waktu yang tidak tepat. Ini menunjukkan kelemahan arsitektur yang serius pada objek,
aplikasi, dan / atau sistem operasi.
Pengembang perlu membuat komitmen yang kuat untuk tanggap ketika
sebuah aplikasi dirancang. Mengakui masukan pengguna harus selalu menjadi
prioritas tertinggi perangkat lunak.

Berikan indikator sibuk

Berikan indikator sibuk untuk fungsi yang membutuhkan waktu lebih dari 0,1 detik. Jika sebuah
indikator sibuk dapat ditampilkan dalam 0,1 detik, dapat berfungsi ganda sebagai tindakan
pengakuan. Jika tidak, respons perangkat lunak akan terbagi dalam dua bagian:
pengakuan cepat dalam 0,1 detik, diikuti dengan kesibukan atau kemajuan
indikator dalam 1 detik.
Alasan umum untuk tidak menampilkan kursor yang sibuk adalah karena fungsinya
dijalankan dengan cepat sehingga tidak perlu menampilkannya. tapi bagaimana caranya
cepat adalah "cepat"? Bagaimana jika fungsinya tidak selalu dijalankan dengan cepat?
Bagaimana jika pengguna memiliki komputer yang lebih lambat dari pengembang atau yang tidak
dikonfigurasi secara optimal? Bagaimana jika fungsi mencoba mengakses data yang temporer-
apakah terkunci? Bagaimana jika fungsinya menggunakan layanan jaringan dan jaringan digantung
atau kelebihan beban?
Perangkat lunak harus menampilkan indikator sibuk untuk fungsi apa pun yang menghalangi
ada tindakan pengguna saat dijalankan, meskipun fungsi tersebut biasanya dijalankan
dengan cepat (misalnya, kurang dari 0,1 detik). Ini bisa sangat membantu jika karena alasan tertentu
fungsinya macet atau macet. Selain itu, tidak ada salahnya: kapan
fungsi dijalankan pada kecepatan normal, indikator sibuk muncul dan
menghilang begitu cepat sehingga pengguna hampir tidak melihatnya.
Sistem operasi berbasis jendela modern, yang digerakkan oleh pengguna, multitask-
ing, dan multithread, mempersulit pemrogram aplikasi untuk memastikannya
bahwa kursor sibuk ditampilkan pada waktu dan lokasi layar yang sesuai.
Terkadang, kegagalan aplikasi untuk menampilkan kursor sibuk bukanlah aplikasinya.
kesalahan programmer tion. Seorang programmer GUI menulis:

Saya berusaha sangat keras untuk menampilkan kursor yang sibuk, tetapi ada sesuatu di luar kendali saya
terus mengalihkannya kembali ke kursor normal. Mungkin ada jalan lain jika
Saya memprogram cukup keras.

Faktor rumit termasuk pengelola jendela, proses lain, dan

utas mengubah kursor, dan penanganan pengecualian yang salah menyebabkan kursor
agar tidak selaras. Debugging masalah seperti itu bisa sangat memakan waktu
dan membutuhkan keahlian pemrograman yang hebat. Akibatnya, blooper biasa terjadi.
Apapun alasan untuk tidak menampilkan kursor sibuk pada waktu yang tepat,
efeknya sama: membuat pengguna tidak tahu apa-apa tentang apa yang terjadi dan sebagainya
adalah kesalahan besar.

Halaman 326

[Link] 236/315
26/2/2021 Tanpa judul

312 Bab 7 Responsiveness Bloopers

Indikator yang sibuk berkisar dalam kecanggihan. Di ujung bawah, kami memiliki sederhana,
kursor "tunggu" statis (mis., jam pasir). Mereka memberikan sedikit informasi: hanya
bahwa perangkat lunak untuk sementara digunakan dan tidak tersedia bagi pengguna untuk orang lain
operasi.
Selanjutnya, kami memiliki animasi "menunggu". Beberapa di antaranya adalah animasi "tunggu" saat ini
sors, seperti roda warna berputar MacOS. Kursor animasi "tunggu" lainnya
adalah jam tangan dengan tangan yang bergerak, tangan manusia menghitung dengan jari-jarinya,
sebuah pendulum berayun, dan jam pasir dengan pasir yang jatuh. Beberapa "menunggu" anima-
Tions bukan kursor, melainkan grafik yang lebih besar di tempat lain di layar, seperti itu
sebagai animasi "mengunduh data" dari browser Web. Animasi "tunggu" adalah
lebih "ramah" bagi pengguna daripada kursor "menunggu" statis karena mereka menunjukkan bahwa
sistem bekerja, tidak macet atau terputus menunggu koneksi jaringan atau
kunci data.

Menampilkan indikator kemajuan untuk operasi yang lama

Indikator yang lebih baik dari sibuk adalah indikator kemajuan, yang memungkinkan pengguna melihat
berapa banyak waktu tersisa. Batas waktu untuk menampilkan indikator kemajuan
adalah 1 detik.
Indikator kemajuan dapat berbentuk grafik (mis., Bilah kemajuan), tekstual (mis., A
jumlah file yang tersisa untuk disalin), atau kombinasinya. Mereka sangat meningkat
responsivitas yang dirasakan dari suatu aplikasi, meskipun aplikasi tidak mempersingkat
waktu untuk menyelesaikan operasi.
Indikator kemajuan semakin penting semakin lama operasinya. Banyak
perangkat nonkomputer menyediakan indikator kemajuan, jadi kami sering mengambilnya
diberikan. Elevator yang tidak menunjukkan kemajuan mobil elevator menuju lantai Anda
menjengkelkan. Kebanyakan orang tidak akan menyukai oven microwave yang tidak terlihat
waktu memasak yang tersisa.
McInerney dan Li [2002] membuat daftar pedoman untuk merancang kemajuan yang efektif
indikator:

■
Tunjukkan pekerjaan yang tersisa, bukan pekerjaan yang selesai. Buruk: 3 file disalin. Baik:
4 file tersisa untuk disalin.
■
Tunjukkan kemajuan total, bukan kemajuan pada langkah saat ini. Buruk: 5 detik tersisa
langkah ini. Bagus: 15 detik tersisa.
■
Untuk persentase selesai, mulai dari 1%, bukan 0%. Pengguna khawatir jika bilah tetap ada
pada 0% selama lebih dari satu atau dua detik.
■
Demikian pula, tampilkan 100% di akhir hanya dengan sangat singkat. Jika bilah tetap 100%
selama lebih dari satu atau dua detik, pengguna menganggapnya salah.
■
Tunjukkan kemajuan yang mulus dan linier, bukan semburan kemajuan yang tidak menentu.
■
Gunakan presisi skala manusia, bukan presisi komputer. Buruk: 27 detik. Baik:
Kurang dari 1 menit.

Halaman 327

Menghindari bloopers responsif: Teknik 313

Contoh: Indikator kemajuan

Progress bar dari Apple Mac Software Update dan Adobe Update Manager adalah
dirancang dengan cukup baik (Gambar 7.12). Mereka menunjukkan kemajuan dari seluruh instalasi-
tion. Ini jauh lebih berguna daripada yang ditunjukkan sebelumnya pada Gambar 7.2–7.5.
Salah satu kekurangan kecil dari bilah kemajuan Pembaruan Perangkat Lunak Mac adalah tidak adanya
perkirakan waktu yang tersisa. Bilah kemajuan Adobe juga memiliki kelemahan kecil: its
perkiraan waktu terlalu tepat.
Pengembang perangkat lunak seringkali ragu untuk memberikan indikator kemajuan karena itu
sulit untuk memperkirakan waktu yang tersisa secara akurat. Ini adalah kekhawatiran yang tidak beralasan.
Pengguna bukanlah komputer; mereka tidak membutuhkan banyak akurasi. Indikator kemajuan
dapat meleset dengan faktor 10 dan masih berguna.
Operasi transfer multifile dapat memberikan indikator kemajuan yang berguna
menunjukkan berapa banyak file (atau berapa persentase file) yang tersisa untuk ditransfer,
meskipun beberapa file mungkin berukuran 1 kilobyte sementara yang lain berukuran
12 megabyte. Setiap informasi lebih baik daripada tidak sama sekali. Pengguna hanya ingin tahu apakah
mereka harus menunggu, menyesap kopi, memeriksa pesan suara mereka, atau pergi makan siang.
Apple MacOS X menampilkan bilah kemajuan hebat untuk transfer multifile. Dis-
bermain mencakup perkiraan total waktu yang diharapkan (Gambar 7.13). Waktu

[Link] 237/315
26/2/2021 Tanpa judul

Gambar 7.12

Bilah kemajuan yang dapat diterima menunjukkan kemajuan seluruh operasi. (A) Pembaruan perangkat lunak MacOS.
(B) Manajer Pembaruan Adobe.

Halaman 328

314 Bab 7 Responsiveness Bloopers

Gambar 7.13

Transfer file MacOS X: perkiraan waktu hanya seakurat kebutuhan pengguna.

perkiraannya sangat kasar. Ini sering kali ditaksir terlalu tinggi pada awalnya, tetapi kemudian disesuaikan
nilai yang lebih realistis saat transfer berlangsung. Tampilan kemajuan Apple memberi tahu
pengguna apa yang ingin mereka ketahui.

Tampilkan informasi penting terlebih dahulu

Aplikasi dapat muncul lebih cepat daripada dengan menampilkan informasi penting-
Pertama, detail dan informasi tambahan nanti. Jangan menunggu sampai muncul tampilan
dirender sepenuhnya sebelum pengguna dapat melihatnya. Beri pengguna sesuatu untuk dipikirkan
dan bertindak secepat mungkin.
Ini memiliki beberapa manfaat. Ini adalah teknik sulap, seperti pesulap
yang memberi isyarat secara flamboyan dengan satu tangan untuk mengalihkan perhatian pengamat dari apa
tangan lain sedang melakukan. Ini mengalihkan pengguna dari fakta bahwa informasi lainnya
sistem ini belum ada dan menipu mereka dengan percaya bahwa komputer melakukan apa
mereka bertanya dengan cepat. Ini memungkinkan pengguna mulai merencanakan apa yang akan mereka lakukan selanjutnya.
Akhirnya, karena waktu respons yang minimum bagi pengguna untuk menanggapi apa
mereka melihat (lihat Tabel 7.1), itu membeli setidaknya 1 detik lagi untuk perangkat lunak menangkap
sebelum pengguna mencoba melakukan apa pun. Satu detik adalah banyak waktu untuk komputer.
Jika perlu terlalu banyak waktu untuk menampilkan semua yang diminta pengguna untuk dilihat,
ware dapat dirancang untuk menampilkan informasi tertentu terlebih dahulu. Berikut beberapa contohnya:

■
Situs web investasi saham: Sementara Anda menunggu "Investasi Saat Ini"
halaman yang akan dimuat, nama saham yang Anda miliki dan pasarnya saat ini
harga ditampilkan.
■
Perangkat lunak pengedit dokumen: Saat Anda membuka dokumen, dokumen itu menampilkan yang pertama
menyaring informasi segera setelah dimilikinya, daripada menunggu sampai memilikinya
memuat seluruh dokumen sebelum menampilkan apapun.
■
Fasilitas database atau pencarian Web: Ini mendaftar beberapa item yang ditemukan segera setelah itu
mereka, sambil terus mencari item yang lebih cocok.

Jika informasi ditampilkan dalam format yang memakan waktu dan kompleks, aplikasi
kation dapat menampilkan informasi dalam bentuk yang disederhanakan dengan cepat, menggantikan atau

[Link] 238/315
26/2/2021 Tanpa judul
menguraikannya nanti. Gambar yang muncul pada resolusi rendah terlebih dahulu kemudian menjadi
dirender dengan resolusi penuh adalah contoh yang bagus.

Halaman 329

Menghindari bloopers responsif: Teknik 315

Contoh program perangkat lunak awal yang dirancang untuk daya tanggap

Pada awal 1970-an, banyak sistem komputer dengan waktu bersama memiliki penggunaan "waktu-hari"
ity program yang menampilkan waktu saat ini. Satu menampilkan gambar grafis a
jam. Jam menunjukkan waktu dengan jarum jam, bukan angka, dan sangat
mewah dan didekorasi. Komputer dan tampilan grafik jauh lebih lambat saat itu; itu
gambar lengkap, jam kukuk Swiss yang rumit, membutuhkan waktu beberapa menit untuk ditampilkan.
Siapapun yang menulis program tersebut menyadari bahwa jam ditampilkan dengan lambat dan itu
orang tidak mau menunggu lama hanya untuk mencari tahu jam berapa sekarang. Program
oleh karena itu dirancang sedemikian rupa sehingga hal pertama yang digambarnya adalah dua garis sederhana yang
memasang dua jarum jam (Gambar 7.14). Itu hanya membutuhkan waktu sepersekian detik.
Itu segera menunjukkan perkiraan waktu. Selanjutnya muncul angka 3, 6, 9,
dan 12, memberikan gambaran yang lebih baik tentang waktu. Jumlah yang tersisa mengikuti. Lanjut,
program menggambar garis besar jam. Akhirnya, program mulai mengembangkan
jarum jam dan angka serta menambahkan dekorasi. Pada titik mana pun di sepanjang jalan, a
pengguna dapat menghentikan program dengan menekan Esc.
Jika pengguna hanya ingin tahu jam berapa sekarang, mereka menghentikan program
setelah itu menarik tangan. Kadang-kadang mereka menunggu sampai nomornya muncul
pastikan mereka membaca waktu dengan benar. Jika pengguna menunjukkan "keren
jam kukuk ”kepada seorang teman, mereka membiarkannya bekerja sampai selesai. Jam itu keluar-
contoh berdiri bagaimana perangkat lunak dapat dirancang untuk menjadi responsif bahkan jika itu
kinerjanya lambat.

Gambar 7.14

Jam ditampilkan dengan lambat, tetapi taruh informasi terpenting terlebih dahulu.

Perhitungan kelas berat palsu

Dalam perangkat lunak interaktif, beberapa tindakan pengguna memerlukan penyesuaian berurutan yang cepat
sampai tujuan tercapai. Contohnya termasuk NEXTing melalui satu set post-
ings, menggulir dokumen, memindahkan karakter game melalui tanah-
scape, mengubah ukuran jendela, atau menyeret objek ke posisi baru. Jika umpan balik
tertinggal tindakan pengguna, pengguna akan kesulitan mencapai tujuan mereka. Kapan
perangkat lunak Anda tidak dapat memperbarui datanya cukup cepat untuk mengimbangi pengguna, pro-
vide umpan balik simulasi ringan sampai tujuannya jelas, lalu terapkan yang sebenarnya
operasi (Gambar 7.15).

Halaman 330

316 Bab 7 Responsiveness Bloopers

Gambar 7.15
Berikan umpan balik menggunakan simulasi “ringan” hingga penyesuaian
berhenti
“Ayo coba letakkan piano di sini.”
“Oke, tapi untuk mengurangi ketegangan di punggung, saya membawa piano karton yang bisa kami pindahkan

[Link] 239/315
26/2/2021 Tanpa judul
sekitar sampai Anda tahu di mana Anda menginginkannya, maka saya akan membawa piano asli dan meletakkannya di sana. "

Menghindari pekerjaan yang tidak perlu dengan memalsukan umpan balik saat pengguna masih melakukan penyesuaian.

Editor grafis memalsukan umpan balik ketika mereka memberikan garis besar karet gelang
objek yang ingin dipindahkan atau diubah ukurannya oleh pengguna. Beberapa editor dokumen membuat
perubahan cepat-dan-kotor ke struktur data dokumen internal untuk mewakili
efek dari tindakan pengguna dan membereskannya nanti.

Memberikan umpan balik tepat waktu di Web

Pembaca yang terutama mengembangkan perangkat lunak Web mungkin telah mengabaikan waktu mati-
baris yang dibahas dalam Responsiveness Principle 3 (halaman 304) sebagai fantasi murni.
Memang benar bahwa memenuhi tenggat waktu di Web itu sulit — biasanya
bahkan tidak mungkin. Namun, benar juga bahwa tenggat waktu itu psiko-
konstanta waktu logis, yang dihubungkan dengan kita oleh jutaan tahun evolusi, itu
mengatur persepsi kita tentang daya tanggap. Mereka bukanlah target sembarangan itu
dapat disesuaikan agar sesuai dengan batasan Web atau teknologi apa pun
peron. Jika perangkat lunak Anda tidak memenuhi tenggat waktu tersebut, pengguna akan mempertimbangkannya
daya tanggapnya menjadi miskin, titik. Itu berarti sebagian besar perangkat lunak Web memilikinya
respon yang buruk. Pertanyaannya adalah: apa yang dapat Anda lakukan untuk memperbaikinya? Sini
adalah beberapa pendekatan:

■ Minimalkan ukuran dan jumlah gambar

■
Sediakan gambar mini cepat untuk ditampilkan atau ikhtisar, dengan cara untuk menunjukkannya
detail hanya sesuai kebutuhan
■ Pisahkan data dalam jumlah besar menjadi beberapa bagian yang lebih kecil dan berikan cara untuk menavigasi
melalui bagian-bagian
■
Style dan tata letak halaman menggunakan cascading style sheets alih-alih presentasi-
HTML tional, bingkai, atau tabel
■ Gunakan komponen browser bawaan jika tersedia alih-alih membuat
mereka dalam HTML
■
Unduh applet dan skrip ke browser; menggunakan metode AJAX [Garrett,
2005]
■ Gunakan animasi sisi browser, misalnya Flash, dengan cara terbatas [Nielsen, 2002;
Perfetti, 2005]

Halaman 331

Menghindari bloopers responsif: Teknik 317

Solusi masalah paralel

Sebuah langkah maju dalam kecanggihan adalah dengan menggunakan salah satu dari dua metode pemrosesan paralel.
ods: menunda pekerjaan dan bekerja ke depan .

Tunda pekerjaan yang tidak penting

Pekerjaan non-waktu-kritis dapat didelegasikan ke proses latar belakang, membebaskan

proses utama untuk menanggapi pengguna. Delegasikan tugas panjang yang tidak dimiliki pengguna
memerlukan umpan balik segera, seperti pembenahan internal perangkat lunak itu sendiri
atau permintaan yang diperkirakan membutuhkan waktu lama.
Gambar 7.16 mengilustrasikan pendekatan ini. Tidak seperti pada Gambar 7.1C, pemanggil di sini
dibebaskan untuk melakukan hal-hal lain sambil menunggu jawabannya.
Beberapa mesin faks kantor dengan cepat memindai halaman dokumen ke dalam
ory dan mengirimkannya nanti, memungkinkan pengguna untuk kembali ke aktivitas lain. Fax
mesin yang melakukan ini lebih responsif.
Ketika tugas yang didelegasikan tidak dilakukan oleh komputer terpisah, teknik ini
memberikan komputer beberapa tugas untuk dikerjakan sekaligus. Ini berisiko macet
seluruh komputer mati, sehingga gagal melakukan apa yang seharusnya dilakukannya: gratis
proses utama untuk menjadi responsif terhadap pengguna. Untuk menurunkan risiko itu, tetapkan induk
proses prioritas tinggi relatif terhadap proses latar belakang, jadi latar belakang
proses dapat ditunda hingga ada lebih banyak waktu.
Bagaimana jika tidak ada waktu lagi? Jangan khawatir. Pengguna bukanlah komputer; mereka
tidak dapat mempertahankan tingkat input yang tinggi untuk waktu yang lama. Itu memastikan bahwa bagian belakang-
tugas dasar akhirnya akan selesai.
Pertimbangkan Microsoft Word. Sampai pertengahan 1990-an, repaginasi dokumen
adalah tugas latar depan. Anda harus menjalankan perintah Repaginate dan kemudian

[Link] 240/315
26/2/2021 Tanpa judul
tunggu beberapa detik — untuk dokumen panjang, menit — sampai selesai sebelumnya
Anda dapat kembali mengedit dokumen. Sekarang, repaginasi di Word adalah a
tugas latar belakang, dijalankan secara otomatis sesuai kebutuhan, memungkinkan Anda untuk melanjutkan
mengedit. Pemeriksaan ejaan memiliki sejarah yang serupa.

Gambar 7.16
Interaksi tidak perlu sinkron. Delegasikan tugas gondrong kepada agen
yang beroperasi secara paralel dengan Anda.
“Saya ingin terbang dari San Francisco ke New York Kamis depan, kembali Minggu malam,
semurah mungkin. "

“Oke, saya akan memeriksa penerbangan dan tarifnya dan menelepon Anda kembali.”

Proses pemijahan paralel untuk melakukan tugas yang panjang.

Halaman 332

318 Bab 7 Responsiveness Bloopers

Bekerja ke depan

Bekerja lebih awal dari pengguna jika memungkinkan. Perangkat lunak dapat menggunakan periode beban rendah untuk
prakomputasi tanggapan untuk permintaan probabilitas tinggi. Akan ada periode
beban rendah karena penggunanya adalah manusia. Perangkat lunak interaktif biasanya digunakan
banyak waktu menunggu masukan dari pengguna. Jangan buang waktu itu! Gunakan
untuk mempersiapkan sesuatu yang mungkin diinginkan pengguna. Jika pengguna tidak pernah mau
itu, jadi apa? Perangkat lunak melakukannya dalam waktu "bebas"; itu tidak memakan waktu lama
ada yang lain.
Gambar 7.17 memberikan contoh pekerjaan ke depan, diekspresikan sebagai manusia-ke-
komunikasi manusia. Satu contoh (Gambar 7.17A) menunjukkan pekerjaan "pintar "-
depan: dengan beberapa pengetahuan tentang tugas-tugas, sistem dapat membuat terdidik
tebakan tentang apa yang diinginkan pengguna. Contoh lainnya (Gambar 7.17B) bisa jadi
disebut pekerjaan depan "bodoh": alih-alih pengetahuan tugas, ia menggunakan fakta sederhana
pekerjaan itu bisa dimulai sebelum instruksi selesai. Pekerjaan depan bodoh adalah
tidak buruk; ini bisa sama membantu dengan pekerjaan cerdas ke depan.
Bekerja ke depan harus dilakukan sebagai proses latar belakang dengan prioritas rendah,
sehingga tidak mengganggu aktivitas pengguna. Proses yang berfungsi
ke depan harus memeriksa terus-menerus apakah tugas yang mereka kerjakan masih relevan.
evant dan abort jika tidak.
Berikut beberapa contoh perangkat lunak yang menggunakan pemrosesan latar belakang untuk bekerja
di depan pengguna:

■
Fungsi pencarian teks mencari kemunculan berikutnya dari kata target while
Anda melihat yang sekarang. Saat Anda memberi tahu fungsi untuk mencari berikutnya
kemunculan kata tersebut, sudah ada dan sepertinya sangat cepat.
■
Penampil dokumen membuat halaman berikutnya saat Anda melihat halaman saat ini.
Saat Anda meminta untuk melihat halaman berikutnya, itu sudah siap.

Gambar 7.17
J: Antisipasi keinginan pengguna, dan gunakan waktu luang untuk mempersiapkan berbagai hal
sebelum ditanya.
“Ini adalah biaya tambahan untuk ceramah Anda. Juga, saya pikir Anda ingin salinan kertas untuk diserahkan
untuk penonton, jadi saya membuat 20. ”
“Terima kasih, Fred, kamu adalah anugerah!”

B: Bahkan tanpa pengetahuan tugas, itu mungkin untuk bekerja di depan pengguna.
"Dan apa yang Anda inginkan untuk hidangan utama?"
"Hmmm. Kami belum memutuskan. -Ada banyak yang bisa dipilih! ”
“Nah, selagi kau memutuskan, aku akan menyiapkan hidangan pembuka dan mengambil anggurmu. -Ketika saya
kembali, Anda bisa memberi tahu saya apa yang Anda inginkan. "

Bekerja di depan pengguna untuk membuat perangkat lunak tampak lebih cepat.

[Link] 241/315
26/2/2021 Tanpa judul

Halaman 333

Menghindari bloopers responsif: Teknik 319

Optimasi antrian

Ide dasar pengoptimalan antrian adalah meninjau daftar tugas secara berkala
putuskan tugas apa yang harus dilakukan dan dalam urutan apa. Dua cara berbeda untuk mengoptimalkan a
antrian tugas adalah:

■ menyusun ulang, juga dikenal sebagai "pemrosesan input nonsequential", dan

■
membilas tugas darinya yang telah menjadi perdebatan.

Pemrosesan masukan tidak penting

Urutan tugas sering kali penting. Melakukan tugas secara membabi buta di
urutan permintaan dapat membuang waktu dan sumber daya atau bahkan membuat
makan kerja ekstra. Perangkat lunak harus mencari peluang untuk menyusun ulang tugas di dalamnya
antre. Terkadang pengurutan ulang tugas dapat membuat menyelesaikan seluruh rangkaian lebih banyak
efisien, seperti yang diilustrasikan pada Gambar 7.18. Bandingkan ini dengan pendekatan naif
diilustrasikan pada Gambar 7.8C.
Personel maskapai penerbangan menggunakan pemrosesan input yang tidak penting saat mereka berjalan
dan antrean check-in yang panjang mencari orang-orang yang penerbangannya akan berangkat sangat
segera sehingga mereka dapat menarik mereka keluar dari barisan dan meminta mereka check in.
Di browser Web, mengklik tombol Kembali atau Berhenti atau pada link yang ditampilkan
segera membatalkan semua aktivitas yang sedang berlangsung untuk memuat dan menampilkan halaman saat ini.
Mengingat berapa lama waktu yang dibutuhkan untuk memuat dan menampilkan halaman Web, kemampuan untuk membatalkan
pemuatan halaman sangat penting untuk penerimaan pengguna.

Tugas siram yang telah menjadi perdebatan

Terkadang tugas pada daftar tugas menjadi diperdebatkan. Tujuan atau persyaratan mungkin
berubah, tenggat waktu untuk tugas mungkin kedaluwarsa, permintaan terbaru mungkin menggantikan sebelumnya
satu. Perangkat lunak dapat memindai antrian sehingga tugas moot dapat dikenali dan
dikeluarkan dari antrian atau, jika sudah dimulai, dibatalkan. Perbuatan

Gambar 7.18
Pra-pindai antrian dan optimalkan pesanannya.
(Seorang penjaga gedung apartemen memulai harinya)
"Ayo lihat. Apa yang pertama di daftar saya untuk hari ini? Sapu lantai lorong. Papan pasir masuk
lorong. Cat ulang pegangan tangga. "
“Baiklah, mari kita lihat ...... Saya tidak akan repot-repot menyapu sampai setelah saya mengampelas, karena akan mengampelas
tinggalkan debu dan pasir di mana-mana. Jika saya mengecat pegangan tangga terlebih dahulu, saya harus menunggu satu atau dua hari
agar cat mengering sebelum saya bisa mengampelas alas tiang. Jadi sebaiknya aku mengampelas, lalu menyapu,
lalu lukis. ”

Mempersiapkan antrian tugas dan menyusun ulang tugas.

Halaman 334

320 Bab 7 Responsiveness Bloopers

Gambar 7.19
Sebelum memulai tugas antrian, periksa untuk melihat apakah itu masih diperlukan. Jika tidak, lewati
saya t.
“Yah, kalau bukan pemilik baru! Masuklah!"
Kami hanya mampir untuk melakukan beberapa pengukuran.
"Betulkah? Kami mencoba menelepon Anda, tetapi Anda pasti sedang dalam perjalanan ke sini. Kita
dijanjikan dalam perjanjian jual beli untuk mengganti karpet lama. Kami merobek karpet tua,
tapi kami ingin memeriksa ulang dengan Anda untuk memastikan Anda menginginkan karpet baru. "
“Nah, Anda beruntung. Kami telah memutuskan untuk mengekspos lantai kayu keras, jadi kami tidak perlu
karpet baru. Tapi terima kasih telah merobek barang-barang lama! ”

Memeriksa antrian tugas untuk melepaskan tugas yang telah diperdebatkan.

[Link] 242/315
26/2/2021 Tanpa judul

ini dapat menghemat banyak waktu dan tenaga yang terbuang. Teknik ini bisa dijelaskan
sebagai "memalsukan kecepatan dengan hanya melakukan apa yang diperlukan, tidak semua yang diminta".
Gambar 7.19 mengilustrasikan teknik, kontras dengan Gambar 7.9B.
Contoh perangkat lunak dapat ditemukan di editor teks EMACS. EMACS pro-
menyediakan kedua perintah gerakan absolut (misalnya, "pindahkan kursor ke baris 10") dan rela-
perintah tive-pindah (misalnya, "memindahkan kursor 6 baris ke depan"). Misalkan EMACS
tertinggal dalam memproses perintah Anda. Ini prescans antrian inputnya dan jika itu
menemukan "pindah ke baris 26", ia dapat melewati antrean sebelumnya "pindah ke bawah 3 baris"
perintah. Teknik terkait yang digunakan oleh beberapa editor teks adalah menggabungkan delapan
tombol panah atas ditekan dan tiga tombol panah bawah ditemukan dalam antrean masuk
lima tombol panah atas.
Responsiveness Principle 7 (halaman 309) menyebutkan teknik yang penting
untuk memaksimalkan responsivitas mouse: hapus atau abaikan antrian apapun
gerakan kursor. Pengguna memperhatikan posisi kursor, bukan
jarak mereka memindahkan alat penunjuk. Menggerakkan kursor adalah tangan–
tugas koordinasi mata dan karenanya membutuhkan umpan balik segera. Gerakan kursor
peristiwa adalah prioritas tinggi yang harus diproses oleh sistem operasi (OS)
mereka secepat pengguna membuatnya, tetapi jika tidak bisa karena alasan tertentu dan
tertinggal, OS hanya harus melewati peristiwa gerakan kursor antrian.
Sederhananya: gerakan kursor antrian diperdebatkan menurut definisi. Pengolahan
antrian peristiwa gerakan kursor selalu salah. Hal yang sama berlaku untuk semua orang
perangkat penunjuk gerakan relatif.

Manajemen waktu yang dinamis

Kategori teknik responsivitas yang paling kompleks adalah dinamis

manajemen waktu. Teknik lainnya adalah strategi waktu desain statis untuk
memprioritaskan dan menangani masukan pengguna. Manajemen waktu dinamis melibatkan
mengubah strategi saat runtime, tergantung pada apa yang terjadi saat ini.
Manajemen waktu dinamis terkadang disebut sebagai program "waktu nyata "-

Halaman 335

Menghindari bloopers responsif: Teknik 321

ming, meskipun istilah itu biasanya mengacu pada antarmuka antara komputer dan
instrumen, bukan antara komputer dan pengguna.
Empat jenis manajemen waktu dinamis dapat membantu dalam mengimplementasikan respon-
sive UI.

Pantau antrian acara; sesuaikan strategi jika tidak mengikuti pengguna

Perangkat lunak dapat memantau antrean acara dan menyesuaikan strateginya jika tidak disimpan
up dengan pengguna. Itu dapat melacak berapa banyak acara yang ditumpuk di
antrean dan beralih ke strategi yang lebih cepat jika antrean terlalu penuh. Bank, supermar-
kets, dan plaza tol jalan raya menggunakan strategi ini dengan tepat ketika mereka menambahkan teller,
pegawai kasir, atau pengambil tol ketika antrean panjang.
Editor dokumen WordStar dari tahun 1980-an menggunakan antrian dinamis
memproses agar responsif meskipun kinerja sangat terbatas
prosesor 1-MHz 8080 dan Z-80 yang menjalankannya. Pengetik cepat bisa dengan mudah
iya menyebabkan editor dokumen pada hari itu, termasuk WordStar, tertinggal
memproses penekanan tombol. Saat tertinggal, sebagian besar editor dokumen di dalamnya
hari akan mengantri penekanan tombol dan memprosesnya dalam urutan yang diterima, jadi
tampilan pada waktu tertentu tidak mencerminkan apa yang diketik pengguna, tetapi di mana
program sedang memproses antriannya. Sebaliknya, WordStar memastikan hal itu
karakter yang diketik pengguna langsung terlihat. Saat pengguna berhasil
darinya, WordStar mengubah strateginya: ia berkonsentrasi untuk mendapatkan karakter yang diketik-
ters ke atas layar dan berhenti membungkus kata, memperbarui posisi kursor
indikator, dan cenderung hal-hal lain sampai pengguna melambat.
Meskipun komputer saat ini lebih dari 1000 kali lebih cepat daripada komputer pada
yang dijalankan WordStar, banyak aplikasi saat ini kurang responsif dibandingkan WordStar.
Ini sebagian karena aplikasi saat ini melakukan jauh lebih banyak daripada aplikasi kontra 1980-an mereka.
bagian dan sebagian karena desainer mereka tidak menempatkan prioritas tinggi pada penyediaan
umpan balik yang cepat. Performa tinggi tidak menjamin respons yang tinggi.

Pantau kepatuhan waktu; menurunkan kualitas atau

jumlah pekerjaan yang harus dijaga

Memantau panjang antrian input adalah cara yang cukup kasar bagi perangkat lunak
mengukur seberapa baik itu mengikuti pengguna. Cara yang lebih tepat adalah dengan waktu itu sendiri:

[Link] 243/315
26/2/2021 Tanpa judul
pantau kepatuhannya dengan tenggat waktu waktu nyata. Jika perangkat lunak tidak memenuhi itu
tenggat waktu, hal tersebut dapat menurunkan kualitas atau kuantitas pekerjaannya agar dapat mengejar ketertinggalan.
Dalam pendekatan ini, desainer menetapkan — secara eksplisit, dalam kode — maksimum
waktu penyelesaian yang dapat diterima untuk setiap operasi, dan perangkat lunak terus menerus
waktu itu sendiri untuk mengevaluasi seberapa baik itu memenuhi tenggat waktunya. Jika perangkat lunaknya
melewatkan tenggat waktu atau menentukan bahwa berisiko melewatkan tenggat waktu yang tertunda,
ia mengadopsi metode yang lebih sederhana dan lebih cepat dalam melakukan tugasnya, biasanya menghasilkan
pengurangan sementara dalam kualitas atau kuantitas outputnya. Pendekatan ini harus
berdasarkan waktu nyata , bukan pada siklus prosesor, sehingga menghasilkan respons-
ness di komputer yang berbeda.

Halaman 336

322 Bab 7 Responsiveness Bloopers

Beberapa perangkat lunak animasi interaktif menggunakan teknik ini. Seperti yang dijelaskan
di bawah Responsiveness Principle 3 (halaman 304), diperlukan 16 bingkai / detik untuk
serangkaian gambar dianggap sebagai animasi yang halus. Stuart Card dan
rekannya mengembangkan "mesin" perangkat lunak untuk menyajikan animasi interaktif
tions yang memperlakukan frekuensi gambar sebagai aspek terpenting dari animasi
[Robertson et al., 1989, 1993]. Jika mesin mengalami masalah dalam memelihara 16 bingkai /
kedua karena gambarnya rumit atau pengguna sedang memindahkannya, maka mulailah
mengorbankan aspek lain dari gambar: label teks, efek tiga dimensi,
highlighting dan shading, color, dan sebagainya. Idenya adalah lebih baik untuk mengurangi
gambar 3D animasi pesawat sementara untuk gambar garis sederhana dari
itu untuk membiarkan frame rate turun di bawah 16 / detik.
The Cone Tree, dikembangkan di PARC, adalah tampilan interaktif dari hierarki-
struktur data chical, seperti direktori file dan subdirektori (Gambar 7.20).
Pengguna dapat mengambil bagian pohon mana saja dan memutar pohon. Rotasi bergerak
lancar. Saat pohon berputar, perangkat lunak mungkin tidak punya waktu untuk merender
semua detail dari setiap bingkai dengan tetap mempertahankan 16 bingkai / detik. Dalam hal ini, itu
dapat menghemat waktu dengan membuat label nama file di setiap folder sebagai gumpalan hitam
bukan sebagai teks yang dapat dibaca. Saat animasi berhenti, perangkat lunak menampilkan
pohon dengan detail lengkap. Sebagian besar pengguna bahkan tidak memperhatikan degradasi gambar selama
ing gerakan, karena mereka menghubungkan ketidakmampuan mereka untuk membaca label
blur.
Cara langsung untuk membuat perangkat lunak beroperasi dalam waktu yang ditentukan oleh manusia.
ner adalah memulai dengan perkiraan kasar dari hasil yang diinginkan dan menghasilkan
perkiraan yang lebih baik berturut-turut sampai waktu habis. Fungsi menggambar jam
Untuk beroperasi di bawah tenggat waktu waktu nyata dapat menggunakan strategi yang diilustrasikan dalam
Gambar 7.14, menampilkan jam-jam yang lebih mewah secara berturut-turut ke dalam buffer tampilan tersembunyi,
menampilkan yang terbaru saat tenggat waktu tiba.

Memprediksi waktu penyelesaian; memutuskan bagaimana melakukan tugas

Bahkan lebih baik daripada memiliki ukuran software seberapa baik telah lakukan adalah untuk memiliki
itu memprediksi seberapa baik itu akan dilakukan dan memutuskan berdasarkan prediksi tersebut bagaimana mempro-
ceed. Jenis manajemen waktu dinamis ini membutuhkan layanan perangkat lunak
dan fungsi dapat memperkirakan berapa lama waktu yang dibutuhkan.
Saat Anda mengeklik bilah gulir dan mulai menyeret, bilah gulir dapat bertanya
jendela yang berisi konten yang akan di-scroll berapa lama waktu yang dibutuhkan
gulir konten beberapa piksel. Jika jendela menjawab, itu akan memakan waktu 0,1 detik atau
kurang, scrollbar akan melakukan operasi scroll; jika tidak, scrollbar akan melakukannya
gerakkan bilah gulir dengan kursor dan lakukan operasi gulir setelah Anda melepaskannya
lift di posisi akhirnya.
Salah satu kegunaan prediksi waktu adalah untuk menghindari masalah waktu dinamis yang lebih sederhana
skema manajemen. Cukup melacak kepatuhan masa lalu ke dead-time dead-
garis dan menyesuaikan kualitas pekerjaan yang diperlukan dapat menyebabkan yang tidak diinginkan
osilasi. Pertimbangkan program animasi yang menyesuaikan kualitas renderingnya

Halaman 337

[Link] 244/315
26/2/2021 Tanpa judul

Menghindari bloopers responsif: Teknik 323

Gambar 7.20

Cone Tree (A) menjadikan label folder sebagai gumpalan sementara pengguna memutar pohon (B).

berdasarkan frekuensi gambar rata-rata yang dicapai selama 10 bingkai terakhir. Jika
10 bingkai terakhir dirender terlalu lambat (yaitu, di bawah 16 bingkai / detik),
ini mungkin menurunkan kualitas gambar ke tingkat yang dapat dengan mudah ditampilkan
waktu yang dibutuhkan. Segera, ini merender frame terlalu cepat atau memiliki waktu luang
tersedia, sehingga meningkatkan kualitas rendering, menyebabkan frekuensi gambar menurun
lagi, dan seterusnya, bolak-balik. Mendasarkan kualitas rendering pada waktu yang diprediksi
kepatuhan serta kepatuhan masa lalu dapat menghilangkan osilasi tersebut.

Halaman 338

324 Bab 7 Responsiveness Bloopers

Gambar 7.21
Perkirakan berapa banyak waktu yang dibutuhkan untuk suatu tugas; menegosiasikan protokol mana yang akan digunakan.
"Apakah kamu siap untuk memesan?"
"Hampir. -N menit lagi. -Semuanya terlihat bagus! ”
“OK, saya akan ......” TALI N: {
N <1 menit: "......tunggu disini."
1 <= N <3 menit: “...... terima perintah orang lain ini dan segera kembali.”
N> = 3 menit: "...... pergi, dan kembali saat aku melihat kamu sudah siap."
}

Proses pemijahan paralel untuk melakukan tugas yang panjang.

Perangkat lunak juga dapat menggunakan prediksi waktu untuk memutuskan apakah akan melakukan tugas di
latar depan atau latar belakang. Perangkat lunak yang bersiap untuk menjalankan suatu fungsi
pertama menanyakan fungsi untuk perkiraan waktu. Kemudian menggunakan perkiraan untuk memutuskan
apakah akan menjalankan fungsi di latar depan (artinya akan menunggu
agar fungsi dapat diselesaikan) atau dalam proses latar belakang (yang membebaskan panggilan-
proses untuk melakukan pekerjaan lain). Gambar 7.21 mengilustrasikan metode ini, dinyatakan sebagai

[Link] 245/315
26/2/2021 Tanpa judul
komunikasi orang ke orang.
Dalam pendekatan dinamis, keputusan tentang apakah akan menjalankan fungsi
tion sebagai latar depan versus tugas latar belakang dibuat di runtime , tidak merancang
waktu. Jika suatu fungsi selalu membutuhkan jumlah waktu yang sama, keputusannya
tentang apakah akan menjalankannya di latar depan atau latar belakang dapat dibuat kapan
perangkat lunak itu ditulis. Menunda keputusan hingga runtime hanya diperlukan
jika waktu yang dibutuhkan oleh fungsi sangat bervariasi, misalnya, tergantung pada sistem
memuat atau ketersediaan sumber daya jaringan.
Misalkan Anda memberi tahu program email Anda untuk mengambil email baru. Jika program
melihat bahwa tidak banyak email, ia dapat mendownload email sebagai latar depan
tugas, mengikat UI sebentar. Jika program melihat ada banyak email, itu
bisa melakukannya di tugas latar belakang, membiarkan Anda kembali ke menulis atau membaca
e-mail (dan memberi tahu Anda apa yang dilakukannya).

Memprediksi kepatuhan waktu; menegosiasikan kualitas atau

apakah akan melakukan tugas sama sekali

Akhirnya, perangkat lunak dapat memprediksi apakah itu akan menyelesaikan tugas tepat waktu dan, berdasarkan
pada prediksi itu, negosiasikan kualitas pekerjaannya atau apakah akan melakukan tugas sama sekali.
Ini adalah jenis manajemen waktu dinamis yang paling canggih. Idenya adalah
bahwa ketika sebuah aplikasi bersiap untuk memanggil suatu fungsi, itu bernegosiasi dengan
fungsi tentang kualitas dan waktu penyelesaian. Jika aplikasi dan fungsinya
dapat menyepakati trade-off antara kualitas dan waktu penyelesaian, fungsinya adalah
dieksekusi; jika tidak, tidak. Untuk dapat bernegosiasi:

Halaman 339

Menghindari bloopers responsif: Teknik 325

■
Aplikasi harus dapat menyebutkan tenggat waktunya. Ini bisa jadi sulit-
dikodekan ke dalamnya.
■
Aplikasi tersebut harus dapat menyatakan persyaratan kualitasnya. Ini bisa jadi
hardcode.
■
Fungsi tersebut setidaknya harus dapat memprediksi waktu penyelesaian dan indikatornya.
catat kualitas pekerjaannya. Idealnya, itu harus menawarkan berbagai tingkat kualitas
dengan waktu penyelesaian yang berbeda.
■
Protokol negosiasi harus ada untuk menemukan hasil dengan kualitas tertinggi itu
dapat dilakukan dalam tenggat waktu.

Sebagian besar aplikasi presentasi slide — mis., Microsoft Powerpoint — menawarkan transi-
tions antar slide, seperti fade, wipe, zoom, dan page flip. Transi animasi-
tions seharusnya lancar dan cepat, tetapi dapat ditampilkan di komputer
kecepatan yang bervariasi. Ketika presenter mengklik untuk mengubah slide, aplikasi dapat melakukannya
bernegosiasi dengan fungsi transisi untuk menemukan transisi kualitas terbaik (gambar
kualitas dan jumlah frame) yang dapat ditampilkan dalam waktu yang dibutuhkan ini
komputer tertentu. Jika negosiasi gagal menemukan versi yang dapat diterima dari
transisi, aplikasi slide hanya mengalihkan slide tanpa animasi.
Ingat Gambar 7.1C, di mana dua orang di bengkel kamera gagal melakukannya
menyebutkan persyaratan waktu mereka dan secara tidak sengaja melakukan kesalahan dalam penjadwalan-
ing bencana. Sebaliknya, Gambar 7.22 menyajikan situasi di mana para pihak melakukannya
berkomunikasi dan menegosiasikan persyaratan mereka, dengan hasil yang lebih baik.
Teknik yang melibatkan negosiasi waktu proses antara komponen perangkat lunak
mungkin tampak rumit. Namun, mereka tidak lebih rumit dari industri-
protokol standar yang digunakan untuk negosiasi komponen perangkat lunak pada waktu proses
format umum terbaik untuk transfer data, misalnya, ActiveX.

Gambar 7.22 J : Beberapa permintaan bergantung pada waktu.

“Bisakah kamu mengetik memo ini untukku?”
“Saya cukup sibuk. Seberapa cepat Anda membutuhkannya? Saya mungkin bisa melakukannya besok siang. "
“Saya membutuhkannya dalam dua jam. Udah lah. Saya akan mencari orang lain untuk melakukannya atau melakukannya sendiri. "

B : Orang akan sering menerima sesuatu dengan kualitas yang lebih rendah jika lebih berkualitas
lebih mahal.
“Bisakah kita mendapatkan dokumen untuk presentasi besok disalin dalam warna?”
“Ya, tapi saya harus mengirimkannya ke Reprographics. Mereka biasanya memiliki waktu penyelesaian dua hari,
jadi saya harus mengirimkannya sebagai pesanan terburu-buru, yang menaikkan biaya menjadi 50 sen per halaman. Diberikan
jumlah barang yang akan disalin, kurasa biayanya sekitar $ 500. ”
"Mendesah. Salin saja ke mesin fotokopi hitam-putih kita sendiri. ”

[Link] 246/315
26/2/2021 Tanpa judul
Menegosiasikan waktu dan persyaratan kualitas untuk memutuskan apakah akan melakukan tugas.

Halaman 340

326 Bab 7 Responsiveness Bloopers

Ringkasan teknik responsivitas

■ Umpan balik tepat waktu

- Akui masukan pengguna segera (dalam 0,1 detik).
- Menyediakan indikator sibuk atau indikator kemajuan untuk operasi yang diambil
> 1 detik.
- Tunjukkan informasi penting dulu.
- Perhitungan kelas berat palsu hingga final.
■
Solusi masalah paralel
- Menunda pekerjaan sampai ada waktu untuk mengerjakannya.
- Bekerja kedepan jika memungkinkan.
■ Optimasi antrian
- Susun ulang antrian masukan untuk efisiensi.
- Siram tugas yang bisa diperdebatkan.
■
Manajemen waktu yang dinamis
- Pantau antrian acara; sesuaikan strategi atau sumber daya jika terlalu jauh tertinggal.
- Pantau kepatuhan waktu; menurunkan kualitas atau kuantitas untuk mengimbangi.
- Memprediksi waktu respons; memutuskan bagaimana melakukan tugas.
- Memprediksi kepatuhan waktu; menegosiasikan kualitas, apakah akan melakukan tugas sama sekali.

Kesimpulan

Dengan menggunakan teknik di atas, Anda dapat membuat perangkat lunak yang:

■ memberi tahu pengguna secara instan bahwa tindakan mereka telah diterima,
■
memungkinkan pengguna memperkirakan berapa lama waktu yang dibutuhkan untuk operasi,
■ membebaskan pengguna untuk melakukan hal lain sambil menunggu operasi selesai,
■
mengelola acara antrian dengan cerdas dan efisien,
■ melakukan pekerjaan rumah tangga dan prioritas rendah di latar belakang,
■
memanfaatkan waktu idle untuk mengantisipasi (dan menghitung sebelumnya) kemungkinan masa depan pengguna
permintaan.

Namun, untuk perangkat lunak responsif menjadi umum, industri perangkat lunak
harus menyadari bahwa daya tanggap adalah:

■ sangat penting bagi pengguna,

■
berbeda dari kinerja,

Halaman 341

Kesimpulan 327

■
bukan semata-mata masalah implementasi,
■ tidak dapat dipecahkan hanya dengan penyetelan kinerja atau perangkat keras yang lebih cepat.

[Link] 247/315
26/2/2021 Tanpa judul
Sampai fakta-fakta
gigi mereka, ini diakuiapa
bertanya-tanya secara
yangluas, pengguna
sedang perangkat
dilakukan lunak
komputer akan menemukan
mereka diri mereka
atau apakah komputer itusedang
[Link]
Sejarah menunjukkan bahwa prosesor yang lebih cepat tidak akan menyelesaikan masalah. Bahkan
ketika komputer pribadi dan peralatan elektronik sekuat saat ini
superkomputer paling bertenaga, daya tanggap masih akan menjadi masalah karena
perangkat lunak pada hari itu akan menuntut lebih banyak dari mesin dan
jaringan yang menghubungkan mereka. Misalnya, aplikasi perangkat lunak masa depan akan melakukannya
mungkin didasarkan pada:

■ penalaran deduktif;
■
pengenalan gambar;
■ generasi pidato real-time;
■
komunikasi;
■ enkripsi data, otentikasi, dan teknik kompresi;
■
mengunduh file terabyte;
■ komunikasi nirkabel antara lusinan peralatan rumah tangga;
■
pengumpulan data dari ribuan database jarak jauh;
■ pencarian kompleks di seluruh Web.

Hasilnya adalah aplikasi yang menempatkan beban lebih berat di komputer

daripada aplikasi saat ini. Saat komputer tumbuh lebih kuat, sejarah menunjukkan
banyak dari kekuatan itu yang dimakan oleh aplikasi yang menuntut lebih banyak lagi
kekuatan pemrosesan.
Selain itu, meningkatnya penggunaan komputer tertanam yang murah berarti hal itu
tidak semua komputer masa depan memiliki prosesor yang lebih cepat dan memori yang lebih banyak
daripada komputer desktop, laptop, dan server saat ini. Tiga puluh tahun dari sekarang,
Edisi ke-7 buku ini dapat memiliki gambar yang terdiri dari panel datar fleksibel
layar sentuh menyajikan contoh interaktif dari blooper. Masing-masing mungkin
digerakkan oleh komputer kecil yang tertanam hanya dengan kekuatan masa kini
laptop top-of-the-line. Performa dan daya tanggap akan lebih baik
masalah di layar tersebut seperti di komputer saat ini.
Inilah saatnya untuk mulai memperlakukan daya tanggap sebagai masalah kegunaan dan, banyak lagi
khususnya, sebagai masalah desain antarmuka pengguna . Yang penting.

Halaman 342

Halaman ini sengaja dikosongkan

[Link] 248/315
26/2/2021 Tanpa judul

Halaman 343

Pengelolaan
Bloopers
pengantar

Sikap kontraproduktif

Proses kontraproduktif

329

[Link] 249/315
26/2/2021 Tanpa judul

Halaman 344

330 Bab 8 Kesalahan Manajemen

pengantar

Penyebab utama bloopers UI dalam perangkat lunak bukanlah kesalahan oleh program-
mers. Para programmer biasanya melakukan yang terbaik di bawah pengaruh buruk
keadaan. Keadaan yang merugikan diciptakan oleh manajemen mereka.
Bab ini menyajikan cara-cara umum yang menghambat organisasi pembangunan
pengembangan perangkat lunak yang berguna dan berguna.

Lipstik pada bulldog

Konsultan antarmuka pengguna sering dipanggil oleh perusahaan untuk meninjau, mengkritik,
dan meningkatkan UI produk yang buruk sesaat sebelum rilis. Dalam peran itu, kami adalah
sering kali seperti peserta dalam hubungan yang tidak berfungsi dengan merusak diri sendiri
orang. Peran kami adalah memuluskan masalah saat ini — yang tidak dapat digunakan
produk — tanpa mandat atau sumber daya untuk memperbaiki proses yang cacat dan
sikap yang menghasilkannya. Ada dua masalah dengan ini.
Pertama, "merapikan" adalah cara yang baik untuk menggambarkan apa yang bisa dilakukan terlambat
dalam pengembangan; hanya perbaikan dangkal yang mungkin. Dalam, substansial
perbaikan dikesampingkan karena tidak cukup waktu atau kemauan. Seorang rekan menelepon
upaya menit terakhir ini untuk menyelamatkan UI yang buruk "mengolesi lipstik pada bulldog"
(Gambar 8.1).

Gambar 8.1

Mencoba memperbaiki UI di akhir pengembangan seperti meletakkan lipstik di bulldog.

Halaman 345

Sikap kontraproduktif 331

Kedua, terbatasnya peran konsultan UI membuat perusahaan sulit meninggalkan perusahaan.

nies lebih baik daripada saat kita mulai. Klien mempekerjakan kami untuk mengidentifikasi produk mereka
kekurangan kegunaan dan menyarankan cara memperbaikinya dengan cepat dan murah. Mereka menggunakan
sekutu jangan mempekerjakan kami untuk membantu mereka memperbaiki proses pengembangan, organisasi
struktur nasional, atau budaya perusahaan yang memungkinkan produk tidak dapat digunakan — atau salah satunya
yang tidak sesuai dengan kebutuhan pelanggan mana pun — untuk dikembangkan. Terkadang sepertinya
bahwa konsultan UI membantu perusahaan mengabaikan, dan karenanya mengabadikan, kenyataan mereka
masalah.

Memutus siklus
[Link] 250/315
26/2/2021 Tanpa judul

Untuk membantu industri menghentikan perilaku disfungsionalnya, bab ini menjelaskan

kesalahpahaman manajemen dan kesalahan yang biasanya berada di luar tujuan
pandangan konsultan UI, namun hal itu menyebabkan kegunaan produk yang buruk.
Mereka terbagi dalam dua kategori: (1) sikap kontraproduktif tentang kegunaan
dan (2) proses pembangunan yang kontraproduktif. Mereka adalah yang paling penting-
kesalahan besar dalam buku ini, serta yang paling sulit untuk diperbaiki. Jika perangkat lunak berkembang-
ers mengenali kesalahan besar ini di perusahaan mereka sendiri, dan mengambil langkah untuk memperbaikinya
mereka, industri perangkat lunak dan publik akan mendapatkan keuntungan, dan konsultan UI dapat melakukannya
menghabiskan lebih sedikit waktu sebagai ahli kosmetik bulldog.
Penulis lain telah mengabdikan seluruh buku untuk masalah tingkat manajemen
yang menghalangi kegunaan dan kegunaan perangkat lunak, misalnya:

■
The Trouble with Computers, oleh Tom Landauer [1995];
■
The Inmates Are Running the Asylum, oleh Alan Cooper [1999];
■
The Invisible Computer, oleh Don Norman [1999].

Jakob Nielsen juga membahas masalah kegunaan tingkat manajemen dalam karyanya
Blog AlertBox [[Link]]. Scott Berkun menjelaskan bagaimana mengelola pembangunan
proyek secara efektif dalam bukunya The Art of Project Management [2005].

Sikap kontraproduktif

Pertama, kami memeriksa kesalahpahaman manajemen dan sikap yang salah itu
pada akhirnya menyebabkan banyak blooper yang dijelaskan di tempat lain dalam buku ini.

Blooper 64: Memperlakukan UI sebagai prioritas rendah

Di banyak organisasi pengembangan perangkat lunak, antarmuka pengguna dan kegunaan

masalah memiliki prioritas rendah dibandingkan dengan masalah lainnya. Ini memiliki beberapa bentuk.

Halaman 346

332 Bab 8 Kesalahan Manajemen

Variasi A: Dengan asumsi bahwa kegunaan memiliki dampak yang rendah

tentang kesuksesan pasar

Beberapa manajer dan pengembang perangkat lunak percaya bahwa kegunaan produk memiliki
berdampak kecil pada kesuksesan pasarnya. Mereka salah.
Gambar 8.2 menunjukkan pengeluaran dan pendapatan kumulatif dari waktu ke waktu untuk perangkat lunak
proyek pengembangan. Setelah proyek dimulai, biaya menumpuk. Setelah
produk dilepaskan, pendapatan mulai bertambah. Waktu dari awal hingga rilis
adalah waktu untuk memasarkan. Jika produk sama sekali berhasil, di beberapa titik setelahnya
rilis, pendapatan total melebihi biaya total. Itu adalah titik impas. Itu
waktu dari awal hingga titik impas adalah waktu menuju profitabilitas.
Kebanyakan manajer terpaku pada meminimalkan waktu ke pasar. Namun, eko-
Analisis nomik menunjukkan bahwa mempersingkat waktu menuju profitabilitas biasanya lebih banyak
penting bagi kesehatan jangka panjang perusahaan daripada mempersingkat waktu ke pasar.
Mempertimbangkan kegunaan di awal proyek dapat menunda waktu untuk memasarkan dan meningkatkan ini-
biaya tial, tetapi biasanya membayar investasi itu dengan meningkatkan pendapatan dan pengurangan
ing biaya hilir [Conklin, 1996].
Memiliki produk yang lebih bermanfaat dengan kecepatan rilis penerimaan pasar dan
meningkatkan kemiringan kurva pendapatan (Gambar 8.3). Tingkat pendapatan yang tinggi
kurva tepat setelah rilis produk memiliki dampak yang jauh lebih besar pada waktu ke laba-
kemampuan dan pendapatan jangka panjang dibandingkan tanggal pasti rilis. Bergegas a
produk ke pasar tanpa memastikan kegunaannya mengurangi kemiringan
kurva pendapatan dan meningkatkan dukungan pelanggan dan biaya pelatihan, mendorong
titik impas, sehingga memperpanjang waktu untuk profitabilitas.

Gambar 8.2
Waktu menuju Profitabilitas

$$$ Beban
Pendapatan

[Link] 251/315
26/2/2021 Tanpa judul

Saatnya ke Pasar Melepaskan Impas

tanggal tanggal

Waktu
Total biaya dan pendapatan dari waktu ke waktu untuk proyek pengembangan perangkat lunak normal.

Halaman 347

Sikap kontraproduktif 333

Gambar 8.3 Berinvestasi dalam kegunaan dari awal proyek

Tidak

Waktu menuju Profitabilitas

$$$ Beban
Pendapatan

Saatnya ke Pasar
Melepaskan Impas
Waktu sedikit kemudian sebelumnya

Total biaya dan pendapatan dari waktu ke waktu dengan dan tanpa investasi kegunaan awal.

Selain itu, berinvestasi dalam kegunaan di awal proyek tidak selalu

memperpanjang waktu ke pasar. Seringkali, itu mempersingkatnya :

1. Ini memberi programmer target implementasi yang jelas, daripada membiarkan mereka
hack tanpa tujuan. Saat Anda tahu kemana tujuan Anda, Anda bisa sampai di sana
lebih cepat.
2. Menyederhanakan implementasi dengan menyediakan desain yang koheren dan dapat difaktorkan
menyediakan fungsionalitas yang dibutuhkan pengguna.
3. Ini melokalkan lebih banyak iterasi desain dalam revisi spesifikasi kertas,
sketsa, dan prototipe dengan ketelitian rendah, yang biayanya lebih murah daripada perubahan
Kode Produk.

DILBERT | © Scott Adams / Dist. oleh United Feature Syndicate, Inc.

Halaman 348

[Link] 252/315
26/2/2021 Tanpa judul

334 Bab 8 Kesalahan Manajemen

Analisis yang lebih baru tentang nilai bisnis dari investasi dalam kegunaan bisa jadi
ditemukan dalam buku Cost-Justifying Usability [Bias dan Mayhew, 2005] dan
Memprioritaskan Kegunaan Web [Nielsen dan Loranger, 2006].
Sejak berinvestasi dalam kegunaan awal dalam pengembangan biasanya mempersingkat waktu
profitabilitas, meningkatkan pendapatan total, dan mempersingkat waktu ke pasar, manajer
yang tidak melakukannya berarti melakukan kesalahan besar.

Variasi B: Dengan asumsi bahwa UI hanya "font dan warna"

Beberapa manajer pengembangan memiliki pandangan sempit tentang "antarmuka pengguna"

termasuk: keyakinan yang salah bahwa ini hanya tentang aspek yang paling dangkal
perangkat lunak dan karena itu dapat ditunda sampai sebelum pengiriman. Sebagai contoh,
salah satu pengembang mengatakan kepada saya “Desain UI sering disebut oleh manajer di sini sebagai 'font
dan warna '. "
Desain antarmuka pengguna tidak hanya tentang font dan warna. Bahkan tidak terutama
tentang font dan warna (Blooper 65, halaman 337). Ini lebih tentang interaksi: bagaimana
perangkat lunak berperilaku, bukan seperti apa tampilannya. Ini mencakup "dalam"
masalah seperti kemudahan yang dapat digunakan pengguna untuk mempelajari perangkat lunak, kesesuaian file
fungsionalitas perangkat lunak untuk tujuan pengguna, pemetaan langsung antara
konsep dalam domain tugas dan yang disajikan oleh perangkat lunak, dan efisiensi
efisiensi yang dengannya operasi umum dapat dilakukan. Masalah ini bisa-
tidak ditunda sampai akhir pembangunan. Jika mereka tidak dipertimbangkan sejak awal
pengembangan dan diuji di sepanjang jalan, mereka tidak akan cukup di rilis
Versi: kapan.

Variasi C: Dengan asumsi bahwa pengguna dapat beradaptasi dengan apa pun

Keyakinan umum dalam industri perangkat lunak adalah bahwa UI tidak penting: manusia
akan belajar menggunakan apa pun yang menyediakan fungsionalitas yang mereka butuhkan. Ini adalah
sebagian benar. Jika suatu produk tidak memiliki persaingan atau captive market, maka
fungsionalitas yang dibutuhkan mungkin cukup. Orang-orang sangat mudah beradaptasi dan
dapat mempelajari hal-hal menakjubkan jika cukup termotivasi dan jika tidak diberikan yang lain
pilihan.
"Jika" itu sangat penting. Hanya karena orang bisa melakukan sesuatu, tidak
berarti mereka akan melakukannya . Dalam pasar yang kompetitif, berisiko untuk mengasumsikan bahwa prospek
tive pelanggan akan mengabaikan kemudahan penggunaan yang buruk dan membeli produk karena fiturnya
daftar makanan. Mengapa harus demikian? Mungkin tidak ada yang membayar mereka untuk belajar menggunakannya.
Mungkin mereka tidak punya waktu untuk bergumul dengannya. Perangkat lunak pesaing mungkin
lebih mudah digunakan sekaligus menyediakan fungsionalitas serupa. Jika potensi adat-
Pengguna tidak menyukai perangkat lunak Anda dan tidak membeli atau menggunakannya, mereka bukanlah pihak yang merugi,
kamu adalah.

Halaman 349

Sikap kontraproduktif 335

Situs belanja culun tidak berhasil

Selama ledakan dot-com, sebuah perusahaan rintisan sedang mengembangkan aplikasi Web
untuk perbandingan belanja. Idenya adalah bahwa konsumen akan mengunduh aplikasi
kation dan menggunakannya untuk menemukan harga terbaik untuk apa pun yang ingin mereka beli. Pengguna
akan mengetikkan nama produk dan mendapatkan kembali tabel yang menunjukkan harga berbeda
toko online. Aplikasi ini juga memiliki keranjang belanja untuk membeli barang dan keinginan
daftar untuk menyimpan item untuk kemungkinan pembelian nanti.
Perusahaan tidak memiliki staf desainer UI dan tidak melakukan riset pengguna. Di
ruang belakang, pemrogram visa-H1 menghasilkan kode berdasarkan sedikit deskripsi
tions dan beberapa sketsa yang dibuat oleh para eksekutif. UI aplikasi sangat buruk:
penuh dengan kesalahan besar umum yang dijelaskan dalam buku ini serta beberapa kekurangan unik.
Ketika manajemen mulai mencurigai bahwa produk mereka tidak ramah pengguna,
mereka memutuskan untuk melakukan uji kegunaan untuk melihat dengan tepat seberapa buruk itu.
Manajemen puncak, termasuk CEO, Ketua, dan Wakil Presiden pengamat Teknik-
ved sesi tes dari balik jendela satu arah. Setelah duduk sampai pukul tiga
sesi pengujian yang menyakitkan, di mana tidak ada pembeli yang dapat menyelesaikan salah satu
belanja tugas tanpa bantuan, Ketua berdiri, menghadap yang lain, dan berkata

[Link] 253/315
26/2/2021 Tanpa judul
Sayangnya, “Tuan-tuan, produk kami masih lahir.” Perusahaan bangkrut beberapa bulan kemudian.

Variasi D: Rasionalisasi

Untuk beberapa manajer perangkat lunak, menganggap kegunaan sebagai prioritas rendah hanyalah a
rasionalisasi: salah satu cara untuk melakukan triase dalam menanggapi anggaran yang ketat, ketat
sumber daya, dan jadwal yang ketat.
Antarmuka pengguna bukanlah fitur produk yang dapat dibuang untuk memenuhi a
tenggat waktu. Ini adalah bagaimana fungsionalitas disajikan dan dikendalikan. Kualitas dari
UI menentukan nilai setiap fitur serta nilai produk secara keseluruhan.
Produk tanpa UI yang efektif seperti toko buku tempat buku berada
tumpukan sesuai ukurannya: buku yang Anda inginkan mungkin ada di sana, tetapi Anda tidak dapat menemukannya.

Variasi E: Menetapkan GUI untuk programmer junior

Banyak manajer pengembangan menganggap UI sangat rendah sehingga mereka menetapkannya

untuk programmer yang kurang berpengalaman. Di beberapa perusahaan, tugas mengembangkan a
GUI untuk produk ditugaskan untuk karyawan baru atau magang musim panas.
Sisi lain dari menugaskan pengembangan GUI untuk programmer yang tidak berpengalaman
adalah bahwa insinyur yang merancang dan mengembangkan GUI cenderung berstatus lebih rendah daripada
mereka yang mengembangkan perangkat lunak sistem. Ini dijelaskan lebih lengkap oleh Ellen
Ullman dalam esai berwawasan tentang bekerja sebagai programmer [1995]:

Halaman 350

336 Bab 8 Kesalahan Manajemen

Dalam kehidupan biasa, kata “rendah” biasanya berarti sesuatu yang buruk. Dalam pemrograman, "rendah" adalah
baik. Rendah lebih baik.

Jika kode membuat program yang melakukan pekerjaan berguna untuk manusia biasa, itu
disebut "lebih tinggi". Program tingkat yang lebih tinggi disebut "aplikasi". Aplikasi
adalah hal-hal yang digunakan orang. Meskipun tampaknya kegunaan itu oleh orang-orang
akan menjadi hal yang baik, dari sudut pandang programmer, penggunaan orang langsung
buruk. Jika orang biasa, yang disebut "pengguna," dapat memahami tugas yang diselesaikan
oleh program Anda, Anda akan dibayar lebih sedikit dan dihargai lebih rendah. Secara reguler
dunia, istilah "lebih tinggi" mungkin lebih baik, tetapi, dalam pemrograman, lebih tinggi lebih buruk.
Tinggi itu buruk.

Jika Anda menginginkan uang dan prestise, Anda perlu menulis kode yang hanya mesin atau
programmer lain mengerti. Kode seperti itu "rendah".

Manajer menetapkan pengembangan GUI untuk programmer yang kurang berpengalaman

meminimalkan biaya. Programmer junior dibayar lebih sedikit. Desainer UI berpengalaman
atau pemrogram menuntut gaji yang lebih tinggi (atau biaya konsultasi). Jadi, mempekerjakan banyak
dari pemrogram junior, tetapi sedikit pemrogram yang sangat berpengalaman, perangkat lunak
arsitek, atau desainer, "menghemat" uang.
Namun, Anda mendapatkan apa yang Anda bayar. Penempatan staf dengan cara ini lebih mahal daripada
itu menghemat. Ini menghasilkan kegunaan yang buruk, dukungan pelanggan dan biaya pelatihan yang tinggi,
pelanggan yang tidak puas, penjualan yang lesu, dan pasar yang kecil dan stagnan.

Menghindari Blooper 64

Manajemen harus memprioritaskan pengembangan produk yang memiliki

antarmuka pengguna berkualitas:

■
Kegunaan memiliki dampak yang kuat pada keberhasilan produk: meningkatkan ini-
penerimaan pasar tial dan mempersingkat waktu untuk profitabilitas, sehingga meningkat
total pendapatan.
■
Antarmuka pengguna adalah tentang masalah "mendalam", bukan hanya "font dan warna". Penggunaan mendalam-
Masalah bility yang ditemukan terlambat dalam pengembangan akan sulit untuk diperbaiki karena

[Link] 254/315
26/2/2021 Tanpa judul

DILBERT | © Scott Adams / Dist. oleh United Feature Syndicate, Inc.

Halaman 351

Sikap kontraproduktif 337

mereka membutuhkan perubahan arsitektural. Menguji dan memperbaiki masalah kegunaan melalui-
keluar pengembangan, dimulai lebih awal.
■
Pengguna dapat beradaptasi dengan UI yang buruk, tetapi mengandalkan itu bodoh karena dalam file
pasar yang terbuka dan kompetitif, pelanggan tidak perlu beradaptasi: mereka dapat memilih
produk pesaing.
■
UI tidak dapat dibatalkan untuk memenuhi jadwal atau batasan anggaran. Ini per-
vades dan mempengaruhi seluruh produk. Jika UI produk buruk, produk
uct buruk, karena UI adalah aspek produk yang pelanggan
pengalaman.
■
Pengalaman itu penting. Mengembangkan GUI yang baik tidak hanya membutuhkan kepekaan
pengguna dan masalah mereka, itu juga membutuhkan kemampuan untuk membuat perangkat GUI
melakukan segala sesuatu selain backflips. Seringkali membutuhkan pemrograman waktu nyata
keterampilan, termasuk pemrograman multithread. Pastikan GUI Anda
programmer memiliki keterampilan untuk membuat kode desain yang ditentukan sesuai jadwal.

Blooper 65: Salah paham tentang pengguna

profesional antarmuka lakukan

Antarmuka pengguna dan profesional kegunaan memiliki masalah: banyak masalah lain di
industri perangkat lunak tidak memahami apa yang kami lakukan. Percakapan berikut ini
sayangnya umum:

Manajer pengembangan: “Anda adalah konsultan antarmuka pengguna? Apakah Anda seorang Windows
peretas toolkit atau peretas toolkit Java? ”

Konsultan: "Tidak Keduanya".

DM: “Oh. Maka Anda harus menjadi seorang hacker XHTML, atau seorang hacker PERL,… atau seorang Visual
Peretas BASIC. "

C: “Tidak. Saya merancang antarmuka dan interaksi pengguna. Jika saya membutuhkan programmer untuk
menerapkan atau membuat prototipe desain saya, saya menyewa satu. "

DM: “Hmmm… seorang desainer. Anda menggambar ikon dan membuat tautan Web
dan tombol terlihat keren. ”

C: “Um, tidak. Saya bukan seorang desainer grafis. Saya seorang interaksi dan desainer UI. Jika saya
membutuhkan seorang desainer grafis untuk membuat visual yang realistis untuk sebuah desain, saya menyewa satu. "

DM: “Anda bukan programmer GUI, dan Anda bukan desainer grafis. … Jadi
Apa yang kamu kerjakan?"

Banyak manajer pengembangan tidak jelas tentang perbedaan antara antar pengguna
desainer wajah dan pemrogram antarmuka pengguna . Lainnya tidak jelas tentang dis-
tinction antara desainer grafis dan desainer antarmuka pengguna . Mari kita periksa
dua kesalahpahaman pada gilirannya.

Halaman 352

338 Bab 8 Kesalahan Manajemen

Variasi A: Dengan asumsi programmer GUI adalah desainer GUI

Banyak manajer pengembangan perangkat lunak secara keliru percaya bahwa semua itu diperlukan

[Link] 255/315
26/2/2021 Tanpa judul
mengembangkan perangkat lunak yang mudah digunakan adalah mempekerjakan pemrogram terampil yang memiliki pengalaman-
ence menggunakan alat pengembangan antarmuka pengguna dan toolkit komponen. Menurut
untuk kesalahpahaman ini, setelah Anda memiliki programmer GUI yang baik, Anda baru saja
harus memberi tahu mereka perangkat lunak apa yang harus ditulis dan memberi mereka waktu dan sumber daya
untuk menulisnya. Manajer sering kali menganggap boros untuk mempekerjakan orang yang merancang GUI
atau lakukan uji kegunaan tetapi tulis sedikit atau tidak ada kode sama sekali.
Ini kesalahan besar yang serius. Ini mencerminkan kesalahpahaman yang mendalam tentang apa
Pemrogram GUI versus GUI dan perancang interaksi berkontribusi pada pengembangan
usaha operasi. Itu juga dapat mencerminkan pengabaian nilai UI yang dirancang dengan baik
(Blooper 64, halaman 331).
Kebanyakan manajer pengembangan menyadari bahwa pemrogram yang tidak berpengalaman
enced dalam menggunakan toolkit GUI sering menghasilkan GUI yang buruk: mereka tidak selalu bisa membuatnya
perangkat melakukan apa yang mereka inginkan. Lebih sedikit manajer pengembangan yang menyadari hal itu
programmer berpengalaman yang tahu toolkit luar dalam dapat menghasilkan
UI yang buruk, bahkan dengan banyak waktu dan sumber daya. Ada beberapa alasan:

■
Kurangnya pengalaman desain GUI: Pengalaman pemrograman tidak sama dengan
Pengalaman desain UI, dan pengalaman pemrograman GUI belum tentu
pengalaman mendesainnya.
■
Merancang GUI agar sesuai dengan toolkit: Jika seorang programmer mengetahui toolkit dengan sangat baik tetapi
kurang memahami — atau empati untuk — bagaimana orang berpikir dan bekerja,
kenyamanan pemrograman bisa menang.
■
Keterampilan kerja tim yang buruk: Pemrogram terbaik sering kali berkemauan keras
orang yang tidak berkompromi atau bernegosiasi dengan mudah dengan orang lain. Ketika sebuah
tim pengembangan terdiri dari beberapa anggota dan manajemennya
tidak menegaskan otoritas, masing-masing akan melakukan hal-hal dengan caranya sendiri, akibatnya
dalam banyak inkonsistensi (Blooper 67, halaman 348).

Alasan penting lainnya mengapa programmer yang baik menghasilkan GUI yang buruk dibahas
oleh Gentner dan Grudin [1990].

Variasi B: Asumsi desainer grafis adalah desainer GUI

Beberapa manajer pengembangan memahami bahwa merancang perangkat lunak yang mudah digunakan
mereka membutuhkan lebih dari sekadar pemrogram GUI yang baik di tim mereka, tetapi tetap saja
tidak jelas tentang keahlian lain yang dibutuhkan. Banyak yang tidak mengerti perbedaannya.
perbedaan antara desain UI dan desain grafis. Mereka pikir antarmuka penggunanya
hanya tampilan sebuah aplikasi, jadi mereka mempekerjakan ahli penampilan — grafis
desainer — untuk mendesainnya. Hasil dari keputusan seperti itu bisa menjadi produk itu
demo dengan baik tetapi tidak mendukung tugas pengguna dengan baik.

Halaman 353

Sikap kontraproduktif 339

Kesalahpahaman ini menjadi lebih umum sebagai situs Web dan aplikasi Web.
kation tumbuh lebih menarik, membawa daya tarik estetika, kesadaran merek, dan hiburan-
nilai lebih ke garis depan. Dengan meningkatnya frekuensi, calon klien
menunjukkan bahwa mereka mewawancarai UI dan desainer grafis untuk pekerjaan yang sama:

Manajer: “Kami sedang berbicara dengan pria lain dengan gelar seni yang merupakan jagoan sejati
dengan DreamWeaver, Visio, dan PhotoShop dan mengenakan biaya sepertiga dari jumlah yang Anda miliki
biaya."

Saya menganggap ini sebagai peringatan bahwa manajer perekrutan mungkin tidak memahami UI apa
dan desain interaksi. Terkadang saya mencoba mendidik manajer di sana
di tempat; lain kali saya hanya berkata: “Oke. Hubungi saya jika dia sudah selesai. ”

Menugaskan pekerjaan untuk amatir menghasilkan perangkat lunak amatir

Bayangkan Anda sedang merencanakan rumah impian Anda. Anda menginginkan kelistrikan yang canggih
kabel, jadi Anda menyewa tukang listrik terkemuka. Anggaran Anda terbatas, jadi Anda bertanya
tukang listrik untuk juga mendesain pipa rumah, pemanas, isolasi, bingkai,
atap, dan pondasi.
Konyol? Sejauh ini, inilah yang dilakukan banyak organisasi dengan properti
lebih berharga daripada rumah mana pun: produk perangkat lunak dan situs Web mereka. Orang-orang
yang profesional dalam menulis perangkat lunak diberi tugas tambahan
mereka adalah amatir. Ini setidaknya sebagian karena manajemen mempertimbangkan UI dan
kegunaannya menjadi prioritas rendah (Blooper 64, di atas) dan berpikir bahwa mereka dapat menabung
uang dengan meminta programmer untuk merancang UI juga. Hasil yang mungkin terjadi adalah beberapa
dari bloopers yang dijelaskan di tempat lain dalam buku ini. Kesalahan dari kesalahan besar seperti itu terletak

[Link] 256/315
26/2/2021 Tanpa judul
bukan dengan programmer yang mengikatnya, melainkan dengan manajernya .

Menghindari Blooper65

Untuk menghindari melakukan kesalahan besar ini, manajer perlu memahami perbedaan-
ence antara programmer UI dan desainer UI dan perbedaan antara UI
desainer dan desainer grafis. Kemudian mereka perlu memastikan semua itu
keterampilan hadir di — atau setidaknya tersedia untuk — tim pengembangan mereka.

Jangan bingung programmer GUI dengan desainer GUI

Mengetahui pertukangan tidak membuat seseorang menjadi desainer furnitur yang banyak dicari
atau rumah. Mempelajari cara membaca dan menulis musik tidak mengubah seseorang menjadi a
komposer melodi abadi. Demikian pula, mengetahui bagaimana menggunakan program GUI-
alat dan komponen ming tidak berarti bahwa seseorang akan tahu apa yang harus dilakukan
bersama mereka untuk membuat perangkat lunak yang berguna dan berguna.

Halaman 354

340 Bab 8 Kesalahan Manajemen

Memiliki pemrogram GUI yang baik dalam sebuah tim tidak menghilangkan ekstensi
kebutuhan desainer GUI. Manajemen harus memastikan bahwa produknya ada
dirancang oleh orang-orang yang memahami interaksi manusia-komputer dan pengguna
Persyaratan.

Jangan bingung antara desainer grafis dengan desainer GUI

Merancang GUI dan mendesain tampilan grafis GUI berbeda

kegiatan, membutuhkan keterampilan yang berbeda. Kedua jenis keterampilan tersebut dibutuhkan untuk mendesain
GUI yang bagus, tetapi berbeda.
Desainer UI terampil dalam menganalisis dan memahami kebutuhan tugas pengguna-
ments dan konteks kerja, dalam menyederhanakan kompleksitas, dalam menentukan apa
kontrol dan informasi diperlukan untuk mendukung tugas-tugas target, dan
mengetahui di mana pengguna akan kesulitan mempelajari atau menggunakan aplikasi. Beberapa
Desainer UI juga tahu bagaimana mempersiapkan, melakukan, dan menganalisis uji kegunaan.
Desainer UI kurang peduli dengan bagaimana perangkat lunak terlihat dan lebih
prihatin dengan bagaimana ia berperilaku, betapa mudahnya untuk dipelajari, dan apakah itu membantu
pengguna mencapai tujuan mereka. Misalnya, tombol aplikasi mungkin terlihat
menarik, tetapi penggunanya mungkin masih tidak tahu mana yang harus diklik untuk dicapai
tujuan mereka. Masalahnya bisa jadi label tombol yang tidak jelas, atau bisa juga
lebih dalam: fungsi tombol tidak terkait dengan tujuan pengguna. Mungkin beberapa dari
tombol bahkan bisa dihilangkan jika alur tugas lebih sederhana. Di sini adalah
perbaikan yang dapat dilakukan oleh desainer UI untuk membantu perusahaan mencapai:

■
Kurangi jumlah perintah dari dua ratus menjadi dua lusin
■ Ratakan hierarki menu dari empat tingkat menjadi dua
■
Kurangi jumlah jendela dari 18 menjadi 8
■ Hilangkan setengah dari klik yang diperlukan untuk menyelesaikan tugas umum
■
Kurangi waktu untuk mempelajari aplikasi dari dua minggu menjadi dua jam
■ Tambahkan link ke halaman muka situs Web yang membawa pengguna dalam satu klik ke populer
kandungan
■
Atur ulang kategori situs Web e-niaga agar sesuai dengan cara penggunanya
mengkategorikan produk
■ Ubah UI dari mengekspos logika implementasi yang berbelit-belit menjadi penyajian
fungsi sederhana yang memungkinkan pengguna mencapai tujuan mereka

Sebaliknya, desainer grafis yang terampil tahu bagaimana memberikan hierarki visual yang jelas.
archy, memfokuskan perhatian pengguna, mendesain simbol yang dapat dikenali, menyampaikan fungsi
secara grafis, sajikan data secara efektif, gunakan tipografi dengan baik, maksimalkan produksi
nilai-nilai, dan merancang gaya grafis yang konsisten untuk digunakan di seluruh aplikasi
atau lini produk (Prinsip Dasar 6, halaman 37).
Area yang tumpang tindih antara perhatian desainer UI dan
desainer grafis adalah tata letak kontrol dan informasi dalam tampilan perangkat lunak.

[Link] 257/315
26/2/2021 Tanpa judul

Halaman 355

Sikap kontraproduktif 341

Tabel 8.1 Membandingkan keterampilan desainer GUI, desainer grafis, dan programmer GUI

Wewenang Keterampilan

Desainer GUI • Analisis tugas, desain konseptual

• Desain interaksi: konteks, organisasi tingkat tinggi, alur tugas
• Desain UI: masukan dan keluaran
• Sasaran tanggap waktu nyata
• Evaluasi kegunaan, pengujian kegunaan
• Menilai kesesuaian dengan standar kegunaan
• Tata Letak

Perancang grafis • Membuat gambar yang dapat dikenali, simbol intuitif

• Nilai-nilai produksi, daya tarik estetika, kesadaran merek
• Memanfaatkan media tampilan yang tersedia dengan sebaik-baiknya
• Fungsi penyampaian secara grafis
• Tata letak, hierarki visual
• Konsistensi visual

Pemrogram GUI • Prototipe dinamis

• Menerapkan desain yang ditentukan: arsitektur internal,
pemrograman
• Pengetahuan tentang perangkat GUI
• Memaksimalkan kinerja, memenuhi tujuan waktu nyata
• Menilai dan menjelaskan kendala teknis, biaya, dan risiko

Tampilan detail setiap kontrol jelas merupakan tanggung jawab sebuah grafik
perancang. Kontrol apa yang dibutuhkan dan bagaimana mereka beroperasi jelas merupakan
tanggung jawab desainer UI. Kedua jenis desainer akan memiliki ide tentang
bagaimana kontrol diletakkan di layar. Tumpang tindih peran ini adalah salah satu alasannya
orang terkadang bingung dengan kedua jenis desainer (lihat Tabel 8.1).
Untuk menghindari aplikasi amatir, peralatan, dan situs Web yang sarat dengan
blooper, dapatkan profesional yang tepat untuk setiap pekerjaan.

Blooper 66: Mengurangi nilai pengujian dan desain berulang

Banyak manajer pengembangan tidak melihat perlunya jadwal pengembangan

termasuk pengujian kegunaan atau waktu untuk revisi UI yang signifikan. Satu akan berharap
Sikap puluhan tahun ini menghilang karena munculnya perkembangan Agile dan
Metode pemrograman ekstrem (XP), yang memerlukan pengujian dan desain yang sering
iterasi, tetapi belum. Alasannya beragam.

Variasi A: Agile / XP hanya dalam nama

Beberapa tim pengembangan perangkat lunak mengatakan mereka menggunakan metode Agile atau XP, tetapi
sebenarnya tidak. Ini dibahas lebih lengkap di Blooper 67 (halaman 348); untuk

Halaman 356

342 Bab 8 Kesalahan Manajemen

sekarang cukup untuk mengatakan bahwa beberapa tim melabeli diri mereka "Agile / XP" untuk bergaya
dan untuk membenarkan tidak menggunakan dokumen spesifikasi, tetapi tidak melakukan sebagian besar dari apa
Agile / XP membutuhkan. Dalam tim seperti itu, adalah umum menemukan sikap kuno
masih berkembang, termasuk sikap bahwa pengujian kegunaan tidak diperlukan.

Variasi B: Desainer yang baik tidak membutuhkan iterasi

Beberapa manajer desain UI menganggap bakat kreatif misterius sebagian orang

memiliki. Dalam pandangan ini, desainer UI adalah seniman yang mengolah otak kanannya, memohon
inspirasi mereka, dan memunculkan GUI yang luar biasa dalam kilatan inspirasi yang membutakan.

[Link] 258/315
26/2/2021 Tanpa judul
Semakin baik perancangnya, semakin cepat flash dan semakin baik desainnya.
Ada keuntungan diperlakukan sebagai pesulap atau artis. Desainer UI
dapat menuntut bayaran yang lebih tinggi jika klien kami percaya apa yang kami lakukan itu ajaib. Manajer
kecil kemungkinannya untuk mencoba mengelola mikro seniman kreatif.
Namun, kerugiannya lebih besar daripada keuntungannya. Satu kelemahan dari
mempertimbangkan desainer UI untuk menjadi seniman adalah bahwa itu menghasilkan mentalitas "superstar":
semua orang ingin produk mereka dirancang oleh beberapa ahli desain UI terkenal
yang membebankan tarif setinggi langit dan dipesan jauh ke masa depan, sementara ratusan
desainer UI yang kompeten mengalami kesulitan menemukan kontrak atau pekerjaan permanen.
Ini buruk bagi industri karena banyak produk dan layanan perangkat lunak tidak
dapatkan perhatian UI yang mereka butuhkan.
Kerugian yang lebih penting adalah memandang desainer UI sebagai orang yang kreatif
seniman membuat ekspektasi yang salah tentang perlunya pengujian dan revisi. UI
desain adalah jenis rekayasa, yang membutuhkan pengujian dan revisi.
Memperlakukannya sebagai seni kreatif membuat seseorang mengabaikan atau mengabaikan kebutuhan desainer
untuk menghasilkan dan mempertimbangkan desain alternatif dan untuk menguji, mengevaluasi, dan merevisi a
rancangan. Mempertimbangkan desain alternatif, menurut pandangan ini, boros dan
tanda ketidaktegasan dan pengalaman. Merevisi desain dianggap sebagai
pengakuan kegagalan: jika desain baru lebih baik, desain lama pasti jelek
dan karena itu merupakan kerugian bagi desainer. Kepada manajer yang memiliki pikiran ini
set, seorang desainer UI yang meminta pengujian kegunaan mengakui ketidakmampuan.
Manajer sebenarnya mengatakan:

“Mengapa kita membuang-buang waktu dengan mempertimbangkan alternatif desain yang tidak akan kita gunakan? Jangan
Anda tahu desain mana yang lebih baik? ”

“Mengapa kita perlu mengujinya? Kami mempekerjakan Anda karena Anda seharusnya menjadi orang baik
perancang. Bukankah kamu? ”

“Kami tidak punya waktu untuk menguji dan merevisi. Kami membutuhkan Anda untuk berusaha
mendesainnya dengan benar pada kali pertama. ”

Kode terus diuji dan direvisi. Metode Agile / XP bergantung pada iterasi. Namun,
dalam hal desain UI, kebutuhan akan iterasi kurang diakui secara luas.

Halaman 357

Sikap kontraproduktif 343

Tentunya, dengan desainer UI yang berpengalaman di tim Anda, Anda dapat melakukannya
lebih percaya diri bahwa desain pertama akan lebih baik daripada yang Anda bisa jika desainer
adalah seorang pemula. Namun, menggunakan desainer berpengalaman dan terampil tidak menghilangkan
kebutuhan untuk pengujian kegunaan dan desain berulang.
Katakanlah GUI berkisar dalam kualitas dari 1 sampai 10. Seorang desainer UI baru mungkin
awalnya mengusulkan desain kualitas 3-5. Pengujian kegunaan dan desain ulang mungkin
tingkatkan ke kualitas 6–8. Mungkin desain pertama seorang desainer berpengalaman
memiliki kualitas 5–7. Namun, pengujian dan revisi tetap akan meningkatkan kualitasnya,
mungkin sampai 8–10. Terlepas dari desainer mana yang dipekerjakan, pengujian dan revisi
akan meningkatkan produk.

Bagaimana desainer UI mendapatkan pengalaman?

Untuk desainer UI, menjadi "berpengalaman" tidak hanya membutuhkan pengalaman desain, tetapi
juga evaluasi dan pengalaman pengujian. Desainer mungkin telah mendesain ratusan
produk perangkat lunak, tetapi jika mereka belum menerima umpan balik tentang desain tersebut
dari profesional UI lainnya dan dari mengamati pengguna, semua desain itu diperhitungkan
untuk sangat sedikit. Melacak keberhasilan atau kegagalan produk di pasar
tidak cukup, karena banyak faktor selain kegunaan yang berkontribusi untuk itu.
Pengalaman dibangun dengan menerima umpan balik eksplisit tentang masalah kegunaan
dalam desain seseorang dan menggunakan umpan balik itu untuk merevisi desain. Jadi, kegunaan
pengujian dan revisi tidak hanya menghasilkan desain yang lebih baik, tetapi juga menghasilkan lebih baik
desainer . Inilah salah satu alasan pekerjaan tingkat awal di bidang kegunaan cenderung masuk
pengujian kegunaan daripada desain UI.

Menguji dan merevisi juga merupakan cara untuk mengurangi risiko. Manajemen ingin file
risiko kegagalan pasar hampir nol, tapi itu terlalu mahal. Sebaliknya, jalankan dengan baik
vendor perangkat lunak mengurangi risiko mereka dalam meluncurkan produk baru ke "alasan-
tingkat ble ”. Melakukan pengujian kegunaan dan merevisi UI sangat baik dan
cara yang relatif murah untuk mengurangi risiko. Ini benar apakah desainernya atau bukan
berpengalaman. Meskipun uji kegunaan menunjukkan bahwa UI produk baik-baik saja dan

[Link] 259/315
26/2/2021 Tanpa judul
tidak ada perubahan yang diperlukan, hanya pembelajaran yang akan mengurangi risiko peluncuran
produk.
Argumen paling ringkas untuk pengujian dan desain berulang berasal
Buku Fred Brooks The Mythical Man-Month [1995], meskipun Brooks
tidak hanya mengacu pada desain UI:

Rencanakan untuk membuangnya. Bagaimanapun, kamu akan melakukannya. Satu-satunya pilihan Anda adalah apakah
untuk mencoba menjual barang sekali pakai kepada pelanggan.

Peringatan: Pernyataan Brooks tidak memberi Anda izin untuk membuat inco- yang jelek,
desain awal herent dan berharap dapat direvisi menjadi bentuk. Pengujian dan revisi

Halaman 358

344 Bab 8 Kesalahan Manajemen

tidak dapat menggantikan desain depan yang cermat. 1 Pernyataan Brooks berarti bahwa
manajer tidak boleh membodohi diri sendiri dengan percaya bahwa desainer bisa mendapatkan a
mendesain dengan tepat pada percobaan pertama.

Variasi C: "Kami tidak memiliki kemewahan dalam pengujian kegunaan"

Variasi umum dari kesalahan besar ini adalah manajer mencoba mempersingkat pengembangan-
jadwal operasi dengan melewatkan pengujian kegunaan. Beberapa mengabaikannya saat merencanakan
susunan acara; yang lain memasukkannya pada awalnya tetapi memerasnya ketika jadwalnya meleset.
Pengujian kegunaan adalah bagaimana Anda menentukan apakah desain Anda sesuai jalur dan apa
penyesuaian di tengah jalan dibutuhkan. Tanpanya, Anda terbang buta dan mungkin
sebenarnya butuh waktu lebih lama untuk menyelesaikannya. Namun banyak manajer memperlakukan pengujian kegunaan sebagai
langkah pengembangan yang dapat dibuang yang dapat dihentikan untuk memenuhi tenggat waktu yang semakin dekat.
Sikap ini didasarkan pada dua mitos:

Mitos 1. Pengujian itu mahal . Banyak pengembang menganggap pengujian kegunaan terjadi-
menelepon di fasilitas pengujian yang rumit dengan banyak peralatan video
dan ruangan pengamat di belakang cermin setengah perak membuat catatan sebagai bayaran
subjek menggunakan perangkat lunak rilis alfa untuk melakukan tugas realistis. Beberapa kegunaan
pengujian dilakukan dengan cara itu, tentunya. Namun, seseorang juga dapat berperilaku rendah
biaya, tes cepat yang dibuat dalam waktu singkat dan dilakukan dengan menggunakan kertas atau
Prototipe HTML dari perangkat lunak dan orang-orang yang direkrut dari lorong
(atau keluarga karyawan) dan dibayar dengan coklat. Tes semacam itu dapat menghasilkan hasil yang penting
informasi, seperti mana dari dua desain yang terbaik, yang dapat ditemukan oleh pengguna
perintah menu, atau apakah ikon menyampaikan arti yang diinginkan.
Mitos 2. Melewati pengujian akan menghemat uang . Dengan menghindari pengujian kegunaan, seorang pria-
ager dapat menghemat uang tetapi perusahaan tidak akan. Uang
disimpan dengan tidak melakukan siklus uji-dan-revisi sebelum pengiriman akan dilakukan
menghabiskan banyak waktu untuk revisi pasca-rilis dan peningkatan dukungan
biaya. Pendapatan yang hilang karena kurangnya pelanggan akan lebih dari meniadakan
penghematan apa pun dari melewatkan pengujian kegunaan.

DILBERT | © Scott Adams / Dist. oleh United Feature Syndicate, Inc.

1. Meskipun beberapa pendukung radikal dari pengembangan Agile / XP membantah hal ini.

Halaman 359

[Link] 260/315
26/2/2021 Tanpa judul

Sikap kontraproduktif 345

Manajer yang melewatkan pengujian menipu diri sendiri. Mereka akan melakukan kegunaan
pengujian — itu tidak bisa dihindari. Dengan tidak melakukan uji kegunaan sebelum rilis, mereka
memutuskan untuk melakukan pengujian mereka di pasar, dengan pelanggan yang membayar
sebagai subjek.
Masalah yang lebih serius dengan pengujian di pasar adalah data yang diperoleh—
keluhan pelanggan — tidak terlalu berguna. Selain terlambat, itu tidak sistem-
atic, subjektif, anekdot, samar, dipilih sendiri, dan dicampur dengan laporan bug
dan keluhan tentang fungsionalitas yang hilang. Bayangkan mencoba memutuskan bagaimana caranya
meningkatkan UI berdasarkan komentar seperti "tiga dari lima bintang" atau "MENYENANGKAN!"
atau "Perintah tidak masuk akal" atau "saya menggunakan perangkat lunak Anda hanya karena setiap
orang lain di sini melakukannya tetapi saya membencinya karena sangat berbeda dari perangkat lunak lama saya. ”
Bayangkan mendasarkan perubahan UI secara eksklusif pada komentar yang disampaikan melalui penjualan
staf.
Hanya mengandalkan umpan balik pasar juga membuat Anda rentan terhadap
Fenomena "roda melengking". Anda tidak memiliki cara untuk mengetahui apakah umpan-
punggung yang Anda terima mewakili masalah yang dialami sebagian besar pengguna, jadi
Anda akan bias untuk menangani keluhan dari pelanggan Anda yang lebih vokal
tomers. Tidak ada pengganti untuk data yang diperoleh dari eksplisit, erat
memantau pengujian kegunaan.

Variasi D: Tidak memberikan waktu untuk memperbaiki masalah kegunaan

Variasi Blooper 3 yang paling membingungkan adalah ketika manajer melakukan review
atau menguji kegunaan produk yang tertunda, tapi kemudian tidak memberikan waktu untuk memperbaiki
masalah yang diungkap ulasan atau pengujian. Beberapa manajer menyewa konsultan untuk
meninjau atau melakukan uji kegunaan, tetapi ketika mereka mendapatkan hasil dan merekomendasikan-
dations, katakan: "Kami tidak punya waktu untuk mengubah sebagian besar dari hal ini." Luar biasa!
Mengapa mereka menghabiskan semua uang itu? Inilah empat jawaban:

1. Jika manajer percaya bahwa UI hanya tentang presentasi dan desain grafis,
mereka mengharapkan tinjauan UI atau uji kegunaan hanya menemukan masalah yang dangkal.
Masalah seperti itu, seperti yang menyangkut pelabelan, tata letak, dan warna
mudah diperbaiki. Ketika tinjauan kegunaan atau pengujian mengungkap masalah yang dalam membutuhkan-
mendesain ulang konseptual, perubahan arsitektur, atau revisi back-end
layanan, banyak manajer tidak menganggap masalah seperti "antarmuka pengguna".
2. Mengembangkan produk perangkat lunak memerlukan keputusan tentang fitur yang diinginkan
akan "berhasil." Seringkali, "ujung depan yang ramah pengguna" dianggap hanya a
fitur untuk menentukan peringkat dibandingkan yang lain, seperti "kemampuan untuk mengimpor file Lotus 1-2-3"
(Blooper 64, halaman 331). Pengembang terkadang menolak kegunaan penting
perbaikan dengan alasan bahwa "tidak ada waktu", sekaligus
membuang-buang waktu menambahkan lonceng dan peluit yang menurut pengembang "keren".
Kadang-kadang tanggal rilis tergelincir terus menerus selama berbulan-bulan, namun perkembangan-
Manajer ment menolak peningkatan kegunaan karena pada titik tertentu
"Tidak ada cukup waktu."
3. Terkadang manajer, pengembang, dan bahkan desainer UI memiliki begitu banyak
ego diinvestasikan dalam desain bahwa mereka tidak dapat membayangkan ujian menemukan masalah.

Halaman 360

346 Bab 8 Kesalahan Manajemen

Ketika tes tidak menemukan masalah kegunaan, itu harus bahwa tes itu buruk
dirancang atau bahwa pengguna yang salah telah diuji.
4. Manajer mungkin telah memesan uji kegunaan hanya karena itu manda-
tory dalam proses pengembangan perusahaan. Manajer tidak terlalu
peduli apa yang ditemukan oleh tes, selama tes dapat ditandai sebagai selesai. Pemasangan
masalah kegunaan yang ditemukan oleh tes tidak ada dalam daftar periksa.

Menghindari Blooper66

Desain UI bukanlah seni mistik yang didasarkan pada bakat bawaan dan kilatan cahaya yang menyilaukan
kreativitas. Ini adalah disiplin teknik yang dipelajari. Ini memiliki banyak karakteristik yang terlihat
dalam jenis teknik lainnya:

■
Dasar ilmiah: persepsi manusia, pembelajaran, tindakan, proses informasi-
ing, dan motivasi
■
Standar industri dan praktik terbaik
■

[Link] 261/315
26/2/2021 Tanpa judul
Kebutuhan akan persyaratan yang jelas
■
Generasi dan pertimbangan alternatif desain
■
Bekerja dengan kendala dan kompromi
■
Kebutuhan untuk menguji, mengevaluasi, dan merevisi

Ada tes untuk setiap tujuan, anggaran, dan tahap pengembangan

Pengujian kegunaan bukanlah sesuatu yang Anda lakukan hanya saat perangkat lunak akan digunakan
kapal, dan tidak memerlukan fasilitas dan peralatan pengujian yang rumit. Selama
desain dan pengembangan, pertanyaan sering muncul yang dapat dijawab oleh pengujian kegunaan.
Anda dapat memilih dari berbagai metode pengujian yang bervariasi dalam biaya, persiapan
dibutuhkan, ketelitian hasil, dan titik dalam pengembangan di mana hal itu terjadi. Untuk
detail dan contoh, lihat Lampiran E (halaman 383).

Saat peserta tes sulit didapat

Bagaimana jika Anda ingin melakukan uji kegunaan, tetapi pengguna yang representatif jarang,
sibuk, atau sangat mahal? Ini adalah situasi yang sulit, tetapi tidak menutup kemungkinan
keluar pengujian kegunaan. Pertimbangkan solusi ini:

■ Beberapa aspek dari produk perangkat lunak tidak bergantung pada pengguna yang memiliki pengalaman
tise dalam tugas target perangkat lunak. Jika sistem kontrol lalu lintas udara termasuk
mouse sebagai alat penunjuk, Anda tidak perlu pengontrol lalu lintas udara untuk mengujinya
apakah tombol di layar cukup besar untuk dipukul. Jika media berbasis web
referensi kal untuk dokter menggunakan tabel yang dimaksudkan untuk berfungsi seperti tabel di
Aplikasi Windows, Anda tidak perlu dokter untuk mengujinya.

Halaman 361

Sikap kontraproduktif 347

■
Jika keahlian tugas diperlukan, Anda dapat menggunakan lebih murah, lebih mudah
merekrut pengganti untuk pengguna nyata, misalnya, perawat atau mahasiswa kedokteran
alih-alih dokter, pilot swasta, bukan pilot maskapai, manajer menengah
bukannya eksekutif puncak, staf kongres, bukan kongres
perwakilan. Pertanyaan mungkin tetap tentang bagaimana pengguna sebenarnya akan melakukan-
formulir, tetapi banyak pertanyaan desain penting akan dijawab dan penting
kekurangan akan ditemukan.
■
Jika diperlukan pengguna yang benar-benar representatif, mungkin sulit atau mahal untuk mendapatkannya
mereka, tetapi itu bukan tidak mungkin. Jika produk dipandang oleh pengguna sebagai sesuatu yang signifikan
maju untuk mereka, mungkin sangat mudah untuk meminta partisipasi mereka.
Misalnya, tim yang mengembangkan perangkat lunak untuk visualisasi dan perencanaan sebelumnya
operasi otak berhasil menguji perangkat lunak mereka pada 50 ahli bedah saraf dan
bermacam-macam ahli bedah lainnya. Ahli bedah merelakan waktu mereka karena:
(1) proyek ini disponsori oleh departemen bedah saraf sekolah kedokteran-
ment, (2) mereka melihat alat tersebut sebagai potensi kemajuan besar bagi mereka, dan (3)
beberapa rekan mereka telah membantu merancang perangkat lunak [Hinckley et al.,
1998]. Lima puluh ahli bedah saraf, gratis!

Gunakan pengujian untuk meningkatkan produk, bukan untuk menilai desainer

Ciptakan budaya di mana pengujian kegunaan dianggap sebagai alat yang sangat diperlukan
untuk meningkatkan produk dan mengurangi risiko kegagalan pasar, bukan sebagai cara untuk melakukannya
mengevaluasi kinerja perancang dan pengembang. Berdayakan anggota tim
Anda harus menggunakan tes cepat dan kotor kapan pun mereka merasa perlu. Sebelum rilis,
mengarahkan perangkat lunak ke pengujian kegunaan yang komprehensif. Bangun frasa "uji
awal dan sering ”ke dalam budaya organisasi Anda.
Pada proyek yang menggunakan metode pengembangan Agile / XP, sering digunakan
pengujian adalah wajib. Jika Anda mengembangkan perangkat lunak yang memiliki UI, kualitas-
pengujian jaminan tidak cukup; Anda harus menguji perangkat lunak pada pengguna. Jika kamu
Jangan melakukan semacam uji kegunaan di hampir setiap siklus revisi, Anda
tidak melakukan pengembangan Agile / XP.

Mengapa menguji jika Anda akan mengabaikan hasilnya?

Jika tes kegunaan memiliki nilai, manajer harus meramalkan bahwa

ers akan membutuhkan waktu setelah pengujian untuk memperbaiki masalah kegunaan.
ers. Ingatlah bahwa tes mungkin menemukan konseptual dan arsitektural yang mendalam
masalah.

[Link] 262/315
26/2/2021 Tanpa judul
Pengujian kegunaan: Lakukan saja!
Intinya: Ini benar-benar bodoh untuk mengembangkan dan mengirimkan perangkat lunak berbasis
produk tanpa melakukan beberapa jenis pengujian kegunaan sebelum rilis.

Halaman 362

348 Bab 8 Kesalahan Manajemen

Proses kontraproduktif

Kategori kedua dari blooper manajemen berfokus pada proses pengembangan

yang menghambat pengembangan perangkat lunak yang dapat digunakan dan berguna.

Blooper 67: Perkembangan anarkis

Masalah yang merajalela dalam industri perangkat lunak adalah proses pengembangan
anarkis: tidak terkendali, tidak dapat diulang, dan didorong oleh keinginan individu dan
krisis saat ini, bukan oleh praktik yang berulang dan terbukti, perusahaan
tujuan, dan kebutuhan pelanggan dan pengguna. Buku Alan Cooper The Inmates Are
Running the Asylum [1999] menjelaskan mengapa manajemen pengembangan perangkat lunak
memiliki sedikit kendali atas produk dan layanan yang dikembangkan perusahaan mereka
dan mengapa hal itu merusak kegunaan produk dan karenanya kesuksesan perusahaan.

Perkembangan anarkis → Inkonsistensi

Salah satu dampak perkembangan anarkis mudah dilihat: produk atau rangkaian produk
yang penuh dengan inkonsistensi karena setiap tim pengembang atau setiap
programmer telah melakukan sesuatu secara berbeda. Beberapa contoh mengikuti:

■
Editor dokumen mengharuskan pengguna memberi nama dokumen saat mereka membuatnya,
tetapi editor grafis dari perusahaan yang sama tidak memerlukan nama file
sampai pekerjaan itu diselamatkan.
■ Dalam satu kotak dialog, menekan tombol Tab akan memindahkan fokus input ke yang berikutnya
bidang data, tetapi di kotak dialog lain, tidak.
■
Dalam satu fungsi, objek data baru dibuat dengan mengklik tombol "Baru ..."
dan mengisi kotak dialog yang dihasilkan, tetapi di fungsi lain, mereka dibuat
ated dengan mengisi formulir yang selalu terlihat dan mengklik tautan Tambahkan tekstual.
■ Dalam program menggambar, kotak dapat diputar dan / atau diisi, tetapi segitiga
tidak bisa.
■
Satu program mempertahankan versi grafik sebelumnya dalam file cadangan, tetapi
program pendamping tidak.
■ Perintah di menu menu diberi label "Pencarian Basis Data," tetapi
perintah yang sama pada bilah alat memiliki label keterangan alat “Repositori Kueri”.

Sayangnya, ketidakkonsistenan seperti itu tidak ada habisnya. Pada beberapa produk, serupa
fungsi memiliki UI yang sangat berbeda karena programmer yang mendesainnya
tidak berbicara satu sama lain atau karena masing-masing mengira desainnya lebih baik. Beberapa
Situs Web perusahaan dirakit dari halaman-halaman yang dibuat dan dipelihara

Halaman 363

Proses kontraproduktif 349

oleh organisasi terpisah dalam sebuah perusahaan, dan setiap halaman organisasi
tampil dan bekerja secara berbeda dari yang lain. Pemrogram terkadang bahkan mendesain

[Link] 263/315
26/2/2021 Tanpa judul
satu kotak dialog
hari hanya karenadengan
merekasatu
tidakcara pada
ingat satu hari mereka
bagaimana dan yang serupa sangatsehari
melakukannya berbeda di hari berikutnya
sebelumnya dan
tidak termotivasi untuk memeriksa. Perbedaan seperti itu merupakan masalah, tetapi lebih serius.
Masalah kami adalah banyak organisasi pengembangan tidak siap untuk menemukan,
menyelesaikan, dan mencegahnya.
Pengguna ingin jatuh ke kebiasaan tidak sadar secepat mungkin (Dasar
Prinsip 6, halaman 37). Mereka ingin bisa fokus pada tujuan mereka sendiri.
UI yang konsisten memungkinkan mereka melakukan itu. Perangkat lunak yang penuh dengan incon-
sistencies memaksa pengguna untuk terus memikirkan perangkat lunak itu sendiri, mengganggu
mereka. Pengguna harus mempelajari bagaimana setiap aplikasi atau masing-masing fungsi dalam sebuah
aplikasi bekerja. UI yang tidak konsisten dan tidak koheren menghalangi pembelajaran, produktivitas,
dan, pada akhirnya, pendapatan penjualan.

Menggiring kucing

Seorang kolega berkomentar bahwa mengatur dan mengelola insinyur perangkat lunak “adalah
seperti menggiring kucing. " Meski sulit, tetap perlu mempertahankan kendali
menghasilkan UI dan produk yang koheren yang selaras dengan tujuan perusahaan. Banyak
organisasi pengembang perangkat lunak melakukan pekerjaan yang buruk dalam menggembalakan kucing mereka.

Perkembangan anarkis → Lebih sedikit pelanggan

Hasil lain dari perkembangan anarkis adalah produk dan layanan yang sangat pro-
grammerisme dan desain blooper yang ditolak pelanggan. Bahkan jika pelanggan
tomers tidak langsung menolak suatu produk, mereka mungkin hampir tidak mentolerirnya. Kapan
pelanggan menggunakan suatu produk tetapi mengutuknya setiap hari, mereka tidak memiliki loyalitas dan akan beralih
kepada pesaing tanpa ragu-ragu [Cooper, 1999].
Tiga jenis perkembangan anarkis berkontribusi pada kegunaan yang buruk.

Variasi A: Tidak ada desain

Banyak organisasi mulai mengembangkan aplikasi perangkat lunak tanpa desain pertama-
ing mereka. Programmer meretas berdasarkan sketsa belakang amplop atau tidak jelas
daftar fitur. Beberapa perusahaan merasa malu karena begini cara mereka beroperasi,
tetapi banyak yang tidak: “Kami tidak melakukan itu di sini. Di pasar kami, kami tidak punya waktu untuk
Spesifikasi UI. Kami menggunakan pengembangan Agile / XP. ” Sebagai jadwal pembangunan
mempercepat apa yang disebut "Waktu Internet", dan sebagai pengembangan Agile dan Extreme
pemrograman semakin populer, kecenderungan untuk melewatkan desain dan melompat lurus
pengkodean meningkat .
Landauer membahas konsekuensi dari ini dalam bukunya The Trouble
dengan Komputer [1995]. Cooper juga meliputnya dalam bukunya The Inmates Are

Halaman 364

350 Bab 8 Kesalahan Manajemen

Menjalankan Asylum [1999]. Peretasan terarah hampir dijamin

menghasilkan perangkat lunak yang:

■
mencerminkan pertimbangan teknis lebih dari sekadar mencerminkan persyaratan pengguna;
■
memiliki model konseptual yang tidak koheren dan tidak berfokus pada tugas yang sulit bagi pengguna
untuk mengerti;
■
sarat dengan ketidakkonsistenan UI dan kesalahan desain;
■
tidak sejalan dengan tujuan perusahaan.

Pendukung pengembangan Agile / XP mungkin memprotes bahwa metode tersebut tidak

"Perkembangan anarkis" atau "peretasan yang tidak terarah"; mereka mencapai yang diperlukan
panduan dan kontrol dengan cara selain dokumen spesifikasi. Beberapa Agile /
Pendukung XP juga berpendapat bahwa membuat desain UI terlebih dahulu dan memberi tahu pengembang
mengimplementasikannya adalah bagian dari model pengembangan perangkat lunak "air terjun" yang didiskreditkan-
ment. Desain UI, kata mereka, tidak boleh dilemparkan ke dalam batu, karena itu tidak mungkin
untuk menentukan semua persyaratan dan desain terbaik di awal. Desain
harus berkembang dengan pemahaman tim tentang persyaratan dan kemungkinan
solusi.
Memang, pengembangan Agile / XP seharusnya sangat didorong oleh pelanggan
persyaratan tomer berdasarkan review dan tes yang sering [Beck dan Andres,
2004]. Tim — termasuk pengguna dan pakar domain tugas lainnya — harus bertemu di
Setidaknya setiap minggu dalam “scrum” informal untuk mendiskusikan masalah desain dan mencari solusi
yang akan diimplementasikan dan diuji pada siklus berikutnya.
Dalam prakteknya, bagaimanapun, banyak organisasi pembangunan yang mengaku menggunakan
Metode Agile / XP tidak melakukan banyak hal yang diperlukan metode: tidak ada domain

[Link] 264/315
26/2/2021 Tanpa judul
ahli di tim atau terdekat untuk memberikan umpan balik, tidak ada scrum mingguan, tidak
tes cepat dan kotor. Mereka hanya menghindari spesifikasi UI dan menyebutnya sebagai pengembangan "Agile / XP"
ment. Dalam kasus seperti itu, label "Agile / XP" hanyalah penutup untuk anarkis, tidak terarah
peretasan.
Bahkan jika pengembang mengikuti praktik yang disarankan Agile / XP dengan cermat, lewati-
ping desain depan masih beresiko. Ini mengasumsikan bahwa melalui pengujian dan revisi,
UI cepat dan kotor yang ditoleransi (atau tidak) pengguna akan berkembang menjadi koheren,
berfokus pada tugas, mudah dipelajari yang disukai pengguna. Asumsi itu sangat luar biasa
optimis. Lebih sering daripada tidak, hasilnya adalah UI yang membuat pengguna meringis,
daripada tersenyum.
Memulai tanpa desain juga seringkali menghabiskan waktu daripada menghematnya, seperti
UI ad hoc dan arsitektur perangkat lunak dibuat, ternyata tidak memadai, robek
terpisah, dan dibangun kembali berkali-kali. Ini malah menghasilkan banyak keributan tanpa tujuan
daripada gerakan yang disengaja menuju tujuan.

Variasi B: Tidak ada standar atau pedoman

Banyak perusahaan perangkat lunak tidak memiliki standar untuk pengoperasian perangkat lunak atau
Lihat dan rasakan. Mereka tampaknya tidak mengerti bahwa mereka sedang dipublikasikan-

Halaman 365

Proses kontraproduktif 351

bisnis, seperti perusahaan yang membuat majalah, koran, buku, TV

program, dan film.
Penerbit dan penyiar tradisional memiliki standar yang ketat tentang bagaimana informasi
mation disajikan (misalnya, diagram batang vs diagram lingkaran), bagaimana kata-kata dieja (misalnya,
“Khadafy” vs. “Gadhafi”), tipografi apa yang digunakan (mis., Times vs. Bookman),
bagaimana teks diformat, apakah artikel dimulai dengan ringkasan, arah mana
Orang tion di foto wajah, dan sebagainya. Penerbit dan penyiar yang
jangan mengikuti standar dan pedoman menghasilkan UI yang tampak amatir,
bahkan untuk pengguna yang tidak dapat menjelaskan dengan tepat apa yang salah, atau yang sulit untuk dilakukan
memahami.
Pengembang perangkat lunak, sebagai penerbit, harus memiliki standar dan panduan-
garis yang sesuai untuk produk dan pelanggan mereka, tetapi hanya sedikit yang melakukannya.
Pengembang sering menganggapnya sebagai tindakan anal-kompulsif yang berlebihan untuk dikhawatirkan
inkonsistensi dalam detail seperti kata-kata pada perintah dan pesan,
kapitalisasi label pengaturan, jarak kontrol, dan sejenisnya.
Manajemen tidak mempersoalkan masalah karena itu akan menambah waktu untuk
jadwal, belum lagi pekerjaan itu harus ditugaskan ke
programmer sendiri karena tidak ada orang lain yang berwenang untuk mengubah file
Kode sumber.
Beberapa manajer berasumsi bahwa standar platform target mereka -
Windows, Mac, Java, Web — sudah cukup. Tidak begitu. Standar untuk itu
platform tidak cukup dibatasi. Aplikasi dapat menyesuaikan dengan
Macintosh UI standar dan masih penuh dengan blooper desain. Dua produk perangkat lunak
Produk keduanya dapat sesuai dengan Windows namun terlihat dan terasa sangat berbeda
pengguna akan kesulitan beralih di antara mereka.

Variasi C: Tidak ada pengawasan

Sungguh menakjubkan betapa umum bagi perusahaan untuk mempekerjakan programmer untuk berkembang
aplikasi interaktif, beri mereka sedikit panduan, dan berharap yang terbaik.
Seorang manajer perangkat lunak mencirikan praktik ini sebagai:

“Pekerjakan kutu buku, katakan apa yang Anda inginkan, kunci di kantor mereka, dan lempar pizza
dan T-shirt setiap beberapa minggu. ”

Asumsi yang mendasari filosofi ini sebagian didasarkan pada ink-

Ide yang benar bahwa programmer GUI adalah desainer GUI (Blooper 65, halaman 337).
Juga berkontribusi adalah sikap keliru bahwa GUI adalah prioritas rendah dan bisa
ditugaskan ke programmer junior yang lebih murah (Blooper 64, halaman 331).
Penulisan teks yang ditampilkan oleh perangkat lunak seringkali tidak diawasi dengan baik.
Pemrogram sering menulis label perintah, label tombol, nama pengaturan,
dan pesan kesalahan yang ditampilkan kode mereka, meskipun mereka tidak dilatih
untuk melakukannya. Ketika manajemen gagal meminta penulis dan editor teknis meninjau
teks perangkat lunak, perangkat lunak sering masuk ke pasar dengan terminologi yang tidak konsisten,

[Link] 265/315
26/2/2021 Tanpa judul

Halaman 366

352 Bab 8 Kesalahan Manajemen

jargon programmer, pesan kesalahan yang tidak jelas, kesalahan ejaan, tata bahasa
kesalahan, dan umumnya tulisan yang buruk (lihat Bab 4).
Kurangnya pengawasan dapat disebabkan oleh manajemen yang lemah serta kesalahan
konsepsi tentang apa programmer dan tidak pandai. Banyak laki-laki-
Umur dalam organisasi pengembangan perangkat lunak memiliki manajemen orang yang lemah
keterampilan. Gabungkan manajer yang lemah dengan pemrogram yang tidak memiliki pelatihan desain UI
dan yang tidak bekerja sama atau berkomunikasi dengan baik satu sama lain, dan Anda mendapatkannya
perkembangan anarkis. Berikut skenario tipikal:

Desain dan pengkodean dibagi di antara beberapa pemrogram berdasarkan program

berfungsi, berdasarkan minat dan keterampilan mereka. Para programmer baik dis
setuju tentang bagaimana perangkat lunak harus menyajikan kontrol dan informasi atau tidak
membicarakannya satu sama lain. Setiap programmer mendesain UI secara berbeda di
bagian dari perangkat lunak yang menjadi tanggung jawabnya. Manajer mereka atau
pemimpin tim menyadari inkonsistensi desain dan ingin
memperbaiki mereka, tetapi tidak dapat meyakinkan pemrogram untuk berunding dan mencapai kesepakatan-
dan terlalu lemah atau ragu-ragu untuk memaksakan keputusannya sendiri pada
tim.

Dalam situasi seperti ini, beberapa manajer memiliki agenda tersembunyi saat mereka
bawa konsultan UI. Konsultan UI seharusnya dipekerjakan untuk menemukan kegunaan
masalah dan merekomendasikan solusi, tetapi sering kali menemukan bahwa mereka sebenarnya
sekutu yang dipekerjakan untuk memecahkan masalah manajemen: manajer membutuhkan orang luar
"Otoritas" untuk merekomendasikan apa yang sudah diketahui manajer kepada pemrogram
harus dilakukan.
Manajer mungkin percaya bahwa pemrogram hanya membuat keputusan teknis,
Namun nyatanya programmer sering membuat keputusan yang sangat mempengaruhi bisnis
hasil, seperti:

■
siapa pelanggan produk itu nantinya dan seberapa besar mereka akan menghargai
produk;
■
fungsi perangkat lunak mana yang akan banyak digunakan dan mana yang akan digunakan
jarang digunakan mereka mungkin juga tidak ada;
■
seperti apa reputasi perusahaan sebagai pengembang perangkat lunak nantinya;
■
seberapa cepat pendapatan perusahaan dari produk akan meningkat, kapan akan
melebihi biaya, kapan akan mencapai puncaknya, dan berapa lama akan bertahan;
■
seperti apa permintaan layanan dukungan pelanggan nantinya.

Sayangnya, biasanya tidak sampai produk telah dikirim ke beta-

pelanggan — atau bahkan kemudian — bahwa semua konsekuensi bisnis dari
keputusan pemrogram menjadi jelas.

Halaman 367

Proses kontraproduktif 353

Contoh programmer membuat keputusan bisnis secara default

Sebuah perusahaan membutuhkan bantuan untuk mendesain ulang GUI dari produk manajemen jaringan.
Manajer produk menjelaskan bahwa produk tersebut sedang dalam pengembangan
selama lebih dari setahun tanpa desainer UI di tim (Blooper 68, halaman 357) dan — sur-
hadiah! —pelanggan prospektif menyebut produk tidak dapat digunakan. Memeriksa saya
pemahaman, saya menggunakan metafora produk mereka sebagai kamera:

Saya: “Jika saya mengerti dengan benar, pelanggan Anda menginginkan point-and-shoot otomatis
kamera, tetapi programmer Anda membuat kamera profesional yang dikontrol secara manual. "

[Link] 266/315
26/2/2021 Tanpa judul
Manajer: “Tidak; itu lebih buruk dari itu. Mereka membuat perlengkapan untuk membuat kamera. Anda bisa membangun
kamera apa pun yang Anda inginkan dengannya. Tetapi pelanggan kami tidak ingin membuat kamera. Mereka
menginginkan kamera. "

Para programmer mengembangkan perangkat lunak yang mereka inginkan jika mereka memiliki
tugas mengelola jaringan. Tetapi orang lain memiliki pekerjaan itu, dan perangkat lunak mereka
inginkan bukanlah apa yang dirancang oleh programmer.
Dengan mengembangkan produk yang tidak bisa dijual langsung ke custom-
ers, tetapi harus dijual melalui integrator sistem pihak ketiga dan
nilai tambah reseller, programmer membuat keputusan bisnis yang penting
perusahaan — keputusan yang tidak diinginkan manajemen. Manajemen di
perusahaan ini memungkinkan pengembangan untuk berlanjut selama lebih dari setahun ketika apa yang pro-
yang dikembangkan oleh para grammers adalah ketidakcocokan besar dengan apa yang diinginkan pelanggan.
Apakah tidak ada yang memperhatikan?

Menghindari Blooper 67

Aplikasi yang memiliki GUI — atau antarmuka pengguna yang signifikan — harus
dirancang sesuai dengan prinsip desain yang berpusat pada pengguna (UCD) dan terbaik
praktek.
Sebelum Anda mulai menulis kode, Anda harus memiliki desain UI awal
bekerja dari. Jika Anda dengan hati-hati merancang apa yang akan Anda buat sebelum Anda
mulailah membangunnya, gedung tersebut akan berjalan lebih cepat dan Anda kemungkinan besar akan membangun
produk yang disukai pelanggan [Cooper, 1999]. Apakah desainnya direkam
dalam dokumen teks, storyboard, atau prototipe terserah Anda, tetapi seharusnya begitu
direkam di suatu tempat selain di benak orang. Desainnya tidak diragukan lagi-
edly berubah, dan seperti itu, catatan itu harus diperbarui. Tanpa
sebuah desain, Anda mencari masalah, baik selama pengembangan maupun setelahnya
melepaskan.

Halaman 368

354 Bab 8 Kesalahan Manajemen

UCD dan Agile / XP kompatibel

Desain yang berpusat pada pengguna, seperti pengembangan Agile / XP, sangat menghargai:

■
memahami kebutuhan pelanggan dan pengguna,
■
meminta bantuan pengguna dan pakar domain tugas lainnya,
■
merancang model konseptual yang berfokus pada tugas (disebut "model objek" di Agile / XP),
■
pengujian yang sering,
■
desain berulang.

Juga seperti pengembangan Agile / XP, desain yang berpusat pada pengguna menolak air terjun
model. Ini mengakui bahwa persyaratan pelanggan dipahami lebih baik
waktu dan berubah bahkan setelah mereka dipahami. UCD mengakui itu
desain berkembang, tetapi menyarankan untuk tidak mulai membuat kode sampai Anda selesai
analisis tugas, membuat kasus penggunaan dan profil pengguna, merancang fokus tugas
model konseptual, dan membuat desain UI awal (lihat Bab 1). Itu
tujuannya bukan untuk mengukir hal-hal ini di atas batu. Justru sebaliknya, itu adalah membiarkan Anda
mengujinya pada pengguna sehingga Anda dapat merevisi dan meningkatkannya sebelum menginvestasikan waktu,
uang, dan ego pada kode. Setelah implementasi dimulai, pengujian dan revisi
lanjutkan, dan desain berkembang. Tidak ada konflik yang melekat antara pengguna-
desain terpusat dan pengembangan Agile / XP. 2
Metode Agile dan XP pada awalnya dikembangkan oleh rekayasa perangkat lunak
ahli, bukan ahli desain UI, jadi tulisan awal tentang Agile / XP memiliki titik buta
tentang UI, kegunaan, desain yang berpusat pada pengguna, dan bagaimana mereka cocok dengan metode
ods. Menurut Bankston [2001]:

XP cenderung mempromosikan fokus yang sangat ketat; jangan khawatir tentang apa yang akan datang, cukup
kode kartu yang Anda pegang. … Sayangnya,… pendekatan ini bisa mengarah ke
antarmuka yang terputus-putus, canggung atau rumit yang tidak perlu dirancang di sekitar
fungsionalitas back-end daripada tujuan akhir pengguna. Merancang yang efisien
dan antarmuka pengguna yang elegan memerlukan beberapa konsep tentang langkah-langkah yang terdiri dari a
tugas yang diberikan, dan bagaimana tugas saling terkait untuk membuat aliran aplikasi.

[Link] 267/315
26/2/2021 Tanpa judul
Baru-baru ini, pakar UI dan pakar Agile / XP telah mencoba "mengawinkan" mereka
metode. Sebagian besar mengakui kebutuhan akan beberapa desain depan:

■
Scott Ambler, ahli Agile / XP, mengatakan bahwa keseluruhan arsitektur file
aplikasi harus dimodelkan dalam "fase 0" sebelum kode normal – tes–
merevisi siklus mulai [2005].
■
Larry Constantine, seorang konsultan UI, mengatakan “beberapa desain awal minimum adalah
diperlukan agar UI dapat tertata dengan baik dan menghadirkan pengguna dengan konsisten

2. Ada orang fanatik di kedua kubu yang mengklaim bahwa UCD dan Agile / XP tidak kompatibel.

Halaman 369

Proses kontraproduktif 355

Gambar 8.4
Lahirnya Pengguna Analisis Tugas;
Mulailah
Tahap Profil Kasus Penggunaan Penting

Elaborasi Ruang Lingkup & Partisi

Konseptual Level tinggi
Tahap Pengembangan;
Model UI papan cerita
Buat Panduan Gaya

Tes kegunaan kertas

Siklus 1 Siklus n
Konstruksi
Tahap
(Agile Dev.) Akhir

UI terperinci
Rancangan

Desain yang berpusat pada pengguna dengan pengembangan Agile [diadaptasi dari Meads, 2007].

dan antarmuka yang mudah dipahami. ” Dengan Carolyn Lockwood, dia mengembangkan file
metodologi desain "berpusat pada penggunaan" yang efisien yang mereka klaim cocok
ke dalam proses Agile / XP [2002].
■ Jon Meads, konsultan UI, menemukan bahwa UCD cocok dengan metode Agile jika
pekerjaan desain (dan iterasi) terjadi terutama di Inception dan Elaboration
fase proyek, sedangkan siklus Agile code-test-merevisi terjadi di
Fase konstruksi (Gambar 8.4).
■
Lynn Miller menyajikan studi kasus penggunaan UCD pada proyek yang menggunakan Agile /
Metode XP dan menyimpulkan bahwa pengembangan Agile / XP menekankan pada
input pengguna porating meningkatkan UCD [2005].

Upaya ini menunjukkan bahwa Agile / XP dan UCD dapat digabungkan untuk mendapatkan file
manfaat dari keduanya, selama praktisi Agile / XP mengakui bahwa beberapa di muka
desain diperlukan untuk memastikan koherensi dan konsistensi, dan praktisi UCD
mengakui bahwa desain UI akan berkembang.

Pengembang adalah penerbit, dan harus bertindak seperti itu

Anda berada dalam bisnis penerbitan dan media — biasakanlah. Seperti semua orang lain di
bisnis itu, Anda memerlukan standar desain, konvensi, pedoman, dan yang di atas
semua, proses pengembangan yang menghasilkan gaya interaksi yang konsisten, tata letak,
pemformatan, jenis huruf, terminologi, gaya penulisan, penggunaan warna, dan sebagainya. Mengembangkan
perangkat lunak yang mudah digunakan, Anda memerlukan pedoman desain yang melampaui batas minimal
persyaratan kesesuaian untuk platform GUI Anda.
Melihat diri Anda sebagai penerbit juga membantu memperjelas perbedaan antara “itu
berfungsi "dan" siap dikirim ". Kesenjangan antara kedua negara tersebut mungkin seperti

Halaman 370

[Link] 268/315
26/2/2021 Tanpa judul

356 Bab 8 Kesalahan Manajemen

sebesar jarak antara "inilah ide" dan "berhasil." Bayangkan jika The New
York Times atau National Geographic dikirim ke pelanggan segera setelah semua
wartawan menyerahkan cerita dan foto mereka. Misalkan potongan kasar pertama
dari Alfred Hitchcock "The Birds" atau "Lord of the Rings" karya Peter Jackson
telah dirilis. Perangkat lunak adalah produk media, dan pengembang perlu menyadari hal itu
itu bermanfaat untuk "memusingkan detail", seperti halnya dengan film, acara TV, surat kabar-
pers, dan majalah.

UI yang berkualitas membutuhkan investasi

Perusahaan pengembang perangkat lunak harus berinvestasi dalam:

■
melatih programmer tentang prinsip-prinsip desain yang berpusat pada pengguna;
■ mempekerjakan perancang interaksi / UI dan penguji kegunaan;
■
menyediakan programmer dengan GUI dan buku pedoman Web untuk referensi mereka
ence, terutama panduan gaya platform standar industri seperti Windows,
Mac, Java, AJAX, dan Flash;
■ mengembangkan panduan dan standar gaya UI departemen atau perusahaan;
■
memastikan bahwa panduan dan standar gaya perusahaan dan industri diikuti;
■ menggunakan toolkit dan template GUI yang mendukung standar UI;
■
termasuk desain UI dan revisi jadwal pengembangan;
■ memiliki arsitek proyek yang bertanggung jawab untuk memastikan konsistensi antara
berbagai bagian perangkat lunak;
■
meletakkan semua teks yang ditampilkan oleh perangkat lunak dalam file pesan;
■ meminta penulis teknis dan editor meninjau semua pesan teks dan label
digunakan dalam perangkat lunak;
■
melakukan uji kegunaan;
■ merevisi desain berdasarkan hasil uji kegunaan.

Lapisan standar GUI

Standar UI memiliki banyak lapisan, dengan lapisan dalam memiliki cakupan yang semakin sempit
(Gambar 8.5). Ada standar industri yang luas. Ada platform khusus
salah satunya, misalnya untuk Windows, Macintosh, dan Java. Beberapa perusahaan mengembangkan perusahaan
standar porate sehingga produk mereka memiliki tampilan khas merek
dan rasakan. Selain itu, produk dalam lini produk tertentu mungkin terlihat dan berfungsi lebih baik
sama dengan produk perusahaan pada umumnya. Akhirnya, standar bisa
dikembangkan untuk produk tertentu, untuk menumbuhkan konsistensi antara yang berbeda
bagian darinya. Lapisan dalam menambah, bukannya bertentangan, lapisan luar.

Halaman 371

Proses kontraproduktif 357

Gambar 8.5
Industri
Standar

Peron
Standar

Perusahaan
Standar

Produk-line
Standar

Produk
Standar

[Link] 269/315
26/2/2021 Tanpa judul

Beberapa lapisan standar desain GUI diterapkan secara bersamaan ke suatu produk.

Memberi pengaruh lebih banyak kepada pakar UI

Memberi desainer UI dan insinyur uji kegunaan lebih banyak otoritas untuk menyatakan kegunaan
itu masalah untuk menjadi tukang pamer. Cara termudah untuk mencapai ini adalah dengan lebih
Desainer UI untuk menjadi manajer. Pakar UI juga bisa mendapatkan pengaruh dengan melayani
sebagai penasihat manajer, membantu mereka memperkirakan implikasi bisnis UI
keputusan dan kekurangan desain.
Setelah tim pengembangan memutuskan desain UI, programmer
harus menerapkan desain itu. Ketika programmer tidak menyukai sesuatu di file
desain, mereka harus melobi untuk mengubah desain daripada pengkodean secara sepihak
GUI apapun yang mereka inginkan.

Mengambil tanggung jawab

Akhirnya, manajemen dapat membantu mengatasi perkembangan anarkis hanya dengan

menjadi lebih tegas. Siapa, bagaimanapun, pada akhirnya bertanggung jawab atas kesuksesan
produk?

Blooper 68: Tidak ada keahlian tugas dalam tim

Banyak manajer di industri perangkat lunak tidak memahami desain itu

UI yang efektif untuk produk perangkat lunak membutuhkan pemahaman yang mendetail tentang

Halaman 372

358 Bab 8 Kesalahan Manajemen

pekerjaan yang dilakukan pengguna yang dituju dan lingkungan kerja tempat
perangkat lunak akan digunakan. Mereka percaya pengenalan singkat tentang perangkat lunak itu
tugas target adalah semua kebutuhan perancang atau pemrogram untuk membuat setelan-
UI yang mampu. Oleh karena itu, tim pengembang sering kali tidak menyertakan orang yang benar-benar
memahami tugas, dan banyak tim tidak berusaha untuk mendapatkannya
pemahaman.

Pengembang berasumsi bahwa mereka adalah pakar domain tugas

Salah satu alasannya adalah sejarah. Produk berbasis komputer dulunya

dimaksudkan dan dirancang hanya untuk pengguna yang terlatih secara teknis: ilmuwan, insinyur,
dan programmer lainnya [Grudin, 1991; Norman, 1998]. Pengembang dirancang
untuk orang-orang seperti diri mereka sendiri. Bahkan ketika pengguna yang dituju bukanlah perangkat lunak
insinyur, desain semacam berhasil karena pengguna cerdas secara teknis
cukup untuk dapat beradaptasi dengan desain teknosentris.
Perangkat lunak saat ini yang ditujukan untuk ahli teknologi hanyalah sebagian kecil dari perangkat lunak
pasar ware. Produk dan layanan perangkat lunak sudah umum. Internet
adalah konsep rumah tangga. Pengguna sekarang adalah pekerja di setiap jenis bisnis
dan konsumen di rumah di seluruh dunia — bahkan di negara berkembang.
Asumsi bahwa pengembang perangkat lunak dapat merancang produk yang dapat digunakan tanpa
perlu mengimpor keahlian domain tugas sekarang benar-benar tidak valid, meskipun itu
pernah valid.
Bahkan dengan perangkat lunak yang dikembangkan untuk audiens non teknis, pengembang
mungkin berasumsi bahwa mereka mengetahui lebih banyak tentang domain tugas daripada yang sebenarnya mereka ketahui.
Mereka menyeimbangkan rekening bank mereka setiap bulan, jadi mereka pikir mereka mengerti
akuntansi. Mereka adalah siswa baru-baru ini, jadi mereka pikir mereka tahu apa yang diajarkan-
ers butuhkan. Mereka pernah ke klinik, jadi mereka yakin bisa merancang perangkat lunak untuk
perawat. Terlalu melebih-lebihkan pengetahuan bukanlah masalah; itu hanya sifat manusia;
tetapi ketika manajer membeli penilaian diri yang terlalu tinggi dari pengembang, mereka setuju
melakukan kesalahan besar.

[Link] 270/315
26/2/2021 Tanpa judul

© 1996 Greg Howard, didistribusikan oleh King Features Syndicate.

Halaman 373

Proses kontraproduktif 359

Mendiskon pengetahuan tugas pengguna

Alasan kedua untuk kurangnya keahlian domain tugas pada tim pengembangan
adalah kurangnya perhatian terhadap pengetahuan tugas. Pengembang tahu tentang teknologi,
dan teknologi adalah apa yang mereka kembangkan. Jadi apa lagi yang perlu diketahui?
Pengetahuan tentang domain tugas didiskon: pengguna tidak tahu tentang technol-
ogy, jadi mereka tidak tahu apa-apa.
Orang dapat melihat sikap ini dalam label yang sering digunakan oleh pengembang perangkat lunak
berbicara tentang pengguna yang dirancang untuk perangkat lunak tersebut. Keahlian adalah
skala linier, mulai dari pengguna "pemula" atau "naif", yang tidak tahu banyak
tentang komputer, hingga pengguna "ahli", yang seperti insinyur penuh
para pengembang. Skala tersebut didasarkan pada pengetahuan tentang teknologi komputer.
Keahlian dalam domain tugas tidak berperan dalam memposisikan seseorang di
skala.
Tiga jenis pengetahuan mempengaruhi efektivitas seseorang dalam menggunakan suatu perangkat lunak
produk: pengetahuan tentang domain tugas target produk, pengetahuan tentang
produk perangkat lunak tertentu, dan pengetahuan tentang teknologi komputer secara umum
(Prinsip Dasar 1, halaman 8). Seseorang bisa rendah, sedang, atau tinggi pada setiap tipe,
mandiri.
Demikian pula, jenis keahlian yang berbeda juga dibutuhkan untuk mendesain yang dapat digunakan
dan produk yang bermanfaat. Pengembang perangkat lunak biasanya hanya memiliki keahlian teknis.
Mereka biasanya tidak ahli dalam domain tugas target perangkat lunak, sehingga membatasi
kemampuan untuk menghasilkan produk yang sukses untuknya.

Aplikasi kompleks yang dikembangkan tanpa UI atau keahlian tugas

Beberapa perusahaan mengembangkan aplikasi yang sangat terspesialisasi atau sangat kompleks.
Merancang UI yang efektif untuk sistem kendali lalu lintas udara, perawatan intensif rumah sakit
sistem pemantauan, atau sistem perdagangan saham membutuhkan lebih banyak pengetahuan domain tugas
edge daripada mendesain kalender desktop atau pembaca email. Inilah tiga
aplikasi kompleks yang awalnya dikembangkan perusahaan tanpa UI atau tugas-
ahli domain.
■ Perdagangan ekuitas. Workstation untuk pialang saham profesional, pedagang saham, dan
staf pendukung mereka. Pengembang telah menerima umpan balik dari saat ini dan
calon pelanggan bahwa perangkat lunak itu terlalu rumit dan "luar biasa
didesain dengan teurishly. " Mereka awalnya ingin saya menyederhanakan antarmuka pengguna
secara radikal, dalam beberapa bulan. Kami segera menetapkan tujuan yang lebih rendah untuk membawa-
memasukkan jendela aplikasi dan kotak dialog ke dalam kesesuaian dengan desain
pedoman. Hanya setelah delapan bulan bekerja dengan mereka, saya merasa kompeten
untuk menyarankan perbaikan yang lebih dalam.
■
Melacak kasus kanker. Banyak negara bagian AS melacak kasus kanker masuk
untuk menemukan kelompok yang signifikan dan untuk menyediakan peneliti kanker

Halaman 374

360 Bab 8 Kesalahan Manajemen

data epidemiologi. Perusahaan perangkat lunak yang menyediakan pelacakan kanker

perangkat lunak ke negara bagian mempekerjakan saya untuk membantu meningkatkan kegunaan perangkat lunaknya.

[Link] 271/315
26/2/2021 Tanpa judul
Tugas tersebut dimulai sebagai "tinjauan UI cepat", tetapi segera berkembang menjadi panjang
proyek desain ulang. Untuk mendapatkan beberapa pengetahuan tentang domain tugas, kami lakukan
sebuah studi observasi dan wawancara pengguna, yang tahu banyak tentang
kanker, pengobatannya, dan bagaimana itu dilacak, meskipun "klerikal" dengan no
pelatihan medis formal.
■
Eksperimen biomolekuler. Sebuah perusahaan instrumen biologi mempekerjakan saya untuk menjadi lebih baik
kegunaan perangkat lunak untuk mengendalikan instrumen uji protein yang kompleks. Mereka
awalnya ingin saya meninjau perangkat lunak mereka dengan cepat dan membuat sketsa desain baru untuk
layarnya. Namun, masalah utamanya adalah perangkat lunak tersebut dirancang
istilah tentang bagaimana instrumen bekerja secara internal (misalnya, memasukkan jarum ekstraksi ke dalam
sampel sumur, aliran sampel dari sumur 1 di atas lokasi uji A2), daripada apa biolo-
inti yang ingin dicapai dengannya (misalnya, membandingkan reaksi protein A, B, dan
C menjadi enzim X). Mendesain ulang perangkat lunak agar sesuai dengan kebutuhan ahli biologi a
banyak pengetahuan domain, dikumpulkan dengan meminta masukan dari ahli biologi dan
bahkan memasukkannya ke dalam rapat desain mingguan kami.

Mengimpor keahlian tugas itu sulit

Alasan ketiga kurangnya pengetahuan tugas pada tim pengembangan adalah itu
mengimpornya, baik dengan membawa pengguna ke tim atau dengan mengirim pengembang
belajar dari mereka, tidaklah mudah. Grudin [1991] membuat daftar hambatan yang bahkan
organisasi yang bermaksud baik menghadapi:

■
Terkadang tidak sepenuhnya jelas siapa yang akan menjadi pengguna produk. Itu
Pengangkut pribadi Segway seharusnya untuk semua orang, tetapi yang utama
digunakan pada tahun 2007 adalah pengiriman surat.
■ Mendapatkan umpan balik atau saran yang berguna dari ahli tugas sebelum seseorang memilikinya
produk untuk ditampilkan tidak langsung; itu membutuhkan usaha bersama dan
kreativitas. Seringkali pada saat suatu produk "dapat dipamerkan", sudah terlambat untuk disarankan
gerakan dari pengguna agar berdampak besar pada desain.
■
Memasukkan masukan dari pakar tugas membutuhkan banyak revisi dalam
rancangan. Itu membutuhkan kerja sama dari seluruh tim karena itu mempengaruhi
implementasi, dokumentasi, jadwal, dan anggaran. Mendapatkan dukungan
dari seluruh tim, termasuk manajemen, itu sulit.
■ Realitas bisnis terkadang menghalangi upaya pengembang untuk mencari masukan
calon pengguna produk perangkat lunak. Hambatan keterlibatan pengguna bisa
dapat ditemukan baik di organisasi pengembangan perangkat lunak maupun di pelanggan
organisasi.

Seringkali mereka yang mendesain UI produk akan menerima masukan dari domain tugas
ahli, tetapi sulit mendapatkannya. Pakar domain tugas mungkin

Halaman 375

Proses kontraproduktif 361

menjadi sangat sibuk dan / atau sangat mahal (Blooper 66, halaman 341). Mungkin
pengembang tidak diizinkan untuk menghubungi pengguna potensial untuk organisasi atau
alasan hukum. Perusahaan perangkat lunak jarang didirikan untuk memfasilitasi kontak langsung
antara pengembang dan pengguna. Banyak yang membatasi atau melarangnya.
Bertahun-tahun lalu, beberapa perusahaan bermitra untuk mengembangkan layanan video online
untuk sekolah. Rencananya adalah memungkinkan guru di distrik sekolah tertentu untuk menemukannya
dan tunjukkan video pendidikan online. Guru tidak lagi harus memesan
kaset dan DVD sebelumnya dari perpustakaan video distrik atau khawatir tentang
apakah yang mereka butuhkan untuk kelas mereka sudah diperiksa.
Kami adalah subkontraktor dalam proyek tersebut. Peran kami adalah merancang UI untuk menemukan-
ing dan menampilkan video. Kontraktor utama tidak ingin “membingungkan sekolah
distrik dengan menghadirkan perwakilan dari berbagai perusahaan ”dan
jadi melarang kami menghubungi distrik sekolah atau gurunya.
Kami merasa bahwa tidak mungkin merancang UI tanpa mengetahui cara mengajar-
ers memilih, memesan, dan menggunakan video. Kami menghindari larangan tersebut, menghubungi a
distrik sekolah yang berbeda dan melakukan wawancara dan kelompok fokus dengan
para gurunya. Kami bertanya kepada guru bagaimana mereka memilih dan memesan video
kelas mereka, bagaimana mereka menunjukkannya, dan apa yang mereka suka dan tidak suka
tentang prosesnya. Kami juga menjelaskan kemungkinan kemampuan dan desain untuk
sistem video online dan meminta komentar para guru. Ini beberapa
dari temuan kami:

■
Guru mengategorikan video menurut "unit", "subjek", dan "pelajaran" pendidikan,
bukan berdasarkan topik / hierarki subtopik sederhana.
■ Guru sering kali memilih video berdasarkan apa yang ada di dalamnya. Video tentang hiu

[Link] 272/315
26/2/2021 Tanpa judul
mungkin termasuk klip perahu nelayan dan mungkin digunakan dalam pelajaran tentang
perahu.
■
Guru menunjukkan video untuk mendukung apa yang mereka ajarkan dan sebagai enter-
tainment untuk hari hujan atau hadiah. Video untuk pelajaran sudah direncanakan
jauh sebelumnya. Video untuk hiburan dipilih secara mendadak
saat.
■ Guru mempratinjau video sebelum menunjukkannya di kelas. Kaset dan DVD
izinkan guru membawa pulang video untuk dipratinjau. Layanan online yang tidak
biarkan itu tidak populer.
■
Guru mengedit video agar sesuai dengan rentang perhatian dan presentasi kelas mereka
segmen yang relevan. Mereka juga menghentikan video untuk membahasnya. Sebuah layanan itu
tidak memungkinkan itu akan diabaikan.
■ Guru berbagi informasi tentang video. "Penggemar video" berfungsi sebagai sumber daya
untuk kolega mereka, menawarkan banyak koleksi dan pengetahuan pribadi tentang
video dan peralatan.
■
Banyak guru telah menyerah menggunakan perpustakaan video distrik dan sebaliknya
menggunakan koleksi mereka sendiri. Layanan online akan bersaing dengan mereka sebagai
serta dengan perpustakaan kabupaten.

Halaman 376

362 Bab 8 Kesalahan Manajemen

Tanpa akses ke pakar domain tugas — dalam hal ini, guru — kami akan melakukannya
harus mendesain UI kami "dalam gelap".
Keterlibatan pengguna dalam pembangunan juga dapat terhalang oleh c ustomer
organisasi [Grudin, 1991]. Manajer di perusahaan pelanggan mungkin akan menolak
di mengalihkan personel dari pekerjaan normal mereka untuk membantu pengembangan perangkat lunak-
usaha. Sebagian besar perlu mendengar bagaimana mereka akan mendapatkan keuntungan sebelum persetujuan-
ing. Ini terutama benar ketika perangkat lunak akan dijual secara terbuka
pasar:

“Anda ingin saya meminjamkan kepada Anda salah satu karyawan saya dua hari seminggu selama enam bulan
untuk membantu Anda mengembangkan perangkat lunak yang nantinya akan Anda jual tidak hanya kepada kami tetapi juga kepada kami
pesaing kita? Saya… tidak… berpikir… jadi! ”

Apakah penghalang yang memisahkan pengembang dan pengguna ada di organisasi Anda.
atau pelanggan, gagal mengatasinya mengurangi peluang Anda
produk dapat digunakan dan begitu juga blooper.

Menghindari Blooper68

Ingat kembali induk dari semua prinsip desain UI: fokus pada pengguna dan tugas mereka,
bukan pada teknologi (Prinsip Dasar 1, halaman 8). (Jika Anda belum membacanya
prinsipnya, sekarang akan menjadi saat yang tepat.)
Berfokus pada pengguna dan tugas mereka berarti menjadikannya sebagai prioritas utama
memahami dan memenuhi persyaratan pengguna. Memahami persyaratan pengguna
termasuk memahami domain tugas target perangkat lunak, yang, pada gilirannya,
mengharuskan tim memiliki sumber pengetahuan domain tugas.
Pengetahuan itu bisa didapat dengan menggunakan desainer yang memahami
aktivitas yang didukung atau dengan melibatkan calon pengguna dalam desain sebagai penasihat,
peserta tes, dan penandatangan kode.
Mari kita uraikan sedikit.

Keahlian domain tugas pengguna adalah unsur penting

Pengembang — manajer serta pemrogram — akan menghasilkan perangkat lunak lunak yang lebih baik
aman jika mereka merevisi sikap mereka tentang domain tugas vs. keahlian teknis.
Pengguna tidak cuek; mereka ahli dalam bidang tugas. Pengembang dari
tentu saja memainkan peran penting dalam pengembangan perangkat lunak sebagai penulis kode,
tetapi harus mengakui ketidaktahuan mereka tentang sebagian besar domain tugas, dan manusia-komputer
ter interaksi, dan bekerja untuk mengatasi ketidaktahuan mereka dengan belajar dari
para ahli atau mengatasinya dengan mengundang para ahli untuk bergabung dengan mereka dalam tim
atau keduanya. Ini sangat penting untuk merancang produk perangkat lunak yang sukses dan
layanan di pasar yang sangat kompetitif saat ini.

[Link] 273/315
26/2/2021 Tanpa judul

Halaman 377

Proses kontraproduktif 363

Sebelum mendesain apa pun, bicarakan dengan pengguna. Lakukan dalam wawancara empat mata,
di mana komentar setiap peserta tidak dipengaruhi oleh komentar dari
orang lain. Lakukan juga dalam kelompok fokus, di mana peserta memiliki ide, pemikiran, dan
reaksi bertentangan dan saling melengkapi. Cari tahu bagaimana mereka yang
mungkin akhirnya menggunakan produk yang direncanakan melakukan pekerjaan mereka sekarang, apa yang mereka suka
dan tidak menyukainya, dan bagaimana mereka bisa membayangkannya menjadi lebih baik.
Di awal proses desain, kirim anggota tim untuk membenamkan diri
di domain tugas: mengamati pengguna, bergaul dengan mereka, dan, jika memungkinkan,
benar-benar melakukan beberapa pekerjaan mereka. Setidaknya, desainer UI tim harus
terpapar dengan baik pada pekerjaan yang dilakukan pengguna.
Bahkan lebih baik — tetapi lebih sulit untuk diatur — membawa pengguna ke dalam tim desain.
Peringatan: Tidaklah mudah mendapatkan pengguna untuk berkontribusi secara efektif setelah Anda memilikinya
beberapa waktu mereka. Hanya membiarkan mereka duduk dalam rapat proyek dengan program-
mers dan manajer tidak akan bekerja. Kebanyakan akan ragu untuk berkontribusi karena
mereka merasa tidak pada tempatnya. Bahkan jika mereka mengumpulkan keberanian untuk berbicara, mereka tidak melakukannya
berpikir atau berbicara seperti pengembang, jadi mungkin ada miskomunikasi, ketidakpercayaan,
dan bahkan kurang hormat. Di sisi lain, memperlakukan pengguna sebagai kelas dua
anggota tim juga tidak akan bekerja. Harus dijelaskan kepada mereka bahwa mereka memang benar
dibutuhkan karena keahlian domain tugas mereka , yang tidak dimiliki oleh pengembang.
Sesi terstruktur — dipimpin oleh fasilitator yang juga berfungsi sebagai penerjemah — adalah
yg dibutuhkan. Sesi dapat berfokus pada:

■
menganalisis tempat kerja saat ini, menghasilkan rincian tugas pengguna
tampil dan masalah yang mereka miliki saat ini;
■
mengembangkan model konseptual dan leksikon, yaitu, apa konsepnya
domain tugas dan apa namanya;
■
mengembangkan skenario orang yang menggunakan produk yang direncanakan, diungkapkan di a
tingkat konseptual tinggi (disebut "cerita pengguna" dalam pengembangan Agile / XP);
■
menyaring analisis tugas dan skenario untuk menghasilkan yang paling penting
kasus penggunaan;
■
membayangkan kemungkinan desain untuk produk, menghasilkan sketsa awal;
■
menunjukkan kepada pengguna desain atau prototipe dan meminta umpan balik dan saran-
tions;
■
memberlakukan peran di tempat kerja simulasi, menggunakan prototipe awal.

Pengembangan Agile / XP membutuhkan partisipasi pakar domain tugas—

pengguna — dalam scrum proyek mingguan. Peran mereka adalah untuk memastikan semuanya kritis
persyaratan tercakup dan untuk menjaga desain tetap fokus pada tugas. Tim
yang mengikuti metode Agile / XP dapat menggunakan salah satu cara terstruktur yang tercantum di atas
untuk memastikan bahwa pengguna menyumbangkan keahliannya. Tim menggunakan pengembangan tradisional
Metode ment juga dapat menggunakan jenis rapat terstruktur ini untuk mendapatkan pengguna
berpartisipasi secara efektif.

Halaman 378

364 Bab 8 Kesalahan Manajemen

Berikut adalah panduan yang bagus tentang cara mendapatkan dan melibatkan pengguna dengan sukses:

■
Greenbaum dan Kyng, Desain di Tempat Kerja: Desain Koperasi Komputer
Sistem [1991]
■
Schuler dan Namioka, Desain Partisipatif: Prinsip dan Praktik [1993]
■
Holtzblatt et al., Desain Kontekstual Cepat: Panduan Cara untuk Teknik Utama
untuk Desain yang Berpusat pada Pengguna [2004]

Kebanyakan buku tentang pengembangan Agile / XP juga harus memberikan saran tentang cara mendapatkannya

[Link] 274/315
26/2/2021 Tanpa judul
pengguna untuk menyumbangkan keahlian domain tugas mereka secara efektif. Populer saat ini-
ity dari metode Agile / XP telah menciptakan banyak sekali pilihan seperti itu
buku.

Atasi hambatan organisasi hingga keterlibatan pengguna

Jika Anda menemui kendala dalam mencoba mempertemukan pengembang dengan pengguna,
gunakan keterampilan manajemen Anda untuk mengatasi atau menghindarinya. Jika beberapa pelanggan
tomers tidak akan berpartisipasi, temukan orang yang mau. Jika pengelola pengguna adalah
kendala, tingkatkan permintaan ke manajemen yang lebih tinggi di organisasi itu.
Jika Anda benar-benar tidak bisa mendapatkan akses ke pengguna nyata, temukan pengganti yang berbagi karakter
acteristics dengan pengguna Anda. Jika semuanya gagal, tugaskan seseorang di tim Anda untuk
menjadi pengguna.

Gunakan desainer khusus untuk aplikasi yang kompleks dan khusus

Perusahaan yang mengembangkan aplikasi yang kompleks dan sangat terspesialisasi harus memiliki
seorang desainer UI berdedikasi pada staf sebagai karyawan penuh waktu. Setelah satu tahun di
pekerjaan, desainer mungkin benar-benar tahu sesuatu tentang target perusahaan
domain tugas. Jika tim pengembangan terus mendatangkan desainer baru dari
di luar, baik secara terus menerus harus membayar biaya untuk mengajari mereka
domain tugas atau terus memiliki produk yang dirancang oleh orang-orang yang tidak
memahami apa yang mereka rancang.

Pekerjakan ahli ganda jika Anda dapat menemukannya

Terkadang dimungkinkan untuk mempekerjakan insinyur perangkat lunak yang juga ahli di dalamnya
domain tugas target. Misalnya, industri perangkat lunak musik mempekerjakan pro-
ahli tata bahasa yang juga musisi. Pendekatan ini memiliki keterbatasan karena
Keterampilan pemrograman ditambah keterampilan domain tugas tidak sama dengan keterampilan desain UI, tetapi itu
lebih baik daripada tidak memiliki keahlian domain tugas dalam tim. Terkadang bisa
bekerja dengan sangat baik. Misalnya, perusahaan yang mengembangkan peralatan medis-
staf dan perangkat lunak memiliki staf seorang insinyur yang juga seorang dokter medis.
Produk yang dikembangkan timnya sangat sukses. Tentu saja, orang dengan
keahlian ganda sangat sulit ditemukan.

Halaman 379

Proses kontraproduktif 365

Blooper 69: Menggunakan alat dan blok bangunan yang buruk

Sulit untuk membangun produk berkualitas tinggi dengan menggunakan alat yang berkualitas buruk atau jelek
bahan. Ini berlaku untuk perangkat lunak maupun untuk furnitur, rumah, dan tembikar.
Ini terutama berlaku untuk GUI.
Alat untuk merancang dan membangun GUI untuk perangkat lunak interaktif termasuk
Toolkit GUI, pembuat GUI interaktif, editor halaman web, pustaka grafik,
bahasa kueri, bahasa skrip, dan bahasa spesifikasi deklaratif.
Anda ingin memilih alat terbaik dan paling tepat untuk pengembangan Anda
usaha. Banyak kriteria yang harus dipertimbangkan saat mengevaluasi alat GUI. Satu
yang terpenting adalah kegunaan GUI yang dapat dibangun.
Masalahnya, mereka yang memilih alat GUI organisasi biasanya kekurangan
keterampilan yang dibutuhkan untuk mengevaluasi faktor itu. Baik manajer pengembangan, yang
biasanya memutuskan alat GUI mana yang akan dibeli, atau pemrogram GUI, yang membuat GUI
dan menasihati manajer tentang alat apa yang harus dibeli, adalah pakar desain GUI. Itu
kriteria yang mereka gunakan untuk memilih alat GUI biasanya tidak mencakup kegunaan
GUI yang dapat dibangun. Sebaliknya, manajer dan pengembang fokus pada ini
kriteria:

1. Betapa mudahnya alat ini dipelajari oleh pemrogram

2. Seberapa cepat pemrogram dapat mengembangkan GUI menggunakan alat tersebut
3. Seberapa mudah GUI yang dihasilkan dirawat
4. Seberapa cocok alat tersebut dengan proses pengembangan organisasi
5. Seberapa kompatibel alat tersebut dengan alat pengembangan lain yang digunakan tim
6. Apakah alat tersebut berjalan pada sistem operasi yang digunakan pengembang
7. Seberapa kompatibel GUI yang dihasilkan dengan perangkat lunak back-end dan yang sudah ada
komponen
8. Apakah alat tersebut sudah dimiliki oleh perusahaan
9. Apakah alat tersebut sebelumnya telah digunakan di perusahaan oleh ini atau lainnya
organisasi

[Link] 275/315
26/2/2021 Tanpa judul
10. Berapa banyak kode atau memori komputer yang dibutuhkan GUI yang dihasilkan
11. Apakah programmer menggunakan alat tersebut pada pekerjaan sebelumnya
12. Berapa harga alat tersebut
13. Apakah pembuat perkakas membebankan royalti atas produk yang dibuat dengan perkakas tersebut
14. Apakah alat tersebut sedang dalam mode atau dianggap "keren" di perangkat lunak
industri

Kecuali untuk No. 14, ini adalah kriteria penting. Kriteria 1–5 adalah tentang kegunaan,
tetapi alat itu sendiri dan bukan GUI yang dihasilkannya. Masalahnya adalah
karena manajer dan pemrogram biasanya memutuskan dan memberi nasihat tentang GUI
alat, kriteria 1–14 mendapatkan lebih banyak bobot daripada kriteria yang terkait dengan kegunaan
GUI yang dapat dibangun menggunakan alat, seperti berikut ini:

Halaman 380

366 Bab 8 Kesalahan Manajemen

15. Bagaimana GUI yang dikembangkan dengan alat ini sesuai dengan standar untuk
platform aplikasi target, seperti Windows, Macintosh, Java, dan Web
16. Bagaimana GUI yang dikembangkan dengan alat ini sesuai dengan desain GUI umum
standar
17. Apakah alat memandu pemrogram menuju GUI yang sesuai dengan desain
pedoman dan hindari blooper
18. Apakah alat tersebut menyediakan semua kontrol GUI yang diperlukan untuk file
aplikasi atau memungkinkan pemrogram untuk membuatnya dengan mudah
19. Apakah alat tersebut memungkinkan detail tampilan disetel dengan baik agar sesuai
tampilan dan nuansa perusahaan atau suite aplikasi yang diinginkan
20. Apakah alat menyediakan komunikasi antara kontrol GUI dan
komponen semantik atau back-end yang cukup kaya untuk didapatkan pengguna
umpan balik yang akurat dan tepat waktu untuk tindakan mereka
21. Apakah GUI yang dikembangkan menggunakan alat tersebut cukup responsif (lihat
Bab 7)
22. Betapa mudahnya GUI yang dikembangkan dengan alat ini untuk menginternasionalkan dan
melokalisir
23. Bagaimana GUI yang dikembangkan dengan alat ini dapat diakses oleh berbagai jenis pengguna,
seperti orang yang lebih memilih keyboard daripada mouse atau orang tua atau cacat
(mis., gangguan penglihatan, pendengaran, atau motorik)

Beberapa manajer dan pemrogram memiliki latar belakang untuk mengevaluasi alat
berdasarkan kriteria 15–23. Namun, kegunaan, dan karenanya yang dirasakan
kualitas, produk yang dihasilkan bergantung paling tidak pada kriteria ini
seperti pada kriteria 1–14.
Pengembang, termasuk manajer, lebih fokus pada pengembangan mereka sendiri
biaya dan manfaat daripada biaya dan manfaat yang dihasilkan produk yang dihasilkan
menghasilkan untuk orang lain [Grudin, 1991]. "Lainnya" termasuk orang-orang yang menjual dan mendukung
port produk (baik di perusahaan pengembang maupun di luarnya) dan mereka
siapa yang menggunakannya. Masa pakai produk (mudah-mudahan) berkali-kali lipat lebih lama daripada pengembangannya.
waktu operasi, dan jumlah penjualan dan dukungan produk orang dan pengguna jauh
melebihi jumlah pengembang. Oleh karena itu, fokuslah pada biaya pengembangan
dan manfaat ketika memilih alat pengembangan adalah salah menilai kriteria.
Para ahli yang berada dalam posisi untuk mengevaluasi alat berdasarkan yang kedua
serangkaian kriteria adalah desainer UI dan penguji kegunaan. Namun, mereka jarang
terlibat dalam memilih alat konstruksi GUI. Ini terutama benar dalam
panies yang tidak memiliki profesional UI internal dan malah membawa eksternal
konsultan saat mereka membutuhkan UI yang dirancang, ditinjau, atau diuji. Alatnya adalah
dipilih jauh sebelum konsultan dipekerjakan.
Hasilnya adalah banyak rekomendasi desain yang dibuat oleh para desainer UI dan
penguji kegunaan ditolak oleh pengembang karena “alat pengembangan tidak akan melakukannya
mari kita lakukan itu "atau karena" itu akan terlalu sulit untuk dilakukan di platform ini. "
Berikut adalah kasus di mana kegunaan terhambat oleh pembangunan
alat.

Halaman 381

[Link] 276/315
26/2/2021 Tanpa judul

Proses kontraproduktif 367

Contoh 1: Menu yang melanggar memori otot pengguna

Sebuah perusahaan telah mengembangkan perangkat lunak yang banyak menggunakan menu tarik-turun.
Pengguna harus dapat mengoperasikan menu tersebut dengan salah satu dari dua metode:

1. Tempatkan penunjuk di atas menu, tekan tombol mouse ke bawah untuk menampilkan semua pilihan,
seret penunjuk ke pilihan yang diinginkan (yaitu, pindahkan penunjuk sambil menahan tombol
bawah), lepaskan tombol mouse.
2. Tempatkan penunjuk di atas menu, klik (yaitu, tekan dan lepaskan tombol mouse) ke
menampilkan semua pilihan, pindahkan penunjuk ke nilai baru yang diinginkan, klik untuk memilih nilai
dan tutup menu.

Menu opsi dalam perangkat lunak ini hanya bekerja dengan metode 2. Pengembang
bisa berbuat sedikit tentang masalah ini, karena menu dropdown disediakan
oleh perangkat GUI yang dipilih manajer mereka tidak mengizinkan metode 1 dari
operasi. Anehnya, menu menu, dari toolkit GUI yang sama, berfungsi
dua arah.
Operasi menu adalah tindakan memori otot: orang tidak memikirkannya sekali
mereka telah mempelajarinya. Beberapa orang menggunakan metode 1; yang lain menggunakan metode 2. Menu itu
bekerja hanya dengan satu cara melanggar memori otot pengguna yang mempelajari cara lain
cara. Oleh karena itu, ada cacat kegunaan yang serius dalam perangkat GUI tim
telah memilih. Pimpinan proyek menolak untuk meminta vendor toolkit untuk memperbaiki masalah
karena mereka terlalu sibuk dan kekurangan saluran pendukung, dan mereka tidak berpikir
itu penting karena ada cara lain untuk mengoperasikan menu.
Produk tidak bertahan lama di pasar.

Contoh 2: Kontrol tidak responsif

Seorang klien sedang mengembangkan aplikasi menggunakan kontrol GUI yang sangat ekstrim
lambat dalam menanggapi tindakan pengguna. Perlu beberapa detik untuk tombol
mengakui diklik, scrollbar tidak akan menanggapi gerakan mouse-
ments sampai setelah konten jendela yang digulir digulir, ukuran jendela
dan tindakan -pindah membutuhkan waktu hingga satu menit untuk diterapkan, dan seterusnya. Ini adalah
masalah serius karena ini adalah tugas koordinasi tangan-mata yang membutuhkan
umpan balik visual yang ketat (lihat Bab 7). Alasan pengembang adalah karena GUI
toolkit yang mereka gunakan lambat dan akan tetap demikian hingga rilis berikutnya.
Sayangnya, mereka harus merilis produk mereka berdasarkan toolkit saat ini
rilis, menjamin reputasi lambat.

Contoh 3: Umpan balik navigasi yang tidak memadai

Uji kegunaan menunjukkan bahwa pengguna tersesat dalam aplikasi online

Dokumentasi bantuan. Salah satu alasannya adalah bahwa hubungan antar topik tidak
menunjukkan apakah pengguna telah mengunjungi bagian yang ditautkan. Beberapa tes
peserta menyarankan bahwa tautan harus berubah warna setelah sebelumnya

Halaman 382

368 Bab 8 Kesalahan Manajemen

diikuti. Saran ini diberikan kepada pengembang, tetapi mereka mengatakan bahwa
toolkit yang digunakan untuk membuat dokumentasi Bantuan tidak mendukungnya.
Kelemahan kegunaan yang disebabkan oleh pilihan alat GUI dapat bertambah. Jika menggunakan par-
alat khusus menghasilkan GUI yang memiliki terlalu banyak masalah, proyek diharapkan
manajer untuk mempertimbangkan kembali keputusan mereka untuk menggunakannya. Itu hampir tidak pernah terjadi.

Menghindari Blooper69

Sulit untuk memberikan nasihat yang baik tentang bagaimana menghindari kesalahan besar ini karena banyak sekali
Alat pengembangan GUI dan toolkit sangat buruk. Bagian ini menjelaskan bagaimana caranya
mengevaluasi dan memilih alat dan kontrol yang akan digunakan untuk mengembangkan GUI.

Masalah dengan komponen GUI

[Link] 277/315
26/2/2021 Tanpa judul
Masalah yang umum terjadi pada sebagian besar alat pengembangan GUI adalah mereka memaksa pengembang
untuk memulai dengan memutuskan bagaimana tampilan GUI , bukan bagaimana fungsinya di file
aplikasi. Misalnya, pengembang harus memutuskan di muka bagaimana suatu pilihan akan
disajikan: sebagai menu atau satu set tombol radio. Ini karena kebanyakan GUI
alat mengklasifikasikan kontrol berdasarkan penampilannya (misalnya, menu, bidang teks, tombol radio,
kotak centang). Pengembang juga biasanya harus mengkhawatirkan masalah tata letak sejak awal
pengembangan, karena sebagian besar alat GUI mengharuskan setiap kontrol secara eksplisit
diposisikan. Hal ini mengarah pada mengutak-atik widget dan lay-
keluar, mengalihkan pemrogram dan desainer dari pekerjaan desain yang lebih penting:
memutuskan pengguna aplikasi apa yang perlu mengatur dan mengontrolnya
menyelesaikan pekerjaan mereka.
Toolkit GUI dapat dirancang sehingga pemrogram memilih kontrol berdasarkan
fungsi (misalnya, pilihan satu-dari- N , pengaturan ON / OFF, angka dalam jangkauan) daripada
penampilan mereka. Dalam toolkit seperti itu, menu dropdown dan satu set tombol radio ada
bukan dua jenis kontrol yang berbeda, melainkan jenis yang sama (pilihan satu-dari- N )
disajikan dalam dua cara berbeda [Johnson, 1992].

Kriteria terpenting untuk memilih alat GUI:

Seberapa berguna GUI yang dihasilkan?

Saat mengevaluasi dan membandingkan alat, berikan bobot yang signifikan pada kriteria
15–23 di atas. Pelanggan Anda tidak peduli bagaimana Anda membangun produk Anda atau apa
bagian-bagian itu dibuat; mereka hanya peduli pada produk secara keseluruhan. Apakah itu bagus
cukup untuk mereka, atau bukan? Jika kegunaan produk Anda buruk karena
Alat GUI yang Anda gunakan, yang kalah bukanlah pengembang alat; lagipula, kamu sudah
membeli produk mereka. Mereka menang. Yang kalah adalah kamu.

Halaman 383

Proses kontraproduktif 369

DILBERT | © Scott Adams / Dist. oleh United Feature Syndicate, Inc.

Saat mengembangkan aplikasi, tetapkan kriteria ketanggapan untuk masing-masing aplikasi

fungsi. Bagian dari aplikasi yang tidak memenuhi tujuan daya tanggap mereka
harus dianggap tukang pamer, apakah masalahnya ada pada Anda sendiri
perangkat lunak tim atau dalam kendali GUI yang Anda gunakan. Jangan katakan, "Masalah itu-
masalah ada di kontrol GUI, bukan di perangkat lunak kami, jadi kami tidak dapat memperbaikinya. ” Kamu bisa
perbaiki: minta peningkatan dari pengembang kontrol GUI, dapatkan perbedaan
kontrol, atau buat sendiri. Jika Anda mengirim dengan kontrol GUI yang tidak responsif, itu benar
penjualan Anda yang akan menderita, bukan dari vendor kontrol.
Orang-orang dengan kualifikasi terbaik untuk menilai seberapa baik alat atau perangkat GUI tertentu
memenuhi kriteria 15–23 adalah desainer UI Anda (Anda memiliki beberapa di antaranya, bukan?),
jadi pastikan mereka terlibat dalam pengambilan keputusan. Kriteria 1–13 harus dipertimbangkan
oleh manajemen dan pemrogram. Kriteria 14 harus diabaikan begitu saja.
Jika desainer UI tidak dapat mencoba alat secara langsung (misalnya, karena alatnya adil
perpustakaan kontrol), pemrogram harus menerapkan beberapa GUI
menggunakan alat dan kemudian biarkan orang UI mengevaluasi hasilnya. Saat berbelanja
untuk alat GUI yang akan digunakan tim Anda untuk membangun aplikasinya, coba terapkan
bagian penting dari GUI menggunakan berbagai alat kandidat. Ini tentu saja membutuhkan
waktu, tapi sekali lagi, memilih alat pengembangan GUI adalah keputusan besar karena
setelah programmer Anda mempelajari suatu alat, Anda memiliki investasi yang signifikan di dalamnya dan
jadi tidak mungkin untuk segera mengubah alat. Oleh karena itu, pilih pengembangan GUI Anda
alat dengan sangat hati-hati.

Alat tidak dapat mendesain perangkat lunak; hanya desainer yang bisa melakukan itu

Beberapa manajer di industri perangkat lunak percaya bahwa menggunakan GUI interaktif
alat pengembangan memungkinkan karyawan yang kurang terampil untuk merancang kualitas profesional

[Link] 278/315
26/2/2021 Tanpa judul
GUI. Itu hanya hype pemasaran, angan-angan, atau keduanya.
GUI interaktif dan alat pengembangan Web hanya memungkinkan orang yang kurang terampil
untuk membuat UI, yang sebagian besar memiliki kualitas amatir. Mengetahui cara menggunakan
alat tidak menyiratkan mengetahui apa yang harus dilakukan dengan mereka. Memungkinkan pengembang untuk
membangun GUI dengan menyeret kontrol alih-alih pemrograman tidak memastikan itu

Halaman 384

370 Bab 8 Kesalahan Manajemen

GUI yang dihasilkan akan bagus. Alatnya terlalu tidak dibatasi. Juga, sebagai Cooper
[1999] menunjukkan, fakta bahwa GUI dibangun tidak berarti telah dibangun
dirancang .
Alat konstruksi GUI drag-and-drop tidak dan tidak akan pernah menjadi
solusi untuk masalah perangkat lunak yang sulit digunakan. Memang, itu lebih mungkin
yang akan meningkatkan penggunaan GUI interaktif dan perangkat lunak pengembangan Web
menyebabkan penurunan kualitas aplikasi secara keseluruhan, karena lebih banyak
orang yang tidak tahu apa yang mereka lakukan mengembangkan perangkat lunak. jika kamu mau
perangkat lunak yang sukses memastikan bahwa orang yang merancangnya tahu apa yang mereka lakukan
sedang melakukan.

Blooper 70: Memberi programmer komputer tercepat

Ini mungkin blooper paling kontroversial dalam buku ini. Meskipun demikian, file
praktik umum dalam memberikan pengembang komputer tercepat dan kecepatan tertinggi
Koneksi internet adalah salah satu penyebab penting dari blooper responsif
dijelaskan dalam Bab 7.

Justifikasi

Manajemen sering mengeluarkan biaya yang cukup besar untuk memberi insinyur perangkat lunak
komputer terbaru, tercepat, dan koneksi tercepat yang tersedia ke Internet. Ini
dilakukan karena beberapa alasan:

■
Insinyur menyukai kecepatan. Mereka suka memiliki komputer tercepat yang tersedia. Mereka
seperti dapat mengunduh file dari Web secara instan.
■
Komputer cepat dan koneksi jaringan memaksimalkan produktivitas programmer
ity, terutama ketika pengembangan melibatkan banyak kompilasi atau berbasis skrip
membangun atau menguji versi baru.
■
Perusahaan komputer ingin memiliki karyawan programmer sendiri yang menggunakan
perangkat keras terbaru mereka sebagai salah satu cara mengatasi kekurangan.
■
Perusahaan komputer suka membangun perangkat lunak untuk model terbaru mereka karena
itu mendorong pelanggan untuk meningkatkan.

Biaya

Satu biaya untuk selalu memberi programmer komputer dan jaringan tercepat
koneksi adalah bahwa sistem mereka akan lebih cepat daripada kebanyakan pelanggan.
Adopsi pelanggan atas teknologi baru biasanya mengikuti distribusi kurva lonceng.
tion (Gambar 8.6): beberapa pengambil risiko segera mengambil risiko, kemudian mengadopsi
teknologi baru oleh pelanggan lama dan baru mempercepat, kemudian pasar
jenuh dan kurva penjualan mulai turun, dan akhirnya beberapa penangguhan terakhir
gigit peluru dan mengejar semua orang. Bagian penting dari bel
kurva adalah bagian tengah; di situlah sebagian besar pelanggan berada.

Halaman 385

Proses kontraproduktif 371

Gambar 8.6

[Link] 279/315
26/2/2021 Tanpa judul

Unit terjual per bulan

Produk seumur hidup

Adopsi pasar model komputer baru dari waktu ke waktu.

Biaya lain untuk memberi programmer perangkat keras dan koneksi internet terbaru
adalah mereka menjadi terbiasa dengan peningkatan yang sering dan melihat kinerja
dan masalah daya tanggap hanya bersifat sementara, "hingga peningkatan versi berikutnya".
Pelanggan tidak meningkatkan sesering mungkin karena komputer dan Internet
koneksi membebani mereka dengan uang sungguhan. Mereka harus menunggu untuk meningkatkan sampai mereka
akuntan telah mengamortisasi biaya pembelian terakhir ke level tersebut
di mana peningkatan dapat dibenarkan. Sebaliknya, mengupgrade
komputer biaya mereka apa-apa. Karena itu, mereka cenderung tidak simpatik
keluhan pelanggan tentang kinerja dan / atau daya tanggap: “Tingkatkan saja
komputer dan perangkat lunak Anda akan cukup cepat. ”

Koneksi internet: Massa berada jauh di belakang elit teknologi

Kecepatan koneksi internet adalah area lain di mana masyarakat umum tertinggal
di belakang elit teknologi. Survei dilakukan pada akhir 2006 dan awal 2007
menemukan bahwa antara seperlima dan dua perlima pengguna Internet rumahan di Amerika Serikat
Negara bagian masih menggunakan koneksi dial-up 56 kbaud atau kurang:

■ Urusan Konsumen ([Link]), September 2006: 44% dial-up

■
Pew Internet & American Life Project ([Link]), Desember
2006: 29% dial-up
■ Pengoptimalan Situs Web ([Link]), Februari 2007:
21% dial-up

Demikian pula, sebuah studi internasional yang diterbitkan pada tahun 2005 menemukan bahwa sekitar sepertiganya
dari semua pengguna Internet (termasuk pengguna bisnis) masih memiliki koneksi dial-up. 3
Selanjutnya, analisis tren yang diterbitkan di Horrigan [2005] menyarankan
Gest yang penyerapan akses Internet broadband di rumah-rumah AS, yang lambat

3. Siaran Pers Ipsos News Center, Maret 2005 ([Link]/news/[Link]?id=2583).

Halaman 386

372 Bab 8 Kesalahan Manajemen

sampai sekitar tahun 2000 tetapi meningkat tajam sampai pertengahan 2005, mulai melambat lagi di akhir-akhir ini
2005 dan awal 2006. Rupanya, kejenuhan pasar mulai terjadi, seperti
mereka yang menginginkan atau membutuhkan broadband mendapatkannya, dan mereka yang menggunakan Internet
terutama untuk e-mail tetap puas dengan dial-up.
Bahkan yang disebut koneksi Internet "kecepatan tinggi" yang dimiliki kebanyakan orang
di rumah dan bisnis kecil mereka — terutama DSL dan kabel — kom-
dikupas ke T3, fiber-optic OC3, dan koneksi Internet super cepat lainnya
biasanya ditemukan di perusahaan pengembangan teknologi.
Sebagian besar pelanggan perusahaan komputer atau perangkat lunak tidak akan memiliki
komputer paling kuat atau koneksi Internet tercepat selama berbulan-bulan atau
tahun. Pada saat itu, banyak pengembang perangkat lunak sudah meningkatkan ke
model baru berikutnya dan koneksi internet. Hasilnya, perangkat lunak dapat diterima
responsif pada komputer pemrogram akan sering tidak begitu pada komputer pelanggan.

Menghindari Blooper70

Jangan terlalu cepat memutakhirkan komputer pemrogram

Tidak diragukan lagi, programmer memerlukan akses ke mesin cepat untuk kompilasi
dan membangun perangkat lunak. Tetapi kompilasi dan pembangunan dapat dilakukan di server. Itu
komputer tempat pengembang menjalankan dan menguji perangkat lunak yang mereka kembangkan seharusnya
menjadi seperti yang digunakan sebagian besar pelanggan. Jika tidak, programmer akan melakukannya
memproduksi perangkat lunak yang menurut pelanggan akan lamban dan tidak responsif. Bekas

[Link] 280/315
26/2/2021 Tanpa judul
Desainer antarmuka[1997],
Desain Antarmuka pengguna
dia Apple Peter Bickford membagikan pendapat saya. Dalam bukunya
menulis:

“Ada sebuah aliran pemikiran yang mengatakan bahwa programmer harus dipaksa
bekerja pada sistem yang paling tidak kuat di pasar sasaran mereka, daripada sistem
mengakhiri workstation yang cenderung mereka gunakan. Meskipun ini sepertinya agak kejam dan tidak biasa
hukuman bagi saya, saya telah melihat programmer ... menulis ulang rutinitas untuk bekerja 20 kali
lebih cepat ketika mereka dipaksa untuk menjalankan aplikasi mereka di departemen secre-
mesin tary. "

Uji di komputer yang lebih lambat

Tim teknik setidaknya harus memiliki mesin yang lebih lambat untuk diuji. Selanjutnya,
pengujian pada komputer seperti yang dimiliki pelanggan harus diwajibkan, dengan tegas
kriteria untuk memutuskan apakah perangkat lunak cukup responsif untuk dirilis.

Ujilah dengan koneksi internet yang lambat

Meskipun saya tidak menganjurkan memaksa pengembang perangkat lunak — terutama Web
pengembang — untuk menggunakan koneksi Internet yang lambat, saya menganjurkan agar mereka melakukannya
uji aplikasi Web dan situs Web menggunakan kecepatan koneksi yang biasa
pelanggan mereka. Itu tentu saja membutuhkan mencari tahu jaringan seperti apa
koneksi yang dimiliki pelanggan.

Halaman 387

Lampiran

Lampiran A: Daftar Istilah

Bagi pembaca yang baru mengenal desain UI, berikut adalah istilah yang umum digunakan di UI
bidang.

■
Aplikasi, aplikasi perangkat lunak: perangkat lunak yang dirancang untuk membantu kinerja pengguna
tugas, memecahkan masalah, atau mencapai tujuan. Perangkat lunak aplikasi kontras
dengan perangkat lunak sistem, yang mengontrol operasi internal komputer
ter. Perangkat lunak aplikasi adalah perangkat lunak yang paling banyak ditemui pengguna komputer
langsung. Istilah ini berasal dari gagasan bahwa perangkat lunak diterapkan pada suatu tugas atau
serangkaian tugas.
■ Back end: layanan perangkat lunak yang digunakan oleh aplikasi untuk menyediakan konten dan
logika tugas-domain . Back end menyimpan dan mengambil data, melakukan com- besar
putations, komunikasi rute, dll. Perangkat lunak back-end sering berjalan
komputer yang disebut server.
■
Model konseptual: deskripsi tingkat tinggi tentang bagaimana aplikasi adalah organ-
ized dan beroperasi. Ini menentukan konsep yang diekspos oleh aplikasi
pengguna dan bagaimana mereka diatur. Tujuan dari model konseptual adalah untuk
memberikan dasar bagi pengguna untuk memahami bagaimana aplikasi bekerja secara berurutan
untuk menggunakannya secara efektif.
■ Objek konseptual: hal-hal dalam domain tugas yang dimanipulasi orang.
Ketika orang berbicara tentang domain tugas, objek konseptualnya adalah kata benda.
(Kata kerja adalah tindakan yang dilakukan orang pada objek.) Contoh
objek dalam domain tugas penyelenggaraan foto digital adalah album foto,
peragaan slide, foto, keterangan.
■
Kontrol: elemen atau komponen antarmuka pengguna grafis yang
Pengguna komputer berinteraksi dengan memasukkan data ke perangkat lunak, atau komponen itu
menyajikan data dari perangkat lunak untuk pengguna. Contoh kontrol adalah dialog
kotak, kotak centang, bidang teks, penggeser. Juga disebut widget .
■ Kotak dialog: jenis jendela perangkat lunak yang terbuka sementara untuk menampilkan a
pesan, biarkan pengguna menyetel opsi pada perintah yang tertunda, atau biarkan pengguna menyetel
properti objek. Kotak dialog biasanya memiliki tombol "OK" dan "Batal"
selain kontrol dan bidang data apa pun yang mereka butuhkan.

373

[Link] 281/315
26/2/2021 Tanpa judul

Halaman 388

374 Lampiran

■
Tampilan inersia: prinsip desain UI yang menyatakan bahwa ketika pengguna mengedit beberapa-
hal di layar, efek perubahan harus dijaga agar tetap lokal
sible, sehingga sebagian besar tampilan tetap seperti itu. Ketika prinsip ini dilanggar,
pengguna bingung dengan terlalu banyak gerakan.
■
Kelompok fokus: pertemuan yang diadakan oleh organisasi pengembangan produk
untuk menunjukkan kepada pelanggan atau pengguna produk, prototipe, atau ide desain baru untuk didapatkan
tanggapan mereka. Peserta bereaksi dalam kelompok, demikian tanggapan dari orang yang berbeda
tidak independen, melainkan dibangun berdasarkan umpan balik dari peserta lain.
■
GUI toolkit: sekumpulan kontrol (komponen) dari mana aplikasi dibuat.
terstruktur. Biasanya kontrol dalam toolkit GUI mewujudkan tampilan tertentu dan
merasa, tetapi beberapa toolkit GUI dapat diubah untuk menampilkan tampilan yang berbeda.
Contoh dari toolkit GUI adalah Java Swing dan Windows ActiveX.
■
Evaluasi heuristik: metode meninjau kegunaan perangkat lunak untuk
temukan masalah potensial. Peninjau mempelajari perangkat lunak secara sistematis
dengan daftar pedoman desain UI di tangan, mencatat tempat di mana perangkat lunak
UI ware melanggar pedoman.
■
Sistem interaktif: perangkat atau perangkat lunak komputer apa pun yang dapat dioperasikan orang.
makan dan itu dapat merespons dengan cara yang rumit. Palu tidak akan dipanggil
sistem interaktif, tetapi telepon genggam, dan mesin cuci
mungkin, tergantung seberapa rumitnya.
■
Berpikir dari dalam ke luar vs berpikir dari dalam ke dalam: berpikir dari dalam ke luar adalah (salah)
dengan asumsi bahwa pengguna aplikasi tahu apa yang diketahui desainer dan karenanya-
kedepan dapat menafsirkan apa yang mereka lihat di UI seperti yang diinginkan oleh desainer. Berpikir
outside-in (dengan benar) mengasumsikan bahwa pengguna tidak tahu apa desainer
tahu, jadi UI harus dirancang agar dapat ditafsirkan dengan jelas.
■
Metafora: mendesain UI agar serupa dengan cara tertentu untuk sesuatu pengguna
sudah tahu, sehingga mereka dapat mentransfer pembelajaran mereka dari hal lain ke
UI perangkat lunak baru. Contoh metafora yang digunakan dalam sistem komputer untuk
pembelajaran dite adalah desktop komputer, tempat sampah untuk dihapus, salinan di layar
kalkulator genggam.
■
Mode: keadaan aplikasi komputerdi mana tindakan pengguna tertentu memiliki
efek tertentu, sedangkan dalam mode yang berbeda, tindakan yang sama memiliki
efek yang berbeda. Misalnya, pada keyboard komputer, tombol Shift Lock menyala
ON mode yang membuat tombol huruf mengetik huruf besar sampai Shift Lock menyala
matikan. Mode memungkinkan sistem memiliki lebih banyak fungsi tanpa lebih
tombol atau tombol.
■
Diubah, modal: istilah untuk sistem interaktif yang memiliki mode . Diubah
sistem memiliki kelebihan, tetapi lebih sulit dipelajari untuk digunakan.
■
Modeless: istilah untuk sistem interaktif yang tidak memiliki mode, yaitu setiap
tindakan pengguna selalu memiliki efek yang sama.
■
Analisis objek / tindakan: daftar objek konseptual yang dikerjakan orang-
ing dalam pertemuan domain tugas . Pencacahan menentukan bagaimana objek berada

Halaman 389

Lampiran A: Daftar Istilah 375

terkait satu sama lain, misalnya, jenis / subtipe, wadah / penampung, keseluruhan / bagian.
Analisis juga mencantumkan tindakan yang dapat dilakukan pada setiap jenis objek
dan atribut objek. Analisis ini adalah bagian terpenting dari a
model konseptual . Hasil analisis objek / tindakan terkadang disebut
sebuah ontologi .
■
Persona: a profil pengguna dijabarkan dalam penjelasan rinci tentang seseorang,
dengan detail yang relevan tentang gaya hidup, status ekonomi, pendidikan, dan tugas
pengetahuan domain dan sering kali berupa foto atau sketsa pengguna.
■

[Link] 282/315
26/2/2021 Tanpa judul
Jendela utama:keseluruhan
aplikasi secara jendela dalam
atauaplikasi perangkat
setidaknya lunak yang
untuk bagian merupakan
tertentu "rumah" untuk
dari fungsinya.
Jendela utama biasanya tetap ditampilkan untuk waktu yang lama,
berbeda dengan jendela sekunder (misalnya kotak dialog), yang biasanya
sementara.
■
Leksikon produk, kamus, nomenklatur, standar terminologi, kosakata
ulary, glosarium: daftar terminologi yang digunakan dalam aplikasi dan nya
dokumentasi, dengan istilah dan artinya.
■
Pengungkapan progresif: teknik desain yang menyederhanakan UI dengan menyembunyikan
detail atau kontrol yang jarang digunakan hingga pengguna membutuhkannya. Dalam beberapa kasus,
kontrol tersembunyi muncul saat pengguna mengklik tombol "Detail" atau "Lainnya";
di sisi lain, perubahan muncul ketika perubahan lain dalam perangkat lunak membuatnya
relevan.
■
Responsiveness: kemampuan perangkat lunak untuk mengikuti dan menjaga pengguna
mereka diberitahu tentang apa yang dilakukannya.
■
Jendela sekunder: jendela perangkat lunak yang dirancang untuk ditampilkan
sementara, baik untuk menyajikan pesan kepada pengguna atau untuk mengumpulkan masukan
pengguna. Kebanyakan jendela sekunder adalah kotak dialog . Kontras dengan primer
jendela .
■
Analisis tugas : mempelajari tugas dalam domain tugas untuk memahami apa semua
tugasnya adalah, tugas mana yang umum vs. jarang, apa langkah dari setiap tugas
adalah, apa yang menjadi tugas, dan apa hasil darinya.
■
Domain tugas : sekumpulan tugas di mana semua tugas menyangkut umum yang sama
tema. Contoh domain tugas adalah akuntansi bisnis, rekening bank
perawatan, belanja mobil, permainan catur, mengambil foto.
Aplikasi perangkat lunak biasanya dirancang untuk mendukung tidak hanya satu tugas,
melainkan banyak tugas dalam domain tugas.
■
Uji kegunaan: tes di mana perwakilan pengguna diamati saat mereka
menggunakan perangkat lunak. Uji kegunaan dilakukan untuk menemukan masalah kegunaan. Sana
Ada banyak cara berbeda untuk melakukan uji kegunaan.
■
Analisis pengguna: mempelajari pengguna yang dituju dari aplikasi atau situs Web untuk
memahami kebutuhan mereka.
■
Profil pengguna: deskripsi singkat dari satu jenis pengguna bahwa aplikasi ini
dirancang untuk. Beberapa profil pengguna biasanya dibuat untuk setiap produk,

Halaman 390

376 Lampiran

masing-masing mewakili kategori pengguna penting yang berbeda. Saat pengguna

profil diuraikan dengan nama dan detail yang dibuat untuk menentukan stere-
pengguna otypical, mereka disebut persona .
■
Hierarki visual: cara mendesain tampilan agar pengguna dapat melihat dengan cepat
informasi (atau fungsionalitas) yang berada di bagian mana dari tampilan. Ini
memungkinkan pengguna untuk dengan cepat menelusuri informasi atau fungsionalitas itu
yang mereka butuhkan, sambil mengabaikan bagian tampilan lainnya.
■
Panduan: kotak dialog beberapa langkah yang menghentikan proses atau kumpulan yang kompleks
opsi menjadi bagian yang lebih sederhana. Pengguna dibimbing melalui langkah-langkah, tapi bisa
mencadangkan atau berhenti kapan saja.

Lampiran B: Bagaimana buku ini diuji kegunaannya

Edisi kedua: Perbaikan berdasarkan umpan balik dari

pembaca edisi pertama

Ini adalah rilis 2.0. Rilis 1.0 secara eksplisit diuji dan ditingkatkan kegunaannya
sebelum dirilis (lihat di bawah). Hasilnya adalah buku yang berguna (seperti yang ditunjukkan
oleh penjualan), tetapi yang masih memiliki masalah kegunaan.
Masalah-masalah itu ditunjukkan oleh pembaca dalam artikel review untuk mag-
azines, dalam komentar yang diposting di penjual buku online dan dalam diskusi online
kelompok, dan dalam catatan yang dikirimkan kepada saya. Cacat terpenting dari GUI Bloopers 1.0
adalah sebagai berikut:

■
Kurangnya keterangan gambar: Figur di GUI Bloopers tidak memiliki keterangan, hanya num-
bers, menyulitkan pembaca untuk mendapatkan informasi dengan membolak-balik
buku melihat angka-angka.
■
Referensi silang tidak cukup tepat: Dalam edisi pertama, publikasi
proses tidak memungkinkan kami untuk memiliki referensi silang menjadi nomor halaman yang tepat;

[Link] 283/315
26/2/2021 Tanpa judul
sebagai gantinya, referensi silang memberikan blooper atau nomor bagian.
■
Terlalu bertele-tele: Banyak pembaca yang mengeluh bahwa edisi pertama terlalu bertele-tele.
■
Nada anti-programmer: Pada rilis 1.0, saya mencoba menjelaskan bahwa tidak semua GUI
blooper adalah kesalahan programmer, dan mereka yang secara nominal kom-
dipasangi oleh programmer sering karena alat yang salah, jadwal yang tidak realistis,
manajemen yang buruk, atau kurangnya pelatihan desain GUI. Meskipun demikian, beberapa
para pembaca mengeluhkan nada anti-programmer.

Untuk memperbaiki tiga masalah pertama, kami melakukan yang sudah jelas: kami menambahkan cap angka-
tions, kami mengubah referensi silang ke nomor halaman, dan kami memotong ver-
biage. Kami juga menghapus dua bab yang hanya sedikit orang yang pernah disebutkan; mereka hanya
ditambahkan ke jumlah dan harga buku. Menghilangkan nada anti-programmer

Halaman 391

Lampiran B: Bagaimana buku ini diuji kegunaannya 377

tidak sesederhana itu, tetapi dalam merevisi buku saya berusaha sangat keras (lagi)
untuk melakukannya.

Pengujian edisi pertama

Buku ini merekomendasikan pengujian kegunaan perangkat lunak sedini mungkin

dalam pengembangan dan sesering mungkin di sepanjang jalan. Memang, itu mencemooh
pengembang yang tidak menguji kegunaan produk mereka sebelum merilisnya. Saya t
akan munafik untuk menerbitkan buku ini tanpa terlebih dahulu mengujinya pada orang
yang mewakili pembaca yang dituju.

Meninjau bukanlah pengujian kegunaan

Kapan edisi pertama buku ini diusulkan ke penerbit dan sementara itu
sedang ditulis, garis besar dan draf dikirim ke pengulas untuk dievaluasi dan
mengomentari. Para reviewer pada umumnya adalah para profesional UI yang berpengalaman.
Beberapa adalah profesor dan peneliti industri; lainnya adalah desainer UI atau
penguji kegunaan yang bekerja baik untuk perusahaan atau sebagai konsultan. Semua punya tahun
dari pengalaman meninjau buku dan artikel, serta memiliki tulisan sendiri-
ings ditinjau. Mendapatkan masukan dari rekan profesional penulis adalah standar
latihan untuk buku-buku teknis. Namun, ulasan semacam itu bukanlah kegunaan yang valid
ujian buku ini, karena dua alasan:

1. Pengulas yang digunakan oleh penerbit sebenarnya bukan pembaca yang dituju
buku ini. Pembaca yang dituju adalah para pengembang software yang sering bekerja
tanpa dukungan UI profesional, manajer pengembangan, dan UI baru
desainer. Mendapatkan umpan balik dari orang-orang yang mewakili eselon atas
bidang Interaksi Manusia-Komputer sangat berbeda dari pengujian
buku tentang audiens yang dituju.
2. Meminta seseorang untuk membaca buku dan mengomentarinya tidak sama dengan bertanya-
meminta seseorang untuk menggunakannya — atau mempertimbangkan bagaimana mereka akan menggunakannya — dalam pekerjaan mereka.

Mendorong pengembang untuk menguji buku tersebut

Kami bertanya kepada beberapa programmer profesional (beberapa di antaranya juga

agers) untuk membaca naskah dan menggunakannya dalam pekerjaan mereka atau mempertimbangkan caranya
mereka akan menggunakannya. Beberapa benar-benar menggunakan buku itu untuk membantu menemukan dan membersihkan
kesalahan besar dalam perangkat lunak organisasi mereka. Yang lain hanya membacanya dan berimajinasi
bagaimana mereka akan menggunakannya. Selain menerima umpan balik apa pun mereka
memberi kami, kami meminta mereka untuk menjawab pertanyaan tentang konten buku dan
organisasi. Meskipun pengujian ini informal, itu sangat berharga-
mampu memandu desain buku saat kami merevisi draf pertama menjadi
versi yang diterbitkan.

Halaman 392

[Link] 284/315
26/2/2021 Tanpa judul

378 Lampiran

Apa yang kami pelajari dari pengujian

■
Jadikan akses itu lebih acak . Programmer tidak mau harus membaca
buku dari depan ke belakang. Mereka ingin bisa melihat blooper
untuk menjawab pertanyaan desain spesifik mereka. Mereka menginginkan setiap blooper dan
bagaimana menghindarinya, baik menjadi mandiri atau menunjukkan dengan tepat
di mana informasi tambahan dapat ditemukan. Mereka menginginkan buku itu
menjadi lebih — dengan kata-kata seorang programmer— “akses acak”. Tidak ada rekomendasi seperti itu
Perbaikan datang dari akademisi dan peneliti yang mereview
Book. Menanggapi umpan balik ini, kami merevisi blooper menjadi masing-masing
satu mandiri. Jika itu tidak memungkinkan, kami mencoba membuatnya mudah
ikuti referensi silang, dengan mengacu pada kesalahan besar dan nomor bagian (bukan
hanya nomor bab) dan menambahkan daftar isi lengkap dan a
indeks rinci.
■
Tonjolkan poin penting . Programmer tidak suka ketika mengimpor-
poin-poin tant terkubur di tengah paragraf. Mereka ingin bisa
untuk menelusuri atau membalik-balik buku dan tetap mendapatkan informasi berguna. Berbasis
pada umpan balik ini, saya lebih banyak menggunakan heading, penekanan, tabel, dan bul-
biarkan poin dan bekerja sama dengan penerbit untuk memformat dan mengatur tata letak buku
memudahkan pemindaian informasi.
■
Jelaskan mengapa blooper adalah blooper . Pemrogram meminta penjelasan
tentang mengapa blooper dianggap blooper, serta prinsip-prinsipnya
yang mendasari aturan desain untuk menghindari kesalahan besar. Para programmer menginginkannya
penjelasan ini di depan, sebelum bloopers. Draf awal rilis 1.0
dimulai dengan blooper, dengan asumsi bahwa programmer GUI akan melakukannya
ingin fokus pada kesalahan desain konkret dan menghindari prinsip abstrak
dan teori. Prinsip desain tersebar sesuai kebutuhan di sekitar buku—
terutama dalam aturan desain untuk menghindari kesalahan besar. Pengujian menunjukkan bahwa
pendekatan salah, jadi Bab 1 ditambahkan.
■
Berikan lebih banyak contoh . Permintaan yang tidak terlalu mengejutkan dari beberapa programmer
adalah "lebih banyak contoh, lebih banyak gambar layar." Permintaan yang sama datang dari
pengulas biasa. Versi awal manuskrip kurang memiliki ilustrasi
gambar layar. Sebagian sebagai hasil dari umpan balik ini dan sebagian lagi berdasarkan
rencana yang sudah ada sebelumnya, lebih banyak contoh ditambahkan, dan beberapa blooper untuk
contoh bagus mana yang tidak dapat ditemukan atau sketsa telah dihapus.
■
Tandai contoh sebagai "baik" atau "buruk". Programer menginginkan ujian visual-
banyak blooper dan desain yang tepat untuk ditandai dengan jelas sebagai "baik" atau "buruk".
Mereka tidak ingin harus membaca teks di sekitar gambar untuk mengetahui apakah
itu adalah contoh kesalahan besar atau desain yang bagus. Kami melakukan tes kertas
dari berbagai simbol untuk "baik" dan "buruk" dan diselesaikan di tangan dengan ibu jari
atas dan bawah masing-masing untuk "baik" dan "buruk".
■
Jangan “mengabaikan” programmer . Beberapa programmer mengkritik draf awal
buku untuk menyalahkan programmer karena melakukan blooper. Terkadang, mereka

Halaman 393

Lampiran C: Analisis tugas membuat presentasi slide — pertanyaan 379

mengatakan, blooper adalah kesalahan alat atau blok penyusun yang program-
mer harus menggunakan atau proses pengembangan yang harus diikuti oleh programmer.
Saya setuju. Pemrogram GUI bekerja sangat keras dan melakukan pekerjaan dengan baik. saya menggunakan
format bloopers sebagai perangkat instruksional agar pengembang belajar
untuk mengenali kesalahan umum GUI dan cara menghindarinya. Agar tidak
menyinggung audiens utama saya, saya mencoba membuat buku ini tidak terlalu kritis terhadap
orang dan lebih kritis terhadap proses pembangunan .

Lampiran C: Analisis tugas pembuatan slide

presentasi — pertanyaan

Daftar lengkap pertanyaan yang digunakan dalam wawancara analisis tugas dijelaskan dalam
sidebar pada halaman 14–15 adalah sebagai berikut:

[Link] 285/315
26/2/2021 Tanpa judul
1. Apa peran Anda dalam menghasilkan presentasi slide?
1.1 Apakah Anda membuat slide sendiri atau Anda mengawasi orang lain yang melakukannya?
1.1.1 Pelatihan atau pengalaman seperti apa yang dibutuhkan untuk melakukan pekerjaan Anda
melakukan?
1.1.2 [Jika mengawasi orang lain] Apa tingkat keterampilan karyawan Anda?
1.2 Berapa banyak dari total pekerjaan Anda yang melibatkan pembuatan presentasi slide?
1.3 Untuk siapa Anda membuat presentasi slide ini?
1.3.1 Siapa pelanggannya (yaitu, siapa yang menyetujui slide)?
1.3.2 Siapa audiens untuk presentasi ini?
1.4 Tingkat kualitas apa yang diperlukan untuk slide?
1.4.1 Seberapa penting efek khusus yang rumit (mis., Animasi, dis-
memecahkan)?
1.4.2 Siapa yang memutuskan penampilan dan kualitas, Anda atau pelanggan?
1.4.3 Apakah ada jenis presentasi yang berbeda dengan kualitas yang berbeda
Persyaratan?
1.5 Apakah Anda (departemen Anda) mengikuti standar pemformatan slide?
1.5.1 Bagaimana Anda memastikan bahwa slide mematuhi standar tersebut?
1.5.2 Apakah perangkat lunak pembuat slide Anda membantu standarisasi pres-
bujukan?
2. Perangkat lunak apa yang Anda gunakan untuk membuat presentasi slide?
2.1 Siapa yang memutuskan perangkat lunak apa yang Anda gunakan untuk ini?
2.2 Apakah Anda menggunakan satu program atau kumpulan dari mereka?
2.2.1 [Jika banyak] Untuk apa program berbeda digunakan?

Halaman 394

380 Lampiran

2.3 Apakah Anda menggunakan perangkat lunak gambar untuk keperluan umum atau perangkat lunak pembuat slide
ware?
2.3.1 Mengapa?
2.4 Apa yang Anda sukai dari setiap program yang Anda gunakan?
2.5 Apa yang tidak Anda sukai tentang masing-masing; apa yang ingin kamu lihat
berubah?
2.5.1 Jelaskan beberapa hal yang Anda lakukan untuk "mengatasi" keterbatasan
perangkat lunak.
2.6 Seberapa mudah perangkat lunak bagi pengguna baru untuk belajar?
2.6.1 Bagaimana mereka mempelajari perangkat lunak (kelas, manual, penggunaan, bertanya)?
2.6.2 Bagaimana Anda mempelajarinya?
2.7 Perangkat lunak lain apa yang telah Anda gunakan, coba, atau pertimbangkan untuk dibuat
slide, baik di sini atau di pekerjaan sebelumnya?
2.7.1 Mengapa Anda tidak menggunakannya sekarang?
3. Apa yang terlibat dalam pembuatan slide?
3.1 Jelaskan proses lengkap menghasilkan presentasi, dari kapan
Anda mengambil tugas saat Anda mengirimkannya ke pelanggan.
3.1.1 Berapa banyak revisi yang biasanya diperlukan sebelum presentasi dibuat.
dianggap selesai?
3.2 Apakah Anda biasanya membuat presentasi slide baru?
3.2.1 Apa yang sulit dan apa yang mudah tentang membuat materi baru, yaitu,
apa yang berjalan cepat dan apa yang membutuhkan waktu dan usaha?
3.3 Apakah Anda menggunakan kembali slide lama dalam presentasi baru?
3.3.1 Apa yang sulit dan apa yang mudah tentang menggunakan kembali materi lama, yaitu apa
berjalan cepat dan apa yang membutuhkan waktu dan kerja?
3.4 Bagaimana Anda (departemen Anda) mengatur dan melacak slide dan
presentasi?
3.4.1 Apakah setiap slide merupakan file terpisah, atau semua slide dalam presentasi
bersama dalam satu file?
3.4.2 Bagaimana Anda mengatur materi Anda?
3.4.3 Bagaimana Anda memberi nama file slide (atau presentasi) Anda?
3.4.4 Apakah Anda pernah gagal menemukan slide yang Anda tahu Anda miliki?
3.4.5 Bagaimana perangkat lunak Anda menghalangi Anda dalam menggunakan kembali materi?
3.4.6 Seberapa mudah Anda dapat memasukkan satu slide dalam beberapa tampilan

[Link] 286/315
26/2/2021 Tanpa judul
tasi?
3.5 Jenis revisi apa yang sering dibutuhkan dalam proses persiapan
Sebuah presentasi?
3.5.1 Mana yang mudah dan mana yang sulit?

Halaman 395

Lampiran D: Mengilustrasikan kesederhanaan — matriks objek / tindakan 381

3.5.2 Apakah revisi yang sama mudah dan sulit untuk setiap program pembuatan slide
Kau gunakan?
3.5.3 Kasus penting khusus:
[Link] Slide yang digunakan dalam banyak presentasi diubah.
[Link] Logo atau batas standar harus ditambahkan ke semua slide di a
presentasi.
[Link] Urutan slide dalam presentasi harus diubah.
[Link] Poin-poin bulat di seluruh presentasi harus diubah
untuk yang persegi.
[Link] Font yang digunakan selama presentasi harus diubah.
[Link] Setiap titik pada slide harus diperluas menjadi beberapa bagian
meluncur.

Lampiran D: Menggambarkan kesederhanaan — the

objek / matriks aksi

Model konseptual untuk perangkat lunak interaktif apa pun dapat diilustrasikan sebagai matriks
objek dan tindakan. Objek terdaftar di tepi kiri; tindakan terdaftar
di atas (Gambar A.1). Untuk saat ini, kami mengabaikan tipe objek
hierarki dan cukup daftar objek. Semakin banyak objek, semakin tinggi matriksnya;
semakin banyak tindakan, semakin luas.
Dengan membuat matriks seperti itu, Anda dapat memvisualisasikan kesederhanaan dan koherensi
dari model konseptual. Ini menunjukkan seberapa konsisten atau tidak konsistennya itu — betapa mudahnya
bagi pengguna untuk mentransfer pembelajaran tentang satu bagian ke bagian lain. Kecil, padat
matriks menunjukkan desain yang akan mudah dipelajari: sedikit objek, sedikit tindakan,
dan sebagian besar tindakan berlaku untuk sebagian besar objek (Gambar A.2A).
Matriks yang besar dan jarang mencerminkan desain yang tidak koheren yang akan sulit untuk dicapai
belajar dan mengingat karena setiap konsep bekerja secara berbeda (Gambar A.2B).

Gambar A.1 Tindakan

ABCDEFGHI ...
1
2
3
Objek 4
5
6
...

Matriks objek / tindakan menunjukkan tindakan mana yang berlaku untuk objek mana.

Halaman 396

382 Lampiran

Gambar A.2 Tindakan

[Link] 287/315
26/2/2021 Tanpa judul
ABCDEFGHIJKLM
Tindakan 1
ABCDEF 2
1 3
2 Objek 4
Objek 3 5
4 6
5 7
8
9

Baik B - Buruk

Matriks objek / tindakan untuk desain konseptual yang mudah dikuasai vs. sulit dikuasai.

Desain konseptual seperti itu akan tampak membingungkan dan sewenang-wenang bagi pengguna
GUI apa yang terpampang di atasnya.
Semakin besar matriksnya, semakin banyak yang harus dipelajari. Matriks yang tinggi menunjukkan banyak hal
objek untuk dikuasai; yang lebar menunjukkan banyak tindakan untuk dipelajari. Aturan yang bagus
ibu jari adalah untuk menyederhanakan model konseptual sehingga matriks merepresentasikannya
sekecil dan sepadat mungkin.
Namun, matriks kecil mencerminkan fungsionalitas yang sangat terbatas. Mencapai
matriks kecil sulit dilakukan jika aplikasinya lebih rumit
daripada, katakanlah, direktori telepon pribadi atau situs Web untuk mencari perangko
tarif. Tapi semuanya relatif. Untuk fungsionalitas apa pun yang diinginkan, Anda dapat mendesain
model konseptual dengan kompleksitas yang berbeda-beda. Hanya bertujuan untuk penipuan paling sederhana
model ceptual dan matriks objek / tindakan paling kompak untuk yang diperlukan
Kegunaan.
Juga, meskipun mudah dipelajari, sistem yang mudah digunakan sering kali memiliki kompromi kecil,
matriks objek / tindakan pakta, mereka dapat memiliki konfigurasi matriks lain juga.
Pertimbangkan sistem di mana semua fungsionalitas diakses melalui lima atau enam
tindakan umum yang berlaku untuk semua objek. Sistem seperti itu bisa jadi besar
jumlah objek tanpa banyak dampak negatif pada kemampuan belajar, karena
semua benda bekerja dengan cara yang sama. Objek / matriks aksi untuk sistem seperti itu,
meski tinggi, akan sempit dan padat. Pendekatan ini telah digunakan untuk
merancang banyak sistem yang sangat fungsional.
Jika kita memasukkan hierarki tipe objek ke dalam matriks, kita bisa melihat yang lain
semacam model konseptual yang mudah dipelajari: model di mana objek jatuh dengan jelas
ke dalam kategori, dengan setiap kategori memiliki tindakannya sendiri, mungkin dengan beberapa
tindakan yang berlaku untuk semua objek (Gambar A.3). Matriks untuk model seperti itu tidak
kecil atau padat, tetapi juga tidak tersebar. Ini memiliki keteraturan yang membantu pembelajaran
dan retensi. Contohnya adalah layanan real estat yang menawarkan keduanya
properti komersial dan residensial, dengan tindakan berbeda untuk setiap properti
serta tindakan untuk semua properti.

Halaman 397

Lampiran E: Uji kegunaan untuk setiap waktu dan tujuan 383

Gambar A.3 Umum

Jenis-Tindakan Khusus Tindakan
ABCDEFGHIJKLM
1
2
X
3
Objek 4
5
Y
6
7
8
Z
9

Matriks objek / tindakan untuk jenis desain konseptual yang lebih realistis dan mudah dikuasai.

Lampiran E: Uji kegunaan untuk setiap waktu

dan tujuan

Uji kegunaan dapat dikategorikan dalam dua dimensi (Prinsip Dasar 9,

halaman 48):

1. Titik pengembangan di mana mereka dilakukan

2. Formalitas metode pengujian

[Link] 288/315
26/2/2021 Tanpa judul

Tahap implementasi pengujian

Pertama, mari kita pertimbangkan titik pengembangan tempat pengujian dilakukan. Itu membantu
untuk membagi dimensi ini menjadi tiga kategori:

■
Sebelum pengembangan: Sebelum sesuatu diimplementasikan, pengembang bisa
menguji desain menggunakan mock-up. Maket bisa berupa papan cerita — digambar dengan tangan
sketsa desain di atas kertas yang ditampilkan kepada pengguna sesuai urutannya
akan terjadi pada produk yang sedang berjalan. Mereka bisa menjadi gambar layar yang dibuat
menggunakan alat bangunan GUI interaktif, dicetak di atas kertas, dan ditempatkan di
di depan pengguna dengan seseorang yang bertindak sebagai "komputer" saat pengguna "mengklik"
kontrol yang ditampilkan di layar. Mereka bisa menjadi "komputer karton"
dengan layar proyeksi belakang yang menunjukkan gambar yang mensimulasikan tampilan (lihat
bab "Komputer Cardboard" dalam buku oleh Greenbaum dan Kyng
[1991]). Akhirnya, mereka bisa menjadi sistem "Wizard of Oz" di mana tampilan
di layar komputer dikendalikan oleh orang di ruangan lain yang
melihat apa yang dilakukan pengguna dan mengubah layar pengguna sesuai dengan itu.
■ Selama pengembangan: Tim pengembangan dapat menggunakan perangkat lunak pembuatan prototipe
(mis., Flash) untuk membuat mock-up aplikasi yang berfungsi. Prototipe GUI

Halaman 398

384 Lampiran

dengan alat seperti itu hanya akan menjadi prototipe; kode dasar mereka tidak akan
digunakan dalam implementasi akhirnya. Atau, beberapa bangunan GUI
alat memungkinkan antarmuka pengguna untuk sebagian disambungkan dan "dijalankan". Ini
memungkinkan versi awal GUI untuk diuji bahkan sebelum kode back-end
telah ditulis. Cara lain untuk menguji selama pengembangan adalah dengan menguji bagian
aplikasi yang direncanakan secara terpisah, untuk menyelesaikan masalah desain. Sebagai contoh,
seseorang dapat menguji kontrol tabel yang digunakan dalam aplikasi jauh sebelum file
sisa aplikasi sudah siap.
■
Setelah pengembangan: Banyak uji kegunaan dilakukan saat sebagian besar
produk telah diterapkan dan sedang dipersiapkan untuk dirilis. Saat ini
tahap akhir, jarang hasil tes kegunaan memiliki banyak
berdampak pada rilis tertunda karena organisasi pengembangan digunakan
sekutu siap untuk mengirimkannya. Salah satu alasan untuk melakukan uji kegunaan pada tahap ini adalah
untuk memberikan panduan untuk pembersihan awal dari masalah kegunaan kecil.
Meskipun demikian, pengujian semacam itu juga dapat mengungkap masalah "showstopper" itu
dianggap cukup penting untuk menunda rilis. Alasan kedua untuk
menguji perangkat lunak "lengkap" adalah untuk mendapatkan umpan balik tentang cara meningkatkan masa depan
rilis. Pengujian semacam ini dapat dilakukan setelah rilis, ketika file
jadwalnya tidak terlalu rumit dan tim mulai memikirkan yang berikutnya
melepaskan.

Formalitas pengujian

Dimensi kedua di mana pengujian kegunaan dapat dikategorikan adalah

formalitas metode pengujian. Formalitas uji kegunaan berkaitan dengan file
tingkat kontrol yang diberikan penguji atas apa yang dilakukan orang dalam sesi pengujian dan
apakah pengukurannya kualitatif atau kuantitatif. Sekali lagi, ini membantu
untuk membagi dimensi ini menjadi tiga kategori:

■
Informal: Jenis pengujian ini mencakup situasi di mana pengguna inter-
dilihat tentang perangkat lunak, misalnya, bagaimana mereka menggunakannya, apa yang mereka gunakan
karena, bagaimana mereka menyukainya. Terkadang ini dilakukan di depan komputer dengan ekstensi
perangkat lunak berjalan sehingga pengguna dapat menunjukkan apa yang dia bicarakan, dan
terkadang tidak. Pengujian informal juga mencakup situasi di mana pengguna
diamati saat mereka melakukan pekerjaan nyata mereka atau saat mereka menjelajahi soft-
ware dengan cara yang tidak terarah. Para pengamat mencatat suka yang diungkapkan pengguna
dan tidak suka serta mencatat masalah apa pun yang mereka lihat dialami pengguna. Sesi
dapat direkam atau direkam. Pengamatannya kualitatif. ini
terbaik untuk memulai setiap sesi tes dengan tugas-tugas sederhana dan memberikan peserta tes
tugas yang semakin sulit selama sesi.
■
Kuasi-formal: Dalam jenis pengujian ini, pengguna diminta untuk melakukan tugas-tugas yang ada
telah ditentukan oleh penguji, yang juga menyiapkan pasangan yang diperlukan
real dan file data dan mengatur perangkat lunak sesuai kebutuhan. Dengan kata lain,

[Link] 289/315
26/2/2021 Tanpa judul

Halaman 399

Lampiran E: Uji kegunaan untuk setiap waktu dan tujuan 385

pengguna tidak hanya menjelajahi perangkat lunak atau melakukan pekerjaan mereka sendiri; mereka
melakukan apa yang diminta penguji untuk mereka lakukan. Namun, seperti dalam pengujian informal, file
pengukuran terutama bersifat observasi. Penguji merekam (dan menghitung) apa saja
kesalahan yang dibuat pengguna, serta situasi di mana pengguna membutuhkan bantuan (baik dari
dokumen bantuan online atau dari penguji). Para penguji pun mencatat waktu
diperlukan untuk menyelesaikan setiap tugas. Sesi ini dapat direkam dalam video.
■
Formal: Ini adalah jenis pengujian kegunaan yang paling mirip dengan
eksperimen psikologi yang banyak orang ingat dari masa kuliah mereka.
Mereka benar-benar "eksperimen terkontrol", yang dilakukan untuk membandingkan alternatif
desain (misalnya, tata letak kontrol A versus B) atau untuk menentukan nilai optimal
dari parameter desain (misalnya, jumlah level menu bertingkat). Tugasnya
bahwa peserta tes diminta untuk melakukan sangat ditentukan, dan mereka
terkait dengan tugas dunia nyata sering kali tampak lemah (misalnya, menggunakan mouse untuk menekan
urutan target yang diposisikan secara acak di layar; temukan file menggunakan
file browser ini). Padahal, bahan atau software yang digunakan untuk tes sering kali
dirancang murni untuk pengujian itu sendiri, bukan sebagai bagian dari menunggu
produk. Data yang dikumpulkan sebagian besar bersifat kuantitatif (misalnya, reaksi pengguna atau
waktu penyelesaian, jumlah kesalahan) dan dianalisis secara statistik. Seringkali,
data dikumpulkan secara otomatis, oleh komputer yang sama yang menjalankan
uji perangkat lunak. Selain itu, sesi semacam itu biasanya direkam dalam video.

Setiap tingkat formalitas memiliki tempat dalam pengembangan produk. Ini penting untuk
menyadari bahwa formalitas suatu ujian tidak bergantung pada tujuan pengembangannya
yang mana pengujian itu dilakukan. Pada setiap tahap perkembangan, seseorang dapat merancang penggunaan-
tes bility di semua tingkat formalitas. Beberapa contoh diberikan dalam diskusi
dari Blooper 66 (halaman 341).
Tabel A.1 memberikan contoh pengujian yang menunjukkan setiap kemungkinan kombinasi
tiga tahap perkembangan dan tiga tingkat formalitas.

Tes prapembangunan memberikan nilai yang tinggi

Uji sebelum pengembangan jika memungkinkan. Ini teknologi rendah, murah, mudah, itu
memberikan umpan balik yang berharga, dan ini cukup awal untuk berdampak besar
desain. Pengujian pra-implementasi memungkinkan Anda untuk menguji ide sebelum pengembangan-
tim operasi menggunakan biaya untuk mengkodekannya.
Misalnya, untuk menguji apakah label grafis pada tombol toolbar menyampaikan
maknanya bagi pengguna, mencetaknya dengan warna atau menaruhnya di Web
halaman dan minta orang untuk mencocokkannya dengan daftar nama fungsi. Untuk mengetahui apakah
lokasi dan penamaan item di menu menu masuk akal bagi pengguna,
cetak bilah menu dan menu (atau bahkan tulis tangan) dan tanyakan pada orang lain
untuk menemukan item tertentu. Pengujian pra-implementasi bagus untuk menguji masalah
pemahaman, navigasi, dan alur tugas secara keseluruhan, tetapi tentu saja buruk untuk pengujian
masalah interaksi dan respon yang kompleks.

Halaman 400

386 Lampiran

Tabel A.1 Uji kegunaan dilakukan pada berbagai tahap perkembangan dan formalitas yang bervariasi

Formalitas Tahap pengembangan

metode pengujian Sebelum Selama Setelah

Informal: Wawancara dan Selama deve- Pada hari pemilihan 2004,

wawancara, grup fokus lopment dari sebuah Web relawan hukum di
survei, lapangan dilakukan aplikasi untuk call center siapa
studi, dengan guru untuk merekam dan menggunakan
mengamati pelajari cara mereka menggunakannya
melacak pemungutan suara Insiden Pemilu

[Link] 290/315
26/2/2021 Tanpa judul
pengguna di video di masalah di Sistem pelaporan
ruang kelas kerja normal dan apa pemilu AS 2004, (EIRS)
lingkungan yang mereka suka dan tidak suka sesi itu direkam dan
tentang arus diamati di mana diwawancarai.
(tidak terkomputerisasi) pengguna sukarelawan Lapangan
sistem untuk menemukan, dilatih observasi dan
memilih, dan versi awal komentar pengguna
menampilkan video. aplikasi. asalkan berharga
Ini dilakukan di Aspek UI masukan untuk perbaikan
persiapan untuk itu sulit EIRS untuk tahun 2005
mendesain online untuk instruktur dan pemilu selanjutnya
pencari video dan jelaskan juga [Johnson dan
layanan melihat mereka yang tentang Marshall, 2005].
untuk ruang kelas trainee bertanya banyak
menggunakan. Untuk detailnya, pertanyaan dicatat
lihat Blooper 6 dan digunakan untuk membimbing
(halaman 77). perbaikan desain-
ments [Johnson
dan Marshall, 2005].

Quasi-formal: Protokol HTML statis- Pembuatan awal Versi yang dirilis

telah ditentukan sebelumnya
jenis perusahaan berbasis browser dari genggam
tugas yang diberikan Situs web digunakan untuk aplikasi grafis Alat internet
dengan tes uji seberapa mudah tion untuk mengelola telah diuji
moderator; orang bisa navi- kelompok server 10 orang untuk ditemukan
pengamat gerbang yang diinginkan telah diuji. Delapan masalah kegunaan
catatan informasi. berpengalaman dan menyarankan
masalah, Enam peserta perbaikan sistem administrasi untuk
penyelesaian ditunjukkan Tor direkam pada rilis berikutnya.
waktu, membantu halaman muka dan ditanya dan waktu pelaksanaan- Peserta tes
untuk menemukan jawaban server tertentu melakukan singkat
pertanyaan tertentu. tugas manajemen. tugas yang ditentukan oleh
Hasil tes Tes itu dilakukan penguji.
membantu memandu disebutkan dalam sesi Tes perusahaan itu
merancang dan mengimplementasikan-
laboratorium kegunaan. Itu dilakukan di tempat kosong
sebutan dari hasil diminta kantor. Pengamat
situs sebenarnya. perubahan signifikan mencatat, tetapi
di UI. sesi tidak
direkam.

Halaman 401

Lampiran E: Uji kegunaan untuk setiap waktu dan tujuan 387

Tabel A.1 Uji kegunaan dilakukan pada berbagai tahap perkembangan dan formalitas yang bervariasi
(Lanjutan) Tahap pengembangan
Formalitas
metode pengujian Sebelum Selama Setelah

Formal: benar Ikon desktop untuk mengevaluasi tes A baru dibandingkan tiga
percobaan, workstation kantor remote touchpad metode penemuan
kuantitatif telah diuji. Uji kontrol untuk operasi Dokumentasi bantuan
pengukuran, peserta di layar di Windows
statistik meminta keduanya untuk menebak
kontrol untuk inter- aplikasi:
analisis, arti ikon televisi aktif (a) daftar konten,
sering kali A vs. B dan untuk mencocokkan ikon layanan, tes (b) indeks, dan
perbandingan dengan nama fungsi. membandingkan (c) pencarian. Uji parti-
Ikon-ikon itu pra- prototipe jarak jauh cipants dicari
dikirim di atas kertas. Kontrol dengan tradi- jawaban untuk prespeci-
tanggapan itu tional pointing pertanyaan fied menggunakan
dianalisis secara statistik perangkat. Ujilah bagian dari setiap metode.
untuk menghasilkan "kebingungan" cipants menggunakan Pengukuran kuantitatif
matriks menunjukkan perangkat penunjuk ke rekaman disertakan
ikon mana yang cenderung mencoba mencapai sukses / gagal secara acak, tugas
bingung dengan satu tombol yang dipilih waktu, jumlah
lain dan yang mana tersusun di TV klik, jumlah
ikon mudah digunakan layar. Waktu dokumen dikunjungi,
mengakui. Untuk detailnya, untuk peserta dan lain-lain. Statistik
lihat Miller dan untuk mencapai target analisis digunakan untuk
Johnson [1996]. tombol itu periksa signifikansi
tercatat. Uji tidak bisa perbedaan
sesi sudah masuk diantara
kegunaan formal Pencari informasi
lab dan metode video.
direkam. Untuk detailnya,
lihat Johnson dan
Keavney [1995].

[Link] 291/315
26/2/2021 Tanpa judul

Buku Snyder Paper Prototyping [2003] memberikan gambaran yang baik tentang
kemungkinan untuk pengujian pra-implementasi. Johnson [1998] menjelaskan sebuah proyek
di mana kendala anggaran dan waktu memerlukan uji kegunaan untuk dilakukan
di atas kertas sebelum sesuatu dikembangkan.

Pengujian selama pengembangan juga bisa murah

Terkadang kegunaan orang dibawa setelah pembangunan sudah ada

dimulai. Jika tidak ada banyak anggaran atau waktu untuk pengujian kegunaan, Anda mungkin punya
untuk menjadi kreatif dalam cara Anda menguji kegunaan perangkat lunak.

Halaman 402

388 Lampiran

Johnson dan Marshall [2005] menjelaskan bagaimana tes berbiaya rendah, cepat-dan-kotor
digunakan untuk mengevaluasi desain dan menyelesaikan masalah desain dalam proyek yang tidak memiliki
anggaran atau waktu untuk pengujian kegunaan. Buku Krug Don't Make Me Think [2005]
juga menjelaskan cara menguji dengan murah. Metode pengujian yang direkomendasikan meliputi:

■
menguji pengguna menggunakan perangkat lunak yang berfungsi sebagian atau proto-
jenis;
■
menggunakan sesama karyawan yang tidak ada dalam proyek sebagai peserta tes;
■
memberikan perangkat lunak kepada pengguna atau pakar kegunaan dan meminta mereka untuk meninjau
itu dan melaporkan masalah;
■
mengamati sesi pelatihan untuk melihat aspek perangkat lunak yang dimiliki peserta pelatihan
kesulitan memahami atau instruktur kesulitan menjelaskan.

Halaman 403

[Link] 292/315
26/2/2021 Tanpa judul

Bibliografi

Ambler, S. 2005. "Siklus Hidup Pengembangan Sistem Agile." Ambysoft online

artikel: [Link]
Apple Computer, Inc. 2006. Panduan Antarmuka Manusia Apple . Di Web di
[Link]
OSXHIGuidelines / [Link].
Bankston, A. 2001. "Kegunaan dan Desain Antarmuka Pengguna di XP". CC Pace
Sistem, di Web di [Link]
[Link].
Barber, R., dan Lucas, H. 1983. "Waktu Respon Sistem, Produktivitas Operator,
dan Kepuasan Kerja. " Komunikasi dari ACM 26 (11): 972–986.
Beck, K., dan Andres, C. 2004. Penjelasan Pemrograman Ekstrim: Embrace
Ubah, edisi ke-2. Membaca, MA: Addison Wesley.
Berkun, S. 2005. Seni Manajemen Proyek . Sebastapol, CA: O'Reilly
Media.
Beyer, H., dan Holtzblatt, K. 1998. Desain Kontekstual: Mendefinisikan Pelanggan-
Sistem Terpusat . San Francisco: Penerbit Morgan Kaufmann.
Bias, RG, dan Mayhew, DJ 2005. Kegunaan Pembenaran Biaya, Edisi Kedua: An
Pembaruan untuk Era Internet . San Francisco: Penerbit Morgan Kaufmann.
Bickford, P. 1997. Desain Antarmuka: Seni Mengembangkan Perangkat Lunak yang Mudah Digunakan .
Chestnut Hill, MA: Academic Press.
Brady, JT 1986. “Teori Produktivitas dalam Proses Kreatif.” IEEE
Grafik Komputer dan Aplikasi 6 (5): 25–34.
Brinck, T., Gergle, D., dan Wood, SD 2001. Kegunaan untuk Web: Merancang
Situs Web Yang Bekerja . San Francisco: Penerbit Morgan Kaufmann.
Brooks, F. 1995. The Mythical Man-Month: Essays on Software Engineering , 20 th
Edisi Peringatan, Membaca, MA: Addison-Wesley.
Brown, CM 1988. Pedoman Desain Antarmuka Manusia-Komputer . Norwood,
NJ: Penerbitan Ablex.
Card, S. 1996. “Pionir dan Settler: Metode yang Digunakan dalam Antarmuka Pengguna yang Berhasil
Rancangan." Dalam M. Rudisill, C. Lewis, P. Polson, dan T. McKay, eds., Human–
Desain Antarmuka Komputer: Kasus Sukses, Metode yang Muncul, Dunia Nyata
Konteks . San Francisco: Penerbit Morgan Kaufmann.
Card, S., Moran, T., dan Newell, A. 1983. Psikologi Manusia-Komputer
Interaksi . Hillsdale, NJ: Lawrence Erlbaum Associates.

389

Halaman 404

390 Daftar Pustaka

Carroll, J., dan Rosson, M. 1984. “Beyond MIPS: Performance Is Not Quality.”
Majalah Byte 9 (2): 168–172.
Conklin, PF 1996. "Membawa Kegunaan Secara Efektif ke dalam Pengembangan Produk."
Dalam M. Rudisill, C. Lewis, P. Polson, dan T. McKay, eds., Human-Computer
Desain Antarmuka: Kisah Sukses, Metode yang Muncul, Konteks Dunia Nyata .
San Francisco: Penerbit Morgan Kaufmann.
Constantine, L. 2002. “Kelincahan Proses dan Kegunaan Perangkat Lunak: Menuju
Desain yang Berpusat pada Penggunaan yang Ringan. ” Era Informasi Agustus / Sep.
Cooper, A. 1999. Para Narapidana Menjalankan Suaka . Indianapolis: SAMS
(sebuah divisi dari Macmillan Computer Publishing).
Cooper, A., Reimann, RM, dan Cronin, R. 2007. Tentang Face 3: The Essentials
Desain Interaksi . New York: John Wiley and Sons.
Keberanian, C., dan Baxter, K. 2004. Memahami Pengguna Anda: Panduan Praktis
ke Metode, Alat, dan Teknik Persyaratan Pengguna . San Francisco: Morgan
Penerbit Kaufmann.
Dayton, T., McFarland, A., dan Kramer, J. 1998. “Menjembatani Kebutuhan Pengguna dengan Keberatan

[Link] 293/315
26/2/2021 Tanpa judul
Prototipe GUI Berorientasi melalui Desain Objek Tugas. ” Dalam L. Wood, ed., User
Desain Antarmuka: Menjembatani Celah dari Persyaratan ke Desain . Boca Raton,
FL: CRC Press, hlm. 15–56.
Dix, A. 1987. "The Myth of the Infinitely Fast Machine." Di Orang dan Komputer
III: Prosiding HCI'87 . Cambridge, Inggris: Cambridge University Press, hal.
215–228. [[Link]/∼cmtajd/papers/hci87]
Duis, D. 1990. Meskipun demikian, Membuat Perangkat Lunak Interaktif yang Sangat Responsif
Batasan Kinerja . Tesis Magister, Cambridge, MA: Massachusetts
Institut Teknologi.
Duis, D., dan Johnson, J. 1990. “Meningkatkan Responsivitas Antarmuka Pengguna
meskipun ada Batasan Performa. ” Dalam Prosiding IEEE CompCon'90, San
Francisco, CA: IEEE Computer Society. hlm. 380–386.
Flanders, V. 2001. Anak dari Halaman Web yang Menyebalkan: Pelajari Desain yang Baik dengan Melihat
di Bad Design . Indianapolis: Sybex.
Flanders, V., dan Willis, M. 1998. Halaman Web yang Menyedihkan: Belajar Desain yang Baik oleh
Melihat Desain Buruk . San Francisco: Sybex. [Lihat juga WebPagesThatSuck.
com]
Fowler, S., dan Stanwick, V. 1998. Buku Pegangan Desain GUI . New York: McGraw – Hill.
[Juga online di [Link]
GDH_FRNTMTR.htm]
Fowler, S., dan Stanwick, V. 2004. Buku Pegangan Desain Aplikasi Web . San
Francisco: Penerbit Morgan Kaufmann.
Galitz, W. 2007. Panduan Penting untuk Desain Antarmuka Pengguna: Pengantar
untuk Prinsip dan Teknik Desain GUI, edisi ke-3. New York: John Wiley
dan Sons.
Garrett, J. 2005. "AJAX: Pendekatan Baru untuk Aplikasi Web." Adaptif
Jalan esai online: [Link]
arsip / [Link].

Halaman 405

Bibliografi 391

Gentner, D., dan Grudin, J. 1990. “Why Good Engineers (Kadang-kadang) Buat
Antarmuka yang Buruk. ” Dalam Prosiding Konferensi ACM tentang Komputer-Manusia
Interaction (CHI'90), Seattle, ACM Press, hal. 277-282.
Proyek Gnome. 2006. Panduan Antarmuka Manusia Gnome . Yayasan GNU:
[Link]
Greenbaum, J., dan Kyng, M. 1991. Desain di Tempat Kerja: Desain Koperasi
Sistem Komputer . Hillsdale, NJ: Lawrence Erlbaum Associates.
Grudin, J. 1989. “Kasus terhadap Konsistensi Antarmuka Pengguna.” Komunikasi
dari ACM 32 (10): 1164–1173.
Grudin, J. 1991. “Sumber Sistematis Perancangan Antarmuka Suboptimal Secara Besar
Organisasi Pengembangan Produk. ” Interaksi Komputer Manusia 6:
147–196.
Hinckley, K., Pausch, R., Proffitt, D., dan Kassell, NF 1998. “Two-Handed
Manipulasi Virtual. ” Transaksi ACM pada Komputer-Interaksi Manusia
5 (3): 260–302.
Hoffman, P. 1999. “Mengakomodasi Buta Warna.” Usability Interface 6 (2).
[Juga tersedia di [Link]
[Link]]
Holtzblatt, K., Wendell, JB, dan Wood, S. 2004. Desain Kontekstual Cepat,
Edisi Pertama: Panduan Cara untuk Teknik Utama untuk Desain yang Berpusat pada Pengguna .
San Francisco: Penerbit Morgan Kaufmann.
Horrigan, JB 2005. “Adopsi Pita Lebar di Rumah di Amerika Serikat”.
Dalam Prosiding Penelitian Kebijakan Telekomunikasi Tahunan ke-33
Konferensi . Arlington, VA. [Juga tersedia dari [Link]]
Isaacs, E., dan Walendowski, A. 2001. Mendesain dari Kedua Sisi Layar:
Bagaimana Desainer dan Insinyur Dapat Berkolaborasi untuk Membangun Teknologi Kooperatif .
Indianapolis: SAMS (sebuah divisi dari Macmillan Computer Publishing).
Johnson, J. 1990. “Mode dalam Perangkat Non-komputer.” Jurnal Internasional
Studi Manusia-Mesin 32: 423–438.
Johnson, J. 1992. “Selectors: Melampaui Widget Antarmuka Pengguna.” Di
Prosiding Konferensi ACM tentang Komputer-Interaksi Manusia (CHI'92),
Monterey, CA: ACM Press, hlm. 273–279.
Johnson, J. 1996a. "Jalan Raya Informasi: Skenario Kasus Terburuk".
Komunikasi ACM 39 (2): 15–17. [Juga tersedia di [Link]-
[Link], di bawah Publikasi]
Johnson, J. 1996b. “R« D, bukan R&D. ” Komunikasi ACM 39 (9):
32–34.
Johnson, J. 1998. “Menyederhanakan Antarmuka Pengguna dari Game Film Interaktif.”
Dalam Prosiding Konferensi ACM tentang Komputer-Interaksi Manusia

[Link] 294/315
26/2/2021 Tanpa judul
(CHI'98), Los Angeles, CA. ACM Press, hlm. 65–72.
Johnson, J. 2003. Bloopers Web: 60 Kesalahan Umum Desain Web dan Cara
Hindari Mereka . San Francisco: Penerbit Morgan Kaufmann.
Johnson, J., dan Beach, R. 1988. “Gaya dalam Sistem Pengeditan Dokumen.” IEEE
Komputer 21 (1): 32–43.

Halaman 406

392 Bibliografi

Johnson, J., dan Henderson, A. 2002. “Model Konseptual: Mulailah dengan Merancang
Apa yang Harus Didesain. ” Interaksi Jan / Feb: 25–32.
Johnson, J., dan Keavney, M. 1995. “Perbandingan Perangkat Penunjuk Jarak Jauh
untuk Aplikasi TV Interaktif. ” Dalam Koleksi Makalah dari FirstPerson,
Inc . Laporan Teknis SMLI TR-95-41. Mountain View, CA: Sun Microsystems
Laboratorium.
Johnson, J., dan Marshall. CR 2005. “Evaluasi Kegunaan Konvergen:
Studi Kasus dari Proyek EIRS. ” Dalam Prosiding Konferensi ACM
tentang Komputer-Interaksi Manusia (CHI 2005), Portland, OR, ACM Press,
hlm. 1501–1504.
Johnson, J., dan Nardi, B. 1996. “Membuat Slide Presentasi: Studi Pengguna
Preferensi untuk Perangkat Lunak Aplikasi Khusus versus Tugas. ” ACM
Transaksi pada Komputer – Interaksi Manusia 3 (1): 38–65.
Johnson, J., Roberts, T., Verplank, W., Smith, DC, Irby, C., Beard, M., dan
Mackey, K. 1989. “The Xerox Star: A Retrospective.” IEEE Computer , 22 (9),
11–29.
King, A. 2003. Mempercepat Situs Anda: Pengoptimalan Situs Web . Indianapolis: Baru
Penunggang. [Lihat juga [Link]]
Koyani, SJ, Bailey, RW, dan Nall, JR 2006. Desain Web Berbasis Penelitian
& Pedoman Kegunaan . Departemen Kesehatan dan Layanan Kemanusiaan AS,
[Link]
Kraut, R., ed. 1996. "Internet @ Rumah." Bagian Khusus Komunikasi
dari ACM 39 (12): 33–74.
Krug, S. 2005. Jangan Membuat Saya Berpikir: Pendekatan Akal Sehat ke Web
Kegunaan, edisi ke-2. Indianapolis: Penunggang Baru.
Lambert, G. 1984. “Studi Banding Waktu Respon Sistem pada Program
Produktivitas Pengembang. ” IBM Systems Journal 23 (1): 407–423.
Landauer, TK 1995. Masalah dengan Komputer: Kegunaan, Kegunaan, dan
Produktivitas . Cambridge, MA: MIT Press.
Lewis, C., Polson, P., Wharton, C., dan Rieman, J. 1990. “Menguji Panduan
Metodologi untuk Desain Antarmuka Walk-Up-and-Use Berbasis Teori. ” Di
Prosiding Konferensi ACM 1990 tentang Faktor Manusia dalam Komputasi
Sistem (CHI'90) , Seattle, ACM Press, hlm. 235–247.
Lynch, P., dan Horton, S. 2002. Panduan Gaya Web: Prinsip Desain Dasar untuk
Membuat Situs Web . New Haven: Yale University Press. [Lihat juga http: //
[Link]]
Mandel, T. 1997. Elemen Desain Antarmuka Pengguna . New York: John Wiley
dan Sons.
Mayhew, D. 1999. Siklus Hidup Teknik Kegunaan: Buku Pegangan Praktisi
untuk Desain Antarmuka Pengguna . San Francisco: Penerbit Morgan Kaufmann.
McInerney, P., dan Li, J. 2002. “Indikasi Kemajuan: Konsep, Desain, dan
Penerapan." Situs Web IBM Developer Works: [Link]
com / developerworks / web / library / us-progind //.

Halaman 407

Bibliografi 393

[Link] 295/315
26/2/2021 Tanpa judul
Meads, J. 2007. “Kegunaan
Pengelolaan." &ACM
Konferensi Pengembangan Produk: Kursus
tentang Komputer Kegunaan
– Interaksi Manusiauntuk
(CHI'07)
tutorial, San Jose, CA.
Perusahaan Microsoft. 2006. Panduan Pengalaman Pengguna Windows Vista . Di
Web di [Link]
UXGuide / [Link].
Miller, L. 2005. "Studi Kasus Masukan Pelanggan untuk Produk Sukses." Di
Agile 2005 Conference Proceedings, Denver, hlm 225-234.
Miller, L., dan Johnson, J. 1996. “Bintang Xerox: Antarmuka Pengguna yang Berpengaruh
Rancangan." Dalam M. Rudisill, C. Lewis, P. Polson, dan T. McKay, eds., Human–
Desain Antarmuka Komputer: Kisah Sukses, Metode yang Muncul, Dunia Nyata
Konteks . San Francisco: Penerbit Morgan Kaufmann.
Miller, R. 1968. “Waktu Respon dalam Percakapan Manusia-Komputer
Transaksi. " Dalam Prosiding AFIPS Fall Joint Computer Conference, Vol.
33, hlm 267–277 .
Mirel, B. 2004. Desain Interaksi untuk Pemecahan Masalah Kompleks: Mengembangkan
Software yang Berguna dan Dapat Digunakan . San Francisco: Penerbit Morgan Kaufmann.
Muller, MJ, Haslwanter, JH, dan Dayton, T. 1997. “Praktik Partisipatif
dalam Siklus Hidup Perangkat Lunak. ” Di H. Helander, TK Landauer, dan P. Prabhu,
eds., Buku Pegangan Interaksi Manusia-Komputer, edisi ke-2. Amsterdam:
Elsevier Science.
Mullet, K., dan Sano, D. 1995. Merancang Antarmuka Visual: Komunikasi
Teknik Berorientasi . Mountain View, CA: SunSoft Press.
Nardi, B., dan Johnson, J. 1994. “Preferensi Pengguna untuk Tugas-Spesifik vs. Generik
Aplikasi perangkat lunak." Dalam Prosiding Konferensi ACM 1994 tentang
Faktor Manusia dalam Sistem Komputasi (CHI'94), Boston, MA, ACM Press,
hlm. 392–398.
Newman, WM, dan Sproull, RF 1979. Prinsip Komputer Interaktif
Grafik . New York: McGraw – Hill.
Nielsen, J. 1993. Teknik Kegunaan . San Diego: Academic Press.
Nielsen, J. 1999a. “Petunjuk Antarmuka Pengguna untuk Web.” Komunikasi dari
ACM 42 (1): 65–71.
Nielsen, J. 1999b. "'Sepuluh Kesalahan Teratas' Ditinjau Kembali Tiga Tahun Kemudian." Di
Web di [Link]/Alertbox.
Nielsen, J. 1999c. “Sepuluh Kesalahan Baru Desain Web.” Di Web di
[Link]/Alertbox.
Nielsen, J. 1999d. Merancang Kegunaan Web: Praktik Kesederhanaan .
Indianapolis: Penunggang Baru. [Lihat juga [Link]]
Nielsen, J. 2002. “Aplikasi Flash dan Berbasis Web.” [Link], di http: //
[Link]/alertbox/[Link].
Nielsen, J. 2005. “Sepuluh Kesalahan Desain Web Terbaik 2005.” [Link], di
[Link]
Nielsen, J., dan Loranger, H. 2006. Memprioritaskan Kegunaan Web . Indianapolis:
Penunggang Baru.

Halaman 408

394 Bibliografi

Nielsen, J., dan Tahir, M. 2001. Kegunaan Situs Web: Lima Puluh Situs Web Didekonstruksi .
Indianapolis: Penunggang Baru.
Norman, D. 1983. "Aturan Desain Berdasarkan Analisis Kesalahan Manusia."
Komunikasi dari ACM 26 (4): 254–258.
Norman, DA 1988. Desain Hal-Hal Sehari-hari . New York: Buku Dasar.
Norman, DA 1999. Komputer Tak Terlihat . Cambridge, MA: MIT Press.
Norman, DA, dan Draper, SW 1986. Desain Sistem Berpusat Pengguna: Baru
Perspektif tentang Interaksi Manusia-Komputer . Hillsdale, NJ: Lawrence
Erlbaum Associates.
Penzo, M. 2006. "Penempatan Label dalam Formulir." UX Matters . Di Web di http: //
[Link]/MT/archives/[Link].
Perfetti, C. 2005. “iHotelier: Mendemonstrasikan Potensi Flash untuk Aplikasi Web
Rancangan." Rekayasa Antarmuka Pengguna, di Web di [Link]
artikel / potential_of_flash /.
Pirolli, P. L, dan Card, SK 1999. "Informasi Mencari Makan." Review Psikologis
106 (4): 643–675.
Raskin, J. 2000. Antarmuka Manusiawi: Arah Baru untuk Merancang Interaktif
Sistem . Membaca, MA: Addison Wesley.
Redish, G. 2007. Melepaskan Kata-Kata: Menulis untuk Web . San Fransisco:
Morgan Kaufmann Publishers.
Roberts, TL, dan Moran, TP 1983. “Evaluasi Editor Teks:
Metodologi dan Hasil Empiris. ” Komunikasi ACM 26:
265–283.

[Link] 296/315
26/2/2021 Tanpa judul
Robertson, G., untuk
Arsitektur Card, Antarmuka
S., dan Mackinlay,
PenggunaJ. 1989. “The”Cognitive
Interaktif. Co-processor
Dalam Prosiding ACM
Konferensi tentang Perangkat Lunak dan Teknologi Antarmuka Pengguna (UIST'89) . New York:
ACM Press, hlm. 10–18.
Robertson, G., Card, S., dan Mackinlay, J. 1993. “Visualisasi Informasi
Menggunakan Animasi Interaktif 3D. ” Komunikasi ACM 36 (4):
56–71.
Rosenfeld, L., dan Morville, P. 2002. Arsitektur Informasi untuk Dunia
Wide Web, edisi ke-2. Sebastapol, CA: O'Reilly and Associates, 2002.
Rosson, MB, dan Carroll, J. 2001. Teknik Kegunaan: Skenario-Based
Perkembangan Interaksi Komputer Manusia . San Francisco: Morgan
Penerbit Kaufmann.
Rudisill, M., Lewis, C., Polson, P., dan McKay, T. 1996. Manusia-Komputer
Desain Antarmuka: Kisah Sukses, Metode yang Muncul, Konteks Dunia Nyata .
San Francisco: Penerbit Morgan-Kaufmann.
Rushinek, A., dan Rushinek, S. 1986. “Apa yang Membuat Pengguna Senang?”
Komunikasi ACM 29: 584–598.
Schuler, D., dan Namioka, A. 1993. Desain Partisipatif: Prinsip dan
Praktek . Hillsdale, NJ: Lawrence Erlbaum Associates.
Shneiderman, B. 1984. “Waktu Respon dan Tingkat Tampilan dalam Kinerja Manusia
dengan Komputer. ” Survei Komputasi ACM 16 (4): 265-285.

Halaman 409

Bibliografi 395

Shneiderman, B., dan Plaisant, C. 2004. Merancang Antarmuka Pengguna: Strategi

for Effective Human-Computer Interaction, edisi ke-4. Membaca, MA:
Addison Wesley.
Smith, SL, dan Mosier, JN 1986. “Panduan Merancang Antarmuka Pengguna
Perangkat lunak." Laporan Teknis ESD-TR-86-278. Springfield, VA: Nasional
Layanan Informasi Teknis.
Snyder, C. 2003. Pembuatan Prototipe Kertas: Cara Cepat dan Mudah untuk Mendesain dan Memperbaiki
Antarmuka Pengguna . San Francisco: Penerbit Morgan Kaufmann.
Spool, J., Scanlon, T., Schroeder, W., Snyder, C., dan DeAngelo, T. 1999.
Kegunaan Situs Web: Panduan Desainer . San Francisco: Morgan Kaufmann
Penerbit.
Strunk, W., dan White, EB 1999. The Elements of Style, edisi ke-4. New York:
Macmillan Publishing Co.
Sun Microsystems. 2001a. Panduan Desain Tampilan dan Nuansa Java, edisi ke-2.
Membaca, MA: Addison Wesley. [Web: [Link]
ed2 / book / [Link]]
Sun Microsystems. 2001b. Panduan Desain Tampilan dan Nuansa Java: Tingkat Lanjut
Topik . Membaca, MA: Addison Wesley. [Web: [Link]
ucts / jlf / di / book /]
Tesler, L. 1981. "The Smalltalk Environment." Majalah Byte 6 (8): 90–147.
Thadhani, A. 1981. "Produktivitas Pengguna Interaktif." IBM Systems Journal 20 (4):
407–423.
Thimbleby, H. 1982. "Karakter-Level Ambiguitas: Konsekuensi untuk Pengguna-
Desain antarmuka." Jurnal Internasional Studi Manusia-Mesin 16:
211–225.
Tidwell, J. 2005. Merancang Antarmuka: Pola untuk Desain Interaksi yang Efektif .
Sebastapol, CA: O'Reilly and Associates.
Tufte, ER 1990. Membayangkan Informasi . Cheshire, MA: Pers Grafik.
Tufte, ER 2001. Tampilan Visual Informasi Kuantitatif, edisi ke-2.
Cheshire, MA: Pers Grafik.
Ullman, E. 1995. "Out of Time: Reflections on the Programming Life."
Dalam J. Brook dan IA Boal, eds., Menolak Kehidupan Virtual: Budaya dan
Politik Informasi . San Francisco: City Lights Books, hlm. 131–144.
Van Duyne, DK, Landay, JA, dan Hong, JI 2002. Desain Situs:
Pola, Prinsip, dan Proses untuk Membuat Web yang Berpusat pada Pelanggan
Pengalaman . Boston: Addison Wesley.
Wharton, C., Rieman, J., Lewis, C., dan Polson, P. 1994. “Kognitif
Panduan: Panduan Praktisi. ” Dalam J. Nielsen dan RL Mack, eds.,
Metode Pemeriksaan Kegunaan . New York: John Wiley and Sons.
Wolfmaier, T. 1999. “Designing for the Color-Challenged: A Challenge.” ITG
Publikasi 2.1. Di Web di [Link]
mar99 / Accessibility_color_challenged.html.
Zarmer, C., dan Johnson, J. 1990. “Alat Antarmuka Pengguna: Dulu, Sekarang, dan
Tren masa depan." Laporan Teknis Laboratorium HP HPL-90-20.

[Link] 297/315
26/2/2021 Tanpa judul

Halaman 410

Halaman ini sengaja dikosongkan

Halaman 411

Indeks

[Link] 298/315
26/2/2021 Tanpa judul
SEBUAH kontrol kotak dialog, 208–211 disalahgunakan sebagai radio
Metode Agile / XP, 341–342, mengganggu jalur keluar, tombol, 55–56
354–355 122–126 saling eksklusif, 56–58
penjajaran tidak ada link kembali, 123 negatif, 105–106
keselarasan, 226–228 posisi yang buruk gunakan untuk non-ON / OFF
bentuk, 223–224 promosi, 123–125 pengaturan, 62–65
ambiguitas, 38 tidak aktif, 282 jendela anak, 230
Ambler, Scott, 354 label, ambigu, 38 pilihan
animasi Oke, 284–285, 287 false, 261–264
untuk inersia tampilan, 281 radio, 53–62 menebak, 258–259, 264
interframe maksimum memilih toolkit, 62 tidak ada perbedaan antara,
interval, 305 menyalahgunakan kotak centang 258, 263
menggunakan sebagai petunjuknya, 207 sebagai, 55–56 jawaban yang jelas, 259–261,
aplikasi tanpa nilai awal, 264
kompleks, pengembangan, 98–99, 101–102 tidak ada gunanya, 258–264
359–360 lajang, 54–55 warna, menyoroti informasi
ditentukan, 373 terlalu berjauhan, 217–220 dengan, 205
Javascript asinkron dan menggunakan tab sebagai, 67-70 tombol perintah, menyalahgunakan sebagai
XML (AJAX), 47 saat menunya toggles, 65–67
otentikasi, 264-267 lebih baik, 102 label perintah, penggunaan…
password, 264–265 tidak responsif, 298 (elipsis) aktif, 193–196
pertanyaan keamanan, kontrol jendela, 210 perintah yang terbuka
265–266 windows, 195–196
terminologi, 190 C konvensi, 194, 196
ketersediaan produk atau Tombol batal, 282, 288–291, label tombol grafis, 196
layanan, 264 296–297 menghilangkan, 194
membatalkan kotak dialog penggunaan berlebihan, 195
B bertingkat, 289 perintah, memungkinkan untuk mengatur
bagian belakang, 373 yang menampilkan salinan judul, 121
Bickford, Peter, 45, 304, 368 pengaturan aplikasi, kompleksitas, versus kegunaan,
remah roti, 128–131 289–290 30–32
singkatnya, versus kejelasan, 171–173 aplikasi edit itu dokumen gabungan
Brooks, Fred, 343 data, 288 aplikasi, 92
indikator sibuk, 298, 311–312 mengubah antara tab komputer, 370–372
tombol panel, 288 biaya, 370–371
Batal, 288–291 alasan, 290–291 Koneksi internet,
mengubah antara tab efek samping penyihir, 289 371–372
panel, 288 Kartu, Stuart, 322 pembenaran, 370
kotak dialog, 288–290 menu berjenjang, dalam dialog pengujian di Internet yang lambat
alasan, 290–291 kotak, 138 koneksi, 372
efek samping penyihir, 289 kotak centang, 53–62 menguji lebih lambat
perintah, 65–67 Lihat juga bidang input / kontrol komputer, 372
kontrol konten, 208–211 memilih toolkit, 62 meningkatkan, 372

397

Halaman 412

398 Indeks

model konseptual, 19–26, 373 memilih toolkit, 62 persyaratan pengalaman,

mendasarkan desain pada, 24-25 lajang, 54–55 343
dasar mental pengguna menggunakan kotak centang sebagai, 55–56 grafis, 340–341
model, 246 tab sebagai manajer, 357
manfaat, 26 terlalu banyak, 70–76 versus programmer, 338–340
didefinisikan, 19-20 gunakan sebagai tombol radio, versus alat, 369–370
untuk mengembangkan produk 67–70 mendesain
leksikon, 158 bidang teks, 84–88 untuk menerima detail pesan kesalahan
desain fokus tidak responsif, 367 pada saat runtime, 189
proses, 25–26 Cooper, Alan, 34, 348 untuk mengakomodasi font yang lebih besar
lexicons, 23–24 kursor ukuran, 236
analisis objek / tindakan, gerakan otomatis, untuk kasus umum, 32–33
21–25 43–44 untuk daya tanggap, 48
contoh, 21–22 dan kesalahan, peringatan, dan aplikasi desktop
hubungan objek, 22–23 dialog konfirmasi font kecil, 233–234
mempromosikan pembangunan, kotak, 231 judul tidak cocok dengan perintah /
25 ditentukan, 157 tautan, 117–118
fokus tugas, 20-21 posisi sebagai indikator pengguna jendela tak dikenal,
skenario tugas, 24 fokus, 204 108–112
objek konseptual, 373 warping, 43 teks yang berpusat pada pengembang, 173–189
Pohon Kerucut, 322 memanggil pelanggan "pengguna",
konsistensi, 39–41 D 181–183
keuntungan, 40–41 bidang data berbicara Geek, 173–180
menghindari gangguan, 39 tidak toleran, 94–96 pesan kesalahan yang tidak jelas,
kerugiannya, 39–40 label terlalu jauh dari, 220–225 184–189
berpusat pada pengguna, 41 lebih dekat ke yang lain proses pengembangan, 348-357
Constantine, Larry, 354–355 pengaturan daripada milik mereka sendiri, pelanggan, 349–353
tombol kontrol konten, pencampuran 222–223, 225 desain, 349–350
dengan kontrol kotak dialog mendikte penyelarasan desainer sebagai manajer, 357
tombol, 208–211 formulir, 223–224 inkonsistensi, 348–349
kontrol, 51–106 label di atas bidang, 225 investasi dalam kualitas, 356-357
Lihat juga bidang masukan / kontrol; berlawanan ekstrim, 221–223 mempertahankan kendali, 349
widget default pengawasan, 351–353
kotak centang, 53–62 memilih nilai-nilai yang masuk akal, penerbitan dan media
memilih toolkit, 62 53–54 bisnis, 355–356
menyalahgunakan sebagai tombol radio, bidang masukan / kontrol tanpa, tanggung jawab, 357
55–56 96–102 standar / pedoman, 350–351

[Link] 299/315
26/2/2021 Tanpa judul
saling eksklusif, 56–58 menu dropdown, 99–100, desain yang berpusat pada pengguna (UCD)
negatif, 105–106 102 versus Agile / XP,
gunakan untuk non-ON / OFF set- bidang nomor, 97–98, 101 354–355
tings, 62–65 tombol radio, 98–99, kotak dialog, 373
tombol perintah, penyalahgunaan 101–102 untuk membatalkan, 283
sebagai matikan, 65–67 alasan untuk menghilangkan, 97 tombol kontrol, pencampuran dengan
bidang data, 94–96 bidang teks, 97–98, 101 kontrol konten
menu dinamis, 89–93 miskin, 103–105 tombol, 208–211
bidang masukan / kontrol menyampaikan informasi, 41–45 menampilkan, 136
tanpa default, 96–102 tampilan inersia, 44–45 hierarki, 133–134
gunakan untuk data hanya-tampilan, desain tampilan profesional, modal, 271–272, 275
77–84 42–43 bertingkat, 289
bergerak, 279–280 kontrol pengguna, 43–44 modal orang tua, 271
ikhtisar, 52–53 desainer, 340–341 pengujian, 287
default yang buruk, 103–105 didedikasikan untuk spesialis yang menampilkan salinan aplikasi-
tombol radio, 53–62 aplikasi, 364 pengaturan tion, 289–290

Halaman 413

Indeks 399

yang mengedit data aplikasi, 288 memantau kepatuhan waktu, bidang

yang menjebak pengguna, 281–287 321–322 data
semua jalan salah, 282 memprediksi waktu penyelesaian, tidak toleran, 94–96
membandingkan opsi dengan 322–324 label terlalu jauh dari,
gol, 287 memprediksi kepatuhan waktu, 220–225
contoh, 285–286 324–325 memasukkan
tidak ada "Batal", 282 tanpa default, 96–102
Tombol OK, 284–285, 287 E gunakan untuk data hanya-tampilan,
tombol yang diperlukan elipsis (…), gunakan atas perintah 77–84
tidak aktif, 282 label, 193–196 tidak dapat diedit, 78–80
pengujian, 287 perintah yang terbuka nomor, 97–98, 101
pilihan tidak jelas, 282–284 windows, 195–196 teks
terlalu banyak level, 131–138 label tombol grafis, 196 tanpa default, 97–98, 101
jendela charting menghilangkan, 194 tidak dapat diedit, 78
hierarki, 137 penggunaan berlebihan, 195 terlalu banyak digunakan untuk dibatasi
contoh, 132–135 sebagai standar, 194, 196 masukan, 84–88
batas dua tingkat, 136–137 pesan kesalahan ramah pengguna, 95–96
cara memotong kelebihan, merancang untuk menerima detail di Flanders, Vincent, 236
137–138 runtime, 189 kelompok fokus, 374
menggunakan sebagai petunjuknya, 205 tipe yang berbeda, 189 ukuran font, 232–238
menggunakan menu berjenjang, 138 ditampilkan oleh kode tingkat rendah, kontrol di Web, 236
diksi, 166–168 184–185 merancang untuk mengakomodasi
kamus, 375 diekspresikan dalam bentuk lebih besar, 236
tampilkan inersia, 44–45, 281, 374 tugas, 187 di aplikasi desktop,
menampilkan komponen generik, 233–234
pengaturan ulang otomatis, 185–186 alasan, 234
277–281 miskin dan membaik, 188 faktor yang mempengaruhi, 235
kontrol bergerak, 279–280 masalah, 184 layar resolusi tinggi, 235
melestarikan tampilan alasan tidak diberikan kepada yang lebih tinggi membiarkan pengguna menyesuaikan,
inersia, 281 kode level, 185 235–236
mengatur ulang data, 278–279 kekurangan perangkat lunak, 192 minimal, 235
kontrol pengguna dari menyarankan solusi, 187–188 menguji pengguna, 236–238
layar, 281 menerjemahkan untuk pengguna, 189 formulir, label mendikte
resolusi tinggi, 235 Windows Media Player untuk penyelarasan, 223–224
mode operasi, 277 Mac, 187 fungsionalitas, 18–26
desain profesional, 42-43 antrian acara, pemantauan, 321 model konseptual, 19–26
gangguan, 35-37 tingkat pengalaman pengguna, 10–11 mendasarkan desain pada, 24-25
menghindari melalui Pemrograman Ekstrim (XP) didefinisikan, 19-20
konsistensi, 39 metode, 341–342, proses desain fokus,
masalah ekstra, 36 354–355 25–26
proses eliminasi, lexicons, 23–24
36–37 F analisis objek / tindakan,
menu dropdown, dengan no umpan balik, 310–316 21–23, 25
default, 99–100, 102 mengakui masukan pengguna, fokus tugas, 20-21
pekerjaan depan bodoh, 318 310–311 skenario tugas, 24
menu dinamis, 89–93 indikator sibuk, 311–312 ikhtisar, 18–19
menambah / menghapus menu, 93 menampilkan informasi penting-
daftar pilihan cepat, 93 tion pertama, 314–315 G
aplikasi mana yang seharusnya navigasi yang tidak memadai, Geek ("bahasa"), 173–180
miliki, 91–92 367–368 mengembangkan leksikon produk,
manajemen waktu yang dinamis, indikator kemajuan, 312–314 179–180
320–325, 326 disimulasikan, 315–316 mengenal pengguna, 179
memantau antrian acara, 321 di Web, 316 Nama komponen GUI, 180

Halaman 414
[Link] 300/315
26/2/2021 Tanpa judul

400 Indeks

Geek ("bahasa") (lanjutan) label kontrol pengguna, 43–44

jargon programmer, 173–178 inkonsistensi penyelarasan, mudah terlewat, 198–208
mengubah kata kerja menjadi kata benda, 226–228 terkubur dalam “kebisingan”, 201–204
178–179 terlalu jauh dari bidang data, warna, 205
pesan kesalahan umum, 186 220–225 membangun hierar visual-
glass teletype (TTY) pengguna kotak dialog pencampuran dan cabai, 204
antarmuka, 85–86 tombol kontrol konten, tampilan data yang tidak berguna,
glosarium, 373–376 208–211 207–208
tata bahasa, 166–168 ikhtisar, 198 memusatkan perhatian,
desain grafis, 197–238 tombol radio terlalu jauh, 199–200
warna, WA1– 11 (mengacu pada "WA" 217–220 faktor manusia, 198–199
ke Apendiks Web di penempatan jendela, lokasi, 200–201, 204
[Link] ) 228–232 membuat informasi menjadi tidak mungkin
latar belakang vs. latar depan, pertimbangan jenis sible to ignore, 205–207
WA1-3 jendela, 231 ukuran, 200, 204
pilihan, WA3-8 menentukan posisi, 231 tujuan informasi dari kegunaan
buta warna, WA7, 10 menampilkan semua pada coor- yang sama pengujian, 49
kontras, WA2-5, 10 dinates, 228–229 bidang masukan / kontrol
ukuran font, 232–238 menampilkan bawahan Lihat juga kotak centang; radio
kontrol di Web, 236 di tengah orang tua, tombol; bidang teks
merancang untuk mengakomodasi 229–230 tanpa default, 96–102
lebih besar, 236 menampilkan bawahan menu dropdown, 99–100,
di aplikasi desktop, off-screen, 230–231 102
233–234 heuristik umum, 232 bidang nomor, 97–98, 101
alasan, 234 kotak kelompok, 212–217 tombol radio, 98–99,
faktor yang mempengaruhi, 235 seputar segala sesuatu di 101–102
resolusi tinggi window, 214–215 alasan untuk menghilangkan, 97
menampilkan, 235 di sekitar pengaturan tunggal, bidang teks, 97–98, 101
membiarkan pengguna menyesuaikan, 235–236 212–213 gunakan untuk data hanya-tampilan,
minimal, 235 dalam kotak grup, 213–214 77–84
menguji pengguna, 236–238 Label, 216 bidang teks yang tidak dapat diedit, 78
kotak kelompok, 212–217 untuk tombol radio, 216 alasan, 78–80
seputar segala sesuatu di Kontrol Teks Statis, 216 menggulir kotak teks,
window, 214–215 82–84
di sekitar pengaturan tunggal, H. pendekatan dari dalam ke desain,
212–213 blooper pintu helikopter, 267–268 37–39, 374
dalam kotak kelompok, evaluasi heuristik, 374 instruksi
213–214 hierarki, visual, 204 panjang, 267–269
informasi mudah terlewat, layar resolusi tinggi, 235 verbose, 169–170
198–208 halaman rumah, banyak, interaksi, 239-291
terkubur dalam “kebisingan”, 201–204 127–128 menyimpang dari fokus tugas,
warna, 205 241–249
membangun hierar visual- saya konsep yang membingungkan,
cabai, 204 identifikasi, 264–267 246–249
tampilan data yang tidak berguna, password, 264–265 mengekspos implementasi
207–208 pertanyaan keamanan, 265–266 kepada pengguna, 241–242
memusatkan perhatian, terminologi yang tidak konsisten, batasan yang tidak perlu,
199–200 154, 157 242–246
faktor manusia, 198–199 informasi ikhtisar, 240
lokasi, 200–201, 204 pengiriman, 41–45 langkah yang tidak perlu, 250–264
membuat informasi menjadi tidak mungkin tampilan inersia, 44–45 meminta pengguna untuk tidak-
sible to ignore, 205–207 tampilan profesional nilai benih esensial,
ukuran, 200, 204 desain, 42–43 256–258

Halaman 415

Indeks 401

meminta pengguna untuk tidak dibutuhkan verbose, 169–170 menampilkan semua pada coor- yang sama
data, 250–256 layout, 197–238 dinates, 228–229
pilihan yang tidak berguna, 258–264 ukuran font, 232–238 menampilkan bawahan
kontrol pengguna, 277–291 kontrol di Web, 236 di tengah orang tua,
pengaturan ulang otomatis merancang untuk mengakomodasi 229–230
dari tampilan, 277–281 lebih besar, 236 menampilkan bawahan
Tombol batal, 288–291 di aplikasi desktop, off-screen, 230–231
kotak dialog, 281–287 233–234 heuristik umum, 232
memori pengguna, 264–277 alasan, 234 belajar
identifikasi otorisasi- faktor yang mempengaruhi, 235 fasilitasi, 37–41
tion, 264–267 resolusi tinggi konsistensi, 39–41
instruksi panjang, 267–269 menampilkan, 235 lingkungan berisiko rendah, 41
mode, 269-277 membiarkan pengguna menyesuaikan, pendekatan luar-dalam,
antarmuka, waktu nyata, 304–306 235–236 37–39
Internet minimal, 235 perjanjian hukum, 80–84
situs Web pendamping untuk memesan, menguji pengguna, 236–238 lexicons, 23–24, 29
5–6 kotak kelompok, 212–217 menciptakan, 158
koneksi, 371–372 seputar segala sesuatu di win- berkembang berdasarkan pengguna
pengujian lambat, 372 dow, 214–215 vocabulary, 179–180

[Link] 301/315
26/2/2021 Tanpa judul
desain berulang, 341–347 di sekitar pengaturan tunggal, menegakkan, 159–160
Metode Agile / XP, 341–342 212–213 pengujian, 160
memberikan waktu untuk pengujian, dalam kotak kelompok, tautan
345–346 213–214 mengganggu jalur keluar, 122–126
desainer penilaian, 347 informasi mudah terlewat, tidak ada link kembali, 123
mengabaikan hasil, 347 198–208 promo-
butuhkan untuk, 342–344 terkubur dalam "kebisingan", tions, 123–125
peserta tes, 346-347 201–204 label, 126
warna, 205 lengthy, 170–171
J membangun hierar visual- tautan-diri, 126–131
jargon. See Geek ("bahasa") cabai, 204 beberapa halaman rumah,
Jarrett, Caroline, 158 tampilan data yang tidak berguna, 127–128
207–208 di bilah navigasi, 127,
K memusatkan perhatian, 130
Krug, Steve, 171 199–200 di remah roti navigasi,
faktor manusia, 198–199 128–129, 130–131
L lokasi, 200–201, 204 lokasi informasi, 200–201,
label membuat informasi menjadi tidak mungkin 204
dalam kotak kelompok, 216 sible to ignore, 205–207 kode tingkat rendah, pesan kesalahan
keselarasan tidak konsisten, ukuran, 200, 204 masalah, 184
226–228 label
rata kiri, 228 inkonsistensi penyelarasan, M
tautan, 126 226–228 manajemen, 329-372
perataan kanan, 228 terlalu jauh dari bidang data, attitude, 331–347
terlalu jauh dari bidang data, 220–225 desain berulang, 341–347
220–225 mencampur kotak dialog dan konten kesalahpahaman pengguna
lebih dekat ke set lain- tombol kontrol, 208–211 profesional antarmuka,
lebih dari milik mereka sendiri, ikhtisar, 198 337–341
222–223, 225 tombol radio terlalu jauh, prioritization, 331–337
mendikte penyelarasan 217–220 pengujian, 341–347
formulir, 223–224 penempatan jendela, 228–232 ikhtisar, 330–331
label di atas bidang, 225 pertimbangan jenis proses, 348–372
ekstrim berlawanan, jendela, 231 perkembangan anarkis,
221–223 menentukan posisi, 231 348–357

Halaman 416

402 Indeks

manajemen (lanjutan) pesan yang salah, 189–192 terlalu banyak level dialog
memberikan programmer penyalahgunaan / non-penggunaan… kotak, 131–138
komputer tercepat, (elipsis), 193–196 tidak menunjukkan kepada pengguna di mana mereka
370–372 teks masuk akal dalam isolasi adalah, 108–121
alat yang buruk, 365–370 tetapi tidak di GUI, 193 halaman tidak teridentifikasi,
keahlian tugas, 357-364 kotak dialog modal, 271-272, 275 108–112
Meads, Jon, 355 penunjuk atau indikator mode, 277 judul yang sama berbeda
model mental, 246 antarmuka pengguna grafis yang dimodifikasi windows, 112–117
menu (GUI), 270–271 judul jendela tidak cocok
dropdown, 99–100, 102 mode, 269–277, 374 perintah atau tautan,
dinamis, 89–93 keuntungan dari, 276 117–121
menambahkan / menghapus menu, bernama buruk, 273–274 jendela tidak teridentifikasi,
93 ditentukan, 270 108–112
daftar pilihan cepat, 93 sulit untuk dihindari, 276 ikhtisar, 108
aplikasi mana yang seharusnya sulit untuk dilewatkan, 277 navigasi pencarian yang buruk,
miliki, 91–92 kerugian dari, 276–277 138–150
menubar, 92 berdampak pada kegunaan, 274 bersaing kotak telusur,
non-dinamis, 92 indikator, 277 139–143
operasi, 367 kotak dialog modal, 271-272, hasil pencarian yang berisik,
tabel, 93 275 145–150
ketika lebih baik dari radio antar-pengguna grafis yang dimodifikasi hasil pencarian yang buruk
tombol, 102 wajah (GUI), 270–271 browsing, 143–145
file pesan menghapus pengaturan mode, bilah navigasi, 127, 130
menghindari judul yang sama di 274–275 Nielsen, Jakob, 108, 130, 193
jendela berbeda, 116 di pemanggang roti, 273 kebisingan
duplikat string teks, 161 tindakan pengguna, 272–273, 275 Lihat juga suara, menggunakan sebagai
membina konsisten pemantauan petunjuknya
terminologi, 160–161 antrian acara, 321 mengubur informasi di,
menerjemahkan teks program, 161 kepatuhan waktu, 321-322 201–204
pesan respon mouse, hasil pencarian, 145–150
keliru, 189–192 memaksimalkan, 320 tata nama, 375
kesalahan, 184–189 kontrol bergerak, 279 menu non-dinamis, 92
mendesain untuk menerima detail kotak dialog bertingkat, 289 teks nontabular, 207
pada saat runtime, 189 kata benda, mengubah kata kerja menjadi, 178–179
tipe yang berbeda, 189 N bidang angka, tanpa default,
ditampilkan oleh level rendah penamaan 97–98, 101
kode, 184–185 Konsep, 158–165 angka, acak, 256
diekspresikan dalam bentuk konsistensi dan inkonsistensi,
tugas, 187 159–161 HAI
komponen generik, mode, 273–274 hubungan objek, 23
185–186 kealamian, 27–29 analisis objek / tindakan, 21,
alasan tidak diberikan kepada yang lebih tinggi pembatasan sewenang-wenang, 28-29 374–375, 381–383
kode level, 185 contoh, 27–28 contoh, 21–22
menyarankan solusi, tindakan tidak wajar, 27 hubungan objek, 22–23
187–188 navigasi, 107–150 mempromosikan pembangunan, 25
menerjemahkan untuk pengguna, 189 remah roti, 128–131 Tombol OK, 284–285, 287

[Link] 302/315
26/2/2021 Tanpa judul
Windows Media Player untuk menyesatkan pengguna, pendekatan luar ke dalam
Mac, 187 122–138 desain, 37–39
metafora, 374 mengganggu jalur keluar label tombol ambigu, 38
Miller, Lynn, 355 tombol, 122–126 ambiguitas grafis, 38
teks menyesatkan, 189–196 mengganggu link off-path, vs. dalam ke luar, 374
istilah ambigu, 158, 122–126 ambiguitas tekstual, 38
161–162 tautan-diri, 126–131 istilah overloading, 154

Halaman 417

Indeks 403

P. Lihat juga bidang input / kontrol manajemen waktu yang dinamis,

halaman, tidak diidentifikasi, 108–112 memilih toolkit, 62 320–325
solusi masalah paralel, 326 dalam kotak kelompok, 216 acara pemantauan
jendela orang tua, 230 tanpa nilai awal, 98–99, antrian, 321
pengurai, 84 101–102 waktu pemantauan
password, 264–265 lajang, 54–55 kepatuhan, 321–322
kinerja, versus responsif- terlalu berjauhan, 217–220 memprediksi waktu penyelesaian,
ness, 300, 303–304 menggunakan kotak centang sebagai, 55–56 322–324
personas, 12, 375 menggunakan pemisah, 219 memprediksi kepatuhan waktu-
pop up, 205 menggunakan tab sebagai, 67-70 ance, 324–325
kekuasaan, versus kompleksitas, 30-32 permisi, 68 mouse, memaksimalkan, 320
PowerBuilder, 64–65 pengungkapan progresif, ikhtisar, 294
memprediksi 68–69 metode pemrosesan paralel,
waktu penyelesaian, 322–324 saat menunya 317–318
kepatuhan waktu, 324–325 lebih baik, 102 menunda tidak penting
presentasi, versus nomor acak, 256 kerja, 317
fungsionalitas, 18–26 tenggat waktu waktu nyata, 302–303 bekerja di depan
jendela utama, 375 menghapus pengguna, 318
corong proses, 125 menu dinamis, 93 optimasi antrian, 319–320
produk lexicons, 375 pengaturan mode, 274–275 pembilasan tugas diperdebatkan,
profil, 12 persyaratan, 8–26 319–320
programmer model konseptual, 19-25 masukan nonsequential
versus desainer, 338–340 metode, 19-25 pemrosesan, 319
memberikan komputer tercepat untuk, perlu membangun sebelumnya alasan untuk, 298–303
370–372 Desain UI, 18–19 pertimbangan selama
biaya, 370–371 analisis tugas, 21 desain, 299–300
Koneksi internet, responsiveness, 45–48, ketidaktahuan pengembang, 298
371–372 293–327, 375 disamakan dengan
pembenaran, 370 umum, 294–298 kinerja, 300
pengujian di Internet yang lambat tidak ada indikator sibuk, 298 alat yang tidak memadai,
koneksi, 372 tidak ada bilah kemajuan, 302–303
menguji lebih lambat 296, 298 implementasi sederhana,
komputer, 372 tidak ada cara untuk membatalkan, 301–302
meningkatkan, 372 296–297 memperlakukan masukan pengguna seperti
jargon dari, 173–178 bilah kemajuan palsu, masukan mesin,
membuat keputusan bisnis dengan 296 301
default, 353 komunikasi yang buruk, pemrogram tidak terampil,
tidak terampil, 303 295 303
bilah kemajuan, 296 tidak responsif teknik, 326
indikator kemajuan, 298, 312–314 tombol, 298 konstanta waktu, 305–306
pengungkapan progresif, 68-69, didefinisikan, 46–47 umpan balik tepat waktu, 310–316
375 prinsip desain, 303–309 mengakui masukan pengguna,
promosi, posisi yang buruk, penundaan, 306–307 310–311
123–125 faktor manusia, 309 indikator sibuk, 311–312
prompt atau pesan, 205, 207 sumber daya terbatas, 304 menampilkan informasi penting
tanda baca, 166–168 urutan tugas, 307 kawin dulu, 314–315
antarmuka waktu nyata, indikator kemajuan, 312,
Q 304–306 313–314
optimasi antrian, 319–320, 326 responsivitas versus umpan balik simulasi,
daftar pilihan cepat, 93 kinerja, 303–304 315–316
operasi yang tidak perlu, di Web, 316
R 307–308 di Web, 47
tombol radio, 53–62 mendesain untuk, 48 link kembali, 123

Halaman 418

404 Indeks

[Link] 303/315
26/2/2021 Tanpa judul
S mengubah antara tab terminologi
desain layar, 42–43 panel, 288 tidak konsisten, 153–161
scrollbar, 299 sebagai kontrol navigasi, 69 membuat leksikon produk,
menggulir kotak teks, 82–84 kontrol panel tab, 67 158
navigasi pencarian, 138–150 terlalu banyak, 70–76 istilah yang berbeda untuk yang sama
bersaing kotak telusur, singkatan label, 71–72 konsep, 153–154
139–143 beberapa baris, 72–73 menegakkan leksikon,
hasil pencarian berisik, 145–150 di beberapa tepi panel, 159–160
hasil penelusuran yang buruk menjelajah, 70–71 istilah standar industri untuk
143–145 ruang terbuang, 70 konsep umum, 159
Hasil Pencarian digunakan sebagai tombol radio, 67–70 mendaftar semua istilah, 153
berisik, 145–150 analisis tugas file pesan, 160–161
browsing yang buruk, 143–145 kelompok fokus, 14 satu nama per konsep, 158
jendela kedua, 375 metode, 13–15, 21–22, istilah yang sama untuk berbeda
pertanyaan keamanan, 265–266 379–381 konsep, 154–157
nilai benih, tidak perlu, tugas, 12–16 testing lexicons, 160
256–258 umum, 32–35 tidak jelas, 161–165
game, 257–258 skenario inti versus pinggiran- istilah ambigu, 161–162,
hanya memberikan kendali, 257 ios, 34–35 164
interval variabel, 257 kemudahan pencapaian, 32-33 konsep terlalu mirip, 163
tautan-diri, 126–131 frekuensi penggunaan, 33-34 tumpang tindih artinya,
beberapa halaman rumah, 127–128 jumlah pengguna, 33–34 162–163
di bilah navigasi, 127, 130 model konseptual terfokus sinonim, 164
di remah roti navigasi, pada, 20–21 pengujian terminologi pada
128–129, 130–131 memutuskan mana yang akan didukung, pengguna, 164–165
ukuran, teks, 200, 204, 232–238 12–13 testing, 341–347, 383–388
kontrol di Web, 236 menyimpang dari fokus, 241–249 Metode Agile / XP, 341–342
merancang untuk mengakomodasi konsep yang membingungkan, memberikan waktu untuk, 345–346
lebih besar, 236 246–249 anggaran, 346, 387–388
di aplikasi desktop, mengekspos implementasi tahap pengembangan, 346
233–234 kepada pengguna, 241–242 kotak dialog, 287
alasan, 234 batasan yang tidak perlu, ukuran font pada pengguna, 236–238
faktor yang mempengaruhi, 235 242–246 formalitas, 384-385
layar resolusi tinggi, 235 pesan kesalahan diekspresikan dalam desainer penilaian, 347
membiarkan pengguna menyesuaikan, 235–236 persyaratan, 187 mengabaikan hasil, 347
minimal, 235 keahlian, 335–336, 357–364 tahap implementasi,
menguji pengguna, 236–238 desainer berdedikasi, 364 383–384
kerja cerdas ke depan, 318 pengembang dengan asumsi mereka lexicons, 160
tujuan sosial dari pengujian kegunaan, adalah ahlinya, 358 sebagai kemewahan, 344–345
49–50 pengguna diskon, 359–360, butuhkan untuk, 342–344
aplikasi perangkat lunak, didefinisikan, 373 362–364 peserta, 346–347
perjanjian lisensi perangkat lunak, ahli ganda, 364 pra-pengembangan, 385–387
83–84 mengimpor, 360–362 pada koneksi internet yang lambat,
terdengar, menggunakan sebagai petunjuknya, 207 hambatan bagi pengguna melibatkan- 372
ejaan, 166–168, 169 ment, 364 pada komputer yang lebih lambat, 372
Kontrol Teks Statis, 216 investigasi dimaksudkan, teks, 151–196
PowerBuilder Sybase, 63, 64–65 13–14 ambiguitas, 38
sinonim, 164 belajar tentang, 15 pengembang-sentris, 173–189
diperdebatkan, 319–320 memanggil pelanggan "pengguna",
T urutan, 307 181–183
menu tabel, 93 skenario, 24 berbicara Geek, 173–180
tab technobabble, 29 pesan kesalahan yang tidak jelas,
menyingkat, 71 visi terowongan teknosentris, 16 184–189

Halaman 419

Indeks 405

menyesatkan, 189–196 memungkinkan perintah untuk diatur kejutan, 48–49

pesan yang salah, judul, 121 kebijakan penggunaan, 83
189–192 penyebab umum, 118 analisis pengguna, 375
penyalahgunaan / non-penggunaan… di aplikasi desktop, desain yang berpusat pada pengguna (UCD),
(elipsis), 193–196 117–118 354–355
penyalahgunaan / non-penggunaan… di Web, 118–120 pengguna, 9–12, 198–199
(elipsis), 184–189 bila sesuai, 120–121 kemampuan beradaptasi, 334
teks masuk akal di isola- sama di jendela yang berbeda, meminta benih yang tidak perlu
yang berbeda tetapi tidak di GUI, 193 112–117 nilai, 256–258
nontabular, 207 ketidaktahuan duplikat game, 257–258
ikhtisar, 152 judul, 114–115 hanya memberikan kendali, 257
ukuran, 235 file pesan, 116 interval variabel, 257
string, digandakan, 161 hanya nama aplikasi meminta data yang tidak dibutuhkan,
teks tidak komunikatif, ditampilkan, 112–113 250–256
152–173 kasus khusus, 116–117 data opsional, 253
tulisan buruk, 165–169 keunikan judul, 116 entri berulang, 250
terminologi yang tidak konsisten, judul yang belum diedit pada disalin login berulang, 253–254
153–161 kode, 113–114 pertanyaan yang tidak perlu,
terlalu banyak teks, 169–173 ketika judul yang sama cocok untuk keduanya, 250–252
terminologi yang tidak jelas, 115 membebani memori,
161–165 mode pemanggang roti, 273 264–277
kotak teks, bergulir, 82–84 toggles, 54, 65–67 otorisasi
bidang teks tipe hierarki, 23 identifikasi, 264–267
Lihat juga bidang input / kontrol typography, 232–238 instruksi panjang, 267–269
tanpa default, 97–98, 101 mode, 269-277
bidang teks (lanjutan) U mengubah mode, 272-273
tidak dapat diedit, 78 Ullman, Ellen, 335–336 karakteristik, 10
terlalu banyak digunakan untuk dibatasi teks tidak komunikatif, konsistensi, 41

[Link] 304/315
26/2/2021 Tanpa judul
masukan, 84–88 152–173 kendali layar, 43–44, 281
alternatif, 86–88 tulisan buruk, 165–169 memutuskan siapa mereka, 10
alasan, 84–85 terminologi yang tidak konsisten, gangguan, 35-37
Konversi TTY-ke-GUI, 153–161 masalah ekstra, 36
85–86 terlalu banyak teks, 169–173 proses eliminasi,
titik penyisipan teks, 157 terminologi yang tidak jelas, 161–165 36–37
“Jempol ke bawah” / “jempol ke atas” pengujian kegunaan, 48–50, 341–347, pengalaman, 10–11, 362–364
simbol, 3 368–369, 383–388 mengekspos implementasi untuk,
kepatuhan waktu Metode Agile / XP, 341–342 241–242
pemantauan, 321-322 memberikan waktu untuk, 49, 345–346 kenyamanan, 242
memprediksi, 324–325 anggaran, 346, 387–388 memfokuskan antarmuka pengguna
konstanta waktu, 304–306 tahap pengembangan, 346 tugas, 242
manajemen waktu, dinamis, formalitas, 50, 384–385 memusatkan perhatian dari,
320–325 gol, 49–50 199–200
memantau antrian acara, 321 desainer penilaian, 347 ukuran huruf
memantau kepatuhan waktu, mengabaikan hasil, 347 membiarkan menyesuaikan, 235–236
321–322 tahap implementasi, 50, menguji, 236–238
memprediksi waktu penyelesaian, 383–384 mengetahui, 179
322–324 sebagai kemewahan, 344–345 memasukkan
memprediksi kepatuhan waktu, butuhkan untuk, 342–344 mengakui, 310–311
324–325 peserta, 346–347 memperlakukan seperti mesin
umpan balik tepat waktu, 326 pra-pengembangan, 385–387 masukan, 301, 309
judul di Internet yang lambat menyesatkan, 122–138
tidak cocok dengan perintah / koneksi, 372 mengganggu jalur keluar
link, 117–121 pada komputer yang lebih lambat, 372 tombol, 122–126

Halaman 420

406 Indeks

pengguna (lanjutan) getaran, menggunakan sebagai petunjuknya, 207 kasus khusus, 116–117
mengganggu link off-path, hierarki visual, 204, 376 keunikan judul, 116
122–126 kosakata, 29, 375 judul yang belum diedit pada disalin
tautan-diri, 126–131 kode, 113–114
terlalu banyak level dialog W ketika judul yang sama cocok untuk keduanya,
kotak, 131–138 Web 115
belajar tentang, 11 situs pendamping untuk memesan, 5–6 sekunder, 375
tidak menunjukkan di mana mereka berada, kontrol ukuran font pada, 236 judul tidak cocok dengan perintah /
108–121 memberikan umpan balik tepat waktu tentang, link, 117–121
halaman tidak teridentifikasi, 316 memungkinkan perintah untuk diatur
108–112 responsivitas aktif, 47 judul, 121
judul yang sama berbeda judul tidak cocok dengan perintah / penyebab umum, 118
windows, 112–117 tautan, 118–120 di aplikasi desktop,
judul jendela tidak cocok halaman tidak teridentifikasi, 108–112 117–118
perintah atau tautan, widget, 52, 373 di Web, 118–120
117–121 jendela bila sesuai,
jendela tidak teridentifikasi, anak, 230 120–121
108–112 kotak kelompok di sekitar, judul, duplikat, 115–116
jumlah, 33–34 214–215 Windows Media Player untuk Mac,
personas, 12 hierarki, 137 pesan kesalahan, 187
sudut pandang, 26–32 tidak teridentifikasi, 108–112 penyihir, 289, 376
kealamian, 27–29 orang tua, 230 kerja depan, 318
kekuatan versus kompleksitas, penempatan, 228–232 menulis, 165–169
30–32 pertimbangan jenis diksi, 166–168
internal program, 30 jendela, 231 tata bahasa, 166–168
kosakata, 29 menentukan lokasi, 231 gaya tidak konsisten, 165–166
profil, 12 menampilkan semua sekaligus tanda baca, 166–168
menyebut pelanggan sebagai, koordinat, 228–229 penulis terampil, 168
181–183 menampilkan bawahan pemeriksaan ejaan, 169
mengambil kendali dari, 277-291 di tengah orang tua, ejaan, 166–168
pengaturan ulang otomatis 229–230 terlalu banyak teks, 169–173
dari tampilan, 277–281 menampilkan bawahan memotong tidak perlu, 172
Tombol batal, 288–291 off-screen, 230–231 gol, 173
kotak dialog, 281–287 heuristik umum, 232 tautan panjang, 170–171
menguji leksikon pada, 160 primer, 375 verbositas, 169–170
pengujian terminologi pada, aturan, 232
164–165 judul yang sama berbeda, X
menerjemahkan pesan kesalahan 112–117 XP (Pemrograman Ekstrim)
untuk, 189 ketidaktahuan duplikat metode, 341–342,
judul, 114–115 354–355
V. file pesan, 116
kata kerja, berubah menjadi kata benda, hanya nama aplikasi
178–179 ditampilkan, 112–113

[Link] 305/315
26/2/2021 Tanpa judul

Halaman 421

tentang Penulis

Jeff Johnson adalah Presiden dan Konsultan Utama di UI Wizards, Inc., sebuah produk
perusahaan konsultan kegunaan yang menawarkan desain UI, tinjauan kegunaan, pengujian kegunaan,
dan pelatihan. Dia telah bekerja di bidang Interaksi Manusia-Komputer sejak itu
1978. Setelah mendapatkan gelar BA dan Ph.D. gelar dari Universitas Yale dan Stanford,
dia bekerja sebagai perancang dan pelaksana antarmuka pengguna, manajer insinyur,
penguji kegunaan, dan peneliti di Cromemco, Xerox, US West, Hewlett-Packard
Labs, dan Sun Microsystems. Dia telah menerbitkan banyak artikel dan buku
bab tentang berbagai topik dalam Interaksi Manusia-Komputer dan dampaknya
teknologi pada masyarakat. Dia sering memberikan ceramah dan tutorial di konferensi
dan perusahaan dalam kegunaan dan desain antarmuka pengguna. Dia membantu dalam desain
dan evaluasi Sistem Pelaporan Insiden Pemilu, sistem berbasis web
untuk masalah pelaporan dan pemungutan suara, yang digunakan untuk memantau tahun 2004 dan
Pemilu AS 2005. Selain membuat GUI Bloopers dan GUI Bloopers 2.0,
ia menulis Web Bloopers: 60 Kesalahan Desain Umum dan Cara Menghindarinya
(2003).

407

Halaman 422

[Link] 306/315
26/2/2021 Tanpa judul

Halaman ini sengaja dikosongkan

Halaman 423

Lampiran Web:
Color Bloopers

Blooper 71: Teks sulit dibaca di latar belakang

Bahkan teks dengan font besar sulit dibaca dengan latar belakang yang berpola dan /
atau sangat kontras dengan warna teks. Kesalahan besar ini terjadi terutama di
Web, tetapi terkadang muncul di aplikasi desktop dan peralatan konsumen.
Ini memiliki tiga variasi umum.

Variasi A: Teks pada latar belakang bertekstur

Variasi pertama adalah menampilkan teks dengan pola latar belakang. Teks konten
di [Link] ditampilkan dengan latar belakang berpola, sehingga sulit untuk melakukannya
baca (Gambar 1).
Situs web Asosiasi Masyarakat Glaukoma Internasional,
[Link], juga memiliki teks pada latar belakang berpola (Gambar 2).
Ini ironis bagi organisasi yang berfokus pada penyakit yang merusak

[Link] 307/315
26/2/2021 Tanpa judul
penglihatan.

Gambar 1

[Link]: background berpola membuat teks sulit dibaca.

Halaman 424

2 Apendiks Web: Color Bloopers

Gambar 2

[Link]: latar belakang berpola membuat teks sulit dibaca.

Variasi B: Kontras rendah antara teks dan latar belakang

Tidak ada yang mengharapkan pengguna untuk dapat membaca teks dengan warna yang sama dengan
latar belakang, 1 namun beberapa desainer berharap pengguna untuk membaca teks yang hampir tersebut
warna yang sama dengan latar belakang.
Situs Web Hunt Museum menampilkan beberapa halaman dengan teks putih di atas lampu
latar belakang cokelat (Gambar 3). Lebih buruk lagi, link di halaman ini berwarna kuning — hampir
tidak mungkin untuk dibaca.
Contoh lain datang dari [Link], situs web Koehler–
Brightstar, sebuah perusahaan senter dan lampu industri. Navigasi situs
menu menggunakan teks putih di atas abu-abu muda (Gambar 4).

1. Desainer web terkadang membuat teks dengan warna yang sama dengan latar belakang. Sebagian besar pengguna tidak akan melihatnya, tetapi
mesin telusur akan menemukan dan menggunakannya untuk mengindeks situs, dan pengguna tunanetra menemukannya dengan pembaca layar dan
gunakan untuk menavigasi halaman secara efisien.

[Link] 308/315
26/2/2021 Tanpa judul
Halaman 425

Blooper 71: Teks sulit dibaca di latar belakang 3

Gambar 3

[Link]: kontras yang buruk antara teks dan latar belakang membuat teks sulit untuk dibaca.

Gambar 4

[Link]: kontras yang tidak memadai antara teks dan latar belakang.

Variasi C: Benturan warna

Beberapa pasang warna bentrok. Bahkan jika kontras antar warna tinggi, kaki-
kesibukan teks berkurang ketika teks dan warna latar belakang bentrok. [Link]
bilah navigasi menggunakan teks biru cerah dengan latar belakang merah cerah, membuatnya sangat indah
sulit dibaca (Gambar 5) atau bahkan untuk dilihat dalam waktu lama.

Halaman 426

4 Apendiks Web: Color Bloopers

Gambar 5

[Link]: warna teks dan latar belakang sangat bentrok, membuat teks sulit dibaca.

[Link] 309/315
26/2/2021 Tanpa judul
Gambar 6

[Link]: teks kontras rendah di atas latar belakang berpola.

Semua yang di atas

Beberapa situs web dan aplikasi menggabungkan variasi blooper ini. Lebeda
Pabrik Kasur menempatkan teks putih dan biru di atas latar belakang biru berair
pola (Gambar 6)
Situs Web Keller Williams Montana Realty memuat teks di atas foto, rendah
kontras, dan warna bentrok (Gambar 7).

Halaman 427

Blooper 71: Teks sulit dibaca di latar belakang 5

Gambar 7

[Link]: teks sulit dibaca. (A) Halaman beranda. (B) Diperluas

tautan subnavigasi.

Menghindari Blooper 71

Untuk memastikan bahwa teks terbaca dengan latar belakangnya, desainer hanya perlu mengikuti
pedoman ini:

● Gunakan latar belakang solid: Jangan gunakan latar belakang berpola atau bertekstur. Jika kamu melakukan,
membuatnya pingsan, seperti tanda air, dan meletakkan area tanpa pola di belakang teks.
●
Dark on light beats light on dark: Dark on the light background is more
terbaca dari teks terang pada latar belakang gelap karena persepsi "berdarah"
dari latar belakang menjadi teks. Teks terang di latar belakang gelap berfungsi
hanya jika kontrasnya bagus dan teksnya cukup tebal untuk menahan
"berdarah."
● Hindari warna yang bentrok: Jangan gunakan warna merah dengan biru, biru melawan kuning,
hijau melawan magenta, atau sebaliknya.
●
Hitam di atas putih sangat ideal: Untuk keterbacaan, tidak ada yang mengalahkan teks hitam pada a
latar belakang putih. Tentu saja, keterbacaan bukanlah satu-satunya perhatian: GUI—
terutama situs web — akan terlalu hambar jika semua teks dihitamkan
putih. Meskipun demikian, pertimbangkan yang ideal saat memilih teks dan
warna latar belakang. Untuk teks, lebih gelap lebih baik; untuk latar belakang, lebih terang
lebih baik.

[Link] 310/315
26/2/2021 Tanpa judul

Kalkulator hipotek dari Federal Reserve Bank AS sebelumnya memiliki pola

latar belakang terned (Gambar 8A). Mereka baru-baru ini menggantinya dengan yang memiliki
latar belakang putih (Gambar 8B).

Halaman 428

6 Apendiks Web: Color Bloopers

Angka 8

Kalkulator hipotek Federal Reserve Bank. (A) 2002. (B) 2007.

Halaman 429

Blooper 72: Mengandalkan perbedaan warna yang halus 7

[Link] 311/315
26/2/2021 Tanpa judul

Blooper 72: Mengandalkan perbedaan warna yang halus

Banyak aplikasi dan situs Web mengandalkan perbedaan warna yang halus untuk menyampaikannya
informasi penting. Ini menyebabkan masalah bagi banyak pengguna, untuk delapan berbeda
alasan:

1. Buta warna: Sekitar 8% pria dan sedikit di bawah 0,5%

wanita memiliki defisit persepsi warna: 2 kesulitan membedakan tertentu
pasang warna [Wolfmaier, 1999]. Bentuk paling umum adalah merah / hijau
(Gambar 9); bentuk lain jauh lebih jarang.
2. Daya membedakan warna pucat yang buruk: Untuk semua orang, warna pucat (kurang satu-
dinilai) dua warna, semakin sulit membedakannya (Gambar 10A).
3. Mengurangi daya pembeda dari bercak warna kecil: Semakin kecil atau tipis
objek, semakin sulit untuk membedakan warnanya (Gambar 10B). Teks adalah
seringkali tipis, sehingga warna teks yang tepat seringkali sulit ditentukan. Peningkatan
popularitas perangkat genggam layar kecil berarti area warna yang lebih kecil.
4. Hilangnya daya pembeda dari tambalan yang terpisah: Warna yang lebih terpisah
semakin sulit membedakan warnanya (Gambar 10C).
5. Variasi di antara tampilan berwarna: Tampilan komputer berbeda-beda dalam tampilannya
warna, karena teknologi yang berbeda, perangkat lunak driver yang berbeda, atau berbeda
pengaturan warna. Sesuatu yang tampak kuning pada satu tampilan mungkin tampak krem
lain. Warna yang berbeda di satu sisi mungkin terlihat sama di sisi lain.
6. Tampilan skala abu-abu: Meskipun sebagian besar tampilan saat ini berwarna, ada
perangkat, terutama perangkat genggam kecil, dengan tampilan skala abu-abu.

Gambar 9

Warna-warna ini sulit dibedakan oleh orang yang buta warna merah / hijau. (A) Merah tua vs.
hitam. (B) Biru vs. ungu. (C) Hijau muda vs. putih.

Gambar 10

Faktor-faktor yang mempengaruhi daya pembeda warna. (A) Pucat. (B) Ukuran. (C) Pemisahan.

2. Istilah umum adalah "buta warna", tetapi "defisit penglihatan" warna, "defisiensi penglihatan", "penglihatan
cacat, "" kebingungan, "dan" kelemahan "lebih akurat. Warna "menantang" juga digunakan. Jumlah
ketidakmampuan untuk melihat warna sangat jarang.

Halaman 430

8 Apendiks Web: Color Bloopers

7. Sudut tampilan: Beberapa layar komputer, terutama yang LCD, bekerja lebih baik.
ter jika dilihat langsung daripada jika dilihat dari sudut. Saat LCD dis-
drama dilihat dari suatu sudut, warna — dan perbedaan warna — sering kali diubah.
8. Pencahayaan sekitar: Cahaya yang kuat pada layar menyapu warna-warna sebelumnya
membersihkan area terang / gelap, mengurangi tampilan warna menjadi skala abu-abu, seperti
orang yang telah mencoba menggunakan ATM bank di bawah sinar matahari langsung tahu. Di kantor,
silau dan bayangan buta-venetian dapat menutupi perbedaan warna.

Warna sebagai alat bantu navigasi

Di Web, penggunaan warna secara navigasi yang paling umum adalah untuk membedakan
tautan rendah dari yang sudah diikuti. Di banyak situs Web, kata "diikuti" dan
Warna yang "tidak diikuti" terlalu mirip. Federal Reserve Bank of Minneapolis
(Gambar 11) memiliki kesalahan besar ini. Bisakah Anda melihat dua tautan yang diikuti? 3
Beberapa tahun yang lalu, situs Web perjalanan online [Link] menggunakan perbedaan warna
itu terlalu halus. Saat pelanggan melewati langkah-langkah membuat reservasi,
lokasi menunjukkan langkah saat ini dengan warna kuning sangat pucat (Gambar 12). Untuk salah satu
Delapan alasan yang dijelaskan di atas, banyak pengguna tidak dapat melihat langkah mereka
di. Situs baru ITN mengoreksi kesalahan besar tersebut (lihat Menghindari Blooper 72, di bawah).

Gambar 11

[Link] 312/315
26/2/2021 Tanpa judul

[Link]: perbedaan warna antara tautan yang dikunjungi dan tautan yang tidak dikunjungi terlalu halus.

Gambar 12

[Link] (2003): langkah saat ini dalam proses reservasi maskapai penerbangan yang ditandai dengan warna yang halus.
Langkah 2 adalah langkah saat ini.

3. Unit Perumahan Resmi dan Indeks Harga Rumah.

Halaman 431

Blooper 72: Mengandalkan perbedaan warna yang halus 9

Warna dalam konten

Contoh sebelumnya tentang mengandalkan perbedaan warna yang halus diperhatikan

dengan navigasi di situs Web. Warna juga sering digunakan — dan disalahgunakan — untuk menyampaikan
informasi dalam konten .
Produk perangkat lunak MoneyDance menyediakan perincian grafis
keuangan rumah tangga (Gambar 13A). Pengguna buta warna merah / hijau tidak dapat membedakan
guish biru dari ungu atau hijau dari khaki. Ini bisa kira-kira
ditiru dengan mengurangi grafik menjadi skala abu-abu (Gambar 13B).
Gambar 13

MoneyDance. (A) Grafik menggunakan warna yang tidak dapat dibedakan oleh beberapa pengguna. (B) Versi skala abu-abu.

[Link] 313/315
26/2/2021 Tanpa judul

Halaman 432

10 Apendiks Web: Color Bloopers

Menghindari Blooper 72

Untuk menghindari desain UI yang mengandalkan perbedaan warna halus, ikuti satu atau beberapa
aturan ini:

1. Jangan hanya mengandalkan warna . Gunakan warna secara berlebihan dengan isyarat lain. Jika Anda menggunakan
warna untuk menandai sesuatu, tandai dengan cara lain juga. IPhoto Apple menggunakan
warna dan simbol untuk membedakan album foto "pintar" dari biasa
yang (Gambar 14).
2. Hindari perbedaan warna yang halus . Pastikan kontras antar warna tinggi
(selama warnanya tidak bentrok). Warna harus berbeda dalam saturasi dan
kecerahan serta rona . Salah satu cara untuk menguji apakah warnanya berbeda
cukup dengan melihatnya dalam skala abu-abu [Hoffman, 1999]. Jika Anda tidak bisa membedakan
warna saat dirender dalam abu-abu, tidak cukup berbeda.
3. Jangan gunakan pasangan warna yang menyulitkan orang buta warna . Itu akan menjadi gelap
merah vs. hitam, merah tua vs. hijau tua, biru vs. ungu, hijau muda vs. putih.
Jangan gunakan warna merah tua, biru, atau violet pada warna gelap apa pun. Sebagai gantinya, gunakan
merah tua, biru, dan violet melawan kuning dan hijau muda.

Seperti disebutkan di atas, [Link] baru-baru ini meningkatkan cara menandai res-
langkah pengawetan. Ini menggunakan warna secara berlebihan dengan bentuk (Gambar 15).
Grafik lain dari Federal Reserve Bank menggunakan warna putih dan corak
hijau (Gambar 16). Ini adalah grafik yang dirancang dengan baik. Setiap orang yang bisa melihat bisa membaca
itu, bahkan dengan tampilan skala abu-abu.

Gambar 14

IPhoto Apple Computer: menggunakan warna dan simbol secara berlebihan untuk membedakan dua jenis
album.

Gambar 15

Koreksi blooper di [Link]: langkah saat ini disorot dalam dua cara, warna dan bentuk.

Halaman 433

Blooper 72: Mengandalkan perbedaan warna yang halus 11

Gambar 16

[Link] 314/315
26/2/2021 Tanpa judul

[Link]: grafik menggunakan perbedaan warna yang terlihat oleh semua orang yang dapat melihat,
di layar apa pun.

Referensi
Hoffman, P. 1999. “Mengakomodasi Buta Warna.” Antarmuka Kegunaan
6 (2). (Juga tersedia di [Link]
buta [Link].)
Wolfmaier, T. 1999. “Designing for the Color-Challenged: A Challenge.” ITG
Publikasi 2.1. ([Link]
ity_color_challenged.html.)

[Link] 315/315