UI Synchronization

Demo and Rollout

Agenda

• Synchronization Intro
• Demo of Properties Panel in Style Guide
• Demo of Properties Panel in Recon
• Quick Review of Properties Panel Recon Usage Code
• Review of Potential Usages of Properties Panel
• Future Synchronization Efforts
• Game Plan for Rollout

Why Synchronization?

On a micro-level, we do a great job reusing tiny components in the Ember app

textboxes, modals, labels, buttons, checkboxes

Why Synchronization?

On a super-macro-level, we have also have success 

Recon, Context Panel, List Manager, Data Filters

Why Synchronization?

In the middle, though, we tend to re-invent the wheel.

We often have similar mid-sized UX problems, that have solutions already available, but that we fail to use

Why Synchronization?

Why do we fail?

Everyone is to blame.

Why Synchronization?

• Product fails to realize "this is like that"
• UX fails to notice there are cross-product reusability opportunities
• Arch UX Reviews do not include the right people
• UI Eng fails to solve potentially generic problems with reusability in mind

Why Synchronization?

The goal of this synchronization effort is to find these opportunities for reuse, build the reusable componentry, and retroactively apply the reusable UX

Why Synchronization?

Why do it now?

What is gained from retroactively applying solutions?

Why Synchronization?

1. Identical UX

While we have reinvented the wheel, they are almost always slightly different wheels

Eliminating similar solutions in favor of a reused solution gives users an identical experience when encountering this problem

Identical UX reduces cognitive load on user

Why Synchronization?

2. Same UI Code

No more maintaining separate solutions. No more fixing problems in multiple places. 

New features added to the common code get introduced to all places that code is used

And less code is good.

Why Synchronization?

3. Future Reuse

Making reusable solutions now, and leveraging them everywhere, ensures the next UI engineer doesn't copy the same set of one-off components to create another one-off

Why Synchronization?

4. Speed Everywhere

Creating the common components ensures down the road we'll be faster.

Faster to develop, but also faster to refine.

No more "well, which of these inconsistent solutions should we select for our problem?"

Todd: Demos/Discussion

• Demo of Properties Panel in Style Guide
• Demo of Properties Panel in Recon
• Quick Review of Properties Panel Recon Usage Code
• Review of Potential Usages of Properties Panel
• Future Synchronization Efforts

Rollout

So how are we going to get this done?

Rollout

Updating all the portions of the application to reuse the new componentry isn't the job of one engineer

Rollout

We (Todd, Brian, David, Eliot) will pick something worth replacing, Todd/Brian will work on designs, and Todd will build the reusable componentry

Rollout

I will build a feature around replacing the existing instances with the new reusable components

UX will work with UI to identify those places that should have their code replaced with the new componentry

Rollout

We'll get the feature prioritized, hopefully really high!

That feature will contain x-scrum user stories for each instance that needs replacement

Rollout

SCRUM teams will work with UX/Todd to ensure the implementation is correct

Profit

Rollout

Properties Panel trial run

https://bedfordjira.na.rsa.net/browse/ASOC-92541

Cycle 16: Identify Replacement Locations, provide to teams for refinement

Cycle 17: Execute Replacements

Questions?