Ticket #9271 (closed PLIP: duplicate)
Improving the search results page
Reported by: | laurenskling | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Unknown | Version: | |
Keywords: | search, listings | Cc: | plip-advisories@… |
Description
MOTIVATION
“Search-dominant” navigating is one of the three popular ways to reach goals on a website. Search isn't just useful for finding content, it's how many people navigate. The search of Plone could do better to help these people. Here are some small adjustments that could help out big time. (this PLIP is only about normal search, not advanced or live search).
PROPOSAL
- Location (path/URL)
One of the main things the search results are missing is the location of the item. If you archive old items in folders called 'archive', try searching that one archive folder you are looking for. Adding the location (URL) gives users feed forward about the item.
- Relevance.
I have never understood the relevance of showing the relevance. At the Sorrento European Plone Symposium we have some mixed feelings about this, so I am interested in your opinion.
- Search only in current section.
Plone gives the opportunity to search within current section, which sadly is gone on the new plone.org. When checked, the resultpage doesn't give any feedback that the results are only from the certain section. It also doesn't give the opportunity to search again within this section. Adding a simple line states “searched in <section>” and a checkbox to search within it again could solve this.
- Sorting.
The search results can't be sorted in any way at the moment. People like to sort their results on for example date/name/location.
- Webmaster: cut/copy/paste actions.
If a webmaster searches for content, it would be useful to have options like cut/copy/paste from this list, so bulk copying items becomes easy.
- Controlpanel settings.
All these search settings should be configurable in the Plone control panel.
IMPLEMENTATION
Small adjustments, so it is nothing spectacular if you ask me.
RISKS
Search should stay as easy as possible. Adding checkboxes to (normal) search makes it bigger then “just type and press enter”. If the the checkbox is unchecked by default this is still a simple searchbar, so I do not see any problems. Sorting search results will make the page need adjustments, there has to come a good UI for it.
Change History
comment:2 Changed 7 years ago by pupq
Students are often VERY pleasantly surprised when they learn it's not hard to make search pages that let you search by location. Making this more discoverable would be a big win--it's a feature our search has that some of our competition doesn't, and it's very useful for many people.
comment:3 Changed 7 years ago by erikrose
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:7 Changed 7 years ago by davisagli
FWT vote: +1 assuming this is merged into #9282 and a single set of review branches is submitted.
The bulk cut/copy/paste actions seem like the biggest departure from the existing search results UI. I'm not sure we should tackle that without thinking through how we'd like a full-featured bulk editing interface to work in the long term.
comment:8 Changed 7 years ago by raphael
FWT vote: +1 assuming this is merged with the related PLIPs
And I'd stay clear of bulk editing here - that's a completely different story IMHO
comment:9 Changed 7 years ago by calvinhp
FWT Vote: +1 but I would like to understand the issue with relevance in the results better. Seems like it still a potentially good area to sort on if the full text search provides good numbers for relevance.
comment:10 Changed 7 years ago by esteele
Approved by FWT vote (pending merge).
comment:11 Changed 7 years ago by alecm
- Status changed from new to closed
- Resolution set to duplicate
Closing as this has been superseded by #9352
This is very similar to #9282 which is a bit more detailed, but less ambitious.