NICK SIMONS: Hi, I'm Nick Simons,
the Product Manager on the Fluid Framework.
I'm excited to announce that
Fluid Framework is ready to power
your production scenarios this summer.
The Fluid Framework Open Source Library
will reach version 1.0 and the Azure Service that
powers Fluid will be out of preview this summer.
We will be talking to teams both inside of Microsoft and
outside who are using Fluid for
production scenarios right now.
We'll also demonstrate how to build
a collaborative experience using the Fluid Framework.
But first, let's talk a little bit about
what Fluid Framework actually is.
As it turns out, building
software that allows people to collaborate in
real time is remarkably challenging and
that challenge is twofold.
First, you have to design
the parts of the product that people interact with;
the user experience.
Second, you have to architect and deploy
the services that power that experience.
But what if building collaborative experiences was,
well, not easy exactly, but easier?
What if you didn't have to worry about
the service part at all?
That is where Fluid Framework comes in.
Fluid is designed to handle
the complexity that lies beneath
real time collaboration.
Teams within Microsoft and
around the software industry are using
Fluid right now to bring
collaborative experiences to their customers.
We'll talk to them a little bit later.
But first, I want to show you something.
My colleague Tyler and I were discussing
the best way to explain Fluid.
We agreed that it's better to show Fluid in
practice rather than trying to explain how it works.
I wrote a simple app that simulates
a child's felt board,
basically a canvas where you
move colored shapes around to make a picture.
I used an open source library called
PixiJS that made it easy
to create the core app in an afternoon.
I didn't even try to make the experience collaborative.
Tyler took my app and used Fluid to
add real time collaboration to the experience.
I'll let Tyler explain how he did that.
TYLER BUTLER: Hello. My name is
Tyler Butler and I'm
a Product Manager on the Fluid Framework.
In order to get Fluid integrated with our application,
we needed to do three high level things.
First, we needed to add a way to
connect to the Fluid service and
initialize a Fluid distributed data structure
in order to store all of our Fluid data.
Second, we needed to determine what exactly we wanted to
synchronize using Fluid and
create some functions in order to do that.
Finally, we needed to connect
the synchronized Fluid data
in the distributed data structure to
the application UX so that
as users interact with the application,
the data is synchronized and actually
updates on all of the remote clients.
In order to get started with Fluid,
we first imported the Fluid Framework Libraries.
We then needed to decide which Fluid distributed
data structure to use to hold our Fluid data.
We used a shared map,
which is a data structure for key value pair data.
We started by looking at
the PixiJS display object class
which contains properties that control
the shape, position, color, etc.
But it also contains a bunch of other properties
that we don't want to synchronize between clients.
In addition, in order to synchronize data using Fluid,
that data needs to be in a safely
JSON serializable form.
Classes aren't JSON serializable.
In order to synchronize data using Fluid,
we created a plain JavaScript object
called FluidDisplayObject.
That object contains the properties that
we want to synchronize using Fluid.
Since it's a plain object,
it's safe to serialize.
Now we have an object with
properties that we can synchronize using Fluid.
We next created two functions.
The first, Pixi2Fluid, takes
a Pixi display object and extracts
its properties into a FluidDisplayObject.
The second function, Fluid2Pixi, does the inverse.
It takes a FluidDisplayObject and sets
the relevant properties on a Pixi display object.
Now, we have a fluid compatible object
and a set of functions to work with that object.
The next step is to connect
the Fluid data to the application.
We need to do that in two places.
First, we need to update
the Fluid data as shapes are moved locally.
To do that, we enable each shape to update
its own Fluid position by providing
a function to each shape called setFluidPosition.
Each shape defines its own event handlers
for things like dragging shapes,
so now we call setFluidPosition in those handlers.
Now, each shape is updating its own Fluid data
and Fluid is synchronizing
all of that data to every client.
We've now handled getting the local changes into Fluid,
but we have not yet handled changes from remote clients.
In order to do that,
we can listen to an event on
our Fluid distributed data structure.
Whenever a remote shape is changed,
the value change event handler is called.
You can see here in the code that it uses
the Fluid2Pixi function to update
existing shapes and creates
new Pixi shapes if the shape doesn't exist locally yet.
In order for us to share the experience
on the Internet though,
we need a Fluid server.
We didn't need to write any server code,
but we do need something for
the Fluid Framework to synchronize
data between the clients.
We use the Azure Fluid Relay Service
which is currently free to try
and exits preview this summer.
Setting up an instance of the Azure Fluid Relay is the
same as setting up most Azure resources.
In only a couple of clicks,
we had a working Fluid Relay instance.
The Fluid Framework includes
client APIs that make it easy to use the Fluid Relay.
Use the URLs and keys like the one shown here to
connect your app to the
service and everything else just works.
NICK SIMONS: Thanks, Tyler.
I want to emphasize how
fundamental Azure Fluid Relay
was to the success of this demo.
In principle, anyone can stand up a Fluid service,
but it represents an enormous investment.
Azure comes with critical properties, such as security,
reliability, compliance,
scalability, and data residency.
I want to thank the Azure Fluid Relay Team
for building an amazing service.
Second, I want to talk a little bit about how we handle
off and the token required to
connect the client to the Fluid Relay.
Our app is anonymous and
we use an anonymous token provider.
This is not recommended.
But most likely, your app will include
off and you can use that
off solution to manage your tokens.
Last, I want to point out
a potential bug in our demo app.
Right now, if client one is dragging
an object and client
two changes the color of that object,
then client two's color change
will be lost when the drag ends.
This is because we store all of the properties in
a single Fluid object and
that object is changed atomically.
To fix this bug,
we need to break up the Fluid data into smaller chunks.
For example, one object that includes position data and
a different object for
secondary qualities like color and transparency.
It's important to note that everything we did to build
that demo app, you can do too right now.
Follow the links on the screen to learn more.
There are several products in
market or coming to market soon
built with the Fluid Framework.
These include both Microsoft products
and products from other companies.
I reached out to some of
our partners to talk about Fluid.
SHELLY MUJTABA: The industries we serve are
seeing an increasing trend towards
real time collaboration and
more and more data is appearing in the Cloud.
It allows multiple participants
and even automated systems
to react to data in
the real time and modify the data in real time.
For example, one of our key products,
AutoCAD, has a capability called Sheet Set Manager.
Previously, users had to check out the sheet set,
make their changes, and check it back in.
But with the use of Fluid technology, they are
able to now concurrently edit these sheet sets.
This is just one example.
We have numerous use cases,
such as collaborative design editing,
model coordination, and Excel-based
workflows that can take
advantage of concurrent workflows.
BRUCE ENGELMANN: Fluid Framework is really
going to provide us
the backbone for all our future work,
to connect our customers data and provide
a truly collaborative environment for our customers.
For us, it gives us a means to develop
a scalable digital thread that could be used from
everything from instantaneous collaboration of
a few colleagues on
an engineering team to something that's
much more locked down and deliberate
like managing simulation and engineering data.
Fluid is going to allow us to be able to combine
automated workflows that can be set
up to provide that necessary automation,
as well as orchestrated workflows with
humans and machines at the controls.
FAITH ALLINGTON: Whiteboard was built to be
collaborative and so being
able to use the Fluid Framework
and OneDrive for Business for
data sync just means that
we can focus on our productivity experiences
and we get to leverage all of
the storage capabilities in
a very straightforward way, which is great.
Fluids distributed data structure was
just a really good match for the way
our product was already put together,
so it made total sense for us to use Fluid.
As a widely used product
with a lot of year over year growth,
we absolutely need a framework
that's being deeply invested in like Fluid is.
SHELLY MUJTABA: So we looked at a number of
different technologies,
but there was also a recognition that
concurrent collaborative editing is
a complex orchestration problem.
We realized that we would like to join an ecosystem that
allows us to not only learn from
the community, but also contribute back.
When Microsoft rolled out the Fluid initiative,
that was a perfect fit for us.
BRUCE ENGELMANN: We chose Fluid because
it's the right technology at
the right time to link data
across all of our applications.
It's unopinionated, it's simple,
but it's extremely powerful.
It's really important to
us that Fluid is open source.
It gives us a genuine way to be
part of a great emerging technology.
We can benefit from all the work
put in by Microsoft and the other contributors.
We can also contribute to the code ourselves.
I know my teams are super excited to be part of this.
NICK SIMONS: We're excited to see
Fluid Framework powering real world scenarios right now,
but it's still early days.
I've invited Roland from Autodesk and
Taylor from the Fluid Framework Team to talk about
some of our investments that we're making in
new distributed data structures
to support new scenarios.
I know we're working on adding a tree
distributed data structure to the Fluid Framework.
Can you talk a little bit about why?
ROLAND RUITERS CHRISTOU: Today, Fluid is based on
the concept of rather simple data structures
like an editable string or a map.
But for Autodesk, we have
often much more complex data models.
We realize that it makes much more sense to have
one tree structure which can have
all these elements inside of the data structure.
TAYLOR WILLIAMS: I think the problem that we
are trying to solve here with
the shared tree effort is bringing together a number of
often disparate technologies and putting them together
in a package that is adaptable and easy to use.
ROLAND RUITERS CHRISTOU: This gives you, for example,
transaction safety
where you can do multiple
edits inside the data
structure as one transaction.
The ability to do more complex editing operations,
like moving things around within the tree.
They are also better performance because
we no longer have so many small objects to handle.
NICK SIMONS: I think it's awesome that
Autodesk and Microsoft are
working together on this.
How did that start?
ROLAND RUITERS CHRISTOU: Inside of Autodesk, we have
already been working on
collaboration technology for several years,
but at some point, we realized
that this is really something we should do
together with stronger parties
instead of just developing our own solution.
Microsoft just had open source, the Fluid Framework.
We realized that their and our goals
are actually very similar and so we
decided to join this project and
contribute large parts of
what we have been working internally.
TAYLOR WILLIAMS: Just like the shared tree
itself is a conglomeration of
a bunch of different really cool features
in a neat package,
I think the team building it is also
a conglomeration of a bunch of different experts.
We have people from four different teams who have
all independently worked on IP in
this space and we're bringing them all
together to build something really cool.
NICK SIMONS: I want to thank
Shelley Mujtaba and
Roland Ruiters-Christou
from Autodesk,
Bruce Engelman from Hexagon,
Faith Allington from
the Whiteboard Team and Taylor Williams and
Tyler Butler from the Fluid Framework Team
for talking to us today.
If you're interested in anything you've seen,
please follow the links on the screen.
Thank you.