Lời nhắc, xác nhận và cảnh báo của JavaScript được coi là kiểu cũ [đóng]


21

Gần đây tôi đã phát triển một hệ thống quản lý dựa trên web cho phòng tập thể dục. Ứng dụng trước đây của họ được phát triển trong Visual Basic. Đối với ứng dụng mới, tất cả các tập lệnh phía trước đều sử dụng jQuery, máy chủ đang chạy PHP & MySQL ... bạn biết đấy, ngăn xếp dựa trên linux el-cheapo điển hình.

Dù sao, tôi đã tự hỏi tại sao các hộp thoại thông báo nhắc nhở, xác nhận và cảnh báo của JavaScript ngày nay không được sử dụng nhiều. Có rất nhiều plugin jQuery cho các cửa sổ phương thức và các thông báo cảnh báo cố gắng bắt chước một cái gì đó mà ngôn ngữ đã cung cấp và mọi trình duyệt buộc phải hỗ trợ đúng cách.

Sử dụng các giải pháp làm bằng tay hoặc dựa trên plugin là ổn đối với các hình thức phức tạp và nhu cầu đặc biệt, nhưng nếu bạn chỉ cần yêu cầu một giá trị duy nhất hoặc xác nhận xóa bản ghi, tại sao bạn lại thêm chi phí đó vào ứng dụng web của mình? Hơn nữa, iOS và Android cung cấp các hộp thoại tin nhắn thích nghi độc đáo khi bạn sử dụng lời nhắc, xác nhận và cảnh báo.


7
"El cheapo?" Có thật không? Đó không phải là một chút miệt thị sao?
asthasr

1
Tôi bối rối; Đầu tiên bạn nói ứng dụng được phát triển trong Visual Basic, sau đó bạn nói rằng máy chủ đang chạy PHP. Huh?
jhocking

@jhocking: có vẻ như anh ta nói hệ thống cũ là một ứng dụng máy tính để bàn được viết bằng VB và hệ thống mới (ứng dụng anh ta viết) được viết bằng một ngăn xếp LAMP.
Jordan

Âm thanh như ứng dụng trước đây của họ được viết bằng vb, anh ấy hiện đang tạo một giao diện web cho nó.
GrandmasterB

Câu trả lời:


56

1. UX: hộp tin nhắn chủ yếu là xấu xa

Hộp cảnh báo là xấu trong mọi trường hợp từ quan điểm UX. Trong các ứng dụng máy tính để bàn. Trong các ứng dụng web dưới dạng cảnh báo hoặc tin nhắn JavaScript nội tuyến. Mọi nơi.

Bạn có thể đọc About Face 3 của Alan Cooper¹ nếu bạn muốn biết tại sao; nó giải thích rất rõ làm thế nào điều này làm gián đoạn tiến trình công việc và gây khó chịu cho người dùng và gần như mọi hộp cảnh báo tồn tại trong phần mềm hiện tại đều sai lầm sâu sắc . Trên trang 542, "Hộp thoại đã khóc Sói!" Giải thích rằng các hộp cảnh báo bị loại bỏ thường xuyên, do đó mô hình của chúng bị hỏng hoàn toàn. Trên trang 543 của cuốn sách được liệt kê ba nguyên tắc thiết kế chính:

  • Đừng, đừng hỏi.
  • Làm cho tất cả các hành động đảo ngược.
  • Cung cấp phản hồi không điều độ để giúp người dùng tránh sai lầm.

Sau đó, các tác giả cho chúng tôi biết làm thế nào để thay thế các hộp cảnh báo bằng phương pháp thiết kế chính xác.

Tin nhắn nhắc nhở là hơi khác nhau. Tuy nhiên, họ phá vỡ trải nghiệm người dùng của ứng dụng của bạn. Nếu bạn muốn người dùng nhập một cái gì đó, hãy xem xét sử dụng hộp văn bản hoặc văn bản, trang trí nó bằng JavaScript khi cần. Đừng lười biếng, cung cấp giao diện phong phú trong kỷ nguyên của các ứng dụng hỗ trợ RIA và AJAX ; trong mọi trường hợp, nếu JavaScript bị tắt, lời nhắc của bạn sẽ không được hiển thị.

Trong các trang web, cả hộp cảnh báo và lời nhắc hầu hết đều gây khó chịu. Vài ví dụ:

  1. Một số diễn đàn cho phép bạn tạo danh sách bằng cách nhắc vô hạn cho các mục danh sách. Điều đó có nghĩa là trong khi tạo danh sách, bạn không thể sử dụng chính trang đó, bao gồm sao chép-dán. Bạn cũng có một lĩnh vực nhỏ bé duy nhất. Còn văn bản dài thì sao? Còn in đậm và in nghiêng thì sao?

  2. "Nếu bạn tiếp tục, ảnh sẽ bị xóa hoàn toàn khỏi hồ sơ của bạn. Bạn có chắc không?" . Tất nhiên tôi chắc chắn! Tôi có thể nhấp vào "Xóa ảnh khỏi hồ sơ của tôi" không? Tại sao ứng dụng web của bạn cho rằng tôi rất ngu ngốc? Trên thực tế, các ứng dụng của Google như GMail cho thấy cách tiếp cận chính xác. Bạn có thể xóa, xóa, hủy bất cứ thứ gì bạn muốn và khi bạn làm như vậy, ứng dụng sẽ hiển thị một liên kết "Hoàn tác" nhỏ.

  3. "Bạn có muốn thực hiện cuộc khảo sát lớn nhất của chúng tôi?" . Chà, thực ra tôi đã ở đó để truy cập trang web của bạn, nhưng vì bạn làm phiền tôi với những tin nhắn phiền phức của bạn, tôi thà đi nơi khác.

  4. "Nhấp chuột phải bị vô hiệu hóa trên trang web này để bảo vệ ảnh có bản quyền" . Chà, thực ra tôi đã nhấp chuột phải để thay đổi ngôn ngữ của trình kiểm tra chính tả trước khi gửi bình luận của tôi. Chắc chắn, tôi sẽ gửi nó mà không kiểm tra chính tả.

Kết luận: từ quan điểm trải nghiệm người dùng, các ứng dụng sử dụng hộp thông báo sai phần lớn thời gian.

Nhưng chờ đã! Nhiều trang web chất lượng thấp thay thế các hộp cảnh báo gây phiền nhiễu bằng các thông báo JQuery gây phiền nhiễu bằng nền bán trong suốt bao trùm tất cả các trang. Vì vậy, những hạn chế vẫn còn.

Vâng, có một lý do khác để không sử dụng hộp thông báo trong các ứng dụng web:

2. Thiết kế: hộp cảnh báo có thiết kế riêng

Bạn không thể thiết kế một hộp cảnh báo nào cả. Bạn không thể thay đổi màu sắc, kích thước, phông chữ của nó. Điều này khiến người dùng càng khó chịu hơn: bạn đang làm việc với một ứng dụng web và quy trình làm việc của bạn bị phá vỡ bởi một thông báo dường như đến từ đâu đó và thậm chí không khớp với khía cạnh trực quan của ứng dụng. Không tính rằng ngôn ngữ của các nút cũng phù hợp với ngôn ngữ hệ điều hành / trình duyệt, không phải ngôn ngữ ứng dụng web.

Đối với các nhà thiết kế, thông điệp JavaScript mạnh hơn nhiều so với các hộp cảnh báo.

Họ cũng mở rộng hơn nhiều. Bạn có thể thêm chữ đậm và chữ nghiêng, bạn có thể chọn các nút của riêng mình (điều gì về: "Chúng tôi xin lỗi nhưng mật khẩu bạn đã nhập không hợp lệ. [Đặt lại mật khẩu của tôi] [Thử một cái khác] [Hủy]"?) ².

3. JavaScript: dừng dòng ứng dụng

Khi hiển thị hộp cảnh báo, JavaScript dừng thực thi cho đến khi người dùng nhấp vào. Trên một trang web, nó có thể là ok. Với một ứng dụng web, nó thường trở thành một vấn đề.

4. Sandbox: không buộc người dùng khởi động lại máy tính của mình

Hãy nhớ các trang web crappy cho bạn thấy vô số hộp tin nhắn ? Cách duy nhất để người dùng không có đủ nền tảng kỹ thuật có thể tiếp tục làm việc là trên thực tế để khởi động lại máy tính của họ. Điều này đưa chúng ta đến một vấn đề: các hộp cảnh báo nằm ngoài phạm vi của trang web hoặc ứng dụng web. Bạn không được phép ngăn người dùng truy cập các tab khác của trình duyệt³.

Vấn đề tương tự buộc các trình duyệt phải giải quyết nó theo nhiều cách khác nhau. Firefox, ví dụ, cho phép truy cập vào các tab khác khi hiển thị cảnh báo trên tab của bạn. Mặt khác, Chrome cho phép bạn kiểm tra xem bạn có muốn nhận bất kỳ hộp cảnh báo nào từ một trang nữa không, nhưng vẫn chặn quyền truy cập vào các tab khác.

Ảnh chụp màn hình hiển thị hộp cảnh báo với hộp kiểm "Ngăn trang này tạo các hộp thoại bổ sung"

Mặc dù cách tiếp cận của Firefox là hoàn toàn hợp lệ, nhưng cách tiếp cận của Chrome có thể bị chỉ trích (vì nó vẫn chặn mọi tab) và gây ra sự cố: nếu người dùng bị làm phiền nghiêm trọng bởi một số hộp thông báo do ứng dụng của bạn phát hành và sau đó, bạn đã cố gắng thể hiện một cái gì đó thực sự quan trọng? Phải, người dùng sẽ không bao giờ nhìn thấy nó.

Thực tế vẫn như vậy, hầu hết người dùng sẽ khó chịu bởi các hộp cảnh báo, vì vậy họ vẫn không thân thiện với người dùng và có thể chặn người dùng không có đủ nền tảng kỹ thuật. Nội tuyến, tin nhắn JavaScript có thể chặn trang, nhưng không phải chính trình duyệt. Vì mô hình ứng dụng web là một loại hộp cát, ví dụ bạn không thể truy cập bàn phím người dùng hoặc khởi động lại máy tính hoặc đọc tệp từ đĩa cứng hoặc toàn màn hình hoặc sử dụng hai màn hình, hộp cảnh báo với hiệu ứng chặn của chúng bị phá vỡ nghiêm trọng mô hình hộp cát .

Cuối cùng nhưng không kém phần quan trọng, điều gì sẽ xảy ra nếu người dùng ở trên một tab khác khi ứng dụng của bạn quyết định hiển thị hộp cảnh báo? Điều gì xảy ra nếu người dùng đang làm điều gì đó quan trọng và không muốn tương tác với ứng dụng của bạn ngay bây giờ?


¹ About Face 3, Yếu Tương tác Thiết kế , Alan Cooper, Robert Reimann và David Cronin, ISBN 978-0-470-08411-3; Chương 25: Lỗi, Cảnh báo và Xác nhận.

² Đây chỉ là một ví dụ. Xin vui lòng, đừng làm điều đó trong các ứng dụng web của bạn, vì đó thực sự là một lựa chọn thiết kế kém.

Nếu bạn muốn so sánh với thế giới của các ứng dụng máy tính để bàn, một thông báo JavaScript nội tuyến giống như một hộp thông báo của ứng dụng máy tính để bàn. Mặt khác, một hộp cảnh báo trong trình duyệt, giống như một cửa sổ xuất hiện từ hư không, được đặt ở trên cùng, trên nền mờ toàn màn hình, ngăn bạn truy cập bất kỳ ứng dụng máy tính để bàn nào khác. Bất kỳ ứng dụng nào quyết định thực hiện một lần trên máy tính của tôi sẽ bị xóa ngay lập tức và mãi mãi.


1
Câu hỏi không liên quan gì đến cửa sổ bật lên vô hạn hoặc spam, vậy tại sao bạn lại đề cập đến nó ở đây? Và tôi không nghĩ rằng nó thực sự là một điều tồi tệ mà các cửa sổ bật lên của JS là không thể thay đổi. Khi được sử dụng đúng cách (để cảnh báo người dùng về một cái gì đó CHÍNH), họ buộc người dùng phải giải quyết chúng trước khi làm bất cứ điều gì khác, đôi khi đó là những gì bạn muốn.
Graham

Điều này không trả lời câu hỏi.
CaffGeek

1
"Khi hiển thị hộp cảnh báo, JavaScript dừng thực thi cho đến khi người dùng nhấp vào" - điều này đúng với a confirm()prompt(); với alert(), hành vi phụ thuộc vào trình duyệt (thực thi có thể tiếp tục ngay cả khi cảnh báo () được hiển thị - lý do là "dù sao cũng chỉ có một lối thoát").
Piskvor

1
@ Graham: Bạn phù hợp với quảng cáo vô hạn; Tôi đã lạc đề về điểm này. Tôi đã cố gắng cải cách điều này tốt hơn. Để cảnh báo cho điều gì đó quan trọng, hãy xem điểm thứ tư trong câu trả lời của tôi: có, bạn có thể muốn dừng mọi thứ trước khi người dùng xác nhận một hành động, nhưng nó không cho phép bạn chặn mọi tab của trình duyệt, vì các tab khác không thuộc về ứng dụng web của bạn
Arseni Mourzenko

1
@BornToCode: không có lựa chọn nào khác. Ngay khi bạn hiển thị ảnh trên màn hình của người dùng, không có cách nào để bảo vệ chúng khỏi bị sao chép. Đối với câu hỏi thứ hai của bạn, bạn phải cụ thể hơn. Hãy thử ux.se .
Arseni Mourzenko

3

Dòng dưới cùng: Hộp thoại nhắc nhở, xác nhận và cảnh báo mặc định phù hợp với kiểu trình duyệt của bạn, không phải kiểu của trang web của bạn. Hầu hết người dùng UI muốn tất cả các hộp thoại chảy với giao diện người dùng của trang web của họ. Họ sử dụng các cửa sổ phương thức để trình bày tin nhắn và thu thập dữ liệu bằng cách sử dụng cùng một phông chữ và màu sắc như giao diện người dùng của trang web, không phải màu xám và màu xanh mặc định của MSIE hoặc FF.


2

Bạn chỉ thêm chi phí nếu bạn không cần các hộp thoại ưa thích ở nơi khác, điều mà bạn có thể làm. Vào thời điểm đó, sẽ không có nhiều khác biệt cho dù chức năng được bao gồm như một phần của trình duyệt hay là một phần của khung bạn đang sử dụng và bạn cũng có thể giữ cho tất cả các cửa sổ bật lên của mình trông ổn định.

Mặc dù bạn có thể làm rất nhiều với javascript và không có khung, tôi nhớ nó giống như phát triển trong javascript trước khi các khung có sẵn và tôi sẽ không muốn quay lại nó.


1

Bởi vì các trình duyệt không xử lý chúng rất tốt . Như bạn có thể nhận thấy chúng thường là các hộp thoại theo chế độ và không chỉ ngăn người dùng di chuyển và thay đổi kích thước trình duyệt của họ, họ còn ngăn các tab khác truy cập, điều này rất khó chịu.

Đối với các hộp thoại như xác nhận và thay đổi, tôi vẫn nghĩ trình duyệt nên thực thi hành vi và đối với trình duyệt Firefox mới nhất, bạn có thể thấy họ đã khắc phục sự cố tôi đã đề cập ở trên. Họ sử dụng trong các cảnh báo trang nằm trong phạm vi của trang hiện tại.

Do đó, tôi khuyên bạn nên ghi đè hành vi cảnh báo để tất cả các trình duyệt có thể xử lý (ít nhất là cảnh báo) một cách thanh lịch hơn.

Một vài lý do tóm tắt:

  • Đây là API tiêu chuẩn và nhà phát triển có thể tìm ra những gì bạn đang cố gắng thực hiện.
  • Nó thân thiện với người dùng hơn và trông đẹp hơn.
  • Hỗ trợ nền tảng, các trang web di động có thể cần API gốc.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.