Phần 2 của loạt bài “Các kỹ thuật thiết kế Bot App“. Trong phần này mình và các bạn sẽ cùng nhau tìm hiểu những nguyên tắc cơ bản khi thiết kế, lập trình một ứng dụng bot là gì?
Các bạn có thể xem lại phần 1 của loạt bài viết này tại đây.
Các nguyên tắc cơ bản khi thiết kế, lập trình một ứng dụng bot
Thiết lập tương tác ban đầu
Lấy được ấn tượng đầu tiên luôn luôn là điều quan trọng mà mỗi lập trình viên cần quan tâm khi thiết kế ứng dụng. Giống với tương tác giữa người với người, việc thiết lập một cuộc hội thoại luôn bắt đầu bởi lời chào. Tuy nhiên lời chào ở đây không đơn thuần chỉ là một câu “xin chào” mà có nhiều cách để gửi thông điệp đầu tiên để bắt đầu một cuộc hội thoại dưới dạng một lời chào. Ở những ứng dụng di động thuộc hàng “TOP”, các bạn sẽ thấy được sự tinh tế của người làm ra ứng dụng đấy khi có những hình ảnh hoặc hiệu ứng hướng dẫn người dùng sử dụng ứng dụng, cách điều hướng giữa các trang hoặc giới thiệu những khả năng mà ứng dụng đó có thể làm được ở ngay màn hình đầu tiên sau khi mở ứng dụng. Với bot, người dùng cũng rất cần sự tinh tế đấy để dễ dàng bắt đầu sử dụng bot app của bạn. Nói một cách khác, chỉ với một câu “Xin chào” hoặc “Xin chào ông/bà/anh/chị ABC XYZ” là không đủ!
Vậy một ứng dụng bot cần phải bắt đầu một cuộc hội thoại với người dùng như thế nào?
Thử nhìn vào 2 ví dụ sau:
Bắt đầu một cuộc hội thoại giữa người và bot với việc bot chỉ hỏi một câu đơn giản “How can I help you?” như ở ví dụ 1 là một cách thiết kế khá tồi! Giả dụ bot của bạn có thể thực hiện hàng trăm thứ khác nhau, rất khó để người sử dụng có thể biết được hết những tính năng, những khả năng mà con bot của bạn có thể làm được. Nếu bot của bạn không chỉ ra nó có thể làm được những gì, liệu rằng người sử dụng có thể biết được những gì nó có thể làm được không?
Để giải quyết được vấn đề trên, từ trước tới nay người ta sử dụng đến một giải pháp đơn giản được gọi là “menu”. Áp dụng giải pháp này vào lập trình bot chúng ta phát hiện được rằng giải pháp đơn giản này lại phát huy tác dụng vô cùng lớn. Thứ nhất nó giải quyết được vấn để khám phá ở mức cơ bản những khả năng mà bot có thể làm được. Thứ hai nó giúp người sử dụng không phải gõ quá nhiều mà chỉ cần nhấp chuột để chọn, nhanh hơn rất nhiều so với việc gõ. Và điều thứ ba là nó giúp lập trình viên giảm đi được việc xử lý ngôn ngữ tự nhiên.
Đừng nghĩ rằng menu là một giải pháp không đủ thông minh. Nó rất thân thiện với người dùng. Hãy nhớ lại những điểm không làm nên sự thành công của một ứng dụng bot. Bot của bạn không nhất thiết cần phải quá thông minh!
Ở ví dụ 2 bot bắt đầu hội thoại bằng một câu xin chào giống với ví dụ 1 những kèm theo menu các chức năng mà bot làm được. Mặc dù cung cấp cho người dùng menu, tuy nhiên cũng không nên bỏ qua việc xử lý những gì mà người dùng nhập vào bằng tay. Lấy ví dụ với ví dụ 2 trên, giả sử như bot của bạn còn có khả năng hiển thị lịch sử mua hàng với câu lệnh “Show My Orders”. Trong trường hợp người dùng nhập câu lệnh trên thay vì chọn 3 tùy chọn trong menu của bạn, một ứng dụng bot “tốt” là ứng dụng xử lý được câu lệnh mà người dùng nhập vào thay vì trả về kết quả không hiểu hay không làm được vì không phải 1 trong 3 tùy chọn trong menu. Vậy nên hãy luôn luôn cố gắng xử lý những câu lệnh mà người dùng nhập tay trong khi hiển thị menu. Những tùy chọn được đặt trên menu là những tính năng ưu tiên mà người dùng có xu hướng bấm vào và thường người dùng sẽ bấm vào thay vì phải gõ chữ. Tuy nhiên đừng ép người dùng dùng bot của bạn theo cách mà bạn mong muốn!
Ngoài ra, xét ở khía cạnh quyền riêng tư, bạn cũng nên đặt những thông báo về bảo về quyền riêng tư của người sử dụng, cách sử dụng thông tin, dữ liệu cá nhân của người dùng hay những điều khoản sử dụng bot ở lời chào đầu tiên của bot của bạn.
Quản lý luồng hội thoại
Trên các ứng dụng web hay ứng dụng di động chúng ta có khái niệm giao diện dưới dạng các màn hình. Một ứng dụng có thể có nhiều màn hình khác nhau. Về cơ bản, một ứng dụng sẽ có một màn hình chính để điều hướng sang các màn hình chức năng như màn hình hiển thị danh mục các sản phẩm, màn hình hiển thị chi tiết sản phẩm, màn hình hiển thị giỏ hàng, …
Bot cũng sử dụng khái niệm giao diện tương tự tuy nhiên hơi khác một chút là những màn hình này được gọi là hộp thoại (dialog) trong bot. Dialog ở đây không hẳn là cần có giao diện đồ họa đẹp mắt mà nó đơn giản chỉ là một đoạn văn bản, các nút tương tác hay là một đoạn âm thanh nào đấy. Các dialog có thể gọi qua lại cho nhau giống như việc điều hướng qua lại giữa các màn hình trên ứng dụng web hay ứng dụng di động.
Khi thiết kế ứng dụng web, ứng dụng desktop, khái niệm xếp chồng màn hình lên trên nhau dạng “stack” là rất quen thuộc. Lấy ví dụ ở màn hình chính “Main Screen”, người dùng nhấp chuột vào một nút nào đó và màn hình tương tác (modal popup/modal dialog/modal screen/modal window) “New Order Screen” hiện lên. Lúc này, màn hình “New Order Screen” sẽ chiếm lấy quyền tương tác với người dùng bằng việc nó hiển thị chồng lên “Main Screen” (có thể kèm theo các hiệu ứng làm mờ màn hình “Main Screen” hay vô hiệu hóa tương tác với màn hình “Main Screen”). Màn hình “New Order Screen” cũng có thể điều hướng sang các màn hình khác và cũng sẽ bị màn hình được điều hướng tới chiếm quyền tương tác với người dùng tương tự. Một khi màn hình “New Order Screen” đã hoàn thành nhiệm vụ của nó và đóng lại, màn hình “Main Screen” sẽ được hiện ra và nhận tương tác của người dùng trở lại.
Đối với bot thì luồng xử lý ra sao? Về cơ bản xử lý xếp chồng dạng “stack” là hoàn toàn hợp logic với người sử dụng, tại một thời điểm người dùng chỉ tập trung vào tương tác, xử lý với một màn hình. Và một số bot framework hiện nay như Microsoft Bot Framework (Mình sẽ có một bài giới thiệu về Microsoft Bot Framework sau) đang sử dụng cách xử lý này trong việc xử lý các dialog trong ứng dụng bot.
Hãy cùng nhìn vào đoạn code sau, đây là đoạn code điều hướng tới màn hình “Main Screen” hay trong bot thì thường được gọi là “Root Dialog”.
Lưu ý: Các đoạn code ví dụ dưới đây đều sử dụng Microsoft Bot Framework.
public class MessagesController : ApiController
{
public async Task<HttpResponseMessage> Post([FromBody]Activity activity)
{
// Controller chuyển hướng sang RootDialog
await Conversation.SendAsync(activity, () => new RootDialog());
Đoạn code này thể hiện việc nhận request HTTP POST tới controller và sau đó kết nối tới RootDialog.
Trong RootDialog, bạn có thể gọi đến NewOrderDialog với đoạn code sau:
[Serializable]
public class RootDialog : IDialog<object>
{
public async Task StartAsync(IDialogContext context)
{
// RootDialog được khởi tạo và chờ message tiếp theo từ người dùng.
// Khi nhận được message từ người dùng, hàm MessageReceivedAsync sẽ được gọi
context.Wait(this.MessageReceivedAsync);
}
public virtual async Task MessageReceivedAsync(IDialogContext context, IAwaitable<IMessageActivity> result)
{
var message = await result; // Nhận được message!
if (message.Text.ToLower().Contains("order"))
{
// Người dùng đặt lệnh 'order'. Gọi đến New Order Dialog và đợi hội thoại đó kết thúc
// Sau đó, hàm ResumeAfterNewOrderDialog sẽ được gọi
await context.Forward(new NewOrderDialog(), this.ResumeAfterNewOrderDialog, message, CancellationToken.None);
}
// Người dùng nhập một câu lệnh khác không được hỗ trợ nên tạm thời bỏ qua và chờ message tiếp theo
context.Wait(this.MessageReceivedAsync);
}
private async Task ResumeAfterNewOrderDialog(IDialogContext context, IAwaitable<string> result)
{
// Ở đây sẽ nhận được kết quả trả về của NewOrderDialog.
var resultFromNewOrder = await result;
await context.PostAsync($"New order dialog vừa trả về kết quả: {resultFromNewOrder}");
// Và tiếp tục đợi message khác từ người dùng
context.Wait(this.MessageReceivedAsync);
}
Dialog Stack
Một khi một dialog nào đó được gọi, dialog đó sẽ được đặt lên trên cùng của “dialog stack” và chiếm quyền tương tác với người dùng (giống với cơ chế hoạt động của modal window). Mỗi một message mà người dùng nhập vào sau đó sẽ đi vào luồng xử lý của dialog được gọi.
Trong đoạn code trên, bạn điều khiển điều này bằng cách gọi context.Wait() và truyền vào callback mà sẽ được gọi tới khi người dùng gửi message tới cho bot của bạn. Nếu bạn sử dụng Microsoft Bot Framework và viết bot bằng C#, câu lệnh context.Wait(), context.Fail() hay context.Forward() hoặc context.Call() luôn là dòng code kết thúc trong callback. Nếu không làm vậy sẽ rất dễ gây ra lỗi bởi vì Microsoft Bot Framework không hiểu được rằng cần phải làm gì khi ở lần tới người dùng gửi một message nào đấy cho bot của bạn.
Lưu ý rằng khi sử dụng “stack” để xử lý các dialog, khi một dialog A gọi đến dialog B, dialog B sẽ được push vào stack đồng nghĩa với việc dialog A mất quyền tương tác với người dùng. Khi dialog B hoàn thành xong nhiệm vụ của nó thì nó sẽ được pop ra khỏi stack và nhường quyền tương tác với người dùng trở lại cho dialog A.
Xử lý yếu tố con người
Sẽ thật tuyệt vời nếu người dùng sử dụng bot của bạn theo đúng với luồng dialog mà bạn thiết kế ra, mở đầu bằng “root dialog”, gọi đến “new order dialog”, sau đó gọi đến “product search dialog”, lựa chọn một sản phẩm, xác nhận và quay trở lại “new order dialog”, hoàn thiện đơn hàng và trở lại “root dialog”.
Tuy nhiên cần nhớ lại mục địch của ứng dụng bot của bạn đó là tương tác với con người để giải quyết vấn đề của họ. Con người rất phức tạp! Chúng ta không tương tác, trao đổi thông tin với nhau theo cơ chế “stack”. Cùng xem ví dụ sau:
Sau một loạt qua lại giữa các dialog để đặt vé xem phim và ở dialog xác nhận đặt vé “Yes/No” cuối cùng, bot của bạn mong muốn nhận được câu trả lời xác nhận là “Yes” hoặc “No” nhưng người dùng lại không cho bot của bạn một câu trả lời “Yes/No” mong muốn và thay vào đó là một câu hỏi chẳng liên quan gì đến việc xác nhận việc đặt vé cả. Bạn sẽ xử lý trường hợp này ra sao?
- Yêu cầu người dùng cần trả lời câu hỏi xác nhận trước?
- Hủy toàn bộ việc đặt vé của người dùng và
cleartoàn bộstackđể trả lời câu hỏi về thời gian chiếu của bộ phim? - Trả lời câu hỏi về thời gian chiếu của bộ phim và sau đó quay trở lại câu hỏi xác nhận?
Đối với trường hợp trên có lẽ giải pháp cuối cùng là phù hợp hơn cả. Tuy nhiên không phải lúc nào giải pháp như giải pháp cuối cùng là phù hợp. Nó phụ thuộc vào tình huống, sẽ có bao nhiêu khả năng tình huống đó xảy ra, và điều người dùng mong muốn bot của bạn làm điều gì tiếp theo. Việc quản lý điều hướng qua lại giữa các dialog và không làm người dùng “đi lạc” trong ứng dụng bot của bạn là công việc rất cơ bản của việc thiết kế bot app tuy nhiên đây cũng là việc vô cùng thách thức với các lập trình viên.
Điều hướng – Navigation
Một trong những nguyên tắc thiết kế cơ bản trong việc điều hướng trên ứng dụng web hay ứng dụng di động là cho người sử dụng biết họ đang ở đâu hay nói cách khác là đang ở màn hình nào. Trang web có breadcrumb, ứng dụng di động có menu. Tuy nhiên với bot thì việc giúp người dùng định hình được họ đang ở đâu trong một cuộc hội thoại chưa thực sự có một giải pháp nào ổn cả tính đến thời điểm mình viết bài viết này!
Tạm gác lại việc giúp người dùng định hình được họ đang ở đâu trong một cuộc thoại, việc đảm bảo rằng người dùng không “đi lạc” trong bot app của bạn được cần được chú trọng khi lập trình ứng dụng bot! Người dùng có thể “back” trong một cuộc thoại? Người dùng có thể “cancel” một tác vụ nào đấy? Làm sao để quay trở lại “root dialog”/”main menu”?
Hãy cùng phân tích một số tình huống liên quan đến điều hướng mà bot xử lý không khéo và cách giải quyết vấn đề đó dưới đây:
Bot “lầy”
Hãy xem một ví dụ sau:
Hãy đặt mình vào tình huống này và bạn sẽ thấy sự bực tức của người dùng. Người dùng muốn hủy việc đặt vé và muốn làm lại từ đầu. Tuy nhiên việc không tính đến trường hợp này và lặp đi lặp lại một câu hỏi giống nhau là một lỗi phổ biến trong lập trình bot.
Để giải quyết trường hợp này thì có rất nhiều cách. Hãy giải quyết với một cách đơn giản đó là “trigger” một dialog nhắc nhở sau 3 lần nhập câu trả lời không phù hợp:
PromptDialog.Choice(context, this.OnOptionSelected, new List<string>() {
FlightsOption, HotelsOption
}, "Are you looking for a flight or a hotel?", "Not a valid option", 3);
Đây là một cách giải quyết không được thông minh cho lắm khi mà bot không trực tiếp xác định được message mà người dùng nhập vào là hủy việc đặt vé mà dựa vào số lần người dùng không đưa ra câu trả lời phù hợp để hủy nhưng ít nhất là cách này cũng chặn được sự “lầy lội” của bot khi lặp đi lặp lại một câu hỏi.
Bot “khờ”
Hãy xem ví dụ sau:
Trong tình huống này bot hiển thị một “prompt dialog” (dạng dialog yêu cầu nhập thông tin) yêu cầu nhập mã cho một yêu cầu nào đấy. Tuy nhiên người dùng lại không rõ là mã cần điền là mã nào nên đã theo một cách tự nhiên đặt lệnh trợ giúp “Help?”. Tuy nhiên “Help?” là một đoạn string hợp lệ, và thay vì hiển thị một dialog trợ giúp thì bot đã chấp nhận giá trị mà người dùng nhập vào để xử lý.
Với trường hợp này thì cách giải quyết mà nhiều người sẽ hướng đến đó là kiểm tra xem giá trị mà người dùng nhập vào có rơi vào các câu lệnh như “cancel”, “help”, … hay không. Tuy nhiên vấn đề là bạn phải làm điều này ở mọi dialog trong ứng dụng bot của bạn.
Với Microsoft Bot Framework thì bạn không cần phải làm điều trên một cách vất vả như vậy! Framework này cung cấp cho bạn khả năng override lại “prompt dialog” mặc định để thêm logic xử lý cho các câu lệnh như “cancel”, “help” hay các xử lý cần thiết khác. Cùng xem đoạn code sau:
[Serializable]
public class PromptStringRegex : Prompt<string, string>
{
private readonly Regex regex;
public PromptStringRegex(string prompt, string regexPattern, string retry = null, string tooManyAttempts = null, int attempts = 3)
: base(new PromptOptions<string>(prompt, retry, tooManyAttempts, attempts: attempts))
{
this.regex = new Regex(regexPattern, RegexOptions.Compiled | RegexOptions.IgnoreCase | RegexOptions.IgnorePatternWhitespace);
}
protected override bool TryParse(IMessageActivity message, out string result)
{
var quitCondition = message.Text.Equals("Cancel", StringComparison.InvariantCultureIgnoreCase);
var validEmail = this.regex.Match(message.Text).Success;
result = validEmail ? message.Text : null;
return validEmail || quitCondition;
}
}
Đoạn code trên thể hiện việc tạo mới một “prompt dialog” có tên PromptStringRegex, kế thừa generic class Prompt<string, string>, một “prompt dialog” chuẩn trong Microsoft Bot Framework. Trong class mới này có thêm logic xử lý câu lệnh “cancel” cũng như khả năng đối chiếu giá trị nhập vào có format phù hợp với regex được truyền vào hay không. Việc sử dụng “prompt dialog” mới này như sau:
private const string PhoneRegexPattern = @"^(\+\d{1,2}\s)?\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}$";
public async Task StartAsync(IDialogContext context)
{
var promptPhoneDialog = new PromptStringRegex(
"Please enter your phone number:",
PhoneRegexPattern,
"The value entered is not phone number. Please try again using the following format (xyz) xyz-wxyz:",
"You have tried to enter your phone number many times. Please try again later.",
attempts: 2);
context.Call(promptPhoneDialog, this.ResumeAfterPhoneEntered);
}
Đoạn code trên thể hiện việc bot muốn người dùng nhập vào số điện thoại. Với PromptStringRegex thì giờ đây bot của bạn sẽ dễ dàng xử lý được những trường hợp mà người dùng nhập vào giá trị không mong muốn và còn xử lý được khi người dùng nhập vào lệnh “cancel” để hủy thay vì nhập số điện thoại.
Bot tỏ ra “nguy hiểm”
Hãy nhìn vào ví dụ sau:
Nếu gặp phải tình huống trên liệu bạn có đoán được tại sao không? Có thể là bot bị hết pin? Có thể bot đang vướng ở đâu đấy. Hay có thể là bot cần thời gian để tìm câu trả lời cho câu hỏi của bạn. Việc không đưa ra bất kỳ dấu hiệu nào là bot của bạn vẫn đang hoạt động là một thiết kế không hề tốt một chút nào! Trong trường hợp này người dùng không biết cần phải làm gì? Lặp lại câu hỏi hay là hủy và làm lại từ đâu?
Có một vài gợi ý để giải quyết vấn đề trễ trong việc phản hồi lại người dùng theo các trường hợp khác nhau:
- Quá trình xử lý câu hỏi mất nhiều thời gian: Trong trường hợp này bot không phản hồi lại người dùng vì nó còn đang bận để xử lý câu hỏi của bạn và việc xử lý này tốn nhiều thời gian. Hướng giải quyết ở đây:
- Khởi tạo một timer với một thời gian phù hợp ví dụ là 5 giây
- Nếu bot của bạn xử lý xong câu hỏi của người dùng dưới thời gian cho phép, hủy timer và trả lời câu hỏi của người dùng
- Nếu quá thời gian cho phép, hiển thị một thông báo là bot vẫn đang xử lý câu hỏi và nhắc nhở người dùng quay trở lại sau
- Tùy vào nền tảng một số nền tảng có hỗ trợ “typing indicator” (chỉ báo đang nhập liệu, thường thấy trên Facebook Messenger hay Skype khi người dùng đang gõ chữ thì người chat cùng sẽ nhìn thấy chỉ báo đang nhập liệu này). Bạn có thể sử dụng khả năng này để thông báo với người dùng rằng bot đang bận gõ câu trả lời cho câu hỏi của bạn và cũng giúp người dùng biết được rằng bot đang không gặp vấn đề gì.
- Xảy ra lỗi: Bot cũng chỉ là một phần mềm mà thôi vậy nên việc xảy ra lỗi là chuyện hết sức bình thường! Khi xảy ra lỗi chúng ta sẽ xử lý nó trong logic của dialog. Dưới đây là một số hướng giải quyết:
- Clear stack và làm lại từ đầu. Tuy nhiên trường hợp này rất khó chấp nhận trong những ứng dụng bot khi đưa ra thị trường.
- Thu thập từ xa các thông tin cần thiết trong trường hợp xảy ra lỗi để có thể hiểu được vấn đề là gì và đưa ra cách khắc phục tự động cho bot của bạn.
- Xây dựng cơ chế “đánh chặn” message để xây dựng thuật toán kiểm tra các vấn đề bất thường có thể xảy ra. Ví dụ ở đây là thuật toán phát hiện được rằng người dùng gửi nhiều message mà bot không phản hồi từ đó phát hiện được vấn đề và đưa ra hướng giải quyết như hiển thị dialog thông báo và tự động
clearstackchẳng hạn. Trong Microsoft Bot Framework có khái niệm “middleware” cho việc đánh chặn message.
Bot “thánh phán”
Nhìn vào ví dụ sau:
Nhìn vào ví dụ trên thoạt đầu bạn thấy rằng con bot này rất thông minh. Biết được mình tiêu bao nhiêu và đang làm gì. Tuy nhiên phân tích sâu hơn thì thực ra con bot này đang cung cấp thông tin thừa thãi, những thông tin mà người dùng không cần biết. Đơn thuần nó đang “phán” mà thôi!
Ở một số framework hỗ trợ xây dựng bot có cung cấp cho lập trình viên khả năng cho phép bot lắng nghe một sự kiện nào đấy rồi trả về message khi sự kiện xảy ra. Ở Microsoft Bot Framework có proactive bot. Những message được trả về theo cách này được tạm gọi là “proactive message”. Khả năng này rất hay nhưng nếu không xử lý khéo nó sẽ trở thành thảm họa. Một số điểm cần lưu ý:
- Bot gửi quá nhiều thông tin không cần thiết.
- Thông tin bot gửi không chứa nhiều thông tin hữu ích.
- Proactive message khá giống với cơ chế push notification trên ứng dụng di động. Do vậy bạn nên có phần thiết lập tần suất nhận cũng như nội dung của proactive message.
- Nếu người dùng yêu cầu bot dừng lại việc gửi các proactive message, bot của bạn cần có cơ chế để làm được điều đó.
Bot “thù lâu nhớ dai”
Nhìn vào ví dụ sau:
Một trong những khía cạnh tốt của bot đó là khả năng nhớ các thông tin, cuộc hội thoại giữa các thiết bị và theo thời gian. Tất nhiên điều này còn phụ thuộc vào việc framework xây dựng bot mà bạn sử dụng có hỗ trợ hay không. Lấy ví dụ người dùng có thể bắt đầu hội thoại đặt vé với bot của một hãng đặt vé trực tuyến bằng Skype trên điện thoại tuy nhiên vì lý do nào đấy mà không thể xác nhận đặt vé được luôn và sau đó thực hiện xác nhận đặt vé bằng Skype trên laptop chẳng hạn.
Tuy nhiên có một vấn đề đó là đôi lúc bot của bạn cần phải quên đi những gì đã trao đổi với người dùng trong quá khứ và khởi tạo lại một hội thoại hoàn toàn mới. Cụ thể với ví dụ trên, người dùng muốn đặt vé đi sang nước Ý, nhưng bot lại nhớ quá dai khi mà thay vì thực hiện quy trình đặt vé tới Ý thì nó lại hỏi người dùng là xác nhận việc thu phí $200 cho phiên đặt vé tới Las Vegas mà người dùng đã thực hiện qua bot 3 tháng về trước. Trong trường hợp này chúng ta đề hiểu rằng bot cần phải quên đi việc đặt vé trước đó tới Las Vegas của người dùng và thực hiện quy trình đặt vé tới Ý.
Việc xóa lịch sử hội thoại sẽ không xảy ra một cách tự động mà sẽ do lập trình viên quyết định khi nào hoặc những gì cần được xóa. Một trong những ví dụ cho việc này đó là việc thiết lập thời gian hết hiệu lực hay hết hạn phiên hội thoại. Ví dụ như nếu message được gửi tới sau X giờ, bot sẽ hiểu rằng toàn bộ hội thoại trước đó cần được quên đi và bắt đầu lại từ đầu. Các quy tắc này do nhà phát triển bot quyết định tùy thuộc vào các tình huống khác nhau trong quá trình bot được sử dụng.
Như vậy mình và các bạn đã cùng nhau tìm hiểu 3 nguyên tắc thiết kế cơ bản của một ứng dụng bot đó là thiết lập tương tác đầu tiên, quản lý luồng hội thoại và điều hướng. Trong phần 3 của bài viết, mình và các bạn sẽ tiếp tục tìm hiểu các nguyên tắc thiết kế cơ bản còn lại trong lập trình ứng dụng bot.
Trả lời