Đang tải…
Đang tải…
Điều hướng của site này trên điện thoại không có header. Chỉ có một thanh dock sát đáy màn hình, và quyết định khó nhất là con số 4.

Điện thoại mở site này ra thì không có thanh nav trên cùng. Không phải nó bị ẩn khi cuộn, mà là nó không tồn tại. Toàn bộ việc điều hướng nằm ở một thanh dock sát đáy màn hình.
Lý do không phải thẩm mỹ. Nó nằm ở chỗ ngón tay cái với tới đâu.
Cầm điện thoại một tay, ngón cái vẽ ra một hình cung. Vùng thoải mái nhất của cung đó nằm ở nửa dưới. Góc trên bên trái, chỗ mà quy ước web đặt logo và nút menu, lại là điểm xa nhất.
Ứng dụng native đã giải bài này từ lâu bằng tab bar dưới đáy. Web thì phần lớn vẫn bê nguyên header của desktop xuống rồi thu nhỏ lại, vì đó là thứ CSS dễ viết nhất.
Chi tiết làm thanh dock đọc ra như một ứng dụng thật, thay vì như một thanh nổi của web, là nó tràn hết chiều ngang: không lề hai bên, không bo góc, và phần đệm cho vùng an toàn của máy nằm bên trong thanh chứ không nằm dưới nó. Một thanh có lề và bo góc luôn trông như một widget đang trôi trên trang.
/**
* Route tabs hiển thị thẳng trong thanh. PHẢI giữ số chẵn: cái orb ở
* giữa chia đôi hàng, số lẻ sẽ làm thanh lệch hẳn sang một bên.
*/
const DOCK_SLOTS = 4;
Ở giữa thanh có một nút tròn nổi lên, và nó chia hàng làm hai nửa. Bốn tab thì mỗi bên hai, cân. Năm tab thì một bên hai một bên ba, và mắt nhận ra ngay, dù ít ai nói được là lệch ở chỗ nào.
Ràng buộc này không thể hiện ở đâu ngoài comment kia. Không có kiểu dữ liệu nào bắt được nó, không có test nào đỏ lên. Người thêm tab thứ năm sáu tháng sau sẽ chỉ thấy thanh trông hơi kỳ. Đó là lý do comment được viết bằng chữ in hoa.
Và đây là chỗ bài toán trở nên thú vị. Một trang portfolio có hai loại đích đến khác hẳn nhau.
Loại thứ nhất là route thật: blog, thuật toán, công cụ, câu đố. Loại thứ hai là các mục của trang chủ, thứ mà trên desktop bạn cuộn tới bằng anchor. Trên desktop cả hai cùng nằm trên một hàng ngang và không ai thắc mắc. Trên một thanh bốn ô thì không nhét được.
Nút tròn ở giữa giải chuyện đó. Chạm vào là mở một tấm sheet chiếm hết màn hình, trong đó các mục trang chủ trở nên chạm tới được, còn các route explore nằm dưới dạng thẻ có màu riêng từng module. Bốn ô trong thanh dành cho những nơi hay lui tới nhất; phần còn lại nằm sau đúng một cú chạm.
Thứ nhất, sheet mở ra thì mã nguồn bắt đầu nạp trước chỉ mục tìm kiếm:
const { prime: primeSearch } = useSearch();
Hàng tìm kiếm nằm ngay trong sheet, cách một cú chạm nữa. Bắt đầu tải lúc sheet mở nghĩa là tới lúc người dùng thật sự gõ thì dữ liệu thường đã sẵn. Người dùng không thấy gì cả, và đó chính là mục đích.
Thứ hai, sheet có bẫy tiêu điểm bàn phím. Một lớp phủ toàn màn hình mà không giam tiêu điểm lại thì người dùng bàn phím sẽ tab ra khỏi nó, đi lang thang trong đám link vẫn còn ở trang phía dưới, và không hiểu tiêu điểm đang ở đâu. Đây là thứ dễ quên nhất khi làm overlay, vì bằng chuột thì không bao giờ lộ ra.
Thanh dock tự ẩn khi cuộn xuống và hiện lại khi cuộn lên. Nghe hợp lý: trả màn hình lại cho nội dung.
Thực tế nó khiến điều hướng thành thứ chập chờn. Bạn cuộn tìm cái gì đó, muốn đổi trang, và thanh không có ở đó; phải cuộn ngược lên một chút để gọi nó ra. Nếu làm lại từ đầu mình sẽ để nó đứng yên và chấp nhận mất khoảng năm mươi pixel. Một thanh điều hướng luôn ở đúng chỗ đáng giá hơn khoảng trống nó chiếm.
Chưa có bình luận nào — hãy là người đầu tiên!