Search UI Ideas

{toc}

h1. Currently Implemented
Semantic search realisation as per RS3.1 iteration. There are no data objects migrated in the test server at the moment so the search result and faceting is not visible.
!Nuxeo_screenshot.png!

Jana: Changing Search UI should be planned for another iteration
Hollie: These ideas are a concept for the whole project not a suggestion of changes for sprint 1, we'd hope to achieve something like this over the whole project.

h1. Initial BVA wireframe

Using this idea of building up the search based on relationships to make complex search queries, we developed the interface and interactions. We looked at different ways you could express this type of search but make it easier to understand and simpler to use.
We combined this with some of the interface ideas already proposed to come up with this.
Detailed explanations of each steps functionality can be seen in the yellow post it notes.
!search_example1.jpg!

h2. Notes

Search history / Recently visited
* Logs recent searches to allow user to quickly go back to past searches.
* Should there be two searches? One for project and one for collections?
* If two how are they represented?
* Does collections search take precedence?
* Should these results be mixed?

Settings - change thesaurus
* As all auto completes use the thesaurus this would effect whole search

1. Keyword / term search
* Free text with autosuggest
* Autosuggests helps to narrow the users choice quickly into the right topic eg actor / thing / place
* Freebase style definitions pull out snippets of description if topic
* pressing return completes the search as a free text search rather than defining as a topic

2. Relationship options
* OR - opens the thesauri tree adds same as terms or narrows / broadens search
* WHICH - brings up relationship options and topic input box. Only available relationships shown... Could include a number here...

3. OR option Thesaurus Tree
* Taken from Dominic's mockup different metaphor for the tree of look of the thesauri. View can be changed to the more traditional tree format.
* Option to swap thesaurus

4. Which option
* This opens up 5 the relationship dropdown

5. Relationship picker
* Only available relationships shown... Could include a number here...

6. Topic input
* Same interactions as main input must be a thesauri topic.

Faceted search
* Uses to ontology to create dynamic guided navigation relevant to the search

Sort by
* Relevance / A-Z / date etc

View
* List view / thumbnail view / map view / timeline view

Results tabs
* Results = Collections results / RS internal results
* Graph view = graph view of internal results
* External results = dbpedia results etc

Results settings
* Controls what info is show in the result snippet eg date, location etc

h1. Query as a Sentence
Looking at these functions and user actions we saw the advantage of trying to make the interface similar to a sentence structure to simplfy it. The 3D coform UI although extensive in terms of functionality is quite a complex looking interaction which lacks prompts and clues for the user as to how powerful the search is. Changing the emphasis to structure a meaning search sentence means the user is clear about the next action.
!Screen shot 2011-11-24 at 16.22.23.png!

* OR could possibly be an keyword input as well as the narrow / expand
* AND Keyword or narrow / expand
* Which can only be a relationship
* Relationships shown are relevant to the type keyword first entered eg actor has different possible relationships from a thing
* Thing is called object for ease
* Find is used rather than search as it seem a more exploratory term and also to establish that this search differs from others
* Language maybe changed to be more user friendly as per Ken's suggestion
* May need an indication of how complex the search is
* Search should be being modified as refined (If possible)

h2. Click-through Demos
Please have a look at these slideshows and let us know what you think about the idea of constructing sentences and also the interactions you think are important if we go down this route.
# Object [http://dl.dropbox.com/u/12395553/Bureau-VA/Research%20space/demo%201/index.html]
# Actor [http://dl.dropbox.com/u/12395553/Bureau-VA/Research%20space/demo%202/index.html]
# Object longer [http://dl.dropbox.com/u/12395553/Bureau-VA/Research%20space/demo%203/index.html]

h2. Visio diagram (Maria)
The purpose of the example is to to show a how user could define a search based on real data, currently existing in RS and to assess if such search logic is applicable into the RS. Do not take into account the UI controls used into the example, I just found them as most appropriate in MS Visio.
[^Query as Sentence-Visio.vsd]
!Query as Sentence-Visio.png!

h2. Issues with Query as a Sentence
Vlado:
- We need to define the grammar of AND/OR/WHICH (see [#Jira Searches] below)
-- As presented you cannot specify [precedence|http://confluence.atlassian.com/display/JIRA044/Advanced+Searching#AdvancedSearching-SettingPrecedenceofOperators] so you cannot say eg "(typeIs Marble or objectIs Vase) and placeIs China"
-- I'm not sure such structured searches are in RS3 scope (to be discussed with Dominic)
-- For now we're searching only for Museum Objects, so WHICH is not needed (all relations are about objects)
-- Onto's [KIM Latest News showcase|http://www.ontotext.com/kim/showcases] has examples of "pattern search" that use different kinds of objects in a business-meaningful configuration.
Eg ?person holdsPosition ?pos inOrganization ?org (question marks are at things being searched)
- Thesauri
-- "Switch thesaurus" is not needed, since every relation must know its applicable thesaurus (or thesauri if we combine several thesauri in a single relation)
-- "Tree with checkboxes" is not applicable to a large thesaurus (eg 80k geo names)

Hollie:
- On structural or scoping discussion we need Dominic's feedback to progress, I've added a few comments below.
- The designs represent what is hopefully possible over the course of the project, these are conceptual mockups rather than suggestions for sprint 1.
- The kim example is what we are suggesting it is just more context sensitive and interactive rather than selecting a predefined pattern.
- Grammar needs further definition. Dominic whats are your thoughts on this?
- Browsing large thesauri is difficult in any senario, we will look at different methods for doing this within the concept. We can remove the switching Thesauri option.
* Precedence: Although the parenthesis () are not shown I agree they are needed in complex queries we saw them as were implied by the sentence structure
* When OR is used it always groups itself with the previous statement that is the nature of an OR operator.
* The example you use would be presented as
(Keyword search marble type: thing / OR keyword search vase type: thing) / WHICH: IS FROM China type:place
the latter is implied by the IS FROM option
* WHICH is the mechanism to bring up the relationship options so is needed if we plan to use that type of searching. If not WHICH then some method of using relationship data 3D coform use the relationship dropdowns, WHICH is a way to structure that type of command.

Austin:
- I wonder if it would be a good idea to have a "researcher friendly" set of vocabulary too in the search option - rather than "is of type" could be "is made of" ?
- Vlado: exactly my point: "CRM Search" collapses all object characteristics to one "thing has type". But to be able to autocomplete against the appropriate thesaurus, and for better understanding by people, it's better to differentiate these as we've done in RS3.1

Hollie: Yes agree
- we used the examples from the system proposed by Doerr. These are:
-* Has type
-* Is part of
-* Is similar or same as
-* Has met
-* From, has founder or has parent
-* Is origin of, founder of, or parent of
-* At
-* Refers to
-* Is referred by
- Dominic has included definitions of these types [here:|Search Mockups (BVA)] in the comments.
- I believe Maria has been working on the relationships which Ontotext will be able to do. So if we could confirm with them and then work on the language.
- Vladimir or Maria are you able to provide that list? Are you also working from the Doerr model?

Maria: Yes, you could review the FRs created for RS3.1 in [Search Design].

Hollie: I've complied this list from the link you gave, please add any I have missed.
- These seem to be starting with an Object
-* has owner
-* has type
-* from place
-* from time
-* has material
-* has applied technique
- Are there anymore relationships you are planning to map? Will you be doing more Actor / Place / Event / Time based relationships?


h1. Jira Searches
Jira has excellent searches

h2. Jira Simple Search
[Simple Search|http://confluence.atlassian.com/display/JIRA044/Searching+for+Issues] is based on dropdowns and edit controls. It's a structured search most similar to the current RS implementation
!jira-search-simple.png!

h2. Jira Advanced Search
[Advanced Search|http://confluence.atlassian.com/display/JIRA044/Advanced+Searching#AdvancedSearching-UsingAuto-complete] comprises free-text entry with auto-completion and online validation. It knows the query syntax and the editing context, so it can suggest thing (Jira: field name, RS: relation name); connective (and/or); values (thesaurus). Validates syntax at all time. See [this screencast|http://www.youtube.com/watch?v=Q3WfyUyQnHc]
!jira-search-autocomplete-character.png!

h2. Jira HP-Palm Search Plugin
[HP-Palm Search Plugin|https://plugins.atlassian.com/plugin/details/338080] constructs complex queries using drop-downs. The indentation reflects query structure. Here you see a complex grammar in action, searching through sub-object data. This will be very useful if we decide to search on properties of events (event being sub-object of MO), eg
"give me objects that were at Auction in Holland between 1600-1700"
!jira-hp-palm-search-complex-functions.png!