I'm trying to allow users to say a dollar amount as input to a Bixby capsule.
So I made a concept of type money.Currency:
structure (Amt) {
role-of (money.Currency)
description (Amount to spend)
}
And then I gave some training examples using it:
[g:SomeGoal] I want to pay {[g:Amt] ($)[v:viv.money.PrefixSymbol:$](25.32)[v:viv.money.CurrencyValue]}
This works fine when the user enters their dollar amount in text, but it frequently fails if the user tries to speak the amount aloud to Bixby.
Example 1 (fails): The user says "I want to pay twenty-five dollars thirty-two cents." Bixby parses this as "I want to pay $25 32 cents" and populates the Amt field with just $25, leaving out the cents.
Example 2 (fails): The user says "I want to pay twenty-five thirty two." Bixby parses this as "I want to pay 2532" and populates the Amt field with $2532, again failing to fill in a value for the cents.
Example 3 (succeeds): The user says "I want to pay twenty-five point three two dollars." Bixby correctly parses this as "I want to pay $25.32" and fills in the Amt field with $25.32. This sounds very unnatural for English speakers though, and I do not think it will be easy to train users to speak this way.
Example 4 (sometimes succeeds): The user says "I want to pay twenty-five dollars and thirty-two cents." Bixby sometimes parses this correctly, other times as "I want to pay $25 in 32 cents" or other similar corruptions.
Anybody have suggestions for getting Bixby to consistently understand dollar amounts in natural language? I am okay with example 2 failing since it is ambiguous, but mainly I would like examples 1 and 4 to succeed consistently. I do have one idea for a workaround (a separate cents field that's manually added to the dollars field by an action), but I'd prefer to avoid that if possible since this seems like a common case that Bixby should be able to handle on its own.
Thank you for bringing this to our attention. I tried the following sentence "Pay one hundred dollars and 25 cents" multiple times and Bixby was able to transcribe it accurately every time.
But your use case (especially #1) is valid as some users tend to not use "and" to tie dollars and cents together. We will raise this internally with our team but I would suggest that you open a ticket with Bixby Developer Support so we can tie your ticket with the issue and keep you posted when its fixed.
Also, your workaround of using a second property to capture cents should work fine too. Let us know if you run into any issues.
Related
I wanted to try the currency converter feature of bixby where i ask it to convert the value from lets say USD to INR. This feature was in earlier updates of bixby. But when i tried it now, it wont work. If anyone could help me that would be great.
Thanks
Depending on how your questions is phrased, you should be presented a list of capsules that can address your use case.
For example, asking, "What is 50 Dollars in Indian Rupees" provides me with a list of two capsules that can serve this request. When I select one (I arbitrarily chose CNBC), I get the answer I requested, "50 U.S. dollars are equal to 3751.5 Indian rupees".
I'm currently working on a bot that helps a user fill in a form in a conversational way. I'm wondering if I should pick LUIS or azure text analytics for this. Or maybe both? Since I'll need to respond to certain intents but answering a question obviously has no intent. Or can I count answering a question as an intent. Either way I'll have to deal with various types of answers ranging from well ranges to names, dates and sentiments. And to add to this: it'll need to support dutch.
Simple example:
Bot asks:
On a scale of 1 - 10 how do you feel about some subject?
User responds:
Well I would give it a 10
Bot extracts:
feelingScore = 10
More complex example
Bot asks:
How do you feel about some subject?
User responds:
Well I would give it a 10
Bot extracts:
feeling = "10"
User responds:
I honestly didn't feel that good about it.
Bot extracts:
feeling = "not that good" (or possibly a sentiment score)
Since there's no action based on user's input, I don't see a reason for using LUIS. You can achieve what you want using Text Analytics.
PS: Please notice that even tough users reply with a 10, the sentiment analysis may not be 100%.
Example:
"I will give it a 10" -> sentiment score is 95
"Well I would give it a 10" -> sentiment score is 85
But at the same time, you can check the NAMED ENTITIES and get the extracted number from it (when provided in the answer)
https://azure.microsoft.com/en-us/services/cognitive-services/text-analytics/
Im tring to create a booking system for a restaurant so the assistant go to ask to user number of guest, time and day to reserve, and finally the name and the phone number of guest! But many time the phonenumber is confused by the guest number.
I set in parameters for #guest the value of #sys.number and for $telephone the entity of #sys.phone-number, but sometimes get wrong recognize. I could make it work?
The Dialogflow team has a really full-featured example on Github here (it's a bike shop, rather than a restaurant, but most of the functionality is the same). Give it a look for some inspiration.
Regarding the specifics of recognizing phone numbers: I'd recommend adding a bunch (like more than 10) of example training phrases to the appropriate Intent that include phone numbers. Often the problem with matching these things is just a matter of the number of examples the system gets to learn from.
Good luck!
Suppose i want to make a pizza ordering DialogFlow agent. To order a pizza we need 3 things: size, type and toppings.
If we want to go with follow-up intents approach rather than using entities then there will be so many combinations in which user might provide the information.
1: i want a pizza -> no info
2: i want small pizza -> size
3: i want small cheese pizza -> size and type
4: i want small cheese pizza with olives -> size, type and toppings
5: i want small pizza with olives -> size and toppings
...
and so on
How to solve this problem?
There will be so many combinations if we have more entities (2^n combinations)
Note 1: cannot take entities and slotfilling option as there are so many problems if we go down that road, like re-prompts loop, validation etc.
Is there any better solution?
Note 2: If we use entities, mark them required, and set prompts then many times if it does not get desired input from user it get stuck in re-prompt loop, i.e it keeps asking user same (or random) prompt for same entity. In my use case, it is bad for user experience. If we use follow-up intents instead, then we can set fallback intents for all those intents which solved this problem. (please note that this is just example of the use case)
This is another example of why I used follow-up intents, it solved my date capturing problem as well. I took #sys.date.recent and set a fallback intent to capture inputs like last week, last month etc, this was not possible using slots.
First, remember that Intents should reflect what the user says, not necessarily what you are doing.
On the surface, it isn't clear why slot filling (either with fulfillment or using built-in prompts) won't meet your needs. Since you've indicated that all three bits of information are necessary (size, type, and toppings), you can mark them as such in your phrases and Dialogflow will prompt for the missing information until it gets everything.
You almost certainly do not want to use Followup Intents. These are good when you always have a specific response that you send that will always have a very narrow set of replies from the user, but are very poor if the response from your action will prompt the user to reply in many different ways.
Instead, I would use a related concept: Contexts. (At least if you're not going to use slot filling.) When you ask the question of what they want, set a Context so you know they are. Then have one or more Intents that have this as an Input Context that accept the various things the user might say. Your webhook should see if you have the information you need and, if not, prompt them what else you're looking for. At the end, prompt for a confirmation, but they may say something that adjusts the order.
I am a bit confused with the way people write statements in the Gherkin language to describe various actions performed for acceptance testing.
In some articles people use "I" and in some articles people use "User".
The same is the case for reaction (Then) statements:
Case 1 --> xyz page should be displayed
Case 2 --> xyz page is displayed
Ex 1:
Given statement abc
When user performs action A
Then screen xyz should be displayed
Ex 2:
Given statement abc
When I perform action A
Then screen xyz is displayed
Is it better to write "user" or "I", and is it better to write "should be" or "is", so that my BDD scenarios are presentable and correct as per standards?
References to any article would also be a great help. Thanks in advance.
Both are correct, and have different benefits.
Dan North, who invented BDD, says he prefers 1st person ("I"), as it allows him to put himself in the user's shoes. However, he's often used 3rd person ("he / she / the customer") as he does in his introductory article.
The first-person use can help to make a scenario fit with the standard story template:
As <a stakeholder>
I want <something>
So that <goal>.
If the stakeholder is the user, then it makes sense to use "I" again in the scenario.
However, sometimes scenarios' outcomes aren't really for the benefit of the user.
As the moderator of the site
I want users to prove that they're human
So that I can limit spam.
In this case, it would be odd to put the scenario in the perspective of the user, because the user doesn't really want to be filling in that captcha box. We'd probably use 3rd person here.
Given an odd-looking number "31" on a door frame
When the user identifies the number as "31"
Then the system should authenticate them as being human.
You may also find that you have more than one stakeholder whose outcomes are important. In that case, putting the scenario in the 3rd person can help to spot any other outcomes or important stakeholders that might not have been included.
Given Suzanne searches for a taxi for 4pm to take her to hospital
And the estimated price is $23
When she books the taxi
Then she should get a confirmation email
And the driver should be notified of the trip
And she should be charged $23.
Because both Suzanne, and the driver, and Uber, are all involved in this scenario, it makes more sense to put them in the 3rd person.
I tend to prefer the 3rd person, especially for large products with a lot of scenarios, as I find it confusing to have to switch 1st person roles, and it allows for consistency. It also means you can give the actors in the scenarios memorable names and talk about them more easily ("The one where Clarence Clumsy types his number in wrong", for example).
However, remember that when you're talking to your stakeholders to get hold of these scenarios, the most important thing is the conversation. Write down their words as closely as you can, and only compromise the language afterwards when you come to rephrase it using Gherkin.