Một câu hỏi tuyệt vời mà bất kỳ nhà phát triển ứng dụng sử dụng dữ liệu người dùng nên hỏi, và, thật đáng buồn rất ít làm :(
Trong thực tế, có hai câu hỏi hoàn toàn độc lập ở đây:
Và đây là một số phân tích cho từng câu hỏi. Vui lòng tha thứ cho niềm đam mê của tôi đến từ trải nghiệm "người dùng thất vọng" của riêng tôi. :)
Q1 là câu hỏi khả dụng thuần túy. Câu trả lời thực sự hiển nhiên:
- Tránh hoặc trì hoãn để buộc người dùng đăng nhập nhiều nhất có thể!
Ngay cả khi cần lưu trạng thái thì cũng không đủ lý do. Nếu tôi là người dùng không quan tâm đến việc lưu trạng thái đó, thì đừng ép tôi ký! Xin vui lòng!
Lý do duy nhất cho bạn (như trang web) để biện minh buộc tôi ký là khi tôi (như người dùng) muốn để lưu dữ liệu của tôi để sử dụng sau. Ở đây tôi nói như người dùng có lãng phí thời gian trên ký chỉ để tìm trang web vô ích. Nếu bạn muốn loại bỏ quá nhiều người dùng, đó là cách đúng đắn. Trong bất kỳ trường hợp nào khác - xin vui lòng, trì hoãn nó càng nhiều càng tốt!
Tại sao có quá nhiều trang web hoàn toàn bỏ qua quy tắc rõ ràng như vậy? Các lý do có thể tôi có thể thấy:
Thân thiện với nhà phát triển thân thiện với người dùng. Có, đó là nhà phát triển thân thiện để yêu cầu đăng nhập ngay lập tức, vì vậy chúng tôi không cần phải bận tâm với concurrency (Q2). Vì vậy, chúng tôi có thể tiết kiệm chi phí phát triển, thời gian, vv Nhưng mỗi tiết kiệm đến với chi phí! Trong trường hợp này được gọi là Trải nghiệm người dùng. Mà không nhất thiết là nơi bạn muốn tìm kiếm tiết kiệm. Đặc biệt, vì giải pháp không nên khó như vậy (xem bên dưới).
R2 - Nhà thiết kế hoặc người quản lý đưa ra quyết định là "người đam mê trong nhà" :) Cô sống cuộc sống hạnh phúc được bao quanh bởi máy tính siêu nhanh với kết nối internet siêu nhanh và không thể tưởng tượng việc hát lên có thể khó khăn cho bất kỳ người dùng. Vì vậy, tại sao nó là một việc lớn như vậy? Vì vậy, nhiều lý do:
Nó phá vỡ luồng ứng dụng. Các trang web sống trong thế kỷ trước vẫn thay thế toàn bộ màn hình với hình thức đôi khi khá dài. Một số biểu mẫu được thiết kế kém, một số có hướng dẫn thất thường, một số chỉ đơn giản là không hoạt động. Một số đã gửi các nút vì một số lý do bị vô hiệu hóa trong trình duyệt được sử dụng. Một số nhà thiết kế biểu mẫu có ý tưởng thiên tài để khóa các trường nhất định với sự thay đổi hoặc màu sắc không đáng chú ý. Sau đó, không cho tôi thấy trường nếu bạn không muốn tôi điền vào nó!
Nếu trang web nghiêm túc về dữ liệu của người dùng, trang web phải yêu cầu Email và phải xác minh nó! Tại sao? Làm cách nào khác tôi sẽ quay lại với người dùng đã quên tất cả thông tin xác thực khác? Tại sao xác minh? Điều gì sẽ xảy ra nếu người dùng nhập sai email? Nếu tôi không xác minh nó, lần sau người dùng cố khôi phục mật khẩu bằng email chính xác của mình, quá trình khôi phục không thành công và tất cả dữ liệu bị mất! Rõ ràng, nhưng vẫn còn có các trang web ra khỏi đó không làm điều đó.Sau đó, tôi cần đợi cho đến khi email xác nhận được nhận và nhấp vào, hy vọng, liên kết được định dạng và duy nhất có thể nhận dạng không bị phá vỡ trong trình duyệt của tôi, cũng như không nhận được một số ký tự buồn cười do phát hiện mã hóa bị hỏng, làm cho toàn bộ liên kết không sử dụng được.
Kết nối internet có thể bị chậm hoặc bị hỏng, làm cho mỗi bước bổ sung trở thành một phần đau. Ngay cả với kết nối tốt, nó xảy ra ở đây và ở đó trang đó đột nhiên mất nhiều thời gian hơn để tải. Ngoài ra, email có thể không đến ngay lập tức. Sau đó, người dùng thiếu kiên nhẫn bắt đầu nhấn mạnh vào liên kết "gửi lại xác minh". Trong trường hợp này, 90% trang web gửi lại liên kết của họ bằng mã thông báo mới nhưng cũng vô hiệu hóa tất cả các mã thông báo trước đó. Sau đó, một số email đến theo thứ tự không thể đoán trước và người dùng nghèo phải đoán vô ích, cái nào (và chỉ một) vẫn hợp lệ. Bây giờ tại sao các trang web đó lại gặp khó khăn trong việc giữ một số mã hoạt động, chỉ trong trường hợp này, là ngoài sự hiểu biết của tôi.
Cuối cùng vẫn còn khó khăn như vậy để không tìm hiểu thói quen cho các trang web để nhấn mạnh vào cái gọi là "tên người dùng". Vì vậy, bây giờ, bên cạnh email của tôi, tôi phải suy nghĩ khó khăn để tìm ra tên người dùng độc đáo này, khác với bất kỳ người dùng nào trước đây! Cảm ơn bạn rất nhiều vì đã làm cho nó ngọt ngào và dễ dàng! Cách riêng của tôi đối phó với nó là sử dụng email của tôi như tên người dùng. Đáng buồn thay, vẫn có những trang web không chấp nhận nó! Sau đó, nếu một số loại thú vị sử dụng email của tôi như tên người dùng của mình? Không quá thực tế nếu email của bạn là [email protected] Nhưng tại sao chỉ đơn giản là không sử dụng Email và mật khẩu để tránh tất cả các mớ hỗn độn này?
Dưới đây một số hướng dẫn có thể để giảm đau của người dùng:
Chỉ buộc tôi để đăng nhập/lên nếu bạn hoàn toàn cần và cung cấp cho tôi một cơ hội để chọn không!
Làm cho trang này trở thành một trang, vì vậy tôi biết tôi đang làm gì và không cần phải nói, sử dụng càng ít trường nhập càng tốt. Lý tưởng nhất là chỉ Email và mật khẩu (có thể hai lần), không có tên người dùng!
Hiển thị biểu mẫu đăng nhập của bạn dưới dạng cửa sổ nhỏ ở đầu trang mà không tải lại và cho phép tôi loại bỏ nó bằng một lần nhấp chuột từ cửa sổ đó. Đừng bắt tôi phải tìm nút "đóng" hoặc thậm chí tệ hơn, tôi có thể nhầm lẫn với một thứ khác!
Tài khoản cho người dùng nhấp vào nút quay lại/ra và tải lại. Không xóa biểu mẫu khi tải lại! Đừng đặt nút rõ ràng chút nào! Nó là quá dễ dàng để bấm vào một cách tình cờ. Các dữ liệu bạn đang yêu cầu tôi điền vào không nên quá lâu ở nơi đầu tiên, rằng tôi không thể nhập lại nó mà không cần "hỗ trợ" để xóa.
Bây giờ đặt câu hỏi Q2. Ở đây chúng tôi đã biết rõ vấn đề giải quyết xung đột xảy ra bất kỳ lúc nào hai dữ liệu cần được hợp nhất. Ví dụ, dữ liệu ẩn danh và dữ liệu người dùng đã đăng ký, nhưng cũng bất cứ khi nào hai người dùng sửa đổi cùng một dữ liệu hoặc cùng một người dùng sửa đổi nó từ các thiết bị khác nhau vào các thời điểm khác nhau hoặc xung đột dữ liệu được lưu trữ cục bộ với dữ liệu máy chủ, v.v.
Nhưng bất kỳ nguồn nào là, vấn đề luôn giống nhau. Chúng ta có hai dữ liệu, nói hai đối tượng $ obj1 và $ obj2 và bạn cần tạo ra đối tượng đã hợp nhất của bạn $ obj3. Logic có thể đơn giản như quy tắc mà đối tượng của máy chủ luôn thắng hoặc đối tượng được sửa đổi lần cuối luôn thắng hoặc các khóa đối tượng được sửa đổi cuối cùng luôn giành được hoặc bất kỳ logic phức tạp nào khác. Điều này thực sự phụ thuộc vào bản chất của ứng dụng của bạn. Nhưng trong mỗi trường hợp, tất cả những gì bạn cần làm là viết hàm logic của bạn với các đối số $ obj1, $ obj2 trả về $ obj3.
Một giải pháp có thể hoạt động trong nhiều trường hợp là lưu dấu thời gian trên mỗi thuộc tính đối tượng (khóa) và để cho phép thay đổi khóa mới nhất tại thời điểm đồng bộ hóa. Tài khoản đó ví dụ: cho tình huống khi cùng một người dùng sửa đổi các thuộc tính khác nhau khi ẩn danh từ các thiết bị khác nhau.
Hãy tưởng tượng tôi đã sửa đổi phím A và B trên thiết bị AA ngày hôm qua, sau đó đăng nhập hôm nay từ thiết bị BB để nhập B khác và lưu nó vào máy chủ, sau đó chuyển về thiết bị AA của tôi, nơi tôi ẩn danh, để tham gia A khác mà không thay đổi B cũ từ ngày hôm qua, và sau đó nhận ra tôi muốn đăng nhập và đồng bộ hóa. Sau đó, địa phương của tôi B rõ ràng là cũ và nên rõ ràng không ghi đè lên giá trị của B mà tôi thay đổi gần đây hơn trên thiết bị BB. Trong trường hợp có vẻ phức tạp này, các giải pháp trên hoạt động liền mạch và hiệu quả. Ngược lại, đặt dấu thời gian chỉ trên toàn bộ đối tượng sẽ là sai.
Hiện tại trong một số trường hợp, có thể có ý nghĩa để giữ cả hai đối tượng và, ví dụ: phân biệt chúng bằng cách thêm các thuộc tính phụ, như trong trường hợp 1 được đề xuất trong câu hỏi của Radek. Ví dụ, Dropbox thêm một cái gì đó giống như "bản sao mâu thuẫn của người dùng X" vào cuối của tập tin. Giống như trong trường hợp Dropbox, điều này là hợp lý trong trường hợp các ứng dụng cộng tác, nơi người dùng muốn có một số điều khiển phiên bản. Tuy nhiên, trong những trường hợp đó, bạn là nhà phát triển chỉ cần lưu hai bản sao và cho phép người dùng xử lý vấn đề đó.
Nếu mặt khác, bạn phải viết một logic phức tạp dựa trên dữ liệu của người dùng, có hai bản sao khác nhau treo xung quanh có thể là một cơn ác mộng. Trong trường hợp đó, tôi sẽ chia dữ liệu thành hai nhóm (ví dụ: tạo hai đối tượng ra khỏi một nhóm). Nhóm đầu tiên có dữ liệu đại diện cho trạng thái của ứng dụng nói chung, điều quan trọng là duy nhất. Đối với dữ liệu đó tôi sẽ sử dụng độ phân giải xung đột như trên hoặc tương tự. Sau đó, nhóm thứ hai là người dùng cụ thể, nơi tôi sẽ lưu trữ cả hai dữ liệu dưới dạng hai mục riêng biệt trong cơ sở dữ liệu, đánh dấu chúng đúng cách (như Dropbox) và sau đó cho phép người dùng xử lý danh sách hai (hoặc nhiều) mục của dự án của họ . Cuối cùng, nếu sự phức tạp thêm về quản lý cơ sở dữ liệu làm cho nhà phát triển khó chịu, và vì Radek yêu cầu cung cấp tài liệu tham khảo tài nguyên, tôi muốn "giết hai con ruồi với một lần" bằng cách đề cập đến mục nhập blog StackMob offline Sync. cơ sở dữ liệu và chức năng quản lý người dùng và do đó làm giảm nhà phát triển khỏi nỗi đau đó. Chắc chắn có rất nhiều thông tin được tìm thấy khi tìm kiếm sự đồng nhất dữ liệu, giải quyết xung đột và các lượt thích. Để kết thúc, tôi phải thêm tuyên bố từ chối trách nhiệm bắt buộc, tất cả được viết ở đây chỉ là suy nghĩ và đề xuất của riêng tôi, rằng mọi người nên tự chịu rủi ro và không chịu trách nhiệm nếu bạn đột nhiên có quá nhiều người dùng hạnh phúc Hệ thống của bạn bị lỗi :)
Vì bản thân tôi đang làm việc trên một ứng dụng, nơi tôi đang triển khai tất cả các khía cạnh đó, tôi chắc chắn rất thích nghe ý kiến khác và những người khác phải nói gì về chủ đề này.
Truy cập Amazon, đăng nhập, đặt thứ gì đó vào giỏ, mở một trình duyệt khác và đặt một thứ khác. Bây giờ đi đến kiểm tra. – Gonfva