Hoàn thành Tiếp thị: Xe buýt tương tác người dùng

Một hoạt động tốt không chỉ cần có lối chơi hấp dẫn mà còn phải cung cấp cho người dùng trải nghiệm trọn vẹn, xử lý phản hồi tương tác tốt và nâng cao cảm giác tương tác tổng thể của người dùng. Vậy làm sao chúng ta có thể đạt được mục tiêu này? Có lẽ bạn có thể thử xây dựng một "xe buýt tương tác người dùng". Chúng ta hãy cùng xem xét phân tích của tác giả để biết cách hiểu và thiết lập nó một cách cụ thể.

1. Giới thiệu

Trước đây chúng ta đã nói về việc tách rời và kết nối giữa các lối chơi, về cơ bản đã giải quyết được 50% các vấn đề về chức năng. Về cơ bản, chúng ta có thể xây dựng một hoạt động hoàn chỉnh, nhưng vẫn còn một khoảng cách so với một hoạt động tốt, chủ yếu là về trải nghiệm của người dùng và hiệu ứng của hoạt động. Bài viết này sẽ nói về cách xử lý các vấn đề tương tác của người dùng tham gia hoạt động từ góc độ back-end.

Khi thiết kế kiến ​​trúc hệ thống hoặc trừu tượng hóa các chức năng, khả năng của hệ thống được phân chia vì những lý do như khả năng mở rộng. Mỗi lối chơi có thể tồn tại độc lập và có thể được liên kết động. Thiết kế kiến ​​trúc hệ thống rất tuyệt vời, nhưng các hoạt động được xây dựng theo cách này sẽ làm hỏng trải nghiệm của người dùng nếu phản hồi tương tác không được xử lý tổng thể. Ở một mức độ nào đó, người dùng vẫn cảm thấy đây là một hoạt động giống như trò giải đố. Mỗi lối chơi đều có tương tác riêng, người dùng không cảm nhận rõ mối liên kết và có thể xảy ra xung đột trong tương tác giữa các lối chơi. Tính chính trực không đủ mạnh.

Các hoạt động do toàn bộ hệ thống của chúng ta tạo ra phải hoàn chỉnh thay vì rời rạc. Chi phí cho mỗi quá trình tùy chỉnh đều quá cao và việc từ bỏ khâu biên đạo trò chơi có nghĩa là phải quay lại vạch xuất phát. Vì vậy, để cung cấp trải nghiệm tương tác tốt hơn với người dùng và giảm chi phí phát triển logic tương tác hoạt động, chúng ta cần một "bus" tập trung chịu trách nhiệm cho toàn bộ tương tác của người dùng.

2. Giải pháp

1. Phân tích vấn đề

Trách nhiệm của bus tương tác là "xử lý tập trung phản hồi sự kiện trong quá trình tương tác của người dùng và chịu trách nhiệm về ý nghĩa chung của tương tác". Các sự kiện được phân loại theo nguồn gốc của chúng:

Có hai loại chính: các quy tắc tương tác hoạt động đã được thiết lập (lối chơi, giữa các trò chơi) và các hoạt động vận hành.

1. Theo hình thức thể hiện, có thể chia thành: thông báo nhắc nhở, cửa sổ bật lên, thông báo không hoạt động, tin nhắn riêng tư, thông báo đẩy, v.v.
2. Theo thời gian, về cơ bản có thể chia thành tiếp cận theo thời gian thực (chấp nhận thụ động) và kích hoạt trong quá trình tương tác (kích hoạt chủ động).

Về bản chất, tất cả các hành động này đều là "phản hồi trong tương tác" giữa hoạt động và người dùng. Chúng ta chỉ cần nắm bắt bản chất của sự chạm, sau đó phân tích bối cảnh, hình thức và thời điểm của "phản hồi", rồi tóm tắt và trừu tượng hóa nó.

2. Xác định vị trí

Bus tương tác chịu trách nhiệm phản hồi về hoạt động trong quá trình tương tác của người dùng, do đó nó phải tồn tại dưới dạng "lát cắt". Mọi phản hồi tương tác đều diễn ra ở đây. Nói cách khác, bus sự kiện kinh doanh và trò chơi cung cấp chức năng trình bày tích hợp, còn bus tương tác cung cấp phản hồi tương tác thống nhất của người dùng. Hai phần này cung cấp cho người dùng trải nghiệm tốt xung quanh bối cảnh tham gia của người dùng.

3. Tóm tắt

Đầu tiên hãy xác định bối cảnh: Chúng ta đang giải quyết các vấn đề phản hồi tương tác trong quá trình người dùng tham gia vào trường hoạt động. Mục đích cốt lõi của quá trình xử lý là phản hồi . Các vấn đề chính cần giải quyết là phản hồi không nhất quán trong quá trình tương tác, phản hồi quá nhiều hoặc quá ít, không có khả năng quản lý tập trung và chi phí bảo trì tương đối cao.

Đối với người vận hành, phản hồi là một loại quy tắc tương tác hoạt động cần được cấu hình, quản lý và kích hoạt. Đối với người dùng, phản hồi có thể được đẩy hoặc kéo chủ động khi tham gia một hoạt động. Những phản hồi này có nội dung riêng, hình thức thể hiện và đối tượng tiếp nhận khác nhau. Có những ưu tiên hoặc logic loại trừ lẫn nhau giữa các phản hồi, v.v. Nhìn chung, phản hồi có thể được tóm tắt sơ bộ như sau:

Do đó, bạn chỉ cần triển khai một dịch vụ có thể tạo và duy trì phản hồi cũng như xử lý thống nhất mối quan hệ giữa các phản hồi.

4. Chạy chế độ xem

Trước tiên, chúng ta hãy xem xét chế độ xem thời gian chạy tổng thể và sau đó giải thích chi tiết cách đạt được quá trình xử lý thống nhất phản hồi tương tác.

Trước hết, nguồn sự kiện của bus tương tác có thể là một sự kiện không đồng bộ, chẳng hạn như hoàn thành nhiệm vụ, hỗ trợ thành công, v.v., hoặc có thể là cú nhấp chuột hoặc mở giao diện của người dùng hoặc lệnh gọi lại liên hệ tập trung do thao tác phát hành. Sau khi nhận được sự kiện, chúng ta cần tạo phản hồi tương tác cho chính sự kiện đó và phản hồi tương tác liên quan đến sự kiện đó. Ví dụ, sẽ có lời nhắc chúc mừng khi nhiệm vụ hoàn thành và sẽ có hành động làm mới hoặc hiệu ứng đặc biệt khi nhiệm vụ hoàn thành để tăng cơ hội giành giải thưởng.

Sau khi nhận được phản hồi tương ứng, thông tin phản hồi sẽ được đổ vào bộ đệm hiện có hoặc trực tiếp trải qua quy trình tiếp theo, sau đó sự kiện sẽ được chuẩn hóa theo các quy tắc. Nếu có bộ đệm, nó sẽ được hợp nhất với các sự kiện hiện tại khác hoặc bị loại bỏ và tích hợp với trình tự tương tác giao diện hiện tại để xác định trình tự cuối cùng của bộ đệm hiện tại đang chờ được sử dụng.

Chuỗi tiêu hao cuối cùng có thể được đẩy chủ động đến người dùng thông qua liên kết dài của máy chủ hoặc được đưa đến người dùng khi người dùng tương tác.

5. Quy tắc tiêu thụ

Việc duy trì các quy tắc tiêu thụ của toàn bộ bus là phần phức tạp nhất của toàn bộ quá trình triển khai. Thông thường, các phương pháp tiêu thụ của hàng đợi tiêu thụ có thể được chia thành hai loại: kéo và đẩy. Logic thông thường của pull là thu thập hành vi phản hồi của tương tác của người dùng giữa tương tác cuối cùng và tương tác hiện tại, trong khi push thường là logic tiêu thụ theo thời gian và định lượng, và việc tiêu thụ phản hồi phải hỗ trợ xử lý đa chiều, chẳng hạn như chỉ tiêu thụ những phản hồi liên quan đến một lối chơi nhất định và chỉ tiêu thụ những phản hồi liên quan đến tương tác này.

Do đó, phản hồi có tính năng xử lý kinh doanh mạnh mẽ. Việc triển khai phần này có thể rất phức tạp hoặc rất đơn giản, tùy thuộc vào tình hình kinh doanh. Nói chung, khía cạnh hoạt động chỉ cần gói gọn các quy tắc một chút và sẽ không trở nên quá phức tạp.

Chúng ta hãy lấy một ví dụ khá phổ biến để bạn có cảm nhận đơn giản:

• Chế độ tiêu thụ <kéo, đẩy <thời gian, số lượng>, kéo & đẩy <thời gian, số lượng>;
• Bộ tính năng <các tính năng đã hợp nhất, ưu tiên, cờ loại bỏ, thẻ phản hồi>.

Nhiều hoạt động đơn giản không có yêu cầu phản hồi mạnh mẽ. Lúc này, chúng ta chỉ cần một bộ quy tắc thời gian mặc định đơn giản hoặc không cần quy tắc đặc biệt nào.

Thực hành thiết kế quy tắc trong phần này có liên quan chặt chẽ đến tình hình kinh doanh. Với chúng tôi, chỉ cần đảm bảo các quy tắc có thể được áp dụng và gỡ bỏ một cách linh hoạt là đủ. Nếu bạn muốn trao đổi thêm, chúng ta có thể trao đổi chi tiết riêng.

3. Suy nghĩ cuối cùng

Bài viết này sẽ dừng lại ở đây. Nhiều chi tiết kỹ thuật liên quan không được thảo luận chi tiết, chẳng hạn như định nghĩa về DSL, cách tạo văn bản, bộ lưu trữ là redis hay mysql, SDK có cung cấp dịch vụ hay rpc được sử dụng với thế giới bên ngoài hay cơ chế đếm bộ đệm, cơ chế đẩy, hiệu suất và đảm bảo tính nhất quán của dữ liệu, v.v., có thể được xác định dựa trên lựa chọn công nghệ và kịch bản kinh doanh của công ty. Nếu bạn có bất kỳ câu hỏi liên quan nào, bạn có thể trò chuyện với tôi từng câu hỏi một. Ý tưởng được mô tả trong bài viết này không chỉ giới hạn ở các tình huống hoạt động. Một số hệ thống thông báo hoặc hệ thống liên lạc cũng sử dụng ý tưởng này để giải quyết vấn đề.