To include the search capability in Basie, there are a couple things that we need. The first is the search bar at the top of every page. It's convenient to be on any page and be able to search for something specific. That general search bar will search for the content over the entire site. There will also be the option of doing a general Google search. You can see an drop-down arrow where the user can select whether they want to search only in their Basie project or on Google instead. if they choose to do a Google search from that search bar, then a new tab or window should open with the Google results page.
The Search results from Basie will display the "Title" which will be any number of things depending on the result.
* Events - event name
* Mail - subject line
* Tickets - ticket title/one-liner description
* Wiki - title of the Wiki page
* Source - full file name including root directory (i.e. /root/trunk/file.py)
Next to the Title will be a percentage rating of how relevant the result is. The first item will always be 100%, and all subsequent results will be rated with respect to the first item. So if the first result gets 5 hits of the key words, and the next item gets 4, then the second result will display 80%.
Following the "Title" will be the context in which the search content appears.
Then on a new line, the link to the item as plain text.
In the advanced search, there are several more fields that the user can specify:
Show Items with...
* all of these words - makes sure all the words appear in the result
* this exact phrase - must appear exactly in the result
* any of these words - lets the user input words separated by 'OR'. You will notice that there is a second 'OR' after the second box. It is a button, that, once pressed, inserts two new input boxes directly below the current two input boxes.
* none of these words - will exclude any result that contain any of the words inputted here
Last Updated...
* within the last - this will let users specify how recent the search results must be based on the last time the item was modified or updated. List options would be "anytime"(default), "24 hours", "2 days", "week", "month", "year".
* before - this will let users specify how old the search results must be at least. List options would be "now"(default), "24 hours", "2 days", "week", "month", "year".
Languages...
* any language
* in the following languages - lets users specify what language the search results should be in.
Results...
* Display ## results per page - gives the user the abilitty to specify how many results they want to display on one page. Since we are using pagination, users may only want to see the first few or see them all on one page. It will be a drop-down menu with the following options: 5, 10, 20, all.
I thought it would be a good idea to allow users to specify the language since Basie supports multiple languages. It's likely that in a single project, there may be multiple language source files or e-mails. So this option may be useful if the user wants to search for only e-mails written in french.
4 comments:
Google search is a neat idea, but for student projects, not likely to be useful: most instructors will set permissions so that only authenticated users (i.e., not search robots) can see content, so Google won't be able to index it.
Question: does search look at the current project, all the projects I can view, or all the projects I'm an explicit member of, or...? Or is there a way to scope it for that? If it looks across projects, how do we rank/display results from different projects? Does the UI code do that, or does the underlying search engine take care of it?
Ican see where small student projects wouldn't use a google search while looking at their projects.
I clearly did not think about multiple projects. I'll look into that, talk to Kosta and put up a new post soon. =)
I think people might also want to search only within one content type - say I'm looking for a specific ticket, for instance.
Another thing to consider is which items will be ranked higher based on which fields contain the words. A ticket with the search term mentioned once in the title should pop up ahead of a ticket with the search term in the text. While a lot of that boils down to how they code the algorithm, if we can give some advice from the UX perspective it will help avoid a problem I noticed in DrProject, if I remember right: the title field in tickets was never indexed. oops. :-)
You said "Next to the Title will be a percentage rating of how relevant the result is. The first item will always be 100%, and all subsequent results will be rated with respect to the first item."
I think that might be over-specifying it a little too much. If I search for "foo", and "foo" doesn't appear in any pages, or appears really sparsely in a lot of pages, then having low relevancy ratings is a useful bit of information that we will have lost. (Assuming we have it in the first place. If we end up using an algorithm that's fast, but doesn't give a percentage-relevancy, then we can't really do this feature at all.)
In the advanced search, can we specify terms in all of the fields, or only one of {all of these words, this exact phrase, any of these words, none of these words}?
And is "all of these words" the default for non-advanced searches?
Will there be short cuts, i.e.:
all of these words "and this exact phrase" -but -not -these -words?
Post a Comment