Our checklist for filters on sites
Quite often on e-commerce sites we are asked to implement filters. A good filter is a rather expensive toy. In general, they are not always appropriate - the user is easier to look at the list with his eyes than to understand the logic of the filter developer. Of course, if there are not many elements in this list. Let's say no more than 200 in each section. Below in the form of a checklist for our QA, I have fixed some requirements that we are aggressively implementing on our projects from this year. Standardization, EPT.
These requirements are reasonable. Some of them are difficult to implement. The part is obvious. Part depends on the context. But in general, they are quite versatile. If there are any questions on specific points - we wish in the comment.
[] If the filter is not applied - the browser address bar contains the CNC with no additional parameters.
')
[] When first entering a category page in a url, there should be no “questions”.
You need to go to the directory or category page and make sure that the CNC is used.
Example: Zimzum .
[] When switching to a product from the catalog - the link “back” in the browser should work correctly and restore the parameters.
Example: Zolotoy-telets .
Why so: If the user chose something in the filter, received a selection, went into one of the products, then the “back” button in the browser should become active (the transition was “deeper”). In addition, it should lead the user not just to the page with the filter dropped, but to the page with the parameters selected by the user - the system should not force the user to select the parameters every time.
[] For all filter fields, make sure that the correct data is loaded from the relevant directories.
[] For drop-down lists and checkboxes check the completeness of the output information.
[] For input fields, check for automatic substitution (chuzen).
[] For lists and radiobuttons, check if the selected value can be canceled after a value has already been selected.
[] Check that the output of data from the directories is sorted.
[] When you open a link with filtered data - the state of the filter is restored.
[] The filter dynamically changes the URL when applying filtering options.
[] When you open a link with filtered data in a separate window in incognito mode, the filter state and filtered data are restored without causing redirects, filter blinking or unnecessary transitions.
[] Changing each field from the filter is saved and restored in the link.
Example: Trainer.ru .
Why so: The user should be able to filter the directory and send a link to the received sample to another user. Another user when clicking on the resulting link should go to the filtered page.
[] All fields in the filter correctly affect the filtered list.
[] Check the filtering separately for each field.
[] Check filtering by field combination.
This is important: Often, when developing a multiple filter, the developer faces a dilemma: use the logical operator “and” or the operator “or”. With reference to the catalog, this means: when the option "green" and "XL size" is selected, only green XL-sized T-shirts will be shown or are all green T-shirts and all with XL size? As a rule, such issues are solved individually with the project manager.
[] Filter reset button works correctly.
[] Both the filtering parameters and the URL are reset.
[] Rebuilds the list of goods.
Example: Zaitsev .
[] Paging for search engines is provided.
Example: Restlook .
Why exactly this way: Products in the catalog can be loaded "infinitely" using JavaScript. The search engine "does not see" everything inside JavaScript, however, it is necessary that all products be indexed. Solution: if you have a scroll paging (or paging on AJAX, by clicking on the “Next” button) - provide a static link by which the search engine will be able to index the directory, as was done in the example.
[] Robots.txt protects against duplicate content during indexing.
[] Directory pages without a filter should be open for indexing (including indexing by page navigation).
[] Pages with applied filter should be closed from indexing.
Example: Sapato - robots.txt .
Why exactly: When a filter is applied to a directory, the page is rebuilt and the address changes. However, the content remains the same. The search engine perceives the filtered results page as a separate independent page, moreover as “bad”, with duplicate content. Solution: in the robots.txt file, only allow indexing of category pages and pages with paging. The rest (for example, filtered by color, size and other similar parameters) - prohibit indexing.
[] The filter does not create unnecessary SQL queries.
[] Works quickly, no unreasonable samples.
Example: Zappos .
[] Lists, checklists, trees, and other fields should contain only those elements by which positions can be found.
[] If filtering by any field or criterion returns 0 positions - you need to remove it from the filter or make it inactive (depending on the design).
Example: Tiffany .
This is important: Such operations significantly load the server.
[] Dependent fields are updated synchronously.
[] If one of the dependent fields changes, the rest of them update their data (update data lists, change the activity of values, etc.).
Example: Ebazaar .
Why exactly this way: Such a mechanic saves the user from “zero” returns, reduces the number of steps to finding the right products. Unavailable dependent fields can be hidden or made unavailable.
[] Provides a preloader to update the sample.
Example: Sapato .
[] A preloader for updating filter parameters is provided.
Note: On some sites (the same Sapato) there is one common preloader for updating the sample and filter parameters. This is quite acceptable, although it seems to us that this is not the most elegant solution.
[] A preliminary calculation of the number of positions found is provided and works correctly.
Example: Interno and Yandex.Market .
Why exactly this way: Depending on the design, it can be provided both on the filtering button and next to each value of the filter fields (it indicates how many elements will be found if the filter is used according to the required criterion).
[] The filter with the ajax directory loading will correctly restore the position in the list.
Example: Restlook .
Why exactly this way: If a user has loaded several pages by paging, this should change the url so that when going through it he would immediately get to the necessary page of paging. Download either directly in html or ajax, as agreed with the project manager.
[] The filter does not overload the caching system.
[] For filters with a large amount of characteristics and large catalogs, check the validity of caching results.
[] The presence of the tagged cache.
[] The reset frequency.
Why exactly this way: Suppose a user chooses the parameters: color “red”, size “XL”, material “cotton”, model “Slim”, price: 1500 rub. (the price could be specified manually, from the keyboard). The probability of repetition of just such conditions in another sample is small, respectively, it is not worth caching such a sample. At the same time, the issuance of such parameters may contain elements that may require additional sampling. You can cache them.
[] The default sort field is set.
[] Provided on the design layout.
[] The selected collations are obvious.
[] Obviously, by what field and in what direction is the sorting applied now.
[] Obviously, how to change the field and direction of sorting.
Example: Ebazaar .
This is important: The icon next to the sort field (“up arrow” or “down arrow”) should reflect the current state of sorting.
[] The button for applying the filter is always in view.
Example: Bulgary .
Why exactly this way: As a rule, the filter application button should always be present on the screen with the filter (the user should see it).
[] Bread crumbs when viewing a product allow you to return to a properly filtered list.
Example: Restlook .
This is important: When a user enters the product page, bread crumbs are often used for easy navigation. Moreover, if the user came to the product from the filter, it is highly desirable for bread crumbs to return it to the results with the filter applied.
Filter parameters cannot be stored in breadcrumb links to ensure that there are no duplicate pages for search engines. Breadcrumb links should also work correctly if the user switched to the product card for a direct link (in this case the filter should not be applied).
Possible (but not the only solution and not the most optimal) solution - instead of bread crumbs use the link "Return to catalog". The link address must contain the directory section to which it is returned and an additional parameter indicating that if the user used the filter, then you need to restore its state (eg http: // <product_cateory>? Back = true).
In order to restore the state of the filter - the filters are pre-stored in the session, separately for each category.
[] When changing the filter parameters, the button "Show" appears next to the field.
Example: Ebazaar .
Why so: If provided by the design, when the filter parameters are changed, the Show button next to the corresponding field immediately appears with the number of items to be found. This allows the user to navigate to how well the selected filter options are suitable for him before they are applied.
[] Bread crumbs when viewing goods are formed taking into account filtering parameters.
Example: 6pm .
Note: A controversial, but interesting decision.
[] The parameters selected in the filter appear in a list with the option to reset any of the selected parameters.
Example: Trias .
Why so: If it is provided by design - the chosen filter parameters get on the special panel. Each parameter on the panel has a cross to cancel filtering by this parameter. In some cases it is convenient for the user, but you always need to push off from a specific case.
Checklist in Google dock .
Use and supplement.
And here is a video from holivar about filters. With discussions we wait in the comments.
These requirements are reasonable. Some of them are difficult to implement. The part is obvious. Part depends on the context. But in general, they are quite versatile. If there are any questions on specific points - we wish in the comment.
Importance: Extra High
[] If the filter is not applied - the browser address bar contains the CNC with no additional parameters.
')
[] When first entering a category page in a url, there should be no “questions”.
You need to go to the directory or category page and make sure that the CNC is used.
Example: Zimzum .
[] When switching to a product from the catalog - the link “back” in the browser should work correctly and restore the parameters.
Example: Zolotoy-telets .
Why so: If the user chose something in the filter, received a selection, went into one of the products, then the “back” button in the browser should become active (the transition was “deeper”). In addition, it should lead the user not just to the page with the filter dropped, but to the page with the parameters selected by the user - the system should not force the user to select the parameters every time.
[] For all filter fields, make sure that the correct data is loaded from the relevant directories.
[] For drop-down lists and checkboxes check the completeness of the output information.
[] For input fields, check for automatic substitution (chuzen).
[] For lists and radiobuttons, check if the selected value can be canceled after a value has already been selected.
[] Check that the output of data from the directories is sorted.
[] When you open a link with filtered data - the state of the filter is restored.
[] The filter dynamically changes the URL when applying filtering options.
[] When you open a link with filtered data in a separate window in incognito mode, the filter state and filtered data are restored without causing redirects, filter blinking or unnecessary transitions.
[] Changing each field from the filter is saved and restored in the link.
Example: Trainer.ru .
Why so: The user should be able to filter the directory and send a link to the received sample to another user. Another user when clicking on the resulting link should go to the filtered page.
[] All fields in the filter correctly affect the filtered list.
[] Check the filtering separately for each field.
[] Check filtering by field combination.
This is important: Often, when developing a multiple filter, the developer faces a dilemma: use the logical operator “and” or the operator “or”. With reference to the catalog, this means: when the option "green" and "XL size" is selected, only green XL-sized T-shirts will be shown or are all green T-shirts and all with XL size? As a rule, such issues are solved individually with the project manager.
[] Filter reset button works correctly.
[] Both the filtering parameters and the URL are reset.
[] Rebuilds the list of goods.
Example: Zaitsev .
Importance: High
[] Paging for search engines is provided.
Example: Restlook .
Why exactly this way: Products in the catalog can be loaded "infinitely" using JavaScript. The search engine "does not see" everything inside JavaScript, however, it is necessary that all products be indexed. Solution: if you have a scroll paging (or paging on AJAX, by clicking on the “Next” button) - provide a static link by which the search engine will be able to index the directory, as was done in the example.
[] Robots.txt protects against duplicate content during indexing.
[] Directory pages without a filter should be open for indexing (including indexing by page navigation).
[] Pages with applied filter should be closed from indexing.
Example: Sapato - robots.txt .
Why exactly: When a filter is applied to a directory, the page is rebuilt and the address changes. However, the content remains the same. The search engine perceives the filtered results page as a separate independent page, moreover as “bad”, with duplicate content. Solution: in the robots.txt file, only allow indexing of category pages and pages with paging. The rest (for example, filtered by color, size and other similar parameters) - prohibit indexing.
[] The filter does not create unnecessary SQL queries.
[] Works quickly, no unreasonable samples.
Example: Zappos .
[] Lists, checklists, trees, and other fields should contain only those elements by which positions can be found.
[] If filtering by any field or criterion returns 0 positions - you need to remove it from the filter or make it inactive (depending on the design).
Example: Tiffany .
This is important: Such operations significantly load the server.
[] Dependent fields are updated synchronously.
[] If one of the dependent fields changes, the rest of them update their data (update data lists, change the activity of values, etc.).
Example: Ebazaar .
Why exactly this way: Such a mechanic saves the user from “zero” returns, reduces the number of steps to finding the right products. Unavailable dependent fields can be hidden or made unavailable.
[] Provides a preloader to update the sample.
Example: Sapato .
[] A preloader for updating filter parameters is provided.
Note: On some sites (the same Sapato) there is one common preloader for updating the sample and filter parameters. This is quite acceptable, although it seems to us that this is not the most elegant solution.
[] A preliminary calculation of the number of positions found is provided and works correctly.
Example: Interno and Yandex.Market .
Why exactly this way: Depending on the design, it can be provided both on the filtering button and next to each value of the filter fields (it indicates how many elements will be found if the filter is used according to the required criterion).
Importance: Normal
[] The filter with the ajax directory loading will correctly restore the position in the list.
Example: Restlook .
Why exactly this way: If a user has loaded several pages by paging, this should change the url so that when going through it he would immediately get to the necessary page of paging. Download either directly in html or ajax, as agreed with the project manager.
[] The filter does not overload the caching system.
[] For filters with a large amount of characteristics and large catalogs, check the validity of caching results.
[] The presence of the tagged cache.
[] The reset frequency.
Why exactly this way: Suppose a user chooses the parameters: color “red”, size “XL”, material “cotton”, model “Slim”, price: 1500 rub. (the price could be specified manually, from the keyboard). The probability of repetition of just such conditions in another sample is small, respectively, it is not worth caching such a sample. At the same time, the issuance of such parameters may contain elements that may require additional sampling. You can cache them.
[] The default sort field is set.
[] Provided on the design layout.
[] The selected collations are obvious.
[] Obviously, by what field and in what direction is the sorting applied now.
[] Obviously, how to change the field and direction of sorting.
Example: Ebazaar .
This is important: The icon next to the sort field (“up arrow” or “down arrow”) should reflect the current state of sorting.
[] The button for applying the filter is always in view.
Example: Bulgary .
Why exactly this way: As a rule, the filter application button should always be present on the screen with the filter (the user should see it).
[] Bread crumbs when viewing a product allow you to return to a properly filtered list.
Example: Restlook .
This is important: When a user enters the product page, bread crumbs are often used for easy navigation. Moreover, if the user came to the product from the filter, it is highly desirable for bread crumbs to return it to the results with the filter applied.
Filter parameters cannot be stored in breadcrumb links to ensure that there are no duplicate pages for search engines. Breadcrumb links should also work correctly if the user switched to the product card for a direct link (in this case the filter should not be applied).
Possible (but not the only solution and not the most optimal) solution - instead of bread crumbs use the link "Return to catalog". The link address must contain the directory section to which it is returned and an additional parameter indicating that if the user used the filter, then you need to restore its state (eg http: // <product_cateory>? Back = true).
In order to restore the state of the filter - the filters are pre-stored in the session, separately for each category.
[] When changing the filter parameters, the button "Show" appears next to the field.
Example: Ebazaar .
Why so: If provided by the design, when the filter parameters are changed, the Show button next to the corresponding field immediately appears with the number of items to be found. This allows the user to navigate to how well the selected filter options are suitable for him before they are applied.
Importance: Low
[] Bread crumbs when viewing goods are formed taking into account filtering parameters.
Example: 6pm .
Note: A controversial, but interesting decision.
[] The parameters selected in the filter appear in a list with the option to reset any of the selected parameters.
Example: Trias .
Why so: If it is provided by design - the chosen filter parameters get on the special panel. Each parameter on the panel has a cross to cancel filtering by this parameter. In some cases it is convenient for the user, but you always need to push off from a specific case.
Checklist in Google dock .
Use and supplement.
And here is a video from holivar about filters. With discussions we wait in the comments.
Source: https://habr.com/ru/post/210542/
All Articles