I have a very simple webforms app that will allow field techs to order parts from the warehouse.
Essentially it work like so:
User selects a category from a filter dropdown, which then binds items of that category to a gridview control
User finds an item in the gridview and inputs a desired quantity (in a text box in a template field in each row)
User repeats 1 & 2 as needed
User sees a summary of the complete requisition
User confirms items and submits the requisition for processing
My no-brainer UI design so far is the generic dropdown-above-a-gridview where there's a category drop-down list that filters a gridview, like in the eye-catching asp.net ado tutorials:
http://static.asp.net/asp.net/images/dataaccess/15fig01vb.png
Each gridview row (in my app, not in the image above) lists an item's details and can accept a quantity input in the template textbox if the user wants to requisition that item.
Given that a user will want items from different categories during a single usage session, I'm trying to figure out a good, user-friendly way to allow users to input a quantity for an item, have a warm fuzzy feeling that their input has been accepted/stored, then change the category filter (thus binding the gridview to a different set of data) and select other items from the gridview as many times as necessary before summing up their order and submitting it.
I've thought about putting another grid below the first and adding items to it dynamically as the user selects each item. But that seems awkward. Ditto with an unordered list or similar simple structure under the grid.
I've also thought about just storing the user's picks in view state or session state and displaying a summary on another page, kind of like a shopping cart sort of functionality. Maybe do that and use some sort of ajaxy goodness on the main page to display something warm and fuzzy when a quantity is input?
WWYD? What Would You Do?
TIA.
I strongly agree with your first choice: users need to see somewhere what they have chosen or they will probably keep choosing it over again thinking it failed. Waiting to display it on a summary page shouldn't even be an option. I don't see much wrong with binding to another grid, although a repeater is also a decent option. Well, there are many options. Anyway, if there is room to do this off to one side or another - especially the left- I definitely would, rather than at the bottom. Also, bonus points for enabling users to change the quantities (or delete all) of an item they already selected, wherever you choose to display this.
I like the idea of a search, but be careful with auto-complete. Google style is good where it displays results below, but I've seen people develop some that are way too aggressive and love to write over what you're typing: this is awful. Good luck.
Probably because both your choices are fine - it comes down to personal preference. The shopping cart idea is well known. But sometimes it gets old if you have to keep going back and forth between the cart and the item selection.
What's wrong with the separate grid? -That way you keep the selection list separate from the ordered items list?
Why tie the user to selecting the correct category and then selecting the quantity and hitting a button?
Why not use some type of autocomplete search so they can type in the produce name they want? Then a user could type "widg", get a drop town of choices, hit tab to go to a quantity field, enter a number, and then hit enter.
Display a quickie preview with the aucocomplete too, like as single row of your data.
Then throw all these into another grid at the top of the page if its a critical part of the application, maybe at the bottom if you think the actual grid results are important.
The reason I don't like category drop downs is people who are familiar with their jobs or company usually know the names and even skus numebers for what they are trying to do. Having them select a category instead of typing just slows them down. Also I hate running into the "which category is this?" moment. For example, is a chicken a pet, food, livestock, or food producer?
Related
I have a master/detail relation similar to the relations sample provided.
In my example department has a one to many relationship with employee
I have a form widget(department) which has a button to insert an employee.
when I click on that button the correct dialog form is displayed but I am allowed to enter any department which I do not want.
I am looking to have the relation defaulted to the "parent" widget where it was clicked and ideally not be editable.
It's hard to give an exact answer without seeing your app, but you should probably replace the dropdown in the form with a label, that will make it not editable. You can bind the value of the label to the relation just like the value of the dropdown was bound.
A slightly easier option would be disabling the dropdown (look for the Enabled probably in the property inspector). But that could be confusing for your users since they might think it should be editable.
(Alternatively, you could just remove the field altogether if it's not important to show the relation.)
I think this only answers the "not editable" part of your question, if you want it to be pre-filled you either need to do some scripting, or use relation data sources.
I suggest using relation data sources, so right now you probably have something like:
app.datasources.Emp.create(), which creates a new employee.
Instead, you can use widget.datasource.relations.Emp.create(), which will create a new employee which has a relation to the current item in widget.datasource. If this button is placed in your department form widget, then that means it will create an employee related to whatever department is shown in the form.
Note that none of this stops users from changing the department of an employee, it just changes the UI. In lots of cases that is enough, but you may also want to add some server-side security controls if it's important to limit which users can create employees, change departments, etc: See https://developers.google.com/appmaker/security/secure-app-data
I am working on a webpart which makes use of 5 dropdowns (each dropdown represents 'Project' table columns like projectNo, ProjectPM, ContractNo etc). The table has more than 3000 items, so when the dropdownlists are finally databound, they have more than 3000 items to load, which pretty much brings IE to a halt.
What is the best way to go about architecting a solution, so users can still make use of the dropdown list interface, may be like first rendering an empty dropdownlist and then using a modal window to first find the project number they are looking for and then set the item as selected in the dropdownlist. I am envisioning the following UI. Can anyone guide me on how I should go about solving this issue?
-------------------
|V| [SearchBtn]
-------------------
-------------------
|V| [SearchBtn]
-------------------
-------------------
|V| [SearchBtn]
-------------------
[FindProjectBtn]
Clickikng on the searchBtn basically brings up a popup window where they can search for their stuff, and when they click on the matched result, it will set the dropdownlist.
When working with dropdown lists, a good rule-of-thumb is to keep the list short so you do not experience browser performance issues. If you have thousands of items to look through you can:
Create a search component whereby the user enters a part of the project name they are searching for and display a simple grid for them to choose from.
Implement a type-ahead mechanism. The user enters the first couple of letters of what they are searching for. You can query your DB for the top 10 hits and return them via AJAX.
If you have 3000 items, then definitely drop down list will not be a right designing decision.
using any kind of repeater lists with paging, sorting and searching functions is highly recommended in your case.
but if you insist to have a kind of drop down list view then Matthew's suggestions are your answer.
I'm using Telerik scheduler to display a Timeline view of meetings. The resources derive from the Person class, and they are Advocate, and Legislator.
On the Y axis, I am listing Advocates, and on the X axis, I am listing blocks of time in one hour increments.
When I double click an appointment, the Edit Appointment modal dialog pops up and lists Advocates and Legislators.
Since meetings will have multiple advocates and possibly multiple legislators in attendance, I would like to have a checkbox list inside the resource dropdowns on the edit screen. Is there any way to accomplish this?
I believe this will allow me to solve one problem in that, if Peter Pan and Homer Simpson both are to attend the same meeting, clicking the meeting in the row for either of those two advocates will display 'Peter Pan' in both instances (or sometimes '-', not yet sure where that comes from) rather than 'Homer Simpson' where I open up the meeting from his row.
If it is not possible to introduce checkboxes to the resources list, can you suggest an alternate way around the ultimate issue in the above paragraph? Thanks in advance.
Telerik supports the adding of a listbox to support what you are trying to do. On the Scheduler itself add the code below that mimics your field names that your advocates are pulling from in your DB:
<ResourceTypes>
<telerik:ResourceType DataSourceID="SqlDataSource2" ForeignKeyField="Adv_AdvocateID"
KeyField="Adv_AdvocateID" Name="Advocate" TextField="Adv_FullName" AllowMultipleValues="true" />
</ResourceTypes>
The next step is to populate the resources using a custom provider. See this program here for a great project in which you can see resource population in action. Using the SchedulerDBProvider class you can then adjust their example to more represent your fields and populate the appointments accordingly with your desired ResourceTypes.
In terms of getting that particular drop down to have multiple selections via checkboxes you would most likely have to define your own custom advanced template. This route allows you to take a UserControl and use that as the edit view for your appointments. There's a demo that displays all of this (including source code) right here.
However, having that RadComboBox there might not even be the ideal approach to take. What about just a simple list of checkboxes? This demo shows off how a very simple declaration for the RadScheduler can achieve this functionality. Additionally, there is some code-behind (both in C# and VB.NET) that shows off how you can customize the text on each appointment, which might be helpful in the case that you're referring to.
On the Job Positions page, I would like to have 3 groups of input fields which are static so user can enter Job Name, Job Description, etc. respectively.
I'm not sure what the best approach is but I imagine there would be a button at the bottom which says "Add More". When user clicks on this, it would reveal (say 3) more groups of the input fields. And after entering up to 6 groups, the user can still click "Add More" (perhaps as many times as permissible) to bring up 3 more each time it is clicked.
Hope this is clear enough. I'm slowly getting into the AJAX world.
Thank you.
I would recommend using a framework such as jQuery and use a particular function called append, very easy to do and you'll find the framework simplifying alot of thing for you in the future as well
I have a single web page with master detail form/input layout. Currently the form works in a way like
User opens the page containing both master/detail data entry controls and enters the master information (The details save button is disabled)
When he saves the master information, the save master button gets disabled and save details is enabled
User continues to enter multiple details which get populated in a gridview at the bottom of page
All works well
Problem is that, the master part contains a lot of data entry controls (drop down lists gridviews etc)
How do I facilitate the user much more then the current layout? Should he be redirected to a new page after he enters the master record ? How can I improve on this?
If the user doesn’t need to refer to the entire master to complete the detail, and isn’t navigating among multiple masters to view/edit their details, then you don’t need a master-detail, and you can divide the input into two or more windows. A window for the details can repeat a few fields from the master that users need to complete the details.
Assuming it is desirable to keep everything on the same page, I think I see few things you can do:
Use edit-in-place for both the master and detail, so you don’t need space for both editing/creating a record and space to display it. Every field should only appear once.
Pack your controls more tightly together. You can do this without appearing too cluttered if you adopt a quieter visual style (e.g., lose the reverse-video and the rules). Allocate about 20 vertical pixels per single-row control
Adopt an object-selection-action syntax so you don’t need to take space repeating the same command buttons/links for every record. That leaves mores space for fields.
Put your tables in their own panes with vertical scrolling. The tables you have now are already pretty short (5 or fewer rows), but limiting them to 5 or fewer visible rows will keep the window from being too long for cases when there are a lot of rows.
Assuming you have edit-in-place, use wider tables, each set in their own pane with horizontal scrolling in order to reduce the height by moving fields out of the “overflow” spaces and into the tables. Be sure you have row headers that do not scroll away.
Divide fields up into tabs, especially on the master. That reduces the space the master needs to a fraction. You can have tabs within a portion of the master if your users need to keep key fields constantly visible.
Put some fields within the master or detail in expanders or secondary windows, especially for fields the user doesn’t necessary need to interact with (e.g., where usually the default values are correct). Show an aggregate, abbreviation, or summary of what the users don’t see to cue them on when they do need to interact with the fields.
Consider using a “paging” interface for your stack of multi-row text boxes at the bottom of the master so they’re “stacked” in the z-dimension rather than the y-dimension and thus take up the space of a single text box.
Consider using more compact drop-down lists rather than radio buttons, especially for fields the user is less likely to change (e.g., the default is very often correct). A dropdown list is more work to set a value (takes two clicks) but no more to see the value, and you can weigh the editing effort against navigation effort (scrolling, tab-clicking, etc.)
Consider putting the entire master in its own scrolling pane so the detail is always in view at normal window size and the user can scroll the master to whatever portion is relevant for entering details.
If users are telling you that everything in the window must be constantly in view, then you’re going to have to dig deeper, prioritize fields, and make trade-offs because that’s not going to happen unless your client buys everyone a suite of big-ass monitors. Some fields will be out of view, even it that just means scrolled out of view.
There can be various options:
Page may show master and summary (gridview) of details. Save button will only work for master data. Add/Edit details will happening in a modal pop-up.
Have a tabbed view - one tab will show master while other tab will show details. There will be one save button per tab. Tab switching will happen on client side.
Have both master and details always open for editing. Any changes in details will be temporarily held in view-state/session-state. The save button for master will save changes for both master and details. No need to disable any UI.
We typically prefer #1 - IMO, its simple UI from user's perspective.