If you're reading this article, it may be because you're interested in integrating Searchspring or because the process is underway and you want to know how to prepare. As part of the project for enabling Searchspring on a site, the team here will create a mockup. What is a mockup though? A mockup is a "copy" of your site that will show how Searchspring is going to function when implemented on a site. It will allow a person to perform test searches and use filters.
To create a mockup, the Searchspring team should be provided a completed design of either a search or category results page. With the latest version of the Searchspring catalog, we create various templates using the page's HTML markup thereby inheriting your site's CSS (or stylesheets).
But what exactly do we mean by a "completed design"? There are a few things (noted below) that we'll be looking for.
Development or Live Site?
If the design has not been published live yet, Searchspring can create a mockup using a design from a development site. While Searchspring is creating a mockup, there cannot not be any drastic changes to the development site. To further explain, the Searchspring Developer will pull down and copy current assets (CSS, JavaScript, HTML, etc.) from the results page for the mockup. If at any point the site styles are changed or the HTML markup is altered, the mockup becomes outdated. This creates delay in receiving a mockup as the Searchspring team has to change assets on their end and verify everything is working correctly. And as one might imagine, postponing the mockup delivery also holds back subsequent stages in the site's project (such as the Revision and Integration stage).
If updates are made in CSS and the URL for that file does not change, this won't be a problem as we'll inherit the site's styles. The only time a CSS change does make a difference is when there is a caching system in place on the site's assets.
Example
A Searchspring developer creates a mockup and at the time the site's CSS file was the following:
http://mysite.com/css/site.css?1234
The "?1234" specifies a version number. While the mockup is being worked on, there is a change to the site design that makes a button in the item results blue instead of green. The CSS file now has a new version number like so:
http://mysite.com/css/site.css?5678
The Searchspring developer does not know this change was made and the delivered mockup will potentially be inaccurate.
Results
The results portion of a site will usually include products, pagination, sort by, or item per page selections. For a mockup, this section on the page to match should be complete. Questions you might review are:
- Is there pricing logic with the MRSP and retail price?
- Are there badges/flags on the items to tell a customer is something is "New", "Out of Stock", "On Sale", etc.?
- Is there an "Add to Cart" button and does it bring the customer to the product page or does it add an item to a cart?
- Is there other native platform functionality like "Quick View" or "Add to Wishlist"?
It is unlikely that the Searchspring team will not be able to replicate the design of your results, but in order to ensure the mockup process goes as smoothly as possible, it is necessary for the results to be finalized. Providing examples for logic you would like to see carried over is helpful as well.
Example
A product in the data has a "New" badge assigned to it for testing purposes. Giving us the appropriate product id or link means we do not have to hunt for the correct product to verify logic. This is especially useful if a site has a large amount of products.
Filters
The filter (or sidebar) design can be flexible in comparison to other points discussed in this article. Often we realize that people aren't quite sure what they would like as adding filtering can be a new experience. To begin the filter portion of the mockup, the Searchspring team requires (at minimum) simple HTML markup and a few styles (such as font colors and type) for the filter titles and options.
Example
<div class="filter-container">
<h4>Filter Title</h4>
<ul>
<li><a href="//mysite.com/option-one">Option One</a></li>
<li><a href="//mysite.com/option-two">Option Two</a></li>
<li><a href="//mysite.com/option-three">Option Three</a></li>
</ul>
</div>
Thankfully, Searchspring has some "stock designs" to improve the look and feel of the filters. These additions (at the time of mockup creation) are at no extra charge and if you like any of these features, please let your Customer Success Manager or Sales Representative know.
Add-ons:
- Checkboxes in a choice of three styles: style 1, style 2, and style 3.
- A selected option Filter Summary in two styles: style 1 and style 2.
- For mobile and responsive design, we have a flyout filter menu. This will enable customers to use filter options when searching on mobile devices.
- A range slider (commonly used with prices). For a slider, data in the feed must be formatted in either decimal or whole number values.
- Color palettes using web-safe color values from the feed. Custom colors ("rainbow", "multi-color", etc.) can be used in a palette, but Searchspring will need either a hex color code or image to map to.
- Typically used with "Sizes", we can add grid selections. It is recommended that text values for option be smaller in size - no bigger than four letters long. For example: SM, LRG, X-LRG, MD.
- A toggle button which will hide or show filters beneath the title. There are two styles currently: with a plus/minus icon or with an up/down arrow.
Please note that most of the screenshots above are very basic. If any of these add-ons are requested, we will attempt to match your site's design. Because we have the ability to add extra styles for the sidebar, at the very least, the overall site design has to contain a basis of colors and fonts that you would like us to use. Heavy customizations or change requests to these stock designs may require Professional Service fees.
Functionality
In regards to functionality, having JavaScript and/or jQuery code as accessible, named functions is always preferable. With the Searchspring catalog, when we create templates of items and filters, we have to "re-run" functions after the catalog has fully loaded and content is displayed. If functions are named, we can easily execute the code again. Take the below code examples:
if ( jQuery('.an-element').length > 0 ) {
// Execute over 100 lines of code here
}
versus
function myFunction() {
if ( jQuery('.an-element').length > 0 ) {
// Execute over 100 lines of code here
}
}
myFunction();
In the second example, Searchspring can add one line of code to run myFunction, whereas in the first example, we can either copy over 100 lines of code or request the client to name the function.
There are cases of functionality that while we can duplicate, it requires a bit more complexity.
Example
mysite.com has an "Add to Wishlist" button on all items in the results. A customer can click this button and add an item to a wishlist which is visible in the user's control panel. If a product has been added, the button changes color and items can be removed from the wishlist by clicking on the button again. To wrap everything together, Searchspring will need to know:
- Is the user logged in or not?
- What items has the user already added to their wishlist?
This information can be relayed to Searchspring over global variables on the search page. It is added through the cart's templates.
AutoComplete
As Searchspring has a standard AutoComplete template updated to match your site's design, we do not need anything to match. Though if there is something special you'd like to see in the AutoComplete modal, you are welcome to address this to your Customer Success Manager or Sales Representative.
Comments
0 comments
Article is closed for comments.