TIÊU CHUẨN QUỐC GIA TCVN 7318-13:2015 (ISO 9241-13:1998) VỀ ECGÔNÔMI – YÊU CẦU ECGÔNÔMI ĐỐI VỚI CÔNG VIỆC VĂN PHÒNG CÓ SỬ DỤNG THIẾT BỊ HIỂN THỊ ĐẦU CUỐI (VDT) – PHẦN 13: HƯỚNG DẪN NGƯỜI SỬ DỤNG

TIÊU CHUẨN QUỐC GIA

TCVN 7318-13:2015

ISO 9241-13:1998

ECGÔNÔMI – YÊU CẦU ECGÔNÔMI ĐỐI VỚI CÔNG VIỆC VĂN PHÒNG CÓ SỬ DỤNG THIẾT BỊ HIỂN THỊ ĐẦU CUỐI (VDT) – PHẦN 13: HƯỚNG DẪN NGƯỜI SỬ DỤNG

Ergonomic requirements for office work with visual display terminals (VDTs) – Part 13: User guidance

Mục lục

Lời nói đầu

Lời giới thiệu

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ định nghĩa

4  Áp dụng tiêu chuẩn này

5  Các khuyến nghị hướng dẫn chung

6  Dấu nhắc

7  Phản hồi

8  Thông tin trạng thái

9  Quản lý lỗi

10  Hỗ trợ trực tuyến

Phụ lục A (tham khảo) Mẫu quy trình phục vụ việc đánh giá khả năng ứng dụng và liên kết

Phụ lục B (tham khảo) Thư mục tài liệu tham khảo

Lời nói đầu

TCVN 7318-13:2015 hoàn toàn tương đương với ISO 9241-13:1998.

TCVN 7318-13:2015 do Ban kỹ thuật tiêu chuẩn quốc gia TCVN/TC 159 Ecgônômi biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

Bộ TCVN 7318 (ISO 9241), Ecgônômi – Yêu cầu ecgônômi đối với công việc văn phòng có sử dụng thiết bị hiển thị đầu cuối (VDT) gồm các phần sau:

– TCVN 7318-1:2013 (ISO 9241-1:1997/Adm 1:2001), Phần 1: Giới thiệu chung;

– TCVN 7318-2:2013 (ISO 9241-2:1992), Phần 2: Hướng dẫn các yêu cầu nhiệm vụ;

– TCVN 7318-3:2002 (ISO 9241-3:1992), Phần 3: Yêu cầu về hiển thị;

– TCVN 7318-4:2013 (ISO 9241-4:1998), Phần 4: Yêu cầu về bàn phím;

– TCVN 7318-5:2013 (ISO 9241-5:1998), Phần 5: Yêu cầu về bố trí vị trí và tư thế làm việc;

– TCVN 7318-6:2013 (ISO 9241-6:1999), Phần 6: Hướng dẫn về môi trường làm việc;

– TCVN 7318-11:2015 (ISO 9241-11:1998), Phần 11: Hướng dẫn về tính khả dụng;

– TCVN 7318-12:2015 (ISO 9241-12:1998), Phần 12: Trình bày thông tin;

– TCVN 7318-13:2015 (ISO 9241-13:1998), Phần 13: Hướng dẫn người sử dụng.

Bộ ISO 9241 về Ergonomic requirements for office work with visual display terminals (VDTs) còn có các phần sau:

– ISO 9241-14:1997, Part 14: Menu dialogues;

– ISO 9241-15:1997, Part 15: Command dialogues;

– ISO 9241-16:1999, Part 16: Direct manipulation dialogues.

Ngoài ra bộ ISO 9241 về Ergonomics of human-system interaction còn có các phần sau:

– ISO 9241-20:2008, Part 20: Accessibility guidelines for information/ communication technology (ICT) equipment and services;

– ISO 9241-110:2006, Part 110: Dialogue principles;

– ISO 9241-129:2010, Part 129: Guidance on software individualization;

– ISO 9241-143:2012, Part 143: Forms;

– ISO 9241-151:2008, Part 151: Guidance on World Wide Web user interfaces;

– ISO 9241-154:2013, Part 154: Interactive voice response (IVR) applications;

– ISO 9241-171:2008, Part 171: Guidance on software accessibility;

– ISO 9241-210:2010, Part 210: Human-centred design for interactive systems;

– ISO 9241-300:2008, Part 300: Introduction to electronic visual display requirements;

– ISO 9241-302:2008, Part 302: Terminology for electronic visual displays;

– ISO 9241-303:2011, Part 303: Requirements for electronic visual displays;

– ISO 9241-304:2008, Part 304: User performance test methods for electronic visual displays;

– ISO 9241-305:2008, Part 305: Optical laboratory test methods for electronic visual displays;

– ISO 9241-306:2008, Part 306: Field assessment methods for electronic visual displays;

– ISO 9241-307:2008, Part 307: Analysis and compliance test methods for electronic visual displays;

– ISO 9241-308:2008, Part 308: Surface-conduction electron-emitter displays (SED);

– ISO 9241-309:2008, Part 309: Organic light-emitting diode (OLED) displays;

– ISO 9241-310:2010, Part 310: Visibility, aesthetics and ergonomics of pixel defects;

– ISO 9241-331:2012, Part 331: Optical characteristics of autostereoscopic displays;

– ISO 9241-400:2007, Part 400: Principles and requirements for physical input devices;

– ISO 9241-410:2008, Part 410: Design criteria for physical input devices;

– ISO 9241-4220:2011, Part 420: Selection of physical input devices;

– ISO 9241-910:2011, Part 910: Framework for tactile and haptic interaction;

– ISO 9241-920:2009, Part 920: Guidance on tactile and haptic interactions.

Lời giới thiệu

Tiêu chuẩn này đề cập đến các khía cạnh hướng dẫn người sử dụng của giao diện người sử dụng phần mềm.

Mục đích chính của hướng dẫn người sử dụng là nhằm hỗ trợ tương tác của người sử dụng với hệ thống bằng cách

– tăng cường hiệu quả của việc sử dụng hệ thống;

– tránh gánh nặng tâm lý không cần thiết;

– cung cấp hỗ trợ cho người sử dụng nhằm quản lý các tình huống gặp lỗi;

– cung cấp hỗ trợ cho người sử dụng ở các cấp độ kỹ năng khác nhau.

Tiêu chuẩn này phục vụ các đối tượng người sử dụng sau đây:

– Nhà thiết kế hướng dẫn người sử dụng, người sẽ áp dụng tiêu chuẩn này trong suốt quá trình phát triển;

– Các nhà thiết kế công cụ triển khai hướng dẫn người dùng được sử dụng thông qua hộp thoại người thiết kế;

– Người mua, là người sẽ tham khảo tiêu chuẩn này trong quá trình mua sản phẩm, và những người sử dụng cuối cùng sẽ hưởng những lợi ích được nêu ra trong tiêu chuẩn này; và

– Những người chịu trách nhiệm đảm bảo sản phẩm đáp ứng được các khuyến nghị nêu ra trong tiêu chuẩn này.

Người hưởng lợi cuối cùng của tiêu chuẩn này sẽ là người sử dụng cuối cùng của thiết bị đầu cuối có màn hình hiển thị. Các khuyến nghị về ecgonomi đưa ra trong tiêu chuẩn này xuất phát từ nhu cầu của người sử dụng cuối cùng. Có thể người sử dụng cuối cùng sẽ không đọc, thậm chí không biết đến sự tồn tại của tiêu chuẩn này, nhưng việc áp dụng nó sẽ làm cho giao diện người dùng khả dụng hơn, nhất quán hơn và mang lại hiệu quả cao hơn.

Việc áp dụng tiêu chuẩn này gồm sự hiểu biết về người sử dụng dự tính, môi trường và nhiệm vụ của người sử dụng. Nhiệm vụ của người sử dụng cần được liệt kê và các nhiệm vụ chính, được xác định là những nhiệm vụ thường xuyên và quan trọng nhất, cần được nhận dạng một cách rõ ràng.

Các khuyến nghị về cách sử dụng tiêu chuẩn này có thể xem tại phần tham khảo Phụ lục A.

Đối với các nguyên nhân mang tính thực tế, cấu trúc dưới đây được chọn để trình bày các khuyến nghị hướng dẫn người sử dụng:

– Các khuyến nghị hướng dẫn người sử dụng (xem Điều 5),

– Gợi ý (xem Điều 6),

– Phản hồi (xem Điều 7),

– Thông tin trạng thái (xem Điều 8),

– Quản lý lỗi (xem Điều 9),

– Hỗ trợ trực tuyến (xem Điều 10).

ECGÔNÔMI – YÊU CẦU ECGÔNÔMI ĐỐI VỚI CÔNG VIỆC VĂN PHÒNG CÓ SỬ DỤNG THIẾT BỊ HIỂN THỊ ĐẦU CUỐI (VDT) – PHẦN 13: HƯỚNG DẪN NGƯỜI SỬ DỤNG

Ergonomic requirements for office work with visual display terminals (VDTs) – Part 13: User guidance

1  Phạm vi áp dụng

Tiêu chuẩn này cung cấp khuyến nghị cho các thuộc tính hướng dẫn người sử dụng của các giao diện người sử dụng phần mềm và sự đánh giá của họ. Hướng dẫn người sử dụng trong tiêu chuẩn này là một phần bổ trợ thông tin cho đối thoại người sử dụng máy tính thông thường, được cung cấp cho người dùng dựa trên yêu cầu hoặc được hệ thống tự động cung cấp. Ngoài hướng dẫn chung đưa ra trong tiêu chuẩn này, các khuyến nghị liên quan đến hướng dẫn người sử dụng đối thoại riêng biệt được cung cấp trong các tiêu chuẩn: TCVN 7318-12 (ISO 9241-12), ISO 9241-14, ISO 9241-15, ISO 9241-16 và ISO 9241-17.

Tiêu chuẩn này có thể áp dụng được cho các nội dung tương tác, hỗ trợ người sử dụng trong việc khắc phục các điều kiện bị lỗi. Hướng dẫn người sử dụng có trong tiêu chuẩn này sẽ bao gồm các khuyến nghị đối với các gợi ý, phản hồi và trạng thái, quản lý lỗi và hỗ trợ trực tuyến cũng như các khuyến nghị chung phổ biến đối với tất cả các dạng hướng dẫn người sử dụng kể trên.

Người sử dụng có thể được hỗ trợ cung cấp thông qua các phương tiện khác (ví dụ: hướng dẫn trực tuyến, tài liệu trực tuyến, hỗ trợ thực hiện hệ thống thông minh) những dạng hỗ trợ này không được đề cập trong tiêu chuẩn này.

Các khuyến nghị trong tiêu chuẩn này được hình thành độc lập với các ứng dụng, môi trường hoặc công nghệ triển khai. Chúng tương đương với các tình huống điển hình bao gồm các yêu cầu đặc biệt về thông tin và thao tác thực hiện.

Cũng như đối với các phần khác của bộ ISO 9241, tiêu chuẩn này có thể được áp dụng toàn bộ hoặc chỉ từng phần. Ví dụ các ứng dụng không có hỗ trợ khả năng duyệt sẽ không phải tuân theo các khuyến nghị liên quan đến lớp hướng dẫn người sử dụng này.

2  Tài liệu viện dẫn

Các tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

TCVN 7318-12:2015 (ISO 9241-12:1998), Yêu cầu ecgônômi đối với công việc văn phòng có sử dụng thiết bị hiển thị đầu cuối (VDT)- Phần 12: Trình bày thông tin).

ISO 9241-14:1997, Ergonomic requirements for office work with visual display terminals (VDTs) – Part 14: Menu dialogues. (Các Yêu cầu ecgônômi đối với công việc văn phòng có sử dụng thiết bị hiển thị đầu cuối (VDT) – Phần 14: Đối thoại bảng menu).

ISO 9241-15:1997, Ergonomic requirements for office work with visual display terminals (VDTs) – Part 15: Command dialogues. (Yêu cầu ecgônômi đối với công việc văn phòng có sử dụng thiết bị hiển thị đầu cuối (VDT) – Phần 15: Đối thoại câu lệnh).

ISO 9241-16:1999, Ergonomic requirements for office work with visual display terminals (VDTs) – Part 16: Direct manipulation dialogues. (Yêu cầu ecgônômi đối với công việc văn phòng có sử dụng thiết bị hiển thị đầu cuối (VDT) – Phần 16: Đối thoại thao tác trực tiếp).

ISO 9241-17:1998, Ergonomic requirements for office work with visual display terminals (VDTs) – Part 17: Form filling dialogues. (Yêu cầu ecgônômi đối với công việc văn phòng có sử dụng thiết bị hiển thị đầu cuối (VDT) – Phần 17: Đối thoại điền vào mẫu).

3  Thuật ngữ định nghĩa

Trong tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau

3.1

Hỗ trợ khả năng trình duyệt (browsable help)

Hỗ trợ trong đó truy nhập độc lập với tình huống nhiệm vụ đang thực hiện. Các chủ đề hỗ trợ có thể được truy nhập theo lệnh và trình tự do người sử dụng đưa ra.

3.2

Hỗ trợ tình huống nhạy cảm (contex-sensitive help)

Hỗ trợ trong đó nội dung hỗ trợ hoặc phạm vi chủ đề hỗ trợ được xuất phát từ thông tin theo bối cảnh gắn liền với nhiệm vụ của người sử dụng, dữ liệu đầu vào cuối cùng của người sử dụng, đối tượng được chọn, vị trí hiện tại hoặc chế độ hiện tại bên trong một hệ thống hoặc ứng dụng.

3.3

Lỗi (error)

Không khớp giữa mục tiêu của người sử dụng và phản hồi của hệ thống. Các lỗi có thể gồm lỗi về điều hướng, lỗi cú pháp, lỗi khái niệm…

3.4

Quản lý lỗi (erro management)

Biện pháp hỗ trợ người sử dụng trong việc tìm lỗi, giải thích lỗi hoặc khắc phục lỗi.

3.5

Phòng ngừa lỗi (error prevention)

Biện pháp giảm thiểu khả năng xuất hiện lỗi.

3.6

Phản hồi (feedback)

Đầu ra của dữ liệu cung cấp cho người sử dụng bởi hệ thống khi tương tác với đầu vào dữ liệu do người sử dụng nhập hoặc do một biến cố hệ thống.

3.7

Chỉ dẫn (guidance)

Các phần tử đối thoại hỗ trợ người sử dụng đạt được kết quả dự tính. Chỉ dẫn có thể hỗ trợ người sử dụng trong việc phát hiện khả năng của hệ thống, cho phép họ xây dựng kế hoạch để đạt được mục tiêu, hỗ trợ người sử dụng trong việc đạt được một mục tiêu, hoặc hỗ trợ người sử dụng quản lý được các tình huống lỗi.

3.8

Hỗ trợ trực tuyến (online – help)

Thông tin bổ sung hỗ trợ người sử dụng ngoài lời nhắc, phản hồi, trạng thái và các thông báo lỗi có thể nhận được theo chủ động của người sử dụng hoặc theo hướng dẫn chủ động của hệ thống. Thông tin thường được cung cấp về các đặc điểm của hệ thống, đối thoại và cách sử dụng có thể được dùng để hỗ trợ người sử dụng trong việc hoàn thiện (các) nhiệm vụ.

3.9

Dấu nhắc (prompt)

Dữ liệu đầu ra của hệ thống yêu cầu dữ liệu đầu vào từ người sử dụng.

3.10

Thông tin trạng thái (status information)

Thông tin chỉ rõ trạng thái hiện thời của hệ thống.

3.11

Hướng dẫn chủ động của hệ thống (system-initiated guidance)

Hướng dẫn được hệ thống cung cấp cho người sử dụng khi người sử dụng không đưa ra một hành động rõ ràng yêu cầu hướng dẫn.

CHÚ THÍCH Hướng dẫn chủ động của hệ thống bao gồm, ví dụ, lời nhắc, phản hồi, thông tin trạng thái v.v…

3.12

Hướng dẫn người sử dụng (user guidance)

Thông tin bổ sung ngoài đối thoại thông thường giữa người sử dụng và máy tính, thông tin này được cung cấp theo yêu cầu của người sử dụng hoặc do hệ thống tự động cung cấp.

3.13

Hướng dẫn chủ động của người sử dụng (user-initiated guidance)

Hướng dẫn được cung cấp cho người sử dụng chỉ khi người sử dụng đưa ra một hành động rõ ràng yêu cầu hướng dẫn.

4  Áp dụng tiêu chuẩn này

4.1  Tính phù hợp của hướng dẫn người sử dụng

Hướng dẫn người sử dụng phù hợp với tất cả các hình thức tương tác, dạng thức đối thoại và tình huống, nhằm hỗ trợ người sử dụng trong việc hoàn thành nhiệm vụ.

4.2  Áp dụng các khuyến nghị

Mục tiêu thiết kế tiện dụng nói chung được cung cấp tại Khoản từ 5 đến 10. Các khuyến nghị riêng lẻ nhằm đạt được các mục tiêu này cần được áp dụng trong tình huống cụ thể mà các khuyến nghị có liên quan (ví dụ loại người sử dụng, nhiệm vụ, môi trường, công nghệ riêng biệt). Định dạng cho các khuyến nghị riêng biệt là: các tuyên bố về khuyến nghị, ví dụ (nếu phù hợp), và các chú ý (nếu phù hợp). Các ví dụ được cung cấp cho những khuyến nghị khác nhau thường mô tả chung về việc tiến hành triển khai có bao gồm khuyến nghị. Một số ví dụ cũng chỉ ra các giải pháp mang tính lựa chọn.

Các khuyến nghị riêng lẻ cần được đánh giá khả năng áp dụng và, nếu đã đánh giá khả năng áp dụng, thì phải được triển khai trong hướng dẫn người sử dụng có liên quan trừ khi có bằng chứng cho thấy việc làm này sẽ sai lệch với các mục tiêu thiết kế hoặc làm suy giảm tổng thể tính khả dụng. Khi xác định khả năng áp dụng, các khuyến nghị nhìn chung cần được đánh giá theo trật tự được nêu trong điều khoản chính hoặc điều khoản phụ liên quan. Trong quá trình đánh giá liệu các khuyến nghị có thể áp dụng có được thực hiện hay không thì người đánh giá cần đánh giá sản phẩm hoặc quan sát các đại diện người sử dụng sản phẩm trong tình huống hoàn thành nhiệm vụ của người sử dụng thông qua hướng dẫn dành cho người dùng. Các quy trình mẫu hỗ trợ xác định khả năng áp dụng và để xác định xem liệu một khuyến nghị có được tuân theo hay không được cung cấp trong Phụ lục A.

4.3  Đánh giá sản phẩm

Nếu một sản phẩm được công nhận là đáp ứng được các khuyến nghị về khả năng áp dụng trong tiêu chuẩn này, thì quy trình được sử dụng trong việc thiết lập các yêu cầu cho việc phát triển, và/hoặc đánh giá, hướng dẫn người sử dụng sẽ được chỉ rõ. Mức độ cụ thể của quy trình là vấn đề về thỏa thuận giữa các bên liên quan.

Người sử dụng tiêu chuẩn này có thể vừa sử dụng các quy trình được cung cấp tại Phụ lục A, vừa phát triển quy trình khác được xây dựng riêng cho hoạt động phát triển và/hoặc môi trường đánh giá của mình.

5  Các khuyến nghị hướng dẫn chung

5.1  Mô tả

Điều khoản này đề cập tới các khuyến nghị chung có thể được áp dụng cho hướng dẫn người sử dụng (như: Dấu nhắc, phản hồi, trạng thái, quản lý lỗi, hỗ trợ trực tuyến).

5.2  Các khuyến nghị chung

5.2.1  Thông tin hướng dẫn người sử dụng cần phân biệt rõ với các thông tin được hiển thị khác. (Đối với các khuyến nghị liên quan đến việc trình bày thông tin thị giác có sử dụng các đối tượng đồ họa và kỹ thuật mã hóa, Xem ISO 9241-17, Điều 6 và Điều 7).

VÍ DỤ: Khi một người sử dụng yêu cầu hướng dẫn, một hộp thoại tách rời với màu nền khác số xuất hiện.

5.2.2  Nếu các thông điệp hướng dẫn chủ động của người sử dụng không còn áp dụng được cho trạng thái hiện thời của hệ thống hoặc các hành động của người sử dụng, thì thông tin cần phải được gỡ bỏ khỏi màn hình hiển thị.

5.2.3  Hướng dẫn chủ động của người sử dụng cần phải tuân theo sự điều khiển của người sử dụng.

5.2.4  Các thông điệp hướng dẫn người sử dụng cần cung cấp cho người sử dụng thông tin cụ thể liên quan đến tình huống nhiệm vụ chứ không đơn thuần chỉ là các thông điệp chung chung.

VÍ DỤ: Ngày phải trong phạm vi từ 1 đến 31

thay vì

Dữ liệu không hợp lệ

5.2.5  Hướng dẫn người sử dụng không nên làm gián đoạn nhiệm vụ và tiến trình đối thoại của người sử dụng.

5.2.6  Thông điệp riêng hoặc các kỹ thuật mã hóa cần được sử dụng nhất quán để cảnh báo cho người sử dụng biết các điều kiện trong đó yêu cầu phải có sự chú ý đặc biệt.

5.2.7  Người sử dụng phải có khả năng chỉ rõ được mức độ hướng dẫn mà mình mong muốn nếu việc tương tác với hệ thống khác với kinh nghiệm của người sử dụng.

5.3  Diễn đạt hướng dẫn người sử dụng

5.3.1  Cần nói rõ kết quả của một hành động trước khi mô tả cách thức thực hiện hành động đó.

VÍ DỤ: Để xóa màn hình, nhấn nút RETURN

thay vì

Ấn nút RETURN để xóa màn hình

5.3.2  Các thông điệp hướng dẫn người sử dụng cần được diễn đạt để làm tăng khả năng nhận thức về sự điều khiển của người sử dụng chứ không phải là sự điều khiển của hệ thống khi thực hiện nhiệm vụ.

VÍ DỤ: Để lưu những thay đổi mà người sử dụng tạo ra, ấn nút OK

thay vì

Hệ thống sẽ chỉ lưu những thay đổi mà người sử dụng tạo ra, nếu ấn nút [OK].

5.3.3  Thông thường, các thông điệp hướng dẫn người sử dụng phải diễn đạt bằng các câu khẳng định để nhấn mạnh “phải làm gì” hơn là “phải tránh cái gì”. Tuy nhiên các câu phủ định cũng cần được dùng để chỉ rõ các trường hợp ngoại lệ đối với các quy định hoặc để nhấn mạnh một điểm nào đó.

VÍ DỤ: Để xóa các ký tự bên trái con trỏ chuột nhấp nháy, sử dụng “phím backspace”, không sử dụng “phím delete”.

VÍ DỤ: Không sử dụng ổ băng khi chạy chương trình sao lưu thay vì

Dữ liệu có thể được lưu trên ổ đĩa hoặc ổ băng trừ khi chương trình sao lưu đang hoạt động.

5.3.4  Hướng dẫn người sử dụng phải được diễn đạt sử dụng cấu trúc ngữ pháp đồng nhất.

VÍ DỤ:

Các tùy chọn sẵn có bao gồm:		Các tùy chọn sẵn có bao gồm:
Tệp hiển thị		Tệp hiển thị
Tệp in	thay vì	In tệp
Tệp xóa		Xóa một tệp

5.3.5  Nếu hướng dẫn người sử dụng bao gồm các đoạn văn bản dạng văn viết và ở dạng văn nói, thì hướng dẫn này phải được diễn đạt bằng các câu ngắn gọn và đơn giản.

5.3.6  Hướng dẫn người sử dụng cần thể hiện bằng câu chủ động trừ khi hướng dẫn này đối lập với ngôn ngữ bản địa của người sử dụng.

5.3.7  Hướng dẫn người sử dụng cần sử dụng thuật ngữ mà phần đông người sử dụng để thực hiện nhiệm vụ.

CHÚ THÍCH: Việc sử dụng thuật ngữ người sử dụng tránh sử dụng thuật ngữ của nhà thiết kế vì có thể không phù hợp với nhiệm vụ.

5.3.8  Các thông điệp hướng dẫn người sử dụng cần diễn đạt bằng cách sử dụng các thuật ngữ mang sắc thái trung lập như

– các thuật ngữ không mang tính chất coi thường người sử dụng

– các đặc điểm mang tính nhân văn được áp dụng một cách phù hợp, và

– các thuật ngữ không mang tính hài hước gây cười không phù hợp.

6  Dấu nhắc

6.1  Mô tả

Các dấu nhắc chỉ rõ hệ thống sẵn sàng tiếp nhận dữ liệu đầu vào. Dấu nhắc có thể chung chung hoặc cụ thể. Các dấu nhắc chung chung cho biết hệ thống đang đợi người sử dụng nhập thông tin đầu vào, nhưng không chỉ rõ dạng dữ liệu đầu vào được yêu cầu (ví dụ DOS “>”, UNIX dấu nhắc lệnh “$”). Các dấu nhắc cụ thể chỉ rõ hệ thống đang đợi dữ liệu đầu vào của người sử dụng cũng như hướng người sử dụng đến dạng dữ liệu đầu vào hợp lệ tại điểm này trong đoạn đối thoại (ví dụ Đánh tên tệp được tải:).

6.2  Các khuyến nghị về dấu nhắc

Có nhiều khuyến nghị dành cho các dấu nhắc có thể áp dụng tương tự như với “các nhãn” khi chúng xuất hiện trong các đối thoại dạng điền vào. Để biết thêm thông tin, Xem ISO 9241-17, 5.3.

6.2.1  Các dấu nhắc cần chỉ rõ các dạng ẩn ý (dấu nhắc chung chung) hoặc rõ ràng (dấu nhắc cụ thể) của dữ liệu đầu vào sẽ được hệ thống đối thoại chấp nhận.

6.2.2  Các dấu nhắc cụ thể cần được hiển thị dưới các điều kiện được nêu sau đây. Vì càng nhiều điều kiện được đáp ứng, thì khả năng áp dụng các câu nhắn cụ thể càng lớn.

a) Người sử dụng quen với hệ thống và sẽ cần thông tin về cách xử lý.

b) Có một tập hợp hữu hạn các dữ liệu đầu vào hợp lệ.

c) Các yêu cầu nhiệm vụ (ví dụ nhiệm vụ phức tạp, nhiệm vụ yêu cầu các bước theo trình tự hoặc cần giảm thiểu việc mắc lỗi) đề xuất các dữ liệu đầu vào của người sử dụng cần được hướng dẫn.

6.2.3  Các dấu nhắc chung chung cần được hiển thị theo các điều kiện được nêu sau đây. Vì càng nhiều điều kiện được đáp ứng, thì khả năng áp dụng các câu nhắn chung chung càng lớn.

a) Các điều kiện đối với những dấu nhắc cụ thể không có khả năng áp dụng.

b) Có rất nhiều dữ liệu đầu vào của người sử dụng hợp lệ và không có đủ không gian hiển thị để cung cấp thông tin trên toàn bộ các dữ liệu đầu vào khác.

CHÚ THÍCH: Khi các dấu nhắc chung chung được sử dụng, việc tính đến các dạng người dùng khác nhau là cần thiết (là những người đã quen và chưa quen với dấu nhắc).

6.2.4  Người sử dụng phải tiếp cận được với hỗ trợ trực tuyến liên quan đến các dấu nhắc quá phức tạp hoặc người sử dụng không hiểu.

6.2.5  Nếu một nhiệm vụ yêu cầu một chuỗi riêng biệt các hành động của người sử dụng, thì cần đưa ra lời nhắc cho bước yêu cầu hiện tại. (Xem TCVN 7318-12 (ISO 9241-12, 6.2.5).

6.2.6  Các dấu nhắc nhập dữ liệu/lệnh cần được hiển thị tại một vị trí tiêu chuẩn gần với trường nhập dữ liệu.

VÍ DỤ: ở các ngôn ngữ được viết từ trái sang phải thì dấu nhắc phải ở bên trái trường nhập dữ liệu.

6.2.7  Nếu một giá trị mặc định được xác định cho dữ liệu đầu vào nhắc người sử dụng, thì giá trị đó cần được chỉ rõ bằng thị giác. (Xem ISO 9241-17, 6.13.)

VÍ DỤ: Có bao nhiêu cửa sổ cần được hiển thị rõ tại phần đăng nhập?

6.2.8  Các dấu nhắc cần đưa ra dấu hiệu cho dạng dữ liệu được nhập vào bằng định dạng trường nhập dữ liệu một cách đồng nhất và rõ ràng. (Xem ISO 9241-17, 5.3.7.)

VÍ DỤ: Nhập ngày hiện tại: ___/___/______

6.2.9  Để thuận tiện cho hồi đáp với dấu nhắc, con trỏ chuột dạng nhấp nháy phải tự động định vị trong trường dữ liệu đầu vào tại vị trí phù hợp với dạng dữ liệu đầu vào được yêu cầu.

VÍ DỤ: Dữ liệu có chứa chữ số được sắp xếp trong các cột phải thẳng hàng về bên phải, nghĩa là con trỏ chuột nhấp nháy được đặt ở vị trí tận cùng bên phải trong trường dữ liệu đầu vào và các số di chuyển về phía bên trái khi được gõ vào. Dữ liệu ở dạng chữ được sắp thẳng hàng về phía bên trái, nghĩa là con trỏ chuột nhấp nháy được đặt ở vị trí tận cùng bên trái trong trường dữ liệu đầu vào và con trỏ chuột nhấp nháy di chuyển về phía bên phải khi các ký tự được gõ vào.

7  Phản hồi

7.1  Mô tả

Phản hồi cung cấp thông tin trả lời dữ liệu đầu vào của người sử dụng. Dạng phản hồi biến đổi đối với các thay đổi trong nhiệm vụ, trạng thái hệ thống và dữ liệu đầu vào của người sử dụng.

Ví dụ về phản hồi bao gồm:

– Lặp lại các ký tự trên màn hình khi người sử dụng gõ phím;

– Hiển thị một thông điệp chỉ rõ một câu lệnh vừa nhận được và đang được xử lý;

– Thay đổi có thể nhìn thấy trong khu vực dữ liệu đồ họa sau khi một câu lệnh sửa đổi lại các phần tử của nó;

– Hiển thị một cửa sổ hỗ trợ khi người sử dụng nhấn một phím hỗ trợ;

– Di chuyển con trỏ chuột trên màn hình theo sự dịch chuyển của con chuột.

7.2  Các khuyến nghị phản hồi

7.2.1  Mọi dữ liệu đầu vào được nhập bởi người sử dụng cần tạo ra phản hồi kịp thời và có thể nhận biết được từ hệ thống. (Xem ISO 9241-15:1997, 7.9 và ISO 9241-17, 7.1.)

VÍ DỤ: Phím nhập mục được lặp lại trên màn hình hiển thị trong vòng 150 ms khi người sử dụng gõ phím, trừ khi có các yêu cầu về bảo mật không lặp lại các ký tự.

7.2.2  Phản hồi gắn với việc thực hiện nhiệm vụ thông thường cần ở chế độ không thể xâm nhập và không được làm người sử dụng xao nhãng khỏi nhiệm vụ.

CHÚ THÍCH: Khuyến nghị này không áp dụng cho các thông điệp hướng dẫn người sử dụng, như xóa các xác nhận hoặc lệnh cảnh báo liên quan đến các sự kiện đặc biệt quan trọng, cần can thiệp vào luồng nhiệm vụ của người sử dụng nhằm có được một phản hồi được cân nhắc bởi người sử dụng.

7.2.3  Cần tính đến dạng phản hồi do hệ thống cung cấp:

a) Các đặc điểm người sử dụng: phương thức phản hồi cần tương thích với năng lực người dùng (ví dụ một hệ thống được thiết kế cho người khiếm thị ngoài phản hồi bằng hình ảnh, cần cung cấp thêm phản hồi bằng lời nói).

b) Thay đổi theo nhóm người sử dụng: phản hồi dành cho những người mới sử dụng cần có nhiều thông tin giải thích hơn là phản hồi cho những người sử dụng đã có kinh nghiệm.

c) Các yêu cầu thông tin nhiệm vụ: phản hồi phải tương thích với các yêu cầu chú ý của nhiệm vụ.

VÍ DỤ: Nhiệm vụ yêu cầu người sử dụng quay đầu khỏi màn hình; do vậy dạng phản hồi dưới hình thức giọng nói, tần số âm thanh số được lựa chọn hơn là hiển thị bằng hình ảnh.

d) Năng lực hệ thống: hiển thị phản hồi không được phụ thuộc vào phần cứng cụ thể có sẵn (ví dụ không sử dụng dữ liệu đầu ra bằng lời nói như hình thức phản hồi duy nhất nếu một số hệ thống không có khả năng trình bày dữ liệu đầu ra bằng lời nói).

7.2.4  Hệ thống phải chỉ rõ trạng thái bất cứ khi nào trạng thái (hoặc chế độ) thay đổi.

VÍ DỤ: Khi người sử dụng gõ một trình tự ngắt quãng vào hệ thống, một chỉ thị về trạng thái mới của hệ thống sẽ được cung cấp.

7.2.5  Khi người sử dụng chọn một mục hiển thị nhằm thực hiện một số thao tác vận hành với mục đó hoặc cho chạy mục đó, thì mục này cần được hiện sáng. (Xem ISO 9241-14:1997, 7.1.4)

7.2.6  Nếu có yêu cầu dịch vụ từ xa (ví dụ in một tài liệu trên một máy in từ xa), cần đưa ra một thông điệp trên máy in nội bộ để xác nhận yêu cầu dịch vụ từ xa đang được xử lý. (Xem ISO 9241-17, 7.4.)

7.2.7  Cần cung cấp phản hồi về sự hoàn tất yêu cầu của người sử dụng. (Xem ISO 9241-17, 7.5.)

7.2.8  Nếu việc hoàn tất yêu cầu của người sử dụng không được thực hiện ngay lập tức, thì hệ thống đối thoại sẽ đưa ra một chỉ thị thông báo yêu cầu đó đã được chấp nhận. Hệ thống đối thoại cũng cần chỉ rõ khi nào yêu cầu được hoàn thiện thành công.

VÍ DỤ: Người sử dụng được cung cấp một chỉ thị khi quá trình xử lý hoàn tất. Khi một thao tác yêu cầu thời gian lâu hơn 5 s để hoàn tất, một đồng hồ cát sẽ được hiển thị để chỉ rõ thao tác vẫn đang trong tiến trình thực hiện.

7.2.9  Phản hồi hệ thống đối với nhập mục của người sử dụng cần phù hợp để không làm người sử dụng xao nhãng khỏi nhiệm vụ (nghĩa là không quá chậm mà cũng không quá nhanh).

VÍ DỤ 1: Phản hồi liên quan đến di chuyển đến một trường biểu mẫu mới được đưa ra dưới 250 ms.

VÍ DỤ 2: Sự di chuyển của con trỏ chuột trên màn hình hiển thị có thể thấy được trong vòng 100 ms di chuyển của thiết bị trỏ (ví dụ: chuột).

8  Thông tin trạng thái

8.1  Mô tả

Trạng thái là thông tin hướng dẫn người sử dụng chỉ rõ tình trạng hiện thời của các thành phần trong hệ thống phần cứng và/hoặc phần mềm. Bao gồm thông tin về các ứng dụng sẵn có và đang hoạt động, các chế độ, quy trình và phần cứng… Thông tin trạng thái có thể được trình diễn ở các mức độ chi tiết khác nhau. Mức độ chi tiết trong thông tin trạng thái cần phải phù hợp với nhiệm vụ hiện thời của người sử dụng. Trong khi tất cả người sử dụng có thể hưởng lợi từ thông tin trạng thái, thì đặc biệt thông tin trạng thái sẽ đem lại nhiều lợi ích hơn cho người sử dụng có kinh nghiệm và hiểu biết về hệ thống để điều chỉnh được các thao tác của họ đối với những thay đổi trong trạng thái hệ thống.

Các ví dụ về khu vực mà tại đó thông tin trạng thái được cung cấp bao gồm:

– hoạt động mạng hoặc thư tín: tóm tắt các thông điệp được yêu cầu, các hệ thống khác hoặc người sử dụng sẵn sàng đối thoại;

– các thiết bị từ xa hoặc cục bộ: chuỗi các văn bản đang đợi in ra, các sự cố thiết bị, và hoàn thành việc in;

– thực hiện nhiều nhiệm vụ: tóm tắt các quy trình xử lý đang hoạt động hoặc hệ thống khởi động; các mục được chọn hiện tại;

– trạng thái điều khiển hiện tại (ví dụ: các nút radio, các hộp kiểm tra).

Trạng thái, như được đề cập trong tiêu chuẩn này, không bao gồm thông tin liên quan đến các điều kiện về lỗi.

8.2  Các khuyến nghị trạng thái

8.2.1  Thông tin trạng thái cần liên tục được hiển thị theo các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của thông tin trạng thái đang liên tục hiển thị càng lớn.

a) Thông tin luôn phù hợp với nhiệm vụ hiện tại của người sử dụng, việc trì hoãn hiển thị thông tin sẽ dẫn đến các lỗi nhiệm vụ, làm giảm hiệu năng hoặc các lỗi hệ thống nghiêm trọng.

b) Thông tin liên tục phù hợp với nhiệm vụ hiện tại của người sử dụng và hệ thống có các nguồn lực phù hợp (ví dụ: khả năng xử lý và không gian hiển thị) để cung cấp cả thông tin về trạng thái và nhiệm vụ.

8.2.2  Thông tin trạng thái cần được tự động hiển thị theo các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của thông tin trạng thái tự động hiển thị càng lớn.

a) Thông tin trạng thái luôn phù hợp với nhiệm vụ hiện tại của người sử dụng, và việc tự động hiển thị thông tin trạng thái sẽ không gây ngắt quãng việc thực hiện nhiệm vụ của người sử dụng.

b) Thông tin trạng thái là phản hồi duy nhất được cung cấp cho một hành động của người dùng (ví dụ một đối tượng thay đổi màu sắc để cho thấy đối tượng đó đã được chọn).

c) Người sử dụng có ít kinh nghiệm và kiến thức về hệ thống hoặc ứng dụng và không biết cách yêu cầu thông tin trạng thái.

d) Không thường xuyên sử dụng hệ thống hoặc ứng dụng.

e) Những thay đổi trong trạng thái hệ thống ảnh hưởng đến phản hồi của hệ thống trước dữ liệu đầu vào của người sử dụng (ví dụ: thay đổi về khả năng sẵn có của các thiết bị ngoại vi).

8.2.3  Thông tin trạng thái chỉ nên hiển thị khi phản hồi lại yêu cầu của người sử dụng trong các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của thông tin trạng thái hiển thị chỉ phản hồi đối với yêu cầu của người sử dụng càng cao.

a) Thông tin không liên quan đến nhiệm vụ hiện tại của người sử dụng.

b) Thông tin không quan trọng và chỉ phù hợp với một tập hợp nhỏ người sử dụng tiềm năng.

c) Thông tin chỉ thỉnh thoảng cần đến để hướng dẫn các yêu cầu của người sử dụng.

d) Thông tin trạng thái không quan trọng và thay đổi nhanh chóng và những thay đổi thường xuyên của thông tin hiển thị dường như sẽ làm gián đoạn nhiệm vụ của người sử dụng.

8.2.4  Một vị trí (cửa sổ) hiển thị nhất quán cần dùng cho từng dạng thông tin trạng thái.

VÍ DỤ: Bất cứ khi nào nhận được mail, thông tin trạng thái được hiển thị trong một hộp tại một khu vực nhất định (ví dụ: ở góc bên tay phải phía trên màn hình).

8.2.5  Nếu đầu vào dữ liệu của người sử dụng bị vô hiệu hóa bởi hệ thống đối thoại (ví dụ: bàn phím bị khóa), thì người sử dụng cần được thông báo bằng một tín hiệu (thị giác hoặc thính giác) để chỉ rõ trạng thái này.

8.2.6  Nếu hệ thống hay ứng dụng có các chế độ (có nghĩa là một hành động cụ thể của người sử dụng đem lại các kết quả khác nhau dựa trên trạng thái của hệ thống), người sử dụng cần có khả năng phân biệt trạng thái hiện tại và các trạng thái khác.

VÍ DỤ 1: Trong một nhiệm vụ mà người sử dụng không thể nhìn thấy màn hình hiển thị qua các thay đổi chế độ, thì tín hiệu thính giác sẽ được đưa ra để phân biệt các chế độ.

VÍ DỤ 2: Trạng thái “tắt” hoặc “bật” của nút kiểm tra trong một hiển thị đồ họa được đặt phía bên trái ký hiệu nút kiểm tra.

9  Quản lý lỗi

9.1  Mô tả

Các lỗi trong tương tác giữa con người và máy tính bao gồm:

– sự cố hệ thống do lỗi phần mềm hoặc phần cứng (ví dụ: gặp vấn đề với ổ đĩa).

– Các dữ liệu đầu vào của người sử dụng không được hệ thống nhận dạng.

– Lỗi nhập dữ liệu hoặc lỗi lô-gic ở phía người sử dụng.

– Các kết quả không mong đợi từ dữ liệu đầu vào của người sử dụng.

Hệ thống hoặc người sử dụng có thể tự xóa lỗi. Dò tìm phát hiện lỗi hệ thống chỉ khả thi trong các trường hợp sự cố hoặc không nhất quán và xung đột về lô-gic. Các lỗi được phát hiện của người dùng là các lỗi chỉ phát hiện được bởi chính người sử dụng.

9.2  Phòng ngừa lỗi

9.2.1  Phòng ngừa lỗi là hoạt động luôn luôn phù hợp, nhưng cần phải được sử dụng đặc biệt trong các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của phòng ngừa lỗi càng lớn.

a) Người sử dụng có không có nhiều kinh nghiệm về hệ thống hoặc các đánh giá về hệ thống dựa trên một nền tảng không liên tục.

b) Người sử dụng có khả năng bị xao nhãng khi đang thực hiện nhiệm vụ.

c) Nhiệm vụ sẽ gây ra những hậu quả nghiêm trọng nếu xảy ra lỗi, hoặc nếu lỗi thường xuyên xảy ra.

d) Nhiệm vụ yêu cầu người sử dụng cung cấp dữ liệu đầu vào được sắp xếp theo trình tự chính xác.

e) Hệ thống có nhiều chế độ khác nhau.

9.2.2  Nếu hệ thống sử dụng nhiều chế độ khác nhau, lỗi người sử dụng sẽ được giảm thiểu bằng cách

a) lập bản đồ cùng loại dữ liệu đầu vào của người sử dụng cho một phím chức năng có cùng dữ liệu đầu ra tương tự hoặc có liên quan qua các chế độ;

VÍ DỤ	Chế độ 1: F4 – Thư mục danh sách		Chế độ 1: F4 – Thư mục danh sách
	Chế độ 2: F4 – Các tập danh sách	thay vì	Chế độ 2: F4 – Các cửa sổ thay đổi

b) tránh gán lại dữ liệu đầu vào của người sử dụng cho các chức năng mang đặc tính xóa bỏ.

VÍ DỤ: Phím chức năng F4 không được gán lại thành phím Delete nếu nó đã được gán trước cho File.

9.2.3  Nếu có thể lường trước các lỗi về hệ thống, thì cần đưa ra một chỉ định về vướng mắc tiềm ẩn trước khi lỗi xuất hiện.

VÍ DỤ: Đưa ra thông điệp cảnh báo cho biết hệ thống đang chạy đã hết chỗ trống trong bộ nhớ và có thể không hoàn thành được nhiệm vụ.

9.2.4  Khi người sử dụng yêu cầu thoát ra ngoài một chương trình hoặc rời hệ thống (logoff), thì hệ thống cần kiểm tra trạng thái tệp và các giao tác chưa xử lý. Nếu dữ liệu của người sử dụng có khả năng bị mất hoặc một giao tác chưa hoàn tất không thể được hoàn thành, một thông điệp yêu cầu xác nhận của người sử dụng sẽ hiển thị để đưa ra chỉ dẫn về dữ liệu có thể mất hoặc giao tác nào sẽ bị bỏ dở.

9.5.2  Người sử dụng sẽ phải quay lại hầu hết các thao tác vận hành vừa thực hiện nếu nhiệm vụ cho phép và nếu việc làm này có lợi cho việc triển khai thực hiện nhiệm vụ của người sử dụng (ví dụ. Phím undo). Nếu các hành động của người sử dụng dẫn đến việc xóa bỏ và không thể khôi phục lại, một thông điệp cảnh báo hoặc xác nhận sẽ được đưa ra để báo cho người sử dụng biết những hậu quả có thể xảy đến trước khi thực hiện hành động được yêu cầu.

9.2.6  Người sử dụng cần có khả năng sửa đổi hoặc hủy bỏ dữ liệu đầu vào trước khi thực hiện một hành động. Người sử dụng cần được cung cấp một phương tiện để kiểm tra và hủy bỏ các thao tác vận hành đang trong quá trình xử lý, mà không gây tổn hại đến hệ thống hoặc dữ liệu.

9.3  Sửa lỗi do hệ thống

9.3.1  Việc sửa lỗi do hệ thống cần được sử dụng theo các điều kiện được nêu dưới đây, càng nhiều điều kiện được đáp ứng, khả năng áp dụng của chức năng sửa lỗi bằng hệ thống càng lớn.

a) Lỗi do trục trặc phần cứng và/hoặc phần mềm tại nơi hệ thống có đường truy nhập cho một giải pháp tiềm năng để giải quyết lỗi.

b) Các phương thức sửa lỗi khác bị giới hạn, được chỉ rõ, và không có sự mập mờ nào đối với hành động sửa lỗi mà người sử dụng muốn áp dụng để thực hiện.

9.3.2  Nếu việc sửa lỗi do hệ thống thực hiện được đưa ra:

a) người sử dụng cần biết cách cấu hình dù việc sửa lỗi có được tự động thực hiện hay không, hoặc

b) cần đưa ra một thông điệp xác nhận hoặc cảnh báo cho người sử dụng chỉ rõ việc sửa lỗi đã được lên kế hoạch.

9.4  Quản lý lỗi do người sử dụng thực hiện

9.4.1  Nếu nhiệm vụ yêu cầu việc quản lý lỗi được thực hiện bởi người sử dụng, thì chức năng đối thoại cần đưa ra một phương thức (thông tin và/hoặc chức năng) cho phép người sử dụng tiếp tục đối thoại đó.

9.4.2  Nếu người sử dụng muốn sửa lỗi, cần cung cấp các công cụ sửa lỗi.

Các ví dụ về công cụ sửa lỗi gồm có:

– chức năng khôi phục (undo);

– kiểm tra cú pháp;

– danh sách các tham chiếu chéo;

– chức năng lược sử;

– kiểm tra chính tả.

9.4.3  Nếu hệ thống không thể thực hiện được chức năng nhận diện lỗi theo yêu cầu của nhiệm vụ, thì cần cung cấp cho người sử dụng các công cụ chẩn đoán nhận diện lỗi.

Các ví dụ về các công cụ chẩn đoán nhận diện lỗi bao gồm:

– trình soạn thảo WYSIWYG;

– các chức năng xem trước;

– các chức năng mô phỏng;

– lập danh sách các thiết lập hệ thống.

9.4.4  Theo hoạt động rà soát lỗi, người sử dụng cần được phép hiệu chỉnh dữ liệu đầu vào bị lỗi hơn là bắt buộc phải nhập lại toàn bộ dữ liệu đầu vào. (Xem ISO 9241-15:1997, 8.3 và ISO 9241-17, 6.4.3.)

9.4.5  Nếu hệ thống có khả năng rà soát tìm kiếm đa lỗi trong mục nhập của người sử dụng:

a) cần cung cấp một vài chỉ thị cho người sử dụng về tình trạng đa lỗi.

b) tất cả các trường hoặc các phần của trường có chứa lỗi cần được nhận diện đồng thời bởi người sử dụng. (Xem ISO 9241-17, 6.4.2.)

9.5  Các thông điệp báo lỗi

9.5.1  Nếu các thông điệp báo lỗi ngắn gọn được hiển thị, thì người sử dụng có thể yêu cầu thông tin trực tuyến chi tiết hơn hoặc nên tham khảo thông tin ngoại tuyến bổ sung.

9.5.2  Nếu xuất hiện một lỗi trong trình tự các thao tác vận hành được viện dẫn bởi một thao tác đơn lẻ của người sử dụng, thì cần cung cấp thông tin cho biết các thao tác vận hành hệ thống đã được hoàn thành và chưa được hoàn thành.

9.5.3  Các thông điệp báo lỗi cần nói rõ cái gì sai, hành động sửa lỗi nào cần áp dụng, và

a) nguyên nhân gây ra lỗi (xem thêm ISO 9241-15:1997, 8.3 và ISO 9241-17, 7.3):

VÍ DỤ: Một lỗi đã được xác định trong một đơn vị lô-gic của dữ liệu đầu vào, con trỏ chuột nhấp nháy được đặt ở vị trí bên trong trường dữ liệu hoặc từ lệnh tại điểm nhận ra lỗi đầu tiên để chỉ ra vị trí lỗi.

hoặc

b) hệ thống cần cung cấp một chỉ thị của lớp lỗi càng chính xác càng tốt [(ví dụ: lỗi đọc file (tên file)].

9.5.4  Nếu thông điệp báo lỗi được hiển thị trong một vị trí đơn và sẽ chồng lên các thông điệp báo lỗi trước đó, thì người sử dụng cần được cung cấp một tín hiệu cho phép họ có thể phân biệt được sự xuất hiện của thông điệp báo đã nhận diện được lỗi.

VÍ DỤ: Khi một thông điệp báo lỗi được lặp lại, số lần xuất hiện lỗi sẽ được thêm vào thông điệp báo lỗi.

9.5.5  Các thông điệp báo lỗi cần phải được gỡ bỏ một trong hai trường hợp sau:

a) ngay sau khi điều kiện lỗi được sửa; hoặc

b) trước khi sửa lỗi, nếu người sử dụng yêu cầu gỡ bỏ thông điệp.

9.5.6  Thông tin báo lỗi cần được hiển thị tại một vị trí nhất quán; một trong hai trường hợp sau:

a) thông tin cần được hiển thị càng gần mục nhập gây ra lỗi của người sử dụng càng tốt và không che khuất mục nhập đó; hoặc

b) thông tin cần được hiển thị tại một vị trí riêng lẻ nhất quán trên màn hình hiển thị hoặc trong cửa sổ

9.5.7  Hệ thống cần cho phép người sử dụng di chuyển các thông điệp báo lỗi, nếu những thông điệp này che khuất thông tin của nhiệm vụ liên quan.

9.5.8  Các thông điệp báo lỗi cần được hiển thị càng nhanh càng tốt sau khi đơn vị liên quan đến nhiệm vụ của dữ liệu đầu vào được nhập.

VÍ DỤ: Khi điền vào một mẫu, các lỗi đánh máy trong một trường sẽ không nhận được thông điệp báo lỗi cho tới khi người sử dụng thoát ra khỏi trường và để lại các ký tự gõ không chuẩn xác.

9.5.9  Nếu một tập hợp các dữ liệu đầu vào của người sử dụng hợp lệ nhỏ và có đủ chỗ để hiển thị, thì tập hợp những dữ liệu đầu vào khác nhau cần được hiển thị cùng với thông điệp báo lỗi.

9.5.10  Tùy thuộc vào người sử dụng, các đặc điểm nhiệm vụ hoặc các ưu tiên:

a) người sử dụng cần có khả năng tắt các thông điệp tư vấn yêu cầu xác nhận.

b) người sử dụng cần có khả năng điều khiển âm lượng hoặc tắt âm thanh hay thông điệp được dùng để chỉ các lỗi không nghiêm trọng.

10  Hỗ trợ trực tuyến

10.1  Mô tả

Hỗ trợ trực tuyến cung cấp hướng dẫn bổ sung cho người sử dụng và hỗ trợ người sử dụng khi tương tác với đối thoại và giao diện người sử dụng. Hỗ trợ trực tuyến giải thích cái gì có thể làm được, nó có thể làm được ở đâu, khi nào và làm như thế nào. Hỗ trợ trực tuyến cũng có thể đưa ra hỗ trợ để hoàn thành những mục tiêu của người sử dụng. Hỗ trợ trực tuyến có thể đưa ra các cấp độ thông khác nhau cho những người sử dụng ở các cấp độ kỹ năng khác nhau.

Ví dụ về các dạng thức hỗ trợ mà hỗ trợ trực tuyến có thể mang lại:

– thông tin liên quan đến cú pháp câu lệnh, các phím sẵn có, quy trình thực hiện nhiệm vụ;

– các phần giải thích (ví dụ: các khái niệm liên quan đến nhiệm vụ);

– thông tin hỗ trợ (ví dụ: liệt kê các tùy chọn)

– các phần mô tả (ví dụ: các màn hình và thao tác liên quan).

10.2  Hỗ trợ chủ động của hệ thống

10.2.1  Các điều khoản về hỗ trợ trực tuyến chủ động của hệ thống cần được xem xét dưới các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của hỗ trợ trực tuyến chủ động của hệ thống càng lớn.

a) người sử dụng không có kinh nghiệm và cần phải thao tác thành thạo một cách nhanh chóng.

b) người sử dụng truy nhập vào hệ thống hoặc ứng dụng không thường xuyên và cần chức năng nhắc để nâng cao hiệu quả sử dụng.

c) người sử dụng không để ý tới những lối tắt (shortcut) sẵn có trong hệ thống.

10.2.2  Không nên đưa ra hỗ trợ trực tuyến chủ động của hệ thống trong các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của hỗ trợ chủ động của người sử dụng càng lớn.

a) Người sử dụng không có kinh nghiệm muốn thông tin hỗ trợ trực tuyến hiển thị, trong khi người sử dụng có kinh nghiệm lại không muốn điều này,

b) Việc hiển thị đoạn hướng dẫn hỗ trợ trực tuyến can thiệp vào tương tác của người sử dụng trong nhiệm vụ chính.

c) Việc vận hành hệ thống/ứng dụng bị giảm sút đáng kể do sự xuất hiện của thông tin về hỗ trợ trực tuyến.

d) Hỗ trợ trực tuyến bao gồm một khối lượng lớn thông tin chi tiết mà chỉ người sử dụng có kinh nghiệm hoặc người sử dụng cao cấp mới yêu cầu.

10.2.3  Nội dung thông tin hỗ trợ trực tuyến chủ động của hệ thống cần tập trung vào tình huống nhiệm vụ (ví dụ: màn hình, bước thực hiện của người sử dụng) và đầu vào dữ liệu hay tập hợp các đầu vào dữ liệu của người sử dụng ở thời điểm gần nhất (ví dụ: đối tượng được chọn, lựa chọn menu, câu lệnh đã gõ).

10.2.4  Hỗ trợ trực tuyến chủ động của hệ thống không thể bị xâm nhập:

a) hỗ trợ trực tuyến chủ động của hệ thống cần được hiển thị trong một khu vực nằm bên ngoài khu vực tiến hành nhiệm vụ hoặc trong một cửa sổ riêng biệt dạng không chồng lên nhau, để tránh sự can thiệp có thể nhìn thấy được của khu vực thực hiện nhiệm vụ của người sử dụng.

b) hỗ trợ trực tuyến chủ động của hệ thống thông thường không nên hiển thị dưới hình thức làm người sử dụng xao nhãng khỏi khu vực thực hiện nhiệm vụ chính (ví dụ không nên nhấp nháy hoặc để màu sắc quá nổi bật).

c) Hỗ trợ trực tuyến chủ động của hệ thống không nên viết đè lên toàn bộ màn hình hiển thị nhiệm vụ.

10.2.5  Nếu người sử dụng muốn tắt hỗ trợ trực tuyến chủ động của hệ thống, thì nên cung cấp cho người sử dụng một phương tiện bật / tắt chức năng hỗ trợ trực tuyến này.

10.3  Hỗ trợ chủ động của người sử dụng

10.3.1  Nếu hỗ trợ trực tuyến chủ động của người sử dụng được cung cấp, người sử dụng sẽ phải yêu cầu hỗ trợ trực tuyến bằng một hành động nhất quán và đơn giản.

VÍ DỤ: Phím “?”; phím chức năng F1: chọn lựa biểu trưng hỗ trợ, trạng thái “hỗ trợ” bằng lời nói.

10.3.2  Việc xác định các chủ đề hỗ trợ trực tuyến của người sử dụng cần được cung cấp theo các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của việc xác định các chủ đề hỗ trợ trực tuyến của người sử dụng càng lớn.

a) Không có tình huống nhiệm vụ sẵn có để phân định ranh giới dạng hỗ trợ trực tuyến được cung cấp.

b) người sử dụng sẽ cùng lúc thực hiện các nhiệm vụ và có thể cần đến sự linh hoạt trong việc lựa chọn dạng hỗ trợ trực tuyến cần được cung cấp.

10.3.3  Hệ thống cần hướng dẫn người sử dụng trong việc xác định các chủ đề hỗ trợ trực tuyến theo các điều kiện được nêu dưới đây. Càng nhiều điều kiện được đáp ứng, khả năng áp dụng của hướng dẫn hệ thống trong việc hỗ trợ cụ thể càng lớn.

a) Tình huống nhiệm vụ có thể phân định ranh giới tập hợp các chủ đề mong muốn có vẻ phù hợp nhưng không phải là chủ đề chính xác mà người sử dụng cần có thông tin.

b) người sử dụng cần linh hoạt trong việc chọn lựa hỗ trợ trực tuyến nhưng lại gặp khó khăn trong việc xác định chính xác chủ đề hỗ trợ trực tuyến nếu thiếu đi sự hỗ trợ.

10.3.4  Nếu người sử dụng yêu cầu một chủ đề hỗ trợ thông qua các phương pháp mà không phải thông qua chọn lựa (ví dụ: gõ yêu cầu hỗ trợ),

a) thì hệ thống sẽ chấp nhận các từ đồng nghĩa để xác định chỉ đề hỗ trợ trực tuyến (bao gồm cả các từ đồng nghĩa không mang tính kỹ thuật).

b) thì hệ thống cần chấp nhận các so khớp chính tả chặt chẽ đối với thuật ngữ hệ thống tiêu chuẩn để xác định chủ đề hỗ trợ trực tuyến.

10.3.5  Nếu người sử dụng yêu cầu hỗ trợ trực tuyến không xác định được chủ đề tương xứng để được hỗ trợ trực tuyến, thì hệ thống cần

a) hiển thị thông tin hỗ trợ trực tuyến tương ứng với tình huống nhiệm vụ và giao tác hiện tại, hoặc

b) khởi động một đối thoại để chọn lọc xem người sử dụng có thể xác định dữ liệu gì, thông điệp gì hay câu lệnh nào để yêu cầu giải thích.

10.4  Trình bày thông tin hỗ trợ

10.4.1  Nếu người sử dụng xác định một chủ đề để yêu cầu hỗ trợ trực tuyến, thì chỉ thông tin tương ứng với chủ đề được xác định mới được biểu diễn.

10.4.2  Hỗ trợ trực tuyến cần được trình diễn càng nhanh càng tốt sau khi nhận được yêu cầu của người sử dụng.

10.4.3  Đối với dạng tương tác trực tuyến, thời gian phản hồi của việc trình diễn hỗ trợ trực tuyến cần dự đoán được.

10.4.4  Thông tin hỗ trợ trực tuyến cần được cung cấp dưới dạng phương tiện phù hợp nhất để giải thích chủ đề, sử dụng các điều kiện thuận lợi về dữ liệu đầu ra sẵn có đối với người sử dụng, hơn là hiển thị toàn bộ thông tin dưới dạng văn bản.

10.4.5  Hỗ trợ trực tuyến cần cung cấp thông tin liên quan đến nhiệm vụ về hệ thống và mục đích.

10.4.6  Hỗ trợ trực tuyến cần khớp với các nhu cầu nhiệm vụ của người sử dụng và nên bao gồm thông tin về cả mô tả lẫn quy trình như yêu cầu của nhiệm vụ.

VÍ DỤ: Đối với một câu lệnh được đưa ra, thông tin được cung cấp dựa trên định nghĩa các yêu cầu về cú pháp, cũng như các bước được yêu cầu để kết nối câu lệnh này với các câu lệnh khác nhằm thực hiện nhiệm vụ đề ra.

10.5  Điều hướng hỗ trợ và các biện pháp kiểm soát

10.5.1  Nếu việc truy nhập vào hỗ trợ trực tuyến làm người sử dụng thoát ra ngoài đối thoại chính của nhiệm vụ, thì người sử dụng cần được chỉ dẫn cách quay lại và tiếp tục giữa đối thoại thực hiện nhiệm vụ và hỗ trợ trực tuyến.

VÍ DỤ: Trong một môi trường của thiết bị cuối, người sử dụng có thể ở giữa hai trạng thái quay lại hoặc tiếp tục giữa hỗ trợ trực tuyến và các màn hình thực hiện nhiệm vụ.

10.5.2  Nếu việc đào tạo trực tuyến hoặc các tài liệu trực tuyến sẵn có, thì cần đưa ra sự kết nối giữa thông tin hỗ trợ trực tuyến, đào tạo và tài liệu.

10.5.3  Nếu có thể, cần cung cấp điều khiển hỗ trợ trực tuyến cho người sử dụng (do hệ thống chủ động hoặc do người sử dụng chủ động). Người sử dụng có thể:

a) cấu hình hỗ trợ trực tuyến chủ động của hệ thống (ví dụ: bật hoặc tắt, chọn mức độ) phù hợp với nhu cầu của cá nhân;

b) chủ động hỗ trợ trực tuyến bất kỳ khi nào người sử dụng cần;

c) chọn lựa và thay đổi chủ đề hỗ trợ trực tuyến;

d) điều khiển loại thông tin hỗ trợ trực tuyến, nếu được cung cấp nhiều loại thông tin (ví dụ: thông tin hướng dẫn, cú pháp, nhiệm vụ);

e) thoát khỏi hệ thống hỗ trợ trực tuyến bất cứ khi nào muốn.

10.5.4  Nếu người sử dụng có các hệ thống với những hạn chế về năng lực, thì thông tin hỗ trợ trực tuyến cần ở dạng mô-đun cho phép người sử dụng chọn các phần thông tin hỗ trợ trực tuyến được lưu trong hệ thống của mình.

10.5.5  Nếu có thể áp dụng được (được hỗ trợ bởi năng lực của hệ thống), hệ thống nên cho phép người sử dụng tùy biến hỗ trợ trực tuyến bằng cách:

– diễn giải hỗ trợ trực tuyến người sử dụng riêng lẻ;

– lưu tình huống khi hoán chuyển giữa hỗ trợ trực tuyến và nhiệm vụ;

– bổ sung thêm chủ đề hỗ trợ.

10.5.6  Nếu hỗ trợ trực tuyến được triển khai như một chế độ,

a) cần cung cấp các tín hiệu cho người sử dụng để chỉ rõ ứng dụng đang ở chế độ hỗ trợ trực tuyến;

VÍ DỤ: Hệ thống thay đổi lời nhắc hoặc con trỏ chuột chỉ vào hình dấu “?”.

b) người sử dụng cần biết rõ cách thoát ra khỏi chế độ và quay trở lại nhiệm vụ.

VÍ DỤ: Hệ thống cung cấp một hộp thoại có nút thoát ra.

10.6  Hỗ trợ khả năng duyệt

10.6.1  Người sử dụng cần có khả năng duyệt qua các hiển thị hỗ trợ trực tuyến (ví dụ: để làm quen với các chức năng hệ thống và các quy trình vận hành).

10.6.2  Nếu hỗ trợ trực tuyến có khả năng duyệt được cung cấp, thì chức năng này cần bao gồm một danh sách hoặc sơ đồ về các chủ đề hỗ trợ trực tuyến để từ đó người sử dụng có thể đưa ra các lựa chọn.

10.6.3  Nếu số lượng các chủ đề trong danh sách hỗ trợ khả năng duyệt lớn, thì một hay nhiều các chức năng sau đây cần được cung cấp cho người sử dụng để xác định được vị trí chủ đề mong muốn:

– tìm kiếm theo chuỗi trong danh sách các chủ đề;

– tìm kiếm theo từ khóa trong văn bản hỗ trợ trực tuyến;

– thiết lập cấu trúc phân cấp trong văn bản hỗ trợ trực tuyến;

– lập sơ đồ các chủ đề hỗ trợ trực tuyến.

10.6.4  Nếu có thể áp dụng được (ví dụ: quan trọng đối với nhiệm vụ, dựa trên nội dung hỗ trợ), thì hệ thống cần cung cấp:

– kết nối trực tiếp giữa các chủ đề;

– các tín hiệu cho phép người sử dụng nhận diện được vị trí các kết nối tồn tại;

– một đường dẫn mặc định để duyệt;

– một đại diện (ví dụ: sơ đồ) cho các liên kết giữa các chủ đề;

– các vạch dấu vị trí người sử dụng để truy nhập lại vào thông tin.

10.6.5  Nếu người sử dụng có thể điều hướng được các chủ đề khác nhau trong hệ thống hỗ trợ và điều này có lợi cho việc thực hiện nhiệm vụ của họ, thì hệ thống cần được cung cấp các cơ chế truy nhập nhanh như:

– quay lại chủ đề hỗ trợ trước;

– quay lại vị trí ban đầu trong hệ thống hỗ trợ;

– truy nhập các chủ đề liên quan chỉ với một thao tác (tham chiếu chéo);

– truy nhập vào phần lược sử (history) của các chủ đề đã truy nhập trước.

10.6.6  Nếu thông tin hỗ trợ trực tuyến có cấu trúc phân cấp:

a) cần cung cấp một chỉ thị về cấu trúc của các chủ đề hỗ trợ trực tuyến;

b) người sử dụng cần có khả năng truy nhập vào thông tin dành cho chủ đề hỗ trợ ở bất kỳ cấp độ nào trong cấu trúc phân cấp, không phải chỉ riêng ở cấp cao nhất;

c) cần cung cấp cho người sử dụng một phương pháp sẵn có và đồng nhất để truy nhập vào hỗ trợ trực tuyến một cách chi tiết hơn (nghĩa là các mức độ thấp hơn của cấu trúc hỗ trợ trực tuyến);

d) người sử dụng cần được cho phép trực tiếp điều hướng tới chủ đề gốc bên trong hệ thống phân cấp.

10.6.7  Nếu người sử dụng có thể truy nhập vào các chủ đề hỗ trợ trực tuyến theo một đường truy cập ngẫu nhiên, thì thông tin hỗ trợ trực tuyến nên tồn tại độc lập (có nghĩa là hệ thống không nên giả định người sử dụng đã đọc các phần trước của hỗ trợ trực tuyến trước khi nhận được thông tin hiện tại).

10.6.8  Nếu thông tin hỗ trợ trực tuyến mở rộng ra ngoài màn hình hiển thị đơn và các cuộn thông tin, thì chủ đề thông tin cần giữ nguyên tính rõ ràng (ví dụ: nhan đề thông tin giữ nguyên trạng thái có thể nhìn thấy được).

10.7  Hỗ trợ tình huống nhạy cảm

10.7.1  Việc chọn lựa tình huống nhạy cảm của các chủ đề hỗ trợ trực tuyến cần được cung cấp khi nhiệm vụ bao gồm các bước cụ thể liên tục hoặc thông tin tình huống rõ ràng cho phép hệ thống dự đoán chính xác thông tin hỗ trợ trực tuyến mà người sử dụng cần. Thông tin này nên hỗ trợ cho các yêu cầu nhiệm vụ hiện tại của người sử dụng.

10.7.2  Hỗ trợ trực tuyến tình huống nhạy cảm cần cung cấp đường truy nhập tới thông tin nhiệm vụ về

– tất cả các khía cạnh (ví dụ: ngữ nghĩa học hoặc từ vựng học, tính chất mô tả hoặc quy trình) của bước đối thoại hiện tại;

– nhiệm vụ hiện tại;

– ứng dụng hiện tại;

– thông tin về nhiệm vụ được hiển thị trên màn hình.

10.7.3  Nếu nhiều các chủ đề hỗ trợ trực tuyến tình huống nhạy cảm liên quan tới bước đối thoại hiện tại, cần chọn lựa một mặc định trong khi cho phép người sử dụng truy nhập vào các chủ đề khác.

10.7.4  Hỗ trợ trực tuyến dành riêng cho các đối tượng giao diện người sử dụng cần đưa ra lời giải thích đối tượng đó là gì, làm gì và sử dụng như thế nào. Hỗ trợ này cần nhạy với tình huống, nếu có thể áp dụng được.

VÍ DỤ: Một tùy chọn menu không sẵn có bị làm mờ đi. Văn bản hỗ trợ trực tuyến chỉ rõ tại sao tùy chọn lại không sẵn có và người sử dụng có thể làm gì để tùy chọn menu có thể sử dụng được.

10.7.5  Nếu hỗ trợ trực tuyến chỉ dành riêng cho một tập con các đối tượng giao diện người sử dụng, thì cần cung cấp một chỉ thị bằng hình ảnh nêu rõ những đối tượng nào có thể được giải thích.

VÍ DỤ: Con trỏ chuột xuất hiện dưới hình thức một dấu “?” đậm khi được đặt trên các đối tượng có sẵn hỗ trợ trực tuyến, hoặc hệ thống tự động hiển thị mô tả về một đối tượng, khi con trỏ chuột di chuyển trên đối tượng đó.

Phụ lục A

(Tham khảo)

Mẫu quy trình phục vụ việc đánh giá khả năng ứng dụng và liên kết

Phụ lục này đưa ra ví dụ về quy trình xác định tính khả thi của việc áp dụng các khuyến nghị có trong tiêu chuẩn này. Cần lưu ý rằng quy trình được mô tả dưới đây được cung cấp như một hướng dẫn và không phải là một quá trình nghiêm ngặt được sử dụng để thay thế cho tiêu chuẩn này. Quy trình này cung cấp một quá trình gồm hai giai đoạn nhằm:

1) Xác định khuyến nghị nào có liên quan, và

2) Xác định các khuyến nghị có liên quan đã được tập hợp đầy đủ hay chưa.

Việc thiết kế giao diện phụ thuộc vào nhiệm vụ, người sử dụng, môi trường và công nghệ sẵn có. Do đó, tiêu chuẩn này không thể được áp dụng mà không có kiến thức gì về thiết kế và sử dụng tình huống giao diện và không nhằm mục đích được sử dụng như một tập hợp các quy định theo thông lệ được áp dụng trọn vẹn. Hơn nữa, giả định người thiết kế có thông tin chính xác liên quan đến nhiệm vụ và yêu cầu của người sử dụng, đồng thời có những hiểu biết cơ bản về việc sử dụng công nghệ sẵn có (điều này có thể yêu cầu tư vấn từ một chuyên gia giàu kinh nghiệm về egônômi cũng như kiểm tra theo kinh nghiệm đối với người sử dụng hiện tại).

Quy trình đánh giá cần dựa trên một phân tích về người sử dụng cụ thể, các nhiệm vụ cụ thể và chủ yếu của họ cũng như môi trường sử dụng đặc thù. Các đánh giá hướng dẫn người sử dụng thường rơi vào hai loại sau:

a) Khi người sử dụng và nhiệm vụ của người sử dụng được nhận biết, các nhà đánh giá sẽ đánh giá sản phẩm hoặc quan sát người sử dụng sản phẩm trong tình huống hoàn tất các nhiệm vụ cụ thể và chủ yếu của người sử dụng trong một môi trường sử dụng cụ thể.

b) Khi những người sử dụng xác định và các nhiệm vụ của người sử dụng không được nhận biết, tất cả các khía cạnh của việc biểu diễn thông tin được sử dụng trong sản phẩm đang được đánh giá.

Việc xác định liệu sản phẩm có đáp ứng được khuyến nghị đề ra cần dựa trên các hướng dẫn người sử dụng riêng biệt gặp phải trong suốt quá trình đánh giá được mô tả kể trên. Hướng dẫn người sử dụng có thể cho thấy sự cải thiện hơn so với các mặt đáp ứng được các khuyến nghị mô tả trong tiêu chuẩn này có thể được chấp nhận là đáp ứng được các khuyến nghị của tiêu chuẩn.

Người sử dụng trong tiêu chuẩn này có thể mô tả việc họ đáp ứng các khuyến nghị ra sao bằng cách liệt kê phương pháp sử dụng để đánh giá khả năng áp dụng (như đã mô tả ở A.1); phương pháp được sử dụng để đánh giá mức độ tập hợp (như đã mô tả ở A.1); và kết quả đạt được.

A.1  Khả năng áp dụng

Khả năng áp dụng một khuyến nghị dựa trên hai yếu tố sau:

a) Câu lệnh có điều kiện, nếu bao gồm một phần của điều khoản, có đúng không. Một khuyến nghị riêng biệt có (hoặc không) thể áp dụng khi câu lệnh – nếu có điều kiện là (không) đúng. Ví dụ: nếu nhiệm vụ không yêu cầu một trình tự thao tác cụ thể, khuyến nghị 6.2.5 sẽ không được áp dụng.

b) Môi trường thiết kế. Một khuyến nghị riêng biệt có thể không được áp dụng do người sử dụng, nhiệm vụ, môi trường và những hạn chế về mặt công nghệ như cộng đồng người sử dụng không được biết tới, sự khác biệt trong nhiệm vụ, văn phòng ồn ào, độ phân giải màn hình, thiếu thiết bị chỉ. Tuy nhiên, nếu môi trường thiết kế bao gồm cả đặc điểm của người sử dụng, nhiệm vụ hoặc các đặc tính về công nghệ được đề cập tới trong một khuyến nghị riêng biệt, thì khuyến nghị đó sẽ được áp dụng. Ví dụ: nếu thông tin trạng thái được cung cấp cho người sử dụng, thì các khuyến nghị tại 8.2 cần được đánh giá để xác định khả năng áp dụng của những khuyến nghị này.

Các phương pháp phù hợp để xác định khả năng áp dụng một khuyến nghị riêng biệt là:

a) Phân tích tài liệu hệ thống,

b) Bằng chứng được văn bản hóa,

c) Quan sát,

d) Đánh giá phân tích,

e) Đánh giá theo kinh nghiệm.

Điều A.2 mô tả chi tiết từng phương pháp về khả năng áp dụng.

A.2   Mô tả các phương pháp về khả năng áp dụng

A.2.1  Phân tích tài liệu hệ thống

Phân tích tài liệu hệ thống đề cập đến việc phân tích bất kỳ một tài liệu nào có thể mô tả việc biểu diễn thông tin một cách tổng quan và chi tiết. Các tài liệu này có thể bao gồm tài liệu về thiết kế có trong hệ thống và các yêu cầu của người sử dụng, hướng dẫn sử dụng, chỉ dẫn người sử dụng… Ví dụ: theo yêu cầu của hệ thống đối với một ứng dụng riêng biệt, chỉ cung cấp cho hỗ trợ chủ động của người sử dụng.

A.2.2  Bằng chứng văn bản

Bằng chứng được văn bản hóa đề cập đến việc phân tích bất kỳ thông tin được văn bản hóa có liên quan về các yêu cầu nhiệm vụ hoặc các đặc điểm, luồng công việc, kỹ năng người sử dụng, năng khiếu của người sử dụng, các quy ước hoặc xu hướng của người sử dụng hiện tại, dữ liệu kiểm tra từ việc thiết kế các hệ thống tương tự… Những thông tin này có thể được sử dụng để xác định liệu một khuyến nghị đề ra có khả năng áp dụng hay không. Ví dụ: dữ liệu phân tích nhiệm vụ có thể chỉ ra rằng người sử dụng sẽ thường xuyên yêu cầu có thông tin về trạng thái của hệ thống.

A.2.3  Quan sát

Quan sát đơn giản có nghĩa là kiểm tra hoặc điều tra việc biểu diễn thông tin về sự hiện diện của một đặc tính riêng biệt có thể nhận thấy. Việc quan sát có thể được tiến hành bởi bất kỳ ai có kỹ năng cần thiết để kiểm tra một cách có hệ thống việc biểu diễn thông tin và xác định nếu việc biểu diễn thông tin đó có các đặc tính riêng biệt gắn với khả năng áp dụng của các khuyến nghị có điều kiện đề ra. Do tính chất hiển nhiên này, các hoạt động quan sát có thể hoàn toàn được xác nhận bởi một người khác.

A.2.4  Đánh giá phân tích

Đánh giá phân tích đi đôi với các phán đoán “được thông báo” liên quan đến các đặc tính của một hướng dẫn người sử dụng của một chuyên gia có liên quan (nghĩa là của các đặc tính này). Phương pháp này chủ yếu được dùng để đánh giá các thuộc tính có thể được phán đoán chỉ trong tình huống của thông tin và kiến thức khác. Ngoài ra, đánh giá phân tích có thể phù hợp khi hệ thống tồn tại chỉ về mặt tài liệu thiết kế, quần thể người sử dụng không sẵn có để đánh giá theo kinh nghiệm hoặc thời gian và các nguồn lực bị hạn chế. Đánh giá phân tích có thể được sử dụng để xác định liệu một khuyến nghị riêng biệt có thể áp dụng hay không, ví dụ để xác định nếu hỗ trợ trực tuyến chủ động của hệ thống làm người sử dụng xao nhãng khỏi nhiệm vụ.

Phân tích đánh giá có thể được tiến hành bởi bất kỳ ai có chuyên môn phù hợp, là người có kỹ năng và kinh nghiệm cần thiết để phán đoán thuộc tính liên quan của việc biểu diễn thông tin. Nếu các thuộc tính đề cập đến ứng dụng của các nguyên tắc về sự tiện dụng, thì chuyên gia cần sở hữu các kỹ năng phù hợp liên quan đến tiện ích phần mềm. Nếu các thuộc tính đề cập đến môi trường làm việc, đặc điểm hệ thống hoặc các mặt khác của việc thiết kế, thì người đưa ra phán đoán phải là một chuyên gia thuộc lĩnh vực có liên quan.

A.2.5  Đánh giá theo kinh nghiệm

Đánh giá theo kinh nghiệm đề cập đến ứng dụng các quy trình kiểm tra sử dụng những người dùng cuối cùng đại diện để xác định khả năng áp dụng của một khuyến nghị. Phương pháp này phù hợp nhất khi một nguyên mẫu hoặc hệ thống thực tế sẵn có, và quần thể người sử dụng thực tế hay tiềm năng sẵn có. Nhiều loại quy trình kiểm tra có thể được sử dụng, nhưng trong từng trường hợp các đối tượng kiểm tra cần phải đại diện cho quần thể người sử dụng cuối cùng và có số lượng đầy đủ để các kết quả có thể phổ biến cho toàn bộ cộng đồng người sử dụng. Ví dụ: đánh giá theo kinh nghiệm để xác định liệu người sử dụng sẽ thường xuyên yêu cầu hỗ trợ có thể được tiến hành bằng cách để những người sử dụng riêng biệt thực hiện một số nhiệm vụ công việc đại diện chỉ sử dụng hỗ trợ trực tuyến cho hướng dẫn người sử dụng.

Cần lưu ý rằng việc đánh giá phân tích phải được tiến hành bởi các cá nhân có kỹ năng phù hợp trong lĩnh vực phương pháp luận kiểm nghiệm và kỹ thuật đánh giá.

A.3  Tính liên kết

Nếu một khuyến nghị có thể áp dụng trên nền tảng tiêu chuẩn mô tả tại A.1, thì cần phải xác định liệu khuyến nghị đó có đáp ứng yêu cầu hay không. Tính liên kết được xác định bằng cách sử dụng một hoặc nhiều phương pháp được liệt kê dưới đây.

CHÚ THÍCH: Các phương pháp phù hợp để xác định tính liên kết của một khuyến nghị riêng biệt được liệt kê cùng với khuyến nghị trong phần Danh sách kiểm tra trong Bảng A.1.

a) đo lường,

b) quan sát,

c) bằng chứng văn bản,

d) đánh giá phân tích,

e) đánh giá theo kinh nghiệm.

Cần lưu ý là kết quả của các hoạt động kiểm chứng khả năng áp dụng thường đóng vai trò quan trọng trong việc xác định tính liên kết. Các phương pháp liên kết khác được mô tả kỹ ở phần dưới đây.

A.4  Mô tả về các phương pháp liên kết

A.4.1  Các phương pháp tính toán đo đạc

Các phương pháp tính toán đo đạc đề cập đến việc đo đạc hoặc tính toán một biến số liên quan đến đặc điểm hướng dẫn người sử dụng. Một ví dụ cho các đặc điểm này là thời gian đáp ứng hệ thống. Tính liên kết được xác định bằng cách so sánh giá trị đạt được từ việc tính toán với giá trị quy định trong khuyến nghị.

A.4.2  Quan sát

Quan sát đơn giản có nghĩa là kiểm tra hoặc giám sát về hướng dẫn người sử dụng để đảm bảo rằng một đặc tính riêng biệt có thể nhận thấy đã được đáp ứng. Các hoạt động quan sát có thể được tiến hành bởi bất kỳ ai có kỹ năng cần thiết một cách có hệ thống kiểm tra việc biểu diễn thông tin và xác định nếu một câu lệnh liên quan đến một thuộc tính có thể nhận thấy đã được áp dụng một cách nhất quán. Thuộc tính có thể nhận thấy được so sánh với khuyến nghị để xác định tính liên kết.

A.4.3  Bằng chứng văn bản

Đối với tính liên kết, bằng chứng văn bản đề cập đến bất kỳ thông tin văn bản tương ứng nào liên quan đến tính liên kết của hướng dẫn người sử dụng với các khuyến nghị có điều kiện kiện thích hợp. Bằng chứng này có thể bao gồm các quy ước hoặc xu hướng của người sử dụng, dữ liệu kiểm chứng nguyên mẫu, dữ liệu kiểm chứng từ việc thiết kế các hệ thống tương tự…. Ví dụ: dữ liệu kiểm chứng từ một hệ thống tương tự có thể đã chỉ rõ rằng sự điều hướng và các chức năng điều khiển hệ thống hỗ trợ (10.5) trong hướng dẫn người sử dụng được đánh giá là phù hợp với các dạng người sử dụng và các nhiệm vụ liên quan đến ứng dụng. Trong trường hợp này, tính liên kết về cơ bản được xác định dựa trên bằng chứng văn bản của tính liên kết đối với khuyến nghị của hệ thống tương tự.

A.4.4  Đánh giá phân tích

Như đã nêu ở A.2.4, đánh giá phân tích đi đôi với những phán đoán “được thông báo” liên quan đến các đặc tính của hướng dẫn người sử dụng bởi một chuyên gia liên quan (nghĩa là của những đặc tính đó). Phương pháp này chủ yếu dùng để đánh giá các thuộc tính có thể phán đoán được chỉ trong tình huống của thông tin khác hoặc kiến thức khác. Ngoài ra, đánh giá phân tích có thể là một phương pháp liên kết phù hợp khi hệ thống chỉ tồn tại về mặt tài liệu thiết kế, các nhóm người sử dụng không sẵn có để đánh giá theo kinh nghiệm, hoặc thời gian và nguồn lực bị hạn chế. Ví dụ: đánh giá phân tích có thể được sử dụng để xác định tính liên kết cho việc liệu hệ thống có chỉ rõ trạng thái của nó bất cứ khi nào trạng thái thay đổi hay không (7.2.4). Ở trường hợp trên, “rõ” là một khía cạnh mang tính phán đoán.

Như đã nêu ở A.2.4, đánh giá phân tích có thể được thực hiện bởi bất kỳ người nào có trình độ phù hợp, với kỹ năng và kinh nghiệm cần thiết để phán đoán thuộc tính liên quan của việc biểu diễn thông tin. Đối với tính liên kết, chuyên gia cũng cần có các kỹ năng và kiến thức cần thiết để phán đoán một cách có căn cứ sự phù hợp và tính hữu dụng của một giải pháp thiết kế cụ thể. Cũng cần lưu ý rằng đánh giá phân tích có thể kiểm tra tính lô-gic của một thiết kế, nhưng không thể xác nhận tính hợp lệ của thiết kế. Tính hợp lệ chỉ có thể đạt được bằng cách sử dụng đánh giá phân tích.

A.4.5  Đánh giá theo kinh nghiệm

Đánh giá theo kinh nghiệm đề cập đến ứng dụng của quy trình kiểm nghiệm sử dụng đại diện người sử dụng cuối cùng để xác định sự liên kết đối với một khuyến nghị. Như đã nêu ở A.2.5, phương pháp này là phù hợp nhất khi một nguyên mẫu hoặc hệ thống thực tế sẵn có và đại diện quần thể người sử dụng thực tế và tiềm năng cũng sẵn có. Nhiều hình thức quy trình kiểm chứng có thể được sử dụng, nhưng trong từng tình huống đối tượng kiểm chứng cần phải đại diện quần thể người sử dụng cuối cùng và có số lượng phù hợp để các kết quả có thể khái quát cho toàn bộ cộng đồng người sử dụng. Việc thực vụ của người sử dụng cuối áp dụng hướng dẫn người sử dụng có thể được phân tích nhằm xác định sự liên kết với các khuyến nghị có điều kiện khác nhau. Ví dụ: bằng cách phân tích thời gian người sử dụng cần để sửa lỗi, có thể xác định nếu các thông điệp báo lỗi đang truyền đạt cái gì là sai, các thao tác sửa lỗi nào có thể được thực hiện và nguyên nhân gây ra lỗi (xem 9.5.3). Những đánh giá kiểm tra đó có thể được thực hiện trong quá trình phát triển (Ví dụ: bằng mẫu phát triển nhanh) và sau khi thiết kế và triển khai hệ thống (Ví dụ: các kỹ thuật đánh giá hệ thống) và có thể căn cứ trên dữ liệu người sử dụng khách quan và chủ quan. Các kiểm chứng đặc biệt cũng có thể được thiết kế để đánh giá tính liên kết với một khuyến nghị cụ thể.

Điển hình là các đánh giá theo kinh nghiệm được sử dụng để xác định sự liên kết bằng cách so sánh kết quả kiểm chứng và các khuyến nghị riêng biệt. Tuy nhiên, cũng cần phải đánh giá các kết quả kiểm chứng về khía cạnh hiệu quả (ví dụ: hướng dẫn người sử dụng hỗ trợ người sử dụng trong việc thực hiện nhiệm vụ theo cách giúp cải thiện việc thực hiện, kết quả trong một nhiệm vụ khó đang được tiến hành ít gặp khó khăn hơn, hoặc cho phép người sử dụng hoàn thành một nhiệm vụ bất khả thi).

A.5  Quy trình

Có thể tiến hành theo quy trình sau đây (xem Hình A.1) để đánh giá một hướng dẫn người sử dụng riêng biệt có tính đến các khuyến nghị trong tiêu chuẩn này.

A.5.1  Các khuyến nghị có điều kiện “mệnh đề giả định”

a) Tính có thể áp dụng – Mỗi khuyến nghị có một điều kiện – giả định cũng như trong nội dung của khuyến nghị (ví dụ: Điều 5.2.3), hoặc hàm ý trong tiêu đề một mệnh đề phụ (ví dụ: 10.2). Đối với mỗi khuyến nghị có điều kiện, khả năng áp dụng của câu giả định cần được xác định bằng cách sử dụng các phương pháp được đề xuất kiểm chứng nếu điều kiện – giả định là đúng hoặc không đúng (ví dụ: trong mục 9.5.9, bằng chứng đã được văn bản hóa, đánh giá phân tích, hoặc đánh giá theo kinh nghiệm phù hợp để xác định liệu tập hợp các dữ liệu đầu vào khác nhau có nên được biểu diễn trong cùng một thông điệp báo lỗi hay không). Cũng như vậy, khi có một tập hợp các khuyến nghị có điều kiện có thể tùy chọn như trong 9.3.2 a) và 9.3.2 b), hướng tiếp cận khả năng áp dụng cần được xác định bằng cách sử dụng (các) phương pháp đã đề xuất. Các tập hợp khuyến nghị có điều kiện mang tính tùy chọn khác nhau được mô tả kỹ hơn trong Danh mục kiểm tra khả năng ứng dụng và tính liên kết bằng việc sử dụng chức năng kết nối lô-gic.

b) Tính liên kết – Đối với mỗi khuyến nghị có điều kiện có thể áp dụng như đã xác định ở phần a), thông tin về tính liên kết với khuyến nghị cần được xác định bằng cách sử dụng các phương pháp đã đề xuất (ví dụ: nếu 9.5.9 có thể áp dụng được, thì việc quan sát cần được sử dụng để xác định các tập hợp đầu vào dữ liệu khác đã được đưa ra trong các thông báo lỗi).

Hình A.1: Quá trình ra quyết định – Tình huống đánh giá

A.5.2  Các khuyến nghị có điều kiện khác

a) Khả năng áp dụng: các khuyến nghị có điều kiện không có câu giả định thường phù hợp với cho mọi hướng dẫn người sử dụng. Tuy nhiên, một số phần (ví dụ: Điều 10.2 Hỗ trợ chủ động của hệ thống) có thể áp dụng chỉ khi hướng dẫn người sử dụng các tính năng đó. Nếu hướng dẫn người sử dụng bao gồm hỗ trợ chủ động của hệ thống, thì khuyến nghị trong các mệnh đề phụ có thể áp dụng được (và khả năng áp dụng của câu giả định được xác định tại A.5.1).

b) Tính liên kết: đối với mỗi khuyến nghị không có điều kiện câu giả định như đã xác định tại phần a), thông tin về tính liên kết với khuyến nghị được mô tả tại A.5.1 b) là cần thiết. Ví dụ: đánh giá phân tích hoặc đánh giá theo kinh nghiệm đều là những phương pháp phù hợp để xác định tính liên kết có tính đến thời gian người sử dụng nhập mục có phù hợp hay không (7.2.9). Nếu có các lý do hợp lệ để không tuân theo khuyến nghị đã đề xuất, thì cả lý do và giải pháp thiết kế được chọn đều xuất phát từ lợi ích của người sử dụng trong tiêu chuẩn này.

Với tư cách là một phần hỗ trợ cho việc áp dụng các quy trình kiểm nghiệm sự tương thích, một Danh mục kiểm tra đánh giá khả năng áp dụng và tính liên kết được cung cấp tại Bảng A.1.

A.6  Danh mục kiểm tra

CHÚ THÍCH: Người sử dụng trong tiêu chuẩn này có thể tự do sao chép danh mục kiểm trong phụ lục này phục vụ mục đích xác định và xa hơn có thể xuất bản danh mục hoàn chỉnh.

Danh mục kiểm tra tại Bảng A.1 có mục đích như một công cụ hỗ trợ cho cả các nhà thiết kế và nhà đánh giá về hướng dẫn người sử dụng trong việc đánh giá khả năng áp dụng và sự liên kết, các khuyến nghị có điều kiện của tiêu chuẩn này. Danh mục kiểm tra gồm một “phiên bản ngắn” toàn bộ các khuyến nghị có trong tiêu chuẩn này và cung cấp một cấu trúc có lô-gic nhằm đánh giá người sử dụng trong việc xác định khả năng áp dụng. Nhiều khuyến nghị điều kiện cho phép có một số các giải pháp khác nhau. Danh mục kiểm tra mô tả sự phụ thuộc lẫn nhau này thông qua việc sử dụng các từ nối “và” / “hoặc”. Những từ nối này cho thấy không chỉ các khuyến nghị có điều kiện trong một mệnh đề riêng biệt (giả định các mệnh đề có gắn “và” tới mức độ mà mệnh đề đó có thể được áp dụng). Trong một số trường hợp, “và”/ “hoặc” được chỉ rõ do các lựa chọn này không duy nhất ảnh hưởng qua lại với nhau.

A.6.1  Mô tả danh mục kiểm tra

A.6.1.1  Cột các khuyến nghị

Cột đầu tiên của danh mục kiểm tra bao gồm “phiên bản ngắn” của các khuyến nghị có điều kiện, được kết nối bởi các liên kết lô-gic, và phân chia bởi các mệnh đề phụ. Vì mỗi khuyến nghị có điều kiện được đánh số với số mệnh đề phụ của nó, người sử dụng có thể tra cứu toàn bộ văn bản một cách dễ dàng trong các khoản mục phụ và khoản mục chính có liên quan.

A.6.1.2  Các cột khả năng áp dụng

Hai cột đầu tiên của phần khả năng áp dụng của danh mục kiểm tra được cung cấp phục vụ việc ghi chép kết quả xác định khả năng áp dụng bằng cách đánh dấu “Y” hoặc “N” vào cột. Ngoài ra, phần này cũng chỉ rõ các biện pháp có thể áp dụng liên quan đến mỗi khuyến nghị có điều kiện và cung cấp khoảng trống để “đánh dấu” vào phương pháp được sử dụng bởi nhà thiết kế hoặc nhà đánh giá. Các phương pháp có thể không liên quan đến một khuyến nghị riêng biệt nhưng lại được tăng độ đậm dần lên giúp danh mục kiểm tra dễ dàng sử dụng hơn. Các mật mã được dùng cho các phương pháp khả năng áp dụng là:

S = phân tích tài liệu hệ thống

D = Bằng chứng văn bản

O = quan sát

A = đánh giá phân tích

E = đánh giá theo kinh nghiệm

DM = phương pháp khác (ngoài phương pháp được dùng ở trên)

Nếu một phương pháp khác được sử dụng (có nghĩa là “DM” đã được kiểm tra), thì phương pháp đó có thể được mô tả trong cột Nhận xét. Cũng cần lưu ý rằng việc đánh dấu các phương pháp khả năng áp dụng đang sử dụng được xem như một đặc điểm tùy chọn của danh mục kiểm tra.

A.6.1.3  Các cột liên kết

Phần này của danh mục kiểm tra chỉ rõ phương pháp nào là phù hợp đối với việc xác định liên kết tới mỗi khuyến nghị có điều kiện và cung cấp không gian cho nhà thiết kế và nhà đánh giá để “đánh dấu” vào phương pháp được sử dụng. Các phương pháp không liên quan tới một khuyến nghị riêng biệt được tô đậm, giúp danh mục kiểm tra dễ sử dụng hơn. Nếu kết quả kiểm chứng liên kết là khả thi, đánh dấu vào cột “P” (P = đạt) và nếu kết quả không khả quan, đánh dấu vào cột “F” (F= không đạt). Các mật mã được dùng cho các phương pháp liên kết như sau:

M = đo lường

D = Bằng chứng được ghi lại

O = quan sát

A = đánh giá phân tích

E = đánh giá theo kinh nghiệm

DM = phương pháp khác (ngoài phương pháp được dùng ở trên)

Như đối với khả năng áp dụng, nếu phương pháp khác được sử dụng (“DM” được kiểm tra), thì phương pháp đó có thể được mô tả trong cột Nhận xét. Cũng như đã lưu ý cho khả năng áp dụng, việc đánh dấu vào các nội dung sử dụng để đánh giá tính liên kết được xem là một đặc điểm tùy chọn các danh mục kiểm tra.

A.6.1.4  Nhận xét

Cột Nhận xét cung cấp chỗ trống để ghi các câu bổ sung và nhận xét cho mỗi khuyến nghị có điều kiện và có thể được dùng để chỉ rõ nguồn đánh giá (ví dụ: tên chuyên gia, nhan đề bằng chứng được ghi lại) cũng như để mô tả “Các phương pháp khác nhau” khi được sử dụng. Vì các giải pháp khác nhau (phương pháp) có thể phù hợp trong các tình huống cụ thể, tốt nhất là mô tả các giải pháp duy nhất này trong cột Nhận xét. Mô tả này có thể bao gồm cách thức các giải pháp này liên quan đến các khuyến nghị thiết kế hướng dẫn người sử dụng và các nguyên tắc đối thoại phù hợp.

A.6.2  Dữ liệu tóm tắt

Người sử dụng của danh mục kiểm tra Khả năng áp dụng và Tính liên kết có thể tóm tắt các kết quả của việc đánh giá bằng cách tính toán tỉ lệ liên kết (AR). AR là tỉ lệ phần trăm của các khuyến nghị có thể áp dụng thành công liên kết với (có nghĩa là số dấu đánh vào cột “P” chia cho số dấu đánh vào cột “Y”). Cần khuyến cáo rằng tất cả các dữ liệu (có nghĩa là số đánh dấu vào cột P và số đánh dấu vào cột Y) được báo cáo có tính đến cả AR. Tuy nhiên cần lưu ý rằng, AR chỉ đơn thuần là một số đếm có thể được dùng như một phương pháp tính toán tin cậy về mức độ liên kết với các khuyến nghị có khả năng áp dụng mà không cần xét đến trọng số tương ứng của các mục (bởi cả chính các khuyến nghị và trong tình huống sử dụng).

Bảng A.1 – Danh mục kiểm tra khả năng áp dụng và tính liên kết

Các khuyến nghị

Khả năng áp dụng

Gắn kết

Nhận xét

Kết quả

PP sử dụng

PP sử dụng

Kết quả

Y

N

S

D

O

A

E

DM

M

O

D

A

E

DM

P

F

5  Các khuyến nghị hướng dẫn chung

5.2  Các khuyến nghị chung

5.2.1  Thông tin hướng dẫn người sử dụng cần phân biệt rõ với các thông tin được hiển thị khác

5.2.2  Thông tin không còn áp dụng được cho trạng thái hiện thời cần phải được gỡ bỏ khỏi màn hình hiển thị

5.2.3  Hướng dẫn chủ động của người sử dụng cần phải tuân theo sự điều khiển của người sử dụng

5.2.4  Cung cấp cho người sử dụng thông tin cụ thể liên quan đến tình huống nhiệm vụ

5.2.5  Người sử dụng không nên làm gián đoạn nhiệm vụ

5.2.6  Thông điệp riêng hoặc các kỹ thuật mã hóa được sử dụng có sự chú ý đặc biệt

5.2.7  Người sử dụng có khả năng chỉ rõ được mức độ hướng dẫn mà mình mong muốn

5.3  Diễn đạt hướng dẫn người sử dụng

5.3.1  Cần nói rõ kết quả của một hành động trước khi mô tả cách thức thực hiện hành động

5.3.2  Diễn đạt để làm tăng khả năng nhận thức vì sự điều khiển của người sử dụng

5.3.3  Diễn đạt bằng các câu khẳng định, các câu phủ định cũng cần được dùng để chỉ rõ hoặc để nhấn mạnh một điểm nào đó.

5.3.4  Diễn đạt sử dụng cấu trúc ngữ pháp đồng nhất

5.3.5  Văn bản phải được diễn đạt bằng các câu ngắn gọn và đơn giản.

5.3.6  Dùng câu chủ động (trừ khi hướng dẫn này đối lập với ngôn ngữ bản địa của người sử dụng)

5.3.7  Người sử dụng cần sử dụng thuật ngữ mà phần đông người sử dụng để thực hiện nhiệm vụ

5.3.8  Người sử dụng cần diễn đạt bằng cách sử dụng các thuật ngữ mang sắc thái trung lập

6  Dấu nhắc

6.2  Các khuyến nghị về dấu nhắc

6.2.1  Dữ liệu đầu vào sẽ được hệ thống đối thoại chấp nhận (chung chung hoặc cụ thể)

6.2.2  Các dấu nhắc cụ thể cần được hiển thị dưới các điều kiện thích hợp

6.2.3  Các dấu nhắc chung chung cần được hiển thị theo các điều kiện thích hợp

6.2.4  Người sử dụng phải tiếp cận được với hỗ trợ trực tuyến liên quan

6.2.5  Đưa ra các nhắc nhở trong các bước thực hiện trình tự nhiệm vụ

6.2.6  Nhắc cho dữ liệu /lệnh nhập tiếp theo vào trường nhập

6.2.7  Nếu giá trị mặc định được xác định, thì hiển thị dấu nhắc trong trường nhập

6.2.8  Các dấu nhắc cần đưa ra dấu hiệu cho dạng dữ liệu được nhập vào bằng định dạng trường nhập dữ liệu

6.2.9  Con trỏ chuột dạng nhấp nháy tự động định vị trong trường dữ liệu đầu vào

7  Phản hồi

7.2  Các khuyến nghị phản hồi

7.2.1  Mọi dữ liệu đầu vào được nhập bởi người sử dụng cần tạo ra phản hồi kịp thời

7.2.2  Phản hồi gắn với việc thực hiện nhiệm vụ thông thường cần ở chế độ không thể xâm nhập và không được làm người sử dụng xao nhãng khỏi nhiệm vụ

7.2.3  Cần tính đến dạng phản hồi: Đặc điểm người sử dụng, Thay đổi theo nhóm người sử dụng, Các yêu cầu thông tin nhiệm vụ, Năng lực hệ thống

7.2.4 Hệ thống phải chỉ rõ trạng thái bất cứ khi nào trạng thái (hoặc chế độ thay đổi)

7.2.5  Khi chọn mục hiển thị thì mục này cần được hiện sáng

7.2.6  Cung cấp phản hồi cục bộ về yêu cầu dịch vụ từ xa

7.2.7  Cần cung cấp phản hồi về sự hoàn tất yêu cầu

7.2.8  Nếu việc hoàn tất yêu cầu không được thực hiện ngay lập tức, thì hệ thống đối thoại sẽ đưa ra một chỉ thị thông báo yêu cầu đó đã được chấp nhận và chỉ rõ khi nào yêu cầu được hoàn thiện thành công

7.2.9  Thời gian phản hồi cần phù hợp (nghĩa là không quá chậm mà cũng không quá nhanh)

8  Thông tin trạng thái

8.2  Các khuyến nghị trạng thái

8.2.1  Thông tin trạng thái cần được hiển thị liên tục khi thích hợp

8.2.2  Thông tin trạng thái cần được hiển thị tự động khi thích hợp

8.2.3  Thông tin trạng thái chỉ nên hiển thị phản hồi lại yêu cầu khi thích hợp

8.2.4  Mỗi vị trí hiển thị nhất quán cần dùng cho từng dạng thông tin trạng thái

8.2.5  Nếu đầu vào dữ liệu của người sử dụng bị vô hiệu hóa, thì cần đưa ra thông báo bằng một tín hiệu để chỉ rõ trạng thái này

8.2.6  Nếu hệ thống hay ứng dụng có các chế độ, người sử dụng cần có khả năng phân biệt trạng thái hiện tại và các trạng thái khác

9  Quản lý lỗi

9.2  Phòng ngừa lỗi

9.2.1  Cung cấp các hoạt động phòng ngừa lỗi khi thích hợp

9.2.2  Cung cấp các hoạt động phòng ngừa lỗi về các ứng dụng của chế độ

9.2.3  Cung cấp thông tin người dùng về vướng mắc tiềm ẩn của hệ thống

9.2.4  Cung cấp thông điệp xác nhận về việc ngăn ngừa dữ liệu bị mất

9.2.5  Một thông điệp cảnh báo hoặc xác nhận sẽ được đưa ra để báo cho người dùng biết những hậu quả có thể xảy đến trước khi thực hiện hành động được yêu cầu

9.2.6  Người sử dụng có khả năng sửa đổi hoặc hủy bỏ dữ liệu đầu vào, cần được cung cấp một phương tiện để kiểm tra và hủy bỏ các thao tác vận

9.3  Sửa lỗi do hệ thống thực hiện

9.3.1  Việc sửa lỗi do hệ thống thực hiện cần được sử dụng khi thích hợp

9.3.2  Người sử dụng có thể biết cấu hình việc tự động thực hiện sửa lỗi hoặc nhận được cảnh báo

9.4  Quản lý lỗi do người sử dụng thực hiện

9.4.1  Nếu nhiệm vụ yêu cầu việc quản lý lỗi được thực hiện bởi người sử dụng, cần đưa ra một phương thức cho phép người sử dụng tiếp tục đối thoại

9.4.2  Cung cấp các công cụ sửa lỗi

9.4.3  Cung cấp các công cụ chẩn đoán nhận diện lỗi

9.4.4  Người sử dụng cần hiệu chỉnh dữ liệu đầu vào được phép

9.4.5  Nếu xuất hiện đa lỗi trong mục nhập người dùng, cần cung cấp các chỉ thị về tình trạng này

9.5  Các thông điệp báo lỗi

9.5.1  Nếu các thông điệp báo lỗi ngắn gọn được hiển thị, thì người sử dụng có thể yêu cầu thông tin trực tuyến chi tiết hơn

9.5.2  Nếu xuất hiện một lỗi trong trình tự các thao tác vận hành được viện dẫn bởi một thao tác đơn lẻ của người sử dụng, thì cần cung cấp thông tin cho biết các thao tác vận hành hệ thống đã được hoàn thành và chưa được hoàn thành

9.5.3. Các thông điệp báo lỗi cần nói rõ cái gì sai, hành động sửa lỗi nào cần áp dụng và nguyên nhân hoặc các dạng lỗi

9.5.4  Nếu thông điệp báo lỗi được hiển thị trong một vị trí đơn và sẽ chồng lên các thông điệp báo lỗi trước đó, thì người sử dụng cần được cung cấp một tín hiệu cho phép họ có thể phân biệt được sự xuất hiện của thông điệp báo đã nhận diện được lỗi

9.5.5  Các thông điệp báo lỗi cần phải được gỡ bỏ khi đã sửa lỗi hoặc có yêu cầu

9.5.6  Thông tin báo lỗi cần được hiển thị tại một vị trí nhất quán

9.5.7  Hệ thống cần cho phép người sử dụng di chuyển các thông điệp báo lỗi, nếu những thông điệp này che khuất thông tin của nhiệm vụ liên quan

9.5.8  Các thông điệp báo lỗi cần được hiển thị càng nhanh càng tốt sau khi đơn vị liên quan đến nhiệm vụ của dữ liệu đầu vào được nhập

9.5.9  Cung cấp tập hợp các dữ liệu đầu vào cùng với thông điệp báo lỗi

9.5.10  Người sử dụng có khả năng kiểm soát đặc điểm các thông điệp lỗi

10  Hỗ trợ trực tuyến

10.2  Hỗ trợ chủ động của hệ thống

10.2.1  Cung cấp hỗ trợ trực tuyến chủ động của hệ thống khi thích hợp

10.2.2  Không cung cấp hỗ trợ trực tuyến chủ động của hệ thống khi thích hợp

10.2.3  Cung cấp nội dung nhiệm vụ cụ thể cho hỗ trợ trực tuyến chủ động của hệ thống

10.2.4  Cung cấp hỗ trợ trực tuyến chủ động của hệ thống không thể bị xâm nhập

10.2.5  Người sử dụng có thể chủ động hệ thống bằng phương tiện bật / tắt chức năng hỗ trợ trực tuyến

10.3  Hỗ trợ chủ động của người dùng

10.3.1  Cung cấp các yêu cầu hỗ trợ nhất quán và đơn giản

10.3.2  Việc xác định các chủ đề hỗ trợ trực tuyến của người sử dụng cần được cung cấp khi thích hợp

10.3.3  Hỗ trợ hệ thống cho việc cung cấp các chủ đề đã lựa chọn

10.3.4  Nếu người sử dụng yêu cầu một chủ đề hỗ trợ thông qua các phương pháp mà không phải thông qua chọn lựa thì hệ thống sẽ chấp nhận các từ đồng nghĩa và các so khớp chính tả chặt chẽ

10.3.5  Yêu cầu hỗ trợ trực tuyến không xác định được chủ đề tương xứng để được hỗ trợ trực tuyến, cần được hỗ trợ bởi thông tin tình huống hiện tại hoặc một cuộc đối thoại để làm rõ

10.4  Trình bày thông tin hỗ trợ

10.4.1  Chỉ thông tin tương ứng với chủ đề được xác định mới được cung cấp

10.4.2  Hỗ trợ trực tuyến cần được trình diễn càng nhanh càng tốt sau khi nhận được yêu cầu của người sử dụng

10.4.3  Đối với dạng tương tác trực tuyến, thời gian phản hồi của việc trình diễn hỗ trợ trực tuyến cần dự đoán được

10.4.4  Thông tin hỗ trợ trực tuyến cần được cung cấp dưới dạng phương tiện phù hợp nhất để giải thích chủ đề

10.4.5  Hỗ trợ trực tuyến cần cung cấp thông tin liên quan đến nhiệm vụ về hệ thống và mục đích của nó

10.4.6  Hỗ trợ trực tuyến cần khớp với các nhu cầu nhiệm vụ của người sử dụng và nên bao gồm thông tin về cả mô tả lẫn quy trình như yêu cầu của nhiệm vụ

10.5  Điều hướng hỗ trợ và các biện pháp kiểm soát

10.5.1  Nếu việc truy nhập vào hỗ trợ trực tuyến làm người sử dụng thoát ra ngoài đối thoại chính của nhiệm vụ, thì người sử dụng cần được chỉ dẫn cách quay lại và tiếp tục giữa đối thoại thực hiện nhiệm vụ và hỗ trợ trực tuyến

10.5.2  Cần đưa ra sự kết nối giữa thông tin hỗ trợ trực tuyến, đào tạo và tài liệu.

10.5.3  Nếu có thể, cần cung cấp điều khiển hỗ trợ trực tuyến cho người sử dụng

10.5.4  Lựa chọn thông tin hỗ trợ dạng mô-đun để dùng trong các hệ thống hạn chế về năng lực

10.5.5  Hệ thống nên cho phép người sử dụng tùy biến hỗ trợ trực tuyến

10.5.6  Nếu hỗ trợ trực tuyến được triển khai như một chế độ, thì người sử dụng cần biết rõ cách thoát ra khỏi chế độ và quay trở lại.

10.6  Hỗ trợ khả năng duyệt

10.6.1  Người sử dụng cần có khả năng duyệt qua các hiển thị hỗ trợ trực tuyến

10.6.2  Cung cấp danh sách hoặc sơ đồ về các chủ đề hỗ trợ trực tuyến

10.6.3  Hỗ trợ cho số lượng lớn các chủ đề hỗ trợ được cung cấp

10.6.4  Nếu có thể áp dụng được, cần cung cấp các hỗ trợ trình duyệt

10.6.5  Cần cung cấp các cơ chế truy nhập nhanh

10.6.6  Cấu trúc phân cấp giúp hỗ trợ một cách thích hợp

10.6.7  Nếu người sử dụng có thể truy nhập vào các chủ đề hỗ trợ trực tuyến theo một đường truy cập ngẫu nhiên, thì thông tin hỗ trợ trực tuyến nên tồn tại độc lập

10.6.8  Nếu thông tin hỗ trợ trực tuyến mở rộng ra ngoài màn hình hiển thị đơn và các cuộn thông tin, thì chủ đề thông tin cần giữ nguyên tính rõ ràng

10.7  Hỗ trợ tình huống nhạy cảm

10.7.1  Cung cấp các bước hoặc thông tin cụ thể khi hỗ trợ các yêu cầu nhiệm vụ

10.7.2  Cung cấp dữ liệu về thông tin tình huống thích hợp

10.7.3  Cần chọn lựa một mặc định trong khi cho phép người sử dụng truy nhập vào các chủ đề khác

10.7.4  Hỗ trợ trực tuyến dành riêng cho các đối tượng giao diện người sử dụng cần đưa ra lời giải thích đối tượng

10.7.5  Nếu hỗ trợ trực tuyến chỉ dành riêng cho một tập con các đối tượng giao diện người sử dụng, thì cần cung cấp một chỉ thị bằng hình ảnh nêu rõ những đối tượng nào có thể được giải thích

Từ khóa Y = Có khả năng áp dụng N = Không có khả năng áp dụng

S = phân tích tài liệu hệ thống D = Bằng chứng được ghi lại O = quan sát

A = đánh giá phân tích E = đánh giá thực nghiệm DM = phương pháp khác

M = phương pháp đo P = Đạt (khả thi) F = Không đạt (không khả thi)

 

Phụ lục B

(tham khảo)

Thư mục tài liệu tham khảo

[1] AKSCYN, R.M., McCRACKEN, D.L. and YODER, E.A., KMS: A distributed hypermedia system for maintaining knowledge in organizations, Communications of the ACM, 1986, 31, 7, 820-835.

[2] Bell Communications Research, Guidelines for Dialog and Screen Design, JA-STS-000045, Sept. 1986. Piscataway, N.J. (based on course Dialog and Screen Design, Bell Communications Research, 1985).

[3] BUTLER, T.W., Computer response time and user performance during data entry. Bell Laboratories Technical Journal, 1984, 63, 100710018.

[4] BORENSTEIN, N.S., Help texts vs. Help Mechanisms: A new mandate for Documentation Writers. Proceedings of the 1985 SIGDOC Annual Meeting, 1985, 8-10.

[5] CARBONELL, J.R., ELKIND, J.l. and NICKERSON, R.S., on the psychological importance of time in a time-sharing system. Human Factors, 1969, 10, 135-142.

[6] CHEN, H. and K. TSOI, Factors affecting the readability of moving text on a computer display. Human Factors, 1988, 30, 25-33.

[7] CLARK, H.H., and CLARK, E.V., Semantic distinctions and memory for complex sentences. Quarterly Journal of Experimental Psychology, 1968, 20, 129-138.

[8] COHILL, A.M., and WILLIGES, R.C., Computer-augmented retrieval of HELP information for novice use. Proceedings of Human Factors Society – 26th Annual Meeting, 1982, 79-82.

[9] COHILL, A.M., and WILLIGES, R.C., Retrieval of Help information for novice users of interactive computer systems. Human Factors, 1985, 27, 335-343.

[10] CONKLIN, J. A survey of Hypertext, STP-356-86 Rev.2., Microelectronics and Computer Technology Corporation, 1987.

[11] DIN 66 234, Part 8, Display Work Stations Principles of Dialog Design, Deutsches Institut fur Normung, 1986.

[12] ENGEL, S.E. and GRANDA, R., Guidelines for Man/Display Interfaces. Technical Report TR 00.27200, IBM Poughkeepsie, New York, Dec. 1975.

[13] FECHT, B.A., RIDEOUT, T.B., RANKIN, W.L., BARNES, V.E., SAARI, L.M., TRIGGS, and DESTEESE J.G., Human Factors Applications to Computer-Aided System Design in LNG Facilities, Volume 1 Design Principles. Technical Report GRI-85/0183.1, Batteile Pacific Northwest Laboratories, Richland, Washington 99352, 1985.

[14] FISHER, G., Computational models of skill acquisition processes. InR. Lewis and D.Tagg (Ed.) Computers in Education, World Conference on Computers and Education, Lausanne, Switzerland, 1981, 477-481.

[15] FISHER, G., LEMKE, A., and SCHWAB, T., Active help systems. In Green, et al. (Ed..) Cognitive Ergonomics, Mind and Computer, Proceedings of the Second European Conference on Cognitive Ergonomics, Mind and Computer, Sept. 1984.

[16] FORLEY, J.D., and VAN Dam, A., Fundamentals of Interactive Computer Graphics, Addison-Wesley, Reading, MA, 1982.

[17] GREGORY, M. and POULTON, E.C., Even versus uneven right-hand margins and the rate of comprehension in reading. Ergonomics, 1970, 13, 427-434.

[18] Human Computer Interaction Standards Committee. General consensus of committee members.

[19] HORTON, W.K., Designing and Writing On-line Documentation. John Wiley and Sons, 1990.

[20] JOHNSON-LAIRD, P.N., and TRIDGELL, J.M., When negation is easier than affirmation. Quarterly Journal of Experimental Psychology, 1972, 24, 87-91.

[21] KEARSLEY, G., On-line Help Systems: Design and Implementation, Ablex Publishing Corp., Norwood, New Jersey, 1988.

[22] KEISTER, L, and SHNEIDERMAN. B., Making software user friendly, an assessment of data entry performance. Proceedings of the Human Factors Society 27th Annual Meeting. Santa Monica, Ca: Human Factors Society, 1983.

[23] LIMANOWSKI, J.J., On-line documentation system: History and issues. Proceedings of Human Factors Society 27th Annual Meeting. Santa Monica, CA: Human Factors Society, 1983.

[24] MAGERS, C.S., An experimental evaluation of on-line Help for non-programmers. Proceedings of CHI’83 Human Factors in Computing Systems. New York: Association for Computing Machinery, 1983.

[25] MIL-STD-1472C. Military standard: Human engineering requirements for military systems, equipment and facilities. Washington, DC: Department of Defense, Sept. 1983.

[26] MONK, A., Mode errors: a user-centred analysis and some preventative measures using keying contingent sound. International Journal of Man-Machine Studies, 1986, 2, 313-327.

[27] MOSKEL, S., ERNO, J., and SHNEIDERMAN, B., Proofreading and comprehension of text on screens and paper. University of Maryland Computer Science Technical Report, June 1984.

[28] NEAL, A.S., Time intervals between keystrokes, records, and fields in data entry with skilled operators, Human Factors, 1977,19,163-170.

[29] PAKIN, S.E. and WRAY, P., (1982). Designing screens for people to use easily. Data Management, 1982, 20, 36-41.

[30] PARON, D., HUFFMAN, K., PRIDGEN, P., NORMAN, K. and SHNEIDERMAN, B., Learning a menu selection tree: training methods compared. Behaviour and Information Technology, 1985, 4, 81-91.

[31] RAMSEY, H.R., and ATWOOD, M.E., Human Factors in Computer Systems: A Review of the Literature. Technical Report No. SAI-79-111-DEN. Science Applications Inc., Denver, CO, 1979.

[32] RUBINSTEIN, R. and HERSH, H., The Human Factor: Designing Computer Systems for People, Digital Press, Burlington, MA, 1984.

[33] SHNEIDERMAN, B., System message design: Guidelines and experimental results. In Badre, A., and Shneiderman, B. (Editors), Directions in Human Computer Interaction, Ablex Publishers, Norwood, NJ, 1982, 55-78.

[34] SHNEIDERNAM, B., Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley Publishing, 1987.

[35] SLATIN, J., Hypertext and the teaching of writing. In Text, ConText and HyperText: Writing with and for the Computer. Cambridge, MA: The MIT Press, 1988, 111-129.

[36] SMITH, S.L., Exploring compatibility with words and pictures. Human Factors, 1981,23, 305-315.

[37] SMITH, S.L., and AUCELLA, A.F., 1983. Design Guidelines for the User Interface to Computer- Based Information Systems. Technical Report ESD-TR-83-122m NTIS AD A127345, USAF Electronic Systems Division, Hanscom Air Force Base, Massachusetts.

[38] SMITH, S.L. and. MOSIER, J.N., 1986. Design Guidelines for the User Interface for Computer-Based Information Systems. Technical Report ESD-TR-86-278, Mitre, Bedford Massachusetts.

[39] SNOWBERRY, K., Parkinson, and Sisson, N., Effects of help fields on navigating through hierarchical menu structures. International Journal of Man-Machine Studies, 1985, 22, 479-491.

[40] STIBIC, V., A few practical remarks on the user-friendliness of on-line systems. Journal of Information Science, 1980, 2, 277-283.

[41] TIJERINA, L, CHEVALAZ, G., and L.B. MYERS., 1985. Human Factors Aspects of Computer Menus and Displays in Military Equipment. BalieWe Colombus Division, Columbus Ohio 43201-2693.

[42] TINKER, M.A., Prolonged reading tasks in visual research. Journal of Applied Psychology, 1955, 39, 444-446.

[43] WASON, P.C., The contexts of plausible denial. Journal of Verbal Learning and Verbal Behaviour. 1965, 4, 7-11.

[44] WATLEY, C. and MULFORD, J., A comparison of commands documentation: On-line vs hard copy, Unpublished student project, University of Maryland, 1983, cited in B. Shneidemnan Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley Publishing, 1987.

[45] WHITE, C.T., Eye movements, evoked responses and visual perception: some speculations. Acta Psychologica, 1976, 27, 337-340.

[46] WOGALTER, M.S., GODFREY, S.S., FONTENELLE, G.A., DESAULNIERS, D.R. ROTHSTEIN, P.R., and LAUGHERY, K.R. Effectiveness of Warnings, Human Factors, 1987, 29(5), 599-612.