What is Modelshare?

Modelshare.app is an easy way for anyone to upload a 3D environment, make adjustments, and share that environment with virtually anyone. Environments can be experienced on desktop/laptop, mobile, and VR headsets.

The idea for Modelshare came up when my brother (who is an interior designer) mentioned not having a quick and effective way to share his work with clients virtually. There are several products on the market that offer a solution to this problem. However, most of them force you into a particular ecosystem and/or demand a steep monthly subscription. Modelshare aims to fix this through self-hosting your 3D file, and keeping things simple. Modelshare is still very much in beta and many improvements are yet to come.

Demo of modelshare beta on different devices

Project Goals

Although the product goals were relatively straightforward and simple, the project goals were multifaceted. The months prior to developing Modelshare I decided that I wanted to become a more competent developer. In the past, I didn't venture too far outside of my design role and shied away from vanilla javascript and working with any sort of database.

When I decided to take on what became Modelshare I knew I wanted to use it as an experiment to work on my dev chops. I was already familiar with the webVR framework, aframe and figured it would be a good place to start given that it works seamlessly in the browser. Previously, I hadn't been able to take full advantage of aframe due to my lack of comprehensive vanilla javascript understanding.

Second to improving my overall developer skills I also wanted to try out some fun project strategies that I typically don't get a chance to do given the size of the projects I work on. I've been listening to a lot of Basecamp's co-founder, Jason Fried. Jason shares many ideas on product strategies online and in his books. One of the recent talks I heard from him was regarding his concept of going from breadboarding to fat-marker sketching, to crude prototypes (mentioned in this designbetter article).

The Plan

I started with a list, what is the barebones functionality that Modelshare needed day one? What were some of the pieces of functionality I would like to see in beta but could live without? What are the post-beta features I would like to implement? I find it very important to have a living document/list that keeps track of these items. Often times we get distracted implementing features that aren't necessary to ship the product. Having a place to document your ideas, plans, and findings can give you an assurance that the idea has been accounted while also keeping you focused.

I tend to keep all of my personal project notes and ideas in Notion, though I sometimes also utilize the product readme file.

An example of my lists created in Notion (I was originally calling this project "Enviroshare")

Once a rough roadmap was created, I jumped right into some fat-marker sketching (from Jason Fried).

15x speed timelapse of quick fat markering. The camera focuses part-way through, sorry about that. :D

Initial Prototype

Once I had a rough idea of the general layout and flow that I wanted to implement, I dove straight into creating a static prototype with real inputs and code. I started by heading over to the aframe documentation and implementing one of their boilerplate "hello world" environments. Secondly, I threw together a basic form that's absolute positioned above the aframe environment. The form included the inputs I listed that I deemed essential while creating my lists and sketches earlier.

A basic prototype created with aframe boilerplate and html inputs.

Functional Prototype

The next step was to get the previously created form and inputs to actually control the aframe environment. Luckily, aframe's documentation makes this pretty easy. Essentially each attribute of aframe environment I want to control is a variable that is tied to the value of the corresponding input field; these get updated each time there is a change to the fields. Eazy peezy. During this iteration, everything should be functional except for the saving ability since this will take some database configuring.

Demo of the functional prototype. Lighthouse model by Cotman Sam, Art by Catherine Unger

Database Prototype

In past projects, I never wanted to deal with databases. Something about them frightened me as a designer, they seemed to be the source of most frustrations with my developer counterparts. However, I wanted to use this project to conquer this fear.

At first glance, choosing and implementing a database seemed like a confusing task. I nearly decided to go an entirely different route with the product just to avoid the database. However, I found a great compromise called Sheety. Sheety is a service that allows you to turn a google sheet into an api endpoint. Sheety has since matured with lots of features but at the time it just allowed you to read from a google sheet similar to how you would read from a database; it was nearly perfect. All I had to do now was find a way that allows users to write to google spreadsheet without realizing it. Lo and behold, with enough hacking I reskinned and embedded a google form into Modelshare. Whew, whatta hack.. but it worked!

Obviously, this database hack isn't very scalable, especially if I were to ever save anything other than strings (objects for example). Using Sheety was a great step for me; it helped me get more familiar with using databases and APIs.

Saving an environment with database prototype Lighthouse model by Cotman Sam, Art by Catherine Unger

There are several hidden google form fields in Modelshare that help keep track of the user's position and rotation in the 3D environment. These fields are automatically updated through aframe and saved with the rest of the manually altered fields so that the user doesn't have to worry about them.

Loading an environment with database prototype. Lighthouse model by Cotman Sam, Art by Catherine Unger

As designers, I believe we have a habit of making sure every pixel is perfectly placed before we show anyone what we're working on. There is a lot of risk that accompanies this behavior; we can sink dozens of hours into a project before we even know if it's useful or addressing the correct issues. Instead, developing actual functioning prototypes like the ones pictured above can be a huge benefit. I was able to get the actual product in front of users super early in the process and get feedback before even thinking about the design. Another benefit here is motivation. It can be very demotivating if no one is using our work, but by developing a working prototype early in the process I get to hear how helpful the project is along the way!


Since I had already worked through some of the development of the product I wanted to keep the design for the beta version of Modelshare light and simple. While developing the prototypes I discovered (and documented) many features that I could implement in future versions. So, I knew I wanted the design to feel beta. I chose a simple color scheme and a single font-family (is it just me or do mono fonts seem to reflect a beta/prototype vibe?) for UI.

Keeping the UI simple and unopinionated allows for future versions to look entirely different without seeming like an entirely new product. Feel free to check out some of the early design work in the embedded figma doc below:

Modelshare Beta

To graduate from prototype to final beta version of Modelshare I knew I needed to implement a real database. Sheety was a godsend for the time being but after having such luck implementing it, I was motivated to dive further into database implementation. I also had run into some issues where I needed to save non-string items like objects. After some consideration and discussions with others, I decided using Google's Firebase database platform would suit Modelshare's needs quite well. On top of Firebase being quick and easy to set up, the platform would also allow me to set up user authentication and asset uploading/storage in future versions of Modelshare.

I continued to get the prototypes in the hands of users that could offer some feedback and feature suggestions. I was able to fit several of these options into the beta but ultimately wanted to wrap up the beta quickly and save further feature implementation for future versions.

At the time of writing Modelshare beta is live at modelshare.app.