it-swarm-vi.tech

Xác nhận và công bố lũy tiến

Tôi đang cố gắng tìm một ví dụ về xác nhận lũy tiến. Chúng tôi có giao diện người dùng cho trình chỉnh sửa trực quan nơi người dùng thực hiện những việc như chỉ ra kích thước bằng pixel hoặc phần trăm.

Các thuộc tính của trình soạn thảo nằm trong các bộ tab để không phải tất cả các trường đều hiển thị cùng một lúc. Chúng tôi đã thảo luận về cách thức và nếu chúng tôi xác nhận trong giao diện người dùng này.

Tôi xuất phát từ quan điểm rằng: a) Xác thực là hữu ích vì nó sẽ tạo ra một kênh liên lạc nơi người dùng có thể tìm hiểu những kỳ vọng của phần mềm và "cải thiện" những gì được yêu cầu. b) Luôn luôn tốt hơn để chỉ ra lỗi xác thực trực tiếp trên các trường đầu vào (có hay không sử dụng tóm tắt ở nơi khác) để người dùng có một dấu hiệu trực quan cho những gì cần thay đổi.

Đồng nghiệp của tôi, người mà tôi không có gì ngoài sự tôn trọng tối đa không đồng ý. Logic của anh ấy như sau: a) Sẽ tốt hơn nếu ngăn chặn một số loại mục nhập nhất định hoặc, trong trường hợp một số mục nhập để thay đổi nó thành một giá trị phù hợp hơn nếu nó không hợp lệ. Ví dụ: nếu ai đó sử dụng giá trị phần trăm lớn hơn 100, UI sẽ đặt lại giá trị thành 100 trong trường hợp mất tiêu điểm. b) Vì chúng tôi đang ở trong môi trường tab, một số lỗi sẽ không hiển thị cho người dùng. Sử dụng một bản tóm tắt là vô ích vì có khả năng có thể có "rất nhiều" lỗi xác nhận.

Tôi nghĩ rằng một giải pháp xung quanh điều này có thể là một tiết lộ lũy tiến của các giá trị không hợp lệ. Khi người dùng nhập các giá trị có thể không chính xác, chúng được gắn cờ trong một số loại tóm tắt. Tóm tắt cho phép người dùng điều hướng đến các trường trong câu hỏi mà không hiển thị chúng.

Tôi ước tôi là một người nguyên bản nhưng tôi chắc chắn có những tiền lệ ở đây. Câu hỏi của tôi như sau:

  1. Bất cứ điều gì để thêm vào quan điểm của tôi hoặc đồng nghiệp của tôi?

  2. Bất kỳ ví dụ nào về giao diện người dùng như thế này với mục nhập phức tạp không xác thực lũy tiến?

11
David in Dakota

Chúng tôi hiện đang vật lộn với cùng một vấn đề cho một ứng dụng máy tính để bàn, mặc dù không dựa trên tab. Bạn có thể thử một cách tiếp cận như thế này:

alt text

trong đó một biểu tượng nhỏ xuất hiện nếu có gì đó đòi hỏi sự chú ý của người dùng. Thậm chí có thể sử dụng hai màu: vàng để cảnh báo và đỏ cho những thứ phải được sửa trước khi người dùng có thể đi xa hơn.

7
Hisham

Điều tốt nhất bạn có thể làm trong tình huống phức tạp này là tạo một nguyên mẫu với số lượng UI nhiều nhất có thể và kiểm tra nó trên cơ sở người dùng của bạn để xem điều gì xảy ra. Bạn có thể sử dụng HTML kết hợp với một cái gì đó như jQuery UI để nhanh chóng có được nhiều điều khiển tương tác có sẵn và sẵn sàng để thử nghiệm nhanh chóng.

Hệ thống tab của bạn nghe có vẻ phức tạp nên tôi phải đề xuất một vài điều để đơn giản hóa:

  • Tạo các nút "áp dụng" trong mỗi tab để chỉ có thể lưu trạng thái cho các thuộc tính mà người dùng có thể thấy ngay bây giờ. Nếu điều đó dẫn đến trạng thái ứng dụng không hợp lệ, hãy thiết kế lại các tab của bạn để người dùng có các thuộc tính được nhóm lại với nhau mà can được lưu độc lập với nhau.
  • Nếu bạn không thể làm điều đó, bạn có thể đánh dấu các tab bằng biểu tượng "không hợp lệ" và màu để biểu thị các thuộc tính trong tab đó cần chú ý. Mặc dù bất kỳ tab nào không hợp lệ, nút "áp dụng" sẽ bị tắt. Bạn có thể xem xét thêm thông báo vào nút nếu nó được nhấp để hiển thị thông báo cho biết vẫn còn lỗi. Tóm tắt cho những gì sai sẽ được hiển thị trong mỗi tab thay vì có một bản tóm tắt bao quát.
  • Một bản tóm tắt toàn cầu có thể hoạt động, nhưng tôi ngần ngại đề xuất nó vì dường như sẽ không có một vị trí rõ ràng ngay lập tức để đặt nó, và trừ khi đó là trường hợp, người dùng sẽ chú ý?
  • Các thuộc tính được nhóm như thế nào? Có khả năng chức năng? Hãy thử nhìn chúng từ một góc độ khác, ví dụ như khả năng sử dụng. Đây là một phần trong cách Microsoft tiếp cận thiết kế Ribbon cho các sản phẩm Office 2007 của mình. Pehaps bạn có thể thiết kế các tab của mình theo cách mà hầu hết người dùng chỉ cần lộn xộn với các thuộc tính trong tab đầu tiên hoặc hiển thị ngay lập tức và các tab khác có thể được coi là "nâng cao" hoặc theo ngữ cảnh.

Cuối cùng, và tôi đã nói điều này, kiểm tra thiết kế của bạn! :-)

Theo như xử lý lỗi, kinh nghiệm của tôi là nếu bạn ngăn chặn một số đầu vào nhất định, người dùng sẽ bị nhầm lẫn. Chẳng hạn, nếu không rõ ràng từ trường đầu vào chỉ cho phép số, nhưng dù sao bạn cũng không cho phép bất kỳ ký tự nào khác, điều đó sẽ gây khó chịu cho người dùng - họ sẽ không trải nghiệm nó như một hình thức thông minh đang cố gắng giúp đỡ họ . Vì vậy, tôi khuyên bạn nên sử dụng kính hiển vi rõ ràng trong suốt nếu bạn quyết định đi xuống con đường sử dụng các sự kiện và phát hiện đầu vào để tự động sửa lỗi.

Nhưng tất cả điều này là giai thoại - tôi chưa thực hiện bất kỳ nghiên cứu nào trong lĩnh vực này. Thay vì lấy Lời của tôi cho nó, hãy tham khảo cuốn sách của Luke Classicalblewski, Thiết kế mẫu web: Điền vào chỗ trống , và nghiên cứu của anh ấy về xử lý lỗi để biết một số hiểu biết hữu ích về cách xử lý các tình huống như thế này (cho ví dụ, điều này bài đăng trên thiết kế lại biểu mẫu thanh toán của Apple thảo luận về cách họ xử lý lỗi một cách chi tiết).

4
Rahul

Gần đây tôi đã làm việc trên một dự án gặp phải một vấn đề tương tự. Bạn có thể thấy một ảnh chụp màn hình về cách chúng tôi giải quyết nó trong bài viết " Tối thiểu hóa độ phức tạp " của tôi từ năm ngoái.

1
Tyler Tate

Tôi đã nghĩ về một trường hợp trong đó một bản tóm tắt cho nhiều lỗi được sử dụng và loại công việc, có lẽ.

Trong bất kỳ IDE như nói Visual Studio có khả năng xảy ra vô số lỗi khi xây dựng hoặc sử dụng bất kỳ công cụ phân tích tĩnh nào trong khi viết mã. Nói chung, có hàng tá hoặc hàng trăm tệp và nhiều tệp trong số đó mở trong các tab, với một hoặc hai cái có thể nhìn thấy cùng một lúc,

Các lỗi sau đó được liệt kê trong một danh sách có thể thay đổi có thể cuộn được trượt ra (theo mặc định) bên dưới giao diện người dùng chính. Điều này có thể được thực hiện ngay khi một lỗi bị mắc kẹt. Khi một lỗi được nhấp hoặc nhấp đúp, nó sẽ đưa bạn đến đúng nơi và tập trung để sửa lỗi - và lỗi sẽ biến mất khỏi danh sách khi nó không còn hiệu lực nữa.

(Trong thực tế, nhiều lỗi trong số này cần một hành động do người dùng khởi tạo để được đánh giá lại nhưng có rất nhiều bổ trợ phân tích tĩnh thực hiện điều này trong nền và thực sự cập nhật danh sách lỗi một cách linh hoạt trong khi chỉnh sửa mã) .

0
Oskar Duveborn

a) Ví dụ: nếu ai đó sử dụng giá trị phần trăm lớn hơn 100, UI sẽ đặt lại giá trị thành 100 trong trường hợp mất tiêu điểm.

Điểm tốt, nhưng sau đó bạn cần chắc chắn:

  1. Người dùng nhận ra rằng đầu vào của mình đã được sửa.
    [.___.] Có thể, ví dụ, làm cho trường flash trong một giây nếu bạn sửa giá trị.

  2. Bạn có thể đoán một cách hợp lý những gì người dùng thực sự có nghĩa.
    [.___.] Ví dụ: lấy một bộ chọn màu tôi đã vật lộn với ngày hôm qua. Tôi muốn một vài yếu tố khớp với các yếu tố từ một trang web khác, vì vậy tôi đã có cho mình các giá trị hex và sao chép chúng vào các hộp văn bản đặc biệt nhỏ. Giá trị đầu tiên là #202040, nhưng vì một số lý do tôi chỉ dán #20204, đã được "sửa" kịp thời thành #020204. Giá trị thứ hai tôi đã dán là #BCD (viết tắt cho #BBCCDD), cũng được "sửa" thành ... #000BCD. Thở dài.
0
badp