In a typical business application it is quite common to have forms that are used for searching.
Some basic features are:
A pane that contains the search criteria
A grid to display the results
Sorting on the grid
A detail page that opens when an item is selected in the results grid
What other features would you expect in a business application's search functionality?
Maybe it's a bit trite but there is some sense in this picture:
removed dead ImageShack link
Do it as it shown at the second example, not as at the 3rd one.
There is a well known extreme programming principle - YAGNI. I think it's absolutely appliabe to almost any problem. You always can add something new if it's necessary, but it's much more difficult to remove something what is already exist because someone already uses it even if it's wrong.
How about the ability to save search criteria, in order to easily re-run a search later. Or, the ability to easily, cleanly, print the list of results.
If search refining is allowed (given a search result, limited future searches to the current results), you may also want to add a breadcrumb system, so that the user can see the sequence of refinements that lead you to the current result-set -- and by clicking on a breadcrumb, return to a previous refinement stage.
Faceted search:
(source: msdn.com)
This is displayed in the area in the right ellipse. There are filters and the engine shows the number of results that will remain after aplying the filter. This is very useful and can be done without pain in some search engines, such as Apache Solr. Of course, implement this only if filters make sense in your task.
Aggregate summary info, like total(s), count(s) or percentages.
One or more menus, like right click context for the grid, a ribbon or menu on top.
Your list for the UI elements is kinda good. Export, print (asking them whether it is really necessary to print this?), category/tag and language selection is worth to consider. Smart and working pagination (don't forget ordering).
Please do not force a search to open in a new (or even worse, always in the same window). Links of search results should be copy-pastable (always use GET),
But it really matters to have a functional (i.e. a really good) algorithm. Mostly I google company websites, because their search engine is, cough, awwwwkward. Looking for a feature chart, technical spec, pricing etc. one is not interested in press releases and vica-versa.
Search engine providers offer integration into company websites.
Use Auto-complete wherever possible on your text input fields.
If using selects or combo boxes with related information try and use chain selects to organise the information.
Where results depend on location try and serve relevant results.
Also remember to keep the search form as simple as possible even down to one text field. To refine the search you can have an alternate form as an "Advanced Search interface".
Printing, export.
A grid to display the results
Watch out not to display results a user is not authorized to see (roles / permissions / access rights).
A detail page that opens when an item is selected in the results grid
In case a user attempts to circumvent the search page links and enter some document directly, again, check out for permissions.
Validation, validation, validation.
It should be very hard, near impossible, for me to run a query that makes no sense. ie, start date occurring after an end date.
Export a numerical dataset (even if it only has one numeric column - so just make it so by default) to CSV for import into Excel (people love this function, even if only 1% of users seem to use it with any regularity. Just ask yourself when's the last time you highlighted something for copy-n-paste. Would it have been easier to open a CSV?
Refinable searches (think Google's use of site: -). People who use the search utility a lot will appreciate this. People who don't won't know it's not there.
The ability to choose to display 1 records, 5 records, 100 records, 1000 records, etc. "Paging" I believe is what we most commonly call it ;).
You mentioned sortable grids. Somebody else mentioned auto-sum or auto-count. Those are good if (once again) you have largely numeric data. But those are almost report-oriented functions.
Hope this helps.
One thing you can do is have a drop down of most common searches in plain english. e.g. "High value sales in New York in last 5 days". This is the equivalent of user selecting an amount, the city, date ranges etc. done conveniently for them.
Another thing is to have multiple search criteria tabs based on perspective of the user. Like "sales search", "reporting search", "admin search" etc.
ALso consider limiting the number of entries retrieved in the search and allow users to do more narrow searches. This depends on the business needs however.
The most commonly used search option listed first and in a prominent location.
I think your requirements are good. Take a cue from Google. Google got it right. One text box where you type whatever you want, and your engine spits out the answers. Most folks will try this, and if the answers are good enough, then that is what they will use. In the back-end, you'll probably want to flatten all of the data into a big honkin' table and then index it or use a SQL query with "LIKE" in it.
However, you will probably want to allow the user to refine the search. For this, have a link to "Advanced Search" and use a form there to specify filter criteria. This lets the user zero in on the results if basic search is not good enough. For the results on th is page, you will certainly want to have sorting on key fields, but do it after you have produced the initial result set.
It depends on the content that you are searching for.. make it relevant :) Search always look easy but can be incredibly difficult to get right.
Not mentioned yet, but very important I think - a search that actually works. This item is often neglected and makes the rest a bit moot.
Related
Hello World,
I'm in research mode for one of feature to be built in our software and there one new thing that we have never faced.
The thing is, on one form we have a drop down with list of items. User can select default which means all items needs to be considered or else he can selectively opt for certain list items.
Actually the form is related to filter functionality depending upon users input the data is going to get filtered and displayed on UI.
The main problem we are trying to solve is suppose user selects default, which means all list items ID's are gonna be considered in POST call of API. The list can be huge, say 1 to 1K and above too.
So under such circumstances we can build the query string but, it seems its gonna be so huge. I have also studied that certain browsers support limited query string as per their standard limits.
So currently I have following doubts in mind.
Will shortening of query string work here ?
By which technique it can be handled efficiently ?
What performance considerations I need to take care during during so ?
Any suggestions or thoughts are welcome. That would boast my software design thinking.
based on what I understand from your question, here is my opinion:[if I understood wrong, please correct me, so I can help you]
You need to send query in URL and not in body or using JSON!is that correct?
I think you don't need to send every one of the selected items one by one!
If there are selected in serial, you can perform a range in your query!
Like http://abcd/test?id=1-43,6-765(take ID as string and then export the useful data in back-end) with this approach, you can shorten your query!
And also think about the database too (if there is any).querying this much data is use a lot of IO and make query low performance.
I've inherited an SSRS report that doesn't work correctly. The report is a meta report of a document management system. FWIW, this is a monthly destruction report -- certain documents to be destroyed per retention policy. The kicker in this application is that there are special "stack_location" values that represent certain content status, e.g. 86/86/86 meaning document checked out but not returned. Any given document can have only one stack location, or one special stack location value.
The basic query returned all the appropriate documents. The original designer, then created a filter list that excluded all the special values. This is as intended. However, the designer apparently assumed these special value exclusions could be toggled by clicking on a radio button in an options section. This, of course, does not work. Indeed, the whole approach seems off.
I think I need a default query that includes an AND NOT IN ('86/86/86', '96/96/86'...), then somehow optional unions with the special values. I am completely at sea, however, on how to accomplish this.
It seems it would be relatively straight forward if I were just using VB, or C#, to write different dynamic queries based on the value of a radio button. I am required, however, to use SSRS, technology I'm only vaguely familiar with.
If anybody can point me in the right direction, I would be most appreciative.
Thanks.
You can pass the radio button's value to the query, then as you suggested, include in your where clause something like
AND (StackLocation NOT IN ('86/86/86', '96/96/86'...) OR #MyRadioButton = 'SomeValue').
I rewrote a news application (overview + detail) from Fast-Query to Content Search. The performance gains were enormous, but i see some possible limitations, for which i don't know to handle in conjunction with the Page Editor.
When i use a fast query, i get an instance of a news even if there isn't a language version yet. In Lucene, i cannot find a result (because i filter for the language) and therefore the news detail is missing in the overview in the particular language.
EDIT for question 1
Lets assume that we have a solution with two languages (English and German). I have an item which currently only exist in a single english version. When i'm on an overview page in German and want to find this item with an fast query (the query does not matter), i will get this item back. In the wrong version, but i get it back. Now if i'm in Page Editor, i can go to this item and edit this in German, even if there is no version yet. The first click on the save button will create the first version for me.
When i want to find the item trough the Content Search, my natural way of query it is by making the same filter (probably by template, path and some channeling or whatever) AND a filter by the language property of the SearchResultItem, since i don't want multiple results for the same item. But since there is only a english version yet, the index only contains a single result in english and because of the language filter, i cannot find this item to call GetItem on it.
Since writing this question initially, i see two approaches to get around this:
a) Remove the language filter in Page Editor mode and filter it afterwards somehow (I don't know whether i'm able to get an item which i can edit in Page Editor in the German language)
b) Create a Page Editor specific master search index which holds an entry for all languages in the solution for every item, even if there isn't any in the specific language. I can add a computed field to indicate, whether this result is a real item version or not to filter at some point if necessary. Probably i'm able go call GetItem on this and enable Page Editor capabilities.
With lucene, i cannot find the detail item in a (currently) non-existing language version when i want to resolve it by it's display name trough Lucene (because there is no language version indexed yet).
EDIT for question 2
This goes hand in hand with question 1
In relation with Workflows, i see possible struggles with the Version which is indexed. Is the first Version in index, before you approve the version? Otherwise the overview has no chance to show this item till it is approved in Content Editor.
Has anybody used the Content Search for Page Editor relevant actions and has some advice how to get around such problems?
I've had the same issues with Sitecore 7, and while I don't have the ultimate solution for you, hopefully you will find the following information helpful.
I can't word my answer any better than this post: http://thegrumpycoder.com/post/75524076869/sitecore-content-search-beware-of-the-context
With Sitecore ContentSearch you are choosing which search index you would like to use. You are likely using sitecore_master_index when in Page Editor / Preview mode, and sitecore_web_index on the published site. As the web database only has one version of each item, you don't need to worry about their being multiple versions in the index. However sitecore_master_index will by default index all versions of an item in all languages. You can then potentially see items showing up multiple times in your listings components if you're not careful.
Sitecore 7 has a field "_latestversion" which you can add to all your queries, but it isn't reliable for a couple of reasons:
The latest version isn't necessarily the correct one, taking into account things like publishing restrictions and what date you have selected in the "Experience" view.
Due to a bug I have often been able to cause there to be more than one version of an item in the index where _latestversion is 1. Not after a complete rebuild, but after an edit or two. I saw this in Sitecore 7.0 and I'm not sure if it's been fixed yet.
Read http://www.sitecore.net/Learn/Blogs/Technical-Blogs/Sitecore-7-Development-Team/Posts/2013/04/Sitecore-7-Inbound-and-Outbound-Filter-Pipelines.aspx for more information on how you can use "Inbound filters" to ensure only the latest version makes it into the master index, but bear in mind that doesn't really solve the core issue in my opinion as the latest version isn't necessarily the correct one.
So taking this, and the fact that you need language fallbacks, you should probably not filter these results out at the Lucene level, but do the necessary magic yourself in code. This would need to:
Group versions together by their items
Choose the right version based on the current language, date, security and workflow
Apply your desired fallback logic if said version isn't found
Somehow work in pagination into this in a way which performs well
I also feel the following SO question is relevant:
Indexing Sitecore Item security and restricting returned search results - something else which can catch you out when you expect the Search API to work exactly in the same way as the Query API.
I'd be interested to know your thoughts and if you ever find a better solution! Thanks, Steve.
I have three databases that all have the contents of several web pages in them. What would be the best way to go about searching all three and having the most relevant web page at the top of the search results?
The only way I can think of is break down content by word count and/or creating a complex set of search rules to give one content priority over another. This might be more trouble than what it's worth, but I was wondering if anybody knows a way or product out there that would be able to help me.
To further support Ivans answer above Lucene is the way to go. You haven't mentioned what platform you're on so I'll point out that you can use a .NET port of this too.
If you do use Lucene there is a very good book from Manning on the subject which I recommend you look at.
When it comes to populating your index, you have a couple of choices. For starters you can just dump all of your text into the index and allow the engine to just search on it. However, I'd recommend adding fixed fields to your index which will allow you to support things such as partitioned searches or searches against those fields only.
To explain, lets say you have a field for the website. Then you can partition your index by restricting the index search to those documents that have that website in that field.
The other process is to extract points of interest from your document and allow searches on those without searching the entire index entry. Your mileage may vary with this as the lucene engine is very well written so it may simply allow you to collect your searches into more logical units which helps you with your solution.
I've done this myself and it helps when answering management questions about what exactly is searched and indexed.
HTH!
If you're using MS SQL Server then the full text search can return a ranking for you. I haven't used it, so you'll need to check the documentation or online for specifics.
How would you create a database in Microsoft Access that is searchable only by certain fields and controlled by only a few (necessary) text boxes and check boxes on a form so it is easy to use - no difficult queries?
Example:
You have several text boxes and several corresponding check boxes on a form, and when the check box next to the text box is checked, the text box is enabled and you can then search by what is entered into said text box
(Actually I already know this, just playing stackoverflow jeopardy, where I ask a question I know the answer just to increase the world's coding knowledge! answer coming in about 5 mins)
My own solution is to add a "filter" control in the header part of the form for each of the columns I want to be able to filter on (usually all ...). Each time such a "filter" control is updated, a procedure will run to update the active filter of the form, using the "BuildCriteria" function available in Access VBA.
Thus, When I type "*cable*" in the "filter" at the top of the Purchase Order Description column, the "WHERE PODescription IS LIKE "*cable*" is automatically added to the MyForm.filter property ....
Some would object that filtering record source made of multiple underlying tables can become very tricky. That's right. So the best solution is according to me to always (I mean it!) use a flat table or a view ("SELECT" query in Access) as a record source for a form. This will make your life a lot easier!
Once you're convinced of this, you can even think of a small module that will automate the addition of "filter" controls and related procedures to your forms. You'll be on the right way for a real user-friendly client interface.
This is actually a pretty large topic, and fraught with all kinds of potential problems. Most intermediate to advanced books on Access will have some kind of section discussing "Query by Form," where you have an unbound form that allows the user to choose certain criteria, and that when executed, writes on-the-fly SQL to return the matching data.
In anything but a flat, single-table data structure, this is not a trivial task because the FROM clause of the SQL is dependent on the tables queried in the WHERE clause.
A few examples of some QBF forms from apps I've created for clients:
Querying 4 underlying tables
Querying a flat single table
Querying 3 underlying tables
Querying 6 underlying tables
Querying 2 underlying tables
The first one is driven by a class module that has properties that reflect the criteria selected in this form, and that has methods that write the FROM and WHERE clauses. This makes it extremely easy to add other fields (as long as those fields don't come from tables other than the ones already included).
The most complex part of the process is writing the FROM clause, as you have to have appropriate join types and include only the tables that are either in the SELECT clause or the WHERE clause. If you include anything else, you'll slow down your query a lot (especially if you have any outer joins).
But this is a big subject, and there is no magic bullet solution -- instead, something like this has to be created for each particular application. It's also important that you test it thoroughly with users, since what is completely clear and understandable to you, the developer, is often pretty darned mystifying to end users.
But that's a principle that doesn't just apply to QBF!
At start-up, you need to show a form and disable other menus etc. That way your user only ever sees your limited functionality and cannot directly open the tables etc.
This book excerpt, Real World Microsoft Access Database Protection and Security, should be enlightening.
For a question that vague, all that I can answer is open MS Access, and click the mouse a few times.
On second thought:
Use the "WhereCondition" argument of the "OpenForm" method
If the functionality is very limited and/or specialised then a SQL database is probably going to be overkill anyhow e.g. cache all combinations of the data locally, in memory even, and show one according to the checkboxes on the form. Previously you could have revoked permissions from the table and granted them only on VIEWs/PROCs that queried the data in the prescribed way, however security has been removed from MS Access 2007 so you can you now really stop users bypassing your simple app using, say, Excel and querying the data any way they like ...but then isn't that the point of an enterprise database? ;-)