Là người làm phần mềm, tôi thấy nút Back vật lý thực sự là một bất lợi của Android so với iOS

*Bài viết thể hiện quan điểm của riêng tác giả

Ngay khi lên ý định thực hiện bài viết này, tôi đã đoán trước rằng nhiều bạn fan của Android sẽ vội vàng đi đến những kết luận dạng như "fan cuồng iPhone", "lậm iOS quá rồi"... Có lẽ, cần phải nói rõ với bạn đọc rằng tôi là một fan của Samsung (vừa mua Note7), và bài viết này không có mục đích "hạ bệ" bất kỳ ai. Trái lại, bài viết này được tôi thực hiện với quan điểm thuần túy của một người làm phần mềm.

Cách đây gần một tháng, tạp chí The Next Web có đăng tải một bài viết chê bai rằng các nút điều hướng nằm phía dưới của smartphone Android là "cực kỳ vô lý". Lý do chính được trang web công nghệ này đưa ra là bởi các nút Back, Home và Overview sẽ thường chiếm mất một phần diện tích màn hình. Ví dụ được The Next Web đưa ra để khen ngợi là các mẫu điện thoại Samsung, vốn tách hẳn các phím điều hướng ra khỏi diện tích màn hình.

Nhưng vấn đề của các nút điều hướng Android không dừng lại ở đây. Trong khi tôi hoàn toàn đồng tình với sự tồn tại của nút Home và nút Overview, sự tồn tại của nút Back có thể nói là mang một ý nghĩa tiêu cực với người viết ứng dụng.

Giữa một bên là nút Home, nút Overview và bên còn lại là nút Back, bạn sẽ thấy một điểm khác biệt quan trọng: hai nút Home và Overview thì hoạt động ở mức độ hệ điều hành còn nút Back thì hoạt động cả ở trong App. Nói cách khác, theo thiết kế mặc định thì các tác vụ với hai nút Home và Overview đều sẽ không ảnh hưởng gì đến tính năng của ứng dụng cả, chúng được dùng để đi tới các phần khác của hệ điều hành.

Nút Back thì không như vậy. Trong kinh nghiệm sử dụng Android của tôi, ứng dụng nào cũng phải hỗ trợ nút Back để điều hướng bên trong ứng dụng.

Đây sẽ là một vấn đề lớn với giới developer vì 2 lý do chính: 1, iOS và 2, tác hại của nút Back vật lý.

Với iOS, tự nhà phát triển phải lo sẽ cung cấp tính năng "Back" như thế nào.

Lý do đầu tiên sẽ khiến nhiều người chau mày, nhưng nếu là một developer kiếm tiền từ di động thì có lẽ bạn sẽ không quá bất bình: các thiết bị iOS không cần nút Back thì thiết bị Android cần nút Back để làm gì? Hãy nhớ rằng iPhone và iPad không có nút Back, bởi vậy nên các nhà phát triển luôn cần phải tạo một nút Back "ảo" trên giao diện. Với Android thì khác: phần đông ứng dụng không cần nút Back, và rất nhiều người dùng Android có tâm lý phụ thuộc vào nút Back vật lý.

Điều này có nghĩa rằng một nhà phát triển ứng dụng nếu muốn hỗ trợ cả iOS lẫn Android sẽ phải tạo ra hai phiên bản có giao diện khác nhau. Một nút Back trên màn hình có thể không phải là nhiều, nhưng chẳng một ai có thể chắc chắn được rằng một ứng dụng sẽ "chỉ" có 5 hay 10 màn hình. Và kể cả nếu ứng dụng chỉ có 5 màn hình đi chăng nữa thì việc phải tạo ra 2 bộ giao diện khác nhau vẫn là có phát sinh thêm công việc cho nhà phát triển. Đây là một điều không nên.

Kết quả là có khá nhiều ứng dụng cung cấp tính năng quay lại màn hình trước ngay trên giao diện ứng dụng và qua nút Back vật lý của Android. Nếu đã có nút trên giao diện thì nút vật lý hiển nhiên là vô nghĩa.

Nhiều ứng dụng Android vẫn có nút Back trên giao diện.

Thêm nữa, đứng từ góc độ nhà phát triển thì bạn sẽ luôn muốn tạo ra trải nghiệm đồng nhất đến hết mức có thể cho người dùng trên mọi thiết bị, mọi nền tảng. Điều đó có nghĩa rằng về mặt lý thuyết, developer không nên tạo thói quen sử dụng nút Back vật lý cho người dùng Android – nếu một ngày nào đó họ chuyển sang dùng iOS, họ sẽ gặp thêm một chút khó khăn khi tiếp tục sử dụng ứng dụng của bạn. Khó khăn ở đây có lẽ chỉ là "một chút", nhưng vẫn là không nên.

Đọc đến đây, bạn có thể đặt ra câu hỏi "Thế thì tại sao không ưu tiên Android hơn iOS", nhất là khi Apple còn bắt chính nhà phát triển phải tạo ra nút Back cho ứng dụng của họ, còn Android thì lúc nào cũng có sẵn.

Câu trả lời dễ thấy nhất: phát triển ứng dụng cho nền iOS sẽ mang lại tiềm năng kinh tế lớn hơn so với Android. Đây là một thực tế trớ trêu đã được rất nhiều người nằm lòng: Android dù áp đảo về lượng người dùng nhưng lại không thể địch lại iPhone/iPad trên phân khúc cao cấp, vốn là nhóm "chịu chi" hơn rất nhiều so với các phân khúc dưới. Chưa kể, ứng dụng Android cũng dễ bị vi phạm bản quyền hơn ứng dụng iOS. Kết quả là doanh thu bản quyền/mua bán in-app của iOS lúc nào cũng áp đảo Android, và người viết ứng dụng di động gần như luôn ưu ái hệ điều hành của Apple trước tiên.

Cho đến tận bây giờ, nhiều ứng dụng "đỉnh" vẫn có mặt trên iOS trước tiên và ngay cả Google lẫn Microsoft (thời kỳ còn Windows Phone) vẫn mang sản phẩm của mình lên hệ điều hành của Táo.

Tốt nhất là nên bỏ luôn nút Back.

Quan trọng hơn cả, việc các nhà phát triển iOS phải tạo ra nút Back trên giao diện ứng dụng của họ thực chất lại có lợi cho chính họ! Lý do là bởi không phải bất ký màn hình nào cũng nên hỗ trợ nút Back.

Hãy thử nghĩ đến tình huống sau đây: bạn tạo một đơn hàng (có số hiệu #123456) trên ứng dụng và nhấn nút Hoàn tất. Lúc này, đơn hàng của bạn đã được gửi đến cửa hàng, nhưng bạn bỗng chợt nhận ra là mình cần chỉnh sửa lại một vài đơn vị trong đơn hàng nói trên. Bạn nhấn nút Back để quay về màn hình chọn hàng, chỉnh sửa rồi lại nhấn Hoàn tất một lần nữa.

Để khiến mọi thứ thêm phức tạp, từ màn hình đầu đến màn hình cuối số hiệu của đơn hàng vẫn là #123456, bởi mã số này thường sẽ được tạo ngay từ khi người dùng khởi tạo đơn hàng mới (thay vì khi họ hoàn tất). Vậy khi bạn nhấn nút Hoàn tất lần thứ hai (sau khi đã chỉnh sửa), điều gì sẽ xảy ra? Nhà phát triển ứng dụng nên hủy đơn hàng cũ hay báo lỗi cho đơn hàng mới? Bất kể họ làm theo cách nào, người dùng ứng dụng vẫn có thể cảm thấy rối vì số hiệu đơn hàng trên màn hình vẫn là 123456.

Giả sử như đây là sơ đồ mô tả luồng hoạt động của ứng dụng: điều gì sẽ xảy ra khi người dùng có thể nhấn nút Back tại bất cứ một vị trí nào của flow?

Dĩ nhiên ví dụ mà chúng tôi liệt kê ra ở trên rất đơn sơ, và thực tế là người làm ứng dụng có nhiều cách để giải quyết các vấn đề tương tự. Song, điều cần nhận thấy rõ ở đây là bất cứ lúc nào, sự xuất hiện của nút Back có thể làm cho luồng sử dụng (flow) bên trong ứng dụng trở nên rối loạn hơn rất nhiều.

Cách đơn giản nhất để tránh các vấn đề như trên là... hủy luôn tính năng của nút Back – một giải pháp được rất nhiều nhà phát triển ứng dụng web thực hiện nhằm "trói" người dùng vào cách điều hướng do chính họ định nghĩa, thay vì chịu ảnh hưởng của tác nhân bên ngoài (trình duyệt). Nhưng nếu như thiết bị/trình duyệt của bạn lúc nào cũng có một nút Back, bạn sẽ phải "dạy" người dùng rằng trong ứng dụng của bạn, nút Back vật lý không có tác dụng. Người dùng nào không quen với cách làm này vẫn sẽ bấm nút Back vật lý rất nhiều, và mỗi lần bấm "nhầm" như vậy họ lại nhận được một thông báo lỗi nói rằng "Không được quyền dùng nút Back vật lý". Quả là một trải nghiệm sử dụng khó chịu.

Như đã nói ở trên, do ứng dụng di động phần đông là dành cho người dùng phổ thông nên vấn đề về flow sẽ không quá trầm trọng. Thế nhưng, xu hướng rất rõ rệt hiện nay của ngành phần mềm (bao gồm cả phần mềm di động) là ngày một tận dụng iOS và Android cho công việc nhiều hơn. Khi tầm nhìn này thành hiện thực, vấn đề từ nút Back lúc-nào-cũng-có-mặt sẽ trở nên trầm trọng hơn rất nhiều, vì ứng dụng doanh nghiệp đòi hỏi nhiều Workflow phức tạp, nhiều khoảnh khắc không nên... Back.

Tóm lại: đơn giản nhất, có lợi nhất vẫn là để dev tự lo chuyện điều hướng thay vì lúc nào cũng áp đặt nút Back.

Cuối cùng, nhà phát triển hoàn toàn có thể tạo các thanh điều hướng đơn giản (dạng Cấp 1 >> Cấp 2 >> Cấp 3 >> Cấp 4) để người dùng có thể điều hướng một cách trực quan hơn là nhấn nút Back. Trong ví dụ ở trên, bạn có thể thấy rằng khi nào muốn chuyển về trang cũ, người dùng đều sẽ nhận thức rõ ràng hơn họ đang chuyển về đâu. Ở phía còn lại, công việc code cũng sẽ dễ dàng hơn: khi người dùng chuyển từ Cấp 4 về Cấp 1 hay Cấp 3 về Cấp 1, nhà phát triển cũng chỉ cần tạo một hàm trên trang của Cấp 1 để kiểm tra xem tình trạng của đơn hàng/bản ghi hiện tại đang là như thế nào, các tác vụ trên trang Cấp 1 có còn hợp lệ hay không. Nếu người dùng làm theo cách thông thường là nhấn Back 3 lần để đi từ trang Cấp 4 về trang Cấp 1, việc kiểm tra dữ liệu sẽ trở nên nhiêu khê và rối loạn hơn rất nhiều.

Nói tóm lại, là một người làm phần mềm, tôi cho rằng nút Back trên Android là một sai lầm của Google. Nếu thực sự muốn ưu ái cộng đồng developer, Google nên tìm cách hủy bỏ nút bấm dễ gây... bực mình này trong tương lai.