it-swarm-vi.tech

Trải nghiệm người dùng tốt hơn là gì: đánh dấu lỗi hoặc chặn tổ hợp phím sai?

Tôi có một số thông tin để nhập vào một hộp văn bản. Dữ liệu được cấu trúc và chỉ một số trình tự là hợp lệ. Ví dụ, đối với một số điện thoại, một chữ cái như A không hợp lệ.

Vì vậy, tôi có nên chặn các sự kiện bàn phím và ngăn các chữ cái được gõ vào hộp văn bản hay tôi nên vẽ một số dòng nguệch ngoạc màu đỏ (hoặc một dấu hiệu trực quan khác) để cho người dùng của tôi biết chữ không được chấp nhận? Đó là một trải nghiệm người dùng tốt hơn?

20
louisgab

Việc ghi đè quyền kiểm soát của người dùng đối với máy tính của họ sẽ luôn bị gián đoạn và thường được coi là một cuộc xâm lược, trong quy trình làm việc của người dùng đó. Trang web "không được cho là" có quyền kiểm soát máy tính của chúng tôi, do đó, việc kiểm soát như vậy sẽ ít nhất là một chút đáng báo động.

Điều đó nói rằng, bạn giới thiệu một chủ đề thực sự quan trọng, là tầm quan trọng của việc cho người dùng biết mục nhập của họ không hợp lệ trước khi họ điền vào toàn bộ các trường và gửi chúng.

Cách tiếp cận mà tôi thấy là ít xâm phạm nhất nhưng cung cấp phản ứng quay vòng nhanh nhất là dòng chảy bên dưới.

alt text

Về cơ bản, đợi họ điền vào trường đầu tiên của họ, sau đó khi họ nhấp/tab xung quanh một trường mới (hoặc một trường đã bị vô hiệu), hãy kiểm tra trường vừa hoàn thành. Nếu trường vừa hoàn thành là hợp lệ, hãy in biểu tượng "tốt" không phô trương bên cạnh nó (màu xanh lá cây, dấu kiểm, khuôn mặt hạnh phúc, bạn sẽ có ý tưởng). Nếu nó không thành công các quy tắc xác thực, hãy in một cách riêng biệt một biểu tượng "xấu" (màu đỏ, "X", v.v.) và một dòng ngắn về những gì không thành công.

Nhưng hãy nhớ, đừng làm gián đoạn tiến trình công việc của họ:

  • Không có cửa sổ bật lên
  • không có lớp phủ

Khi họ kết thúc với trường họ đã chuyển đến, họ sẽ quay lại trường không hợp lệ hoặc chuyển sang và quay lại sau. Dù bằng cách nào, họ sẽ thấy rằng họ có một chỉnh sửa để thực hiện nhưng có thể thực hiện nó vào thời gian riêng của họ.

Cuối cùng, họ sẽ có một hình thức hoàn toàn hợp lệ trước khi gửi, có nghĩa là

  1. Họ sẽ chỉ phải nộp một lần
  2. Họ không dành thời gian để nổi điên hoặc thất vọng khi bài nộp của họ "thất bại"
  3. Họ sẽ thích trang web của bạn hơn
  4. Mọi người sẽ có bánh
17
Matt

Ở cả hai đầu của việc sử dụng một biểu mẫu, đây là một số nguyên tắc tôi thích:

  • Đầu vào của người dùng hầu như không bao giờ được ngăn chặn. Có nghĩa là nếu tôi nhập chữ 'A' vào trường số điện thoại, tôi sẽ thấy chữ 'A' đó.
  • Tôi bắt đầu xác thực trường văn bản của mình trên một sự kiện onBlur() và không sớm hơn thế. Điều này mang lại cho người dùng cơ hội sửa lỗi 'A' được gõ sai trước khi tôi hiển thị thông báo lỗi. Việc cho phép người dùng sửa lỗi trong khi vẫn ở trong trường nhập liệu cung cấp ít cơ hội hơn cho một loại tin nhắn "hey, you messed, dude" gây khó chịu.
8
wnathanlee

Nếu bạn ngăn các ký tự không hợp lệ trong khi họ nhập, họ có thể nghĩ rằng bàn phím của họ bị trục trặc. Người dùng thích những thứ hoạt động theo cách họ mong đợi. Nếu bạn định ngăn một số ký tự khi nhấn phím, ít nhất bạn cũng nên hiển thị thông báo lỗi gần đầu vào cùng một lúc. Bằng cách này, họ biết tại sao nó không gõ.

Một điều khác có thể gây khó chịu là khi bạn vừa điền xong một biểu mẫu dài và trang web sử dụng xác thực phía máy chủ để bạn phải quay lại biểu mẫu để tìm lỗi. Tôi thích sử dụng xác nhận phía khách hàng là chủ yếu nhưng lại rơi vào phía máy chủ. Tôi sẽ hiển thị một lỗi khi họ đang gõ hoặc khi đầu vào mất tiêu điểm. Bằng cách đó, người dùng biết ngay rằng có một vấn đề và biết chính xác vấn đề là gì.

5
LoganGoesPlaces

Tôi thấy rằng việc ngăn người dùng mắc lỗi luôn khó hơn gấp 10 lần so với suy nghĩ ban đầu của tôi. Ví dụ: Số điện thoại của ai đó có thể có phần mở rộng, như x2333. Tôi đã sử dụng plugin mặt nạ đầu vào jQuery cho thẻ tín dụng và nó hoạt động tốt. Tôi sử dụng Tự động đề xuất bất cứ khi nào có thể.

Trong bất kỳ hệ thống phức tạp nào, bạn sẽ có những tình huống tốn kém để phát hiện nội tuyến và bạn cần nói với họ sau thực tế. Đối với tôi, câu trả lời là tùy từng trường hợp và đảm bảo bạn bao quát mọi trường hợp Edge.

3
Glen Lipka

Tôi sẽ đề xuất kết hợp cả hai cách tiếp cận, nhưng chỉ đối với các trường được xác thực nghiêm ngặt như số điện thoại (SSN, mã zip, v.v ... bất cứ điều gì phải là số theo định nghĩa).

Theo dõi từng tổ hợp phím và khi người dùng nhập một ký tự không hợp lệ, hiển thị nó ... nhưng ngay lập tức báo hiệu rằng có gì đó không đúng. Có thể chuyển trường đầu vào thành màu đỏ và hiển thị "Chỉ nhập các ký tự số" ở bên phải của trường.

Chặn đầu vào là không có bởi vì nó có thể bị người dùng hiểu sai. Họ có thể giả sử có vấn đề với máy hoặc thiết bị đầu vào của họ, không phải là họ không nên nhập một chữ cái trong hộp nhập số.

Xác thực sau đầu vào được hoàn thành có thể gây khó chịu. Đặc biệt với các trường như những người được sử dụng trong việc tạo mật khẩu. Một số trang web yêu cầu mật khẩu 6 ký tự chỉ có các ký tự chữ và số. Những người khác yêu cầu mật khẩu 9 ký tự và cho phép bất kỳ ký tự nào (bao gồm! @ # $% Và như vậy). Nhập mật khẩu và chỉ tìm ra sau Tôi đã nhập nó là loại hình khó chịu nhất mà tôi đã tìm thấy và thực sự đã khiến tôi rời xa một số dịch vụ .

Cung cấp phản hồi động khi người dùng nhập dữ liệu giúp họ

  1. Biết trường nào có lỗi trong khi chúng vẫn ở trong trường
  2. Chủ động sửa lỗi đầu vào trước khi gửi dữ liệu
  3. Học hỏi kinh nghiệm khi họ đi

Chặn đầu vào thất bại trên cả 3 tài khoản. Làm nổi bật các lỗi xác nhận sau khi hộp văn bản được điền không thành công trên cả 3.

2
EAMann

Nó phụ thuộc vào trường hợp. Nếu có thể hãy sử dụng Tự động đề xuất. Nếu bạn chặn đầu vào của người dùng, phản hồi ngay lập tức là rất quan trọng. Một trong những giải pháp khả thi là "hộp manh mối" bật lên ngay lập tức sau khi khóa bị chặn. Bạn có thể thấy nó trên màn hình đăng nhập Windows, nó bật lên nếu bạn nhấn dấu $ chẳng hạn.

1
Janko

Như với hầu hết mọi thứ .. phụ thuộc vào bối cảnh. Tôi có một chuyên ngành hơn về chủ đề này. Hầu hết các ứng dụng tôi hoặc nhóm của tôi làm việc đều có bản chất kỹ thuật và chỉ được sử dụng bởi người được đào tạo hợp lý. Vì vậy, chúng tôi có thể đặt nhiều trách nhiệm và tự do hơn trong tay của người dùng so với công chúng nói chung. Tóm lại, một số hướng dẫn chúng tôi sử dụng ...

  • Bỏ qua mọi mục nhập không hợp lệ .... chặn tổ hợp phím không hợp lệ.
  • Chỉ ra các trường không hợp lệ, trạng thái nên là tất cả nhưng không thể, bằng độ tương phản và màu sắc *.
  • Trọng tâm luôn nằm dưới sự kiểm soát của người dùng. Không bẫy người dùng hoặc ngăn chặn sự thay đổi trọng tâm.
  • Không bao giờ ném một cảnh báo phương thức/hộp lỗi. Không bao giờ.
  • Không bao giờ đặt câu hỏi cho người dùng. Phần mềm là một công cụ không phải là một người. Vâng tôi chắc chắn.
  • Các phím Enter/Return luôn có nghĩa là: Chấp nhận thay đổi và tiếp tục. Không thay đổi điều này bằng cách sử dụng tiêu điểm trên nút hủy/thoát làm mặc định trên Enter.
  • Phím Escape luôn có nghĩa là: Hủy và thoát.
  • Cung cấp tự động hoàn thành bất cứ khi nào có thể.
  • Cung cấp mục nhập ngắn cho các số có giới hạn tối thiểu/tối đa. ví dụ. Nếu một giá trị hợp lệ nằm trong khoảng từ 0,12 đến 100.387 thì các mục lớn hơn 100.387, như 999, được lấy là 100.387, v.v.
  • Thiết lập các quy tắc trắng đen rất rõ ràng về hành vi..rules người dùng có thể hiểu. Nếu điều này trở nên quá phức tạp ... hãy nghĩ lại.

Hầu như tất cả các ví dụ đều được người dùng yêu cầu và, vâng ... việc thực hiện đôi khi là một con gấu/ác mộng/kẻ giết người thực sự nhưng hiếm khi không thể.

Hãy cẩn thận: Một lần nữa, những ví dụ này được đưa ra trong bối cảnh của một hệ thống dọc với cơ sở người dùng kỹ thuật .... không phải là một hình thức chung chung trên web, v.v. Số dặm của bạn thay đổi.

* Trừ màu đỏ. Trong kinh doanh của chúng tôi có nghĩa là màu đỏ: Nguy hiểm bạn có thể bị giết ... hoặc tệ hơn.

1
Rusty