Hi,
First of all I would like to point again to
the example:
http://incubator.myxwiki.org/xwiki/bin/view/Main/ListWebSearch
and proposal pages:
http://dev.xwiki.org/xwiki/bin/view/Design/NewSearchInterface
I think the new search results page (the main search
one not the
lucene one) has some limitations that could be
improved:
- it doesn't scale with large number of documents (if you do a search
that returns a lot of documents)
The proposed search, just as the LiveTable has pagination.
- it
doesn't allow refining your search easily
This will be done with Advanced Search, which is currently not implemented
yet. See
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/SearchProposal+Sear….
The content of the advanced is just for demonstration, those will not
be
the final options.
You also will have the Relevance in your right which will be the default
sorting criteria. So you will not need to go thought pagination and
hopefully find what you look for in the first screen (with a well
implemented Lucene search).
Also you can filter in one step by Date, Rating, Popularity (nr of
comments).
Also the proposal suggested a Quick Search in the Search field
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/SearchProposal+Sear….
All this are mechanisms that will help the user find his page without
needing to browse to large number of documents and through the pagination.
- the information presented take up more vertical space than needed
(currently 3
lines instead of one) and thus less results can be
presented
The old interface was very cluttered and occupied many columns instead of
lines. One big problem of it was the scalability of informations to be
displayed, like number of comments, rating, relevance, author, date,
attachments, page type, etc. There is no way you could display all this
information using horizontal columns.
The results in the example
http://incubator.myxwiki.org/xwiki/bin/view/Main/ListWebSearch actually is
occupying 5 lines, with the final line compressing 3 fields of information.
The search you are talking about (the one with 3 lines) is not the final
version of the proposal. Currently we don't have implemented the display of
the context where the search word is located. When this will be available,
the layout will expand in horizontal, but the scanability will be still
great.
In the Live Table case you need to scan horizontally and vertically to find
what you are looking for. But the purpose of LiveTable is not search, but to
compress large quantity of information.
Keeping the current proposal for the Search, user will need to scan only
vertically, finding more fast the information they were looking for.
"thus less results can be presented" - the purpose of search is not the
amount of data that is displayed, but the quality and relevance of it,
because:
Most of the time, people click on one of the top 3
search results they get on a page. This means they do
not scroll much.
I agree with G:
2 things really matter:
- Each result has to encapsulate enough of the right information to let
the user know whether the result matches his/her expectations
- Each result be clearly identifiable and separated from the others
This was not the case with the previous table-based interface. A table
makes
it harder to identify the different results. The current view improves
contrast by turning each result in an easily scannable nugget of
information.
The "vertical space" argument assumes that
the search will return a lot of
results that the user will scroll through. The best way to answer it is to
provide more relevant results on top to avoid the need of scrolling
altogether.
- it could be reused by other pages which require
listing documents
such as the SpaceIndex which lists all pages in a
given space. It's
actually currently reused but as a consequence the SpaceIndex page
isn't nice at all and doesn't scale.
In my opinion the SpaceIndex that reuse the structure is not style at all.
It doesn't at least have space between entries. So I don't think is a good
example, for which to judge the Search layout.
- The user expectation when arriving on a search page
is that no results
should be present when no query has been entered rather than the other
way
round
display all
docs by default when you arrive on the search page (ie
no filter set)
or display the last search user did :P
I also agree with:
This would solve the issues Vincent listed above:
- Scalability (the lucene search is paginated)
- Relevance (lucene search puts most relevant results up first)
Plus it matches current users' expectations when it comes to search.
Let met be clear: I'm all for experimenting with new, nicer, more
powerful way to interact with data and filter it and I'm a livetable
fan. However, I don't think it's the best choice for our default
search interface right now and
I think we've got other search-related issues to fix first before working
in
that direction.
Guillaume
Caty