Arcol logo

Book a demo

Blog

Customer Stories

Values

Follow us

Careers

Arcol logo

Blog

Customer Stories

Values

Follow us

Careers

Book a demo

Arcol logo

Multiplayer Views

The iceberg problem

The iceberg problem

There are many interesting problems to solve when designing a 3d modeling tool. Often the problems are iceberg problems - they seem simple, but there’s a lot of complexity under the surface. Model views are absolutely an iceberg problem. We’ve taken a few cracks at it over the course of building Arcol, and it’s a problem we still think about today.

What are model views?

In the simplest definition model views are exactly that: views of a model. In Arcol, these views contain multiple settings:

  • Camera position and orientation

  • Camera type (perspective vs orthographic)

  • Shadow time/day

  • Design option visibility

  • Graphic style

  • Label visibility

When a user navigates to a view, the above settings for that view are applied. This allows users to create different views for vantage points, options, shadow studies, diagrams, or documentation all from the same model. All the views are automatically updated as well when the model geometry changes.

Why do model views matter?

There are 2 main use cases for model views: navigation and presentation. While modeling you are typically alternating between 3D, floor plan, and site plan views, and being able to navigate between these views quickly makes modeling much faster. When it comes to presenting your work, views are what make it possible to produce multiple sheets. Another way of looking at these use cases is that navigation is for you - it’s how you get around the model while designing. Presentation is for others - the views are meant to communicate something. The overlap of these use cases is what makes multiplayer views an interesting problem to design for.

What is multiplayer?

One of the main things that sets Arcol apart from other tools is that everything is real-time. There is no manual syncing or saving - everyone in the projects sees all changes being made at the exact moment they’re made. We call this “multiplayer” (a term commonly used in modern tools). The benefit of multiplayer is that nobody is ever working in an out-of-date doc and there are no surprises with work being overridden. However, multiplayer can be a tricky thing to get right, and that’s what we’ll be exploring in the sections below.

Considerations in designing views

Okay, let’s get back to talking about views. For views to be useful a user needs to be able to:

  1. Create views

  2. Navigate to created views

  3. Update views (eg. adjust the camera position)

  4. Delete views that are no longer needed

These requirements seem straightforward at a glance, but it gets more complicated when you dig deeper in a multiplayer context. For example, if one user is in a view and another user deletes it, what should happen? Or if one user is in a view and another user updates that view, what should happen?

Don't be such a drag

For the example of view deletion, our approach is simple - if a view you are in gets deleted, you are redirected to another view. This of course has its own complications (eg. which view?), but it’s enough of an edge case that we’re happy with the current solution. We’re able to mitigate this situation by showing user avatars beside the view name that they are currently in, giving users more information about where their co-designers are in the model.

Things start to get interesting with the example of view updates. First let’s imagine a very bad multiplayer experience. You and I are both in the same view in a project in Arcol. I start orbiting the camera, which changes the view…and you get the change in real-time, which causes the camera to orbit for you as well. Not only would this would be confusing, but it could completely ruin a presentation or client discussion. In addition, orbiting the camera probably shouldn’t automatically update the view…you may be orbiting to see something and then want to return to the original view.

Based on this bad experience, 2 requirements are clear:

  1. Changing a view should not cause that view to immediately change for other users in the projects

  2. A user should be able to temporarily change a view and then “reset” it

These requirements drive Arcol’s view feature. When a user changes a view, the UI notifies them that changes have been made, and those changes are local (ie. other users don’t get those changes). The user can then choose to either reset the view or save the changes, overriding the previous defaults for that view. If the changes are saved, it is at that moment that other users in the project see that changes have been made, and if they reset the view they will now be seeing the latest settings for that view.

Fourth time's the charm?

We’ve taken a few cracks at the UI for model views. As mentioned above, the user needs to clearly know when a view has been changed and then be presented with the option to either reset or save the changes.

V1 - Buttons in bottom center of canvas

There are many interesting problems to solve when designing a 3d modeling tool. Often the problems are iceberg problems - they seem simple, but there’s a lot of complexity under the surface. Model views are absolutely an iceberg problem. We’ve taken a few cracks at it over the course of building Arcol, and it’s a problem we still think about today.

What are model views?

In the simplest definition model views are exactly that: views of a model. In Arcol, these views contain multiple settings:

  • Camera position and orientation

  • Camera type (perspective vs orthographic)

  • Shadow time/day

  • Graphic style

  • Label visibility

When a user navigates to a view, the above settings for that view are applied. This allows users to create different views for vantage points, shadow studies, diagrams, or documentation all from the same model. All the views are automatically updated as well when the model geometry changes.


Why do model views matter?

There are 2 main use cases for model views: navigation and presentation. While modeling you are typically alternating between 3D, floor plan, and site plan views, and being able to navigate between these views quickly makes modeling much faster. When it comes to presenting your work, views are what make it possible to produce multiple sheets. Another way of looking at these use cases is that navigation is for you - it’s how you get around the model while designing. Presentation is for others - the views are meant to communicate something. The overlap of these use cases is what makes multiplayer views an interesting problem to design for.


What is multiplayer?

One of the main things that sets Arcol apart from other tools is that everything is real-time. There is no manual syncing or saving - everyone in the projects sees all changes being made at the exact moment they’re made. We call this “multiplayer” (a term commonly used in modern tools). The benefit of multiplayer is that nobody is ever working in an out-of-date doc and there are no surprises with work being overridden. However, multiplayer can be a tricky thing to get right, and that’s what we’ll be exploring in the sections below.


Considerations in designing views

Okay, let’s get back to talking about views. For views to be useful a user needs to be able to:

  1. Create views

  2. Navigate to created views

  3. Update views (eg. adjust the camera position)

  4. Delete views that are no longer needed

These requirements seem straightforward at a glance, but it gets more complicated when you dig deeper in a multiplayer context. For example, if one user is in a view and another user deletes it, what should happen? Or if one user is in a view and another user updates that view, what should happen?


Don't be such a drag

For the example of view deletion, our approach is simple - if a view you are in gets deleted, you are redirected to another view. This of course has its own complications (eg. which view?), but it’s enough of an edge case that we’re happy with the current solution. We’re able to mitigate this situation by showing user avatars beside the view name that they are currently in, giving users more information about where their co-designers are in the model.

Things start to get interesting with the example of view updates. First let’s imagine a very bad multiplayer experience. You and I are both in the same view in a project in Arcol. I start orbiting the camera, which changes the view…and you get the change in real-time, which causes the camera to orbit for you as well. Not only would this would be confusing, but it could completely ruin a presentation or client discussion. In addition, orbiting the camera probably shouldn’t automatically update the view…you may be orbiting to see something and then want to return to the original view.

Based on this bad experience, 2 requirements are clear:

  1. Changing a view should not cause that view to immediately change for other users in the projects

  2. A user should be able to temporarily change a view and then “reset” it

These requirements drive Arcol’s view feature. When a user changes a view, the UI notifies them that changes have been made, and those changes are local (ie. other users don’t get those changes). The user can then choose to either reset the view or save the changes, overriding the previous defaults for that view. If the changes are saved, it is at that moment that other users in the project see that changes have been made, and if they reset the view they will now be seeing the latest settings for that view.

Fourth time's the charm?

We’ve taken a few cracks at the UI for model views. As mentioned above, the user needs to clearly know when a view has been changed and then be presented with the option to either reset or save the changes.

V1 - Buttons in bottom center of canvas

There are many interesting problems to solve when designing a 3d modeling tool. Often the problems are iceberg problems - they seem simple, but there’s a lot of complexity under the surface. Model views are absolutely an iceberg problem. We’ve taken a few cracks at it over the course of building Arcol, and it’s a problem we still think about today.

What are model views?

In the simplest definition model views are exactly that: views of a model. In Arcol, these views contain multiple settings:

  • Camera position and orientation

  • Camera type (perspective vs orthographic)

  • Shadow time/day

  • Graphic style

  • Label visibility

When a user navigates to a view, the above settings for that view are applied. This allows users to create different views for vantage points, shadow studies, diagrams, or documentation all from the same model. All the views are automatically updated as well when the model geometry changes.


Why do model views matter?

There are 2 main use cases for model views: navigation and presentation. While modeling you are typically alternating between 3D, floor plan, and site plan views, and being able to navigate between these views quickly makes modeling much faster. When it comes to presenting your work, views are what make it possible to produce multiple sheets. Another way of looking at these use cases is that navigation is for you - it’s how you get around the model while designing. Presentation is for others - the views are meant to communicate something. The overlap of these use cases is what makes multiplayer views an interesting problem to design for.


What is multiplayer?

One of the main things that sets Arcol apart from other tools is that everything is real-time. There is no manual syncing or saving - everyone in the projects sees all changes being made at the exact moment they’re made. We call this “multiplayer” (a term commonly used in modern tools). The benefit of multiplayer is that nobody is ever working in an out-of-date doc and there are no surprises with work being overridden. However, multiplayer can be a tricky thing to get right, and that’s what we’ll be exploring in the sections below.


Considerations in designing views

Okay, let’s get back to talking about views. For views to be useful a user needs to be able to:

  1. Create views

  2. Navigate to created views

  3. Update views (eg. adjust the camera position)

  4. Delete views that are no longer needed

These requirements seem straightforward at a glance, but it gets more complicated when you dig deeper in a multiplayer context. For example, if one user is in a view and another user deletes it, what should happen? Or if one user is in a view and another user updates that view, what should happen?


Don't be such a drag

For the example of view deletion, our approach is simple - if a view you are in gets deleted, you are redirected to another view. This of course has its own complications (eg. which view?), but it’s enough of an edge case that we’re happy with the current solution. We’re able to mitigate this situation by showing user avatars beside the view name that they are currently in, giving users more information about where their co-designers are in the model.

Things start to get interesting with the example of view updates. First let’s imagine a very bad multiplayer experience. You and I are both in the same view in a project in Arcol. I start orbiting the camera, which changes the view…and you get the change in real-time, which causes the camera to orbit for you as well. Not only would this would be confusing, but it could completely ruin a presentation or client discussion. In addition, orbiting the camera probably shouldn’t automatically update the view…you may be orbiting to see something and then want to return to the original view.

Based on this bad experience, 2 requirements are clear:

  1. Changing a view should not cause that view to immediately change for other users in the projects

  2. A user should be able to temporarily change a view and then “reset” it

These requirements drive Arcol’s view feature. When a user changes a view, the UI notifies them that changes have been made, and those changes are local (ie. other users don’t get those changes). The user can then choose to either reset the view or save the changes, overriding the previous defaults for that view. If the changes are saved, it is at that moment that other users in the project see that changes have been made, and if they reset the view they will now be seeing the latest settings for that view.

Fourth time's the charm?

We’ve taken a few cracks at the UI for model views. As mentioned above, the user needs to clearly know when a view has been changed and then be presented with the option to either reset or save the changes.

V1 - Buttons in bottom center of canvas

While it is very important to be able to save views for documentation, most of your time in Arcol is spent modeling in non-default view orientations. This means that the view save/reset buttons are essentially always visible, and having them displayed front and center gets annoying very quickly.

V2- Buttons in right sidebar

I couldn’t dig back far enough to get a screenshot of the old UI so this is a re-creation, but I believe this was where our view buttons were when we did our preview release in August of 2023. This design had the opposite problem of the first - nobody noticed it. The design is also based on the View tab being the default tab in the right sidebar; we very quickly made Metrics the default tab since that is what is most important to reference while modeling. So, on we went to V3.

V3 - Show indicator beside view name

A big reason why nobody noticed the buttons in V2 was their placement - buttons appearing in a section header on the right amidst a bunch of other inputs and text was too hidden. The contrast between buttons vs no buttons just wasn’t enough. This design moved the buttons to a context menu (where you also do other common actions like renaming or deleting a view) and opted for a yellow ring to indicate that a view has changed. There were a few problems with this design:

  1. The yellow ring was too small to be very noticeable. At that point we used the dot to indicate which view you were in, so that addition of a small yellow ring around the dot was too subtle.

  2. We showed a tooltip when hovering the yellow ring, but it wasn’t obvious what the ring meant.

  3. We intend to allow multiple views to be changed without being saved, allowing a user have their own “working views” in a session. This would mean showing a yellow ring beside multiple view names…which wouldn’t look great.

V4 - Show buttons in top right of canvas

This is the current design for view buttons in Arcol. Here’s why we like it (so far):

  1. Easily discoverable, but out of the way → The buttons now show in the top right of the canvas, which puts it closer to actions that affect views like shadows, graphic styles, and label visibility. The buttons are still almost always visible but they don’t feel too obtrusive because they’re tucked in a corner with the North arrow, and because they’re on the canvas they’re very easy to spot.

  2. Better tooltip → We changed the selection UI for views in the left sidebar list from the dot to a background color change. Now the dot is used to further indicate that a view has changed (in addition to showing the buttons), and when you click on the dot a tooltip is show explaining how views work. The dot also has hover and click visuals like an actual button, which feels better than just always showing a tooltip on hover.

  3. Scalable → Changing the selection UI also sets us up for having dots shown on multiple views that have changed, which can act like a notification on views you are not currently in. The small unlock here was adjusting from the dot indicating that a view is active to the dot indicating that a view has been changed.

Final thoughts

Model views matter! Multiplayer matters! At Arcol we think about this stuff constantly and obsessively. Sometimes we get things feeling good on the first time around, but most features require multiple iterations. Stay tuned for V5/6/7/… of our view save/reset buttons. What do you think of V4? How could it be better? Drop us a comment, we’d love your feedback.

If you’d like to give Arcol a try, head to arcol.io/demo to book a demo.

— Mike + the Arcol team

Enjoyed this post?
Join our newsletter for stories, insights and features on the future of AEC

Join our newsletter

Join our newsletter