Thiết kế giao diện người dùng

Bối cảnh sử dụng

Chương này nhằm mục đích giúp các nhà thiết kế và phát triển giao diện người dùng hiểu các vấn đề liên quan đến các ứng dụng tương tác đa thiết bị, có thể được truy cập thông qua các thiết bị di động và cố định, thậm chí khai thác các phương thức tương tác khác nhau (đồ họa, giọng nói, v.v.). Chương này thảo luận về các giải pháp khả thi về khái niệm, kỹ thuật, ngôn ngữ và công cụ, đặc biệt chú ý đến môi trường Web. Chương này đề cập đến các chiến lược khác nhau để điều chỉnh, phân phối và di chuyển giao diện người dùng tùy theo ngữ cảnh sử dụng. Nó xem xét cách giải quyết các vấn đề như vậy cả khi tạo giao diện đa thiết bị và khi giao diện người dùng cho các thiết bị khác nhau được điều chỉnh động, phân phối hoặc thậm chí được di chuyển liền mạch giữa các thiết bị để theo dõi người dùng di động. Do đó, nó thảo luận về tính liên tục của nhiệm vụ trên nhiều thiết bị trong giao diện di chuyển cũng như các vấn đề về khả năng sử dụng liên quan .

39.1 Giới thiệu

Một trong những lý do chính giải thích tầm quan trọng ngày càng tăng của việc thích ứng là chúng ta tương tác với các ứng dụng của mình trong các bối cảnh sử dụng ngày càng đa dạng hơn do sự ra đời của công nghệ di động và môi trường thông minh.

Các khía cạnh khác nhau có thể là một phần của bối cảnh sử dụng có thể có và có thể được nhóm lại theo bốn chiều (xem Hình 1):

  • các khía cạnh liên quan đến người dùng : sở thích, mục tiêu và nhiệm vụ, trạng thái thể chất (ví dụ: vị trí), trạng thái cảm xúc, v.v.;
  • các khía cạnh liên quan đến công nghệ : độ phân giải màn hình, kết nối, trình duyệt, pin, v.v.;
  • các khía cạnh liên quan đến môi trường : vị trí, ánh sáng, tiếng ồn, v.v.;
  • các khía cạnh xã hội : quy tắc riêng tư, cộng tác , v.v.

Theo những thay đổi trong các khía cạnh đó của bối cảnh sử dụng, bất kỳ khía cạnh nào đặc trưng cho giao diện người dùng đều có thể được sửa đổi. Do đó, giao diện người dùng có thể được điều chỉnh theo: cách trình bày — các khía cạnh có thể cảm nhận được, bao gồm phương tiện và kỹ thuật tương tác, bố cục, các thuộc tính đồ họa; hành vi động , bao gồm cấu trúc điều hướng , kích hoạt động và hủy kích hoạt các kỹ thuật tương tác; và nội dung , bao gồm văn bản, nhãn và hình ảnh.

Có thể có nhiều chiến lược thích ứng khác nhau, có thể được phân loại theo tác động của chúng đối với giao diện người dùng: bảo tồn , ví dụ: mở rộng quy mô đơn giản của các phần tử giao diện người dùng; sự sắp xếp lại , ví dụ như thay đổi cách bố trí; đơn giản hóa / phóng đại , các yếu tố giao diện người dùng giống nhau nhưng với cách trình bày được sửa đổi; tăng (còn gọi là nâng cao lũy tiến ) / giảm (còn gọi là giảm cấp duyên ), xét về các yếu tố giao diện người dùng.

Bối cảnh sử dụng

Tác giả / Người giữ bản quyền: Được phép của Fabio Paterno. Điều khoản bản quyền và giấy phép: CC-Att-ND-3 (Creative Commons Attribution-NoDerivs 3.0 Unported).

Hình 39.1 : Bối cảnh sử dụng

Một trong những lý do chính cho sự quan tâm ngày càng tăng đến việc thích ứng với giao diện người dùng là sự phân mảnh thiết bị được kích thích bởi sự phát triển của công nghệ, đặc biệt là trong các thiết bị di động. Phân mảnh thiết bị liên quan đến phần cứng và hỗ trợ cho các định dạng, trình duyệt, phát lại / phát trực tuyến âm thanh / video, v.v. Ví dụ: về màn hình, chúng ta có thể nhận thấy rằng độ phân giải màn hình của máy tính cá nhân (PC) thường khác nhau giữa 800×600 và 1920×1200 pixel, trong khi đó của thiết bị di động có sự thay đổi trong khoảng từ 320×240 đến 1136×640 pixel (iPhone 5) và lên đến 1920 × 1080 (Galaxy S 4). Do đó, độ phân giải màn hình thay đổi nhiều hơn với thiết bị di động so với máy tính để bàn. Điểm thú vị là Định luật Moore liên tục thay đổi những con số này, và chúng ta có thể mong đợi nhiều phương sai hơn nữa trong tương lai gần.

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng cửa in 2 days :

    Các mẫu thiết kế giao diện người dùng cho phần mềm thành công

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

Trong những năm gần đây, công nghệ di động đã phát triển đáng kể. Chúng ta có thể dễ dàng nhận ra điều này nếu chúng ta nhìn vào cách tương tác đã thay đổi trong điện thoại thông minh của chúng ta. Các thiết bị cũ nhất có tương tác dựa trên tiêu điểm , trong đó tiêu điểm của trình duyệt xoay vòng qua các phần tử; tiêu điểm hiện tại của trang được xác định dễ dàng vì phần tử tiêu điểm được đánh dấu và tiêu điểm di chuyển từ phần tử có thể chọn này sang phần tử có thể chọn khác (ví dụ: từ liên kết này sang liên kết khác) chỉ tuần tự, ngay cả khi cách xa nhau (điều này có thể mất một chút thời gian). Sau đó, các thiết bị hỗ trợ tương tác dựa trên con trỏ đã được đề xuất, trong đó dựa trên khóađiều hướng điều khiển một con trỏ có thể che bất kỳ phần nào của màn hình. Với giải pháp này, các phần tử có thể lựa chọn cần phải đủ lớn để có thể dễ dàng chọn, vì con trỏ thường di chuyển theo các bước từ 5—10 pixel và các phần tử có thể chọn phải có chuyển động để làm rõ khi con trỏ đã vào vùng hoạt động của chúng. Sau tương tác dựa trên con trỏ, giờ đây chúng ta có được sự thành công của tương tác dựa trên cảm ứng , nơi các sự kiện liên quan trực tiếp đến vị trí chạm ngón tay hoặc bút stylus trên màn hình; các phần tử có thể lựa chọn nên được đặt cách nhau rộng rãi để cho phép người dùng chọn chúng một cách chính xác (các nghiên cứu đề xuất từ ​​7mm đến 9,6mm), các phần tử có thể chọn phải đủ lớn để dễ dàng lựa chọn; không có phần tử nào nằm trong tiêu điểm cho đến khi chúng được chọn vì vậy thông tin bổ sung không thể được chuyển cho người dùng (ví dụ: chuyển đổi không hiệu quả).

Các khía cạnh thiết kế khác nhau có thể hữu ích trong việc hỗ trợ khả năng sử dụng trong tương tác di động. Chúng tôi phải xem xét rằng người dùng có thể đang di chuyển và có thể chú ý hạn chế đến sự tương tác. Do đó, điều quan trọng là giảm thiểu việc nhập văn bản, giữ tính nhất quán giữa các nền tảng để kiến ​​thức ứng dụng thu được thông qua tương tác với máy tính để bàn có thể được sử dụng lại trong truy cập di động và do đó ngăn ngừa lỗi người dùng, tránh quá tải giao diện người dùng với quá nhiều thành phần, hạn chế nhu cầu phóng to, và ngăn các lựa chọn cảm ứng bỏ sót mục tiêu đã định. Nói chung, chúng ta phải xem xét rằng người dùng di động thường có sẵn thời gian truy cập ngắn, và do đó họ thích truy cập vào các mẩu thông tin nhỏ.

Nhìn chung hơn, chúng ta phải xem xét rằng cuộc sống của chúng ta đang trở thành trải nghiệm người dùng đa thiết bị . Thật vậy, một nghiên cứu gần đây (Google, 2012) cho thấy thời gian trực tuyến của chúng ta trải dài trên bốn loại thiết bị (điện thoại thông minh, máy tính bảng, PC / máy tính xách tay, TV). Có hai chế độ sử dụng chúng: sử dụng tuần tự , di chuyển từ thiết bị này sang thiết bị khác vào những thời điểm khác nhau để hoàn thành nhiệm vụ; và sử dụng đồng thời, sử dụng nhiều thiết bị cùng lúc cho một hoạt động có liên quan hoặc không liên quan. Quản lý thông tin trên các thiết bị như vậy là một khía cạnh thách thức của việc sử dụng nhiều thiết bị. Nhìn chung, các vấn đề chính trong giao diện người dùng đa thiết bị là: kém thích ứng với bối cảnh sử dụng, thiếu sự phối hợp giữa các tác vụ được thực hiện thông qua các thiết bị khác nhau, hỗ trợ không đầy đủ để thực hiện tác vụ xuyên thiết bị liền mạch.

Một số nghiên cứu đã bắt đầu điều tra những gì đặc trưng cho trải nghiệm người dùng trong việc truy cập ứng dụng trên nhiều thiết bị. Ví dụ, trong Waljas et al. (2010) các tác giả đã xác định ba khía cạnh quan trọng để cải thiện trải nghiệm người dùng trên nhiều thiết bị: sự phù hợp với hiệu suất tác vụ , để cấu trúc của ứng dụng tương tác cung cấp sự phù hợp hiệu quả với những gì người dùng mong đợi thực hiện trong từng loại thiết bị ; tính liên tục , để luồng tương tác giữa các thiết bị được coi là trôi chảy và được kết nối; nhất quán , các giao diện người dùng cho các loại thiết bị khác nhau phải được coi là các phần mạch lạc, vẫn của cùng một ứng dụng.

39.2 Giao diện người dùng / Tác vụ / Quan hệ nền tảng

Trong phần này, chúng ta thảo luận về một khuôn khổ hợp lý cho phép các nhà thiết kế suy nghĩ về các mối quan hệ có thể có khác nhau giữa các tác vụ cần thực hiện, giao diện người dùng và các nền tảng có sẵn. Theo nền tảng, chúng tôi có nghĩa là các nhóm thiết bị chia sẻ tài nguyên tương tác giống nhau, ví dụ như máy tính để bàn, điện thoại thông minh, máy tính bảng. Đặc biệt, chúng tôi đã xác định được năm mối quan hệ có thể có:

  • Cùng một tác vụ với cùng một giao diện người dùng trên các nền tảng khác nhau
  • Cùng một nhiệm vụ với giao diện người dùng khác nhau trên các nền tảng khác nhau
  • Cùng một nhiệm vụ chính với các cấp độ nhiệm vụ phụ khác nhau trên các nền tảng khác nhau
  • Sự phụ thuộc giữa các tác vụ khác nhau được thực hiện trên các nền tảng khác nhau
  • Các tác vụ chỉ có ý nghĩa trên một số loại nền tảng (ví dụ: vì chúng yêu cầu truy cập rất dài hoặc liên quan đến vị trí di động hoặc đến thiết bị cụ thể như máy ảnh).

Do sự mở rộng nhanh chóng của công nghệ di động nên thực sự có sự khác biệt đáng kể giữa các nền tảng khác nhau. Hệ quả là đôi khi đối với cùng một tác vụ, các giao diện người dùng khác nhau sẽ thích hợp hơn tùy thuộc vào nền tảng và một số tác vụ cụ thể chỉ thực sự thích hợp cho một nền tảng cụ thể. Ví dụ, xem một trận đấu bóng đá không có ý nghĩa gì bằng điện thoại thông minh, ngay cả khi điều này là có thể về mặt kỹ thuật, vì màn hình nhỏ không phù hợp với thời lượng chín mươi phút và nhiều chi tiết của trận đấu không thể được đánh giá cao. Mặt khác, đây là một hoạt động thú vị để thực hiện khi thoải mái ngồi trên ghế sofa với màn hình lớn trước mặt bạn ở một khoảng cách thích hợp.

Hình 2 cho thấy một ví dụ về cùng một tác vụ với các giao diện người dùng khác nhau trên các nền tảng khác nhau. Nhiệm vụ đang hiển thị thông tin không gian. Ở bên trái có phiên bản dành cho thiết bị để bàn, phiên bản này bao phủ một khu vực không gian rộng hơn và cũng cung cấp điểm nhấn tổng quan về vị trí của chế độ xem chi tiết. Ở bên phải, phiên bản dành cho thiết bị di động làm nổi bật vị trí hiện tại của người dùng di động, hiển thị một khu vực nhỏ hơn với điều khiển cảm ứng để thay đổi mức thu phóng.

user interface design adaptation.002

Tác giả / Chủ bản quyền: Google Maps. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

user interface design adaptation.003

Tác giả / Chủ bản quyền: Google Maps. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.2 AB : Ví dụ về cùng một tác vụ với các giao diện người dùng khác nhau

Hình 3 cho thấy một ví dụ thứ hai về cùng một nhiệm vụ chính với các giao diện người dùng khác nhau và một số nhiệm vụ phụ khác nhau. Trong trường hợp này, nhiệm vụ chính là hiển thị thông tin liên quan đến các chuyến bay của một hãng hàng không. Chúng tôi có thể nhận thấy rằng cả hai giao diện người dùng đều hỗ trợ khả năng tìm kiếm chuyến bay và đặt chỗ, nhưng thông qua các cách trình bày và bố cục khác nhau; trong phiên bản di động, các yếu tố tương tác lớn hơn để tạo điều kiện tương tác chạm; trong phiên bản dành cho máy tính để bàn cũng có khả năng truy cập thông tin bổ sung, ví dụ: liên quan đến các chương trình khuyến mãi.

user interface design adaptation.004

Tác giả / Đơn vị giữ bản quyền: Air France. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

user interface design adaptation.005

Tác giả / Đơn vị giữ bản quyền: Air France. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.3 AB : Ví dụ về cùng một tác vụ với các giao diện người dùng khác nhau

Hình tiếp theo cho thấy hai ví dụ về các ứng dụng trong đó phiên bản di động hỗ trợ một số tác vụ chỉ có ý nghĩa đối với nền tảng đó. Ở trên cùng, một ví dụ tìm kiếm với từ khóa ‘nhà hàng’: phiên bản dành cho thiết bị di động hiển thị một tập hợp các nhà hàng lân cận trên bản đồ và trong danh sách, trong đó mỗi phần tử có một nút để bắt đầu cuộc gọi điện thoại ngay lập tức đến nhà hàng tương ứng. Ở phía dưới bên phải, chúng ta có thể thấy phiên bản Flickr dành cho thiết bị di động giúp hiển thị ảnh được chụp gần vị trí hiện tại trên thiết bị di động như thế nào.

user interface design adaptation.006

Tác giả / Chủ bản quyền: Google Maps. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

user interface design adaptation.007

Tác giả / Chủ bản quyền: Google Maps. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

user interface design adaptation.008

Tác giả / Chủ bản quyền: Flickr. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

user interface design adaptation.009

Tác giả / Chủ bản quyền: Flickr. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.4 ABCD : Ví dụ về các nhiệm vụ chỉ có ý nghĩa trên một số nền tảng

39.3 Tạo ứng dụng tương tác đa thiết bị

Việc tạo ra các ứng dụng tương tác trên nhiều thiết bị đòi hỏi phải thay đổi các cách truyền thống để phát triển các ứng dụng tương tác. Có nhiều cách khác nhau để giải quyết vấn đề này. Cách đơn giản nhất là phát triển các phiên bản cụ thể riêng biệt cho từng nền tảng mục tiêu. Bằng cách này, các nhà phát triển có toàn quyền kiểm soát các khía cạnh cụ thể của từng phiên bản. Tuy nhiên, điều này có nghĩa là nhân nỗ lực phát triển một ứng dụng tương tác với số lượng nền tảng mục tiêu. Do đó, nó ngụ ý nỗ lực nhiều hơn trong việc phát triển và bảo trì. Thật vậy, nếu có gì đó phải thay đổi trong ứng dụng thì mỗi phiên bản cần được cập nhật.

Một cách tiếp cận khác bao gồm phát triển một phiên bản chính với bố cục linh hoạt và các cuộc lật đổ. Đây là những gì xảy ra với thiết kế Web đáp ứng , trong đó các tác giả triển khai bố cục lỏng và sử dụng hỗ trợ truy vấn phương tiện để xác định các loại thiết bị khác nhau. Đối với mỗi kiểu được xác định, họ cung cấp các bảng định kiểu mà qua đó họ có thể thay đổi giá trị của một số thuộc tính hoặc hiển thị hoặc ẩn một số phần tử. Đây có thể là một cách tương đối rẻ để giải quyết vấn đề, nhưng nó có thể hạn chế sự khác biệt giữa các phiên bản có thể có trong một số trường hợp, vì các bảng định kiểu không cho phép thay đổi sâu trong cấu trúc của các ứng dụng tương tác.

Một cách tiếp cận khác là tác giả đơn lẻ, trong đó một mô tả khái niệm về ứng dụng tương tác được phát triển, từ đó thu được các phiên bản khác nhau được tối ưu hóa cho các nền tảng mục tiêu khác nhau. Một giải pháp khác là tự động ủy quyền lại, trong đó điểm bắt đầu là triển khai cho một nền tảng cụ thể, sau đó lấy các triển khai phù hợp với các nền tảng khác nhau thông qua các chuyển đổi thích hợp.

Trong cộng đồng nghiên cứu, nhiều giải pháp khác nhau cho mục đích này đã được đề xuất. Một ví dụ là SUPPLE (Gajos, Weld và Wobbrock, 2010) , trong đó có đặc điểm kỹ thuật chức năng của giao diện, các ràng buộc dành riêng cho thiết bị, dấu vết sử dụng điển hình và hàm chi phí. Hàm chi phí dựa trên sở thích của người dùng và tốc độ hoạt động dự kiến. Thuật toán tối ưu hóa của SUPPLE tìm ra giao diện người dùng, điều này giúp giảm thiểu hàm chi phí trong khi vẫn đáp ứng tất cả các ràng buộc của thiết bị.

Môi trường BỔ SUNG (Gajos, Weld và Wobbrock, 2010)

Tác giả / Chủ bản quyền: SUPPLE (Gajos, Weld và Wobbrock). Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 39.5 : Môi trường BỔ SUNG (Gajos, Weld và Wobbrock, 2010)

Sau đó, các tác giả SUPPLE tập trung vào cách khai thác SUPPLE để hỗ trợ người dùng khuyết tật, chẳng hạn như bằng cách tự động tạo giao diện người dùng cho người dùng bị khiếm khuyết về độ khéo léo dựa trên mô hình khả năng vận động thực tế của họ. Nhìn chung, chúng ta có thể coi việc thích ứng là hữu ích cho cả khuyết tật vĩnh viễn và tạm thời. Một ví dụ về tình trạng khuyết tật tạm thời là khi người dùng phải di chuyển nhanh và tương tác với thiết bị di động đồ họa. Do đó, sự chú ý trực quan của người dùng không thể được phân bổ hoàn toàn cho tương tác.

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng cửa in 2 days :

    Các mẫu thiết kế giao diện người dùng cho phần mềm thành công

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

Một trong những cách tiếp cận đầu tiên để tạo ra giao diện người dùng đa thiết bị là Damask (Lin và Landay, 2008), hỗ trợ tác giả cho ba loại nền tảng: máy tính để bàn, điện thoại thông minh và giọng nói. Damask dựa trên ba khía cạnh: phác thảo, lớp và hoa văn. Bản phác thảo được sử dụng để dễ dàng chỉ ra giao diện người dùng trông như thế nào. Các lớp cho biết liệu một phần giao diện người dùng nên được phân bổ cho tất cả các thiết bị hay chỉ cho một nền tảng cụ thể. Các mẫu được sử dụng để xác định các giải pháp cho các vấn đề lặp lại nhằm tạo điều kiện sử dụng lại chúng trên các ứng dụng khác nhau.

Môi trường tác giả Damask (Lin và Landay, 2008)

Tác giả / Người giữ bản quyền: Damask (Lin và Landay). Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 39.6 : Môi trường tác giả Damask (Lin và Landay, 2008)

39.4 Quy tắc thích ứng

Cách giao diện người dùng thích ứng với bối cảnh sử dụng có thể được mô tả thông qua các quy tắc có thể được phân loại theo các loại hiệu quả mà chúng có thể đạt được.

Một số bản chuyển thể bao gồm các quy tắc thay thế : chúng chỉ ra cách thay thế một số yếu tố theo nền tảng hiện tại. Các phần tử cần thay thế có thể là các phần tử giao diện người dùng đơn lẻ như trong Hình 7. Ở dưới cùng, chúng ta có thể thấy một ứng dụng để truy cập lịch trình tàu trên phiên bản máy tính để bàn hỗ trợ chọn giờ thông qua một menu thả xuống dài trong khi phiên bản di động sử dụng một nút radio với một số tùy chọn hạn chế vì các giờ có thể được nhóm lại.

Ví dụ về các quy tắc thay thế cho các phần tử đơn lẻ

Tác giả / Chủ bản quyền: Được phép của TrenItalia, ViaggiaTreno (AllRightsRerserved, FairUse). Điều khoản bản quyền và giấy phép: compositeWorkWithMultipleCopyrightTerms (Tác phẩm bắt nguồn từ hoặc bao gồm nhiều tác phẩm với các điều khoản bản quyền khác nhau và / hoặc chủ sở hữu bản quyền).

Hình 39.7 : Ví dụ về các quy tắc thay thế cho các phần tử đơn lẻ

Hình 8 cho thấy cách áp dụng quy tắc thay thế cho một nhóm các phần tử thay vì các phần tử đơn lẻ. Trong trường hợp này, nhóm đề cập đến kết quả truy vấn liên quan đến các khách sạn cho một vị trí nhất định. Phiên bản dành cho máy tính để bàn (bên trái) hiển thị nhóm kết quả theo cách để cung cấp thông tin bổ sung (chẳng hạn như nhận xét từ khách truy cập trước đó), trong khi phiên bản dành cho thiết bị di động (bên phải) chỉ hiển thị chi tiết theo yêu cầu, thông qua các phần tử có thể dễ dàng chọn bằng cách chạm .

Ví dụ về quy tắc thay thế cho một nhóm phần tử.

Tác giả / Chủ bản quyền: TripAdvisor. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.8 : Các ví dụ về quy tắc thay thế cho một nhóm phần tử.

Một loại quy tắc khác là chia giao diện người dùng thành hai hoặc nhiều bản trình bày riêng biệt. Các giao diện mới có thể được lấy theo hai cách: hoặc bằng cách thực hiện việc tạo các giao diện người dùng riêng biệt hoặc bằng cách hiển thị động và ẩn các phần tử để đạt được hiệu ứng tương tự. Hình 9 cho thấy một ví dụ về tách trang. Nó đề cập đến trò chơi PacMan nổi tiếng: bên trái là bản trình bày trang đơn, bên phải là phiên bản dành cho màn hình nhỏ, trong đó có hai bản trình bày: một để chơi trò chơi và một để xác định các cài đặt khác nhau.

Ví dụ về tách trang

Tác giả / Người giữ bản quyền: Nhiều cách triển khai khác nhau của PacMan (bản quyền của Namco Limited). Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.9 : Ví dụ về tách trang

Trong các trường hợp khác, sự thích ứng cần các quy tắc loại bỏ. Mục đích là xóa nội dung được coi là không liên quan đến thiết bị mục tiêu. Có thể có nhiều lý do khác nhau cho điều này: hạn chế về công nghệ hoặc lựa chọn của nhà sản xuất (ví dụ: iPhone không hỗ trợ video Flash); đối tượng bị loại bỏ vì quá tốn kém về tài nguyên tiêu thụ trong thiết bị mới; các yếu tố hỗ trợ các nhiệm vụ được coi là không liên quan đối với thiết bị mục tiêu. Điều quan trọng cần nhớ là việc loại bỏ các phần tử có thể có tác động đến việc thực thi tập lệnh vì chúng có thể tham chiếu đến chúng và nếu chúng bị loại bỏ thì các tập lệnh có thể không hoạt động bình thường.

Các quy tắc thích ứng được sử dụng nhiều nhất là những quy tắc nhằm mục đích thay đổi một số thuộc tính giao diện người dùng. Trong trường hợp này, các phần tử giao diện người dùng giống nhau nhưng cách trình bày của chúng thay đổi về: thuộc tính của chúng (ví dụ: màu sắc, kích thước, v.v.): vị trí của chúng trong giao diện người dùng; không gian giữa chúng; cấu trúc giao diện người dùng tổng thể.

Các quy tắc thích ứng có thể được thể hiện dưới dạng: Sự kiện / Điều kiện / Hành động. Sự kiện xảy ra kích hoạt đánh giá quy tắc. Các sự kiện cơ bản xảy ra trong ứng dụng tương tác hoặc trong ngữ cảnh sử dụng, hoặc một thành phần của các sự kiện đó. Điều kiện (tùy chọn) là một điều kiện Boolean cần được thỏa mãn để thực hiện (các) hành động liên quan; nó có thể liên quan đến điều gì đó đã xảy ra trước đây hoặc một số tình trạng trạng thái. Hành động cho biết mô tả trừu tượng / cụ thể / triển khai của ứng dụng tương tác sẽ thay đổi như thế nào để thực hiện điều chỉnh được yêu cầu. Nó có thể thay đổi giao diện người dùng ở các mức độ chi tiết khác nhau: thay đổi hoàn toàn giao diện người dùng, thay đổi một số phần giao diện người dùng, thay đổi các phần tử giao diện người dùng hoặc thay đổi thuộc tính của các phần tử giao diện người dùng cụ thể. Dưới đây là một số ví dụ về các quy tắc thích ứng:

  • Sự kiện (người dùng đã chọn liên kết đến mô tả máy in); điều kiện (người dùng đã chọn nhiều hơn ba liên kết đến mô tả máy in); hành động (hiển thị năm máy in được bán nhiều nhất)
  • Sự kiện (thay đổi mức pin); tình trạng (nếu mức pin dưới một ngưỡng nhất định); hành động (thay đổi độ sáng màn hình)
  • Sự kiện (người dùng truy cập ứng dụng); tình trạng (người dùng là người cao tuổi); hành động (tăng kích thước phông chữ lên 10%)
  • Sự kiện ((người dùng đang ở ngoài trời) và (đang là giờ ăn trưa)); tình trạng (có nhà hàng gần đó); hành động (hiển thị danh sách các nhà hàng lân cận)
  • Sự kiện (ứng dụng đã truy cập); tình trạng (thiết bị là điện thoại di động); hành động (hiển thị tổng thể và chi tiết trong các bản trình bày khác nhau)

Nếu chúng ta muốn xem xét các ứng dụng trong đó khả năng tiếp cận là một khía cạnh quan trọng, chúng ta có thể có các ví dụ khác nhau về các quy tắc thích ứng (Minon et al. 2013):

  • Sự kiện: tiếng ồn của môi trường thay đổi đến giá trị trên 25 decibel; Tình trạng: người dùng bị khiếm thính nhẹ; Hành động: tất cả các video phải hiển thị phụ đề.
  • Sự kiện: người dùng truy cập một ứng dụng có nhiều yếu tố tương tác; Điều kiện: người dùng bị mù; Hành động: một bảng nội dung ứng dụng được tạo để dễ dàng truy cập vào từng phần tử tương tác.
  • Sự kiện: giao diện người dùng được kích hoạt; Tình trạng: người dùng mù màu; Hành động: thay đổi màu nền trước thành đen và màu nền thành trắng để cung cấp giao diện người dùng có độ tương phản cao.
  • Sự kiện: giao diện người dùng chứa một phần tử có thời gian chờ; Tình trạng: người dùng bị khuyết tật về nhận thức; Hành động: loại bỏ thời gian chờ hoặc tăng thời hạn đáng kể nếu cần.
  • Sự kiện: giao diện người dùng được kích hoạt; Tình trạng: người dùng có thị lực kém; Hành động: kích hoạt kính lúp màn hình.
  • Sự kiện: người dùng bắt đầu di chuyển; Điều kiện: người dùng bị liệt nửa người và giao diện người dùng không được hiển thị với phương thức giọng nói; Hành động: giao diện người dùng được thay đổi thành phương thức giọng nói
  • Sự kiện: ứng dụng chứa nhiều yếu tố tương tác khác nhau để thực hiện các tác vụ khác nhau cùng một lúc; Tình trạng: người dùng có vấn đề trong việc duy trì sự chú ý; Hành động: giao diện người dùng được tổ chức theo cách mà chỉ một tác vụ được hỗ trợ tại một thời điểm

Một khía cạnh quan trọng khác cần xem xét là các ứng dụng chạy trên thiết bị di động thường phải thích ứng với các sự kiện theo ngữ cảnh. Do đó, ngày càng có nhiều sự quan tâm đến việc đề xuất các môi trường cho phép ngay cả những người không phải là lập trình viên cũng có thể xác định các ứng dụng phụ thuộc vào ngữ cảnh của họ. Tasker (chú thích 1) là một ứng dụng Android cho phép người dùng thực hiện các hành động nhạy cảm với ngữ cảnh dựa trên các quy tắc kích hoạt sự kiện đơn giản. Người dùng có thể tạo các quy tắc nhạy cảm theo ngữ cảnh về nhiệm vụ (tập hợp hành động, có thể là cảnh báo hoặc ứng dụng để kích hoạt, thuộc tính âm thanh hoặc hiển thị để thay đổi, …) được thực thi theo ngữ cảnh (phụ thuộc vào các khía cạnh như ứng dụng , thời gian, ngày tháng, vị trí, sự kiện, cử chỉ, trạng thái) trong cấu hình do người dùng xác định. Mặc dù Tasker vẫn còn hạn chế về loại ứng dụng có thể được phát triển, Dù sao thì đó cũng là một bước khởi đầu và hơn thế nữa còn thể hiện sự tiện ích của loại hình đóng góp này. Ngôn ngữ (chú thích 2) là một ứng dụng Android khác cho phép người dùng tạo các tình huống xác định các điều kiện mà theo đó cài đặt điện thoại của người dùng sẽ thay đổi. Một ví dụ về quy tắc có thể được thực hiện với các công cụ như vậy là: sau 4 giờ chiều nếu mức pin dưới 20% và WiFi đang hoạt động thì hãy tắt WiFi và giảm độ sáng màn hình.

39.5 Thiết kế giao diện người dùng dựa trên mô hình trong bối cảnh đa thiết bị

Mô hình là sự trừu tượng hóa của các thực thể thực. Chúng ta sử dụng các mô hình trong cuộc sống của mình thường xuyên hơn mức thường được thừa nhận. Ví dụ, thường vào buổi sáng, chúng ta nghĩ về các hoạt động chính cần thực hiện trong ngày, từ đó tạo ra một mô hình trong ngày.

Trong các phương pháp tiếp cận dựa trên mô hình, ý tưởng cơ bản là sử dụng các ngôn ngữ mô tả các khía cạnh chính dưới dạng khái niệm để cho phép các nhà thiết kế và nhà phát triển tập trung vào các khía cạnh ngữ nghĩa chính và tránh phải học nhiều ngôn ngữ triển khai. Bằng cách này, nó cũng có thể liên kết thông tin ngữ nghĩa và các yếu tố thực hiện. Ở đây chúng tôi đang đề cập đến ngữ nghĩa tương tác, nó xác định mục đích của các phần tử giao diện người dùng. Điều này làm cho nó có thể đạt được khả năng tương tác của thiết bị thông qua nhiều ngôn ngữ triển khai khả thi bởi vì thông qua các trình tạo triển khai, có thể lấy được các triển khai được điều chỉnh khác nhau từ các mô tả logic. Một lợi thế nữa của nhiều mô tả ngữ nghĩa hơn là chúng tạo điều kiện hỗ trợ từ công nghệ hỗ trợvì mục đích của mỗi phần tử được xác định rõ ràng hơn.

Cộng đồng làm việc về các phương pháp tiếp cận dựa trên mô hình đã đồng ý trong việc xác định một số cấp độ trừu tượng có thể được xem xét khi mô tả các ứng dụng tương tác, đó là:

  • Nhiệm vụ và đối tượng miền: Ở cấp độ này, mục đích là mô tả các hoạt động cần được thực hiện để đạt được mục tiêu của người dùng và các đối tượng cần được thao tác cho mục đích này. Một ví dụ về khái niệm ở cấp độ này là “Tôi muốn chọn một tác phẩm nghệ thuật”. Các ký hiệu đã được sử dụng để đại diện cho loại mô tả này là ConcurTaskTrees (Paterno, 2000) hoặc GOMS (John và Kieras, 1996).
  • Ứng dụng tương tác trừu tượng : Ở cấp độ này, trọng tâm chuyển sang phần tương tác của ứng dụng và nhằm mục đích cung cấp mô tả của ứng dụng đó độc lập với phương thức tương tác được sử dụng. Một ví dụ về khái niệm ở cấp độ này là “Đối tượng lựa chọn đơn với số lượng lớn”. Cần có một đối tượng tương tác có thể đạt được hiệu ứng này mà không cần chỉ định bất kỳ chi tiết nào phụ thuộc vào phương thức; do đó, nó không được chỉ định liệu đối tượng nên được chọn thông qua tương tác đồ họa hoặc một lệnh thoại hoặc một cử chỉ.
  • Ứng dụng tương tác cụ thể : Mô tả phụ thuộc vào phương thức nhưng không phụ thuộc vào ngôn ngữ triển khai. Một ví dụ về khái niệm là “Đối tượng Tương tác Danh sách với các phần tử X”. Giả định rằng một phương thức đồ họa được sử dụng và một phần tử danh sách là bắt buộc. Tuy nhiên, một phần tử danh sách như vậy có thể được lấy bằng nhiều ngôn ngữ triển khai khác nhau.
  • Triển khai ứng dụng tương tác : Ở đây chúng tôi có triển khai thực tế bằng một số ngôn ngữ triển khai. Vì vậy, ví dụ, đối tượng Danh sách có thể được triển khai trong bộ công cụ dành cho giao diện người dùng Java (ví dụ: AWT) hoặc HTML hoặc các thư viện giao diện người dùng khác.

Hình 10 cho thấy một ví dụ nhỏ về giao diện người dùng đa thiết bị có được thông qua cách tiếp cận dựa trên mô hình. Ở phần trên cùng bên trái có một mô tả trừu tượng bao gồm một nhóm hai phần tử, một phần tử để đưa ra lựa chọn và một phần tử để cung cấp giá trị trong một phạm vi. Sau đó, chúng ta có thể thấy ba cách triển khai khả thi cho thiết bị di động, máy tính để bàn và thiết bị gia dụng. Sự lựa chọn được thực hiện thông qua một nút radio trên thiết bị di động, hai nút trên máy tính để bàn và một công tắc trong thiết bị vật lý; trong khi giá trị trong phạm vi nhận được thông qua một thanh trượt trong thiết bị di động, một hộp quay trong thiết bị để bàn và một đòn bẩy trong thiết bị.

Ví dụ về mô tả dựa trên mô hình của giao diện người dùng đa thiết bị

Tác giả / Người giữ bản quyền: Fabio Paterno. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 39.10 : Ví dụ về mô tả dựa trên mô hình của giao diện người dùng đa thiết bị

Hiện tại có một nhóm làm việc về giao diện người dùng dựa trên mô hình trong W3C đang phát triển các tiêu chuẩn dựa trên các khái niệm này (xem tại http://www.w3.org/2011/mbui/ ). Ngoài ra, các khái niệm như vậy đã được chứng minh là hữu ích cho khả năng tiếp cận. Thật vậy, gần đây một nhóm khác trong W3C, nhóm Giao diện Người dùng Độc lập (IndieUI), đã được thành lập ( http://www.w3.org/WAI/intro/indieui ). Nó nhằm mục đích giúp các ứng dụng web hoạt động dễ dàng hơn trong nhiều bối cảnh – các thiết bị khác nhau, công nghệ hỗ trợ khác nhau (AT), nhu cầu người dùng khác nhau . Hình 11 cho thấy một ví dụ về cách một ứng dụng có thể quản lý một sự kiện (Scroll Down) theo cách độc lập với cách nó thực sự được kích hoạt từ các công nghệ khác nhau.

Ví dụ về sự kiện trừu tượng

Tác giả / Người giữ bản quyền: Fabio Paterno. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 39.11 : Ví dụ về sự kiện trừu tượng

Một vấn đề với các phương pháp tiếp cận dựa trên mô hình là sự phát triển của các mô hình đôi khi có những yêu cầu mà các nhà thiết kế không thể giải quyết. Để giải quyết một phần vấn đề này, thiết kế ngượccác phương pháp tiếp cận và công cụ đã được phát triển. Ý tưởng cơ bản là các công cụ như vậy có thể phân tích việc triển khai giao diện người dùng và xây dựng mô hình cơ bản tương ứng. Một ví dụ được mô tả trong Bellucci et al. (2012) trong đó công cụ được trình bày có thể phân tích các trang Web, bao gồm các bảng định kiểu liên quan, và xây dựng mô tả logic tương ứng theo cách để bảo toàn các tập lệnh gốc. Một trong những ngôn ngữ dựa trên mô hình được thiết kế kỹ thuật nhất là MARIA (Paterno và cộng sự, 2009), bao gồm: hỗ trợ cho Mô hình dữ liệu hữu ích để xác định định dạng của các giá trị đầu vào, sự liên kết của các đối tượng dữ liệu khác nhau với các bộ tương tác khác nhau; Mô hình Sự kiện, liên kết mỗi người tương tác với một tập hợp các sự kiện có thể là sự kiện thay đổi thuộc tính hoặc sự kiện kích hoạt (ví dụ: truy cập vào dịch vụ web hoặc cơ sở dữ liệu); một Mô hình Đối thoại, chỉ định hành vi động (sự kiện nào có thể được kích hoạt tại một thời điểm nhất định). Các biểu thức hội thoại được kết nối bằng cách sử dụng các toán tử CTT để xác định các mối quan hệ thời gian của chúng; khả năng hỗ trợ các giao diện người dùng bao gồm các tập lệnh phức tạp và Ajax có thể liên tục cập nhật các trường bằng cách gọi các chức năng bên ngoài, có thể được triển khai như các dịch vụ Web mà không cần người dùng yêu cầu rõ ràng; và tập hợp động của các phần tử giao diện người dùng, có thể thu được thông qua các kết nối có điều kiện giữa các bản trình bày hoặc khả năng chỉ thay đổi một phần giao diện người dùng. Đáng chú ý là HTML 5 đang phát triển theo cùng một hướng bằng cách giới thiệu một số thẻ ngữ nghĩa hơn (chẳng hạn như thanh điều hướng, bài viết, v.v.) cung cấp gợi ý rõ ràng hơn về mục đích của các phần tử được liên kết. Tuy nhiên, HTML 5 chủ yếu giới hạn ở đồ họa, giao diện người dùng dựa trên biểu mẫu. Do đó, nó không thể giải quyết sự sẵn có ngày càng tăng của các phương thức tương tác khác nhau.

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng cửa in 2 days :

    Các mẫu thiết kế giao diện người dùng cho phần mềm thành công

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

MARIA cũng được hỗ trợ bởi môi trường tác giả, MARIAE (Môi trường MARIA, có sẵn công khai tại http://giove.isti.cnr.it/tools/MARIAE/home ), cung cấp hỗ trợ thao tác trực tiếp bằng đồ họa để chỉnh sửa các ứng dụng tương tác ở nhiều mức độ trừu tượng và tạo ra triển khai tương ứng cho các nền tảng khác nhau, cũng sử dụng các phương thức tương tác khác nhau. Hình 12 cho thấy cách công cụ này hỗ trợ chỉnh sửa một mô tả logic; ở bên trái là cây tương tác đại diện cho cấu trúc của ứng dụng, ở khu vực trung tâm, chúng tôi có biểu diễn đồ họa của bản trình bày đã chọn với khả năng kéo và thả các phần tử liên quan được hiển thị động ở bên phải.

Môi trường tác giả MARIAE

Tác giả / Đơn vị giữ bản quyền: Phòng thí nghiệm HIIS. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.12 : Môi trường tác giả MARIAE

39.6 Kỹ thuật cho các giai đoạn thích ứng

Trong thích ứng tự động, chúng ta có thể xác định ba giai đoạn chính: xác định thiết bị, xác định tài nguyên tương tác, thích ứng.

Nhận dạng thiết bịcó thể được thực hiện ở phía máy chủ hoặc phía máy khách. Trong trường hợp phía máy chủ, thông thường việc phát hiện tác nhân người dùng trong Giao thức HTTP được thực hiện. Nó thường chỉ ra: ([thông tin hệ thống và trình duyệt]) [nền tảng] ([chi tiết nền tảng]) [tiện ích mở rộng], ví dụ: Mozilla / 5.0 (iPad; U; CPU OS 3_2_1 như Mac OS X; en-us) AppleWebKit / 531.21.10 (KHTML, như Gecko) Di động / 7B405. Trong trường hợp phía máy khách, một số cấp độ xác định các tính năng chính của thiết bị hiện tại có thể được thực hiện thông qua đánh dấu (ví dụ: thuộc tính srcset có thể cho biết phiên bản hình ảnh sẽ sử dụng tùy thuộc vào các tính năng chính của thiết bị); hoặc bằng cách sử dụng các bảng định kiểu, được liên kết với các thiết bị khác nhau bằng cách sử dụng các truy vấn phương tiện; hoặc bằng cách sử dụng các tập lệnh nhất định (ví dụ: jQueryMobile cung cấp hỗ trợ cho mục đích này).

Nhận dạng tài nguyên tương tácđược áp dụng khi cần có thêm thông tin chi tiết về các tài nguyên tương tác hiện có. Sau đó, môi trường sẽ truy cập chúng bằng cách sử dụng Kho lưu trữ mô tả thiết bị (DDR). Một định dạng cho DDR được cung cấp bởi UAProf (Hồ sơ tác nhân người dùng), mô tả các khả năng của thiết bị cầm tay di động, bao gồm kích thước màn hình và khả năng đa phương tiện. Thiết bị cầm tay di động gửi một tiêu đề (thường là “x-wap-profile“) trong một yêu cầu http với URL tới UAProf của nó. Việc sản xuất thiết bị cho một thiết bị là tự nguyện. Nó dựa trên Đặc điểm cấu hình khả năng / sở thích tổng hợp (CC / PP) do World Wide Web Consortium tạo ra. Một định dạng khác cho DDR do WURFL cung cấp, là tệp cấu hình XML có thể được lưu trữ cục bộ và chứa thông tin về các khả năng và tính năng cho nhiều loại thiết bị di động. Thông tin này được lấy từ các nguồn khác nhau: UAProf, khi có sẵn; tài liệu công khai; báo cáo của nhà phát triển; thử nghiệm thực tế. Nó có cấu trúc phân cấp, có thể mở rộng. Nó bắt đầu như một dự án mã nguồn mởhttp://wurfl.sourceforge.net/ và hiện tại là ScientiaMobile, được thành lập bởi nhóm WURFL, cung cấp hỗ trợ thương mại cho các API này, cũng như một dịch vụ đám mây. Các công cụ thương mại khác trong lĩnh vực này là Device Atlas ( http://deviceatlas.com ) và DetectRight ( http://www.detectright.com ).

Nói chung, các thuộc tính thiết bị có thể được phân loại là tĩnh, không thể thay đổi trong quá trình thực thi ứng dụng, chẳng hạn như hệ điều hành, kích thước RAM, bộ nhớ khả dụng, kích thước hiển thị, thiết bị đầu vào, hỗ trợ đánh dấu, hỗ trợ CSS, hỗ trợ định dạng hình ảnh, hỗ trợ tập lệnh, Vân vân.; hoặc động, chẳng hạn như nghiêng thiết bị, công nghệ mạng đang sử dụng, chất lượng kết nối, mức pin, vị trí, hướng, gia tốc, ánh sáng, tiếng ồn, v.v. chiều rộng thiết bị, chiều cao thiết bị, hướng, tỷ lệ khung hình, tỷ lệ khung hình thiết bị, màu sắc , chỉ số màu, đơn sắc, độ phân giải.

Giai đoạn thứ ba là thích ứng . Có thể có nhiều cách tiếp cận khác nhau để tạo lại tự động:

  • Chia tỷ lệ: chỉ mở rộng tuyến tính theo tài nguyên tương tác của thiết bị có sẵn, chẳng hạn như Safari trên iPhone thực hiện khi tải một trang Web được phát triển cho hệ thống máy tính để bàn;
  • Transducing : giữ nguyên cấu trúc ban đầu và dịch các phần tử sang các định dạng khác, đồng thời nén và chuyển đổi hình ảnh để phù hợp với các đặc tính của thiết bị;
  • Chuyển đổi: tiến xa hơn để sửa đổi cả nội dung và cấu trúc được thiết kế ban đầu cho hệ thống máy tính để bàn để làm cho chúng phù hợp hơn để hiển thị trên màn hình nhỏ.

Vấn đề thực hiện chuyển đổi tự động từ máy tính để bàn sang phiên bản di động có thể thay đổi cấu trúc giao diện người dùng có thể được giải quyết bằng cách tính toán chi phí đầu tiên về không gian màn hình theo yêu cầu của các yếu tố khác nhau: tức là không gian dọc và ngang theo yêu cầu của văn bản , kích thước hình ảnh, giá trị giữa dòng, loại tương tác, v.v. Tiếp theo, việc tính toán không gian mà giao diện người dùng yêu cầu trong thiết bị đích cũng nên xem xét dung sai khi cuộn phải được phép, bao nhiêu không gian bổ sung nên có sẵn cho các bảng và tương tự các khía cạnh. Nếu kết quả cao hơn chi phí bền vững cho thiết bị mục tiêu thì cần xem xét sự thích ứng của các phần tử giao diện người dùng (ví dụ: sử dụng hình ảnh nhỏ hơn và thay thế các phần tử tương tác bằng các phần tử tương đương chiếm ít không gian hơn). Nếu chi phí tổng thể dẫn đến vẫn còn quá mức cho màn hình thiết bị mục tiêu thì việc chia nhỏ giao diện người dùng thành nhiều bản trình bày nên được xem xét. Để quyết định việc chia thành nhiều bản trình bày nên được thực hiện như thế nào, giao diện người dùng có thể được coi là một tập hợp các nhóm phần tử, không thể phân chia nội bộ. Do đó, quyết định là làm thế nào để phân phối các nhóm như vậy để có được các bài thuyết trình bền vững bởi thiết bị đích. Việc phân tách có thể được thực hiện hoặc tạo các bản trình bày di động riêng biệt hoặc bằng cách hiển thị động các phần tử có liên quan. Quá trình thích ứng này có thể được tùy chỉnh theo các thông số và quy tắc nhất định, chẳng hạn như mức độ cuộn nên được phép trong thiết bị đích hoặc tuân theo chính sách nào trong việc phân phối các nhóm phần tử trong thiết bị đích. Trong quá trình điều chỉnh này, đôi khi các bảng là yếu tố quan trọng vì khi chúng được hiển thị trên thiết bị màn hình nhỏ, chúng quá lớn. Một số kỹ thuật đã được đề xuất để xử lý các vấn đề như vậy, ví dụ Tajima và Ohnishi (2008) giới thiệu các tập lệnh động cho phép thu gọn một số cột và / hoặc hàng một cách tương tác để cho phép người dùng liên kết tốt hơn các phần tử quan tâm trong bảng.

Một kỹ thuật thích ứng thú vị khác là tóm tắt trang, mục đích của nó là tự động giảm nội dung để phù hợp hơn với màn hình nhỏ. Có hai cách tiếp cận vấn đề này. Phương pháp dựa trên trừu tượng sử dụng các kỹ thuật thao tác câu như giảm, nén và định dạng lại. Phương pháp dựa trên trích xuất ấn định điểm số cho các câu để chọn những câu đại diện tốt hơn cho toàn bộ văn bản; nó có thể dựa trên đặc điểm (ví dụ: tần suất thuật ngữ, vị trí câu, thuộc tính, v.v.) hoặc sử dụng máy học hoặc các kỹ thuật dựa trên đồ thị.

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng cửa in 2 days :

    Các mẫu thiết kế giao diện người dùng cho phần mềm thành công

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

Một ví dụ về tóm tắt được hỗ trợ bởi PowerBrowser (Buyukkokten và cộng sự, 2002). Ý tưởng cơ bản là tầm quan trọng của một từ khóa phụ thuộc vào tần suất mà nó xuất hiện trong một văn bản và trong một bộ sưu tập lớn hơn. Một từ trong một văn bản nhất định được coi là quan trọng nhất nếu nó xuất hiện thường xuyên trong văn bản, nhưng không thường xuyên trong bộ sưu tập lớn hơn. Yếu tố ý nghĩa của một câu được rút ra từ việc phân tích các từ cấu thành của nó. Những câu trong đó số lượng các từ khác biệt thường xuyên xuất hiện nhiều nhất được tìm thấy trong khoảng cách gần nhất có lẽ là quan trọng. Những người quan tâm đến các kỹ thuật như vậy có thể sử dụng MEAD, một hệ thống tóm tắt đa tài liệu công khai, cung cấp hỗ trợ linh hoạt hơn trong lĩnh vực này (xem http://www.summarization.com/mead/ ).

Kỹ thuật tìm nguồn cung ứng cộng đồng dựa trên ý tưởng phân bổ một số nhiệm vụ để thực hiện thông qua một cuộc gọi mở. Những kỹ thuật này ngày càng có tầm quan trọng và có thể được áp dụng để thích ứng. Ví dụ, Nebeling và Norrie đã áp dụng chúng để điều chỉnh các trang Web. Mục đích là để hỗ trợ các nhà phát triển trong việc chỉ định các giao diện Web có thể thích ứng với phạm vi và sự đa dạng gia tăng của các thiết bị. Vì mục đích này, họ đã giới thiệu một công cụ tăng cường các trang Web để cho phép người dùng tùy chỉnh bố cục của các trang Web cho các thiết bị cụ thể. Các thiết bị được phân loại theo kích thước cửa sổ, độ phân giải màn hình và hướng. Sau đó, có thể chia sẻ các bản điều chỉnh để những người khác có cùng thiết bị và có sở thích tương tự có thể trực tiếp hưởng lợi. Cùng một nhóm (Nebeling và cộng sự, 2013) đã phát triển một công cụ, W3Touch, có mục đích là hỗ trợ sự thích ứng đối với cảm ứng theo số liệu. Công cụ này tạo ra các phân tích về tương tác của người dùng để giúp các nhà thiết kế phát hiện và xác định các vấn đề thiết kế tiềm ẩn cho các thiết bị cảm ứng di động. Vì mục đích này, hai số liệu được xem xét: Tỷ lệ liên kết bị bỏ lỡ, theo dõi tần suất chạm vào bỏ lỡ mục tiêu dự định; và Mức thu phóng, xem xét mức độ trung bình của người dùng cần thu phóng vào các thành phần khác nhau của giao diện Web.

Một khía cạnh quan trọng khác cần xem xét là cách đánh giá sự thích ứng. Vì mục đích này trong Manca et al. (2013) một bộ tiêu chí liên quan được chỉ ra:

  • Nhận thức của người dùng về sự thích ứng : người dùng có thể nhận ra rằng sự thay đổi trong giao diện người dùng là do sự thích ứng gây ra ở mức độ nào;
  • Tính phù hợp của sự thích ứng : hệ thống có lựa chọn một chiến lược thích ứng tốt / phù hợp hay không;
  • Quá trình thích ứng cho phép người sử dụng nhận thức được những gì đang xảy ra trong quá trình thích ứng ở mức độ nào;
  • Tính liên tục của thích ứng : dễ dàng tiếp tục tương tác sau khi thích ứng ở mức độ nào;
  • Tác động của sự thích ứng trong việc giảm độ phức tạp tương tác : liệu độ phức tạp tương tác của hệ thống có giảm không;
  • Tác động của thích ứng trong việc tăng mức độ thỏa mãn của người dùng : sự thích ứng làm tăng mức độ thỏa mãn của người dùng ở mức độ nào.

39.7 Giao diện giọng hát

Giao diện giọng nói có thể đóng một vai trò quan trọng trong các bối cảnh khác nhau: với người dùng bị khiếm thị; khi người dùng đang di chuyển; nói chung hơn khi kênh hình ảnh bận. Ví dụ về các ứng dụng có thể là dịch vụ đặt chỗ, thông tin hãng hàng không, thông tin thời tiết, danh sách điện thoại, tin tức. Tuy nhiên, các ứng dụng tương tác giọng nói có các tính năng cụ thể làm cho chúng khác với giao diện người dùng đồ họa . Chúng tuyến tính và không liên tục, trong khi các giao diện đồ họa hỗ trợ các tương tác đồng thời và liên tục. Ưu điểm của giao diện giọng nói là chúng có thể nhanh chóng và tự nhiên đối với một số hoạt động.

Gần đây, ngày càng có nhiều sự quan tâm đến các giao diện giọng nói vì công nghệ thanh âm ngày càng được cải thiện. Nó đang trở nên mạnh mẽ hơn và ngay lập tức mà không cần đào tạo lâu và do đó nhiều ứng dụng khác nhau của nó đã được đề xuất trên thị trường đại chúng, ví dụ như tìm kiếm bằng giọng nói và điều hướng bản đồ của Google hoặc Siri trên iPhone. Điều này đã được thực hiện bằng cách cung cấp khả năng nhập đầu vào bằng giọng nói với âm thanh được lưu trữ cục bộ và sau đó được gửi đến máy chủ để nhận dạng giọng nói. Điều hướng dựa trên menu giọng nói phải được thiết kế cẩn thận: cần có phản hồi liên tục để kiểm tra trạng thái ứng dụng, nó phải cung cấp lời nhắc ngắn và danh sách tùy chọnđể giảm nỗ lực bộ nhớ và nên hỗ trợ quản lý các sự kiện cụ thể (không có đầu vào, không khớp, trợ giúp). Mặc dù cấu trúc logic của một trang đồ họa là một cái cây, nhưng chiều sâu và chiều rộng của nó quá lớn để duyệt qua giọng nói. Hình 13 cho thấy một ví dụ về giao diện người dùng đồ họa và thể hiện cấu trúc logic của nó bằng cách sử dụng các đa giác có đường viền liền khối để biểu thị các khu vực chính và sau đó là các đường viền đứt nét để biểu thị các khu vực phụ bên trong chúng.

Cấu trúc logic của giao diện người dùng đồ họa

Tác giả / Chủ bản quyền: W3C. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.13 : Cấu trúc logic của giao diện người dùng đồ họa

Hình 14 cho thấy ở bên trái một menu giọng nói tương ứng được tự động dẫn xuất theo một thuật toán (Paterno và Sisti, 2011) trong đó văn bản của các mục menu giọng nói được lấy từ id phần tử hoặc từ nội dung phần. Ở bên phải của Hình 14 có một ví dụ về lời thoại có thể thu được từ giao diện giọng nói như vậy.

Phiên bản giọng hát của giao diện người dùng mẫu

Tác giả / Người giữ bản quyền: Paterno và Sisti. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 39.14 : Phiên bản giọng nói của giao diện người dùng mẫu

39.8 Giao diện người dùng đa phương thức

Đa phương thức liên quan đến việc xác định sự kết hợp hiệu quả nhất của các phương thức tương tác khác nhau. Từ vựng đơn giản cho mục đích này đã được cung cấp bởi các thuộc tính CARE (Coutaz và cộng sự, 1995): tính bổ sung , phần được coi là của giao diện được hỗ trợ một phần bởi một phương thức và một phần bởi một phương thức khác; chuyển nhượng , phần được xem xét của giao diện được hỗ trợ bởi một phương thức được chỉ định; dự phòng , phần được coi là của giao diện được hỗ trợ bởi cả hai phương thức; tương đương, phần được coi là của giao diện được hỗ trợ bởi phương thức này hay phương thức khác. Trong Manca và cộng sự. (2013) các tác giả mô tả cách khai thác chúng chi tiết hơn để thiết kế và phát triển giao diện người dùng đa phương thức: chúng có thể được áp dụng cho các toán tử thành phần, tương tác và các phần tử chỉ xuất. Trong trường hợp các yếu tố tương tác, có thể phân tách chúng thành ba phần: lời nhắc, đầu vào và phản hồi, có thể được liên kết với các thuộc tính CARE khác nhau. Trong cách tiếp cận này, sự tương đương chỉ có thể được áp dụng cho các phần tử đầu vào vì chỉ với chúng, người dùng mới có thể chọn phần tử nào để nhập, trong khi tính dự phòng có thể được áp dụng cho lời nhắc và phản hồi nhưng không cho đầu vào vì một khi đầu vào được nhập thông qua một phương thức thì nó không có ý nghĩa để nhập nó cũng thông qua một phương thức khác.

Hình 15 cho thấy một kiến ​​trúc chung để hỗ trợ các giao diện người dùng đa phương thức thích ứng. Có một trình quản lý ngữ cảnh có thể phát hiện các sự kiện liên quan đến người dùng, công nghệ, môi trường và các khía cạnh xã hội. Sau đó, công cụ thích ứng nhận được các mô tả về giao diện người dùng và các quy tắc thích ứng có thể có. Các mô tả của giao diện người dùng có thể được lấy thông qua môi trường tác giả tại thời điểm thiết kế hoặc được tạo tự động thông qua các công cụ thiết kế ngược tại thời điểm chạy. Khi các sự kiện liên quan đến bất kỳ quy tắc thích ứng nào xảy ra, thì phần hành động tương ứng sẽ được thực thi. Vì mục đích này, có thể có ba lựa chọn:

  • thay đổi hoàn toàn phương thức tương tác: bộ điều hợp tương ứng phải được gọi để thực hiện sự thích ứng hoàn toàn tương ứng với phương thức mới, và sau đó giao diện người dùng mới được tạo;
  • một số thay đổi trong cấu trúc giao diện người dùng hiện tại nên được thực hiện; sau đó mô tả logic của nó nên được sửa đổi và tạo ra triển khai mới;
  • nên thực hiện các thay đổi nhỏ trong giao diện người dùng hiện tại, ví dụ như thay đổi một số thuộc tính trong một số phần tử; sau đó các thay đổi có thể được thực hiện trực tiếp trong quá trình thực hiện thông qua các kịch bản chuyển thể.

Một kiến ​​trúc chung để thích ứng đa phương thức

Tác giả / Đơn vị giữ bản quyền: Phòng thí nghiệm HIIS. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Được sử dụng mà không được phép theo Học thuyết sử dụng hợp pháp (vì không thể xin phép). Xem phần “Ngoại lệ” (và tiểu mục “allRightsReserved-usedWithoutPermission”) trên thông báo bản quyền của trang .

Hình 39.15 : Kiến trúc chung cho thích ứng đa phương thức

Bây giờ có thể tải các ứng dụng đa phương thức cũng trong Web. Khả năng đầu tiên được cung cấp bởi X + V, một ngôn ngữ tích hợp HTML và VoiceXML. Tuy nhiên, ngôn ngữ như vậy không còn được hỗ trợ bởi các trình duyệt hiện tại.

Trong Manca và cộng sự. (2013) một giải pháp mới được đề xuất, thu được bằng cách mở rộng HTML và CSS để truy cập hỗ trợ của Google cho phần giọng nói (thông qua các chú thích CSS được diễn giải bởi các Javascrip cụ thể). Các ứng dụng dành cho máy tính để bàn có thể khai thác các tiện ích mở rộng của Chrome thông qua Javascrip để truy cập ASR và TTS API của Google theo các chú thích CSS như vậy. Việc triển khai này vẫn không thể thực hiện được đối với phiên bản Chrome dành cho thiết bị di động. Do đó, các ứng dụng di động cần tạo các phiên bản của các thành phần Chế độ xem Web có thể tải các trang Web và truy cập các API ASR và TTS thông qua Java. Trong các thử nghiệm thực nghiệm đầu tiên liên quan đến giải pháp này để thích ứng đa phương thức phụ thuộc vào ngữ cảnh, kết quả rất đáng khích lệ. Phản hồi của người dùng chỉ ra rằng người dùng muốn có quyền kiểm soát việc phân phối theo phương thức để hỗ trợ sở thích cá nhân. Nó cũng chỉ ra rằng việc lựa chọn các phương thức phải tính đến các nhiệm vụ hỗ trợ, ngoài bối cảnh sử dụng hiện tại, ví dụ như hiển thị kết quả truy vấn dài là thứ vốn dĩ được ưu tiên trình bày dưới dạng đồ họa vì phương thức giọng nói không liên tục và khi cuối cùng kết quả được trình bày theo cách xưng hô mà người dùng có thể đã quên những kết quả ban đầu. Một khía cạnh khác là trộn các phương thức ở mức độ chi tiết của các phần của các phần tử giao diện người dùng đơn lẻ không phải lúc nào cũng được coi là phù hợp; ví dụ, khi xem xét một trường văn bản duy nhất phải được chọn bằng đồ thị, nó không được coi là có ý nghĩa khi đó yêu cầu nhập giá trị theo cách xưng hô. ví dụ: hiển thị kết quả truy vấn dài là thứ vốn dĩ được ưu tiên trình bày dưới dạng đồ họa vì phương thức giọng nói không liên tục và khi kết quả cuối cùng được trình bày bằng giọng nói, người dùng có thể đã quên những kết quả ban đầu. Một khía cạnh khác là trộn các phương thức ở mức độ chi tiết của các phần của các phần tử giao diện người dùng đơn lẻ không phải lúc nào cũng được coi là phù hợp; ví dụ, khi xem xét một trường văn bản duy nhất phải được chọn bằng đồ thị, nó không được coi là có ý nghĩa khi đó yêu cầu nhập giá trị theo cách xưng hô. ví dụ: hiển thị kết quả truy vấn dài là thứ vốn dĩ được ưu tiên trình bày dưới dạng đồ họa vì phương thức giọng nói không liên tục và khi kết quả cuối cùng được trình bày bằng giọng nói, người dùng có thể đã quên những kết quả ban đầu. Một khía cạnh khác là trộn các phương thức ở mức độ chi tiết của các phần của các phần tử giao diện người dùng đơn lẻ không phải lúc nào cũng được coi là phù hợp; ví dụ, khi xem xét một trường văn bản duy nhất phải được chọn bằng đồ thị, nó không được coi là có ý nghĩa khi đó yêu cầu nhập giá trị theo cách xưng hô.

39.9 Giao diện người dùng phân tán

Khi xem xét quyền truy cập của người dùng trong môi trường đa thiết bị, chúng tôi có thể xác định các khả năng khác nhau:

  • Truy cập các ứng dụng thông qua các thiết bị khác nhau tại các thời điểm khác nhau (một thiết bị tại mỗi thời điểm);
  • Giao diện người dùng phân tán: logic ứng dụng nhận đầu vào từ nhiều thiết bị;
  • Di chuyển các đối tượng trên các thiết bị tương tác (ví dụ: thông qua chọn và thả (Rekimoto, 87));
  • Giao diện người dùng di chuyển: thay đổi thiết bị, di chuyển giao diện với trạng thái bảo toàn.

Giao diện người dùng phân tán và giao diện người dùng di chuyển là hai khái niệm độc lập, thực sự có thể tồn tại giao diện người dùng phân tán cũng có thể di chuyển, nhưng cũng chỉ có giao diện người dùng phân tán (hoàn toàn không di chuyển) hoặc giao diện người dùng di chuyển không được phân phối trên nhiều thiết bị .

Hỗ trợ nhiều thiết bị đang xuất hiện trong nhiều môi trường khác nhau. OS X Lion Resume (chú thích 3) cung cấp
tính năng ‘Tiếp tục’, cho phép người dùng tiếp tục nơi họ đã dừng ứng dụng, cùng với giao diện người dùng của họ. Chrome-to-phone (chú thích 4) cho phép người dùng gửi liên kết từ trình duyệt Chrome trên máy tính để bàn tới Ứng dụng trên thiết bị Android của họ. Chrome-to-mobile (chú thích 5) gửi các trang từ trình duyệt Chrome trên máy tính của bạn đến trình duyệt Chrome chạy trên thiết bị di động của bạn. Firefox (chú thích 6)
đồng bộ hóa dấu trang, tab và lịch sử web giữa các ứng dụng Firefox dành cho máy tính để bàn và thiết bị di động.

Ở cấp độ nghiên cứu, Myngle (Sohn và cộng sự, 2011) cung cấp lịch sử Web thống nhất từ ​​nhiều thiết bị cá nhân và cho phép người dùng lọc lịch sử của họ dựa trên các danh mục cấp cao.

Khi xem xét các giao diện người dùng được phân phối cụ thể, điều quan trọng cần lưu ý là có ba loại thông tin quan trọng cần xác định (Frosini và cộng sự, 2013): phần giao diện nào phải được phân phối; có cho phép đầu vào trên các bộ phận như vậy không; (các) thiết bị mục tiêu , sẽ nhận được các bộ phận được phân phối (chúng có thể được xác định bằng loại thiết bị, ID, vai trò được liên kết với thiết bị).

Nói chung, phân phối có thể được xác định theo những cách khác nhau:

  • Trong phần mô tả của ứng dụng tương tác với đặc điểm kỹ thuật của ứng dụng ban đầu (thời gian thiết kế);
  • Phân phối được xác định thông qua trình xử lý của các sự kiện phân phối được chỉ ra trong đặc tả ứng dụng tương tác (định nghĩa thời gian thiết kế + thời gian chạy thực thi);
  • Phân phối có được thông qua các công cụ tùy chỉnh động (hoàn toàn trong thời gian chạy), cho phép người dùng có được các bản phân phối không được lên kế hoạch tại thời điểm thiết kế.

Một ví dụ về phân phối thu được thông qua các công cụ tùy chỉnh động được trình bày trong Manca và Paterno (2013). Nó sử dụng các thuộc tính CARE để chỉ định phân phối trong mô tả dựa trên MARIA. Khi ứng dụng được tạo, người dùng cuối vẫn có thể tùy chỉnh phân phối của nó trên các thiết bị khác nhau thông qua một công cụ tương tác để giải quyết các nhu cầu không lường trước được tại thời điểm thiết kế. Hình 16 cho thấy một ví dụ: lúc đầu giao diện người dùng được gán hoàn toàn cho một thiết bị di động; sau đó thông qua công cụ tùy chỉnh tương tác, một số yếu tố được gán cho màn hình lớn và những yếu tố khác là dư thừa trên hai thiết bị.

Ví dụ về phân phối giao diện người dùng động

Tác giả / Người giữ bản quyền: Manca và Paterno. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 39.16 : Ví dụ về phân phối giao diện người dùng động

39.10 Ứng dụng Tương tác Di cư

Một trong những nguyên nhân chính gây ra sự thất vọng trong các môi trường phổ biến hiện nay là người dùng cần khởi động lại ứng dụng của họ cho mỗi lần thay đổi thiết bị. Để khai thác ưu đãi công nghệ hiện tại, cần có quyền truy cập liên tục vào các dịch vụ tương tác trên nhiều thiết bị khác nhau. Giao diện người dùng di cư có thể chuyển giữa các thiết bị khác nhau (từ thiết bị ‘nguồn’ sang thiết bị ‘đích’), để cho phép người dùng tiếp tục tác vụ của họ. Nhiều cách tiếp cận khác nhau để triển khai chúng đã được nghiên cứu (sao chép pixel, ứng dụng tương tác, máy ảo, v.v.). Một số miền ứng dụng có thể được hưởng lợi từ chúng như mua sắm, đấu giá trực tuyến, trò chơi, đặt chỗ. Chúng được đặc trưng bởi khả năng duy trì trạng thái của phần tương tác (có thể bao gồm đầu vào của người dùng, phần tử tiêu điểm, cookie, phiên,

Một ví dụ về giải pháp hỗ trợ giao diện người dùng di chuyển là DeepShot (Chang và Li, 2011). Nó xác định ứng dụng mà người dùng đang xem qua camera, khôi phục trạng thái của nó và chuyển nó vào điện thoại di động, với thông tin về trạng thái được mã hóa dưới dạng URI. Một video có sẵn tại

Các giải pháp khác nhau để di chuyển các ứng dụng tương tác đã được nghiên cứu trong dự án EU OPEN (http://saturno.isti.cnr.it:88/), đã được áp dụng trong các ứng dụng khác nhau (trò chơi, trường hợp khẩn cấp, mạng xã hội). Mô tả chi tiết của chúng được đưa ra trong một cuốn sách về Ứng dụng tương tác di cư trong môi trường phổ biến
http://www.springer.com/computer/information+systems+and+application/book/978-0-85729-249-0). Một trong những giải pháp như vậy đã tập trung vào một môi trường hỗ trợ việc di chuyển các trang Web. Điều này có được thông qua một máy chủ proxy có thể đưa các tập lệnh giới thiệu khả năng gửi DOM của trang và trạng thái hiện tại của nó khi quá trình di chuyển được kích hoạt thông qua một ứng dụng di chuyển, là một ứng dụng Web riêng biệt có thể giao tiếp với máy chủ di chuyển và các ứng dụng.

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng cửa in 2 days :

    Các mẫu thiết kế giao diện người dùng cho phần mềm thành công

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

Có một số khía cạnh cụ thể đặc trưng cho khả năng sử dụng trong những môi trường như vậy. Chúng liên quan đến tính liên tục, chẳng hạn như thời gian cần thiết của quá trình di chuyển từ trình kích hoạt trên thiết bị nguồn sang bản trình bày giao diện người dùng trên thiết bị đích. Quá trình chuyển đổi phải được người dùng hiểu được, theo nghĩa là người dùng có thể hiểu rằng quá trình chuyển đổi đang diễn ra. Kết quả điều chỉnh sẽ không gây khó khăn cho người dùng khi hiểu cách tiến hành. Một khía cạnh quan trọng khác là khả năng dự đoán: người dùng có thể dự đoán thiết bị mục tiêu, phần giao diện người dùng nào sẽ di chuyển và nơi kết quả tương tác của người dùng sẽ xuất hiện sau khi di chuyển.

Để làm cho môi trường di chuyển linh hoạt hơn, chúng tôi có thể giới thiệu khả năng di chuyển từng phần trong đó người dùng tương tác chọn các phần mà họ muốn di chuyển sang thiết bị mục tiêu. Điều này có thể hữu ích, chẳng hạn, trong di chuyển từ máy tính để bàn sang thiết bị di động nếu người dùng muốn giới hạn các phần di chuyển để tránh làm quá tải màn hình giới hạn của thiết bị mục tiêu. Một vấn đề với việc di chuyển các ứng dụng Web là trạng thái của JavaScripts. Thật vậy, nếu trạng thái được liên kết với các biến JavaScript không được lưu và khôi phục đúng cách, có thể xảy ra mâu thuẫn: một số biến không còn tồn tại trong phiên bản mới được tải lên hoặc một số biến có thể giữ giá trị không chính xác.

Trong mọi trường hợp, giao diện di chuyển cũng có thể cung cấp hỗ trợ hữu ích trong môi trường nhiều người dùng. Trong Ghiani và cộng sự. (2012) một kịch bản thú vị được thảo luận trong đó các đồng nghiệp lên kế hoạch cho một chuyến công tác khai thác nó để đẩy hoặc kéo các trang web chứa thông tin và dữ liệu hữu ích cho chuyến đi của họ. Video minh họa tình huống này hiện có tại http://www.youtube.com/watch?feature=player_embedded&v=0cOlm28n_YE . Loại môi trường này có thể làm nảy sinh một số vấn đề về quyền riêng tư cần được giải quyết bằng cách cung cấp cho người dùng quyền kiểm soát xem mỗi thiết bị có hiển thị với người khác hay không, liệu các trang được điều hướng trên một thiết bị có thể bị người khác phát hiện hay không và liệu một thiết bị có thể là một mục tiêu của một cuộc di cư. Những khả năng như vậy chỉ có thể được chỉ định cho những người dùng hoặc nhóm người dùng cụ thể.

Các vấn đề khác có thể phát sinh về mặt bảo mật, bao gồm việc đánh cắp thông tin cá nhân từ giao diện người dùng đã di chuyển, chẳng hạn như dữ liệu do người dùng nhập (thẻ tín dụng, mật khẩu, v.v.) hoặc dữ liệu có trong trang (hồ sơ ngân hàng, v.v.) hoặc thông tin được lưu trữ trong các biểu mẫu, phiên, cookie. Các rủi ro khác có thể do mạo danh người dùng thông qua tấn công xác thực. Một số vấn đề như vậy có thể được giải quyết bằng cách tự động phân tích các phần tử trong các biểu mẫu tương tác để xác định liệu chúng có thể chứa dữ liệu bí mật hay không và trong trường hợp này, để xử lý nội dung của chúng trong quá trình di chuyển bằng cách sử dụng các giao thức an toàn, ngay cả khi chúng không được sử dụng trong ứng dụng gốc.

39.11 Kết luận

Tóm lại, chúng ta có thể nói rằng nhiều giải pháp đã được phát triển để khai thác tốt hơn môi trường đa thiết bị. Có thể hữu ích nếu có một tập hợp các kích thước hợp lý cho phép các nhà thiết kế và nhà phát triển so sánh chúng. Tập hợp các thứ nguyên như vậy cùng với một số giá trị có thể hữu ích để phân biệt chúng được cung cấp bởi Paterno và Santoro (2012) và là:

  • Phân phối : cho dù nó là tĩnh hay động;
  • Di chuyển : theo các thành phần trạng thái mà nó có thể bảo tồn: trạng thái biểu mẫu, trạng thái chức năng, phiên, lịch sử, dấu trang, v.v.;
  • Mức độ chi tiết : liệu giải pháp có thể liên quan đến toàn bộ giao diện người dùng, các nhóm, phần tử giao diện người dùng đơn lẻ, các phần của phần tử giao diện người dùng hay không;
  • Kích hoạt Loại kích hoạt : có thể theo yêu cầu hoặc tự động hoặc hỗn hợp;
  • Phương thức tương tác : cho dù giải pháp là đơn phương, xuyên phương thức hay đa phương thức;
  • Loại giao diện người dùng được kích hoạt : cho dù chúng được tính toán trước hoặc được tạo trong thời gian chạy hay một dung dịch hỗn hợp;
  • Chia sẻ thiết bị giữa nhiều người dùng : việc chia sẻ bao gồm khả năng di chuyển các phần tử trong cùng một thiết bị hoặc liệu người dùng có thể tương tác với cùng một thiết bị hay không;
  • Thời gian : cho dù các thay đổi giao diện người dùng là ngay lập tức, trì hoãn hay hỗn hợp;
  • Phương pháp tiếp cận Thích ứng : cho dù đó là phương pháp tiếp cận mở rộng, chuyển đổi hoặc chuyển đổi;
  • Kiến trúc : cho dù giải pháp kiến ​​trúc là dựa trên máy chủ hay ngang hàng.

Tất nhiên, chúng ta vẫn còn lâu mới giải quyết được tất cả các vấn đề thú vị đặc trưng cho môi trường đa thiết bị. Có nhiều khía cạnh khác nhau đáng được nghiên cứu thêm, chẳng hạn như hỗ trợ tích hợp để thích ứng với nhiều kỹ thuật tương tác Post-WIMP hoặc các giải pháp chung hơn để duy trì trạng thái chức năng trong quá trình di chuyển. Cho đến nay, cả việc di chuyển từ nhiều thiết bị sang nhiều thiết bị và thích ứng dựa trên nguồn cộng đồng đều nhận được sự quan tâm hạn chế. Môi trường EUD cho các ứng dụng phụ thuộc vào ngữ cảnh cần các phép ẩn dụ và giải pháp hiệu quả hơn và vẫn còn thiếu các giải pháp chung để khai thác giao tiếp ngang hàng trong giao diện người dùng phân tán và di chuyển.

Start typing and press Enter to search

Shopping Cart