Sekilas Tentang Heuristic Evaluation Checklist

Salah satu cara untuk menguji keberhasilan sebuah antarmuka adalah dengan melakukan heuristic evaluation (HE). Menurut Galitz (2007), cara ini bukanlah cara yang terbaik, namun cara ini adalah yang paling populer. HE dilakukan oleh beberapa orang evaluator yang berkompeten di bidang pengembangan antarmuka. Evaluator akan diminta untuk menilai antarmuka yang telah kita buat dengan menggunakan heuristic evaluation checklist. HE merupakan metode evaluasi antarmuka yang dikembangkan oleh Jacob Nielsen (Artikel lengkap dapat dibaca di sini). Dalam HE ada 10 komponen yang perlu dievaluasi yaitu:

Visibility of System Status

Meliputi kejelasan suatu control dan kesesuaian dengan fungsinya. Misalnya, kalau kita lihat bentuk kursi, kita akan segera tahu bagaimana cara menggunakannya. Itulah visibility. Sesuatu yang dikatakan tidak memenuhi visibility misalnya ada sebuah mobil yang ternyata bukan mobil melainkan sebuah robot transformer. Kita tidak membutuhkan transformer dalam antarmuka. Cukup yang jelas-jelas saja.

Match Between System and The Real World

Komponen ini meliputi kesesuaian dengan dunia nyata seperti penggunaan angka decimal yang tepat, pemilihan icon yang sesuai, dan sebagainya.

User Control and Freedom

Kebebasan pengguna meliputi seberapa kuat peran pengguna untuk mengatur aplikasi. Misalnya, pada aplikasi pemutar musik, apakah ada tombol untuk mengecilkan volumenya? Atau yang lebih sederhana lagi, apakah ada tombol close di aplikasi itu?

Consistency and Standards

Komponen ini berkaitan erat dengan standard an konsistensi desain yang dibangun. Suatu desain dikatakan tidak konsisten apabila tiba-tiba headernya miring padahal sebelumnya tidak, atau tadinya pakai bahasa Indonesia but suddenly the application is in English. This adalah something that tidak konsisten.

Help User Recognize, Diagnose, and Recover From Erros

Poin ini dimaksudkan untuk menguji apakah sistem dapat membantu pengguna keluar dari jeratan eror. Jika terjadi eror, apa peringatan yang diberikan desainer? Sopankah peringatan tersebut? Apakah pemberitahuan tersebut dapat membatu pengguna atau justru membuat pengguna menjadi makin bingung?

Error Prevention

Ini adalah sesuatu yang sangat penting, bagaimana desain yang dibuat bisa mencegah pengguna dari melakukan kesalahan. Bagaimana desainer bisa membuat pengguna tahu bahwa ia harus mengetikkan tanggal/bulan/tahun dan bukannya bulan/tanggal/tahun.

Recognition Rather Than Recall

Salah satu tujuan usability adalah untuk membuat pengguna tidak perlu mengingat informasi yang sebelumnya ia berikan atau dapatkan. Misalnya, ketika kita melakukan search di Google, maka setelah hasil search muncul, textbox search tetap bertuliskan keyword kita kan? Ini adalah upaya untuk membuat pengguna tidak perlu mengingat-ingat “tadi gw ngetik apa ya?”

Flexibility

Sebuah system boleh memiliki batasan, namun jangan sampai mengekang pengguna dan mengabaikan fleksibilitas. Bagaimana kemampuan antarmuka untuk memenuhi “eksperimen” pengguna perlu diuji di sini.

Aesthetic and Minimalist Design

Desain yang sederhana menjadi nilai tambah dalam sebuah aplikasi. Desain yang sederhana bukan berarti ada tombol2 di atas page berwarna putih, namun lebih berkaitan dengan penentuan porsi desain yang “pas” dalam antarmuka. Sederhananya, slide Power Point untuk presentasi agak hambar kalau tanpa animasi, namun animasi berlebihan justru akan sangat mengganggu.

Help and Documentation

Komponen ini berkaitan dengan bagaimana desainer (dan developer) mempersiapkan bantuan bagi pengguna. Apakah ada tooltip dalam aplikasi? Apakah ada tombol help?

Nah, kira-kira itulah poin-poin yang harus diperhatikan dalam melakukan heuristic evaluation. Contoh HE checklist dalam bahasa Indonesia dapat diunduh di sini.

Simple Usability Engineering Lifecycle

Pengembangan sebuah software tidak akan pernah lepas dari pembuatan antamuka aplikasinya. Tidak akan berguna, secanggih apapun algoritmenya, sehebat apapun idenya, kalau tidak bisa digunakan oleh pengguna. Untuk memudahkan penggunaan aplikasi dan agar tujuan pengembangan system dapat tercapai, perlu dilakukan pengembangan antarmuka yang terstruktur dan sesuai dengan kaidahnya. Salah catu cara untuk mengambangkan antarmuka adalah dengan menggunakan metode usability engineering life cycyle (Mayhew 1999) untuk aplikasi sederhana. Gambar 1 menunjukkan skema metode pengembangan tersebut.

Profil Pengguna

Pada tahap ini dilakukan pengumpulan data karakteristik pengguna sistem. Pengumpulan profil pengguna dapat dilakukan dengan berbagai cara seperti dengan wawancara, observasi, menggunakan teknik persona dan lain sebagainya. Intinya, pada tahap ini kita harus mengenal dengan jelas siapa pengguna kita dan bagaimana karakter mereka sehingga desain yang dihasilkan nanti akan sesuai dengan karakter pengguna.

Analisis Tugas Kontekstual

Pada tahap ini dilakukan analisis mengenai tugas pengguna yang berkaitan dengan aliran pekerjaan yang dilakukan. Hasil analisis ini akan digunakan sebagai dasar untuk menentukan usability goals. Analisis dilakukan dengan mendaftarkan pekerjaan yang dilakukan oleh pengguna secara manual sehari-hari beserta permasalahan yang dihadapi pengguna yang berkaitan dengan pekerjaannya. Dengan melakukan tahap ini kita dapat mulai merancang apa urutan pekerjaan yang perlu diotomasi dan bagaimana cara agar system yang kita kembangkan dapat menghapuskan permasalahan yang sering dihadapi

Keterbatasan Platform

Pada tahap ini dilakukan analisis terhadap kapabilitas platform tempat aplikasi ini akan berjalan. Keterbatasan platform akan membatasi desain antarmuka. Antarmuka haruslah dibuat sesuai dengan standar platform tertentu agar dapat suatu aplikasi dapat bekerja dengan optimal. Keterbatasan yang harus diperhatikan antara lain berapa resolusi layar yang digunakan pengguna, apa system operasinya, bagaimana hardware yang digunakan, dan sebagainya.

Prinsip Desain Umum

Pada tahap ini dipelajari mengenai prinsip-prinsip desain antarmuka yang baik dan sesuai standar. Pemehaman mengenai prinsip-prinsip desain tersebut dilakukan berdasarkan panduan pengembangan antarmuka yang ada.

Usability Goals

Pada tahap ini, dirumuskan tujuan-tujuan kualitatif dan kuantitatif yang menggambarkan kebutuhan usability. Rumusan yang dihasilkan pada tahap ini akan menjadi tolak ukur keberhasilan pembangunan antarmuka ini pada tahap evaluasi.

Style Guide

Style guide merupakan panduan desain yang diperoleh dari analisis pada tahap-tahap sebelumnya. Style guide akan menjadi panduan untuk melakukan perancangan lebih lanjut. Berdasarkan Mayhew (1999), pada perancangan aplikasi sederhana style guide tidak perlu didokumentasikan, oleh karena itu tahap pembuatan style guide tidak dilakukan dalam perancangan prototipe ini.

Work Reengineering

Tahap work reengineering merupakan tahap perancangan ulang tugas pengguna pada tingkat organisasi dan aliran pekerjaan. Pada tahap ini tidak dilakukan perancangan antarmuka, melainkan hanya organisasi abstrak fungsionalitas dan aliran pekerjaan. Work reengineering dilakukan jika ada task yang belum dapat dianalogikan secara gamblang ke dunia digital. Misalnya kita ingin membangun sebuah aplikasi word processing semacam MS.Word, di dunia nyata ketika kita menulis dengan tangan, tidak ada cara untuk mengubah ukuran dan jenis tulisan. Hal seperti inilah yang perlu di-reengineering untuk menghasilkan analogi baru yang usable.

Desain Model Konseptual

Pada tahap ini dibuat sketsa desain antarmuka. Desain meliputi sketsa tampilan, navigasi dan menu-menu. Detail perancangan layar tidak dibuat pada tahapan ini.

Standar Desain Layar

Pada tahapan ini dipelajari mengenai tata letak dan aspek-aspek lain yang menjadi standar antarmuka dari platform yang dipilih untuk diikuti. Standar ini diperlukan untuk menghasilkan antarmuka yang mudah dan memiliki ciri-ciri umum seperti antarmuka suatu platform yang biasa digunakan oleh pengguna.

Desain Antarmuka Detil

Rancangan detil antarmuka produk dilaksanakan berdasarkan perbaikan dan validasi model konseptual dan standar desain layar yang sudah terdokumentasi pada style guide produk.

Evaluasi Desain Antarmuka Detil

Pada tahap ini dilakukan evaluasi terhadap desain antarmuka detil. Evaluasi dilakukan untuk memastika rancangan ini telah memenuhi standar dan memungkinkan seluruh pekerjaan dapat diakukan oleh

Instalasi

Pada tahap ini, aplikasi diluncurkan, dikonfigurasi dan diberikan kepada pengguna.

User Feedback

Pada tahap ini akan dilakukan evaluasi heuristic Jacob Nielsen. Hasil evaluasi akan digunakan sebagai bahan revisi antarmuka jika diperlukan.

Itulah tahapan yang dilakukan dalam usability engineering sederhana. Semoga dengan menerapkan tahapan ini kita dapat menghasilkan antarmuka yang usable.

Web Developer’s Mistake: The “Mail to” Link

Ketika user membaca sebuah artikel baik itu ilmiah ataupun sekedar artikel feature, ada kecenderungan user ingin tahu siapa sih yang menulis artikel ini. Kalau saya pribadi ketika membaca sebuah artikel yang bagus, jadi penasaran “pingin tau mukanya orang yang nulis ini! Gaul banget kayaknya..” Nah, oleh karena itulah di suatu halaman post yang bukan berada di blog pribadi sebaiknya mencantumkan foto dan link menuju biografi si penulis.

Kebutuhan akan biografi penulis seringkali digantikan oleh developer dengan meletakkan link “Mail to Author” atau “Mail to author@postkeren.com”. Padahal, in-fact, kebanyakan user cuma pingin tau aja siapa sih yang nulis, bukan pingin langsung kirim email. Pencantuman email memang penting, apalagi buat tulisan ilmiah, tapi seharusnya email bukan menjadi emphasis dari suatu biografi penulis.

Cartoons by

Doug Sheppard and Katrin L. Salyers

Bicara mengenai pencantuman email, kita sering menemukan ada tulisan berwarna biru dan diberi underline yang berisikan tulisan “Ditulis oleh : Author bin Authorian“. Coba kita pikir deh, apa sih ekspektasi user ketika dia menemukan ada tulisan berwarna biru dan ber-underline? Ekspektasi user adalah “Ketika gw klik tulisan ini, maka gw akan pindah ke halaman baru yang isinya adalah informasi mengenai si author.” Tapi apa yang didapat ketika user mengklik anchor itu? Yang terjadi adalah secara otomatis computer kita akan membuka mail client, Outlook misalnya, yang bahkan kebanyakan user males makenya dan belum tentu juga mau kirim email ke si author. Ekspektasi user adalah dia akan diajak ke halaman biodata atau biografi si penulis, bukan malah membuka aplikasi email client.

Anchor yang mengindikasikan “mail to” haruslah disajikan secara eksplisit misalnya “Mail to: author@penulis.com”, atau “Kirim email ke saya”. Jangan sekali-sekali menjadikan foto sebagai anchor untuk mengirim email, karena percayalah ini akan sangat mengganggu.

Web Developer’s Usability Mistake: “Open in New Window”

Seringkali ketika kita mengklik sebuah link di halaman website yang tiba-tiba membuka halaman yang bertautan di window browser baru. Kita mungkin merasa terganggu dengan kemunculan new window ini, apalagi jika kita menggunakan netbook yang layarnya begitu kecil. Developer web memutuskan untuk menggunakan new window dengan tujuan untuk tidak menutup halaman yang sedang dibuka oleh pengguna. Biasanya ini dilakukan jika link menuju pada sebuah eksternal link. Pemilik website tidak menginginkan penggunanya meninggalkan websitenya demi mengunjungi web orang lain. Ini adalah tujuan yang sah sah saja, namun bagaimana jika kita kaji masalah ini dari segi usability?

Cartoons by

Doug Sheppard and Katrin L. Salyers

Kemunculan new window browser justru akan mengganggu keseimbangan dalam penggunaan aplikasi web. Dengan memunculkan window browser baru, maka developer telah merenggut kebebasan pengguna untuk mengklik tombol back. Tombol back pada new window secara otomatis akan menjadi disable karena memang tidak ada halaman sebelumnya. Ini tidak sesuai prinsip dasar aplikasi web konvensional yang seharusnya mengedepankan “navigation-based”. Tombol back seharusnya menjadi lifeline dan pegangan yang menenangkan pengguna “oh saya bisa santai karena apapun yang saya klik, saya akan bisa kembali ke halaman sebelumnya”, namun dengan munculnya new window, pengguna hanya akan menemukan tombol back yang disable dan akan membuatnya bingung sebelum menyadari bahwa halaman yang sebelumnya ada di window yang berbeda.

Memunculkan browser new window (mengutip Nielsen) bagaikan seorang salesman alat penghisap debu yang menuangkan kotoran ke karpet rumah kita sebelum mulai mendemokan dagangannya tersebut. Kata Nielsen, “Don't pollute my screen with any more windows, thanks. If I want a new window, I will open it myself!” Developer berpikir keras untuk membuat pengguna tetap berada pada halaman web mereka namun developer sering mengesampingkan ketidaknyamanan pengguna ketika aplikasi “mengambil alih kontrol sistem”. Memunculkan window baru adalah hak penuh pengguna karena hal tersebut melibatkan entitas lain di luar system web yang dibangun.

Saya sangat menyarankan untuk tidak menggunakan link yang akan memunculkan window baru, gunakanlah page navigation yang standar. Kalau kita takut user berpindah dari web kita, mari kita lakukan dengan cara yang lebih elit: buat konten yang menarik sehingga user akan selalu datang ke web kita. Atau cara yang paling sederhana: Munculkan tab baru saja lah..

Sekilas Tentang Enterprise Service Bus

Progress Sonic, teman baru yang baru saya temui di kantor. Sonic adalah sebuah software yang digunakan untuk mengembangkan sebuah Enterprise Service Bus (ESB). Saya yang masih anget2nya keluar dari kampus lumayan kaget ketemu ESB yang sama sekali ga pernah saya temui sebelumnya. Nah, makanya saya cari2 info soal barang ini (sekalian ditulis biar ga lupa). Oke, ESB adalah sebuah arsitektur software yang menyediakan servis berupa komunikasi (messaging) antara satu sistem dengan system lain. Sederhananya sih ESB ini jadi perantara, pihak penengah diantara beberapa system yang ingin berkomunikasi. ESB biasa diimplementasikan dengan teknologi-teknologi yang banyak ditemukan di infrastruktur middleware.

Secara umum, ESB menyediakan abstraction layer di atas implementasi sebuah enterprise messaging system. Layer ini memungkinkan integration architects untuk mengekspose dan memanfaatkan message yang diproduksi oleh suatu system untuk dapat diteruskan ke system lain. ESB bagaikan mak comblang, ketika ada seorang jomblo tua karatan dateng minta bantuan, si mak comblang akan menerima foto si jomblo, mungkin dia akan lakukan sedikit manipulasi (diedit dikit fotonya biar agak ganteng) lalu dikirimkannya foto itu kepada seorang wanita muda yang mencari jodoh. Sama prinsipnya, system A akan mengirimkan message dalam bentuk xml dan ESB akan melakukan manipulasi seperti mengubah bentuk xml jika diperlukan. Manipulasi, misalnya pengubahan bentuk, dilakukan untuk menyesuailan xml dengan input yang diperbolehkan oleh system B.

Salah satu aplikasi yang dapat digunakan untuk mengembangkan sebuah proses ESB adalah Progres Sonic. Sonic Workbench terintegrasi sepenuhnya dengan eclipse. Yap, Eclipse. Sonic sudah menyediakan banyak proses yang bisa dimanfaatkan, namun jika kita perlu mekalukan kostumisasi, maka pemrograman haruslah dilakukan dengan bahasa Java. Oke Java. Namun menariknya, kita dapat menggunakan library Sonic .Net Client untuk mengembangkan aplikasi berdasarkan Sonic. Yup .Net. Artinya , kita bisa mengembangkan service ESB di dalam workbench dengan java sekaligus memanfaatkan servis yang ada dengan menggunakan .Net.

Saya akan bicarakan lagi mengenai detil penggunaan Sonic Workbench di post berikutnya. Bagi kamu-kamu yang mau tau lebih banyak soal teknologi ini, silahkan aja dulu mampir ke http://web.progress.com/en/sonic/sonic-esb.html. Booyah!