[MUSIC].
>> Welcome back to Customer Tech Talks.
I'm your host, Ben Walters,
and today I'm speaking with
Morgan Stanley, who used WebView2 to bring Windows
and HTML apps together to create
a unified app experience for their employees.
But before we jump into the interview,
let's take a look at the video.
[MUSIC].
>> Morgan Stanley is a
global financial services institution.
We help individuals, families, governments,
and institutions raise, manage,
and distribute the capital that
they need to achieve their goals.
Everything that we do, in some way, relies on technology.
Whether it's the way we relate to
our clients and interact with them,
all the way down to connecting them
to the most powerful markets in the world.
The tools that they have,
the tools that our employees use,
it's all based on technology to get the job done.
Microsoft products are important to us,
from the tools we use on
our desktop to the way we develop software,
to the way we deploy stuff in the Cloud.
>> I'm joined by Dov Katz,
Managing Director
and Distinguished Engineer at Morgan Stanley.
Dov, thanks for taking the time today.
>> Ben, thanks for having me on.
>> Now, looking at that video,
it seems like screen real estate is
at a premium for your employees.
Can you share why unifying
the platform is so important to your industry?
>> Sure, Ben. Many of
our employees have between
two and six monitors on their desk.
We have multiple lines of business that are
being combined to provide
the best service for our clients,
and that often means they're
using multiple applications together,
whatever the problem that it needs to solve.
Those applications may be
written in different technologies.
Some are web-based, some are native desktop applications.
The way we lay those things out
has a direct impact on the client outcome.
The more productive our employees are,
the better off the clients.
How we lay them out, how we arrange
them, every pixel matters,
and doing that over multiple screens on
someone's desk is pretty crucial.
>> Now, you used WebView2
to bring these applications together.
Can you step us through how you approached this and
how you actually managed
to get all these apps to work together?
>> Sure. We started off with
a thick desktop application shell and WPF.
We did scatter flexible workspaces with that.
Over time, as more applications started to adopt HTML,
we decided to embed
Chromium containers inside of that shell
so that we had pieces of
the layout that would work with web technology.
That was okay, but we really wanted
some of those more native experiences,
such as pull-downs that
spill out of the web browser space,
events that go back and forth,
floating windows,
process isolation to manage the memory footprint.
Those things required a bit of
extra work, and we were able to achieve it pretty well.
However, there was one shortcoming,
which was we had to package
the entire Chromium browser in
its current version on every desktop release.
We didn't feel that that was sustainable.
We felt that with Microsoft's introduction of WebView2,
we finally had the ability to produce
a more robust and future-friendly version
of this application framework that
allowed for us to be
evergreen and map against
the versions of the browser on the desktop.
We were able to avoid some of
that security risk of packaging with local browsers,
and we were able to do a way better job in
native integrations such that we didn't have
this inequality where there was
always a host technology and a guest technology.
Having application developers coming
at it from JavaScript
first priority and other application developers
coming at a .NET first priority
and them being able to work
together in the framework really
allowed our developers to be productive,
which ultimately gave the best result for our clients.
>> This created a really flexible
environment that can be used
across the organization no
matter the role an employee is filling.
But that's really just part of the problem,
it's more complex than just an app version of an iframe.
Can you share some of the challenges you
faced in bringing these applications together?
>> We have rich WPF UIs,
and those are fine to
work together, money-making applications.
But the interactions that they have with HTML,
it was a very low fidelity,
you have to do a little bit of
a JavaScript hook here and there.
But that wasn't really adequate for
an employee to really
feel like they're getting the best experience.
Ultimately, the goal was, and we achieved this,
that there is this
indistinguishable user interface.
It all feels like one look and feel.
That involved things like
drop-down menus spilling out of their browser,
which ultimately meant you needed to manage pop-ups and
frameless windows to display things the way
you'd expect it to work and
the way it works with native Windows.
But this required a lot of
extra work and native integrations.
Those are the kinds of things we dealt with.
Memory footprint of the browser was a similar challenge,
for there we had to do some aggressive process isolation.
Really having access to the Webview2 meant there was
a lot of less brittle approaches to this
that really ultimately gave us
a much better feeling that this is
a very good future direction for applications,
and we're not worried about the long-term viability.
We have very good applications
written in both technologies,
and we shouldn't be choosing what's
best for the client based on
the technology stack pieces
that their functionality are written in.
>> It's really great to see that you've put all that
together and all while also not
violating or alienating any of your
developers and the languages they're working in.
As you look back at some of
the lessons you've learned throughout this process,
what's something you can share
with the viewers who are looking to
take a similar approach for their own applications?
>> Ben, like I already mentioned,
the first thing I'd say is,
we thought the whole world was moving to
HTML. That's not happening.
There is going to be this duality
of multiple technologies.
So having a first-class ecosystem
of components is really important.
The other thing I'd say with this is that we
really realize now that we're not alone in this problem.
These are the exactly the kinds of problems that
don't differentiate financial institutions,
it's the components inside these frameworks that do.
These need to be worked on together as a community.
This is the kind of stuff we would be developing in
an open-source first attitude,
and that's what we're doing with the
framework that we're building now.
That's something we enjoy, the
ability to work with our peers,
they're our great institutions.
One of the organizations,
Fintech Open Source Foundation, for example,
that we're all able to work together with peers on
problems that aren't necessarily
a source of competitive advantage.
I'd encourage more people to
be looking at solving these kinds of
common problems together as
an industry group rather than doing them on their own,
because the more people we spoke to,
the more we found everyone was
ultimately struggling with the same problem.
>> Some really great lessons there and also
some great advice for others who are
looking to take a similar approach.
Thank you so much for joining us on Customer Tech Talks.
If you want to learn more about WebView2,
you can check the links on screen now.
You can also check out
some of the work that Morgan Stanley
has been doing with some of this technology as well.
Thanks again for joining us and we'll see you next time.