Các mẫu điều hướng iOS hiện đại

 (frankrausch.com)
6 điểm bởi GN⁺ 2023-12-13 | 3 bình luận | Chia sẻ qua WhatsApp
  • Điều hướng trong ứng dụng iOS cần phân tách rõ ràng giữa hệ phân cấp, overlay và luồng bên trong view để người dùng hiểu vị trí hiện tại và đường quay lại
  • Các mẫu cấu trúc gồm Drill-Down, Flat, Pyramid và Hub-and-Spoke; mỗi mẫu mang ý nghĩa chuyển màn hình khác nhau, như duyệt cây, phân chia dựa trên tab, di chuyển giữa các màn hình ngang cấp, hay quay về hub
  • Overlay là cơ chế để thu hút sự chú ý, nhưng tùy theo có modal hay không và mức ma sát, mức độ chặn màn hình phía sau và hành động người dùng cần thực hiện sẽ khác nhau
  • Điều hướng nhúng nên nằm trong một view hoặc modal cụ thể, và cần được thiết kế để thay đổi trạng thái hoặc luồng Step-by-Step không trông giống như di chuyển trong hệ phân cấp
  • Tab phải có tính dự đoán được; Cancel không nên lập tức xóa dữ liệu; trong ứng dụng iOS, việc duy trì ranh giới rõ ràng giữa hệ phân cấp, trạng thái và modal phù hợp hơn so với di chuyển tùy ý

Ba trục của điều hướng iOS

  • Ứng dụng iOS thường được cấu thành từ nhiều tầng của một cây phân cấp cố định
  • Điều hướng cấu trúc có vai trò giúp người dùng hiểu họ đến từ đâu, đang ở đâu trong hệ phân cấp, và làm thế nào để quay lại vị trí ban đầu
  • Overlay có thể xuất hiện trên bất kỳ ngữ cảnh nào, và cũng có thể hiển thị chồng lên overlay khác
    • Overlay modal không biến mất cho đến khi người dùng thực hiện hành động, và chặn giao diện phía sau
    • Overlay không modal không chặn ứng dụng
  • Điều hướng nhúng phù hợp hơn khi được đưa vào trong một view cụ thể hoặc overlay modal, theo đúng mô hình cấu trúc và không gian của iOS

Các mẫu điều hướng cấu trúc

  • Drill-Down

    • Drill-Down là mẫu duyệt cấu trúc cây của thông tin bằng các danh sách theo từng cấp
    • Chuyển cảnh bằng animation gợi ý chuyển động ngang giữa các cột
      • Di chuyển sang phải là thao tác đi sâu hơn vào một cấp của cây phân cấp
      • Di chuyển sang trái là thao tác quay lại cấp trên
    • Điều hướng Drill-Down có cấu trúc modeless, nên các câu hỏi như có lưu hay không sẽ không làm gián đoạn việc duyệt hệ phân cấp
    • Navigation Bar hiển thị tiêu đề của màn hình hiện tại, còn Disclosure indicator trong hàng của danh sách cho thấy có thể đi vào cấp sâu hơn
    • Nút Back là đường quay lại rõ ràng về cấp trên; nếu không gian cho phép, nên dùng tiêu đề của màn hình cha làm nhãn thay vì “Back” chung chung
    • Thao tác vuốt từ mép trái màn hình sang phải có cùng vai trò với nút Back
    • Triển khai tùy chỉnh nên cung cấp chuyển cảnh có thể tương tác và có thể hủy, được điều khiển bằng screen-edge pan gesture như chuẩn iOS
    • Với các ngôn ngữ đọc từ phải sang trái, hướng điều hướng và vị trí điều khiển được phản chiếu theo hướng đọc
    • Cấu trúc cây có thể được tạo động để lọc cơ sở dữ liệu
      • Trong ứng dụng nhạc, có thể Drill-Down đến cùng một album từ các điểm bắt đầu khác nhau như Artist, Album, Genre, đồng thời cũng có thể dùng giao diện tìm kiếm
    • Drill-Down là biến thể một cột trên mỗi màn hình của Miller columns kiểu macOS Finder

  • Flat

    • Mẫu Flat chia hệ phân cấp ở cấp root và hiển thị bằng tab bar
      • Trên iPad, có thể hiển thị bằng sidebar
    • Các mục trên tab bar được chọn lọc quanh những chức năng chính của ứng dụng, từ đó hình thành kỳ vọng của người dùng và mô hình tinh thần về ứng dụng
    • Một mục trên tab bar luôn được chọn, và lựa chọn đang hoạt động quyết định nội dung được hiển thị trong vùng nội dung chính của ứng dụng
    • Mục tab bar đang được chọn không nên bị thay đổi bằng lập trình mà không có tương tác của người dùng, hoặc bị thay đổi gián tiếp bằng cách chạm vào một nút khác trong giao diện
    • Tab bar luôn hiển thị trên toàn bộ màn hình ứng dụng, ngoại trừ khi bị che tạm thời bởi modal sheet
    • Tab có thể được dùng làm bộ lọc hoặc làm các điểm vào khác nhau cho những bộ sưu tập nội dung lớn như thư viện nhạc, video, ảnh
    • Mỗi section duy trì trạng thái điều hướng của hệ phân cấp con riêng
    • Các mục trên tab bar phải hoạt động theo cách có thể dự đoán được, và không nên mở sheet hay thực thi hành động
    • Menu hamburger là kiểu điều hướng ẩn trái ngược với tab bar
      • Khi toàn bộ giao diện điều hướng bị ẩn sau một biểu tượng nhỏ, khả năng khám phá sẽ giảm
      • Khoảng năm 2015, kiểu này từng phổ biến trên iOS, nhưng sau khi có các nghiên cứu cho thấy tab bar dễ được phát hiện hơn nhiều, các nhà làm ứng dụng đã từ bỏ menu hamburger

  • Pyramid

    • Mẫu Pyramid cho phép di chuyển nhanh giữa các view ngang cấp trong cùng một tầng phân cấp mà không cần quay lại màn hình cha
    • Trong ứng dụng media, cử chỉ vuốt ngang thường được dùng để di chuyển giữa các view ngang cấp
    • Cũng có thể dùng nút, như các nút mũi nhọn Next Message và Previous Message trong ứng dụng iOS Mail
    • Ứng dụng iOS Photos là một ví dụ của mẫu Pyramid
      • Sau khi chạm vào một ảnh để mở toàn màn hình, người dùng vuốt trái/phải để chuyển qua các ảnh liền kề
    • Với các bộ sưu tập nhỏ, dùng page control để trực quan hóa tổng số mục và vị trí của mục hiện tại giữa các mục ngang cấp
    • iOS App Switcher triển khai mẫu Pyramid để di chuyển nhanh giữa các ứng dụng, cung cấp điều hướng nhanh hơn so với đi qua màn hình Home

  • Hub-and-Spoke

    • Mẫu Hub-and-Spoke phù hợp khi ở cấp cao nhất của hệ phân cấp có các bộ sưu tập lớn không liên quan với nhau
    • Để chuyển giữa các view con toàn màn hình, luôn phải quay về hub trước
    • Màn hình Home của iOS là bộ sưu tập tất cả ứng dụng đã cài đặt, đồng thời đóng vai trò trạng thái trung lập đáng tin cậy của hệ điều hành
    • Home indicator ở cạnh dưới màn hình là lối thoát dễ học và luôn sẵn có, đưa người dùng trở lại giao diện màn hình Home quen thuộc
    • Mẫu này hầu như không được dùng bên trong ứng dụng
      • Hiếm khi bên trong một ứng dụng lại cần sự tách biệt mạnh như giữa các ứng dụng ở cấp hệ điều hành

Điều hướng bằng overlay

  • High-Friction Modal

    • Overlay High-Friction Modal chặn màn hình phía sau cho đến khi người dùng đưa ra quyết định, chẳng hạn như sheet hoặc hộp thoại cảnh báo có nhiều hành động
    • Khi soạn email hoặc tạo sự kiện lịch, người dùng cần lựa chọn tiếp tục bằng Done hoặc Send, hoặc đổi ý bằng Cancel
    • Nút Cancel không nên trực tiếp loại bỏ bất kỳ trạng thái hay dữ liệu nào
      • Khi chạm Cancel trong modal sheet, luôn nên hiển thị thêm hộp thoại xác nhận như một lớp bảo vệ
      • Trong hộp thoại cảnh báo, Cancel tuyệt đối không được là hành động phá hủy
    • Modal tập trung vào việc hoàn thành một tác vụ cụ thể và độc lập, như soạn email hoặc thêm sự kiện lịch

  • Low-Friction Modal

    • Low-Friction Modal chặn phần còn lại của ứng dụng như sheet, menu hoặc popover, nhưng không yêu cầu quyết định “một trong hai”
    • Cần dễ đóng, chẳng hạn bằng cách nhấn nút đóng hoặc vuốt sheet xuống
    • Chạm bên ngoài context menu hoặc popover sẽ làm nó biến mất
    • Hộp thoại cảnh báo chỉ có một nút OK dễ đóng, nhưng ma sát thấp không đồng nghĩa với không có ma sát
    • Nên tránh cảnh báo chỉ có một hành động nếu có thể
      • Chúng làm gián đoạn luồng người dùng, và trong nhiều trường hợp có thể thay bằng văn bản inline hoặc thông báo không modal

  • Non-Modal

    • Overlay Non-Modal che một phần màn hình nhưng không chặn giao diện phía sau
    • Vì là cách không chặn, nó gần như không có hoặc hoàn toàn không có ma sát
    • Có thể xuất hiện để phản hồi trigger bên ngoài ứng dụng, như thông báo của hệ điều hành
    • Nếu tự động biến mất, nó nên cung cấp thông tin ngoại vi có thể xem nhanh với mức gián đoạn tối thiểu
    • Overlay không modal tạm thời có thể có tương tác tùy chọn
      • Có thể chạm vào thông báo, hoặc vuốt chỉ báo âm lượng trước khi nó biến mất để thay đổi âm lượng
    • Overlay không chặn phần còn lại của ứng dụng và cũng không tự động xuất hiện hay biến mất có thể được gọi là palette

Điều hướng nhúng

  • State Change

    • Một view có thể có nhiều trạng thái
    • View danh sách có thể có các trạng thái empty, loading, populated mà không trông như vị trí trong hệ phân cấp điều hướng đã thay đổi
    • Cần đảm bảo rằng thay đổi trạng thái không thực sự mang tính phân cấp hay modal
    • Với thay đổi trạng thái tại chỗ, nên tránh chuyển cảnh toàn màn hình
    • Ví dụ gồm chế độ chỉnh sửa của danh sách, giao diện trình duyệt web, bản đồ đường phố có thể pan, và ảnh có thể phóng to
    • Tùy chọn view chỉ thay đổi cách hiển thị nội dung mà không thay đổi vị trí của người dùng
      • Chuyển giữa list view và thumbnail view là toggle giữa hai cách trực quan hóa khác nhau của cùng một thông tin trong cùng một ngữ cảnh

  • Step-by-Step

    • Mẫu Step-by-Step kết nối một chuỗi màn hình thành một luồng tuyến tính, như tour hướng dẫn, luồng thiết lập hoặc tutorial onboarding
    • Những quy trình cần nhập nhiều dữ liệu, như thanh toán trong cửa hàng trực tuyến, cũng cần nhiều bước
    • Di chuyển tiến/lùi trong trình tự không làm thay đổi cấp phân cấp; đây là điểm khác với mẫu Drill-Down
    • Chuỗi Step-by-Step nên được hiển thị trong một overlay modal
      • Trong ngữ cảnh này, nút Back có mục đích khác với nút Back của Drill-Down phân cấp
    • Quy trình thường được hoàn tất bằng nút Done hoặc Close, và nút này cũng đóng modal chứa nó
    • Số bước và đường đi có thể thay đổi tùy theo tùy chọn đã chọn
    • Wizard và assistant là những tên gọi khác của mẫu này
    • Quy trình Step-by-Step có thể tạo cảm giác nhàm chán
      • Nếu dự kiến người dùng sẽ thực hiện thường xuyên, có thể cân nhắc kết hợp nhiều bước thành các trạng thái khác nhau trong một view để tăng mật độ thông tin và giảm chuyển đổi ngữ cảnh

  • Content-Driven

    • Điều hướng Content-Driven là cách hyperlink hoặc nút đưa người dùng tức thì sang trang hoặc view khác
    • Điều hướng web trong trình duyệt hoạt động theo cách này
    • Trong ứng dụng iOS, tốt hơn nên tránh mẫu này, ngoại trừ các ứng dụng hiển thị hypertext, game nhập vai nhập vai sâu, hoặc nội dung phi tuyến tính tương tự
    • Nếu ứng dụng cần hiển thị nội dung hypertext, có thể cân nhắc đưa nó vào trong giao diện trình duyệt có điều khiển back/forward
    • Thay đổi trạng thái trong một giao diện trình duyệt độc lập dễ hiểu hơn việc vị trí trong hệ phân cấp ứng dụng thay đổi ngoài dự đoán
    • Có thể dùng link để di chuyển giữa các ứng dụng
    • Deep Links dùng URL scheme hoặc Universal Links gắn với domain để đưa người dùng từ một ứng dụng hoặc website sang tầng sâu trong ứng dụng khác

Tài liệu tham khảo

Bài viết liên quan

3 bình luận

 
GN⁺ 2023-12-13
Ý kiến trên Hacker News

  • Đây là chuyện đã được nói nhiều rồi, nhưng việc dùng tốt những pattern như thế này là một trong nhiều lý do khiến Apollo vượt xa ứng dụng Reddit chính thức
    Điều hướng, cử chỉ và hành vi đều nhất quán, mà các khái niệm này cũng không khó. Chỉ cần quan tâm đủ để tuân thủ là được, nhưng quá nhiều ứng dụng không làm vậy nên thật nản

    • Đây là khác biệt giữa một ứng dụng được tối ưu để trở thành ứng dụng tốt và một ứng dụng được tối ưu cho mức độ tham gia và doanh số
      Nó giống như siêu thị định kỳ thay đổi cách sắp xếp kệ hàng. Nếu điều hướng, cử chỉ và hành vi nhất quán, người dùng có thể lấy thứ họ muốn quá hiệu quả rồi rời đi
    • Tôi chưa từng thấy ứng dụng nào gây rối như ứng dụng Reddit chính thức, và tôi nghĩ trí thông minh của mình ở mức bình thường
      Tôi điều hành một subreddit 30.000 người nên cần dùng Reddit trên điện thoại, nhưng gần như là không thể. Mọi thao tác đều cần quá nhiều bước, không biết mình đang ở đâu, nên đúng là rác
    • Cách Steve Huffman hủy Apollo và làm hỏng Reddit thật sự là một điều đáng xấu hổ
      Tôi đã bỏ Reddit từ vài năm trước, nhưng chuyện này là chiếc đinh cuối cùng đóng vào quan tài
    • Ứng dụng Reddit chính thức là một trong số ít ứng dụng mà tôi thường xuyên bị lạc
      Việc quay lại màn hình chính tốn quá nhiều năng lượng tinh thần đến mức tôi chỉ cưỡng ép thoát rồi mở lại
    • Ngay cả trong Apollo, bạn cũng có thể mở các lớp như subreddit, hồ sơ người dùng, bài viết bằng cách xếp chồng vô hạn, nên cũng có thể gây rối
      Chỉ sau vài tầng, để quay lại màn hình đầu tiên thì phải tiếp tục vuốt hoặc bấm quay lại cho đến khi tới đó, khá phiền. Có lẽ có một cử chỉ ma thuật nào đó mà tôi chưa biết

  • Tôi rùng mình khi thấy cụm “pattern điều hướng iOS”. Không hề có pattern, và đây là một trong những điểm tệ nhất của iOS so với Android
    Trên Android, quay lại rất dễ và có thể mang nhiều nghĩa. Tôi đã dùng iOS hơn một năm, và tôi sẽ nhắm mắt thử một trong hai “pattern” quay lại, rồi cuối cùng đi tìm một nút ở nơi tay không với tới. Vậy mà đôi khi vẫn không được
    Đừng phó mặc pattern cho nhà phát triển, mà phải sửa ở cấp hệ điều hành. Nhà phát triển không muốn người dùng rời khỏi một phần của ứng dụng. Cứ thử quay lại trong Instagram Reels là thấy

    • Việc “trên Android, quay lại rất dễ và có thể mang nhiều nghĩa” với tôi lại là một trong những điểm tệ nhất của Android
      Nút quay lại hoàn toàn không nhất quán về việc nó sẽ làm gì. Ngay cả là nhà phát triển, tôi cũng phải suy nghĩ trong một số tình huống xem quay lại nên làm gì. Nên về màn hình trước đó, hay đi lên một cấp trong điều hướng drill-down thì rất mơ hồ; đôi khi hai thứ đó giống nhau, nhưng không phải lúc nào cũng vậy
      Có lúc nó đi lên một cấp trong cấu trúc điều hướng, có lúc về màn hình trước, có lúc đóng hộp thoại, thậm chí đóng cả ứng dụng. Tùy ngữ cảnh, hành vi nào cũng có thể xảy ra, và nếu nhiều hành vi cùng áp dụng thì không rõ là cái nào. Cách duy nhất để biết là bấm thử rồi xem chuyện gì xảy ra
      Tôi ghét các thành phần giao diện người dùng mơ hồ. Khi nhấp vào thứ gì đó, tôi muốn biết hành động nào sẽ được thực hiện
    • Trải nghiệm activity stack của Android là phần tôi thích nhất trong thiết kế hệ thống
      Nó tạo ra sự nhất quán sâu sắc, khiến điều hướng không còn vất vả. Giá mà iOS cũng được tích hợp theo cùng cách thì tốt biết mấy
      Activity stack hoạt động xuyên qua các ứng dụng, nên dù nhiều ứng dụng cùng xử lý một tác vụ, cử chỉ quay lại luôn đưa bạn về ngay màn hình trước đó
    • Tôi không hiểu vì sao nút quay lại của iOS lại rải rác khắp nơi như vậy
      Có lúc ở góc trên bên trái, có lúc ở góc dưới bên trái, có lúc ở góc dưới bên phải, và chắc cũng có ứng dụng đặt ở chỗ khác
      Android có nút quay lại cấp hệ điều hành luôn với tới được ngay cả khi dùng một tay. Cách này vượt trội hơn nhiều
    • Việc “đừng phó mặc pattern cho nhà phát triển mà hãy sửa ở cấp hệ điều hành” có lẽ là điều Apple không làm vì về thực tế gần như bất khả thi
      Ví dụ, nếu có thể thay đổi nội dung của một view, bạn cũng có thể xóa toàn bộ nội dung và thay bằng nội dung hoàn toàn mới. Nếu điều này xảy ra do một hành động nào đó của người dùng, thì về bản chất nó giống như “chuyển sang màn hình mới”. Nhưng nếu nhà phát triển không dùng lệnh gọi API hệ điều hành được đề xuất là createNewView mà chỉ thay đổi nội dung của view hiện tại, thì cử chỉ cấp hệ điều hành sẽ không hoạt động
      Tuy nhiên, Apple có thể bắt buộc dùng API hệ điều hành này để được qua xét duyệt. Dù vậy, tôi nghĩ việc cái gì là “view mới có thể quay lại” và cái gì là “view cũ chỉ thay đổi nội dung” vẫn có phần chủ quan
    • Menu chia sẻ là thứ tệ nhất. Tôi không biết người ta phải tự tìm ra cách dùng nó như thế nào
      Nó hiển thị danh bạ, ứng dụng, các mục theo chiều dọc, các mục theo chiều ngang, các mục khác ở phía dưới, và hơn nữa chỉ hiện ra sau khi bạn tự nhận ra rằng phải kéo lên. Mỗi ứng dụng đặt ở vị trí khác nhau, biểu tượng cũng chẳng liên quan gì đến “chia sẻ” hay “sao chép/dán”
      Những người lớn lên cùng smartphone thì như mọi khi vẫn có thể thích nghi. Nếu khi nó được giới thiệu bạn chưa quá 40–50 tuổi thì nhìn chung vẫn thích nghi được. Phần lớn những thứ hiện đại được thiết kế tệ hại và thường không ổn định. AppleTV cũng vậy; kiểu như, hãy thử nói chuyện đổi mật khẩu Wi‑Fi xem. Tôi không hiểu vì sao nút bật/tắt lại không khởi động lại thiết bị, dù việc đó cần để né lỗi

  • Không chắc mức độ liên quan có đủ hay không, nhưng trên Mac và giờ là iPadOS(https://useyourloaf.com/blog/ipad-customizable-toolbars/), các điều khiển thanh công cụ tích hợp hỗ trợ mức độ tùy biến cao
    Có thể thử trong nhiều ứng dụng native, bao gồm Finder
    Các widget tích hợp mạnh mẽ là một yếu tố bị đánh giá thấp trên desktop Mac, và cũng là điều khiến tôi lo lắng khi SwiftUI ngày càng chiếm lĩnh. Đây cũng là một lợi thế lớn trên iOS, nhưng vì các app quá thường muốn khoác lên thiết kế riêng của mình nên nó tương đối ít nổi bật hơn
    Nhưng không biết có phải tôi nhớ nhầm không, dường như các app iOS ngày trước từng hỗ trợ tùy biến thanh tab mặc định. Rõ ràng nó khác với toolbar, nhưng việc cho phép chỉnh thứ tự các tab và những tab thực sự được hiển thị có cảm giác như một thứ tương đương về tinh thần với tùy biến toolbar tích hợp. Vậy mà mấy năm nay tôi không thấy nữa
    Theo tài liệu thì nó vẫn còn. Tôi tò mò không biết có ai biết app nào vẫn dùng pattern này không: https://developer.apple.com/documentation/uikit/uitabbarcont...
    Dù sao thì thanh tab rất tuyệt. Đó là cách hầu hết các app Apple TV tôi từng dùng sử dụng, và trải nghiệm nhất quán rất tốt

    • Thời kỳ đầu, việc xáo trộn các tab và chỉ thêm/bớt những gì mình muốn khá phổ biến
      Tôi nhớ khi Facebook vẫn còn ổn, có lẽ khoảng iOS 7, có thể thay đổi các mục như chat, feed, thông báo, nhóm theo cách này
    • Nhiều app của Apple như Apple Store và Music dùng thanh tab ở dưới, nhưng không cho tùy biến
      Những app ngoài Apple mà tôi nghĩ tới thì từ lâu đều đã chuyển sang menu hamburger khó khám phá
    • Trên Mac, tôi mong nhiều app hơn dùng toolbar tiêu chuẩn
      Khả năng tùy biến rất hay, nhưng gần như không thấy trong các triển khai tự làm
    • UITabBar luôn bị hạn chế đến đau đớn về mặt tùy biến cả từ góc nhìn lập trình viên, và rất ít dự án quan tâm tới khía cạnh người dùng tự thay đổi
      Tôi nghĩ Apple đã khóa giao diện quá chặt, rốt cuộc khiến mọi người thay nó bằng thứ khác
    • Tôi vẫn nhớ tính năng có thể sắp xếp lại toolbar trong các app iOS như Music
      Có 2 tab trong Apple Music mà tôi theo đúng nghĩa đen là hoàn toàn không dùng. Ước gì có thể đưa tôi thẳng đến playlist và album

  • Câu “điều hướng drill-down là không có trạng thái” ở mục đầu tiên có vẻ ngược lại
    Màn hình N phụ thuộc vào những gì đã làm trước đó, và có thể quay lại đó, nên đây là cấu trúc rất nhiều trạng thái. Để hữu ích, nó thực sự phải theo dõi trạng thái bên trong. Ví dụ nội dung danh sách phụ thuộc vào trạng thái N-1, nếu không thì sẽ rất tệ
    UI không trạng thái sẽ giống như một modal một cấp. Hoặc có, hoặc không. Đặc biệt nếu nó tạm thời và không có cách nào để “tiếp tục”, thì càng có thể xem là không trạng thái
    Trong nhiều năm, tôi đã thấy khá nhiều cuộc thảo luận dùng cụm “có trạng thái” theo những nghĩa hoàn toàn khác nhau, và gần đây thì đặc biệt bùng nổ. Vì vậy tôi gần như đi đến kết luận rằng hầu như không ai thống nhất với nhau về ý nghĩa của nó, và cũng ít người nhận ra điều đó
    Tôi tò mò với các bạn, UI có trạng thái là gì. Sự khác biệt đó khá thú vị

    • Tôi đồng ý rằng cụm “UI có trạng thái” nói chung là mơ hồ, nhưng trong ngữ cảnh điều hướng, tôi thường nghe người ta gọi cấu trúc phân cấp là không trạng thái, còn activity stack là có trạng thái
      Trong một cấu trúc phân cấp như iOS, mọi phần tử con phải có đúng một phần tử cha, nên chỉ cần biết trang hiện tại là biết nút “Back” sẽ làm gì. Bất kể bạn đến trang đó bằng cách nào, nó sẽ đi lên trang cha ở một cấp trong cây phân cấp
      Trong activity stack như Android, chỉ biết trang hiện tại là chưa đủ; cần biết bạn đã đến trang đó như thế nào. Vì nút “Back” có nghĩa là đi lùi trong lịch sử
      Nhiều website hỗ trợ cả hai. Nút Back của trình duyệt có trạng thái và duyệt qua lịch sử cá nhân, nhưng điều hướng trong trang như breadcrumb thường không có trạng thái, nên không phụ thuộc vào con đường cụ thể đã đưa bạn đến trang đó. Tất nhiên cũng có ngoại lệ. Nhiều giao diện tìm kiếm có thể xem là có trạng thái, vì nếu bạn đi vào một mục rồi quay lại bằng điều hướng trong trang, nó đưa bạn về truy vấn tìm kiếm trước đó chứ không phải trang cha
    • Với tôi, UI có trạng thái nghĩa là frontend dùng biến để quản lý hành vi của chính nó

  • Ở đây tôi thấy có một cách diễn đạt không chính xác. Đó là đoạn “vuốt từ mép trái màn hình sang phải tương đương với nhấn nút Back”
    Nếu tự triển khai, đây không nên là gesture vuốt mà phải là edge pan gesture. Nó phải đi theo ngón tay và là một pan tương tác có thể hủy; nếu không cảm giác sẽ bị sai

    • Có vẻ app iOS của X/Twitter và app Reddit gặp vấn đề này
      Quá thường xuyên xảy ra chuyện tôi đang nhập gì đó rất chăm chú, chỉ hơi chạm vào mép điện thoại thôi mà toàn bộ bình luận bay mất
    • Vuốt từ trái sang phải để quay lại là một cách triển khai “nút Back” tệ hại và tuyệt đối không nên làm. Luôn phải có nút quay lại thật sự
      Lý do là người thuận tay trái có tồn tại. Đây không phải là chuyển động tự nhiên hay thoải mái khi dùng ngón cái tay trái. Cũng không thể đảo ngược hướng cho người thuận tay trái, vì nếu đọc từ trái sang phải thì vuốt sang phải trông giống như đi tiếp chứ không phải quay lại
      Nhìn chung tôi không thích điều hướng bằng thao tác vuốt. Trên iOS thì đặc biệt tệ. Vuốt từ dưới lên sẽ mở một menu nào đó, trong đó có những thứ thực sự quan trọng, nhưng khi cần thì lại không tìm được, còn khi cuộn trang web thì cứ liên tục kích hoạt nhầm
      Nói rộng hơn, iOS đã thoái hóa thành một hệ điều hành cực kỳ phức tạp, như ác mộng để điều hướng, và tôi cảm thấy Apple cần nghiêm túc trở lại với UI/UX. Vấn đề chính có vẻ là kỳ vọng điện thoại phải xử lý vô số tác vụ vốn dĩ không phù hợp với nó
    • Sailfish OS xử lý việc này đúng và nhất quán trong mọi app
      https://sailfishos.org/
      Nhìn chung tôi cảm thấy nó đơn giản hơn và tốt hơn iOS lẫn Android

  • Đây là tài liệu thực sự tốt cho những người gặp khó khăn với khía cạnh phần mềm trực quan
    Các sơ đồ và phần giải thích rõ ràng rất tuyệt

  • Frank Rausch là người đã tạo ra “V for Wiki”, ứng dụng Wikipedia tuyệt vời nhất
    Vì vậy, khi ông ấy nói về thiết kế iOS và trải nghiệm người dùng thì đáng để lắng nghe
    https://web.archive.org/web/20211223231349/https://v-for-wik...

    • Riêng chuyện V For Wiki thì không rõ rốt cuộc đã xảy ra chuyện gì
      Tôi dùng hằng ngày, rồi một ngày đột nhiên nó ngừng hoạt động; tìm trên App Store thì thấy đã biến mất. Thật sự rất buồn

  • Ước gì có thể tắt thao tác “vuốt từ mép trái màn hình sang phải tương đương với nhấn nút quay lại”
    Khi cuộn ngang trên các trang web không vừa màn hình, chuyện vô tình kích hoạt quay lại xảy ra quá thường xuyên

  • iOS làm phần này khá tốt
    Một ứng dụng iOS điển hình có kiến trúc cố định như một cây phân cấp nhiều tầng, và nhờ cấu trúc chặt chẽ này mà các lựa chọn điều hướng trở nên dễ dự đoán. Các mẫu điều hướng có cấu trúc cho người dùng sự chắc chắn về việc họ đến từ đâu, đang ở đâu trong hệ phân cấp, và làm thế nào để quay lại nơi ban đầu
    Ngược lại, trên Android, cử chỉ quay lại đôi khi đưa về trang trước, đôi khi lại đóng hẳn ứng dụng. Nó thiếu nhất quán đến mức sau 12 năm dùng Android, tôi đã chuyển sang iOS

    • Ngay từ đầu đã vậy rồi
      Thật đáng kinh ngạc là đã chịu đựng tới 12 năm trước khi quyết định không thể chịu nổi nữa

  • Khi tôi mới bắt đầu phát triển iPhone, tức là lúc SDK chính thức vừa ra mắt, Apple rất nghiêm ngặt với Human Interface Guidelines, và tài liệu về những yếu tố tạo nên UI tốt cũng như các mẫu chuẩn cần tuân theo cũng rất tốt
    Nhưng khi chuyển sang thiết kế “phẳng”, có vẻ như điều đó đã biến mất hoàn toàn. Tôi nghĩ lý do chính là các tài liệu đó không còn hợp lý nữa
    Trước đây mọi thứ rất rõ ràng, kiểu như “hãy làm cho tương tác của người dùng hiển thị rõ ràng”, còn bây giờ thì thành “cái này có thể bấm được, cũng có thể chỉ là văn bản, hoặc có thể phải nhấn giữ”
 
genkino 2023-12-13

Xin chào! Tôi cũng chỉ biết điều này khi chia sẻ bài viết này với một đồng nghiệp. Theo tôi được biết, không phải 네비게이션 mà 내비게이션 mới là từ chuẩn phù hợp với chính tả tiếng Hàn. Haha. Vì đây là cách phát âm của tiếng Anh nên thật ra cũng khó nói chắc cái nào mới là “đúng”. Nhưng vì đây là nơi có nhiều người đọc, nên tôi nghĩ sẽ tốt hơn nếu dùng theo từ chuẩn, nên xin phép để lại một bình luận nhỏ.
 
xguru 2023-12-14

Bài viết này là nội dung do GPT-4 tóm tắt. GPT đang dùng “điều hướng” khá ổn, nhưng có vẻ thỉnh thoảng lại dùng lẫn cả “navigation”. Tôi đã sửa lại rồi haha