If you’re already a Hitchhiker, log in to access this content.
How the Frontend Works| Hitchhikers Platform
What You’ll Learn
In this section, you will learn:
- How the Answers frontend works
- What the Answers Search UI SDK is and how Jambo interacts with it
- The key steps to developing an Answers experience
Frontend of Answers with Yext Pages
As a refresher, the frontend of Answers controls what the user sees when they ask a question, including how the results page is structured, what each results card looks like, and other optional components you can use like facets or Q&A.
In order to actually build out an Answers frontend experience, a developer or system (like Yext Pages) uses components from the Answers Search UI SDK.
While, as an Admin, you will not need to use the Answers Search UI SDK directly to build an Answers experience, it’s important to know a few fundamentals, which you’ll learn about in this module. Developers can choose to build on the Answers Search UI SDK, Answers Core, or API directly, but our Pages integration with the Answers Search UI SDK _+ Answers API makes it easy for someone with basic knowledge of HTML/CSS/JS to build an experience end-to-end in under an hour!
While you learned a lot about how to build pages using the Page Builder in the Pages track, with Answers you build using Yext’s Custom Development for Pages. The Answers development uses Jambo, a static site generator (SSG) that relies on the JAMStack architecture.
The Answers Search UI SDK
You will build Answers frontends using Jambo. Jambo ingests components from the Answers Search UI SDK and responses from the Answers API, both of which are built and managed by the Yext Product and Engineering teams. In the Search UI library, we have a number of built-in components that help to create and define an experience. This includes things like:
- Search Bar
- Universal Search Results
- Vertical Search Results
- Direct Answers
- Q&A Submission
- Location Bias
- Sort Options
- Filter Box (e.g., Static Filters)
- And more
We release updates to the library using semantic versioning (a widely accepted practice in software development), where each number in the version tells a user more about the version and whether an update is a Major change, Minor change, or a Patch. This system has several benefits: by pinning to a minor version, you’ll receive any bug fixes for free (without having to redeploy your site), and you can easily compare your version to another to see what changes will need to be accommodated in an upgrade.
Pinning to Versions
When you set which version of the Search UI SDK you want to use, you can choose what level of specificity you want to use. We call this pinning.
Here are some examples:
- sdkVersion: 1 - this means you’re pinning to a major version and your experience will use the latest public library version that starts with 1.*. This is not recommended for production experiences as it could be risky.
- sdkVersion: 1.3 - this means you’re pinning to a minor version and your experience will use the latest public version that starts with 1.3.*. This is recommended for most sites as it means you will get patch fixes automatically.
- sdkVersion: 1.3.4 - this means you’re pinning to an exact version. If there are patch updates (e.g., bug fixes), you will need to do work to upgrade to the latest. This is recommended for high profile sites with strict protocols on changes.
In most cases, we’ll recommend pinning to a minor version, such that you get any patch fixes automatically. To do upgrades, you’ll want to carefully review the changes and upgrade instructions, and may want to enlist the help of a developer. Overall, we recommend upgrading to take advantage of new features as they’re released. If you’re not interested in any of the new features in a major or minor release, you can also choose to skip it (our product team won’t be offended!).
In general, you should expect there to be patches as needed (potentially multiple times a week), minor releases every month or so, and major releases a few times a year.
You will learn more about upgrading versions in Upgrading Your Experience module.
Overview of Build Process Using Jambo
If you’re building an Answers Experience with Jambo, then congratulations – you’re writing code! These are many of the same steps that developers take when they’re building websites, applications or other software.
- You have a repository that houses your code
- You change files in that repository
- You can choose to Preview those changes locally
- You commit your changes
- The system attempts to “build”
- The system “deploys” or “publishes”
Sure, that’s simplifying things, but you’re going to be doing these exact same steps as you build your Answers frontend. Who knows, maybe you’ll become a bonafide developer soon!
Let’s dig into some more detail for each step:
Step 1: Creating an Answers Jambo Repository
Out of the box, we use Git (a widely accepted version control system) to manage your Answers code. When you’re ready to build an Answers site, you’ll need to create a Git Repository in GitHub. A repository, or “repo”, is a common term in software; it is a group of code/files with version history. In Yext, you can do this by creating a Site in Pages and then adding a Repository. You can select an Answers Jambo repository template, which will generate a GitHub Repository with all of the pre-built files you need to create an experience. In many cases, this step will be done for you if you are starting with a Hitchhikers Challenge or a Solution Template, but it’s good to know how to do it in case you want to start a new Experience from scratch.
Step 2: Modify the Code
While we like to think that our default experience (part of the Jambo Theme you’ll learn about later) will work just the way it is, we know that each brand is different and has unique requirements. If you navigate to the Site you created in Yext Pages, you’ll find a link to “View Code Editor”. Here, you can view and modify any of the files in your Repository and customize the Experience to your brand, just like you would through GitHub directly. Want to modify the colors to match your brand? No problem! Want to change the layout of your card? No problem! Want to adjust how data is pulled in from the Knowledge Graph? No problem! You have control with the Yext Code Editor.
You’ll get a description of all of these files and their purpose in the next unit. For now, you just need to know that you can make changes to your Answers Jambo repo straight from the browser, without having to install git and use your terminal. You can access the Code Editor for your site by navigating to Pages > Site > View Code Editor.
Step 3: Preview Your Changes
A good developer always previews their changes while they’re developing to catch mistakes or to experiment with different approaches and designs. We also encourage developers to preview their changes in different browsers. When you’re ready to preview your change, you can click Update Preview, check to make sure there aren’t any errors in the console and then refresh your preview page to see the updates. This will make your life infinitely easier, especially as you’re getting started! You’ll learn more about this in the Live Preview unit.
Step 4: Commit Your Changes
Once you’re feeling good with your code, you’ll want to commit these changes. This will update your GitHub Repository and kick off a “Build”. When you commit your changes, you’ll want to include a message reminding yourself and others what the commit was for. You can also optionally add a tag to your commit, making it easier to publish that specific version of your site.
Step 5: Yext CI Builds
After you commit your changes to your GitHub Repo, the Yext CI will build your site. The Yext CI (CI stands for “Continuous Integration”) monitors your commits and runs a post-processing toolchain as soon as you commit. During the build, we are compiling all of the source code in your repo to get it ready for publishing. You can monitor your builds in the Platform by going to the Builds tab in either the Staging or Production environment (builds are actually not specific to an environment, but this is where you can find them in the UI). You don’t need to know too much about what’s happening in this step, except that there might be errors, typically due to errors in your code. You might need to commit new code to fix these errors or to kick off a new build.
Step 6: Publishes your page
You are almost ready to have the world see your work! The last step you need to do is publish your page. You’ll learn more about this in the Pages Generation unit.