Artikel ini hampir seluruhnya didasarkan pada kutipan dari buku " Antarmuka - Arah Baru dalam Desain Sistem Komputer " karya Jeff Raskin dengan tambahan dan reka ulang saya tentang contoh antarmuka yang diberikan dalam buku ini.
Jawaban cepat untuk pertanyaan apakah perlu menggunakan analisis GOMS untuk menguji kegunaan: “Jika Anda mendesain antarmuka, saat bekerja dengan yang mana dari penundaan 0,3 detik. tidak ada yang mati - tidak sepadan. "
Jadi, "Model Tujuan, Objek, Metode, dan Aturan Seleksi" (GOMS) adalah metode penelitian antarmuka yang dikembangkan oleh Card, Moran dan Newell pada 1980-an. GOMS memprediksi berapa lama waktu yang dibutuhkan pengguna berpengalaman untuk menyelesaikan operasi tertentu menggunakan antarmuka tertentu.
Sekarang kita sudah terbiasa dengan istilah ini, aneh di telinga Rusia, kita bisa menggambarkan esensinya.
Pengembang GOMS memperhatikan bahwa waktu yang diperlukan pengguna untuk menyelesaikan tugas sama dengan jumlah semua interval waktu yang diperlukan untuk menyelesaikan setiap gerakan pengguna tertentu (misalnya, memindahkan tangan dari mouse ke keyboard dan mengetik huruf). Dengan bantuan studi laboratorium, serangkaian interval waktu diperoleh, diperlukan untuk melakukan berbagai gerakan.
Gerakan dan waktu GOMS
- H (mentransfer tangan ke mouse) = 0,4 detik
- K (menekan tombol keyboard atau mouse) = 0,2 detik
- P (menggerakkan kursor ke posisi di layar) = 1,1 detik
- M (memikirkan langkah selanjutnya) = 1,35 detik
- R (menunggu respon dari sistem) - waktu bergantung pada kecepatan sistem tertentu dan tidak berpartisipasi dalam perhitungan.
Dalam kalkulasi selanjutnya, Gestur akan diganti dengan huruf dari daftar di atas dan akan disebut "Operator".
Di bawah ini adalah beberapa aturan yang agak rumit untuk bekerja dengan isyarat yang sama (operator). Untuk saat ini, baca saja, lalu saya akan menjelaskan semuanya dengan contoh.
Aturan penempatan operator
- 0. M
M K ( ), P ( ), (, ); P, (, ), M . - 1. M
, M, , M, M . , , M, 0. - 2. M
M K M K M K… , M, . , «4564.23» « ».
- 3. M
K , (, « — »), M, . - 4. M,
K , (, , ), M, . , M. K , M . - 5. M
M, R, , , .
Diberikan:
Pengguna diminta untuk mengubah suhu dari Fahrenheit ke Celsius atau sebaliknya. Misalnya, mereka mungkin bertanya, "Ubah 3,5 derajat Fahrenheit ke derajat Celsius." Pengguna dapat memasukkan nilai suhu hanya dengan menggunakan keyboard atau mouse.
Tujuan:
Merancang antarmuka di mana waktu untuk menerjemahkan nilai suhu minimal.
Ketentuan
Untuk kesederhanaan, kami akan mengasumsikan bahwa pengguna memasukkan maksimal dua karakter dan pengguna tidak melakukan kesalahan.
Penting : Contoh di bawah ini berfungsi secara tepat untuk mengilustrasikan aturan yang dijelaskan dalam buku. Masalah ini dapat diselesaikan dengan cara lain yang mungkin lebih optimal.
Keputusan. Pilihan 1
Bayangkan bahwa pengguna pertama-tama harus memahami ke arah mana transfer akan dilakukan dan jika ke arah yang dia butuhkan, maka dia cukup memasukkan angka-angkanya. Jika ke arah yang salah, maka dia beralih ke yang benar di grup radio.
Pembayaran
H (tangan di atas mouse) + M (berpikir) + P (pindahkan kursor ke grup radio) + K (klik) + M (pikirkan) + P (kursor ke bidang) + K (klik) + H (gerakkan tangan dari mouse ke keyboard) + M (pikirkan) + K (masukkan digit pertama) + M (pikirkan) + K (masukkan digit kedua).
Menurut aturan 2, kita hapus M ekstra dan dapatkan:
H + M + P + K + M + P + K + H + M + K + K
Jika arah konversi suhu TIDAK sesuai, maka kita dapatkan:
0,4 + 1,35 + 1,1 + 0,2 + 1,35 + 1,1 + 0,2 + 0,4 + 1,35 + 0,2 + 0,2 = 7,85 detik
Jika arah konversi suhu yang sesuai dipilih, maka kita mendapatkan:
0,4 + 1,35 + 1,1 + 0,2 + 1,35 + 0,2 + 0,2 = 4,8 detik
Keputusan. pilihan 2
Kami menghilangkan kebutuhan untuk mengganti sisi terjemahan. Membuat bidang masukan dapat diseret. Jika kita mengubah posisi / nilai satu bidang, maka posisi / nilai bidang lainnya otomatis berubah.
Pembayaran
H (0,4) + M (1,35) + P (1,1) + K (0,2) + P (1,1) = 4,15 detik
Opsi implementasi ini lebih "dapat digunakan" daripada yang pertama sebesar 0,65 detik.
Kesalahan metode
Raskin menulis bahwa menggunakan metode ini dimungkinkan untuk memprediksi berapa lama pengguna akan membutuhkan tugasnya dengan kesalahan absolut kurang dari 5% .
Juga, jangan berasumsi bahwa dengan metode ini kami mengukur waktu khusus untuk bekerja dengan antarmuka. Ini aneh, karena, pada kenyataannya, kami melakukan hal itu, tetapi kami harus memahami bahwa detik lebih digunakan sebagai semacam konvensi. Bagaimanapun, pengguna yang berbeda mungkin memiliki kecepatan yang berbeda. Kami hanya perlu memahami betapa konkretnya satu antarmuka lebih "dapat digunakan" daripada yang lain, dan unit pengukuran membantu kami dalam hal ini. Kecepatan kerja sebenarnya mungkin atau mungkin tidak sesuai dengan harapan kami - semuanya akan tergantung pada pengguna tertentu.
Pendapat saya tentang analisis GOMS
Ketika saya pertama kali mengetahuinya, saya ingin segera mulai menggunakannya di semua proyek saya. Tampak bagi saya bahwa inilah saatnya - menyingkirkan siksaan kuno karena memilih "yang merupakan cara yang benar". Tanpa subjektivitas dan tren. Matematika "bodoh" yang nyata. Namun kenyataannya, untuk mendeskripsikan antarmuka yang paling primitif sekalipun, Anda perlu menghabiskan waktu dua kali lebih banyak daripada mendesainnya. Dan kemudian Anda masih harus merancang alternatif untuk menghitungnya. Dan bahkan jika pada akhirnya saya menemukan opsi mana yang lebih baik, ternyata lebih baik dengan 0,65 detik. Butuh waktu 3-4 jam untuk menang 0,65 detik itu kuat.
Namun demikian, menurut saya metode ini masih keren dan layak digunakan, tetapi dalam beberapa antarmuka yang sangat penting bahkan 0,65 detik pun penting. Di sebagian besar proyek, lebih logis untuk mengandalkan pengalaman Anda dan setelah fakta, tanyakan kepada pengguna bagaimana cara yang lebih nyaman bagi mereka.
Raskin menulis sesuatu seperti ini:
“Pengembang yang terbiasa dengan metode GOMS jarang melakukan analisis yang mendetail dan formal dari model antarmuka. Hal ini sebagian karena mereka mengetahui dasar-dasar GOMS dan metode kuantitatif lainnya hingga pada awalnya mereka dipandu oleh metode ini dalam proses pengembangan. "
PS
Ada juga modifikasi analisis GOMS. Misalnya, "Metode jalur kritis GOMS" (CPM-GOMS) dan versi yang disebut bahasa GOMS alami (NGOMSL), yang memperhitungkan perilaku pengguna yang tidak berpengalaman, misalnya, waktu yang diperlukan untuk belajar. Anda dapat membaca tentang versi ini sendiri.