Search Interface

Version 117.1 by Ecaterina Valica on 2009/03/09 13:56
Warning: For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [incubator:Mockups.Search Interface]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

Search Interface Improvements

Requirements: http: dev.xwiki.org/xwiki/bin/view/Design/NewSearchInterface#requirements
Analysis: http: incubator.myxwiki.org/xwiki/bin/view/Mockups/Search+Interface#analysis
Mockups: http: incubator.myxwiki.org/xwiki/bin/view/Mockups/Search+Interface#mockups
Proposal: http: incubator.myxwiki.org/xwiki/bin/view/Mockups/Search+Interface#proposal

0. Requirements 

The aim of this proposal is to suggest and implement an overhaul to the current XWiki search interface.

Search in XWiki has the following components:

  • Search panel
  • Search page (query field only)
  • Search page (with results displayed)

Search results currently use the default XWiki.Results template. This template uses a table to display results. It's not very user friendly. It has gained negative feedback from some of our customers (Aelia) that do not deem it user friendly enough. Users from the company were expecting results to be be more google-like (unsurprisingly).

1.Aims

This project will be considered a success if the 3 following criteria are met:

  • Cati starts feeling comfortable about XWiki development at the end of the project
  • The project is completed in a relatively short timeframe (4 to 6 weeks)
  • Users can find relevant results faster than with the current interface
2.Users

Users have 3 main ways to end up on any given wiki page:

  • Browsing (through the index or one of the menus)
  • Referral (from another website or a wiki page)
  • Search

Users resort to search when:

  • They're not quite sure what they're looking for
  • They know what they're looking for but cannot access it through navigation (ex: no menu pointing to the page)

The aim of the search experience is to let users access the content they're looking for as fast as possible. Overall speed is the leading criteria (from the moment the user starts looking for the search box to the moment he can read the content he was looking for).

We're targetting users that have a working knowledge of the internet (used to browse google, news site, online shops) but do not have a technical background (people from marketing, sales, HR, accounting...).

3. Food for thought

1. Options

  • Quick Search (Look at the "Quick Find" panel at the top left on the intranet for an example)
  • Google-like search results
  • Table search results
  • Simple + Advanced search ?
  • Filters
  • We'll probably try to integrate [http://www.compass-project.org/>http://www.compass-project.org/] underneath to generate better Lucene search results
    • "Compass simplifies common usage patterns of Lucene such as google-style search"
    • We might be able to get results in context (search term highlighted + surrounding content) using Compass -> keep it in mind in the proposal
  • Other

2.Stuff to keep in mind

Here's a list of XWiki-specific items that may need to be taken into account while rebuilding the search:

  • Spaces / Wikis
  • Attachments
  • Access rights => some users may not be allowed to see some documents
  • Page names vs page titles
  • Page versioning
  • Applications (XObjects)
  • Lucene scoring
  • Ratings
  • Comments
4. Process
  • Create a JIRA issue describing the task in the relevant JIRA project
  • Assess XWiki Enterprise's current search implementation
  • Understand its shortcomings compared with user expectations
  • Suggest one or more potential interface designs to improve it
  • Propose and discuss this interface on the devs@xwiki.org list to get feedback
  • Update the proposal with feedback from the list
  • Once the debate seems to be coming to an end, send a \[Vote\] email
  • Implement the selected search interface
    • Clean the velocity code
    • Clean the HTML code
    • Write cross-browser CSS (make sure it works in IE6)
      • Keep in mind that this CSS needs to be easy to modify for cutomer projects
      • If possible, use a skin extension to store the CSS code
    • If javascript is needed, make it cross-browser and store its code in a JS Extenstion
  • Get the code reviewed by a XWiki developer (JV, Anca, Raluca, Oana, Jérôme or Sergiu)
  • Integrate their feedback and make sure to follow XWiki Applications development best practices
  • Export the XWiki document as an XML file. Clean it (author, version)
  • Provide the resulting file as a patch attached to the JIRA issue
  • Beg for a developer to apply it
  • Go out and party ;-)

1. Analysis: Look of the current implementation 

XWiki-Main-LuceneSearch1235994036615.png

Aims

The aim of the new design is to provide a more fast way for the user to find the page he is looking for. This can be done if the scanning through context is done as fast as possible.  
The search page is for every user (starting with readers through admins), so the page should not be perceived different than a standard website (the concept of space and wiki should be transparent).

Standardization

- Search Results: I need to know how many types of Search XWiki has in their product (XWatch has a different type of search because there are feed entries) so the searches can have a common UI (same ).
- Pagination (up and down): for all the places pagination appears, we can use the same format. Examples of pagination. More patterns.
  See also:
        - http://code.xwiki.org/xwiki/bin/view/Macros/PagedViewLinksMacro
        - http://code.xwiki.org/xwiki/bin/view/Snippets/PaginateSearchSnippet

Types of results

"Quick Search"  should be integrated as a prestep operation.

  1. Table search results (the current version - with filters and column scanning - good for sorting if I can't find the page in one go (require 2 steps - refining) )
  2. "Google-like search results" => Instead of tables show the results as a list of items (that have characteristics like Title, Author, Date, Description (for the "surrounding content") ) See I Solution
  3. Extended "Tree" view - per groups See II Solution

Problems

In the current version of the interface we have the following:

- we don't have the word we are looking highlighted (in bold for example) so that the user can faster visually scan;
- the Filter function is in gray - looking liked a disabled feature;
+ it's a bit too cluttered. I have to many information showed and I don't know where to look first, there is no part highlighted (all elements have the same importance - look the same)
- the most relevant piece of information is where? the title? why it exist pages that don't have a page title?
- the searching is done within what? (page titles, content, tags, authors, etc)
- why the page title is "Lucene Search" - who is Lucene? Why do I care as a user?
- is there the possibility to have 100% Lucene score?
- align "query" input in left side - for better readability (momentarily is in the center)
- do we need to keep the word searched in the "Search Panel"?
- do we need to know how many versions the page has?
- do we need to know how many translations the page has?
- keep in mind if you want to integrate user rating for the page.
- the filter within a pagination filters only the displayed results, not all the results. If I want to see all pages modified by me I have to go on all pagination pages and apply the author filter;
- to take in consideration  differences between instances that have multiple wikis;
- remove for the Search page the "Attachments" and "Comment" part + "Last Modified by" - it is not necessary for a search page (removing clutter);
- integrate Silk icons, if needed, in search results

I Solution

1. Options for search (also advanced search)

Lucene has a very nice set of operators that can be used in advanced search to instruct user about search capabilities http://code.xwiki.org/xwiki/bin/view/Applications/SearchApplicationLuceneSearchQueryHelp

2. Results list

2.1 What is the relevance of displaying the "Page Name" and "Page Title"?

- page name is used internally for xwiki to name pages, do I need to know the "Page Name"?
- wiki and space are used for organizational purpose, this might be helpful.

Example

A) So, for the query:
XWiki-Main-LuceneSearch1236000549609.png

B) I want the result:

XWiki-Main-LuceneSearch1236000756135.png

C) The URL for my page is: http://watch.xwiki.org/xwiki/bin/view/Design/NewUIProposal

D) The desired page has a breadcrumb like this:
XWiki-Design-NewUIProposal1236000618643.png

E) so the correct full breadcrumb for my desired page is: Watch > Design > XWatch User Interface Proposal for http://watch.xwiki.org/xwiki/bin/view/Design/NewUIProposal

So we should display primary the "Page Title" and "Page Name" should be only in the URL.
We can have breadcrumbs for the wiki and the space.

Because of the way URL is constructed the wiki should be first in the query and then the space (you could put this also as pre options for the search).

I would like to have results in this way (list style):
- relevance (score) - invisible - is the order the items appear in the list;
- Page Title [link] (most important) (replace "Page Title" with "Page Name" if "Page Title" doesn't exist)
- Location: Wiki [link] > Space [link] (> Page Name [link] [? - necessary?])
- Author: Author [link] - Date

If we gonna follow this pattern (of breadcrumbs) - then the tale order and query field must be Wiki - Space, not Space - Wiki.

Questions about list view:

  • do I need the date to be in the format "2008 Aug 26 at 15:55"? Year is the least changing element and it is in the first place. Do I need to know the time? (I'm doing a search) - Eliminate the clutter ad let only "26 Aug 2008";
  • it is mentioned that the user name signifies the "Last Author". What "Date" signifies? "Creation Date"? "Last Modified Date"?
  • the date is the only field not clickable;
  • would it be usefull for me to know if the page I'm looking for has comments? or attachments? I need to know only the existence of them or also how many of them are?
  • i could display also what types of attachments the page has: images, pdf, doc
  • attachments and comments could be options from the search options
  • do I need to know if I have access rights for the pages I'm looking for?
  • Last Author - display username or full name?

2.2 Author and date are used for a more advanced search - when you know more details about the page you're looking for.

II Solution

Display result pages in Groups that represent the Space (Wiki) of origin.
You can make a group that contain only "My Pages" and you serve this group in front line for the user. But these can be replaced with an option "Search only my pages" and also you can put the view with "My pages"on the user profile

1. Results list

Type: {Wiki [Space (article, article, article) , Space (article)] , Wiki [Space (article) ]} - like a SiteMap type of result list.

Results:
Wiki
    Space
            article 1 ...
            article 2 ...
            article 3 ...

    Space
            article 4 ...

Wiki
    Space
            article 5 ...

Based on the idea that Lucene Score can predict what a user is looking for and within what Wiki, Space the more pages have a higher score - show that pages.

Serving results organized in groups gives a nice perspective of the page location.

Another group that could be added in front of all the results could be a search did in user's pages. This kind of feature could be removed if this part (of user pages) can be found in "User Profile".

Results:
    Results in user pages
    Other results

2. Mockups 

delete Not Selected by me
add Selected by me

Search bar

The nice thing about the initial version was that the Pre filtering of the results by selecting your wiki and space.

delete Version 1

...
Very nice visual grouping. Actually my favourite. Good for tiny spaces to make the selection wich is not the case.
The filters could be in the Advanced section.

delete Version 2

....
Keeping the existing layout, but inversing Space selector with Wiki selector, to keep the breadcrumbs arrangement.
The filters could be in the Options/Advanced section.

delete Version 3

....
This version is the Version 1 combined with Help Information. This way the width is increased.
Very nice if there were a function separation: a group for search, one for filters, etc every one with their indications.

delete Advanced Search

The advanced section is good if we like to add things like:

  • User select the level of details for the results (Location, Modified, Contains, Surrounding content, Page Rating, Page Versions, Translations)
  • User select the number of results per page
  • Integrate Filters
  • Integrate Lucene advanced search options (AND, OR, NOT, test*, te?t,)

Results List

delete Version 1

Show only minimal informations and display more when the user Hovers one result item.

resultList1.png


The way Highlighted items would look like.
resultList1High.png

add Version 2

Results displayed integrated in the search page.
Score field replaced with Relevance, also replacing Stars form Rating Page with Square rating.
Table Sorting replaced with one way sorting for fields like Relevance, Date, Page Name, LastAuthor.

resultList2.png

The way  a highlighted result looks like.
resultList2High.png

Table fields are grouped (Space with WIki); (Author with Date); (Comments with Attachements). The level of details can be extended (unlike the table view) with the informations like Page Versions, Translations, Page ratings, Surrounding content. The level could be selected by user in his Preferences.

Integration

delete Version 1

integrated1.png

3. Nice ToDo's

  • Highlighted search words in result list
  • Integrate standard XWiki pagination
  • Sorting DESC, ASC
  • Display Recent Pages, My Pages 
  • When you search from a wiki or a page - complete the specific query fields with the curent wiki, space - keep search context

4. Proposal  (for high quality see search.svg)

General View

Proposal.png

Integrated in Toucan Skin (layout)

integration.png

Scalable for only one wiki

onlyspace.png

Scalable if more details needed for result item

details.png