Search form

Minnesota Search Sprint: Your top-five feature requests

Posted on Wed, May 07, 2008 by Robert Douglass

In the same way that the Internet itself would not have achieved greatness without the ability to search it easily and efficiently, Drupal's greatness will always be tied directly to the effectiveness of its core search solution. Improving core search for Drupal 7 will be no small task, however. The current implementation is both elegant but complex, robust yet inflexible. The seven coders participating in the Minnesota Search Sprint this weekend have a great challenge as well as a great opportunity. Here are some of the things we hope to achieve:

- Identify the most important weaknesses in Drupal search and create a project plan for fixing them.
- Identify the most important new features currently missing from Drupal search and clear the roadblocks for implementing them.
- Increase the test coverage for Drupal search.
- Increase general developer awareness and knowledge of search.

A large part of what we will be doing is evaluating and planning. Without a roadmap and common understanding of what search is to become, little progress will be made in the Drupal 7 development cycle. However, a coding sprint is all about code, and we'll be writing some of that, too. Specifically I'm hoping that we'll be able to fix one of the top-five bugs, increase search module's test coverage, and come up with a first attempt at one of the top-five new features.

That's a lot! No matter what we manage to code during the three days together, we'll walk away with a high level of agreement about our goals for the next months, and plenty of homework to do.

We'll post regular updates that you can follow on Planet Drupal, as well as in the search group, and we're all ears if you have suggestions or wishes. For anyone wanting to catch up on their search related reading, here are some links:

Just so we don't miss anything, what are the features or capabilities that _you_ miss the most in Drupal search? What do you think needs the most improvement? What do your customers ask for in search improvements?

For purposes of exposing externally what you and I have discussed
internally, here's my list.

Here they are; I'm happy to put them on the site if you think it's
the right thing.

Faceted search capabilities, where setting up
the faceted search is as easy as using Views. I'd like to (at least)
be able to have core capabilities for setting up facets to select
among:

Node types (blogs, page, other user-created content
types)

Date created

Date last modified

Author

Search terms (e.g. turn off / on search terms that I originally
specified in my search query)

Other CCK-defined fields

Results should be viewable via Javascript interface,
vs. page-oriented. My goal is to have something like the
search results page you get when you search for flights at http://www.kayak.com . Of course, the
built-in Drupal interface may need to be page-oriented, like
today's search results, because not all users like the javascript
style and because we need graceful degradation for
non-Javascript-capable viewing devices. But the Javascript-style
results require that the search results be rendered in ways besides
HTML output (e.g. the web services approach). So Search changes need
to walk hand-in-hand with the web services thinking going on in the
Drupal project. (By "web services" I mean exposing Drupal's own
capabilities via some sort of web service interface (vs. Drupal
consuming web services from other sources. The Drupal
project really needs a better name for the "web services" I'm
referring to here.)

Speed. Google has spoiled us all.

Immediate searchability. Today, we have to wait
for cron to re-index; it would be better if a node could be indexed
when it is saved. Of course, this raises the question of what happens
when a page is _modified_, given the way indexes are built. But
having something be immediately searchable is better than waiting for
cron, so the goal is the same, even though it may be hard.

Search-driven content display. Today, we think
of search as a box we go to when our "manual" attempt to locate
desired content fails. Search should instead be integrated into basic
page contents, something like the "similar content" or "You may also
be interested in..." type stuff works today, but we ought to be
thinking how we could take that to a whole better level. This is the
whole "Search and CMS vendors don't understand what the potential for
the other is" stuff you and I talked about a year ago.

I have to agree with Moshe on this one, lighting fast search. The
customer pain this is solving is clearly the need to integrate search
across multiple systems, as well as provide more advanced capabilities
than what Drupal provides out of box. So something good, solid and
tested, and rocking fast is the key.