Search module

Target release
User Story	SWIK-199 - Getting issue details... STATUS
Document status	DRAFT
Document owner	Serafeim Chatzopoulos
Designer	Christos Pateritsas
Developers	Serafeim Chatzopoulos
QA
Work Package & deliverables
Related JIRA tasks	SWIK-138, SWIK-230, SWIK-267, SWIK-268, SWIK-269, SWIK-274, SWIK-405, SWIK-556, SWIK-557, SWIK-686, SWIK-828, SWIK-839, SWIK-882

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.

#	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		SWIK-686, SWIK-882
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.
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		SWIK-839

UI proposed following discussion in SWIK-707 . Mock up below proposes:

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:

Below is a list of questions to be addressed as a result of this requirements document:

Question	Asked by	Outcome

Feature	Status

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?