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.
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).
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.
Once a rough roadmap was created, I jumped right into some fat-marker sketching (from Jason Fried).
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.
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.
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.
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.
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:
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.