Search: clean up code, api + unified search UI [#14917]

Some discussion with Moshe a while ago gave me some more ideas for search, so here's a patch.

1) The different types of search, which used to be radio button options in the search form, are now subtabs of "search" (default "search/node"). This seems better from a UI point of view, but also has another advantage: modules which implement a custom search form (flexinode, project) can add it as a subtab of search. This means that all search forms will be located in the same place, and also without needing an extra api call to search.module.

2) The current code was a bit hackish, as the indexing of comments along with nodes was hardcoded in node.module. Instead, I created a nodeapi operation "update index" which allows modules to add more data for a node that is being indexed. Comments are now indexed using this mechanism and from comment.module, which is a lot cleaner.

3) The search results format was also hardcoded to include "N comments". I replaced this with a nodeapi operation "search result" and moved the comment code to comment.module where it belongs. This op is quite useful, as for example I also modified upload.module to add "N attachments" to a search result if any are present.

Comment	File	Size	Author
	search.cleanup.patch	8.1 KB	Steven

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Steven CreditAttribution: Steven commented 29 December 2004 at 23:11

Forgot to mention this... what prompted this patch was the idea for a module which would allow text attachments to be indexed along with the node. Thanks to this patch, upload.module could be modified to do so, or it could be written as an extra module.

Comment #2

Steven CreditAttribution: Steven commented 29 December 2004 at 23:15

You could even run pdf attachments through a pdf2html convertor and index them ;).

Comment #3

Dries CreditAttribution: Dries commented 30 December 2004 at 12:27

It looks good but does not conform with the 'tabs must be actions' paradigm.

The page's title 'search for' is somewhat peculiar too. Normally, that would have been 'search'.

Comment #4

Steven CreditAttribution: Steven commented 30 December 2004 at 16:12

I'm still not 100% convinced on the "tabs must be actions" system. For example, both /project and /project/releases violate this rule, yet they are very usable. In fact, I've talked with Kj before to unify these two pages with taxonomy tabs + version subtabs so people can easily find what they are looking for.

If we look at the common usage of tabs in traditional UIs, I can think of several uses:

1) To split up a task in categories. Examples include project's pages, where you can switch between versions and/or type of projects. I can think of similar things in for example my CD burning program, which lets me choose between data CDs, music CDs, photo CDs, in this fashion.

2) To provide different views on an item. For example in an HTML editor, to switch between HTML code and WYSIWYG. In fact, I believe the Drupal node pages match this as well: a node's "view" and "edit" tabs correspond to a read-only and read/write version of the node, in a way.

3) To split up a task or view into pieces as to unclutter the UI. This is what Chris Messina has been doing in his node creation form mockups (although those would be javascript tabs). We already have a similar usage for profile fields, where people have in fact gotten confused that they cannot switch between the (sub)tabs to the different sections of account information, without having to submit the form every time. In other words, people do not see the tabs there as "tasks" at all, but simply part of one page.

The whole "tabs must be local tasks" idea has worked so far because we have mostly restricted their usage to the administration section. However, usually they correspond to either #1 or #2. In the admin section, an admin will probably be performing specific tasks. This is unlike a regular visitor who is probably mostly browsing and has different UI needs.

I feel the rule is too restricting when we apply it to the entire Drupal UI and furthermore I don't think it is even a guarantee for a usable, consistent UI. Consistency is about expectations, not following the rules 100%. The most usable applications are those that bend the traditional UI rules a bit for their specific purposes. For example, if you're using a tabbed browser, you're looking at a giant UI inconsistency: the address bar is specific to each tab, yet it is located outside of the tab control. No-one seems to care, in fact, positioning the tabs close to the page means less mouse travel time.

Similarly, the "admin -> users -> configure -> permissions" page seems located in a place consistent with the "local tasks" idea, but IMO it's buried too deep, and unusuable, because most people do not associate permissions as something they 'do' to users.

In any case, I don't think my patch even violates the "local tasks" idea, except maybe from a language point of view (the tab names are not verbs). The verb is implicit in each of the tabs, hence the title "search for" and not "search" (the tab title completes the page title: "search for content" "search for users"). Each tab specifies a different search task. Many OS-integrated search tools also start off by asking "what do you want to search for?". My patch does the same, except we don't annoy users who just want to search for content (most common use case) with a forced click.

And from a language point of view, there are situations where a verb is a lot more ambiguous than a noun (which would then have the verb "view" implicitly associated with it).

One example that springs to mind is the "track" tab for tracker.module and statistics.module. "Track" is a word with many meanings (to follow, a trail, song, ...). The word "history" would IMO be a lot better there, but it violates the verb-rule (although you could imagine it to be "(view) history"). In the CD burning example above, the tabs have the implicit idea of: "Burn a ...." in them.

Comment #5

moshe weitzman CreditAttribution: moshe weitzman commented 31 December 2004 at 02:31

I like this cleanup patch a lot. If accepted, I volunteer to write the module which helps uploads get indexed.

I agree with Steven on the 'appropriate use of tabs' debate. The 'track' tab on the use profile page is a good example of us forcing a verb where a noun makes more sense. i think 'posts' would be the most descriptive title there.

Comment #6

Abalieno CreditAttribution: Abalieno commented 31 December 2004 at 04:06

Can I add my point of view?

A perfect search page should have various sections:

1- First the field where you can type the strings
2- Checkboxes about the parts of the site (nodes, forum, comments etc..)
3- A box similar to the taxonomy navigator module where you can select multiple categories and narrow the search
4- Another field where you can refine the search by date

Comment #7

Dries CreditAttribution: Dries commented 31 December 2004 at 09:30

Committed to HEAD. Thanks. We'll judge tabs on a case-by-case basis.

Comment #8

Bèr Kessels CreditAttribution: Bèr Kessels commented 2 January 2005 at 15:23

My first reaction was: OMG, tabs are becoming too prominent. Lest assume tabs are ugly (in lots of cases, like sites with horizontal navigation they are). With patches like these I cannot hide tabs for average users anymore. Up to now, you could hide them for all users, but admins.

That said (its a complete different discussion, in fact) I think its not a very useable solutions. Users should never be prompted with questions they can only answer if they have insiders knowledge. Especially the search should never assume users to have knowledge about the content they are searching (for).

If i search for, lets say, "tax submission form" I should not have to know if that form was added as PDF, HTML, or even as outbound link. All i wnat is a result containing that form. This is Googles success, since it uses the KISS principle.

I plead for adding a singe tab: Adcvanced search, Your proposed tabs coud be subtabs of that "advanced searchtab or link", but ideally would be put in one UI.

Bèr

Comment #9

Steven CreditAttribution: Steven commented 2 January 2005 at 15:56

I don't see why you should want to hide tabs from users. Also, the default search is enough for most people, so they don't have to worry too much.

However, I don't see your problem. It is not possible to have one general search form, which allows people to find everything easily. Project issues require a dedicated interface and search from. And flexinodes and events can benefit from that too. I don't see the problem here: we're NOT asking the user "what node type are you looking for?" but "what item are you looking for?". The possible answers are: "generic content", "project issues", "users", "events", ...

Look at it this way: these specific search forms already exist in the relevant modules, so obviously some people think they should be there. Each has a custom form, so I decided that tabs was the best way to unify them. The user can now find all search forms on one page. The old method (radio buttons) would require a form refresh after choosing the type, which wouldn't be user friendly.

Even Google has "web" "images" "discussiongroups" "guide" plus variations like Froogle.