1. The difficulty of searching
A proverb says, a picture is worth a thousand words. Our human brain is able to capture visually information faster than written or heard information. Using visualisations has lots of benefits: clearer and more comprehensible communications, better documentation of results and increased follow-up while presentation. Why is this vast potential of visualisation technology not completely used?
The troublemakers for the creation of visualisation are two necessarily fulfilled qualifications. First of all, the user or illustrator needs drawing skills to picture the visualisation symbols. Additionally, creativity is required to know which symbol to pick for a special term. At least symbols transport so much information that choosing the perfect one in relation to the context is not quite easy.
First problem: Drawing skills
The company Bikablo GmbH & Co. KG developed a visualisation concept and language everybody can draw. They designed symbols to visualize the most diverse terms. These symbols consist of low level geometrical figures with some special effects like a primitive shadow, so that drawing them is simple when also producing a good look. Therefore, this concept is used in this application.
Second problem: Creativity by choosing the perfect symbol
When the illustrator starts thinking about using a symbol to illustrate a term, he often has no specific idea what the final symbol will look like. This is because, the requirements to the characteristics of the symbol are not completely defined at this point of search. Is an item or a figure needed? Which symbol transports the information correct in the given context? To answer such issues, the illustrator needs some inspiration how the different mentioned characteristics could be pronounced. This is the base of Exploratory Search.
Inspiration arises from searching out possibilities. Therefore, the seeker will look for an overview of the various opportunities to resolve his problem. If he gets a promising approach, then he will focus on this and properly define it as requirement for the further search. These two parts of Exploratory Search are named as ‘Exploratory Browsing’ and the following ‘Focused Searching’.
This pattern of getting an overview, trying out possibilities, specifying and rejecting requirements to the final solution ends up in a very dynamic process. The contrary is Iterative Search, which is straight forward because of the predefined requirements to the solution. However, the seeker never explores that much of the information space he does with exploratory search.
To put Exploratory Search into practice as good as possible, the application should present inspirations to the user associated to the current point of search at any time. This collecting of ideas supports being aware of the requirements for the final symbol. As a result, the user should be able to find the ‘perfect’ symbol easily and efficient despite the dynamic and perhaps chaotic kind of search.
An intuitive and clear user interface allows to interact easily with the application and its features. Therefore, it should be a single-page with different areas per functionality. The user should be able to define his problems while the interface reduces uncertainties with orientation guides. All functionalities are exemplarily shown in the wireframe below
Input of search terms
The search term can be written in the input field on the top. It is possible to enter one or more terms, which are connected with AND. The best matching symbol (mainSymbol) to all entered terms is calculated then and also appropriate alternative symbols (see ‚Display search results‘). While typing a dropdown appears with existing terms that match to the current input. So, the user is supported by finding a possible term.
All symbols can be part of a category, like icon or figure. To create a more specific search it is possible to filter the search results by these.
Display search results
The application calculates a symbol, called ‘mainSymbol’, that fits best to all search inputs (terms and filters). It is shown as the centre of a net structure. This net structure consists of appropriate alternative symbols which are related to the mainSymbol. At this stage of view, the user can collect ideas how the final symbol could look like, which is ‘Exploratory Browsing’. By selecting a related symbol for ‘Focused Searching’, the user can either unfold (exemplarily shown below) or choose it as new mainSymbol.
The user gets inspirations because of usefully cross-linked data. Furthermore, he has a good overview of the symbol results without long, scrollable result pages.
To enable the possibility of returning to a previous mainSymbol a timeline exists. In this timeline all selected mainSymbol are listed one after the other with the current at the front. The user can choose one of these symbols to select this again as mainSymbol. Furthermore, he can reset the timeline to null.
Detail view to mainSymbol
All details to the current mainSymbol are shown in a tab below the results. The user finds a larger view of the symbol, some metadata like the internal id and the source of the symbol, and the categories the mainSymbol is part of and the term.
If a logged in user has administration rights, he is able to edit the terms of the mainSymbol in the detail view. He can delete existing terms and create new ones.
Every user has the possibility to select a current mainSymbol as favourite clicking the favourite button. The favourites are marked with a little star to highlight them in the result view. Furthermore, they are shown in a special area as a collection for a good overview.
Selecting the target-symbol
If the user decides to choose the current mainSymbol as target, what means that this is the best symbol for his problem context and the current search input, he can click the target button to inform the application about that. Thereupon, the application updates relations between the search inputs and the target symbol and appropriate ranking values.
Resetting the whole search
All search inputs as well as the timeline and result view can reset with one click to start a brand new search.
The web-application is realised with a client-server-architecture which divides in three layers. Implementing the different functionalities and components with its concepts have to put into practice most of all.
A database is responsible for persisting the data. The data model arises from the key tasks of the application. After strategic considerations which entities are needed the domain model below developed (which is presented graph-oriented due to the used technology). Thereby, the main entity is symbol while the others define different views to symbol. All things considered, a net structure between the data developed.
The relations between the data are absolutely necessary to suggest useful alternatives to the current point of search. A particular position takes the ranking attribute at some of the relations. The mainSymbol, the most appropriate symbol to the search input, is calculated in assistance of these values. The higher the better a symbol matches a term or category.
Neo4j is used to realise the database. This is a NoSQL graph-database which maps perfect to the defined data model determined by relationships. Especially the ranking attribute is handled easier than in a typical relational database
The web-service works as intersection between the web-client and the database via JSON. Its functionality is to ensure to create, modify and return the correct data of the data repository to the web-client.
The web-service consists of three layers:
- Controller. This is a dispatcher, which offers endpoints the web-client can call. Every endpoint realises a function which mostly receives a parameter including information that are relevant for searching.
- Service. There are different kinds of services to preserve the different views to the entity symbol and to work clearer with the net structure out of the database. All services fundamentally resolve the same two tasks: Analyse the transferred information from the controller out of the web-client call accordingly functions in the associated repository.
- Repository. Just like the service, the repository layer is divided into four. In the functions of the repositories, database queries are assembled depending on the transferred information. Then they are send to the database to receive the correct data and subsequently returning them through the layers up to the web-client.
The web-service is a Java-Backed using Spring Boot to connect the technologies of the frontend (Angular) and the database (Neo4j). Furthermore, Spring Boot allows to implement an executable application, a backend in this case, very easily.
The architecture of the web-client is given when using the web-application-framework Angular. Single modules contain all functions to realise an element of the user interface, for example the search input or the detail view of the current mainSymbol. These modules consisting of the same elements: view, component and two optional services, dataService and propertyBag. Beyond that, the component of all modules can use a global communicationService to exchange data with other modules.
- View. Defines the element’s look using HTML with dynamic binding options.
- Component. Implements the functionalities to present the elements and to calculate the displayed data. Deeper functionalities which have no specific relation to the presentation are realised through services.
- DataService. This local service is used if data from the data repository are required for the module’s presentation. Data is just requested if they are really new needed here, so just on-demand. The dataService addresses via special endpoints to the appropriate function of the web-service / backend to get the data.
- PropertyBag. This is a locale data cache for different properties or models which only its module is interested in. These properties are such ones changing by data requests of the dataService to get anytime the correct current values.
- CommunicationService. Similar to the propertyBag, the communicationService holds properties. But these are relevant for more than one module. For example, the mainSymbol should be shown and updated in the symbolView as centrum of the net, in the breadcrumbMenue which shows the timeline of selected mainSymbols and in the detailView of the current mainSymbol. To make this data exchange between the modules work, the properties are observable here. Therefore, every component which is interested in a property’s value can subscribe to it and receive value changes. This communication is very important to realise the collecting of ideas and to hold all elements on the single page updated.
The whole bachelor thesis of Nadine Göbertshan about this issue is found in the following PDF.