I want to implement a searchable list in my Road Safety app for the fines section. Fines will be distinguished based on whether they are parking violations, traffic violations and so on.
I found this App Inventor 1 style block for implementing a list filter but it does not work very well. I'd like some help on which blocks to use and how its done.
You could use the built-in Listpicker.FilterBar
ShowFilterBar
Returns current state of ShowFilterBar indicating if Search Filter
Bar will be displayed on ListPicker or not
alternatively you can use some HTML/jQuery, see this example
Related
In order to make UI automation test cases more stable, I'm looking for a tool (perhaps a chrome extension) to check whether webpage meets some certain standard when front end developers commit their code. For example, to make sure all major UI elements have IDs, and those IDs are not changing etc.
Of course I can also using XPath to identify UI element, but I believe query by ID would be quicker.
Any help would be highly appreciated.
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!
Summary:
The ultimate use for this workbook is to be able to build a components or bill of materials list. The difficulty comes into play because it is desired to be able to start with any component type and start narrowing down your options on other compatible components to ultimately build a product.
Every component option has it's own rules about which other component options that it is able to interface with. Options within the same component group are mutually exclusive and will never be used together. Each component type will always have one option chosen.
My Attempts:
Doing a bit of research on the www, I started with trying to create lists for the component options. I keep getting stuck with the rules of compatibility. I chose to call out "0" for component options that are compatible so that I could run a check to see if the sum of parts was greater than 0 (aka something wasn't compatible).
I also was starting down the path of using pull down lists under the Data Validation tools, but had trouble when it came to all of the restrictions.
Thank you in advance for any input. I would be happy to elaborate on any part of this request.
An example of how the output might look would be to have the options as pull-downs, but filtered out to not allow you to choose any option that isn't compatible with the other choices that you have already made. Here is an attempt to capture that.
example of output table
It happens sometimes that one feature seems to belong to more than one place.
Trivial example, let's say I've got the following menus :
File
Pending orders
Accepted orders
Tools
Help
I've got a search feature, and the same search window work for both pending and accepted orders (it's just an 'order status' combo you can change)
Where does this search feature belongs?
The Tools menu seems to be a good choice, but I'm afraid the users may expect the search accepted orders to be in the accepted orders menu, which would make sense
Duplicating the menu entry in both pending and accepted order seems wrong to me.
What would you do? (And let's pretend we cannot merge the two orders menu into one single menu)
I think the problem you've run into is that you're thinking like a programmer. (code duplication bad). I'm not faulting you for it, I do the same thing. Multiple paths to the same screen, or multiple ways to handle the same process can actually be extremely beneficial. I would guess that more than one person is going to use your program and each probably have slightly different job functions. In essence, they have different needs for the application and will approach using it different ways. If you stick to the all items have one way of being accessed, some people will find the application beneficial and others won't. Sure all people can learn to do a task a certain way, but it won't make sense to some users. It's not intuitive (read familiar) to they way they are used to processing information, which means the application will ultimately be less beneficial to them. When people find a process (program etc.) frustrating, they won't adopt it. They find reasons why the process will need to be changed or abandoned.
An excellent example of the multiple approaches to a problem is with Adobe Photoshop. Normally there are at least 2 different ways to access a function. Most users only know of one, because that's all they are concerned with, but most users are really comfortable with using one, because it makes the most sense to them. With a little extra work, Adobe scored a huge win, because more people find their product intuitive.
Having a feature in multiple locations is not a bad thing. Consider the overall workflow for viewing both pending orders and accepted orders, and think of your new feature as a component, rather than a one-off entity.
After you map out exactly what tasks a user completes in the pending and accepted order viewing process, see where having the ability to search would provide value (by shortening the workflow or otherwise). This is where your search component belongs.
The main thing to remember about UI is that all that really matters in the end is whether your design makes using your application or site a better experience for your users.
In the search example you list above you'll commonly see apps take two approaches:
Put the search feature in a single location and allow the user to filter the search by selecting pending or accepted, or
Put the search feature in both menus, already configured for the type of search to be done based on the menu it was launched from.
If you repeat the above choice for a number of factors you'll see a much more advanced (aka 'complicated') search interface for number one, and a much simpler (aka 'restrictive') search interface for number two.
Which one is best completely depends on your users. This is why many general applications have a simple search by default and a link to a more advanced search for those that want or need the additional capabilities; they're attempting to make everyone happy. There is absolutely nothing wrong with that if you're writing for a wide variety of people with different needs. If you're writing for a set of users with a restricted set of needs however, you can make some better choices.
In my experience your best bet is to work with one or two of your primary users and map out all of the steps they need to take to get each of the tasks the application will be helping them with accomplished. If there aren't a lot of branching points in that sequence of steps there shouldn't be a lot of choices or settings to make in the application; otherwise the users may feel that the app is harder to work with than it needs to be.
For the search example above, if the user has already navigated into the Pending Orders menu, the likelihood that they'll want to launch a search for Accepted Orders is very small and having to make that choice, or go elsewhere to do the search, will be an extra decision or action they'll need to take. Basic principle is if your user has already made a decision, use it; don't make them tell you again.
Use the UI you come up with as a first cut. Let your users, or a subset of them, try it out and make suggestions. If you have the option, watch them use it. You'll learn far more about how to improve the interface by seeing how they work with it than you will from what they tell you.
Generally you do not want the same menu item appearing in different menus. It adds complexity and clutter to the menu, and users will wonder if the two menu items are really the same or not. When it appears that a menu item belongs in two places, then you may have a more basic problem with your menu organization.
For instance, your example shows a menu bar that is organized by the class or attribute of the object the commands within act on. In general, the menu bar should be organized by category of action not type of object. For example, you could have a Retrieval menu for commands like Search and other means of displaying orders, and a Modify menu for processing the orders (e.g., updating, accepting, forwarding). Both menus would have menu items that apply to both types of objects, although some commands may apply to only one.
Organizing commands by object type is actually a good idea but it is better accomplished with a context menu (right click) than the menu bar.
I would try the search in both the Accepted Orders and Pending Orders menus. However, user testing will show if this is a good idea or not. But it also depends on your user base.
You are doing user testing right?
...you may already know this, but this is a good place to use the command\action pattern IMHO.
So to answer your question: IMO, yes, it is ok :) This situation is definitely warranted.
Just put it under both menus and have it open your search window, pre-configured for the order type who's menu it was launched from. Name them accordingly and voila they're actually two different actions - even though they use the same code/component.
Keep the user-selectable "status combo you can change" in the search window active though so the user still can adjust the settings without relaunching it from the other menu... and then perhaps rethink the structure, see some of the great answers in here for ideas ^^
I'm looking for advanced strategies for dealing with User Object Handle limits when building heavy-weight windows interfaces. Please explain how you overcame or bypassed this issue using SWT or direct Windows GUI APIs. The only thing I am not interested in is strategies to optimize widget usage as I have done this extensively and it does not solve the problem, only makes it less likely.
My Situation:
I have an SWT based GUI that allows for multiple sessions within the same parent shell and within each session their are 3 separate places where a list of user generated comments are displayed. As a user opens multiple sessions and pulls data that populates those lists, the number of user object handles can increase dramatically depending on the number of comments.
My current solutions:
1. I page the comments by default thereby limiting the number of comment rows in each session, but due to management demands, i also have what is effectively a "View All" button which bypasses this completely.
2. I custom draw all non-editable information in each row. This means each row utilizes only 2 object handles.
3. I created JNI calls which query the OS for the current usage and the Max usage. With this i can give indications to users that a crash is imminent. Needless to say, they ignore this warning.
First off, are you sure the problem isn't desktop heap vs. handle count? Each handle can consume a certain amount of Windows desktop heap. One USER handle may eat a lot of space, some very little. I'm suggesting this to make sure you're not chasing user handle counts when it's really something else. (google for Microsoft's dheapmon tool, it may help)
I've read that you can alter the maxes on handles by changing keys in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Windows\ USERProcessHandleQuota and GDIProcessHandleQuota
This could be a short term fix for users.
I'd approach this by first figuring out what 2 user handles need to be maintained for each item (like 2 for each item in a listbox?). This seems suspect. User handles are for only a few top-level Windows UI objects (Windows, menus, cursors, Window positions, icons, etc...). I don't see why your widget needs to keep 2 objects around for each item (is it an icon handle??).
If you're looking to rip the whole thing apart - this sounds like a job for a virtual-mode List-View (LVS_OWNERDATA).
You should think about using windowless controls. They are designed for precisely this situation. See "Windowless controls are not magic", by Raymond Chen
Not only top-level windows, but most native controls use one user object each. See Give Me a Handle, and I'll Show You an Object for an in-depth explanation of user- and other handle types. This also means that SWT uses at least one user handle per widget, even for a Composite.
If you truly are hitting the limit of 10000 user objects per process, and you don't have a leak, then your only option is to reduce the number of widget instances in your application. I wrote a blog article about how we did this for our application.