DEV Community: Lauren Clevenger

MACHathon 2021: Building the BigCommerce Weather Alert Merchandising Tool

Lauren Clevenger — Wed, 10 Mar 2021 20:02:16 +0000

MACHathon 2021: Building the BigCommerce Weather Alert Tool

As a proud member of theMACH Alliance, BigCommerce recently participated in the first-ever global MACHathon. The MACHathon is a hackathon that challenges participants to build a project using MACH technology and composable architectures. The MACH Alliance presents and advocates for an open and best-of-breed enterprise technology ecosystem including microservices-based, API-first, cloud-native SaaS, and headless implementations.

The theme of the 2021 MACHathon was “Getting Unstuck.” Our challenge was to build a project in five days that would help people get virtually un-stuck while showing the world what is possible with MACH technology.

Getting Started

At BigCommerce, our hackathon team was inspired by the idea of removing one piece of uncertainty out of people’s everyday lives — the weather. By helping overcome this hurdle, we hope to inspire people to become “unstuck” by giving them the confidence to tackle the outdoors in the right gear, for the right weather, while maintaining safe social distancing.

Our solution is an ecommerce merchandising tool called Weather Alert. Weather Alert displays customized product recommendations based on a shopper’s zip code and current weather conditions. Once a shopper inputs their zip code, our backend functions make an API call to the OpenWeather API to retrieve the upcoming five-day forecast. After receiving the forecast from OpenWeather, the backend parses through the data, matches it to products, and generates a list of recommended products for the upcoming weather conditions. The product list is then surfaced to the customer so they can review the products and shop around.

Our Team

Once we had our idea, we split into two teams — one focused on the frontend and one focused on backend development.

Working together was challenging at times, especially with the short development timeline and the coordination of multiple BigCommerce teams (Solution Engineers and Product Support Engineers) across different time zones. To make sure we could work on the project together, we established routine daily meetings each morning at 7 am CST before work. We used Google Hangouts and Slack as our main forms of communication during this time. Some other unexpected challenges that came up were related to our daily work schedules. We had multiple unexpected meetings come up the week and at times we were left with only 1–2 members able to move the project forward. Throughout the week we needed to remain flexible with our tasks and responsibilities, so we would “ping” the group chat to see if anyone was available to help throughout the day. Another challenge we were exposed to was being unfamiliar with some of the technologies in play. For example, we needed to work through TypeScript, an open-source language that builds on JavaScript, by adding static type definitions. This was not something we were prepared for and required sifting through docs and Stackoverflow posts for answers. A couple of hours were spent each day after work trying to read posts, to try and make some sense of the technology and how it fit our use case.

On the day the MACHathon began, we woke up early and got to work via Hangouts. We began by brainstorming the project on an old dusty whiteboard, then mocking up what would become the design, deciding on the tech stack, and discussing the data flow of this project.

Our Tech Stack

We decided to build the Weather Alert as a headless ecommerce experience using BigCommerce in conjunction with Vercel’s Next.JS framework.

Here’s a look at our tech stack:

BigCommerce: A powerful, open SaaS platform to house product data, images, price data and deliver it to Vercel’s Next.JS framework via the Catalog APIs
Vercel Next.JS: An open-source React framework to power the storefront and display relevant product data to customers
AWS + Serverless Framework: Host the backend functions that made API calls to other pieces of the architecture and parsed through data to display relevant results
OpenWeather API: Used in conjunction with the backend functions to pull weather data for a given zip code

Solution Architecture

Developing Weather Alert

Building the Framework

In the first couple of days, the team built a wireframe for the home page and weather module and set up the Vercel connection to the BigCommerce platform. Once these tasks were completed, the two teams began to explore their respective technologies that were chosen for the project.

The frontend team explored the complexities of TypeScript, a framework we were not familiar with. This required us to spend a lot of time trying to read through documentation and Stackoverflow to familiarize ourselves with the framework. This led us to patch several things together in the way they made sense to us, and a lot of trial by error. Principal SE Stuart Guest-Smith also began an UX/UI mockup through Figma, where he laid out the groundwork for user interactions and flow on the frontend. The backend team lead by Senior SE George Fitzgibbons began hacking away at the logic that would become the backbone of the project. The backend team started by exploring available API endpoints for both BigCommerce and OpenWeather API, and how they could take a given zip code to display relevant product data to the user.

Fine Tuning

As the team entered the second half of the MACHathon, the pressure was on. During this phase team members would meet at random times in the day (sometimes even for 5 minutes!) just to check in with each other and help where needed.

By this point, most of the backend logic had been completed and the team began working on integrating it to the frontend. To integrate the backend logic with the frontend, the team began hacking away at a module that would be used to house the zipcode submit form and be able to return related products back to the customer. We ran into hiccups here and there, especially as our GitHub repo became flooded with new commits as we were trying to push into the final day of the MACHathon. Our project lead, George Fitzgibbons, did an amazing job keeping the team afloat and on course as the hours whittled down to submission day.

Project Submission

During the final day as the MACHathon submission deadline approached, our team was feeling very enthusiastic about the progress made. With any project there is always room for improvement, so we continued working on last-minute user experience enhancements. Some of these last-minute enhancements included aligning the product cards aesthetically, styling the input boxes to be more modern looking and user-friendly, and finalizing the last deployments to the homepage that reflected the initial project mockup.

While some of our team members continued working on finalizing tweaks, the other members concentrated on getting the project submission ready for the MACHathon judges and created the video showcasing Weather Alert:

Conclusion

After having faced various challenges along the way, our team was very proud of the new concepts learned and the created solution to help people become “unstuck”, while using a technology stack representative of the MACH Alliance.

Check out our project here:

The next step with this project will be releasing it as an open-source repo so others can explore the technology and build upon the specific use case.

Have you used Next.js by Vercel to build an ecommerce site, or used BigCommerce for a headless build? Show us what you’re working on and tell us what you learned by commenting below or tweeting @BigCommerceDevs.

Introducing New BigCommerce Transactional Email Templates

Lauren Clevenger — Wed, 10 Mar 2021 19:55:06 +0000

We are excited to announce our new Transactional Email templates. This launch provides a much-needed update to our existing email templates, introducing new features and options to customize the email templates with a new user interface and an API option.

Emails are an incredibly important part of the shopping experience and an expression of a merchant’s brand. Our new visual designs will provide a more aesthetically pleasing experience, and our powerful templating engine will enable merchants to express their brand and customize their emails to fit their own particular needs.

Along with the new API and Control Panel interface, new visual design, Handlebars support, new previewing features, and per-channel management, we are proud to deliver our number 3 top Community requested feature on BigCommerce Ideas.

This update will roll out progressively to new and existing stores over the next month. Since this is a highly customizable area of our control panel, we are deliberately making this feature live over a longer timeframe to ensure platform stability and reliability.

What’s New in this Release?

This release has a ton of changes that we feel will really make a difference for our merchants, partners, and developers.

Full Handlebars Support

All existing 13 Transactional Emails are currently available in Handlebars, the same powerful templating technology used to power Stencil themes. This means that merchants and developers can have much greater flexibility in customizing their emails through the use of conditional logic and helper functions.

New Default Visual Design for all Emails

The new default design of Transactional emails is more attractive and easy-to-read. Additionally, they are now fully mobile responsive and look great on both mobile and desktop.

Translation Management

We’ve made the first step for future multi-language support by adding a clean & simple UI editor for translatable phrases. Today, only the English language is supported but this list will be expanded with the addition of French, Italian and Dutch later this year.

Email Preview

Store admins can preview emails in a browser with one click without having to save the template. Preview supports desktop, tablet and mobile devices.

Send Test Email

If you would like to check how a specific email looks on your mobile or home laptop, it is now effortless with the new “Send Test Email” feature. It allows store admins to send any of the available emails to a specific email address and check it out on a real device & real email service provider.

Update Phrase Values

One area of our UI that really makes this feature shine bright is the option to change the phrase value variable in an easy to see format or in the HTML code directly. This flexibility provides users with options to make a change based on their comfort level.

API Functionality

This release introduces two new endpoints, one for managing which email templates are active or inactive, and another for managing the subject line, HTML content, and translatable phrases for each email.

Taken together, these endpoints allow you to selectively disable emails that you don’t wish to send (or you may be replacing with a 3rd party provider) and allow you to configure the content of any of the emails across all selling channels.

The documentation is available on the BigCommerce Dev Center here.

Additionally, the object model powering the Handlebars templates for each email has been thoroughly documented. This release also empowers us to expand the data available to email templates much more easily, so we’d love to hear your feedback on what information you’d like to pull into emails.

How to Get Started

As mentioned above, we are slowly rolling this new feature out to stores so that we can ensure platform stability for all merchants.

Once your store receives the update, you can easily enable the new transactional emails in your store by going to Marketing > Transactional Emails, and clicking Try New Experience.

After opting int the new version, any customizations made in your existing templates will be copied over.

If you decide this new version is not for you, you can go back to the old version by clicking the “Revert to the old experience” button.

Additional Information

For more information on our new user interface and setting up your new Transactional Emails, check out our Knowledge Base article. For API documentation, click here.

We hope that you find this new feature useful and look forward to any feedback so we can continue to improve it!

Provide a Differentiated Product Experience with the BigCommerce Custom Templates API

Lauren Clevenger — Tue, 09 Feb 2021 19:50:11 +0000

In today’s quickly growing ecommerce ecosystem, the need to differentiate is more important than ever. Merchants need unique options to display their products, categories, brands, and web pages on their storefront. In order to set this up, a merchant would need to go into their Control Panel and manually select their desired templates. This proved to be cumbersome and time-consuming which an API could solve quickly.

We are excited to make this need a reality with the availability of the BigCommerce Custom Templates API, available now!

Custom Templates API

Custom Templates is a feature in our Stencil template platform which allows merchants to use visually distinct templates for different products, categories, brands, and web pages on their storefront. While the ability to make these changes for a simple catalog is quite useful, complex large catalogs are harder to manage and benefit from being managed via an API.

Custom Templates functionality previously required users to associate a particular template with a particular object (e.g. a product) by using the control panel to manually select the desired template file for each object. This works well for users who have a smaller number of objects to deal with (for example, stores with less than 50 products), however, for stores with a lot of data, the control panel is not an efficient way to implement this large amount of configuration.

Stores with large catalogs usually prefer to perform management operations using our public API, often connecting with external systems like PIMs where they store the master version of their catalog data and sync it into BigCommerce. In order to make sure Custom Templates could be used in this way, we chose to expose a public API for managing custom template information, Custom Templates.

Unlocking New Possibilities

A public API helps some merchants directly but also allows BigCommerce partners to come up with creative ways of interacting with Custom Templates to drive merchant efficiency. A partner might use the Custom Templates API to help merchants with a large catalog display various options, or they might use it if their solution involves creating a custom product template for particular products. For example, a partner might create a custom product template for selling subscription products, or for selling products where a bulk order form is displayed on the PDP. This API would help automate the setup of such a solution, by allowing an application to programmatically set the correct template for certain products.

For merchants who have diverse and large product lines, the Custom Templates API can quickly help create a differentiated experience across different areas of their website.

Resources

Supercharge the BigCommerce Storefront Using Widgets

Lauren Clevenger — Tue, 19 Jan 2021 18:05:34 +0000

In 2019, BigCommerce released the Widgets API enabling developers to build integrations via REST API to the Page Builder. Since its initial release, we’ve made many updates to both Page Builder and the Widgets API — with more planned development and enhancements coming in 2021.

If you are unfamiliar with these features, BigCommerce Page Builder gives merchants the ability to drag and drop widgets and page components to customize their storefront with ease. According to PracticalEcommerce these tools, “represent newer approaches to software development and deployment that [provide merchants] advantages in functionality at a low cost.”

For developers, the Widget API unlocks the ability to build everything from bespoke widgets, page components, and marketplace applications.

In this blog post, we’ll explore the key features of the Widgets API and share best practices for an optimal developer workflow. We’ll also answer and give clarity to many common dev questions about building custom widgets. Let’s get started and dive deep into widgets and explore the big possibilities they unlock.

What are Widgets?

Widgets are easily configurable web UI elements. They consist of HTML, CSS and Javascript that is JSON encoded. These UI elements can be applied to any BigCommerce approved theme and extend the functionality already available. A merchant can drag and drop these blocks into their theme’s widget regions and even customize the look and feel of a widget from the control panel.

Developers can create custom widgets for a specific client or they can create widget applications that are available in our BigCommerce Marketplace. These widgets can consume store data now more easily, by using GraphQL queries. Widgets can also be configured from an application to call services that are linked to other third-party APIs like Google Maps, Facebook, or Twilio.

Developing and using Widgets are a great way to unlock functionality for the BigCommerce storefront and create solutions that merchants can leverage right away with minimal assistance. This low to no code functionality for merchants enables developers to innovate and merchants to implement their solutions easier than ever before.

Widgets Features and Support

There are several features supported via the Widgets API:

Widget Templates for the creation and configuration of widgets for both Page Builder and regional placement.
Widget “CRUD” operations and maintenance.
Using specified widget regions and create placements for widgets.
Using global regions for widget placement in generalized regions.
Versioning of widgets using update logic for templates and widgets.
The latest development is around allowing templates to pull store data using our GraphQL API.

Types of Widgets

1. Custom-developed widgets.

Custom Widget Flow Diagram

The custom-developed widgets flow is the base of all widget development. Custom widgets can use storedata from GraphQL or be developed into widget applications.

The custom widget flow documented above shows how to create custom widgets. There are basically two flows with a shared update flow. The first flow ensures that a widget is optimized for Page Builder. These widgets, when placed by the merchant in Page Builder, the POST Widget and POST Placement API calls are made on the developer's behalf by Page Builder, so this process does not need to be done by an application. For most widget use cases, you will want to use this flow.

The second flow is a direct embed to a specific placement. These API placed widgets will always appear below all the Page Builder placed widgets in a specific region. These widgets are not optimized for: utilizing layouts, duplication in various regions, and need to be re-architected if one wants to place them in Page Builder. However, widgets that are placed in regions can have their settings updated in Page Builder.

Based on your requirements and the needs of the client you can determine if you want to have your widget template contain settings. This is a schema object that Page Builder can use to modify things like CSS styling. Page Builder widgets do not require a settings schema but you need to consider how your widget may react to different regions. If that is not necessary because you built the widget template with a specific design and placement in mind, you can just place the widget for the client where it is optimal to do so. This just requires what we talked about in flow two: a region, the widget, and placement.

Versioning and updating widgets are a new feature of the API. This is an optional flow, but a very nice to have feature for managing the widget development lifecycle when you are wanting to update merchants to new versions that could have breaking changes. This allows the merchant to decide if they want the latest version of your widget, absolving developers from the headaches of managing versions outside of the widgets API. Using the Widget Template UUID you can ensure that a template is updated with a flag for “create_new_version” set to true and then update the widget with a flag of “upgrade” set to true.

2. Widgets that leverage storefront data.

Widgets can now leverage storefront data by using the Storefront GraphQL API. These widgets are dynamic in nature but follow the same creation path as above. The BigCommerce Developer Documentation contains a tutorial on how to implement graphql queries into your widget template; Create Widgets powered by GraphQL.

The most important thing is to architect your data to use a single query in your widget template. If you know that you are going to need to use many data nodes, test your query to ensure that the return meets your needs. You can see the GraphQL data relationships using GraphQL Explorer.

Note : Be aware of ‘Complexity Limits’ when using the GraphQL API.

Here is an example GraphQL powered widget template to get you thinking about your next widget build. This widget is Page Builder enabled and would show a product’s name, image and price.

POST [https://api.bigcommerce.com/stores/`{{STORE_HASH}}`/v3/content/widget-templates](https://api.bigcommerce.com/stores/%7B%7BSTORE_HASH%7D%7D/v3/content/widget-templates)
X-Auth-Token: {{ACCESS_TOKEN}}
Content-Type: application/json
Accept: application/json

{
 “name”: “Product Widget”,
 “storefront_api_query”: “query Product($productId: Int = 1) { site { product(entityId: $productId) { name entityId prices { price { currencyCode value } } defaultImage { url(width: 500, height: 500) } } } } “,
 “schema”: [
 {
 “type”: “hidden”,
 “settings”: [
 {
 “type”: “graphQl”,
 “id”: “graphQueries”,
 “typeMeta”: {
 “mappings”: {
 “productId”: {
 “reads”: “productId”,
 “type”: “Int!”
 }
 }
 }
 }
 ]
 },
 {
 “type”: “tab”,
 “label”: “Content”,
 “sections”: [
 {
 “label”: “Product”,
 “settings”: [
 {
 “type”: “productId”,
 “label”: “Product”,
 “id”: “productId”,
 “default”: “”,
 “typeMeta”: {
 “placeholder”: “Search by name or SKU”
 }
 }
 ]
 }
 ]
 }],
 “template”: “<div style=\”text-align:center\”>\n<h1>{{_.data.site.product.name}}</h1>\n<div>\n<img src=\”{{_.data.site.product.defaultImage.url}}\”>\n</div>\n<div>\n<p>${{_.data.site.product.prices.price.value}}</p>\n</div>\n</div>”
}

3. Widgets applications for the BigCommerce Marketplace.

To create a widget that merchants can discover in the BigCommerce Marketplace, you have to create a Single-Click Application. In our Theme Docs under the Page Builder section, there is documentation on “Third-Party Widgets”. You can use this information to inform your build process in addition to the information in this blog post.

You may be asking yourself — why should I sell my custom Widget in the Marketplace? Well, there are a few reasons:

You have the ability to access more data through OAuth scopes.
You can architect solutions that utilize both the Page Builder frontend and your own backend services.
You can give the user configuration options for styling and management of the widget.
You can monetize your development efforts.

Building widgets that take advantage of backend services and utilize the versioning flow give your widget applications all the tools they need to create performant and reliable applications that merchants can use and maintain on their own. This is an amazing way to provide merchants with no code or low code options for store functionality.

Tips to Develop Effective Widgets

Determine your development lifecycle

The above image showcases how to conceptualize the widget development lifecycle.

To begin, a developer or team needs to define the functionality and scope of the widget. Second, devs should work on the widget template user interface. This ensures that the user interface contains all the necessary details for the merchant storefront experience before trying to implement settings or data. This confirms that the scope is fully defined and vetted. Third, continue to work on the widget template but from the perspective of the widget schema. The merchant will then have an interface for updating CSS properties like colors, fonts, and borders as well as making sure that any configuration needs are addressed. Fourth, determine what, if any, data is needed to support the widget template. If storefront data is required, then work on the GraphQL queries and verify that the widget template behaves as expected. Save application implementation and integration efforts for the end of the life cycle is an option that gives a team a lot of flexibility when iterating on widgets. You can validate that the user-facing part of the application is working as expected before requiring placement or creating mechanisms that would allow your widget to be downloaded from the BigCommerce Marketplace.

How to work with Widget Templates

The most complex part of developing widgets is architecting your template. In order to validate your development, you will need:

A REST API client, like Postman.
A sandbox or trial store’s API scopes for Page Builder access.
POST the template to the storefront to which you have API token access.
Access to that storefront to view your widget template in the store’s Page Builder.

Note: You only need to POST the Widget Template to view the Widget in Page Builder. It is not required to POST a Widget or POST a placement, these types of POST’s are optional.

Pro Tip : Before coding an application to create this template or update it, using a tool like Postman to iterate through template creation can save you and your team time. Just be sure to save your UUID to your environment or global variables.

Optimize Widgets for Page Builder

The main property that needs to be included in order to make your widget available to Page Builder is a schema. This schema can be created using the following types:

Tabs and Sections are groups of settings. Tabs require a root-level tab to contain all the visible sections of your widget. Sections contain the settings under an optional label. Settings are the configurable options for your widget. The following diagram is from our docs:

Array schemas are collections of elements that allow you to have multiple settings as each array element can contain its own schema. Array schema types are like an “inception” of settings for widgets. This unlocks the ability to use tabs and sections inside an array type.

Hidden settings are for settings you are making for the user that the user cannot interact with. These settings should be defined first in your widget template schema because they cannot interact with a tab or array. The use case here would be default things that you want the user to see when placing the widget that they override with other settings.

We talked briefly about GraphQL powered widgets above. If you wanted to have users interact with the data that is retrieved from a GraphQL query, you could use the array type and the data filter on things like a product id or other parameter that is passed into the query as variables. This would give users the greatest flexibility when leveraging storefront data.

Convert a Custom Widget to a Widget Application

So, you have a widget already. Congratulations! Now you want to turn that into an application. Where do you begin?

First, create a Single-Click app. You can use this tutorial or the blog post linked above. Second, make a call to GET your widget template by it’s UUID and either apply that widget template to the authenticated storefront or POST a widget to using the widget template UUID to the authenticated storefront. Third, is use the widget update flow to version your widgets and ensure that merchants are alerted to updates in the control panel.

This seems easy when it is one paragraph but there are a lot of steps in between. If you need help, reach out to us in the developer community spaces and we are happy to assist you.

Conclusion

Widgets are a fun way to develop sleek solutions that merchants can actively engage within Page Builder. By creating widgets and widget applications you can unlock some serious functionality that is easily implemented by many merchants. There are so many wants and needs you can fulfill with a little widget-ingenuity.

We can’t wait to see what you all create. Share your development with us at @BigCommerceDevs on Twitter and in our developer community spaces.

Introducing More Facets Per Category with Contextual Filters

Lauren Clevenger — Thu, 14 Jan 2021 21:26:35 +0000

TL;DR

Contextual Filters allow for faceted search implementation on a BigCommerce storefront. To learn more, keep reading about the latest search updates available to BigCommerce merchants and developers.

What are Contextual Filters

Contextual filters are an enhancement to optimize how faceted search filters on categories. This feature allows developers to create a better user experience for customers that are shopping on a complex merchant catalog. Leveraging the Contextual Filter feature you can also create a better search experience for product categories. Developers can configure Product Categories to have different enabled filters. The search enhancements allow shoppers to filter by relevant criteria as seen in the GIF below.

Developer Use Cases

When leveraging contextual filters the ultimate goal is to enhance the shopping experience of a customer. The improved search experience for shoppers allows developers and merchants to create a more relevant set of search parameters, which simplifies the shopping experience. When a shopper can find a product more effectively and quickly, they are more likely to purchase that product. More purchases mean developers can deliver more to their clients.

For example, if your merchant sold both shoes and bags, they would likely have some product attributes that are universal, such as color, fabric type, and designer. However, since shoes and bags have very unique features that don’t cross over, each would need its own attributes available to search by. Shoes may have attributes such as lace options, style (slip-on versus lace-up), and purpose (running versus basketball), whereas bags may have attributes such as number of straps, pockets, and volume.

Using the suite of APIs released as part of Contextual Filters, developers can automate more processes related to the management of storefront search. An example that comes to mind is connecting a Product Information Manager (PIM) to a BigCommerce Storefront. The PIM is the source of truth for the product data and the following APIs unlock the ability to not only keep BigCommerce and the PIM in sync but also ensures that the PIM’s filters are recognizable and searchable for product categories managed in that software.

Additionally, this unlocks a lot of creative solution-ing for implementations that require unique workflows. If the BigCommerce Control Panel user interface does not meet your development style you can now have options to work outside of that UI.

Features of Contextual Filters

Developers can configure via API the settings for a Merchants user interface. In the BigCommerce Developer API reference for Settings you can:

You can “Get” and “Update” the Storefront search settings.
You can get all the available filters as well as the default filters that are applied.
You can update the enabled product filters.
You can “Get” and “Upsert” the contextual overrides for enabled filters.
You can “Delete” a contextual filter applied to a product.

Plus, many more settings that unlock search capabilities beyond the above like:

Sorting options values that are returned.
Displaying names by a label for the storefront.
Showing a number of values that are the best fit for the customer user group.
Display options like the number of products returned from search.
Areas of the user interface that you want to be collapsed by default and require the customer to engage and actively expand them.

This feature includes the following set of filtering on Category, Brand or Search pages:

Product Options filters by product options.
Custom Fields (Enterprise only) — filters by custom fields on products. Product options and custom fields that share the same name will be treated as a single filter. If names differ in case or spacing, they will be treated as different filters.
Category filters by product category or sub-category; this is only used on Brand and Search pages.
Brand filters by the product brand.
Price filters by the base price of the product which does not include variant prices.
Rating filters by product review rating and must be using BigCommerce’s product reviews.

Additionally, Other is a collection of other useful filters including:

Filter the products with free shipping.
Filter the featured products.
Filter the products that are in stock.

What is the Settings API

The Settings API is a set of endpoints that allows you to programmatically update elements of a store’s settings and configuration, which can affect the storefront or control panel experience. This new category of APIs expose settings that were previously only editable by a control panel user to public API consumers. These APIs are under active development and will be enhanced over time to progressively expose more control panel settings.

Who Can Access Contextual Filters

Contextual Filters is a feature enhancement to BigCommerce’s existing Product Filtering feature. Therefore, its availability is limited to stores that already have access to Product Filtering. This includes merchants currently on Pro and Enterprise plans, as well as developer sandboxes in use by our partners. Product filtering with support for Custom Fields is available to Enterprise plans only.

Conclusion

Contextual filters are a great way to add value to a merchant's storefront experience especially when they have a large catalog that makes traditional searching difficult. As a developer, you have options to use the Settings API to automate these processes or to enable customization on a merchant by merchant basis. Once in use, you can then leverage the default user interface or create custom user interfaces or widgets for your search components.

Resources

API Documentation (Contextual Filters)
API Reference (Settings API, Search Filters)
Knowledge Base Article for the Control Panel User Interface
Developer Community
Developer Twitter