Xây dựng trang web theo hướng ưu tiên HTML giúp lượng người dùng tăng gấp đôi chỉ sau một đêm

Đây là câu chuyện về cách xây dựng một trang web theo hướng ưu tiên HTML (HTML-first) đã giúp lượng người dùng của một công ty tăng gấp đôi theo đúng nghĩa đen chỉ sau một đêm.

Khách hàng của tôi là một công ty tiện ích, và họ đang gặp một vấn đề lớn. Để đăng ký sử dụng dịch vụ, khách hàng có thể sử dụng một biểu mẫu ASP cũ kỹ trên trang web hoặc thực hiện quy trình thủ công. Tất nhiên, quy trình thủ công tốn kém hơn nhiều cho công ty. Áp lực càng lớn thêm khi đây là một doanh nghiệp độc quyền được quản lý chặt chẽ; nếu chỉ số hài lòng của khách hàng giảm dưới mức 96% (nếu tôi nhớ đúng), họ có thể bị phạt hàng triệu bảng.

Trước đó, đã có hai lần cố gắng giải quyết vấn đề thất bại (và rất tốn kém). Trong lần gần nhất nhất, các nhà thầu ở một quốc gia khác đã xây dựng một ứng dụng React. Ứng dụng React này được đưa lên mạng trong 3 ngày trước khi bị gỡ bỏ vì sự phàn nàn của khách hàng. Tôi chỉ nhìn qua một lần và đã nói với sếp rằng: "Chúng ta không thể nhận trách nhiệm về thứ này được". Nó là một mớ hỗn độn của các biểu tượng tải (loading spinners) và trạng thái JavaScript toàn cầu. Nó không đảm bảo khả năng truy cập. Tải lên hình ảnh là một phần quan trọng của biểu mẫu, và nó cố gắng lưu trữ hình ảnh (cùng với tất cả dữ liệu biểu mẫu khác) vào localstorage, nơi chỉ có giới hạn 5MB!

Tôi đã đưa ra một quyết định rất táo bạo: xây dựng phiên bản mới của trang web bằng cách sử dụng Astro. Đó là trang web ưu tiên HTML. JavaScript vẫn tồn tại, dưới dạng các web component, nhưng chỉ để nâng cấp dần (progressive-enhance) một trang web hoạt động hoàn hảo mà không cần nó.

Logic của tôi như sau:

• Đây là một dịch vụ công cộng.
• Nó nên hoạt động trên mọi máy tính có thể.
• Nó nên hoạt động khi kết nối kém.
• Các biểu mẫu không bao giờ được mất dữ liệu sau khi đã nhập.

Tôi rất cảm động bởi câu chuyện này của Terence Eden:

"Vài năm trước, tôi đang thực hiện nghiên cứu chính sách tại một văn phòng lợi ích nhà ở ở London. Đó là những nơi không hề dễ chịu chút nào. Các bức tường được làm sáng sủa hơn bằng các áp phích cung cấp các dịch vụ hữu ích cho những người trốn khỏi bạo lực gia đình. Các bảo vệ ở cửa thờ ơ với bất kỳ ai bước vào. Không khí ngập tràn những cuộc trò chuyện căng thẳng giữa các cặp đôi - bị át đi bởi tiếng trẻ em gào khóc.

Ở giữa, một người phụ nữ trẻ ngồi trên một chiếc ghế nhựa cứng. Bà ấy bị bao quanh bởi các túi vải chứa đựng toàn bộ tài sản thế giới của mình. Bà ấy không có vẻ đang ở trong trạng thái cảm xúc tốt lúc này. Trên tay là một máy chơi game cầm tay - một PlayStation Portable. Bà ấy nhìn chằm chằm vào nó; chặn bỏ thế giới bên ngoài bằng Candy Crush.

Hoặc, ít nhất là tôi nghĩ vậy.

Đi ngang qua sau lưng bà ấy, tôi liếc nhìn máy chơi game của bà ấy và nhận ra màn hình bà ấy đang xem. Bà ấy đã kết nối với WiFi miễn phí và đang duyệt các trang GOV.UK về Lợi ích Nhà ở. Bà ấy không đang cắt trái cây; bà ấy đang trang bị cho mình kiến thức.

Trình duyệt web của PSP - nói một cách nhân từ - là thảm hại. Nó chậm, thường xuyên hết bộ nhớ và chỉ có thể mở 3 tab cùng một lúc.

Nhưng các trang GOV.UK được viết bằng HTML đơn giản. Chúng được thiết kế để nhẹ nhàng và sẽ hoạt động ngay cả trên những trình duyệt rác rưởi. Chúng buộc phải làm như vậy. Đây là dành cho tất cả mọi người."

Từ đó, tôi đưa ra một số yêu cầu:

• Mỗi phiên làm việc với biểu mẫu nên có một ID duy nhất.
• Tại mọi bước trong trình hướng dẫn biểu mẫu, dữ liệu đã gửi nên được lưu trữ trên backend, bao gồm cả các tệp tải lên.
• Nên có thể hoàn thành biểu mẫu mà không cần JavaScript.
• Nên có thể hoàn thành biểu mẫu trên các trình duyệt web lỗi thời và kém chất lượng.
• Chúng tôi phải đáp ứng các tiêu chuẩn khả năng truy cập WCAG (đội ngũ chọn mức AA thay vì AAA).
• JavaScript và CSS hiện đại nên được sử dụng để nâng cao trải nghiệm.

Thiết lập cơ bản kết thúc là mỗi bước trong trình hướng dẫn biểu mẫu là một trang riêng biệt. Khi người dùng nhấp vào tiếp theo, biểu mẫu sẽ được gửi đi. Nếu dữ liệu được API đánh giá là hợp lệ, trình duyệt sẽ được chuyển hướng đến bước tiếp theo.

Đây là một mô hình ứng dụng web lâu đời đang có sự phục hưng nhỏ nhờ vào Remix. Việc gửi biểu mẫu và chuyển hướng đã mất một lúc để giải thích cho đồng nghiệp của tôi, bởi vì mọi người đã quen với các ứng dụng web chạy chủ yếu ở phía client (client-side). Tôi không có gì chống lại các ứng dụng chạy chủ yếu ở phía client, ở đúng chỗ của chúng. Nhưng đây chỉ là một biểu mẫu lớn - nó không hiển thị dữ liệu thời gian thực. Người dùng của chúng tôi có thể đang đứng giữa một cánh đồng ở một khu nhà ở mới xây, cầm trên tay chiếc điện thoại Android đời cũ giá rẻ họ mua ở siêu thị. Việc gửi cho họ 20MB JavaScript trước khi chúng ta hiển thị một biểu mẫu là một điều vô lý.

Tiếp theo, tôi giải quyết một trong những vấn đề lớn nhất của tôi: xác thực biểu mẫu (và hiển thị lỗi biểu mẫu). Tôi đã thấy các đội nhóm lãng phí hàng tháng người công để vật lộn với các thư viện xác thực React. Nếu bạn là người dùng React, bạn có thể đang chế giễu điều này - vấn đề về kỹ năng, tôi đoán vậy - nhưng đó là thực tế đối với nhiều đội nhóm. Tôi muốn khiêm tốn đề xuất rằng bạn cũng có thể đang dành nhiều thời gian hơn bạn nhận thức, và nhiều thời gian hơn mức cần thiết, để tương tác và duy trì các bản sao kém chất lượng của hệ thống xác thực được tích hợp sẵn trên mọi trình duyệt.

Vì vậy, tôi đã xây dựng một web component HTML. Đây là các phần tử tùy chỉnh đơn giản bao bọc xung quanh HTML hiện có và làm cho nó sống động. Không có shadow DOM, không (hoặc rất ít) hiển thị HTML trong JavaScript. Của tôi bao bọc xung quanh bất kỳ biểu mẫu HTML nào, nhận diện xác thực HTML, và làm cho nó trông hiện đại. Nó sẽ ngăn chặn các mẹo công cụ bật lên của xác thực HTML, thay vào đó đặt thông báo lỗi vào phần tử aria-describedby được liên kết với trường (ngày nay, aria-errormessage được khuyên dùng thay thế). Nó sẽ xóa xác thực trong khi bạn gõ, nếu bạn đạt đến trạng thái hợp lệ, và đánh giá lại nó khi blur và gửi.

Chính xác là trải nghiệm người dùng mà một biểu mẫu cần, được cung cấp trong vòng dưới 1KB. Nếu nó thất bại, biểu mẫu sẽ quay lại xác thực tích hợp sẵn của trình duyệt. Nếu điều đó thất bại, API backend sẽ xử lý xác thực. Chúng tôi báo cáo các vấn đề xác thực cho người dùng sớm nhất có thể dựa trên trình duyệt của họ, và luôn quay lại một trải nghiệm chấp nhận được nếu nó thất bại.

Kể từ đó, tôi đã viết một phiên bản mới của web component này từ đầu, hướng tới sử dụng chung. Nó được gọi là validation-enhancer. Tôi đã làm việc trong ngành này hơn 20 năm, và đây là thư viện xác thực biểu mẫu tốt nhất tôi từng sử dụng. Tôi rất tự hào về nó.

Kết quả thì sao? Khi chúng tôi ra mắt, số người hoàn thành biểu mẫu đã tăng gấp đôi. Những người làm phân tích thậm chí không biết những người dùng này đến từ đâu. Tất nhiên, gói phân tích dựa trên JavaScript của bạn không thấy những người dùng mà bạn đang từ chối vì lỗi JavaScript. Đó là một làn sóng người dùng! Chúng tôi cũng thấy cách tiếp cận "giữ phiên backend, không bao giờ mất dữ liệu người dùng" của tôi mang lại hiệu quả. Trong một trường hợp, có người đã hoàn thành biểu mẫu một tháng sau khi bắt đầu.

Có một kết thúc buồn; như là cách của công việc hợp đồng, tôi đã chuyển đi. Tôi đã giải thích những gì tôi đã xây dựng cho người thay thế tôi, rằng nó luôn hoạt động ngay cả khi không có JavaScript. Anh ấy kinh hãi và nói: "nhưng điều đó tốn nhiều công việc của chúng ta hơn".

Không thể chấp nhận việc từ chối người dùng trên các trình duyệt cũ, người dùng có kết nối mạng kém, người dùng sử dụng công nghệ hỗ trợ. Chắc chắn không phải từ một dịch vụ công độc quyền. Rất nhiều sự cường điệu và ồn ào đang thúc đẩy chúng ta mở rộng giai đoạn "miền viễn tây hoang dã" của ngành công nghiệp phần mềm. Chúng ta nên đặt điều đó sang một bên và coi trọng bản thân như một ngành công nghiệp trưởng thành. Hãy xây dựng một ứng dụng web hoạt động trên PlayStation Portable với kết nối 3G - nếu bạn làm được điều đó, nó sẽ hoạt động cho tất cả người dùng của bạn, và nó vẫn sẽ hoạt động 30 năm nữa.