saurabhd / hk_realestate

GNU General Public License v2.0
1 stars 0 forks source link

Make chosen search term persistent when displaying the result #7

Closed arpita-addweb closed 8 years ago

arpita-addweb commented 8 years ago

Site area : frontpage / search views (/buy, /buy/freehold-apartments, /buy/capital-investment, /buy/commercial-property-sale) Priority : medium

Description : When you select a value in the search (e.g. Wedding in Borough), once the search is loaded, the select value is reset to the Title (Borough), instead of showing the selected value (Wedding). The search is based on search_api with search_api_solr, search_api_facetapi, facetapi_bonus, search_api_ranges, and the chosen library for styling.

darshi-shah commented 8 years ago

Hi ,

"Borough" and "Category" are only two search criteria in which values are not persistent. These two fields in particular use select list while others use ranges for search. We can use this module : https://www.drupal.org/project/facetapi_multiselect but that will change the design of the search filters. Please see

1 - http://i.share.pho.to/77a79881_o.png 2 - http://i.share.pho.to/be71ea9b_o.png

Same goes for search on homepage. Let me know your inputs on this.

Thanks

heliogabal commented 8 years ago

It's a nice solution which adds additional value by being able to multiselect, but the client wonders rightly so what happens if the selected values are longer than "Moabit"? There will be "Bezugsfreie Wohnungen" and "Vermietete Wohnungen" fo example, or "Oberschöneweide" and "Prenzlauer Berg". Then you would probably not see all selected values, given the select field has a restricted size. Would you be able to scroll inside the field? So as log as it is still possible to see all selected values in a way, please implement it.

darshi-shah commented 8 years ago

Hi Rainer,

When we have more than one value in these filters and width cannot accommodate it, height increases. Please see this : http://i.share.pho.to/bbe0372d_o.png

Scroll inside these two fields will be possible. This will change the look of search filters. We are planning to keep enough height for these two filters so that they can have three lines in it and anymore will add scroll.

This will also change the look of search on homepage. We will have to increase the width.

I will let you know once done.

Thanks

heliogabal commented 8 years ago

Hi Darshi,

Ok, that sounds good. So initially, the filter will look the same (one line) as the others, but if more than one item is selected, it will increase in size, but only up to three lines, then there is scrolling? Why would this increase the width on the frontpage?

And what about the Submit button? Right now, the submit button is hidden and the form is sent as soon as there is a choice. Would that be the same with you solution?

Thanks fo clarifying this.

darshi-shah commented 8 years ago

Hi Rainer,

Yes, it would be initially one line and then increases size upto 3 lines and then we have scroll.

Width will increase on homepage because we are planning to keep dynamic height filters on one side and rest on other side along with search. Please let me know if this is okay.

Search will be hidden and form behavior will be same as what it is now.

Thanks

darshi-shah commented 8 years ago

Hi Rainer,

We are facing some issues in search button. Auto-submit as soon as filter is changed is not working for these two fields. We are removing the submit button and placing a search icon inside these fields. users will have to click on this search icon to make search work for this two fields. For rest of the fields, auto submit is working fine.

Let us know if you have alternative to this.

Thanks

heliogabal commented 8 years ago

Hi Darshi,

I'm not sure this is the best solution. It introduces inconsistency into the interface, which is confusing for users. So maybe it would be more feasible to place a search icon in all the fields?

The initial draft had a search button, but we figured that this might lead to lots of combinations in the search that don't provide a result (if you combine a borough with a price range that doesn't exist in this borough for example), which would even be a worse UX. That's why I introduced the auto submit in the first place, so once a value is selected, the other fields only show included values. So if it is possible, probably a search button with every field would be preferable to one for the whole search. Would the search that is carried out mean a whole page load, or is this working with AJAX?

darshi-shah commented 8 years ago

Hi Rainer,

Please following steps :

1 - take pull

2 - enable facet multiselect module (This module is patched from https://www.drupal.org/node/1806344).

3 - goto admin/config/search/facetapi/search_api%40solr_node_index/block/field_bezirk/edit and select "multiselect" in display widget and select "auto submit" and "count"

4 - goto admin/config/search/facetapi/search_api%40solr_node_index/block/field_kategorie/edit and select "multiselect" in display widget select "auto submit" and "count"

5 - clear cache

Autosubmit is working for "Borough" and "Category".

Thanks

heliogabal commented 8 years ago

Hi Darshi, thanks, I got it to work with your instructions. The select still needs some styling, I think:

border: 2px solid $greyer;
border-radius: 4px;

and border-color when active should be $primary instead of blue.

Then, if the select grows bigger than one line, it should take up space and push everything else down. If that is done, I think we're good.

darshi-shah commented 8 years ago

Hi Rainer,

can we please close this ?

Thanks

heliogabal commented 8 years ago

Hi Darshi,

yes, we can. I adjusted the font-family, size and height just now, so please also pull my latest push, but then this is done. Thank you! Nice work on this one, love that you found a way to use autosubmit in the end!