Sitewide Search

[jordanbyron]

No description provided.

[steveklabnik]

Is this being deployed on Heroku, or some other server you own?

[jordanbyron]

This is on our own server, not on heroku.

[steveklabnik]

Word. Was thinking about what kind of search would be most appropriate, that leaves it open to everything!

[jordanbyron]

Was thinking about what kind of search would be most appropriate, that leaves it open to everything!

😄 We've used the full text search functionality in postgres via texticle in University-Web. While that feature was only deployed a few weeks ago, it seems to get the job done with minimal setup costs.

Of course any other suggestions are always welcome

[seejee]

If this site were extremely high volume, I'd probably shy away from having the full-text search indexes live in the same data store as the rest of the application. Given the relatively low search volume that the site will probably generate, I think using postgres' built-in functionality is the simplest thing that will work.

Plus, migrating it away to something else in the future probably wouldn't be a huge task.

I vote postgres, especially since @jordanbyron already has experience with it.

[steveklabnik]

Agreed.

[seejee]

I'd like to take a crack at this one. I looked into the texticle gem, and it seems pretty straight-forward. Plus, I can always use university web as a reference.

As for the UI:

Would you rather see the search box directly embedded in the nav bar at the top of the page, or just have a simple link to a search page in the nav bar?

[jordanbyron]

It's all yours Chris.

Would you rather see the search box directly embedded in the nav bar at the top of the page, or just have a simple link to a search page in the nav bar?

Could you mock up both ideas so we could discuss the pros and cons of each? I find taking a screenshot of the page and using keynote works really well 😉

[seejee]

I haven't forgotten about this! I know community week is almost over, but this week turned into a scheduling train wreck for me. I'll add a UI mockup tonight, and then start working on the backend bits tonight.

[jordanbyron]

@geihsler no worries, the project isn't going anywhere! I can't wait to see what you've got in mind. I think this is going to be a killer feature and I can't wait to get it completed 😄

[seejee]

Here is the link to a google doc with the two different options. I think Option 1 is the better one just because it's fewer clicks.

Also, for the first iteration, I'm thinking about only searching for Updates. But, I'd like to hear any suggestions about how to represent the search results if we add Activities to the search as well. Do you think they should they go in a single list, or group the results by the record type?

I'm looking forward to feedback. :D

[jordanbyron]

@geihsler thanks for working up those mocks. Option 1 doesn't leave us a lot of room for expansion in the future. That mega search box will limit our growth. Option 2 solves part of that problem, but I don't like having a a lonely search box on an empty page. I've thrown together another option which, while a little hard to create, solves these problems.

After clicking the search icon

What do you think?

[seejee]

Wonderful solution. I'll work on it.