On 11/22/12, Gary Martin <[email protected]> wrote: > On 23/11/12 00:34, Olemis Lang wrote: >> Good answer , indeed ! >> :) >> >> On 11/22/12, Andrej Golcov <[email protected]> wrote: [...] >>>> what is the reason for using tables and columns to display search >>>> results >>> ? >>> The idea is that we combine free-text search and query. If we want to >>> provide readable query result it can be possible to represent it as >>> table. It is aslo consistent to existing TracQuery result view. >>> >> I asked mainly because I've been taking a look at several search UX >> solutions for mobiles and it turns out that they all have no more than >> 3 columns ... and when they have the third one it's most of the time a >> checkbox , download indicator , ... i.e. something tiny . > > Well, this is a problem that we would have to overcome for ticket > queries anyway. >
Maybe , yes , if we take a straight look at it . However it seems to me that ticket queries serve to a different purpose than free text search . In that case it is also important to make results look somehow like users want to . With mobile devices it is still possible to e.g. hide columns ... until everything fits . That's not the goal of free text search . [...] >> For the debate : What about having a single column (e.g. to the right) >> for any kinds of search results metadata displayed in the form of >> clickable metadata [1]_ and stack it under summary + full text hit >> snippets for tablets & smartphones ? >> >> OTOH , regarding meta-data , it'd be nice to have some other tags >> attached to search results in a way similar to what is displayed for >> Hadoop Common when performing this search >> >> https://www.google.com/search?client=opera&rls=en&q=jira+apache&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest > > I guess that there are a number of possible solutions for display. Are > any of these an approach that you would be advocating for the current > ticket queries and reports? Like I mentioned before , even if queries and reports are yet another kind of search engine , there is a difference between them and free text search . For instance , reports and queries have some focus on presentation , hence visible columns may be selected to satisfy some information needs . Nonetheless in free text search findability is the main goal over everything else . That's why the first point mentioned above does not apply . The second suggestion I made seems more appropriate for products , milestones , ... but in the case of tickets , for instance they may be annotated (in a similar way to Google search results I mentioned above) with # of comments , # of attachments , ... each pointing to the specific section within ticket view . To make myself clear , IMO none of them is suitable for query or reports web UI , because that serves to slightly different purpose . -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
