Priya — tuần trước bạn hỏi tôi liệu công cụ theo dõi giảm giá bạn đang xây có nên quét trang sản phẩm mỗi phút "cho chắc" hay không. Trước khi bạn đưa điều đó vào build, hãy để tôi dẫn bạn qua toàn bộ vấn đề, vì khoảng thời gian quét thực ra là quyết định nhỏ nhất ở đây, và làm đúng cấu trúc ngay từ đầu sẽ giúp bạn tránh được một hoặc hai vòng review trước khi ra mắt.
Bắt đầu từ chính prompt. Bạn nói với tôi "một tiện ích theo dõi trang này và báo khi giá giảm", đó là một ý tưởng ổn nhưng chưa phải là một spec — trình xây dựng cần biết khi nào nó hành động, chứ không chỉ nó làm gì. Công cụ theo dõi của bạn là kiểu thứ ba trong ba dạng trigger, và đáng để biết hai dạng còn lại dù bạn không cần đến chúng, vì hình thái quyết định quyền truy cập và quyền truy cập quyết định thời gian review của bạn.
- Nhấp để thực hiện là rẻ nhất: một popup chạy một lần trên trang hiện tại khi ai đó bấm vào biểu tượng thanh công cụ — kiểu như "lấy mọi mức giá trên trang này vào một danh sách".
- Content script luôn bật chạy tự động trên một mẫu URL bạn chỉ định — phù hợp cho việc như làm nổi bật tên đối thủ cạnh tranh trên mọi trang thuộc một tên miền, nhưng bạn phải nêu rõ mẫu đó, vì "trên các site nội bộ của chúng tôi" sẽ bị hiểu hẹp hơn ý bạn muốn.
- Trường hợp của bạn là kiểu thứ ba: một công cụ theo dõi chạy nền, trạng thái được duy trì bất kể tab có mở hay không, chạy trên service worker theo MV3, đánh dấu biểu tượng khi có thay đổi.
Đó là hình thái duy nhất mà trình xây dựng nên phản hồi lại bạn bằng một câu hỏi tiếp theo, và nó sẽ làm vậy — vì con số khoảng thời gian quét là một sự đánh đổi thực sự, không phải chuyện hình thức.
Điều đó đưa tôi quay lại bản năng "mỗi phút" của bạn. Trước đây tôi từng yêu cầu gần như chính xác cùng một build với bạn — theo dõi một trang, đánh dấu biểu tượng khi giá thay đổi — và bản đầu tiên quét mỗi 60 giây. Chạy tốt khi một người test cục bộ. Nhân con số đó với bao nhiêu người thực sự cài tiện ích này lên, bạn sẽ liên tục làm phiền trang sản phẩm của ai đó mà chẳng vì lý do gì, bởi giá trên một danh mục bán lẻ thông thường không đổi quá vài lần một ngày. Hãy nói với trình xây dựng "kiểm tra mỗi 30 phút" trong prompt. Đó không phải là sự thỏa hiệp, mà là yêu cầu trung thực hơn — chẳng ai cần cảnh báo dưới một phút từ một tiện ích trình duyệt, và sau này bạn sẽ cảm ơn chính mình khi không phải giải thích với người review vì sao tiện ích của bạn gọi về máy chủ 1.440 lần mỗi ngày.
Những phần bạn không cần bận tâm
Bạn từng lo lắng về manifest — đừng lo, đó là thứ duy nhất bạn thực sự không cần đụng tới. Cả hai cửa hàng giờ đều yêu cầu Manifest V3; MV2 không còn được chấp nhận cho listing mới và Chrome đang chủ động loại bỏ dần các tiện ích MV2 vẫn còn hoạt động. Thay đổi lớn nhất dưới MV3 là logic chạy nền của bạn chạy dưới dạng service worker thay vì một trang nền bền vững — nó khởi động khi có sự kiện, trình duyệt có thể tắt nó giữa các sự kiện, và trạng thái phải đi qua chrome.storage thay vì chỉ tồn tại trong một biến. Đó chính xác là loại chi tiết vòng đời mà trình xây dựng viết đúng theo mặc định. Bạn sẽ không bao giờ nhìn thấy file manifest trừ khi cố tình tìm nó.
Điều bạn thực sự nên dành sự chú ý là quyền truy cập, vì đó là yếu tố quyết định review của bạn nhanh hay chậm, không phải code. Công cụ theo dõi của bạn cần alarms cho việc quét định kỳ và có lẽ storage để ghi nhớ mức giá cuối cùng — nó không cần tabs hoặc <all_urls>, và nếu bạn yêu cầu "khả năng hoạt động trên bất kỳ site nào trong tương lai" vì có thể sau này bạn sẽ mở rộng nó, trình xây dựng sẽ build theo hướng đó và bạn sẽ phải xin quyền truy cập host phạm vi rộng cho một tính năng chưa hề tồn tại. Đó là dòng đáng sợ nhất trong hộp thoại cài đặt — "đọc và thay đổi dữ liệu trên mọi site bạn truy cập" — và đó cũng là thứ đẩy một review tự động thành review thủ công. Hãy mô tả những gì nó làm hôm nay. Mở rộng sau nếu bạn thực sự cần.
Còn hai điều đáng để bạn dành ba mươi giây quan tâm trước khi coi như xong: giao diện popup và các biểu tượng.
- Giao diện popup — một trang tùy chọn mặc định, những ô checkbox trơ trọi, không phân cấp, là một nguồn thực sự dẫn đến đánh giá một sao chẳng liên quan gì đến việc tiện ích có hoạt động hay không. Tiện ích của bạn chỉ có vài cài đặt (URL, có thể là khoảng thời gian), nhưng nó vẫn nên trông như thuộc về một sản phẩm, chứ không phải một mớ form được đổ ra.
- Biểu tượng — hãy kiểm tra biểu tượng ở cả bốn kích thước của Chrome (16, 32, 48, 128px, với một ma trận hơi khác cho Firefox), vì một logo sắc nét ở 128px sẽ trở thành một vệt nhòe ở 16px, đúng nơi nó xuất hiện phần lớn thời gian trong một thanh công cụ đông đúc.
Trước khi bạn đụng đến bất kỳ cửa hàng nào
Hãy kiểm thử điều này thật sự, không chỉ trong bản xem trước chat. Những gì bạn nhận được từ build là một tiện ích có thể tải lên thực sự, vì vậy hãy vào chrome://extensions, bật chế độ nhà phát triển, chọn "load unpacked" (tải chưa đóng gói), rồi chạy thử trên đúng trang sản phẩm bạn quan tâm — không phải bản mô phỏng của nó. Mình sẽ kiểm tra cụ thể hai điều bằng tay: lời nhắc quyền cài đặt có nói đúng như những gì bạn mong đợi dựa trên yêu cầu đã đưa ra không, và điều gì xảy ra nếu content script gặp phải một trang mà nó chưa được thiết kế cho — nó lặng lẽ thất bại hay ném ra lỗi có thể thấy được? Cả hai đều mất chưa đến một phút, và cả hai đều là kiểu lỗi rõ ràng ngay khi bạn nhìn vào nhưng vô hình nếu bạn không nhìn.
Khi bạn sẵn sàng phát hành thật, bạn sẽ đi qua tài khoản nhà phát triển của riêng bạn trên cả hai cửa hàng — bạn sở hữu listing, nền tảng này không quản lý nó hộ bạn. Và tôi muốn lưu ý rằng hai cửa hàng hoàn toàn không đối xứng nhau, vì tôi không muốn bạn lên kế hoạch ngày ra mắt với giả định rằng chúng giống nhau.
| Store | Quy trình gửi duyệt |
|---|---|
| Chrome | Tự động điền listing — tiêu đề, mô tả, danh mục, và phần giải thích lý do cần quyền mà người review thực sự đọc, được tạo ra từ chính những gì code làm thay vì gõ riêng, điều này quan trọng vì lời giải thích quyền không khớp là một lý do từ chối phổ biến ngay cả khi đứng một mình. |
| Firefox | Về cơ bản là không cần can thiệp; quy trình của Mozilla nhẹ hơn và bản gửi duyệt cứ thế trôi qua. |
Bộ listing được tạo ra sau khi build hoàn tất cũng sẽ tạo ảnh chụp màn hình lấy từ tiện ích của bạn đang thực sự chạy (không phải mockup), nội dung listing, và các câu trả lời về thực hành quyền riêng tư được đối chiếu với code thật thay vì điền theo trí nhớ. Phần cuối này quan trọng hơn nghe có vẻ với một tiện ích giao tiếp với trang bên ngoài: bảng câu hỏi về quyền riêng tư của Chrome hỏi thẳng có/không về việc xử lý dữ liệu, và trả lời "không" cho câu "tiện ích này có thu thập dữ liệu không" trong khi công cụ theo dõi của bạn đang quét và lưu giá là kiểu thiếu trung thực nhỏ mà sẽ bị gỡ sau khi ra mắt, chứ không chỉ bị từ chối trước đó. Việc có các câu trả lời được đối chiếu với những gì code thực sự làm sẽ tự động lấp khoảng trống đó cho bạn.
| Store | Thời gian review điển hình |
|---|---|
| Firefox | Vài giờ, đôi khi dưới một giờ |
| Chrome | Vài ngày, thỉnh thoảng gần hai ngày vào tuần xui xẻo |
Các tiện ích chạy nền liên tục như của bạn có nhiều khả năng rơi vào làn review thủ công chậm hơn so với một tiện ích nhấp-để-thực-hiện đơn giản. Không ai trong chúng ta có thể tác động lên hàng đợi đó. Hãy lên kế hoạch thông báo ra mắt theo lịch trình của Chrome, chứ không phải của Firefox, và đừng lên lịch gì cho đúng ngày bạn nộp duyệt.
Một điều cuối cùng, vì tôi biết bạn — bạn đã đang nghĩ đến việc thêm "đồng bộ danh sách theo dõi của tôi trên các thiết bị" và "theo dõi lịch sử giá theo thời gian" sau khi ra mắt. Điều đó không sao, nhưng hãy biết rằng mỗi tính năng đó là một quyền mới, và một quyền mới có thể đồng nghĩa với review chậm hơn lần bạn vừa trải qua. Nếu bạn chắc chắn muốn phiên bản lớn hơn, thực sự tốt hơn nếu prompt cho nó ngay bây giờ và chấp nhận một lần review chậm hơn, thay vì bổ sung từng quyền một. Nếu bạn chưa chắc, hãy ra mắt những gì bạn đang có — một công cụ theo dõi được giới hạn phạm vi chặt chẽ sẽ được duyệt nhanh, giúp bạn có người dùng thực, và người dùng thực đáng giá hơn lúc này so với một danh sách tính năng dài đang nằm chờ trong hàng đợi của Chrome. Bạn luôn có thể yêu cầu thêm sau; bạn không thể lấy lại lần ra mắt này một khi nó bị kẹt trong review thủ công vì thứ gì đó bạn chưa cần đến.
