In February (2014), Nakisa released version 4.1 of their suite of visualization solutions. This saw a number of updates across both the org visualization (SOVN) and talent visualization (STVN) applications. Amongst these was a new SOVN OrgChart feature called “Quick Search”.
In this post I’m going to take a look at this new functionality and provide…
- An overview of what Quick Search is for and how to use it.
- A quick peek at some of the Quick Search configuration.
- A look at some of the key behaviours of Quick Search.
In a subsequent post I’ll be taking a look at some additional search query syntax that’s guaranteed to boost your credibility as a Quick Search power user.
Overview
In previous versions of OrgChart, searching was always carried out via the listings functionality. By default this provided three search options – employee, position and organizational unit. The new Quick Search feature allows users to search for employees (only) from an input field that is located at the top of the OrgChart interface - i.e. you can search from the chart without having to switch over into a listing.
As you might expect, the new feature is also available in the OrgHub for Mobile application.
To use the Quick Search, a user need only type their search term(s) into the Quick Search field. As they type, the system will automatically begin retrieval and as more characters are entered, the list will be filtered to reflect the changing search parameters.
The results are displayed immediately below the field in a dynamic list. By default the search term(s) are highlighted in the results showing exactly what has been matched on.
The set of data fields searched is the same set of fields that will be displayed, or rather where there is data being held. For example, note in the result set above that only Anja Müller has a telephone number.
The six available fields are:
- Employee Name.
- Location.
- E-mail.
- Telephone.
- Cell Phone.
- Fax.
Selecting (by clicking; or tapping in OrgHub for Mobile) one of the results opens the corresponding employee details panel.
By default, OrgChart will return the first five results. An option to load more is then displayed.
Selecting “See More” loads the next set of five results and scrolls the list down. This process may be continued until there are no more results to load.
In OrgHub for Mobile, the results and process are similar though there are a few notable differences.
The first is that a few “null” values start creeping into the results. Whilst this doesn’t invalidate the data it does detract a little from the cleanliness of the results and means that more scrolling to view results may be required.
The second is that rather than up to five results being returned by default it returns up to fifteen (this is actually a configuration option in the build).
When the bottom of the initial results is reached, an option appears to allow the user to load additional results. Rather than loading an additional five results, the default (again build configurable) is to load a further ten results.
Configuration
The Quick Search feature is currently only available for live (or hybrid) builds. The basic configuration can be achieved by setting the QuickSearchSAPConnection connection string (in AdminConsole) to point to your desired SAP system. The user account it uses for the connection will of course require a suitable level of access to enable it to surface the desired search results.
Once the connection has been configured, when the build is published it will trigger an extract to run in the background (the publish will complete meanwhile as normal). Nakisa estimate this extract usually takes around 15 to 20 minutes to complete. The extract builds a search index file that is stored in Root\Database\QuickSearchIndex. The index is then kept up to date by a periodic “delta” update process – the admin guide states that by default this occurs every 30 minutes.
There are also a number of files (QuickSearch*.txt) within the SettingsResources directory that can configure various options for the search.
If you recall I mentioned earlier that OrgHub for Mobile returns a default of fifteen results and a further ten results per “See More” selection. These are both options available by specifying a numeric value in the QuickSearchMobileInitialCount.txt and QuickSearchMobileIncrementCount.txt files respectively. Unfortunately these options are not configurable (in this first release) for the browser based version.
Interestingly there is also a QuickSearchMinUpdateInterval.txt file. This file contains a default single numeric value of 3000000. I’m not sure if this actually relates to the index update frequency for Quick Search, but assuming it is and that it is a timer value specified in milliseconds (a fairly standard convention for many systems and programming languages based on factors such as system clock accuracy), this would equate to 50 minutes rather than 30 minutes.
Behind the scenes, the Quick Search appears to run on Apache’s Lucene (v4.3). This is a widely used full text index and search engine system and is released under the Apache license. So basically it is a proven technology requiring no additional licensing costs to make use of it.
Search Behaviour
With the release of Quick Search I decided to spend some time experimenting with it to see if I could figure out if it supported any advanced search features. The good news is that it does.
Extended Characters
First of all I thought I’d take a look at the use of extended character sets. You may recall from an earlier example that Anja Müller was in the search index. So I decided to see what would happen if I searched for “Muller” and “Müller”.
As you can see the results are identical and inclusive of the name “Müller”. Reducing the search term however to just the first two characters gave differing results.
So from this we can see that searching with an accented character will return only results containing that accented character, whereas searching using an unaccented character will return unaccented and accented character results.
Wild Cards
On occasion you may wish to carry out a search where you perhaps wish to put in some place holders that could represent other characters. These place holders are typically referred to as wild cards and there are a couple that seem to work for Quick Search.
The first wild card is a question mark (“?”). This character represents exactly one character and can be placed anywhere in the search. Placing it in the middle or the end for example give the sorts of results you might expect.
Putting the question mark at the start did give good matches, but doing so also caused the null values to reappear.
Multiple question marks may also be used (consecutively or non-sequentially).
e.g.
- mu??er
- m?lle?
The second wild card is the asterisk (“*”). An asterisk optionally represents multiple characters. i.e. it may represent any number of characters including just one character or even no character at all.
Again the asterisk can be used at the start / end (though when used at the start, null values can appear) and multiple asterisks may be included in the search query.
It is of course also possible to combine the use of both types of wild card.
There are also a couple of SettingsResources files that are applicable here – QuickSearchEnableLeadingWildcard.txt and QuickSearchEnableTrailingWildcard.txt.
QuickSearchEnableLeadingWildcard.txt contains a single boolean value of “true” or “false”. By default this is set to “false”. This setting controls whether to prefix search query terms with an asterisk wild card.
Logically enough, QuickSearchEnableTrailingWildcard.txt also contains a single boolean value of “true” or “false”, but by default this is set to “true”. This setting controls whether to append search query terms with an asterisk wild card.
So what does this mean for building our search queries?
If we search for the first few characters of an employee’s first and last names without and with asterisks at the end (to replace the omitted characters), we can see that the results are identical.
If however we take the last few characters of an employee’s first and last names without and with asterisks at the start (to replace the omitteed characters), we can see that the results are in fact quite different.
So this is an important behaviour to keep in mind and understand. If you are searching for example for someone’s name, typing in the first few characters will yield the result, but if you miss any of the first few characters you’ll need to prefix an asterisk.
Summary
With the introduction of Quick Search into OrgChart, Nakisa have brought a new style of searching into their application suite. One that is much more akin to the types of searches must of us execute every day via our preferred internet search engine. This gives users a much more familiar way to interact with the organisational data and has the potential to improve the amount of use OrgChart gets from users and to improve user’s productivity as a result.
So that’s my brief look at the essentials of Quick Search, but like any modern search engine, there’s more power waiting to be tapped by those who know how to use it. In the next post I’ll be taking a look at some of the Quick Search query syntax that will be a must for Nakisa consultants, admins, trainers and power users.
- SAP Managed Tags:
6 Comments
