- Khi mở rộng trực tiếp bố cục được tạo cho di động sang desktop, hình ảnh, chữ và khoảng trắng trở nên quá lớn, còn thông tin bị rải ra trên một trang dài, gây ra sự phân tán nội dung và làm giảm khả năng sử dụng
- Hơn 55% lưu lượng web toàn cầu hiện đến từ di động, nên mobile-first được dùng rất rộng rãi, nhưng khi kết hợp với chủ nghĩa tối giản và thiết kế thiên về hình ảnh lớn, mật độ thông tin trên desktop giảm mạnh
- Kết quả so sánh bố cục phân tán và cô đọng trong 13 bài kiểm thử khả dụng định tính cho thấy các trang phân tán khiến việc tìm kiếm và hiểu thông tin khó hơn
- Nội dung bị phân tán làm tăng số lần cuộn và nhấp, từ đó nâng chi phí tương tác, đồng thời buộc người dùng phải ghi nhớ thông tin liên quan nằm trên nhiều màn hình, dẫn đến tăng tải nhận thức, thất vọng và suy giảm niềm tin
- Trên desktop, nên gom các thông tin quan trọng có liên quan vào cùng một viewport, và chỉ nên dùng hạn chế các mẫu dành riêng cho di động như accordion
Sự phân tán nội dung là gì
- Sự phân tán nội dung là hiện tượng nội dung của một trang web responsive hiển thị quá to và bị kéo giãn quá mức trên màn hình laptop hoặc desktop lớn
- Khi các trang mobile-first được render trên desktop, những hình ảnh phủ kín màn hình, cỡ chữ bị phóng to và khoảng trắng âm quá nhiều tạo ra các trang rất dài và đòi hỏi phải cuộn nhiều hơn
- Nếu sự phân tán chỉ xuất hiện ở một vài phần thì có thể chưa gây ra vấn đề khả dụng lớn, nhưng nếu xuất hiện ở phần lớn trang thì tác động tích lũy nhìn chung là tiêu cực
- Trên thiết bị màn hình lớn, sự phân tán nội dung làm tăng tải nhận thức, chi phí tương tác, độ khó trong việc hiểu nội dung và sự thất vọng của người dùng
Các xu hướng thiết kế tạo ra sự phân tán nội dung
- Cách tiếp cận mobile-first là thiết kế trước cho di động rồi mới điều chỉnh cho tablet và desktop
- Cách tiếp cận này được sử dụng rộng rãi khi hơn 55% lưu lượng web toàn cầu đến từ thiết bị di động
- Chủ nghĩa tối giản loại bỏ những yếu tố thiết kế không cần thiết cho chức năng cốt lõi hoặc thông điệp chính của website
- Để tránh tạo cảm giác rối mắt, nó thường dùng nhiều khoảng trắng âm
- Điều này có thể làm giảm lượng nội dung hiển thị trong một viewport, từ đó tạo ra các trang dài với mật độ thông tin thấp
- Thiết kế thiên về hình ảnh lớn gắn với xu hướng dùng ảnh độ phân giải cao ở kích thước lớn trong web hiện đại
- Hình ảnh lớn có thể thu hút ánh nhìn, nhưng cũng có thể khiến nội dung văn bản bị rải ra quá mức
- Một vài hình ảnh lớn trên trang desktop có thể hoạt động tốt
- Nhưng nếu có quá nhiều hình ảnh lớn, nội dung văn bản xen giữa chúng sẽ bị chia nhỏ khắp toàn bộ trang
Cách thực hiện 13 bài kiểm thử khả dụng
- Nghiên cứu kết hợp 13 bài kiểm thử khả dụng định tính với phỏng vấn bán cấu trúc
- Đối tượng so sánh là tổ hợp của hai loại bố cục và hai loại trang
- Bố cục: cô đọng, phân tán
- Loại trang: trang chủ, trang sản phẩm
- Tổng cộng sử dụng 4 prototype
- Prototype phân tán được tái dựng từ các trang web desktop thực tế có mật độ nội dung thấp, nhiều khoảng trắng âm và cỡ chữ lớn
- Phiên bản cô đọng được xây dựng riêng nhưng dùng cùng nội dung với trang gốc
- Người dùng thực hiện các hoạt động mở trên cả 4 prototype và tham gia phần thảo luận tiếp theo để so sánh hai phiên bản của từng loại trang
- Toàn bộ phương pháp nghiên cứu có trong trang phương pháp riêng
Các vấn đề khả dụng do nội dung phân tán gây ra
- Khi sự phân tán xuất hiện trên phạm vi rộng của trang, nó có thể ảnh hưởng lớn đến toàn bộ trải nghiệm người dùng
- Các vấn đề chính gồm
- Tăng độ dài trang và chi phí tương tác
- Tăng tải nhận thức
- Khó hình thành mô hình khái niệm của trang
- Tăng cảm giác thất vọng
- Giảm mức độ tin cậy
-
Tăng số lần cuộn và nhấp
- Sự phân tán nội dung tạo ra các trang dài cần cuộn nhiều hơn, còn các yếu tố thiết kế dành riêng cho di động như accordion đòi hỏi thêm nhiều lần nhấp để truy cập nội dung
- Khi website mobile-first được render trên màn hình lớn, nội dung bị phân tán thành các trang dài; hiệu ứng này càng mạnh khi kết hợp với chủ nghĩa tối giản và thiết kế thiên về hình ảnh
- Khi nội dung bị rải ra trên nhiều viewport, việc tìm một thông tin cụ thể trong trang trở nên khó hơn
- Trong thử nghiệm, người tham gia gặp khó khăn hơn khi tìm thông tin trên trang sản phẩm phân tán so với phiên bản cô đọng
-
Vấn đề của các mẫu chỉ dành cho di động trên desktop
- Accordion trên di động giúp gói nhiều thông tin vào không gian hẹp, làm trang ngắn hơn và cho phép người dùng đi thẳng tới vùng họ quan tâm
- Trên màn hình lớn, vấn đề trang dài tương đối nhỏ hơn, nên accordion có thể làm nội dung bị phân mảnh và làm tăng mạnh chi phí tương tác khi tìm thông tin quan trọng
- Một người tham gia cho biết trên accordion thông tin sản phẩm của prototype phân tán, họ phải mở rồi đóng từng mục để đọc thông tin
- Một người khác đánh giá trang cô đọng tốt hơn vì ít phải nhấp hơn và thông tin nằm ngay trước mắt
-
Tăng tải nhận thức
- Khi hình ảnh lớn hơn và khoảng trắng âm rộng hơn, nội dung dạng văn bản bị chia nhỏ ra qua nhiều viewport
- Nếu các nội dung liên quan bị cắt theo từng màn hình, người dùng sẽ khó nhìn chúng như một khối thống nhất
- Để đưa ra đánh giá hoặc quyết định, họ phải nhớ thông tin từ các viewport khác nhau hoặc cuộn tới lui, khiến dung lượng trí nhớ ngắn hạn dễ bị quá tải
- Bố cục cô đọng hiển thị nhiều thông tin hơn trong cùng một viewport, giúp giảm gánh nặng nhận thức và mang lại trải nghiệm duyệt dễ dàng hơn
- Tính chất của hình ảnh cũng ảnh hưởng đến cảm nhận phân mảnh
- Hình ảnh mang tính thông tin có thể ít tạo thêm gánh nặng dù được hiển thị lớn trên màn hình lớn, vì người dùng sẵn sàng dành thời gian xem để lấy thông tin hữu ích
- Hình ảnh trang trí không có giá trị thông tin nên người dùng thường lướt qua; việc phải cuộn qua các minh họa lớn để tới nội dung hữu ích khiến cảm giác phân mảnh tệ hơn
Ảnh hưởng đến mô hình khái niệm và độ tin cậy
- Các trang phân tán khiến việc đánh giá khái niệm mà website muốn truyền tải và hình thành mô hình khái niệm trở nên khó hơn do trang dài hơn và gánh nặng lên bộ nhớ làm việc
- Với prototype trang chủ, người tham gia cho biết thay vì có thể xem đồng thời 4–5 đề xuất để hiểu phạm vi, họ phải ghi nhớ chúng trong lúc cố gắng hiểu, nên việc này khó hơn
- Trên trang sản phẩm, khi các yếu tố phục vụ quyết định mua như giá, chi tiết sản phẩm và đánh giá bị rải trên nhiều viewport, người dùng phải tiếp nhận và ghi nhớ từng phần riêng lẻ
- Khi thông tin quan trọng được đặt gần nhau hoặc nằm trong ít viewport hơn, người dùng sẽ dễ xây dựng hiểu biết khái niệm về sản phẩm hoặc giá trị được cung cấp hơn
- Ảo giác hoàn chỉnh có thể nổi bật hơn trên các website phân tán
- Các khối màu có thể tạo ra những đường ngang mạnh trong viewport, hoặc khoảng trắng âm rộng có thể làm trang trông như đã kết thúc
- Nếu không có dấu hiệu cuộn cho thấy vẫn còn nội dung, người dùng có thể bỏ lỡ thông tin
- Khi các vấn đề khả dụng tích lũy, website phân tán có thể khiến nội dung trông vừa ít vừa khó tiếp cận
- Một số người dùng có thể cảm thấy công ty đang che giấu thông tin, và trong trường hợp đó độ tin cậy có thể giảm
- Người dùng đặc biệt ưa thích bố cục cô đọng hơn khi mục tiêu của họ là khám phá website và hiểu tổng thể những gì được cung cấp
Khi nào sự phân tán nội dung có ích
- Dù việc cả trang bị phân tán nhìn chung gây tác động khả dụng tiêu cực theo kiểu tích lũy, trong một số tình huống cụ thể nó vẫn có thể cải thiện trải nghiệm
- Khi lượng nội dung hiển thị trong một viewport giảm đi, người dùng có thể tập trung vào một nội dung nhấn mạnh tại một thời điểm và cũng ít cảm thấy quá tải thông tin hơn
- Việc giảm mật độ nội dung trong viewport để nhấn mạnh thông tin có thể hữu ích trong các trường hợp sau
- Khi cần hiểu nội dung phức tạp theo từng phần
- Khi người dùng cần làm quen với nội dung hiển thị và có thể bị choáng nếu có quá nhiều thông tin
- Khi hiển thị hình ảnh có giá trị cao
- Ảnh sản phẩm lớn có thể giúp người dùng dễ quan sát chi tiết sản phẩm, từ đó tạo thêm giá trị
- Hình ảnh có giá trị thông tin cao có thể biện minh cho sự phân tán, nhưng các hình ảnh chỉ để lấp chỗ hoặc tạo hứng thú thị giác đơn thuần thì chỉ gây phân tán mà không mang lại lợi ích bổ sung
- Trong prototype trang chủ, giá trị của hình ảnh thấp hơn nên tác động tích cực của sự phân tán nội dung được ghi nhận ít hơn
Khuyến nghị thiết kế cho desktop
- Cần đánh giá riêng phần render trên desktop
- Nếu các phần lớn của trang trên desktop bị kéo giãn quá mức, nên cân nhắc thiết kế lại để nội dung quan trọng dễ quét hơn
- Cần cân nhắc giá trị mà hình ảnh mang lại
- Nên ưu tiên các hình ảnh lớn giúp người dùng hiểu ngữ cảnh của sản phẩm hoặc dịch vụ
- Cần đánh giá xem hình ảnh lớn có đủ giá trị để chấp nhận mức độ phân tán mà chúng gây ra trên desktop hay không
- Cần gom các nội dung quan trọng có liên quan vào cùng một viewport
- Hãy cân nhắc thông tin nào liên quan nhất để hiểu những gì được cung cấp, rồi chọn thiết kế giúp giảm việc phải cuộn tới lui
- Cần hạn chế các tương tác và yếu tố thiết kế chỉ dành cho di động
- Nên giảm dùng accordion trên desktop
- Nên cân nhắc thiết kế thích ứng để hiển thị cùng nội dung theo cách thân thiện hơn với desktop
- Phù hợp hơn khi chỉ dùng sự phân tán một cách có giới hạn như một chiến lược để tập trung sự chú ý vào các điểm chính hoặc nội dung phức tạp
Kết luận
- Nội dung phân tán trên các trang desktop tối giản có thể giảm xao nhãng và giúp tập trung vào các điểm chính hoặc thông tin phức tạp
- Nhưng nếu toàn bộ trang được cấu thành theo mobile-first, chủ nghĩa tối giản và thiết kế thiên về hình ảnh, các vấn đề khả dụng trên desktop sẽ tăng mạnh
- Khi nội dung bị kéo dài và phân mảnh qua nhiều viewport, người dùng sẽ khó tiếp nhận và hiểu thông tin hơn
1 bình luận
Các ý kiến trên Hacker News
Danny O'Brien từng vận hành blog cũ Oblomovka, và khoảng năm 2007 đã đặt ra thuật ngữ hinternet
Khi đó, Internet là nơi vốn do giới tinh hoa công nghệ vận hành cho chính họ, nhưng người bình thường cũng bắt đầu bước vào; hinternet là quan niệm rằng có một Internet của công nghệ tinh tế và giá trị, tách biệt với một Internet của spam Viagra và banner pop-up
Trước đây, giới tinh hoa công nghệ gần như có thể tránh hinternet như tránh đi vào khu nguy hiểm, nhưng người bình thường không có cơ chế phân biệt như vậy nên có trải nghiệm Internet kém hơn rất nhiều
Giờ đây phần lớn Internet đã trở thành hinternet, và cả các hệ thống thiết yếu như ngân hàng, vay thế chấp mua nhà, thanh toán ô tô, hóa đơn tiện ích cũng được thiết kế theo kiểu mobile-first, dùng những thủ thuật tối tăm vốn hỏng trên các nền tảng mở với cái cớ “xác minh người dùng thật”
Nếu hinternet ngày xưa là một con hẻm âm u bán đồng hồ giả, thì hiện nay nó gần với một dystopia của sự tích hợp thông tin theo chiều dọc do các cơ quan gần như chính phủ vận hành phía sau; muốn đăng nhập IRS thì phải dùng nền tảng quản lý danh tính id.me, nơi còn bán cả hàng hóa
Vẫn có những nỗ lực chăm chút các khu vườn nhỏ tinh tế, nhưng mức độ thành công rất thất thường; với cá nhân thì ngoài những việc bắt buộc, gần như không có động lực tham gia hinternet
Nhìn từ góc độ này, “thiết kế web mobile-first” chỉ là một triệu chứng bị tách khỏi bối cảnh lớn hơn
Một bên là giới tinh hoa có học thức trong học thuật, quân đội, chính phủ, được xem là những nhà sáng lập chính đáng; bên kia là đại chúng tràn vào sau Eternal September
Rốt cuộc câu chuyện trở thành kiểu những người mới đến như con buôn, nhà đầu cơ, kẻ lừa đảo đã nhập tịch thành các công ty và ngân hàng của thế giới mới; nếu xem thời dot-com như một câu chuyện thuộc địa hóa, giới tinh hoa trở thành thổ dân bị đẩy khỏi đất của mình, và điều đó cũng rất hợp với lối tự sự ngày nay
Nhưng điều thiếu trong ngụ ngôn này là những người bình thường thực sự
Dot-com, Web 2.0 và quá trình xây dựng đế chế từ năm 1997 đến khoảng 2010 vẫn chủ yếu là chuyện tiền bạc và quyền lực cũ dịch chuyển lên Internet, với một số ít “doanh nhân” thô ráp bám theo ở vùng rìa; 99% còn lại vẫn là khán giả, rồi giờ đây như bị lùa vào trang trại
Khả năng về một Internet của mọi người vẫn còn, nhưng các vấn đề kinh điển như đi nhờ miễn phí và bi kịch tài nguyên chung hầu như chưa được giải quyết; ở thời điểm này “Web 3.0 và web blockchain” có vẻ đã chết
Muốn quay lại một Internet công cộng, chất lượng cao và rộng lớn, cần nhìn kỹ hơn vào lịch sử và các tự sự của Internet, cũng như ai mới là các bên liên quan thực sự
Không rõ đó là Internet thập niên 90 khó dùng, xoay quanh IRC và Usenet, hay là phần Internet ngầm của thập niên 90 với hosting miễn phí và nội dung bất hợp pháp
Tôi không thấy rõ Internet thập niên 90 với forum, IRC, spam Viagra và goatse giống với Internet ngày nay ra sao, khi nó đầy dark pattern và bị vài siêu công ty kiểm soát theo kiểu đã được khử trùng
Việc dùng di động không làm giảm mù chữ máy tính, mà còn làm tăng lên; kiểu như bấm nhầm liên kết, cài toolbar trình duyệt, rồi dần dần bị lây nhiễm bởi các dark pattern
Tôi khá thường thấy tình trạng này khi họ hàng liên hệ nhờ xử lý vấn đề máy tính
Mỗi khi dùng những cách diễn đạt như “phonish” hay “phonishness” là tôi luôn bị downvote, nhưng smartphone có cảm giác đã làm cuộc sống tệ hơn thay vì tốt hơn, và khiến con người phải phụng sự máy tính
Tôi mong chờ nền tảng tiếp theo
Ngoài hộp thư rác thì gần như không tiếp xúc, phần còn lại đều đã được tuyển lọc thành những khu vực “ổn” hoặc gần như các khu cư trú Internet đặc quyền
Có thể tôi không giàu tiền, nhưng giàu về tri thức; cấu trúc này trông giống một bi kịch tài nguyên chung, nơi tầng lớp mù công nghệ trở thành lá chắn thịt cho quảng cáo và các dịch vụ trả phí như YouTube
Theo thời gian, ngày càng rõ rằng frontend rất có thể là phần khó nhất trong stack
Mọi người nghĩ cứ làm qua loa một ứng dụng Bootstrap React là hoàn hảo, nhưng việc viết một UI phức tạp hoạt động được trên mọi trình duyệt, thiết bị, công nghệ hỗ trợ và ngôn ngữ là cực kỳ khó
Cần kiến thức sâu về HTML, CSS và các Web API liên quan, còn kỹ sư frontend giỏi thì rất hiếm ngay cả ở các công ty công nghệ lớn
UX designer nghĩ đến cả những điều này còn hiếm hơn, và những người như vậy đáng giá cả triệu đô
Cuối cùng tôi chuyển sang làm designer, vì nếu đằng nào cũng không được tôn trọng thì ít nhất tôi không cần phải tiếp tục chạy trên guồng máy học công nghệ mới nữa
Tôi cũng từng làm backend và nó cũng có cái khó riêng, nhưng nếu xét về tiền thì tôi sẽ chọn backend thay vì frontend
Sau khi làm cả design, backend và frontend, trong đầu tôi hình thành hai trục là sự công nhận và sự can thiệp
Design nhận được nhiều công nhận vì kết quả mang tính thị giác, nhưng ai cũng dễ dàng có ý kiến về “cách làm tốt hơn” và chen vào
Backend thì ngoài các kỹ sư khác ra không ai can thiệp, nhưng dù làm tốt thì nó chỉ chạy như thể vốn dĩ phải như vậy, nên khó được ghi nhận công lao
Frontend nằm ở giữa: nếu nhìn đẹp và chạy tốt thì được công nhận ở mức nào đó, nhưng ngay cả khi ứng dụng nhanh và phản hồi tốt, khoảng một nửa công lao đôi khi lại được tính cho designer
Đồng thời mọi người lấy các ứng dụng khác làm chuẩn và nói “nó phải hoạt động như thế này”, còn frontend developer phải bằng cách nào đó làm cho nó chạy được giữa những gì designer đã phê duyệt và những gì backend hỗ trợ
Họ mệt mỏi vì phải tranh cãi cả ngày với đồng nghiệp biết code nhưng không có cảm quan thiết kế, và những đặc điểm tạo nên một frontend engineer giỏi cũng giúp họ dễ chuyển sang các vai trò có chi phí tâm lý thấp hơn
Frontend developer phải đối mặt với con người chủ quan chứ không phải cỗ máy khách quan, phải làm việc với designer và product manager, đồng thời chịu ràng buộc từ backend engineer và hạ tầng
Họ phải làm cho nó chạy trên nhiều thiết bị và trình duyệt, dùng framework do người khác chọn, và không được làm hỏng bất cứ thứ gì
Xin gửi sự kính trọng đến mọi frontend developer
Mọi thứ đều có padding: văn bản có padding, hộp bọc văn bản cũng có padding, hàng bảng chứa hộp đó lại có padding còn lớn hơn
Kết quả là trên màn hình 1080p thông thường chỉ hiển thị được khoảng 4 hàng bảng, mà mỗi hàng gần như chẳng có thông tin thực sự nào
Hơn nữa, không hiểu vì lý do gì họ định nghĩa cỡ chữ theo chiều rộng viewport, khiến nó gần như không thể dùng được trên các màn hình 4:3 cũ
Hãy nghĩ đến những hệ thống phải xử lý hàng chục tỷ lượt theo ngày, tuần, tháng; phải làm caching dữ liệu, data warehouse, thông báo thời gian thực, khối lượng công việc hàng đợi, nhiều loại yêu cầu API, đồng bộ giữa các hệ thống backend, nhiều kho dữ liệu, mở rộng đa vùng, dự phòng, và cả ứng phó sự cố backend
Trong các phần mềm web phức tạp, những vấn đề backend như vậy là chuyện phổ biến
Frontend gắn với backend đó thường ít khi gặp sự cố lúc nửa đêm vì các tiến trình tự động của backend, hoặc phải lo về số lượng người dùng và quy mô dữ liệu
Dù phát triển frontend ban đầu hay bảo trì theo thay đổi của trình duyệt có khó đến đâu, sau khi phát triển xong thì nó là mã tĩnh giao tiếp với các hệ thống nền tảng phức tạp hơn nhiều, và các hệ thống nền tảng đó tiếp tục đòi hỏi sự chú ý mỗi khi dữ liệu và yêu cầu kinh doanh thay đổi
Vấn đề không phải mobile-first so với desktop, mà là các designer đến giờ vẫn chưa hiểu rằng web là nội dung động phải tự chảy theo kích thước và hình dạng màn hình của người dùng
Web không phải phương tiện tĩnh như giấy, cũng không bị ràng buộc vào một kích thước hay hình dạng cụ thể, nên không nên đối xử với nó như vậy
“Designer” web không nên cố ép nội dung khớp với một kích thước hay độ phân giải pixel cụ thể; vì độ phân giải màn hình và tỷ lệ ngang-dọc quá đa dạng, nội dung phải có khả năng chảy theo chúng
Với người dùng khiếm thị cần tăng cỡ chữ, nếu nội dung bị vỡ nghiêm trọng khi phóng to font thì khả năng tiếp cận sẽ giảm mạnh
Những trang như vậy cũng phải hoạt động trên trình duyệt mobile và desktop, và đều phải trông đẹp, nhưng việc đó không khó đến thế
Chỉ mất thêm chút thời gian, còn media query và một ít JavaScript giúp làm được điều đó
Đồng thời, ngay cả với người đã làm việc này lâu năm, đây vẫn là một lĩnh vực hỗn loạn
Dạo gần đây tôi tận dụng nền tảng thiết kế để tham gia tối đa vào giai đoạn thiết kế, rồi sau khi triển khai và phát hành thì nhận phản hồi kiểu “hãy báo cho tôi mọi thứ bị vỡ ở các viewport lửng lơ mà chỉ 1% người dùng dùng”, sau đó sửa trong giai đoạn review hoặc khi đang vận hành bằng các bản vá CSS và media query theo từng viewport
Có lý do khiến độ dài dòng văn bản trong mọi cuốn sách in nhìn chung khá giống nhau, và độ rộng đọc luôn phải được giới hạn
Chiều rộng có thể là 300px hoặc 1920px; người dùng có thể dùng chuột, chỉ dùng cảm ứng, dùng cả hai, hoặc không dùng cái nào
Menu hamburger và biểu tượng tượng hình
Tôi hiểu vì sao chúng được dùng trên di động
Nếu chỉ còn chỗ cho nội dung, việc để một số ít chức năng dưới dạng biểu tượng nhỏ và giấu các thao tác còn lại trong menu hamburger là hợp lý
Nhưng nếu có đủ không gian mà vẫn dùng như vậy thì thật tệ
Nhẹ thì làm tăng số bước, nặng thì khiến người dùng phải thử nghiệm để đoán biểu tượng làm gì và dễ gây sự cố
Nếu hoàn tác hoạt động đúng thì còn đỡ, nhưng có vẻ người ta đã quyết định rằng ngay cả thứ đó hỏng cũng được
Như Apple HIG ngày trước, trên desktop nên đưa các thao tác hay dùng ra khỏi menu và đặt vào nút có nhãn, để người dùng có thể trả lời “mình có thể làm gì?” mà không phải chơi trốn tìm
Hoàn tác rất khó thêm vào về sau, nên cần xây sẵn từ đầu để giảm cái giá của việc thử nghiệm
Đáng tiếc là thiết kế di động đã chiếm lĩnh quá triệt để, đến mức dù ứng dụng gần như chắc chắn sẽ được dùng trên desktop và trong nội bộ có người ủng hộ thiết kế desktop, nhà thiết kế UI vẫn chọn hamburger, biểu tượng tượng hình và hoàn tác bị hỏng
Hơn nữa modal cũng đã quay lại dữ dội, nhưng vì huyết áp nên tôi phải dừng ở đây
Ngay cả một điện thoại giá rẻ 5 năm tuổi như moto e4 cũng có màn hình 1280x720, và có thừa pixel để gắn nhãn cho biểu tượng
Biểu tượng tượng hình gần như là kiểu thiết kế nói rằng “chúng tôi ghét người dùng và muốn họ biết điều đó”
Menu hamburger cũng thường có thể bỏ được nếu nhìn vào số lượng tùy chọn
Ứng dụng Gmail hoàn toàn có thể đưa biểu tượng vào một thanh ngang nhưng vẫn dùng hamburger; trong khi nếu nói không gian quan trọng thì họ lại vẫn nhét thêm thanh dưới cho chat, video và Spaces
Tôi hơi lo người dùng có thể không nhận ra còn tùy chọn để cuộn tiếp, nhưng vẫn thích cách này hơn menu hamburger mở ra rồi che nội dung
Vì người dùng có thể thấy mọi tùy chọn và chữ tương ứng của chúng
Trên desktop thì không cần xử lý kiểu này
Tuy vậy, tôi nghĩ lý do các nhà thiết kế thích chúng là vì dễ giữ thiết kế nhất quán giữa nhiều ngôn ngữ
Ví dụ bản địa hóa tiếng Đức có thể khó căn cho vừa
Tôi cũng muốn thêm vào đây các tùy chọn phụ thuộc ngữ cảnh bị ẩn
Tùy chọn bị vô hiệu hóa, tức được tô xám, khi không dùng được ít nhất cũng cho thấy có khả năng làm được điều gì đó nếu điều kiện phù hợp
Nhưng thiết kế hiện đại lại giấu những tùy chọn đó đi, và nếu không biết điều kiện ma thuật để chúng hiện ra thì bạn sẽ không bao giờ thấy chúng
Unifi của Ubiquiti là một ví dụ
Trên trang quản lý cổng switch không có tùy chọn “Select All”; bạn phải chọn ít nhất một cổng trước thì tùy chọn đó mới xuất hiện như phép màu
Không chỉ bị ẩn, ngữ cảnh cũng sai
Nếu nó là một ô chọn bị vô hiệu hóa, mọi người đã lập tức nhận ra rõ ràng rằng việc ô chọn “Select All” bị vô hiệu khi chưa chọn cổng nào là ngu ngốc
Họ dễ bị choáng nếu trên màn hình có quá nhiều thứ, và chính họ là những người chi phối các focus group
Vì thế có vẻ các nhà thiết kế đã bị trói vào một quy tắc khủng khiếp duy nhất này
Nghiên cứu này không hợp lý về mặt thực dụng
Những trang đó không được thiết kế để truyền đạt tối đa thông tin trong tối thiểu không gian, mà được thiết kế để bán sản phẩm
Nếu muốn khẳng định việc phân tán nội dung có tác động tiêu cực, phải đo theo mục tiêu mà trang đó được thiết kế để đạt được
Ở đây nghiên cứu nêu rõ là về trang thương mại điện tử/sản phẩm, nên các chỉ số liên quan phải là trang nào khiến người xem cảm nhận giá trị sản phẩm cao hơn, có tỷ lệ chuyển đổi cao hơn, NPS cao hơn, hoặc tạo thiện cảm thương hiệu tốt hơn
Loa di động không được bán bằng thông số kỹ thuật, mà bằng hình ảnh đáng khao khát khi dùng trên bãi biển
Nếu mở sẵn accordion chi tiết sản phẩm rồi hỏi “bạn cảm thấy mình hiểu đề xuất mà trang này truyền đạt tốt đến mức nào?” thì điểm khảo sát cao hơn là chuyện đương nhiên
Nếu trang dày đặc thông tin hơn lại chuyển đổi tốt hơn thì mới đáng ngạc nhiên
Điều này giống như thiết kế một nghiên cứu nói rằng ghế cứng của xe đua F1 là tệ, rồi dán đầy mút lên và kiểm tra bên nào thoải mái hơn, sau đó tuyên bố nó tốt hơn vì điểm thoải mái cao hơn, trong khi chỉ số gốc duy nhất là thời gian chạy một vòng
Những lựa chọn thiết kế mà bài viết phê phán không phải là kết quả của thiết kế ưu tiên di động
Thực tế là các website cuối thập niên 2000, trước khi thiết kế responsive trở nên phổ biến, cũng trông như vậy
Ví dụ Apple: https://www.versionmuseum.com/history-of/apple-website
Về cơ bản là so sánh mật độ thông tin của tờ rơi tiếp thị hoặc biển quảng cáo rồi nói rằng chúng không truyền đạt được mọi thứ, trong khi đó chính là mục đích
Quảng cáo không phải là bảng thông số, mà là để khơi gợi ham muốn với sản phẩm ở người xem
Nhưng với tôi thì ngược lại, nó có thể là tín hiệu mạnh của những lời nhảm nhí chất lượng thấp
Rất nhiều website thay đổi hoàn toàn UI khi thay đổi kích thước cửa sổ
Có lúc tôi muốn để trình duyệt chỉ chiếm nửa màn hình và đặt thứ khác bên cạnh, nhưng trên các website hiện đại, khi thu nhỏ cửa sổ thì UI trở nên không dùng được, nên việc này thường thất bại
Làm tốt thì tuyệt, nhưng bạn cũng nói đúng rằng nhiều website hành xử quá mạnh tay, như thể họ chỉ thật sự kiểm thử hai nhóm kích thước
Ý bạn là khi thu nhỏ khung nhìn thì không còn truy cập được chức năng và nội dung nữa sao?
Tôi ghét các website đặt nội dung hữu ích vào một cột mỏng ở giữa
Tệ hơn nữa là cả những website trước đây bình thường cũng dần bị phá hỏng
Thường là khi có quản lý mới vào và muốn “tái tưởng tượng” sản phẩm theo tầm nhìn “ưu tiên di động”
Patreon gần đây là một ví dụ điển hình
Và trong một số trường hợp, website bình thường biến mất hẳn rồi bị thay bằng crapp như Venmo, Amazon Alexa, Chamberlain
Điều thật sự gượng gạo là không có một phương án cảm ứng nào đủ tốt tương ứng với hover
Đây là một yếu tố UX quá hữu ích để bỏ đi khi chuyển sang mobile-first
Ngoài chuyện đó thì mọi thứ gần với mức “không khó đến vậy” hơn
Trong số các vấn đề cần giải quyết, việc làm cho giao diện trông ổn trên nhiều kích thước màn hình nằm khá thấp về thời gian và độ phức tạp
Ít nhất tôi dùng như vậy khi xem văn bản thay thế của ảnh trên Firefox di động
Có lẽ vẫn có thể phát hiện hover thật sự, nhưng trừ khi dùng bút stylus thì UX có vẻ không hay lắm
Ở góc nhìn một nhà thiết kế web, tôi hơi không đồng ý
Các ví dụ trong bài hoạt động tốt hơn khi nội dung trên mỗi màn hình đơn giản
Dễ nắm bắt về mặt thị giác, còn phiên bản nén thì có nhiều bố cục nhiều cột mà cá nhân tôi không thích
Mật độ nội dung cao phù hợp với ứng dụng desktop, nhưng không hợp với những nơi về cơ bản là website brochure
Điều hay là đây không chỉ là cảm nhận của ai đó
Khó tin rằng sau hàng chục năm tiến hóa và thử nghiệm, các trang marketing vẫn chưa đạt tới thứ người dùng thật sự muốn, thay vì thứ họ nói là họ muốn
Với những người lớn lên cùng Internet, cuộn trang là hành vi rất tự nhiên
Việc tận dụng màn hình lớn để so sánh trực quan cũng hữu ích, nhưng ví dụ trong bài thì không tốt
Bài nói “đặt cùng một thông tin vào lưới 2x2 để so sánh nhiều dịch vụ cùng lúc”, nhưng tôi không rõ có gì để so sánh
Chúng là các dịch vụ khác nhau
Tôi thích ví dụ về thông số sản phẩm, nhưng đó gần với một vấn đề usability khách quan hơn, khi buộc người dùng phải nhấp nhiều hơn để xem thêm thông tin
Cần thấy rằng ảnh chụp màn hình đã được “thu nhỏ”, nên bố cục nhiều cột trông phong phú và hấp dẫn hơn về mặt thị giác
Tôi hoàn toàn ủng hộ việc tận dụng không gian ngang, nhưng những gì chúng ta học được về nút kêu gọi hành động lại dẫn đến thiết kế một yếu tố duy nhất
So với các website brochure hay thương mại điện tử, thiết kế mobile-first trong các site năng suất và giao diện công cụ còn gây khó chịu hơn
Thường thì ai lại truy cập những công cụ như vậy bằng điện thoại chứ
Việc nhập tên và địa chỉ của các nơi từng làm việc và cư trú bằng bàn phím di động đã khổ, nhưng nhập ngày tháng còn tệ hơn
Vì bộ chọn ngày bắt đầu từ tháng và năm hiện tại rồi chỉ cuộn từng tháng một, nên để nhập ngày sinh phải chạm khoảng 550 lần
Tôi cũng muốn báo cáo lên EEOC vì việc này ảnh hưởng không cân xứng tới nhóm lao động lớn tuổi, vốn là nhóm được bảo vệ, nhưng đó không phải là cách hay để giới thiệu bản thân với HR của nhà tuyển dụng mới
Trên thực tế nó trở thành giống như chế độ xem màn hình nhỏ, và đây là yêu cầu của WCAG