...
...
...
...
...
...
...
...
...
| Page Properties | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Summary
- This module will implement the search functionality in slidewiki platform, i.e. the users will be able to search slidewiki content & semantics. Content search will cover most of slidewiki entities like decks, slides, comments, questions, tests, users, institutions, etc.
- A simple search box for keywords as well as advanced search fields will be provided so that user can set specific criteria to his searches.
- Filters will also be provided in the results page in order for the user to manage the results better.
Background and goals
Assumptions
Requirements
| # | Title | User Story | Importance | Notes | JIRA |
|---|---|---|---|---|---|
| 1 | Relevance | If one searches with "Semantic Data Web Lecture Series" the whole expression should be queried first, then parts of it and finally the words themselves. | Must Have |
This is the default behavior of queries in SOLR | SWIK-138 |
| 2 | Auto |
| -suggest | Auto |
| suggestion should be created in such a way that it will propose the options of existing presentations or decks. For instance, if the user types “Open E”, auto fill should provide “Open Education” rather than “Open Edit”. Therefore, instead of searching for every type of auto filling, it should scan the database to match the existing ones. | Must Have |
| 3 | Tag cloud | Tag cloud was taking up too much space in the old platform. A possible solution is that it should be hidden and appear only when called. |
3
| 4 | Search Functionality | Basic Search Box: user inserts keywords and gets results Advanced search: Apart from the basic search box, filter fields are also provided to the user so that search criteria are applied in the initial query | Must Have |
| SWIK-138, SWIK-267, SWIK-268, SWIK-269, SWIK-405, SWIK-828 | |||||
| 5 | Facets in results | Facets will be provided in the results page, so that results can be further filtered | Must Have |
| 6 |
...
| Sorting | Search results should be sorted based on relevance, title, last update date etc. | Must Have |
User interaction and design
Search results UI
UI proposed following discussion in SWIK-707 . Mock up below proposes:
- all search entries are marked up as H3 to provide structure to the content
- icons are labelled with aria-label
1 entry per deck.- the one with the most recent modification
Below deck title
- deck description
- date of the last modification of the deck, preceded by "deck" (covers off inaccessibility of the icon)
- followed by owner OR by "user" to show who last modified it
On pressing "Other versions" button, user sees other version of the deck. This could include versions in different languages.
1 entry per slide - the one with the most recent modification
Below the slide title:
- snippet of slide content
- date of the last modification of the deck, preceded by "slide" (covers off inaccessibility of the icon)
- followed by owner OR by "user" to show who last modified it
On pressing "Other versions" button, user sees other deck title containing the slide.
.
The other UI approach to look at is links below the entry that opens a different set of search results as per Google Scholar:
Description of fields/input/elements + validation + test scenarios
...
Source material for user/stakeholder feedback
Requirements (/user stories) from pilot roadmap:
Evaluation/improvements by Farid Hasanov master thesis :
Evaluation/improvements by Farid Hasanov master thesis :
Issues with search functionality. Several issues arose in terms of searching for the website. The structured overview of them is shown here.
Issue 1 - Relevance. Search results could be sorted only by date, and relevance of decks were not taken into account. For instance, if one puts into a search field an existing deck such as “Semantic Data Web Lecture Series”, the desired deck won’t even appear on the first page. All the results containing the words “Semantic”, “Data”, “Web”, “Lecture” and “Series” are shown there and they are ordered by date only. The issue is that, while querying from the database, every word in the expression is queried separately, whereas ideally the whole expression should be queried, then parts of it, before finally the words themselves.
Issue 2 - Auto fill Another aspect is form auto fill. Auto fill should be created in such a way that it will propose the options of existing presentations or decks. For instance, if the user types “Open E”, auto fill should provide “Open Education” rather than “Open Edit”. Therefore, instead of searching for every type of auto filling, it should scan the database to match the existing ones.
Issue 3 - Result sorting. The third issue is that the user cannot view search results in different languages, however that option is available there. The scope of search results stays the same in spite of the selected language. Either those commands are not func- tioning, or there are some bugs in them.
Source. Three previous issues were discovered during my own experience with the web- site and later were reiterated by all users.
Issue 4 - Tag Cloud. One user complained that the Tag Cloud takes up too much space and is annoying because it is not always used.
Source. This issue was mentioned by one user.
Possible solution. It is better to be hidden and appear only when called. More informa- tion and a mockup for this issue will be provided below.
Metric violated: Search functionality.
According to formula 3.8 search functionality will be 0% for Slidewiki. The problem is illustrated here:
Figure 5.15: Original search.[51].
Possible Solution. Some mockups aimed at improving the search functionality will be shown here. The first solution looks like a “Brute-force approach”
Figure 5.16: Mockup for search. Solution 1
Using this approach, the user should select one of the filters before searching for data. The drawback of this approach is that, each time it is used, some filters have to be applied.
The second solution will be called the “Double search”. This mockup differentiates clearly between searches and separates the author from all the other instances.
Figure 5.17: Mockup for search. Solution 2
The obvious drawbacks will be, once again, selecting the filter, and the fact that it could be harder for a developer to code two search engines. However, the user now has two different search domains: Content and Authors.
The third solution provides an advanced search menu which does not differ greatly from the one Slidewiki possesses, but gives more options for filtering. Using this approach, the original search parameters of Slidewiki should be kept. The figure below will be opened after the user clicks “search”.
Figure 5.18: Mockup for search. Solution 3
The advantage of this approach is that the user can quickly search for something and already see the results. In case of dissatisfaction he or she can change the domain from presentations/decks to authors. This solution saves time if the search object is highly relevant. So if a user searches for “Semantics”, he will get a result for “Semantic web lectures” at once without using the advanced search. Hereby I assume that this approach should be favoured over the previous two. Concerning searching for an author, the search should be fulfilled not only by the user’s login name, but also by his real name or e-mail address. To this end, coders should create a bind between login name, real name and e-mail and index them in database. In addition, here, a fixture for the Tag Cloud issue is proposed. The Tag Cloud will be moved to the tabs menu and can be accessed from there. The user can activate the tags by selecting them, thereby opening more space to the left and allowing the display of more search results.Comments from SWIK-863 (we should consider them when re-designing search results):
- would be better if we aligned the search results and display it in a more structured manner (maybe reuse deckOverview components and something similar for slides with thumbnail).
- can we use the same icons used in deck tree for slides and decks?
- what I see as other versions are not exactly other versions of slides e.g. when I try http://testing.slidewiki.org/search/q=semantic%20web it shows different usage of the same revision. Is it the intended behavior?
Requirements (/user stories) from pilot roadmap:
Evaluation at UniBonn :
Project Partners feedback: