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+SearchBar/expanded.png. 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+SearchBar/quicksearch1.png. 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
