Migrating Messaging Console to "Default" theme (Office hours: Oct 27, 2020)

[JT1989]

Issue:
The Messaging Console (https://www.twilio.com/console/sms/) uses a mix of Console components and Legacy components.

As we ship new features this quarter, we'll also be introducing a third theme: the Default theme.

Discussion
Angela Ng and I would like to kick-off a discussion:

1. What do you recommend as a long-term strategy to migrate the Messaging Console to the "Default" theme so customers experience a consistent look and feel?
2. What might the timeline look like?
3. Other top-of-mind expectations, ideas, etc

[SiTaggart]

Hey @JT1989, that's a great question!

First things first, some useful links to get us going, for those following along at home:

• Intro to the new design language https://www.loom.com/share/f6dcc7314bde4d8da30db270d6792c8c
• Transistioning your design files https://www.loom.com/share/f52ce8d9fe5147878af449b71163ee96
• Transistioning your applications https://www.loom.com/share/968cafc1417d4288906f00636d43bb77

The new Design Language is 100% ready to go. It supports everything the Console theme supports. It’s been pretty well stress tested co-existing with old, legacy experiences as part of the Console Zen project, so we’re pretty confident whichever approach you take, it’ll look great.

The new Design Language and default theme is a tool. It’s a tool that can be used by product designers and product owners to design and build Twilio experiences for your customers, better than ever before.

The roll out of this tool is entirely up to the discretion of the product designers and owners, and should be based on the product's priorities, customer need and individual situation.

Each product roll out will be different and we expect that to be the case.

We are expecting product teams to come up with a roll out plan that best suits them and their customers. We, the Design System team, really aren’t in the best position, or close enough to your customers to give a generalized or blanket answer to this.

That said, with the announcement made there is some expectation that product designers should be using the new design language as soon as possible. But you do need to work with your product owners and teams on that.

There are a number of approaches you can choose. These may include, but are not limited to:

• The big swap. Rebuild everything in React and Paste components, push it out in one go. Up front cost is huge, takes a bunch of time, and large changes to customer UI is very risky, but it does remove inconsistency entirely and will likely look great.

• Component by component. Swap components out to Paste components where you can and when you can, switch to the default theme. The inconsistencies may not be a big deal, roll out is more manageable and can be estimated into small manageable chunks

• Page by Page, starting with net new page experiences. Can likely be planned around features or epics and new releases, showcases the design language in its entirety at the page level. Old experiences are left as is until you get time to swap those.

• Feature by feature, theme providers can be nested. You can set the app to the console theme, but nest a new large(ish) new feature inside a nested theme provider using the default theme. Features are rolled out as planned, they use a single design language, but live within an old design language.

The list goes on. Whatever approach you use will be dependent entirely on your product, your priorities, you codebase and design and technical debt. However you do it, we’re confident that the new Design Language will look great supporting old experiences.

[JT1989]

Thanks @SiTaggart, I sent this discussion to our awesome engineering team. From the Messaging UI team, "our current direction is besides doing all new things using fresh components, we will do old things page by page as we see appropriate depending on how our workloads and priorities are at times."

This conversation will evolve as we pick up steam on migrating thoughtfully

[serifluous]

For office hours: Are there experiences in Messaging where you have the most concerns about switching over? Are there any experiences in Messaging Console that don't get much love, might be using legacy components, or might take a while to get prioritized?

If you can bring a rough list of those experiences or screens to office hours, we can work with you on a plan, uncover any unknowns, and help us identify any gaps in Paste that could make migration easier for you.

Suuuuper excited to see this roll out in Messaging! 🎉 We definitely want to make this a gold-star migration experience for y'all and Messaging customers.

[JT1989]

Here are 3 high-traffic, frequently used pages that gets lots of love from the Messaging 3-legged stool. The challenge is that it uses Legacy, Default, Console Components and customized charting components.

As the Default theme starts to support important components like the date range picker, tables, and graphs, it'll be easier to get it prioritized.

Messaging Dashboard: https://www.twilio.com/console/sms/dashboard

Note the automatic, yellow animations within the table.

Messaging Insights: https://www.twilio.com/console/sms/insights/delivery

Note the charts, plots and date range picker.

Messaging Logs: https://www.twilio.com/console/sms/logs