Bài giảng Phương tiện tương tác kỹ thuật số: Bài 6

Bài 6

Giảng viên: Trần Thị Kim Chi

Các lỗi giao diện

Các phương pháp đánh giá

Đánh giá theo kinh nghiệm(heuristic)

Kiểm thử GUI bởi người sử dụng

Kiểm thử bằng phương pháp duyệt dịch vụ

Tổng kết

Các lỗi giao diện

 Giao diện Alt –Tab trong Microsoft

Window  Chức năng tương tự có thể được tìm thấy

trong các hệ thống khác như KDE, Gnome và Mac OS

 Không có tính gợi ý (affordance)  Giao diện Alt-Tab được thiết kế như phím tắt

(shortcut)

 Đảm bảo tính đơn giản về đồ họa và thao tác  Hiệu quả khi chuyển đổi từ cửa sổ này sang

cửa sổ khác trên màn hình

Các lỗi giao diện

Lỗi thiết kế

09/20/16

Các lỗi giao diện

Lỗi thiết kế

Sign-In Page:

1. Good visibility (centered, obvious sign- in spot)

09/20/16

Các lỗi giao diện

Lỗi thiết kế

Opening Page: ·Attention - Info related to most common tasks ·Bridged the Gulf of Execution ·Visibility good- Left pane never changes- even when message is open

09/20/16

Các lỗi giao diện

Lỗi thiết kế

 Menu thích nghi của MS

Office  Khởi đầu menu đơn chỉ có

các items thông dụng

 Khi click chuột trên mũi tên dưới menu thì mọi item sẽ hiển thị

 Menu thích nghi chỉ hiển thị

các items hay sử dụng nhất và mới được sử dụng

 Đáp ứng tính đơn giản và

hướng nhiệm vụ

 Thiếu tính dự báo trước khi

09/20/16

menu thay đổi

Các lỗi giao diện

Các phương pháp đánh giá - Evaluation

• Đánh giá là quá trình sử dụng các phương thức khác

nhau để xác định quá trình thiết kế có đảm bảo yêu cầu của một hệ thống đã đưa ra không.

• Thiết kế và đánh giá là hai quá trình lặp được tiến hành

một cách liên tiếp nhằm giải thích các câu hỏi:

– Why: để kiểm tra các yêu cầu và sở thích của người dùng. – What: kiểm tra các chức năng của hệ thống, của các giao

diện có hoạt động tốt không. – Where: quá trình này diễn ra ở đâu – When: trong suốt giai đoạn thiết kế; sản phẩm hoàn thành

có được đánh giá để đưa ra các thông tin về sản phẩm mới không

Các phương pháp đánh giá

Các phương pháp đánh giá • Đánh giá giao diện (UI) theo phương pháp Heuristic

– Kiểm tra một cách hệ thống thiết kế giao diện so với tập các

nguyên tắc tính sử dụng được đã nhận biết trước

• Đánh giá UI bởi người sử dụng (User Testing)

– Đội ngũ đánh giá: Các chuyên gia

– Người sử dụng thử nghiệm GUI – Cho phép quan sát trực tiếp người sử dụng khi họ đang sử

• Đáng giá UI theo phương pháp duyệt nhiệm vụ

(Cognitive Walkthrough)

dụng ứng dụng

– Đánh giá theo tập các nhiệm vụ và đánh giá tính dễ hiểu và

tính dễ học của chúng

Đánh giá theo kinh nghiệm(heuristic)

• Được phát triển bởi Developed Jacob Nielsen vào năm

1990.

• Dựa trên cơ sở giải quyết vấn đề bằng cách đánh giá và tìm giải pháp qua thử nghiệm từ phân tích kinh nghiệm sử sụng của 249 vấn đề

• Heuristics thường dùng để đánh giá cho các thiết bị

mobile, wearables, virtual worlds, etc.

Đánh giá theo kinh nghiệm(heuristic)

Nhắc lại 10 heuristics của Nielsen • Đáp ứng mong đợi

– Phù hợp thế giới thực – Nhất quán và chuẩn – Trợ giúp và tài liệu • Người sử dụng làm chủ

• Lỗi

– Người sử dụng điều khiển các ứng dụng và tự do – Tính trực quan của trạng thái hệ thống – Mềm dẻo và hiệu quả

• Tính đơn giản

– Tránh lỗi – Nhận dạng, không hồi tưởng – Báo cáo lỗi, phát hiện và khắc phục

– Thiết kế đẹp và tối thiểu

Đánh giá theo kinh nghiệm(heuristic)

Kỹ thuật đánh giá Heuristic • Các bước đánh giá

– Người đánh giá khám phá UI, đánh giá nó trên cơ sở

heuristics

– Lập ra danh sách các vấn đề phát hiện liên quan đến tính

• Kỹ thuật

sử dụng được

– Cần phải diễn giải tại sao nó vi phạm heuristics – Liệt kê đầy đủ các vấn đề mà đã tìm thấy trong bảng – Kiểm tra giao diện ít nhất 2 lần – Hiệu chỉnh mọi vấn đề trong GUI nhờ các hướng dẫn thiết kế đã nghiên cứu (không giới hạn bởi 10 heiristics của Nielsen

Đánh giá theo kinh nghiệm(heuristic) Đánh giá Heuristic • Đánh giá heutistic theo phương pháp của

Nielssen : (10 đánh giá)  Theo các nhà nghiên cứu thì pp của

Nielssen là pp ít tốn kém nhất

 Đánh giá heuristic là pp đánh giá mà các

chuyên gia đánh giá về tính sử dụng được – những hiểu biết – đã sử dụng – suy nghĩ nhiều về thiết kế giao diện

 Các bước cơ bản đánh giá heuristic khá

đơn giản

09/20/16

Đánh giá theo kinh nghiệm(heuristic) Ví dụ về đánh giá heuristic

Ví dụ Hãy thử phân tích một số phần tử để tìm ra các vấn đề vi phạm về tính sử dụng được và chúng cần hiệu chỉnh gì

09/20/16

Đánh giá theo kinh nghiệm(heuristic) Ví dụ về đánh giá heuristic

09/20/16

Đánh giá theo kinh nghiệm(heuristic)

Continue Shopping

09/20/16

Đánh giá theo kinh nghiệm(heuristic)

Tiến trình đánh giá Heuristic • Thông báo

– Tổ chức gặp gỡ giữa đội ngũ thiết kế và những người đánh

giá

– Giới thiệu ứng dụng – Giải thích về số đông người sử dụng, nghiệp vụ và các kịch

• Đánh giá

bản

– Người đánh giá làm việc độc lập – Viết báo cáo hay người quan sát ghi âm lại các bình luận của

người đánh giá

– Tập trung vào phát hiện vấn đề, không xếp hạng tính nguy hại

nó tại thời điểm này

– Mỗi người đánh giá làm việc ít nhất từ 1-2 giờ

Đánh giá theo kinh nghiệm(heuristic)

Tiến trình đánh giá Heuristic • Xếp hạng lỗi nghiêm trọng của UI

– Người đánh giá xếp mức ưu tiên cho mọi vấn đề tìm ra (không

chỉ của riêng mình)

• Bàn bạc

– Giải thích ý nghĩa cách xếp hạng người đánh giá

– Người đánh giá và đội ngũ thiết kế trao đổi các kết quả và

phương pháp giải quyết vấn đề

Đánh giá theo kinh nghiệm(heuristic)

• Đánh giá Heuristics cho websites (Budd, 2007) tập trung

vào:

– Tính rõ ràng – Sự phức tạp – Ngữ cảnh người dùng – Độ tin cậy và sự thỏa mãn của người dùng

Đánh giá theo kinh nghiệm(heuristic)

Kinh nghiệm duyệt Web của người dùng • Điều hướng dễ dàng. • Cung cấp kịch bản trợ giúp người dùng. • Các chức năng phải rõ ràng và cụ thể. • Dựa vào 3 câu hỏi sau:

– Các chức năng có đem đến lới ích cho người dùng không? – Có các thông báo hay phản hồi cho người dùng khi duyệt Web

không?

– Người dùng có chọn chức năng đúng với các phản hồi hay

yêu cầu của Website không?

Đánh giá theo kinh nghiệm(heuristic)

Kinh nghiệm duyệt web của người quản trị • Dễ dàng thay đội, cập nhập thông tin của Website không • Dễ dàng thực hiện các chức năng quản lý các thành

viên không

• …

Đánh giá theo kinh nghiệm(heuristic)

Phân tích • Đánh giá lưu lượng người truy cập vào Website • Các mục nào người sử dụng hay vào • Đánh giá các chức năng tìm kiếm • Số lần của 1 người sử dụng viếng thăm theo ngày, tuần,

tháng,…

Đánh giá theo kinh nghiệm(heuristic)

Social action analysis (Perer & Shneiderman, 2008)

Đánh giá theo kinh nghiệm(heuristic)

Response times for keystroke level operators (Card et al., 1983)

Time (sec)

Operator K

0.22 0.28 0.08 1.20 0.40

P1 H

0.20 0.40

M R(t)

1.35 t

Description Pressing a single key or button Average skilled typist (55 wpm) Average non-skilled typist (40 wpm) Pressing shift or control key Typist unfamiliar with the keyboard Pointing with a mouse or other device on a display to select an object. This value is derived from Fitts’ Law which is discussed below. Clicking the mouse or similar device Bring ‘home’ hands on the keyboard or other device Mentally prepare/respond The response time is counted only if it causes the user to wait.

Đánh giá theo kinh nghiệm(heuristic)

Summing together

Đánh giá theo kinh nghiệm(heuristic)

Using KLM to calculate time to change gaze (Holleis et al., 2007)

Đánh giá theo kinh nghiệm(heuristic)

Fitts’ Law (Fitts, 1954)

• Luật Fitts dự đoán thời gian để chọn một đối tượng bằng chuột hay phím hay thiết bị khác dựa vào khoảng cách tới các đối tượng và kích thước của các đối tượng đó

Đánh giá theo kinh nghiệm(heuristic)

Một số điểm lưu ý khi đánh giá Heuristic • Kết hợp tốt giữa người phát triển và những người quản

lý.

• Các báo cáo phải bao gồm đầy đủ ưu, nhược điểm của

giao diện

– Ví dụ: “Good: Toolbar icons are simple, with good constrast

add few colors(minimalist design)” • Văn phong sử dụng phải lịch sự

• Báo cáo phải cụ thể

– Không viết “The menu organization is a complete mess” – Nên viết “menus are not organized by function”

– Không viết “text is unreadable” – Nên viết ”text is too small, and has poor contrast (black text on

dark green background”)

4 Kiểm thử GUI bởi người sử dụng

Người sử dụng kiểm thử

Task analysis Design heuristic

Heuristic evaluation User testing

Protyping Toolkits

09/20/16

Kiểm thử GUI bởi người sử dụng

Phòng thí nghiệm kiểm thử • Môi trường kiểm thử

– Tổ chức phòng làm việc – Bên ngoài có biển hiệu “User test in process – DO not disturb” – Ngắt điện thoại (Cố định và di động) – Đảm bảo ánh sáng – Không khí trong lành (không có cồ rượu)

Kiểm thử GUI bởi người sử dụng

Phòng thí nghiệm kiểm thử • Các thiết bị kiểm thử

– Máy quay video số (minDV, DVD) – Chân máy quay – Microphone loại tốt – Tai nghe – Gương (để thu hút nét mặt của người kiểm thử) – Đèn (đèn bàn, đèn quay video) – Màn hình màu (để xem ảnh máy quay) – Máy ghi DVD, video – Dây nguồn điện – Biển hiệu – Phần mềm hay mẫu giấy ghi chép

Kiểm thử GUI bởi người sử dụng

Phòng thí nghiệm kiểm thử

Kiểm thử GUI bởi người sử dụng

Phòng thí nghiệm kiểm thử

Kiểm thử GUI bởi người sử dụng

Usability lab with observers watching a user & assistant

www.idbook.com

Kiểm thử GUI bởi người sử dụng

Các bước kiểm thử bởi người sử dụng: Gồm 6 bước 1. Phát triển kế hoạch kiểm thử  Mô tả mục đích kiểm thử  Lý lịch người sử dụng  Phương pháp  Danh sách nhiệm vụ

1. Chọn lựa người tham gia

 Chọn người sử dụng  Phân nhóm  Quản lý CSDL người sử dụng

09/20/16

Kiểm thử GUI bởi người sử dụng

3. Chuẩn bị vật liệu kiểm thử

1. Kịch bản nhiệm vụ 2. Mẫu thu thập dữ liệu 3. Hướng dẫn thảo luận 4. Các câu hỏi sau kiểm thử 5. Lập danh sách các kiểm thử sẽ thực hiện 6. Thực hiện kiểm thử thí điểm (Pilot Test) 7. Thực hiện kiểm thử thật (Real Test) 8. Phân tích và báo cáo cuối cùng

09/20/16

Kiểm thử GUI bởi người sử dụng

4. Thực hiện kiểm thử thí điểm (Pilot Test)

 Các lệnh mơ hồ  Ước lượng thời gian  Tiêu chí mơ hồ  Câu hỏi phỏng vấn không đúng mục tiêu

09/20/16

Kiểm thử GUI bởi người sử dụng

5. Thực hiện kiểm thử thật (Real Test)

 Không nhắc người sử dụng khi kiểm thử  Chỉ hỗ trợ khi người sử dụng gặp phải vần

đề nghiêm trọng

 Lưu trữ lại màn hình khi gặp vấn đề

09/20/16

Kiểm thử GUI bởi người sử dụng

6. Phân tích và báo cáo cuối cùng

 Tổng hợp các dữ liệu : thời gian hoàn thành, số % người sử dụng thực hiện thành công, vẽ biểu đồ tỷ lệ

 Phân tích dữ liệu : nhận biết lỗi và mức độ khó

của chúng, chuẩn đoán nguồn gốc lỗi, gán mức độ nghiêm trọng cho các lỗi

 Báo cáo tổng kết cần bao gồm : trang tiêu đề, mô tả môi trường test, tóm tắt việc thực hiện, mô tả test, dữ liệu người sử dụng test, danh sách các điểm tốt được tìm ra…

 Các phụ lục

09/20/16

Kiểm thử GUI bởi người sử dụng

Các bước kiểm thử bởi người dùng • Chuẩn bị vật liệu kiểm thử

– Kịch bản nhiệm vụ – Mẫu thu thập dữ liệu – Hướng dẫn thảo luận – Các câu hỏi sau kiểm thử – Lập danh sách các kiểm thử sẽ thực hiện – Thực hiện kiểm thử thí điểm (pilot test) – Thực hiện kiểm thực thật (Real Test) – Phân tích và báo cáo cuối cùng

Kiểm thử GUI bởi người sử dụng

Portable equipment for use in the field

Thiết bị dễ mang đi

www.idbook.com

Kiểm thử GUI bởi người sử dụng

www.idbook.com

Kiểm thử GUI bởi người sử dụng

Mobile head-mounted eye tracker

www.idbook.com

Kiểm thử GUI bởi người sử dụng

Một vài dữ liệu để test

(cid:0) Thời gian để hoàn thành công việc theo lý thuyết (cid:0) Thời gian thật để hoàn thành công việc (cid:0) Các lỗi trong mỗi lần test (cid:0) Số các bước để thực hiện một chức năng của hệ thống (cid:0) Số các lỗi do người sử dụng gây ra (cid:0) Số người sử dụng gây ra cùng một lỗi (cid:0) Số người sử dụng vào thành công một chức năng

www.idbook.com

Kiểm thử GUI bởi người sử dụng

What does this data tell you?

high values indicate more variation

Playing against computer Playing against friend

Mean St. Dev. Mean St. Dev.

Boring Challenging Easy Engaging Exciting Frustrating Fun 2.3 3.6 2.7 3.8 3.5 2.8 3.9 0.949 1.08 0.823 0.422 0.527 1.14 0.738 1.7 3.9 2.5 4.3 4.1 2.5 4.6 0.949 0.994 0.850 0.675 0.568 0.850 0.699

Source: Mandryk and Inkpen (2004).

Kiểm thử GUI bởi người sử dụng

Có bao nhiêu người tham gia quá trình kiểm thử GUI bởi người sử dụng • Số người phụ thuộc vào – Chương trình Test; – Số người Test có sẵn; – Chi phí cho quá trình tests. • Thường từ 5 – 10 người tham gia.

Kiểm thử GUI bởi người sử dụng

Name 3 features for each that can be tested by usability testing

iPad

www.idbook.com

Kiểm thử GUI bởi người sử dụng

UbiFit Garden: An in the wild study

Rối, lộn xộn

www.idbook.com

Kiểm thử GUI bởi người sử dụng

Why study skiers in the wild ?

Jambon et al. (2009) User experience in the wild. In: Proceedings of CHI ’09, ACM Press, New York,

p. 4070-4071.

Kiểm thử GUI bởi người sử dụng

Crowdsourcing-when might you use it?

Kiểm thử GUI bởi người sử dụng

Evaluation methods

Method

Controlled settings

Natural settings

Without users

Observing

Asking users

Asking experts

Testing

Modeling

Kiểm thử bằng phương pháp duyệt nhiệm vụ

• Các tham số đầu vào

– Mô tả prototype của hệ thống

– Mô tả nhiệm vụ mà người sử dụng thực hiện

trên hệ thống để đánh giá

– Danh sách viết đầy đủ các hành động (kịch

bản) cần thiết

• Người sử dụng duyệt qua trình tự các hành động để đưa ra các nhận xét về tính sử dụng được của hệ thống

Kiểm thử bằng phương pháp duyệt dịch vụ

 Cần trả lời các câu hỏi

 Người sử dụng cố gắng có được hành động

đúng

 Người sử dụng nhận ra rằng họ đang hành

động đúng

 Người sử dụng kết hợp các hành động đúng

với hiệu ứng đạt được

 Nếu hành động đúng được thực hiện, người sử dụng thấy được bước tiến trong việc giải quyết nhiệm vụ

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ

Ví dụ này mô tả giao diện của một máy tự động bán vé tàu hỏa Kịch bản : Nick đi thăm 1 người bạn ở Edison và muốn mua chiếc vé một chiều. Nick chỉ có $5 trong túi Câu hỏi : Người sử dụng muốn đạt được mục đích ?  Mua vé 1 chiều đến Edison

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ

 Phương pháp này được thực hiện thông qua trả lời các câu hỏi về nhiệm vụ để tìm ra chỗ khuyết điểm của giao diện. Các câu trả lời theo trình tự như sau  Đặt câu hỏi cho từng goal

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ

1. Hành động hiển nhiên đối với người sử

dụng ?

 Có, NSD nhận rõ 4 goal 2. NSD kết nối được mô tả hành động

đúng với ý định của họ

 Có, nhãn bước 1 3. Người sử dụng nhận biết đáp ứng của hệ thống (để biết lựa chọn đúng hay sai)  Có, nếu phím Edison được chiếu sáng

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ

• Lỗi xảy ra ở goal thứ 3

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ

 Trường hợp thông thường, thực hiện

hành động với bước 4 để kết thúc mua vé  Tuy nhiên xảy ra 2 trường hợp như sau  Nick nhận thấy không đủ tiền mua vé trước

khi bỏ tiền vào máy

 Nick nhận thấy không đủ tiền khi đã bỏ $5

vào máy

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ

 Giải quyết trường hợp không đủ tiền, NSD muốn hùy tác vụ và lấy lại tiền  Hành động hiển nhiên với NSD ?  Không, thiết kế cần bổ sung phần tử giao

diện mới để rõ ràng hơn

09/20/16

Kiểm thử bằng phương pháp duyệt nhiệm vụ