A. Proposal

Automate aspects of the initial theme setup process, decouple Commerce theme updates from the release cycle, update the theme documentation to account for the process changes, and consider implications of our existing theme divergence and steps to address them.

1. Summary of problems we are solving

Theme setup and theme updates consume a non-insignificant amount of developer hours each cycle. A recent review revealed that 22+% of the FE team was spending time doing theme-related work. There are a number of factors that contribute to this, including environment bottlenecks, documentation shortfalls, release timelines, asset handling, insufficient automation, lack of ability to theme against a live environment, asset coupling considerations, and the abundance of sites that are still not on Theme Designer.

There is plenty of opportunity to reduce this overhead, and the following steps are recommended to effect this reduction, in this general order:

1. Automate all manual setup processes. These include, but are not limited to:

   1. Theme directory prompted automated generation.

   2. Theme config file prompted automated generation.

   3. Automate asset optimization and theme validation

2. Move themes out of NOP and into independently deployable packages to decouple theming from the release cycle

3. Move theme assets to a CDN or similar file service to deliver theme changes that are not release cycle dependent.

4. Update theme documentation to account for process changes associated with this project.

5. Build TDv2 to utilize CSS Custom Properties (CSS Vars) to enable theming against a live site. (See Tampermoney prototype below for demo)

6. Move all TDv1 resorts to TDv2

7. Move all non-TD stores to TDv2 (undecided, see details in the Proposed Scope section).

2. Goals

1. Measurably reduce the developer hours required each cycle to complete theme work as tracked though timecard allocation to theme work over several months. I would expect to see a 30-40% (50%+ of we built TDv2) reduction in developer hours in this area when using an average number of update requests over 3-4 cycles. This will be addressed through the conversion to TDv1/v2, creation of TDv2, improved documentation, and live environment injection. This involved pre and post release optimizations.

2. Eliminate the dependency on release cycles to get theme updates live. This will be addressed by moving theme files out of NOP and into independently deployable packages that can be shipped directly to a CDN. This is a pre and post release optimization that would eliminate the dependency on release cycles for theme updates.

3. AW theming background

During the first couple of years of Aspenware Commerce, resorts were allowed to highly customize their Commerce store appearance. CSS files were written line by line to customize nearly any element of the site to the Resorts request. There were a couple of rounds of revisions provided before a site went live. Depending on how particular the resort requests were, it would take anywhere from 6 to 12 Front End developer hours to theme a Commerce site before resort sign-off.

A year ago, we made our first efforts to reel-in theming with the development of the Theme Designer platform. Theme Designer implemented several significant changes to the theming process:

1. Theme documentation for Resorts and developers was created.

2. Standard theme options were established, and resorts have to select from these options – though the developer has some flexibility through mixin arguments.

3. A stand-alone theme configuration application was developed to provide a way for developers and resorts to preview the theme decisions in real-time during an initial design meeting. This significantly reduced revision requests.

4. Configurations set up in the app can be exported to use in their theme file - no more custom-written CSS.

5. Theme designer leverages component-focused SASS Mixins to encapsulate and standardize all styling as well as CSS Custom Properties that can be updated in real-time and shared across web properties.

These changes reduced initial theme setup to 4 hours or less on average. Much of the initial setup time is now the result of the other bottlenecks identified in the Summary.

All Boyne resorts were converted to use Theme Designer at Boyne's request because it allowed them to maintain a consistent brand across all their properties, and it made managing brand updates easier for them. All resorts that have joined AW since the creation of the program have been themed using Theme Designer, and we have received very positive feedback from Resorts about the process.

That leaves us with the older Non-Boyne resorts with highly customized and fragile theme CSS to address. These resort themes pose a roadblock to joining any future Self-Service Theming platform and they consume the most developer hours in terms of overall theme maintenance when updates are requested – primarily due to their fragility and extra QA needs.

Current deficiencies in TDv1 include the inability to preview themes on live sites without standing up an environment, the inability to deploy theme updates outside of the release cycle, lots of manual file creation in NOP, a lack of an automatic theme format validator, its reliance on SCSS Mixins that require pre-processing, and that the Theme Designer app needs to be run locally. The last item means that a dev has to be part of the design meeting with the Resort.

4. Benefits of completing the optimizations identified in this proposal

Benefits Resorts

• Decouples theme updates from release cycles

• Deliver theme assets and CSS to the client faster resulting in optimized page loading

Benefits Aspenware

• Reduces developer hours required to do theme work via automation, theme conversion, and improved docs

• Delivery of assets via CDN reduces load on the servers, especially during usage spikes increasing platform stability

• Aligns theming with the trajectory of a self-help proposition for resorts

Benefits Both Aspenware and Resorts

• Faster turn-around times for initial theme setup.

• Seasonal Images will be able to be updated without a release

5. Live theming Demo

1. Install Tampermonkey in your browser.

2. Install this script in Tampermonkey (Utilities > Import From File)

3. Once installed, goto https://qa-current.aspenwarecommerce.net/s/access-products/reservations/ to test it out. The script will only run on QA-Current.

Open

B. Project Details

1. Scope

Round 1 Scope

• Decouple theme updates from release cycles

• Automate asset optimization

• Automate theme directory and base theme file generation

• Automate theme config file generation

• Automate theme validation

• Update theme documentation to account for process changes associated with this project

Additional Proposed Scope (Round 2)

• Developing a way to preview local CSS applied to a live site (TDv2). This is beyond the current capabilities of TDv1. Proposals were discussed during the breakout session on self-help theming to address this disconnect and pave the way for next steps on that project.

• Upgrading resort themes that are already on TDv1 to TDv2.

• Upgrading resort themes that are not on TD yet to TDv2.

2. Estimated developer commitments

Asset automation and theme validation:

1 FE Developer, 1 sprint

Decouple themes from NOP

1 FE Developer, 1 sprint

CDN asset hosting

1 FE Developer, 1-2 sprints (will also likely need some team BE or DevOps support)

Theming documentation updates (post optimization work):

1 FE Developer, 2-3 days.

Under Consideration: Develop Theme Designer v2 to support live theming against a live site.

Options:
Live theming, automated release pipeline to CDN - 2 FE Developers, 1 BE Developer, 1 Devops: 4-6 weeks

Live theming, manual theme download, manual release pipeline - 2 FE Developers, 3-4 weeks

Under Consideration: Store conversions TDv1 to TDv2

1 FE Developer: 1 sprint (22 Stores, 2 stores per day)

Under Consideration: Store conversions, Convert non-TD Stores to TDv2

2 FE Developers: 1 sprint (32 stores, 2-3 stores per day)

Important note on these time estimates. If we address the environment and scripting/automation items identified first, we can reduce the conversion times below the store conversion estimates. If we also build TDv2, these conversions estimates would be further reduced. This would also well-position whatever team(s) gets tasked with the upcoming Alterra onboarding.

3. Resorts that require conversion to TD

Not on TDv1 - Total: 35

Abasin, Aspen, AspenX, Alyeska, Aspen, Bear Valley, Big White, Boreal, Boreal-Summer, Cardrona, Copper, Eldora, Homewood, JacksonHole, Killington, Lee Canyon, Marmot Basin, Mt Bachelor, Panorama, Peak (AW Brand) Pico, Red Lodge, Snow Basin, Snowbird, Soda Springs, Sugar Bowl, Sugar Bush, Sun Peaks, Sun Valley, Tahoe Donner, Telluride, Thredbo, Whitefish, Windham, Woodward Park City

On TDv1 - Total: 22

AV Bay, Big Sky, Bogus Basin, Boyne Golf, Boyne Highlands, Boyne Mountain, Brighton, Crystal Mountain, Cypress, Gatlinburg, Grand Targhee, Inn at Bay Harbor, Loon, Mt Buller, Pleasant Mountain, Revelstoke, Saddleback, Silverstar, Snoqualamie, SugarLoaf, Sunday River, Winsport,

4. Concerns Identified

• Resorts will have less flexibility with theming individual elements than they do now - however, we have not found this to be a problem with any of the resorts we have converted so far. There is enough flexibility in the TD1 mixins to reasonably align the pre- and post-conversion site themes.

• Converting themes to TD1 does not address the lack of use of the CSS Props that will be required to theme against a live environment without the NOP dependancy.

• Resorts may have to move to using our simple header if we are currently scraping their brand header.

• In some cases, converting resorts may have to choose a product card design option that is not a one-to-one match with their current design.

• We may not be able to convince all resorts to convert, but any that do will contribute to a reduction in developer hours required for ongoing theme maintenance/updates. We do not need all resorts to convert, but any that do not may not get access to Self Help theming in the future.

• Aspen and JH are likely to be holdouts on converting as their themes are highly customized – in some areas beyond what we can replicate with TDv1.

• There will be monetary costs associated with hosting theme assets on a CDN

• These optimizations will result in some process changes, so devs will have to learn the process changes. The initial knowledge gap slowdown should be mitigated by the overall optimizations resulting in a net reduction of dev hour allocation even during the learning process.

• Theme Designer v1 will not be able to support live theming against a live site. The reasons are identified in thes Jira cards and will require redevelopment. https://aspenware.atlassian.net/browse/PPP-55 https://aspenware.atlassian.net/browse/PPP-58

5. Preparation considerations

• All resort coordination and sign-off to convert should be done in advance so that developers can move quickly through the list of conversions without having to stop in between to coordinate with resorts.

• A design meeting will likely not be required for conversions as the developer will utilize Theme Designer to replicate the existing themes as closely as possible using the mixins and available mixin arguments.

• It may be beneficial to identify for the resorts those items that will change from their existing theme on a resort by resort basis to set expectations for conversions.

• Theme conversion testing will be done in the Resorts test environment, so no additional environments are needed. Services will need to make sure that the resorts are aware that the conversion will be done on their test store so that we have advanced permission to deploy there for testing/QA.

• Little work will be required of the Resorts beyond feedback and approvals for conversions. All existing images, fonts, logos, etc will be reused in the conversion.

6. Unaddressed in Round 1 Scope

Theme divergence

• We still have a divergence of theme architecture between Pre and Post Theme Designer 1 Resorts on the same platform. This lack of standardization is amplifying our

Theme fragility

• Unaddressed is the fragility that still exists in the way we override global CSS. This time sink is amplified in pre-TD1 Resort themes due to the extensive customization of those themes and the lack of extensively tested standardization that was used TD-1.

Residual NOP dependency

• Neither the Commerce CSS we override, nor the Resort themes make use of the CSS custom properties that will be required to theme against a live environment without running NOP locally. This remains one of largest unaddressed time sinks, and a roadblock to realizing a theming platform that Resorts can access.

Theme Designer App Inflexibility

• Theme Designer v1 was built under a very tight deadline to address the extensive time involved with setting up an initial theme. It was intended to be exclusively a developer tool, to serve a very specific task. As a result, it cannot be adapted to use CSS custom properties as needed and should be rebuilt with a proper development timeline and planning with the intent on being web facing.