Suppose I have a list of a couple of thousand organizations and a user needs to be able to select one of them. The list is too large to populate in a dropdown at page load, and the user often knows what they want but it's not the first part of the organization name. That is, they know "Collections" but not that the precise name of the organization is "Department of Collections". So the user will need/want to type in some information.
It's easy enough to use an autocompleting textbox of some kind, but I don't want to allow the user to type in random text - they have to choose one of the organizations explicitly.
What's the best solution?
IMO I will simplify the UI to:
a textbox to enter the string
a drop down to set the filter options like: "contains | starts with | ends with"
a button "Find"
Then, I will populate a view based on the search string & let the user choose the valid item or refine the search
IMO with something like an auto-complete, you will end up writing a lot of parsing code to get to the string & then there might be server-side load considerations...
HTH.
In additional check if 'facetted navigation' is something you need. Ref.: http://www.alistapart.com/articles/design-patterns-faceted-navigation/
So it seems to me your main challenges are to
Express that the user needs to select an organization from the list (and only from the list).
Express that there are a lot of organizations on the list.
Provide some means for the user to quickly find the organization on the list.
I would say present a selector control that fits in with the rest of your design with a search box just above it. You should then page the list as there will be lots of pages with that many elements indicating that the user should definitely use the search. The search essentially acts like the auto complete, but instead of the found options changing the text, it will change the contents of the paginated list. If you do this on a character by character basis (or throttle using Reactive Extensions), it's very clear that you're just filtering the list to make selection easier.
You could use a CustomValidator to ensure that the TextBoxes content in contained in your collection.
You could use the Ajax AutoComplete Control: http://www.asp.net/ajax/ajaxcontroltoolkit/Samples/AutoComplete/AutoComplete.aspx. You can opt to only do a lookup if the user has typed in a certain number of characters.
You'd create a static Web Method to query the collection (you could use LINQ) and return matching organizations.
You'd obviously need to validate the textbox input afterwards.
Is it possible to structure your list a bit more like a tree, so that it is not a single list. E.g. Could you have a grouping like "Government Depts" and then add Dept of Collections to that. Then ask you users to first select the top level grouping then show them a shorter lists of organizations in that group?
It sounds to me as if your data list should really be in either a database or at least stored well away from the UI.
Wherever its really stored, place a keyword for each entry, say "Collection". The list of keywords could be available as part of your auto-complete functionality. Then search on the keyword alone.
If you could divide items in categories, would using some kind of tree control help?
So, when user clicks on a node you load only items in that node. And so on.
I'd break it into two paths...
Use an autocompleting textbox, for the person who types the correct title (i.e., Department of Collections); and a separate search button to search for possible matches. The search button would take you to a results page to select the desired choice. This functionality would be similar to the way search on MSDN works.
Initially a tree view sounds cool, but are you certain that a single classification will reduce the data into manageable sets? If 80% of your data gets classified as "government dept" this doesn't really help things.
The problem is you want criteria that allows users to quickly split a large list into smaller sets that are easier to consume. Additionally, there should be enough flexibility to react to changes in data.
I'd suggest using a tagging pattern like iTunes. In my library "rock" describes 80% of my collection - but is still a useful categorization for something like random shuffle. I also have the ability to stack tags so I can use genre="rock", decade="1990" and quickly sift my data down to whatever is of interest.
In the UI, I'd recommend a section that allows the user to apply "filters" which is nothing more than selecting specific values for tags. Break the list out into pages and allow them to see a tally of potential matches.
Scenerio:
- Navigate to screeen XYZ and see there are 10,000 companies to pick from
- Click "classification" and select "Government dept" and the list updates to indicate there are now 1,000.
- Click "region" and select "South" and see my list drop to 200.
- Sort list by name and then select (or scroll through, whatever)
Related
Lets say I have three webpages - one for big cars, one for middle sized cars, and one for little cars.
Each page is almost identical and consists of a form where you can select to filter a list of cars by colour etc and a submit button. On the client side the only difference is the title.
On the server side the only difference is in the where clause, for example:
... where car_type = "big" and color = %s, Response.Form['color']
But how can I save myself creating three different asp scripts for each page? How do I pass around which car_type I have?
I was thinking maybe by using a query string, but the query string data will be lost when the user presses the submit button.
Thanks,
Barry
You've found one solution yourself. Might not be the best one, though. When programming you always want to minimize redundancy, to avoid code duplication, because it'll invariably become a maintenance hassle, if not nightmare. So you really want to avoid creating three identical pages with just a tiny parameter difference.
Why don't you simply create one single page containing a select menu for the type of vehicle to search for? You could attach an onselect handler using Javascript to that menu which would reload the page if that's necessary. (And it might not even be.) In some menu, you could have links pointing to this page (search.asp or whatever) containing the vehicle type like this:
search.asp?type=L
search.asp?type=M
search.asp?type=S
Just an idea. Toy around with the code and that way you'll learn a lot. ASP is an old technology but I think a very good one for learning web applications. Do read the docs to learn about the facilities it affords you to avoid duplicating code. Here's a collection of things I found useful.
One way to do this is to use the query string the first time the page is accessed and then a hidden field to pass on the car type on filtering.
Use Case:
End-User searches for something and an ArrayCollection is returned with Result objects. This is displayed in a data grid.
End-User selects a few of the search results and "moves" it over to another datagrid for use later.
End-User does another search.
PROBLEM:
Some of the search results might contain something the user already previously selected and moved over to the second datagrid. I want to remove these from the second search result.
How can I do this quickly, and efficiently in Flex code?
disableAutoUpdate() on both array collection
loop through the first one and for each item of the second remove it if it's present in the first one (or adapt the algorithm based on what you really want - unsure)
enableAutoUpdate() at the end.
Looping through array collection can be quick if no events are dispatched.
Second option, you could also loop through a cheap copy made up of an array, which is arraycollection.source.concat(), or even a vector if all your items are of the same type. That will give the maximum speed, but you might lose in the long run as you need to convert back to an array collection at the end.
So I would stick to the first option.
For the time being, I've implemented a hash collection (extends ArrayCollection). Hash only allows unique values, so in the end, it serves my purpose even though the UI might be confusing to the user. Will probably implement the above method at a later date. :)
I have standard basic article content type which, amongst other things, contains an image field which is configured to contain an unlimited amount of values.
I'm now trying to create a view that lists some of the fields in this content type but I want to limit the number of images that are returned for this specific field to 3 random images in the list (or less). Is this something that can be achieved right in my view configuration or do I need to do something ninja? I'm not aware of everything that's possible php wise to "rewrite" / "filter" the results of my view but I'm confortable with anything programming related.
I'm using drupal-7 with Views 7.x-3.0-alpha1
Thanks!
AFAIK there is no way through the Views UI to randomize the selections of a grouped field.
I can see two possible ways, in theory to achieve what you want.
Use hook_views_query_alter to alter the SQL query for the view. I'm not sure Views support what you need to randomize the results, but you have the ability to alter the query that views generates, and might be able to randomize it.
Select all results, but using theming to only show the randomly selected options. This could be done in a preprocess function. Views provides several, depending on your display option, hook_views_view_unformatted might be what you need.
When and why would it be a good choice to keep the view of two different sets of information on the same page, and just change what's visible depending on different parameters?
For example, an application I'm working on has three levels of users: Admin, Director and Project Manager. We have a Managers.aspx page which follows this flow of control:
If user is admin, load gridview list of directors with several simple CRUD-like properties. This includes a link for each director that, when clicked, will load a new gridview with several properties of all of the Project Managers belonging to the selected director.
If user is director, load straight to the list of Project Managers that belong to this director, in the exact fashion as described in the second half of the "if user is admin" clause".
This is all done on one Managers.aspx page. Why? What advantage does this hold? When else might this type of situation arise? Personally, this seems like a job for two separate pages. One listing the directors, and another listing the Project Managers.
Thanks in advance :)
As you pointed out, most of the logic for those two requirements is the same: get a list of users, present them in a gridview, apply simple CRUD functions. Doing this as two separate pages would require all that code to be repeated twice, and then kept in sync.
The only real difference between the two screens is which users it shws by default... That's one if-statement of difference in a pageful of code..
As stobor indicates - when you don't want to write the same code twice.
Using the one page solution, the decision about which view to display is made on that one page. If you separate the different views out to different pages, you have to make this decision every time you need to display this data. So rather than one single if/else in Managers.aspx to determine the view, you have multiple if/else statements on multiple pages which are intended to decide whether to load AdministratorManagers.aspx or DirectorManagers.aspx.
Provided your application is robust enough, and you're not doing something stupid like determining which page to show based on a querystring value, there is no real problem using one single page to display different views. In fact, many websites do this. What you don't want to do is use seperate but identical controls for each view, because then you're just going to end up with messy code. It may make sense to create custom controls called 'AdminView' and 'DirectorView' to at least allow you to think of the two views as separate entities, but you'll have to decide for yourself whether this will be a headache-saver or a waste of time.
I'm working on an ASP.NET project that replaces many existing paper forms. One of the requirements is that the user can save the form in any state, i.e. they could create a new blank form and immediately save it with no data or with partial data. I'm validating for data type on every save but validation for required fields does not occur until the user marks the form as completed.
I'm not sure what the best approach is to handle this requirement in the database and domain model. As I see it, I have two options:
Allow nulls for any field that may not have data. This feels like the "correct" approach but it requires that almost every database field allow nulls and I have to code around a lot of nullable types. Also, when the form is finalized none of the required fields are enforced in the database.
Populate my business objects with meaningful default values. In some cases, there are meaningful default values for many (but not all) fields that I could use. This approach verges on "magic numbers" which makes me uncomfortable.
Which approach is best? Or is there a third way? I'm not willing to go to extremes, such as splitting the tables.
Edited to add: I wanted to expand on this a bit since I accepted a response. The primary reason that I'm not interested in splitting the tables is that once a project is submitted, the data on the forms is used to generate data for another system that is the system of record. At that point the original form data is unlikely to be revised or used for reporting.
I don't understand why you don't want to split the tables. I don't know what domain you're in but in any I could imagine there are two classes of people:
people who have submitted the form
people who haven't
And as a business executive I don't care about the second. But the first I care deeply about, and they need to have all their data in correctly.
It also improves efficiency - most of your queries about aggregate data will be over the first table, not the second. The second table will only be used for index seeks.
If splitting the table(s) (are there more than one?) is not an option, I would consider creating single table to store serialisations of objects of incomplete forms, and only commit a form to the "real" tables when the form is fully submitted by the user.
If there isn't a sensible default, and you don't want to split the data, then nulls are almost certainly your best option. Re the db not being to verify that they are not null when completed... well, if you don't want to split the table there isn't much you can do (short of using a CHECK constraint, or an INSTEAD OF trigger to run validation). But the DB isn't the only place responsible for data validation. Your app logic can do that too.
You could use a temporary table with "allow nulls" on every column to store the form containing partial or no data and copy / move the data to the final table when the user marks the form as completed. This way, you do not depend on default values (which the user may forget to change), you can save in any state, and you still have the validation in the end.
This is a situation that cries out for split tables. I know you said you don't want to do that, and in a comment even said "this project doesn't warrant that level of effort". but it's really the best solution.
Set up preliminary table(s) with everything except your key nullable. When the user marks the form complete, and it passes validation, move it to the final table(s). not only is this The Right Thing To Do, but it's probably less effort than "coding around nullable values" when working with finished forms.
If you need to see all forms, finished or not, make a Union view.
I'd take the first option but add a column to the database tables so that when the form is completed this is flagged. Then for anything using the form data it merely needs to check that the form has been completed.
That's my suggestion for a way around this.
NULL values are not searchable by the indexes.
If you'll need to issue a query like "select first 10 forms with a certain field unfilled", this query will use a FULL TABLE SCAN which may be not efficient.
Oracle does not distinguish between NULL and empty string, but other databases do. You'll probably want to make an empty string to be the DEFAULT for unfilled fields and use it in a search.
If you don't need to search on unfilled fields, then just make them NULL.
NULL generally means "Don't Know" (in a database) whereas an empty string could actually represent an empty string.
I would tend to use NULL as the "Don't Know" value in your case. When you print out data you'll just have to assume that any NULL value means an empty string.
CHECK CONSTRAINT + VIEW
if you don't have a status field add one so you can tell that it is finished.
add a check constraint on that status field so it can't be marked finished if any of the columns are null.
When you write your queries on "finished" forms you can ignore checking for nulls everywhere if you do one of these two options:
just add Status="F"inished in the where clause
make a view of only finished ones
when using the "finished view" you don't have to do all the validation checks or worry about unfinished ones showing up in the results
I've had a similar situation, and while I haven't yet come up with a solution, I have been toying with the idea of just using simple XML serialization to store the temporary document data. If you generate simple classes that model the data in the objects (using nullable types where needed, perhaps), it would be easy to stuff data from the screen into those objects, serialize them to XML and then store them in a temporary "staging" table. When your users are done working and want to submit or finalize the document, then you perform all of your needed validation against the serialized data, eventually putting into the "real" table with the proper data structures and constraints.