Pertemuan 10 - Implementasi Support Help Document
Pertemuan 10 - Implementasi Support Help Document
PERKULIAHAN KE 9
Pokok Bahasan :
Elemen sistem windowing
Pemrograman Aplikasi
Menggunakan Alat bantu
Sistem Manajemen User Interface
Kebutuhan untuk mendukung user
Pendekatan untuk mendukung user
Sistem bantu pintar (intellegent)
Perancangan sistem untuk mendukung user
Newman, W.M., and Lamming, M.G, Interactive System Design, Addison Wesley,
Cambrigde, UK, 1995
Lecture Notes : Ida Ayu Yulie Primashanti
IMPLEMENTATION SUPPORT
Tujuan
• Tool pemrograman untuk system interaktif :
- Menterjemahkan desain abstrak secara efektif dan prinsip usability ke bentuk
yang dapat dieksekusi
- pelayanan pada level yang berbeda bagi pemrogram
• Sistem window :
- Lingkungan utama bagi pemrogram dan user
- Memungkinkan workstation tunggal mendukung system user yang terpisah
melalui aksi yang simultan
• Toolkit interaksi :
- Memungkinkan pemrogram untuk menggambarkan perilaku objek pada level
yang sama terhadap pencapaian user
• Sistem Manajemen Interface User/ User Interface Management Systems (UIMS) :
- Level terakhir dari tool pendukung pemrograman
- Memungkinkan desainer dan pemrogram untuk mengontrol relasi antara objek
presentasi dari toolkit dengan semantic fungsionalnya dalam aplikasi sebenarnya.
Sistem window menyediakan kemampuan berbagi sumber dari satu konfigurasi perangkat
keras dengan beberapa salinan terminal abstrak. Masing2 terminal abstrak berlaku sebagai
proses bebas dan system window akan mengkoordinasikan control dari proses yang ada.
System window juga perlu untuk menampilkan aplikasi yang terpisah dengan
mendedikasikan daerah dari layar display ke setiap terminal abstrak. Tugas koordinasi
berhubungan dengan menyelesaikan konflik display ketia daerah layar yang terlihat dari dua
terminal abstrak saling tumpang tindih.
Multiple
Application
Windowing Control
System
Device
Independence
Win. Win. 2
1
Mouse Keyboard
Win.
n
Server
Resource Manager
Device Driver
Devices
Win. Win. 2
1
Mouse Keyboard
Win.
n
Bass dan Coutaz mengidentifikasikan ada 3 arsitektur yang mungkin bagi perangkat lunak
untuk mengimplementasikan role dari system window. Semua ini diasumsikan bahwa device
driver terpisah dari program aplikasi. Pilihan pertama adalah untuk mengimplementasikan
dan replikasi manajemen dari proses yang multiple dalam setiap aplikasi yang terpisah.
Arsitektur ini tidak terlalu baik karena mendorong setiap aplikasi untuk melihat masalah yang
sulit dari penyelesaian konflik sinkronisasi dengan perangkat hardware yang berbagi. Juga
mengurangi portabilitas dari aplikasi yang terpisah. Pilihan kedua adalah
mengimplementasikan aturan manajemen dalam kernel system operasi, memusatkan tugas
manajemen dengan membebaskan dari aplikasi individual. Aplikasi masih harus dibangun
dengan system operasi khusus. Pilihan ketiga adalah portabilitas, fungsi manajemen ditulis
sebagai aplikasi yang terpisah sehingga dapat menyediakan interface ke program aplikasi
lain yang generic terhadap semua system operasi. Pilihan terakhir adalah model arsitektur
client-server seperti gambar di atas. Dalam prakteknya, pembagian dari arsitektur ini tidak
terlalu jelas dan setiap aplikasi interaktif atau kumpulan operasi aplikasi dalam system
window berbagi fitur dengan salah satu dari ketiga aritektur konseptual tersebut. Sehingga,
perlu ada satu komponen yaitu aplikasi atau proses yang terpisah bersama dengan
beberapa pendukung system operasi yang siap dan pendukung aplikasi yang hand-tuned
untuk menangani sumber bersama. Aplikasi yang dibuat untuk system window yang berbasis
pada model client-server tidak terlalu portable. Contoh dari system window berbasis
arsitektur client-server adalah system window X release 11 standar industri X11, dibuat di
MIT pertengahan 1980an.
Memprogram Aplikasi
Aplikasi yang interaktif umumnya user-driven, aksi aplikasi yang ada ditentukan oleh input
yang diterima dari user. Ada 2 paradigma pemrograman yang dapat digunakan untuk
mengorganisasikan alur control dalam aplikasi. Paradigma pertama adalah Read-Evaluation
Loop, yang internal terhadap program aplikasi itu sendiri. Contoh pada pemrograman
Macintosh. Server mengirim input user sebagai event terstruktur ke aplikasi client. Fokus
server yang penting adalah pada event dari client yang harus diarahkan. Aplikasi client
diprogram untuk membaca setiap event yang melaluinya dan menentukan semua perilaku
aplikasi khusus yang menghasilkan respon. Alur logika dari aplikasi client dalam pseudocode
dan diagram adalah :
repeat
read-event(myevent)
case myevent.type
type_1 :
do type_1 processing
type_2 :
do type_2 processing
.
.
type_n :
do type_n processing
end case
end repeat
Client
Application
Start
Read input
Server Device
Process input
Quit?
End
Aplikasi memiliki control yang lengkap terhadap proses event yang diterima. Pemrogram
harus mengeksekusi control melalui setiap kemungkinan event yang client akan terima.
Pada macintosh, MacApp.
Paradigma pemrograman lainnya adalah berbasis notifikasi, dimana loop control utama
untuk proses event tidak ada dalam aplikasi. Pusat notifier menerima event dari system
window dan menyaringnya ke program aplikasi dengan suatu program seperti terlihat pada
gambar di bawah. Program aplikasi menginformasikan ke notifier event apa yang penting
dan masing2 event mendeklarasikan satu prosedurnya sebagai callback sebelum mengubah
kontrolnya ke notifier. Ketika notifier menerima event dari system window, terlihat jika event
diidentifikasi oleh program aplikasi maka notifier akan melewatkan event dan control ke
prosedur callback yang diregistrasi untuk event. Setelah pemrosesan, prosedur callback
mengembalikan control ke notifier, memberitahukan untuk melanjutkan event yang diterima
atau meminta diakhiri.
Alur control terpusat di notifier yang membebaskan program aplikasi dari proses yang terlalu
banyak dari setiap proses event yang lewat dari system window. Misalkan program aplikasi
akan menghasilkan kotak dialog pre-empsi dan menginginkan adanya konfirmasi dari user
sebelum diproses. Dialog pre-empsi menghapus secara efektif semua aksi user kecuali yang
dibutuhkan user untuk memperbaikinya.
Application Notifier
Start
Register callbacks
with notifier
Call notifier
End
Read input
Send to
Process event
appropriate
callback
Callback
Request
quit ?
No
Yes
Pada paradigma loop read-evaluation, ini langsung dikerjakan. Jika kesalahan dideteksi,
aplikasi memulai loop read-evaluation yang ada dalam cabang statement case. Pada loop
tersebut, semua event yang tidak relevan dapat diterima dan dihapus. Pseudocode nya
adalah :
repeat
read-event(myevent)
case myevent.type
type_1 :
do type_1 processing
type_2 :
if (error-condition) then
repeat
read-event(myevent2)
case myevent2.type
type_1 :
.
.
type_n :
end case
until (end-condition2)
end if
…..
type_n :
do type_n processing
end case
until (end-condition)
Pada paradigma berbasis notifikasi, dialog pre-empsi tidak sederhana, karena alur control
diluar dari pemrogram aplikasi. Prosedur callback harus dimodifikasi semua untuk megenal
situasi dimana dialog pre-empsi diperlukan dan pada situasi tersebut dihapus semua event
yang dilewatkan kepadanya oleh notifier.
Model Seeheim berikut memasukkan aplikasi dan user dalam konteks dari system interaktif
meskipun tidak secara eksplisit karena hanya memodelkan komponen logika UIMS bukan
system interaktif secara keseluruhan. Dengan tidak membuat aplikasi secara eksplisit ada di
model, control dialog eksternal perlu diasumsikan. Dari sudut pandang pemrogram, model
Seeheim ini sesuai dengan adanya pembedaan antara lapis leksikal klasik, sintaksis dan
semantic dari sistem komputer. Masalah utama dari model Seeheim ini adalah meskipun
terlayani baik pada akhirnya, tetapi tidak terlihat bagaimana arah sebenarnya dari
kemungkinan UIMS distrukturkan. Gambar tersebut menunjukkan alasan efisiensi yang
mungkin dengan dilewatkan/ dihindarkannya komponen control dialog secara eksplisit
sehingga aplikasi memberikan respon semantic aplikasi yang lebih besar. Kotak kosong
tersebut ada karena logika tidak dipisahkan dari implementasi. Selain itu model Seeheim
tidak menginformasikan bagaimana membangun system interaktif yang besar dan kompleks
dari komponen yang lebih kecil.
View
Display
User
Model
Mouse
Controller
Keyboard
Model MVC menunjukkan semantic aplikasi, view menangani output grafik atau teks dari
aplikasi dan pengontrol menangani input. Perilaku dasar dari model ini adalah view dan
pengontrol ditempelkan/ dimasukkan dalam kelas objek umum dari Smalltalk yang
diwariskan dari instant dan dimodifikasi.
Model Coutaz berikut merupakan system interaktif berasitektur multi-agent, disebut model
Presentation-Application-Control (PAC). Model ini berbasis tiga serangkai pula, semantic
aplikasi dilambangkan dengan komponen abstraksi, input dan output digabungkan dalam
satu komponen presentasi dan ada komponen control eksplisit yang menangani dialog dan
menghubungkan aplikasi dan presentasi.
Control
Ada 3 perbedaan penting antara PAC dan MVC. Pertama adalah PAC menggabungkan
input dan output, MVC memisahkannya. PAC menyediakan komponen eksplisit yang
tugasnya melihat kekonsistenan antara abstraksi dan presentasi, dimana MVC tidak
menugaskan ke salah satu komponen. PAC tidak berhubungan dengan lingkungan
pemrograman apapun, secara kondusif merupakan pendekatan berorientasi objek.
Perbedaan yang terakhir ini yang membuat PAC mudah mengisolasi komponen control; PAC
lebih merupakan arsitektur konseptual dibandingkan MVC karena kurang implementation-
dependent.
Latihan
1. Yang bukan merupakan komponen dari UIMS adalah :
a. Presentasi c. Kontrol dialog
b. Interface aplikasi d. Viewer
3. Dalam model Seeheim, level sintaksis merupakan komponen logika UIMS untuk :
a. Input c. Kontrol dialog
b. Presentasi d. Interface aplikasi
Tinjauan
• User mempunyai perbedaan kebutuhan di waktu yang berbeda
• User support seharusnya :
o Tersedia tetapi tidak mencolok
o Akurat dan kuat
o Konsisten dan fleksibel
• Jenis-jenis user support :
o Command based methods
o Context-sensitive help
o Tutorial help
o On-line documentation
o Intelligent help
• Merancang user support harus memperhatikan :
o Presentasi
o Implementasi
Pendahuluan
Ada sebagian pendapat menyatakan bahwa system yang interaktif dijalankan tanpa
membutuhkan bantuan atau training. Hal ini mungkin ideal akan tetapi jauh dari kenyataan.
Pendekatan yang lebih membantu adalah dengan mengasumsikan bahwa user akan
membutuhkan bantuan pada suatu waktu dan merancang bantuan (help) ini ke dalam
system.
o Task-specific help
Membantu user menghadapi masalah atau tidak pasti dalam mengambil tindakan
memecahkan masalah yang khusus atau tidak pasti dalam mengaplikasikan tool.
o Full explanation
Suatu alat bantu atau perintah yang dapat membantu memahami secara lengkap.
Penjelasan ini mencakup informasi dimana user tidak membutuhkannya pada saat
itu.
o Tutorial
Khusus untuk user baru yang menyediakan perintah secara step by step bagaimana
menggunakan tool.
Setiap tipe pendukung user ini dibutuhkan oleh user pada saat yang berbeda berdasarkan
pengalaman user dengan system dan memenuhi kebutuhan yang berbeda. Ada banyak
informasi yang user inginkan – definisi, contoh, kesalahan yang dikenal dan informasi
memperbaiki kesalahan, opsi perintah dan lain-lain. Beberapa diantaranya ada yang tersedia
dalam perancangan interface nya sendiri dan ada yang dimasukkan dalam ‘bantuan’ atau
system pendukung.
Perbedaan utama antara system ‘bantuan’ dan dokumentasi adalah bahwa system ‘bantuan’
berorientasi terhadap masalah dan khusus, sedangkan dokumentasi berorientasi terhadap
system dan umum.
Availability
User dapat menggunakan bantuan pada setiap waktu selama berinteraksi dengan sistem.
User tidak perlu keluar dari aplikasi selama bekerja untuk membuka aplikasi bantuan.
Idealnya, bantuan berjalan konkuren dengan setiap aplikasi.
Consistency
Seperti diketahui bahwa user membutuhkan tipe yang berbeda dari bantuan untuk
digunakan pada tujuan yang berbeda. Hal ini dapat secara tidak langsung menyebabkan
IMK – IMPLEMENTATION SUPPORT & HELP DAN DOKUMENTASI 15 dari 25
Lecture Notes : Ida Ayu Yulie Primashanti
sistem bantuan tidak dapat bekerja. Sistem bantuan yang tersedia harus konsisten
terhadap semua sistem yang ada dan juga pada sistem itu sendiri. Bantuan online juga
harus konsisten dengan dokumentasi kertasnya, konsisten dalam isi, terminologi dan
bentuk presentasi. Pendukung user internal dalam aplikasi juga perlu konsisten terhadap
sistem.
Robustness
Sistem bantuan ini biasanya digunakan oleh orang yang sedang dalam kesulitan karena
system mempunyai perilaku yang tidak diharapkan atau mempunyai kesalahan. Hal ini
sangat penting dimana sistem bantuan seharusnya robust-kuat baik dalam hal
memperbaiki kesalahan dan perilaku yang tidak diharapkan.
Flexibility
Sistem bantuan yang fleksibel akan membuat setiap user dapat beinteraksi dalam
mencari sesuatu yang sesuai dibutuhkannya. Sistem bantuan yang fleksibel membantu
setiap user berinteraksi sesuai dengan keinginannya. Mulai dari perancangan sistem
bantuan yang interaktif secara modular melalui bantuan context-sensitive untuk membuat
sistem bantuan yang dapat diadaptasi atau pintar yang menginfer keahlian dan tugas
user.
Unobtrusiveness
System ini seharusnya tidak mencegah user dalam melanjutkan pekerjaannya atau
terpengaruh dengan aplikasi user. Pada satu saat, system bantuan teks pada interface
yang bukan window dapat menginterupsi pekerjaan user. Untuk menghindari ini
digunakan presentasi pada layar yang terpisah. Pada saat yang lain, system bantuan
pintar dalam menyediakan bantuan atas inisiatif sendiri, bukan permintaan user.
Command Assistance
Mungkin pendekatan yang umum untuk user support adalah menyediakan bantuan pada
level command, user yang membutuhkan bantuan pada command yang khusus dan
ditampilkan pada layar bantuan atau pada manual page yang menjelaskan tentang
command tersebut.
Tipe ini sederhana dan efisien jika user mengetahui apa yang user ingin ketahui dalam
mencari informasi yang lebih detail. Diasumsikan bahwa user mengetahui apa yang
dicari. Pada system computer yang kompleks, ada beberapa perintah yang user ketahui
dengan baik dan dapat menggunakannya dan ada pula beberapa perintah yang jarang
digunakan.
Command Prompts
Menyediakan bantuan ketika user menemukan kesalahan, biasanya dalam bentuk
prompt perbaikan. Prompt sangat berguna jika kesalahan sederhana misalnya kesalahan
sintaks, tetapi knowledge-pengetahuan dari perintah harus diasumsikan. Bentuk yang
lain dari command prompt adalah penggunaan menu dan icon yang dipilih. Ini
memerlukan bantuan ke memori seperti membuat secara eksplisit perintah2 apa yang
tersedia pada waktu tertentu. Ini diasumsikan juga memerlukan sejumlah pengetahuan
tentang kegunaan perintah sehingga pendukung tambahan masih diperlukan.
Context-sensitive Help
Berbentuk menu based system yang menyediakan bantuan pada menu option. Mulai dari
yang memiliki pengetahuan khusus dari user khusus hingga tersedianya kunci bantuan
sederhana yang diinterpretasikan sesuai dengan konteks yang akan dipanggil dan akan
ditampilkan. Contoh perintah help pada editor spy dan bantuan Ballons pada Macintosh.
On-line Tutorial
Mengijinkan user bekerja melalui aplikasi dasar dalam lingkungan percobaan. User dapat
melihat kemajuan sesuai dengan kecepatan dan dapat mengulangi bagian dari tutorial
yang diinginkan. User juga dapat merasakan bagaimana aplikasi bekerja dengan
bereksperimen langsung dengan contoh-contoh. Kebanyakan on-line tutorial tidak pintar
karena tidak mempunyai pengetahuan tentang user dan pengalaman user sebelumnya
ataupun domain atau bentuk pembelajaran. On-line tutorial tidak fleksibel dan sering
dilupakan, beberapa akan mengalami kesalahan dalam memperbaiki jawaban masalah,
sederhana karena tidak diformat untuk itu.
On-line Documentation
Membuat efektif dengan membuat dokumentasi di kertas tersedia di komputer. Ini
membuat materi tersedia terus menerus bersamaan dengan pada saat user bekerja
bahkan sejumlah besar user bekerja secara konkuren. Dokumentasi dibuat untuk
menyediakan deskripsi dari fungsionalitas dan perilaku system secara sistematik.
Bantuan pintar adalah kasus khusus dari kelas system interaktif yang umum, dikenal dengan
system pintar. Bantuan ini meliputi system pintar dengan domain khusus, system tutor yang
pintar dan interface adaptif umum.
Quantification
Model yang paling sederhana dari user modelling yang menggunakan jumlah tingkatan
dari keahlian yang akan merespon dalam cara yang berbeda. User ditempatkan pada
satu level dan berpindah diantara level lainnya berdasarkan pengukuran kuantifikasi dari
keahliannya pada waktu tersebut. Kegiatan2 yang berbeda dibobotkan dan user dinilai
berdasarkan bobot dari aktifitas yang diambil. Jika nilai melebihi batas tertentu, user
dipindahkan ke level keahlian yang lain dan system beradaptasi untuk itu. Contoh :
Mason mengadaptasikan presentasi prompt perintah dari level keahlian user.
Stereotypes
System mengelompokkan user sebagai anggota dari kategori user atau stereotype, yang
berbasiskan pada karakteristik user dan kemungkinan sederhana seperti membuat
perbedaan antara user baru dan user ahli. Atau yang lebih kompleks seperti membuat
stereotype yang berbasiskan pada lebih dari satu informasi.
Ada beberapa cara membuat stereotype. Salah satunya adalah menggunakan informasi
seperti perintah yang digunakan dan kesalahan untuk menggolongkan tipe user yang
berbeda, kemudian menggunakan aturan untuk mengidentifikasikan stereotype dimana
user berada. Pendekatan alternative adalah menggunakan pendekatan mesin
pembelajaran seperti jaringan saraf untuk mempelajari contoh dari perilaku user yang
bermacam2 dan menggolongkan user berdasarkan kedekatannya dalam mempelajari
pelajaran sebelumnya.
Overlay Models
Merupakan model yang ideal yang membandingkan perilaku user. Hasilnya ditampilkan
dalam dua model atau perbedaan. Keuntungan dari model ini dapat melihat secara pasti
bagian dari aktivitas suatu system. Tidak hanya system dapat menyadari apa yang user
lakukan, tetapi juga memiliki representasi perilaku yang optimal. Ini menyediakan suatu
benchmark dalam mengukur unjuk kerja user, dan jika user tidak mengambil aksi yang
optimal ada indikasi pada tipe help atau petunjuk yang diperlukan.
Pendekatan yang serupa adalah digunakan pada error based model dimana system
menyimpan rekaman kesalahan dan perilaku sebenarnya dari user serta
membandingkannya. Jika perilaku sesuai dengan kesalahan pada catalog, aksi yang
sama dapat dilakukan.
Manusia membutuhkan tipe bantuan yang berbeda bergantung pada pengetahuan dan
kondisi. Ini meliputi pengingat-reminder, bantuan dengan tugas khusus-task specific help
dan bantuan tutorial. Ada bukti mengindikasikan bahwa keahlian user mengikuti strategi
yang berbeda ketika memberi advis ke sesamanya. Ini mencakup menginfer keinginan
manusia dalam mencari bantuan dan nasehat pada level tersebut atau menyiapkan
sejumlah pemecahan terhadap masalah. Alternatifnya, menempatkan masalah dalam
konteks dan menyiapkan ‘contoh solusi’ berdasarkan konteks tersebut.
CC is an instance of COMPILE
COMPILE is a command
COMPILE is related to DEBUG
COMPILE is related to EDIT
Automatic debugger facilitates DEBUG
Masalah Lain
Inisiatif
Haruskah user mempertahankan pengawasan yang lengkap terhadap system,
Haruskah system langsung berinteraksi atau
Haruskan penggabungan dialog didukung ?
Effect
Para perancang seharusnya memperhatikan efek dari modelling dan adaptasi
Scope
Para perancang perlu memperhatikan scope dari bantuan dimana digunakan pada level
aplikasi atau system yang luas.
Masalah Presentasi
How is help requested ?
Pilihan pertama bagi perancang untuk membuat bagaiman bantuan dapat diakses oleh
user. Terdapat beberapa pilihan. Bantuan ini dapat berupa command, tombol fungsi yang
dapat memilih on atau off atau aplikasi yang terpisah.
Masalah Implementasi
Para perancang harus membuat keputusan untuk implementasi berupa hambatan/ batas
fisik maupun pilihan yang tersedia untuk user. Keputusan ini sudah termasuk dalam
pertanyaan : akankah bantuan merupakan perintah system operasi, apakah berbentuk meta-
command atau aplikasi. Hambatan fisik apa yang membuat mesin menentukan screen
space, kapasitas memori dan kecepatan. Kecepatan adalah hal yang penting karena waktu
respon yang lambat untuk membuat system tidak digunakan meskipun sangat baik
dirancang. Akan lebih baik menyediakan fasilitas bantuan sederhana yang merespon
dengan cepat dibandingkan yang canggih yang membutuhkan waktu dalam memberikan
solusi.
Masalah lain adalah bagaimana struktur data bantuan : apakah berbentuk single file,
hierarchy file atau database. Ini bergantung pada tipe dari bantuan tersebut dibuat, tetapi
setiap struktur harus fleksibel dan dapat diperluas – system tidak statis dan topic baru
tidak terhindarkan untuk ditambahkan ke system bantuan. Struktur data yang digunakan
akan menentukan dan menyediakan tipe pencarian atau strategi navigasi.
Latihan
1. Jenis bantuan (HELP) yang khusus menyediakan perintah secara step-by-step terhadap
user baru adalah :
a. Full explanation c. Quick reference
b. Task-specific help d. Tutorial
4. Ada empat jenis bantuan yang dibutuhkan user. Yang termasuk Quick reference
digunakan sebagai:
a. Membantu user menghadapi masalah atau tidak pasti mengambil tindakan dalam
memecahkan masalah yang khusus.
b. Untuk user baru yang menyediakan perintah secara step by step
c. Pengingat untuk user dari suatu yang detail yang secara dasar sangat familiar dan
biasa digunakan.
d. Alat bantu atau perintah yang dapat membantu memahami secara lengkap.
5. Ada empat jenis bantuan yang dibutuhkan user. Yang termasuk tutorial digunakan
sebagai:
a. Membantu user menghadapi masalah atau tidak pasti mengambil tindakan dalam
memecahkan masalah yang khusus.
b. Untuk user baru yang menyediakan perintah secara step by step
c. Pengingat untuk user dari suatu yang detail yang secara dasar sangat familiar dan
biasa digunakan.
d. Alat bantu atau perintah yang dapat membantu memahami secara lengkap