I cannot seem to get dialogflow CX to fill out optional parameters, only when they are required.
I want to have the bot ask the user for input, like "Tell me about your experience", and then repeat it back to them, but also give the user the ability to skip the question.
I have tried different solutions for solving this. One solution was to have a requires sys.any parameter and then check if it contains the word "skip" or not. However, that does not seem very robust, as a valid comment could result in a skip if they used that word.
My second attempt is seen in image 1. I tried to have a sys.any parameter which is not required and also a custom "skip" entity which was not required. No matter what I said, it would result in default fallback. I also tried to have an intent for skipping (called "no") which would overrule sys.any if it were required. However, it is just recorded in the "AnyInput" parameter, no matter what I say.
What would be a good way to give the user the ability to make a comment or skip it? Any suggestions would be helpful. Thanks!
Screenshot 1
Related
I have the first parameter (client drop down) that passes an ID to the second parameter to be used in the 3rd and 4th parameter. During testing all the parameters are set to visible to verify what's being passed. As soon as I hide that second parameter the rest don't refresh. Again, visible, correct info flowing through, hidden, DOA. I have this set up exactly like this on at least a dozen other reports with no issue. I'm not real sure where this going wrong since I can see the correct value being passed while visible?
I was able to duplicate your issue. While I can't find a reference to support my supposition, I believe that hidden parameters (even those with a default value) are not evaluated until rendering, which would explain this behavior. Data sets that drive parameter values are run prior to the report being rendered.
As you're talking about having trouble with dependencies between the parameter values, I assume you're using queries to drive your available values for parameters three and four. If this is the case, then simply embed the logic that relates the value(s) of parameter 1 to the value(s) of parameter 3 into the query that drives parameter 3's available values. By cutting out Parameter 2 and incorporating it into the query logic for parameter 3, you will work around this issue.
If you're having trouble accomplishing this, reply in a comment and I'll see if I can help. As it stands, I don't know enough about what you're trying to do to help any more.
Seems like once you set the Testers field on a Test Case in MTM, it will not allow you to clear it. You are only allowed to change it to a different value. Has anyone found a way to clear this field?
It is important to not get the "Assigned" Tester field confused with the Assigned To field. They are distinct fields on a Test Case work item. One reason why someone might want the Tester field to be blank is if a team all pitches in to help with testing during an iteration and leaving the assigned tester blank allows the team to know that no one has "picked up" this test to execute. The team member could then assign the test to his or herself and execute it.
The template pulls the Assigned Tester Values from a list using the 'AllowedValues' tag. Instead, simply change this to 'SuggestedValues'. That will allow for empty values - easy as that.
If you'd rather not allow free entry, you can also add a default value such as 'None' and use that rather than blank.
Unless you've customized your work item type, this field should never be blank after being saved. It defaults to the person who created the bug in all Microsoft supported process templates, and a value is required by default.
That being said, why would you want to change it to blank?
If you really, really want to be able to blank it out (which I don't think is a good idea at all), you'll need to customize your template. See the below guidance:
http://msdn.microsoft.com/en-us/library/ms243849(v=vs.110).aspx
I have a python script that receives text messages from users, and processes them as a query. However, some users have signatures automatically appended to their messages, and the script incorrectly treats them as actual content. What's the best programmatic way to recognize and remove these signatures?
(I'd prefer in python, but am fine with any other language too, as well as just saying it in pseudocode)
If the signatures are appended to the body of the message such that they're actually part of the body text, then there are only two ways to remove them:
Heuristics, such as "anything following three dashes must be a signature". These may be effective if you spend some time tuning them.
A classifier. This is a lot of work to set up, and requires that you "train" it by marking some message parts as signatures. These can also be very effective, but like heuristics will never work 100% of the time.
If the signature always follows a specific pattern, you should be able to just use a regular expression to trim it off.
However, if the user can setup their signature any way they wish, and there is no leading characters (ie: -- at the beginning), this is going to be very difficult. The only reliable way to do this would be to know the content of the signature for each user in advance so you can strip it out. Imagine a worst-case scenario: Somebody could always send a blank message, with a signature that was a fully valid "query". There'd be no way for the script to differentiate that from a "query" message with no signature.
I have received requirements that ask to normalize text box content when the user changes the focus to another control on the same data input form. Example normalizations:
whitespace at the start and end of the input is trimmed
If the text box was made empty and this is not valid, replace the content of the text box with the default value
I have a feeling that this is not in line with good GUI design. I have read the Windows UX Guidelines for text boxes but I did not immediately find any relevant rules.
Is normalizing text box content in this way acceptable?
I have definitely seen this before (examples elude me right now) but I personally don't like it when the UI changes my input.
If the UI is smart enough to change my input on me then it should accept it as is and change the value when it needs to process it.
When the input changes auto-magically you are now forcing the user to stop and ask themselves why it changed and if they did something wrong or if the application has an error. Don't make the user think!
Generally, you should accept user input exactly has they entered it. Chances are users did it that way for a good reason. For example, imagine a user entering a foreign address, and then your app screws it up trying to format like a domestic address. At the very least, users entered the input the way they’re used to it being, so changing it can make it hard for them to cross-check it.
However, there are several exceptions:
Add defaults to incomplete input. Adding input the user left off (e.g., years to dates, units to dimensions) provides good feedback on how the app is interpreting the input that would otherwise be ambiguous. This also encourages the user to use defaults, making their input more efficient.
Resolve other ambiguities. Change to an unambiguous format if the user’s format is open to interpretation. For example, if you have international users, you may want to change “9-8-09” to “Sep 8 2009” (or “9 Aug 2009”) to provide feedback on what your app considers the month and day to be.
Add delimiters when none provided. Automagically adding standard or even arbitrary delimiters to long alphanumeric strings (e.g., phone numbers, credit card numbers, serial numbers) provides an input display that the users can crosscheck more easily. Sometimes users may enter a string without delimiters in order to go faster or because they are the victim of web abuse by sites that refuse to accept even standard delimiters.
Spelling, grammar, and capitalization correction. Users often appreciate this, but only if there’s also a means to override it. Some users like to use "i" as the first person pronoun.
If the field is used by more than one user, then you probably should automatically format the value in some standard way that accommodates the majority of your users, but that should be done when the value is stored on the backend, not when focus leaves the field. For example, if a user enters a time of 15:30 it should remain as 15:30 as long as the user views the page. However, the next time a user (any user) retrieves the data, it should appear as 3:30pm (if that’s how most of your users are used to seeing time).
Such backend formatting applies to trimming whitespace so that all users can search, find, and sort on the field consistently. It’s probably not a good idea to replace a blank value (or any invalid value) with the default because users are unlikely to anticipate getting that value. An exception would perhaps be changing blank to 0 for numeric fields in situations where obviously blank == none == zero, but again this probably should be done when storing in the backend, not in the field itself. If blank is ambiguous, (e.g., may mean 0 or may mean "I don't know") then the second bullet above applies, and you may want to autocorrect in the field when focus is lost.
Of course, if your users vary in how they need to have a data type formatted, then you can have different variants of the app that display the data type in different ways for different user groups, or you can make the format of the data type a user preference, but that’s really another issue.
If the user wants it, and the Stakeholder ask for it, then is perfectly safe.
Trimming is very common. and the replace is common when you are talking about filling textbox with numbers. (a 0 instead of a blank).
It's a fairly standard feature, especially the whitespace trimming. The default value replacement raises a larger flag just because it is less common.
I'm pretty sure that I've seen versions of Microsoft Office that do this - putting "pt." after a value in points, for instance. Microsoft's endorsement should be a good sign.
We have quite a few of these kind of requirement. The reason given for forcing a default value rather than a blank space is that it looks better in reports or if the client wants to see the live system. A blank looks a bit like "couldn't be bothered to enter anything". For a similar reason, we often upper-case the text for consistency as the users never use consistent formatting.
In the very common scenario where you have a textbox, and some kind of validation rule which constraints the valid entries on that textbox. How should a failing validation affect the content of the textbox especially in the case when there originally was a valid value entered before the invalid.
Example: Imagine a form where one can enter a number between 0 and 50. The user enteres 40. Everything is fine. But then the user goes in and changes it to 59.
Obviously IMHO the application should inform him about his mistake asap. But what to do with the values? I think there should be a way back to the 40 as an easy way to a valid state, but I'm not sure when and how to revert it: On focus lost? Only on a special key/ button press?
What do you think?
Edit: I absolutely agree with the first two answers: changing the input automatically is a bad idea. Yet I would like to keep the 'last valid' value available ... Maybe a clean UnDo feature would to the trick?
The approach that I take to field validation like this is pretty simple:
Thou Shalt Not Discard the Users Input
If the entry made by the user is invalid, flag it as such - but don't change the value.
The reasoning behind you is simple - consistency.
Consider, for example, a pair of fields used for entry of a date range where "valid" means that the start date is before the end date.
Now, the user wants to enter a completely new range.
If your system discards invalid entries immediately, you force your user into different behaviour. For entry of an earlier date range, the start date must be entered first; for entry of a later date range, the final date must be entered first. Unfriendly.
Instead, respect the users input - when the start date is entered, freely flag it as invalid, but leave the value in place. Then, when the final date is entered, both fields now validate.
This is also motivation for displaying validation dynamically (as values are changed), but for not limiting the users movement between fields.
Depends on you functional specs really, but yeah falling back to the previous correct value sounds like a good practice ... for a blocking error which will always be blocking.
However do you really want to block your user there? What if the valid range is 0-50 when option b is selected but becomes 0-60 when option c is selected? And the user decides to change the ranged value first? Then the user will be very frustrated at having lost what she considers a perfectly valid value...
Keep that in mind when automatically reverting a change made by a user :) The user may have made a mistake but may also have made the change intentionnaly because he associated it to another change in his mind but can't change both at the same time in the application...
Warn that the value is invalid and let ctrl-Z cancel the stuff the user put there may be a more sensible default.
#Bevan Thou art righteous.
If you want to see an example of how annoying it can be crack open Google Analytics
This unfriendly behaviour is exactly what Google Analytics does when you try to compare dates, and it drives me crazy.
If you enter an end date which is before your start date, it discards your entry and thus forces you to enter information in a prescribed sequence.
It also means that small typo's can mean you being forced to retype a whole date, which just sucks.
I agree with the other answers in not changing the user input, you cannot tell what about it may be wrong, perhaps it was a typo, an missing decimal, swapped day/month/year fields, etc. An undo option to allow them to revert back to previous might be an added nice feature however.
The main items in my view are:
- make it clear what the valid ranges and formats are BEFORE the user enteres the data in the form, via examples or other similar indicators.
- be sure to indicate mandatory fields clearly prior to submision.
- user controls that limit the user to entering valida data - date pickers, spin controls, numeric only controls, max lengths set on textboxes, etc.
- make it clear when validation fails as to what item(s) on the form are invalid and why they are invalid, not just a simple "data is incorrect" global message, espeically if you have a long form with many fields that could have validation issues.