I started working with Dialogflow a couple of weeks ago. It's nice to learn the concept of intent and (input/output) context through which Google models and defines the daily conversation flow in natural language. I understand how intent and context work at the current setting. But to me the function of context can be achieved by only using intent. You may argue whether the word 'intent' is proper for this usage but it's another discussion. So instead of input and output context just do input and output intents. In the implementation make sure the parameters and information of current conversation is carried to the following intent. And the following intent has again its output intent and the talk continues.
Can anyone correct me if I'm wrong?
Intents represent a user action, typically what a user says, including the parameters from that specific utterance.
Contexts serves two purposes:
Hold the parameters from an Intent or that have been set through Fulfillment for some period of time.
When used as an Input Context, limit what Intents can be triggered.
While you can certainly "send the parameters forward" from one Intent to another, this is a very linear way of thinking, and rapidly falls apart in complicated conversations. Using Contexts to store parameters and other info, as the first bullet suggests, makes this a lot easier, so your user can wander around in the conversation, and yet you are still maintaining the overall state.
As for the second bullet, this is used to change how we understand what the user has said based on other parts of our conversation. (This matches how humans handle conversations.)
So my response saying "Yes" means different things depending if I'm asking to delete a message or send a message - Contexts help us manage that.
Related
in uml - system sequence diagram, can the system ask input from the actor (see attached picture)
In my example, the scenario is: system is prompting a confirmation input from user and user is to enter in the input.
Wondering if this is the correct representation for it? I asked as usually I have done it the other way round, in which actor gives input to the system and system return the output based on input...
Preliminary remark
The practice of showing an actor in an interaction diagram is well accepted and quite common.
Nevertheless, in principle, an UML interaction diagram such as a sequence diagram, should show interactions between lifelines within an enclosing classifier:
The actor being external to your system, it’s not a part of any enclosing classifier in your system.
As a consequence, this is valid UML only if the scope of your model is larger than the IT system, i.e. you model the organisatiin that uses your IT system.
Moreover the message semantic is not clearly defined for human participants, which is exactly the issue behind your question
Be consistent
If you choose to go on with your modeling approach and consider the actor as any other classifier, then your actor instance should behave as any other object.
The flow of messages shows which object is the sender of the message and which object responds. You should consistently keep this logic, as you did in your diagram. It will be btw one of the rare place on your model where you can show that the system is at the origin of this specific interaction and not the user. (hint: don’t forget the execution specification on the lifeline: it’ll increase the readability)
If you would materialize the free-will of the actor by an arrow/message in the opposite direction, you would only increase the ambiguity further: this would give the impression that the actor is at the initiative of the message, and that the actor could send a completely different message instead. And I’m not sure that your system is designed for responding to arbitrary messages from the user.
Another alternative?
A less ambiguous alternative could be to show the interaction between a system core element and an element that represents the UI: the UI element acts as proxy for the user, but since it’s an object like any other, the interpretation of message flows is unambiguous.
This is one of the idea behind the ECB decomposition, the C being a use-case specific controller (so it links this interaction to the requirements) and the B being the UI boundary exposed to a specific kind of actors (without entering into UI details).
Short Answer: Yes
Of course, the context of this interaction cannot be the system, since the actor is outside of the system. However, it is allowed to not model the context and let the interaction be its own context. Or you could introduce a Context Class, that contains the Actor and the system. But these are only formal considerations.
More important is, whether it is useful to do this. I would say, it can be. Describing how an actor will interact with the system is one outcome of analysing the use cases. Many people will use text to describe this, but in complicated cases, UML behavior diagrams, like activity diagrams or sequence diagrams can be used.
I would reconsider using a synchroneous message here, though. Communication with a human actor is by nature asynchroneous. You never know, whether the message arrives, whether the actor understands it and whether the actor responds with the appropriate reply message.
PS: The reply message should show the name of the message it replys to, not some arbitrary text. If you want, you can show the return value after a colon (confirmationInput():Answer)
Confirmation is vague.
As a response to user input this part would be missing in your SD. Being incomplete would not be wrong. In that case you just describe that part which starts from the confirmation.
As part of some system activity (e.g. you have a control process which detects over-heating and asks the user to continue with a shut down or so) that part would not show the start of the use case being likely something like "Observe XY".
In any case using system as life line to the right seems pretty much pointless. One would be interested in which object of the system is asking for confirmation.
The question is always: what does the editor of the diagram want to tell someone else.
I am working on a estimate tool for google actions where I want the ability for the user to change individual values after they get an initial estimate. Currently I am using follow up intentions to update values and then invoke the estimation intention, it seems to fail always. I think it is related to contexts. Is there a good resource to understand contexts and debug for them?
If you are using Followup Intents, you're certainly getting tangled up in Contexts. Google's documentation is simple, but covers the issue well.
Without seeing your Intents specifically, it is difficult to see what you're doing, how you're trying to do it, and what problem you may be encountering. However... Followup Intents are not usually good for long chains of questions and answers, particularly if you're expecting the user to go back and correct some of the answers.
Instead, you should leave them as top-level Intents, either triggerable only in specific contexts, or triggerable at any point (or both) depending on exactly what your conversation sounds like.
In this video https://youtu.be/ADD-rvsS5z4?t=927 the presenter demo the creation of a bike shop appointment booking app. The presenter uses Follow up intents to ask user what type of appointment ("Service" or "Repair"?). Can we not do this through having appointment type as a REQUIRED parameter, under the parent intent. I guess the question then becomes, what's the difference between using Follow up intent and setting a parameter as required?
They are two sides of slightly different coins. Each has uses and tradeoffs, and which one you choose to use depends on how your conversation is structured.
First - always remember that an Intent is meant to capture what the user has said. Not what we are saying or doing with that information.
Required parameters determine what needs to be included in the message from the user. If the parameter is not provided by their statement, they can include a prompt that we will give to get that information.
However, sometimes parameters are only required if other parameters are included, or aren't set. For example, you may find it useful for the user to either say "I'd like an appointment tomorrow morning" or "I'd like an appointment at 10 am tomorrow". "Morning" and "10am" are two different parameters (one is more specific than the other), but you would like one or the other expressed. This can't be done using required parameters.
But if it is omitted, we can use fulfillment to prompt the user for more information. For example, we could then ask "Do you want it in the morning, afternoon, or at a particular time?" and then have followup intents setup to capture this reply. But followup intents aren't perfect, either.
What if the user replies with a question, such as "when is available in the morning?" Could our followup intent confuse this with a reply? Quite possibly. Or there might be some additional back and forth before they specify a time. In cases like these, you don't want narrow followup intents, but you do want broader conversational intents that could be triggered at any point in the conversation, but still retain the context of the appointment that is trying to be set.
For these reasons, I tend to suggest that you not worry too much about either required parameters or followup intents. While both have some specific uses, more generally, having other intents that can handle these same questions is best. You can make sure the most appropriate ones are triggered by setting Contexts for when they will be valid. (Followup Intents use Contexts under the covers.)
I created a very simple Dialogflow project for the first time and I am having a problem with one of my follow-up intents. It asks the same follow-up question twice.
enter image description here
I am testing this inside Dialogflow. Do you have any suggestions I can try?
Many Thanks
The issue boils down to how Followup Intents work under the covers and the mechanism that Dialogflow uses to enforce them.
They work because the Base Intent will set an Output Context, and the valid Followup Intents are only triggered for the same Input Context. So the check intent sets a check-followup context, and the check-no intent depends on the check-followup intent being set. Similarly, the check-no intent sets the check-no-followup context and check-no-no intent expects the check-no-followup context to be set.
However, the lifespan of these Contexts are set to 2 initially, and this is decremented each time an Intent is handled. So after the check-no intent is processed, we will have two contexts that have been set: check-followup and check-no-followup.
This becomes a dilemma when the user says "no" again. That matches two Intents, and both of those Intents have a Context that is valid at that time: check-no (because the check-followup context is still active) and check-no-no (because the check-no-followup context has just been made active). Since more than one Intent could be valid - it is indeterminate which one would be called. This is why it would work for other test cases you had been trying.
In your case, a reasonable solution would be to make sure which context of these two you expect to be valid at that point. In this case, it would make sense that you turn off a Context after the Intent that you expect to match them does. So this means that if the check-no context is triggered, then you would set check-followup as an output context with one important distinction - you should explicitly set the lifespan of it to 0. This would remove that context, so there is no confusion about which Intents are available to handle the user's next reply.
Okay, I appreciate the title sounds odd. An event should always be for something that has happened, e.g. OrderCreated, ParcelShipped, etc.
However, I wonder if anyone has any thoughts on the following problem.
Consider an HR application which models people and their jobs. For simplicity's sake, a person can have a bunch of jobs and they can be ended at a date. The person has an EndJob operation which takes an endDate.
If the endDate is in the future, what would the domain event be?
JobEndedEvent (this is not true)
JobEndDateAddedEvent (this is quite technical)
Consumers in other bounded contexts will be interested to know that the Job will be ending, but may also wish to be informed at the point the job ends as well. I feel that the latter should be the consumer's responsibility, rather than the source's.
Any thoughts would be welcomed... Thanks.
Well, from a Domain perspective, you're probably talking about JobTerminationScheduledEvent because from the language point of view, you're notifying other contexts about a scheduling of a job's ending.
It's not the actual thing, schedulings can change and you will leave up to the other contexts how will they handle such an information. A given context might consider the scheduling to be enough information to consider the job will end by the given date.
Another context, as being notifying that such an event happened they might want to double-check when the date comes to make sure no changes happened before taking further action.
In the end, your context is actually expressing what happened which is: nothing concrete. You have a scheduled date defined for this action to happen, but it didn't happen yet.
If the endDate is in the future, what would the domain event be?
JobCompletionScheduled?
We made the decision now, but it's effective date is in the future. That's a perfectly normal thing to do in a line of business, and the decision itself is useful business intelligence to capture.
Dig around with your domain experts, and listen closely - there may already be vocabulary in your domain that describes this case.
Although there is an event that happens when you have specified that someones job is 'going to' end lets call it "jobEndIntentionEvent", there is also an implicit event that happens when the persons job actually ends - "jobEndEvent".
Now, the source bounded context possibly doesn't need to raise this "jobEndEvent" to act on it itself. You may have multiple bounded contexts that are only really interested in knowing about this event though. So should it raise it at all? Or do the multiple other bounded contexts all have to play the cards they're dealt - i.e. listen for the "jobEndIntentionEvent" and implement code that fires when the event they would have liked to have heard ("jobEndEvent") would have been received?
Or should the origin bounded context be nice and fire this 'integration event' for everyone.
Or alternatively a nicer solution would be we have a scheduling bounded context that is a subscriber to "jobEndIntentionEvents" and similar ones to that, and it knows to convert them into the REAL events that people actually care about - "jobEndEvents".