- ADA
- SEO
Screen readers and search engines rely on header hierarchy to organize content.
Currently, we generally don't have h1 tags around our top level L1 categories. We also can have multiple h1's on the page and there's no hierarchy to our h1, h2, or h3 tags. These should correspond to our L1, L2, and L3 categories.
None.
- Performance
- Single API
- Single Merch process
API v2 reduces payload size so it's more performant. API v2 will also include server side filtering, removing much of the logic currently handled client side. Moving to API v2 will also allow us to deprecate v1, which means less maintenance. Category v1 and v2 also follow different processes for Merch, unifying them would mean a single process for Merch.
The structure and how API v2 works is largely incompatible with the current backbone code that powers v1. It's not worth retrofiting v2 into the current backbone codebase as it would be more work than rewriting it in React.
API v2 would require adding filtering support into the Flatiron API endpoint.
The frontend component is relatively lightweight because the most complex code piece to the category page is the filtering. API v2 moves this logic server side.
As long as we need to support v1 and v2, Merch will have to support 2 workflows for merchandizing the site.
- SEO
Information architecture affects how we group products into categories. This can have a big impact on how site navigation works. This can also have a large impact on truncated category pages. The truncated category page design currently merchandized via programs, this can change dramatically depending on the IA work.
None.
- SEO
- Performance
Server side rendering would require that the category page be rewritten in React. Backbone cannot be rendered server side.
None.
- Server side rendering
- Page weight reduction
- Deprecating legacy technologies
The current category page code is very complicated and very much entangled in how the API v1 experience works. Reactifying this page with API v1 would be a lot of work and would not be recommended. Reactifying this page with API v2 would be the preferred path as the v2 experience defers most of the complexity to the API endpoint. This means a simpler build.
None.
To have the same experience as mobile app for L3 categories. Puts the focus of the categories on the products rather than category tiles of different colors. Reduces scroll depth.
Truncated category page is mainly a separate page and feature that won't actually share a lot of code with the non-truncated category page. This will require frontned integration with the truncated category page APIv2.
Merch is heavily impacted by truncation since the current truncated category page experience isn't as flexible as the previous incarnation.