Making the app work the way the user expects it to work
Every morning I get an email report containing all of the Full Text Searches that our customers performed within our SelfService application, along with how many results each search resulted in, and if there were any errors. Our volume is low, so it’s not too much information for me to process on a daily basis. This report allows me to gain some knowledge of who’s using the app, what types of things they’re searching for, and if they are finding answers to their inquiries.
This morning’s report showed that a customer searched for just an integer (for our example, we’ll say they searched for 12345), and came up with no matches. Knowing the customer, I knew they were searching for a case number. However, our search is currently setup to perform full text searches on the textual information with a solution (KB article).
As soon as I got the report, I immediately understood. The customer just assumed that the search page would handle a case id number. Of course! It’s obvious. Unfortunately, the customer’s assumption was wrong. But his intentions were good. Why wouldn’t he assume this? This is what Google does. I type something in Google, and it just knows what I want to do, such as whether I want it to perform a search, act as a calculator, perform currency conversion, or any of the other myriad of functions that Google can perform, from just a search box. Users are expecting applications to work similarly, even if these apps are from different vendors. I think there’s a lot of value in seeing how your users think the system should work, or more importantly, how they want the system to work, especially when the usage was out outside of the original thought box.
Kevin and I sat down, had a brief discussion about this, and then kicked out a story card:
As a user, I can search for a case or solution by entering its id number in the search box, so as to make it easier to find information within the system.
As I kicked off a 3 hour install of Visual Studio Service Pack 1 on my machine, I had some time available. So I grabbed the story card and ran with it.
Check if the user entered an integer (as our case and solution IDs are all integers), and if so, perform a query to see if there is a case with that ID that the user is allowed to view, and also query to see if there is a public solution with that id. If we find a case and/or solution, include those in the results list.
var Solution = FCSession.CreateGeneric('probdesc');
var Case = FCSession.CreateGeneric();
if (isInteger(keyword) == true ){
Solution.AppendFilter("id_number", "=", keyword);
Solution.AppendFilter("public_ind", "=", 1);
Solution.BulkName = 'fts_integer';
Case.DBObjectName = 'cas_secure';
Case.BulkName = 'fts_integer';
Case.DataFields="case_id,case_title";
Case.Distinct=true;
Case.AppendFilter("case_id", "=", keyword);
Case.AppendFilter("contact_objid", "=", FCSession.item("contact.id"));
Case.Bulk.Query();
}
if (Case.Count() > 0){
buildCaseRow(Case);
}
if (Solution.Count() > 0){
buildSolutionRow(Solution);
}
Pretty simple.
Kevin and I tried out a few different UI formats and styles, and here’s what we ended up with:
Notice that I searched for "100", and I got back Case 100, Solution 100, and all solutions that contain the word "100" in their text.
We went from idea to production rollout in just a few hours. Very cool.
I’ll continue to keep an eye on what users are searching for, and how they use the system. If we recognize a need for more changes (as we inevitably do), then we’ll continue to evolve the product. It is software after all.
We’ve already kicked around another idea of full-text searching within cases that the individual user has access to. What do you think? Is this valuable? What other ideas do you have? We’d love to hear what y’all think!
