I'm in the process of building a bot and the experience has been challenging for me so far. This is most likely since I'm coming from v1 and I'm trying to rebuild my bot in v4 style, which is pretty much a completely different framework it seems.
I find there's quite a lot of documentation out there, but it's been split up into theory and practice, probably due to the different development frameworks you can use (i.e. Node, C#). But having to go back and forth between these articles is not helping,
After quite a bit of messing around, I got to a point where things are beginning to get a bit more decent, but I still feel there's lots of room for improvement. I can't share the whole project at the moment, but I've created a gist of the most important code here: https://gist.github.com/jsiegmund/831d5337b1a438133991070daba8a27e
So my issues/questions with this code are the following:
The way to add dialogs and mainly the need to add prompts for retrieving the answers is confusing. I get the idea, but not the inner workings. For instance: I now have the prompts named after the same method names of the corresponding dialog step, is that the way it's supposed to work? There seems to be some magic code linking everything together, by convention? It would make much more sense to me when the waterfall steps would also include the prompts.
What's the right way of feeding the dialog with information so it can skip steps? I've got LUIS intents set-up in the main dialog which then open up this dialog for hour booking. Suppose my user says "I'd like to book 8 hours on customer X", I'd like the dialog to pre-populate the amount to 8 and the customer to X.
The customer/project resolving is maybe a not-so-standard requirement here. These come from a third party application, retrieved through API/SDK. So based on the logged-in user I need to go out to that application and retrieve the data for this user. This comes back in key/value pairs, where the key is a GUID. I don't want the user to type in GUIDs, so I have created these action buttons with the names of the customers, but to get the ID value into the next step it now 'writes' the GUID in the chat instead of the customer name. Using the name is tricky as I can't fully rely on those being unique. Also, for selecting the project I need the customer GUID and saving the final entry I also need the ID's. But I don't want the user to see those.
The way I now have the cards built is also weird to me. I first need to add a dialog for the card, and later when calling stepContext.PromptAsync I need to supply the card as an attachment as well. Feels duplicate to me, but removing either one of the steps fails. The normal style prompt doesn't work for me as that doesn't handle key/value but just strings (see number 3).
Okay, so those are some of the things I'm struggling with. I'm getting there and it works for now, but as said I can't escape the feeling that I'm not doing it right. If anyone could shine a light on this that would be highly appreciated.
Yeah, there is a lot of changes from version to version. Do you really mean v1?! 😲 Or v3?
The way to add dialogs and mainly the need to add prompts for retrieving the answers is confusing. I get the idea, but not really
the inner workings. For instance: I now have the prompts named after
the same method names of the corresponding dialog step, is that the
way it's supposed to work? There seems to be some magic code linking
everything together, by convention? It would make much more sense to
me when the waterfall steps would also include the prompts.
Essentially. The steps listed in the waterfall array are the names of the method names you've created. Basically, this is where you are giving the order of the steps that should be done by the bot. Prompts are classes used to retrieve data and are populated into the ("main") dialog using AddDialog() and are stored in dialog state with unique names so that they can be retrieved correctly. I see your point on how it might be simple to have everything setup in one "call" or declaration, and there probably could have been other approaches to how this was implemented; but this is what we got.
What's the right way of feeding the dialog with information so it can skip steps? I've got LUIS intents set-up in a main dialog which
then open up this dialog for hour booking. Suppose my user says "I'd
like to book 8 hours on customer X", I'd like the dialog to
pre-populate the amount to 8 and the customer to X.
Typically, steps use the previous steps value to reply, act or continue. In simple scenarios, skipping steps can be done by checking the state for those values. In the multiturn sample, if the user does not want to supply their age, it goes on to the next step and then it checks for the value and skips the step (it really doesn't skip it, it reports no age given, but you could just continue without any reply). Assuming the LUIS side of things is correct and getting the right intent+entities (let's say 'booking' intent and entities ['time' and 'customer']), then that should be doable. You would populate state info for both of those entities and then the later step (say prompting for the customer step) would just skip/bypass.
But, what you really want to do is look at adaptive dialogs. They are new and make this type of scenarios much more dynamic and flexible. Look here:
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-adaptive-dialog-introduction?view=azure-bot-service-4.0
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-dialogs-adaptive?view=azure-bot-service-4.0&tabs=csharp
https://github.com/microsoft/BotBuilder-Samples/tree/main/samples/csharp_dotnetcore/adaptive-dialog
The customer / project resolving is maybe a not-so-standard requirement here. These come from a third party application, retrieved
through API/SDK. So based on the logged in user I need to go out to
that application and retrieve the data for this user. This comes back
in key/value pairs, where the key is a GUID. Obviously I don't want
the user to type in GUIDs, so I have created these action buttons with
the names of the customers, but to get the ID value into the next step
it now 'writes' the GUID in the chat instead of the customer name.
Using the name is tricky as I can't fully rely on those being unique.
I'm not 100% sure on this part. Let me look into it and get back to you.
Also, for selecting the project I need the customer GUID and saving
the final entry I also need the ID's. But I don't want the user to see
those.
State (conversation|user|etc) would be a good place to manage this.
The way I now have the cards built is also weird to me. I first need to add a dialog for the card, and later when calling
stepContext.PromptAsync I need to supply the card as an attachment as
well. Feels duplicate to me, but removing either one of the steps ends
in failure. The normal style prompt doesn't work for me as that
doesn't handle key/value but just strings (see number 3).
Nope, that's correct. I know it feels weird, but that is the way to do it. Basically, anything but simple text will be an attachment. Cards are JSON, therefore an attachment and you need to send that to the user/client.
You're doing it all correct. Again; I would suggest on looking at adaptive dialogs as that's the newer tech and the move forward. But otherwise; you're on the right path!
I'm trying to check if a field is leaved initial or not in sm30 with a table that I've made. I've gone to table maintenance generator, then Environment->Modifications->Events and made an entrance named check_class with type 01 (before saving the data in the database) with the following code:
FORM CHECK_CLASS.
IF z10ficlassfica-z_class IS INITIAL.
MESSAGE text-001 TYPE 'E'.
ENDIF.
ENDFORM.
It works all fine except that when z10ficlassfica is initial it doesn't stay in the maintenance of the table and goes to the sm30 first screen. How can I make it stay on the maintenance screen of sm30? Hope I've made myself clear. Thank you.
please see this link :
You can use events, and should use them, dont go modify generated screens, that is why SAP provided events.
You just need 2 things to stop saving and stay on screen
MESSAGE 'Currency must be USD or IDR' TYPE 'S' DISPLAY LIKE 'E'.
vim_abort_saving = 'X'.
Read that link, there is a lot of information you need in there.
As a good practice, use the key of the record that went wrong in the error message, so the user can find the record back when entering thousands of new records
Please edit your original question instead adding another one. I've answered the question there already: Do not use an event, but modify the generated screen. Events are unsuitable here because you have to raise the MESSAGE within the screen LOOP statement.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
This is a perennial question for me that I've never really resolved so I'd like your input. If I have actions that I know a user will not be able to perform due to insufficient privileges or object state, should the UI elements for those actions be hidden from the user, visible but disabled, or visible and result in an error if attempted? What would be the rationale for your answer? If disabled, would you communicate the reason why and, if so, how?
This is a web interface so I already know that I need to check the incoming post/get for permissions and handle errors there anyway. I'm primarily talking about how to handle the UI.
This is similar to Rules about disabling or hiding menu items, though I am interested in all types of UI elements not just menus.
Examples:
I have a New page that allows a user to create a new Event. Events can be master events or subevents. Creating a master event requires "EditMasterEvent" privilege, while creating a subevent requires only "EditEvent" privilege. I have a drop down that allows one to choose an existing event as the parent (master event) or no parent (this is a master event). Should the "Create Master Event" choice be shown on the dropdown or omitted if the user only has "EditEvent" privileges.
Deleting events requires that you be an application administrator or have the appropriate edit permission for the event type. In the latter case, the event must also be more than 5 years old. Deleting an event causes major cascading deletes of related data in the system and for legal reasons this data must be kept for at least 5 years after the event. Since this operation is rare for the normal user, the typical case is that the action is not available. Should it be shown always or only when actually possible?
Hidden - This is the best approach for actions that are never available to the current user. There is no point in having the user waste mental effort figuring out why something is disabled if there is no action they can take to change this.
Disabled - This is the best approach for actions that are sometimes available, but not at the moment or in the current context. A disabled option should convey two things: first, the action is not available right now, and second, there is something the user could do to make the action available (change some setting or permission, select an item, enter prerequisite data, etc.). If you can indicate what needs to be done to enable the action in a tooltip - all the better. Enabling/disabling actions as the user enters data or changes context provides excellent feedback about what the program requires.
Fail with an Error - This is the worst choice. You should only resort to an error report for operations that might work: you can't tell that it will fail except by trying.
As with nearly all UI questions, the answer is "it depends".
You need to weigh discoverability with user satisfaction, among other things. For example, allowing an invalid action gives you an opportunity to explain why something is invalid. This is particularly useful if the answer to "why is this disabled" isn't obvious. For an application where most users are beginners, that's important.
On the other hand, it can be mightily frustrating to see a control, click on it, only to be rewarded with a "sorry, you can't do that now" message. An app I inherited a couple years back was rife with that sort of stuff and it made using the UI an exercise in frustration.
Completely hiding functionality is probably rarely a good idea. Imagine knowing some feature "was there a minute ago" but now it's gone. Whether it's a menu item or a toolbar button or something else entirely, making it hidden can be an exercise in frustration for the end user.
Try doing a little usability testing, if only by asking the next person you see "hey, does it make sense to disable this or show you an informative dialog". Just one other opinion is often enough to get you to look at the problem from another direction.
Bottom line: do what best serves the user. All the scenarios you mention are valid under certain circumstances. As with all UI questions, ask yourself (or better, your users) what best serves their needs.
I disable the elements instead of hiding them. That way the user knows the option would normally be available, and I provide a tooltip to explain why the element isn't currently available.
It depends. Do you want the user to be aware that the action is possible, just not for them? In that case, show them the button, but disable it. An example might be if a user doesn't have delete authority, but other users do, they should know that entries CAN be deleted, so they can ask someone to do it for them if they need the action.
On the other hand, if the user is not supposed to even know about the action (for example, a user who does not have read access to audit logs probably shouldn't know that these logs exist) should not be able to see the button, so hide it completely.
Great question!
A couple of considerations:
If you place the elements on the page but disable them, there's still a remote chance that the user could doctor the system and enable them using a javascriptlet.
If you do not show them at all, the overall functionality may be a bit confusing to the general user. "Shouldn't there be an edit button here?"
If you're going to either display and disable or display and verify the elements, I would definitely do server-side validation. Don't leave the validation in the hands of JavaScript; I think the reasons for this are obvious.
I tend to handle the two different types of situations differently. Is this an action that is governed by privilege and by state of the object.
If the person does not have enough privileges to do an action, I hide the option, they do not know they can perform the action.
If the option is not available because the object is not in a state that can use that option, I disable it, allowing the option to be visible to the user, but no action can be done.
From your examples:
I would not have "Create Master Event" as an option. The user has insufficient privileges to view it.
I would have the Delete button visible to the administrators. Then depending on how you do the rest of the site (a lot of visible text, tooltips, help icon, etc) I would follow that convention about informing the user why the button is not usable at this time. And possibly putting a timer on, above, near the button with either how old the post is or how long until it can be deleted.
Depending on the item, we will either hide them or disable them. If the user has access to a large feature, but not to a smaller piece inside it, then we will hide the smaller piece. However, if the user has access to several large features, but not to others, we'll leave them visible but disabled as a marketing ploy to remind them that the features are available for purchase if they should decide they want them.
I've also seen some programs that disable the menu item and change the text of it to "Log in to do blah..."
I like this because it doesn't leave me with the "why isn't this working?" feeling and tells me immediately what to do to get it working. Not applicable in every case, but this is a nice approach if you can implement it.
The general rule is use disabling if the user can do something in the UI to get the privilege. Disabled means “you can do this command, but just not right now the way things are.” The “way things are” includes the current selection, so use enabling/disabling if the user has the EditEvent privilege for old objects but not for new objects. There should be a clear indication which objects are delete-able so users understand why the associated commands are disabled for some objects (e.g., if users generally know that records must be kept for 5 years, a simple Age field maybe be sufficient, perhaps reinforced with a graphic difference for records over 5 years old).
Use message boxes instead of disabling if there is no way to make the reason for the disabling clear to the user assuming they have average knowledge of the domain. Tooltips for disabled controls, BTW, are a great idea, but may not be sufficient by themselves.
Use hiding if the user never has the privilege no matter what they do in the UI given their current position in the organization (e.g., they are not an Application Administrator). It is cluttering and frustrating to use disabling or message boxes for this case. As far as the users are concerned, actions they don’t have the privilege for are not their job (otherwise they’d have the privilege), and so the associated controls should simply not exist in their UI. Documentation or organization procedure manuals may tell users how such actions are accomplished (e.g., “Your supervisor creates new events for you.”).
I’ve more details at http://www.zuschlogin.com/?p=40.
I would say disable with a hover containing the reason.
It prevents the user from wondering what the hell is going on while at the same time letting them know certain actions are possible under the right conditions.
I have a particular hatred of applications that disable buttons. If you're an end user - you want to know why you can't use that button. Having it greyed out doesn't tell you anything. How do you get to the state to enable it? Tooltips are one solution, but they aren't the best, a lot of users will struggle with tooltips (unless you're working with experienced users).
My personal feeling is that the elements should always be present. If the user doesn't have enough permissions to do them, they should generate an error when clicked upon.
I know that translators don't really enjoy creating a zillion different "permission denied" error messages, so this is often not done in localised applications, which tend to hide the elements instead.
In practice a lot of people tend to hide the options instead even in non-localised apps.
Other people have provided good answers with valid suggestion to avoid hiding elements and instead disable them and provide some hints for the reasons.
So, I would like to look at it from different perspective - but how to hide some UI elements in cases when user does not need to see them, no matter if he has or has no permissions for particular actions related to the elements?
For example, let's say, users of some role are given access to sellers records in the system.
But then business analyst says: "Look, there is a dropdown with sellers list in this form and we should not allow some specific roles to see it".
Developer asks: "So, we just remove the "Read sellers" permission from this role, right?" But the analyst replies: "No! This role should still be able to view the sellers on the Sellers page. It's just this single form where we should hide the list for some roles and show it to some other roles."
So, the developer adds permission called "Show sellers dropdown on the form X".
Ooops, now we have a problem. Access to the same data is being controlled by two separate permissions. Now we have to figure out how to combine both of them. And what if there are more than one form where seller's list should be hidden for some roles? How do we combine it with "Read seller's list"? For us, developers, it is somewhat clear that "Read" permission should have higher priority above "View", so even if a user can "View" a list, he still should not see it (or see empty or disabled with a helpful hint) if he does not have "Read" permission. We, developers and analysts of the system know it. But how should the system administrator know it? Should we teach him this? How can we guarantee that the admin won't confuse all those "View" and "Read" for the single data list?
As you see, it all gets messy for one reason - we are mixing data processing permissions with UI conveniences in the list of role permissions.
I have seen many projects where it gets messy because permissions on the server side get coupled too much to UI, which asks for troubles and possible security holes (because you have multiple items in your role permission editor for the same actions on the same data).
Permissions are about access and operations on some specific data. UI can only react to permissions in consistent way throughout entire system (disabling with hints, hiding etc.). We should never invent new permission entries just for UI purposes.
Now the question remains - but how do we actually hide UI elements for some system users to avoid overwhelming them with huge amount of always disabled items? One solution might be role workspaces. If we clearly know that users of some role will never ever need access to some specific data, we create a set of UI control entries, similar to permissions, but this time we don't call them permissions. And we can get really fancy here, even allowing users themselves to freely customize their workspace and choose what they can or cannot see. Of course, permissions will always take the highest priority, but it will only affect the data and state of UI elements and not visibility.
That's my two cents. Unfortunately, I myself haven't worked on such a system where permissions and UI workspace options are neatly separated because I always somehow come too late to a project, when the "damage has been done". But I hope some day I'll have a chance. I just hope to find a good example how to do this right, but somehow internet searches do not give me anything useful. Does it really mean that nobody else has came to the same conclusions as me? I don't believe it, somebody in the enterprise design pattern world should have noticed this UI<->permission impedance mismatch long ago.
When a long-running process is being executed, it is a good practice to provide feedback to the user, for example, updating a progress bar.
Some FAQs for GUI libraries suggest something like this:
function long_running_progress()
do_some_work()
update_progress_bar()
while finish
do_some_work()
update_progress_bar()
end while
end function
Anyway, we know it is a best practice to separate business logic code from user interface code. The example above is mixing user interface code inside a business logic function.
What is a good technique to implement functions in the business logic layer whose progress could be easily tracked by an user interface without mixing layers?
Answers for any language or platform are welcome.
Provide a callback interface. The business logic will call its method every once in a while. The user layer will update the progress or whatever. If you want to allow cancellation – no problem, let the callback method have a return value which will indicate a need for cancellation. This will work regardless of number of threads.
If you used a MVC paradigm you could have the Model publish its current progress state as a property, the Controller could extract this every x seconds and then put it into the view. This assumes multi-threading though, which I'm not sure if you allow.
Publishing is a great way to go. It all depends on the platform how this is done. However, when it comes to the user experience there are a couple of things to consider as well:
Don't give the user a progress bar if you don't know how long the task is executing. What time is left? What does half-way mean? It's better to use hour-glass functionality (spinning wheels, bouncing progress bars, etc).
The only interesting thing to view progress on is time; what does Half-way in a process mean? You want to know if you got time for that cup of coffee. If you show other things you are probably displaying the workings of the system programming. Most users are not interested or just get confused.
Long running progress should always support the user with an escape, a way to cancel the request. You don't want to lock up the user for long time. Better still is to handle a long running request completely in the background and let the user get back when the result is back.