This app was created alongside Silas Brumwell in 36 hours at the Detroit Masonic Temple during MHacks 8, and can be found here.
When we decided to work together, the one area we had in common was Android dev, so we decided to pursue that for MHacks. After talking about VR one night, we decided we wanted to do something with Google Cardboard, since it incorporated Android with VR. We decided that social media was a relatively novel idea to incorporate with these field, as people love to share the things that make them unique.
In mFrame, users are mainly defined by their rooms. Each user has a room that they can customize with pictures hanging on the walls, as well as defining the wallpaper, ceiling, and floor. From there, you can go to other people's rooms to see how they've set theirs up, and follow ones you like for quick access. mFrame's overarching goal is to allow people to express themselves in an entirely new way through the use of VR.
During our brainstorming, we came across A-Frame.io. This framework gives access to 3d objects as HTML elements, as well as hosting VR in the browser. Because of this, we were able to make mFrame multi-platform with ease. Silas mainly worked on front-end, setting up and drawing the rooms from user data, and Michael worked on the back-end of room data storage and social networking. We used Hackathon Starter as a simple shell for our initial account creation and website layout, and we used Pug as an HTML pre-processor. Our back-end runs on Node.js, Express.js, and mongoDB.
Neither of us were very fluent in JavaScript, or at integrating JavaScript with HTML/Pug, so we ran into trouble with getting data from some of our JavaScript, especially since A-Frame is relatively new and low on documentation. A-Frame objects behave slightly differently than regular HTML objects, which provided challenge as well. Some data we expected to be available from A-Frame objects was not actually available, causing us to have to cut features, such as dragging images around a room. In terms of back-end challenges, we had difficulty in keeping all of the route controllers straight, and managing the responses from our database requests. This, compounded with the issues of getting data in to our HTML, slowed our process.
At the beginning of the project, we developed the front-end and the back-end independently. When we merged the two it worked on the first attempt, which was awesome for us to be able to enter the VR room early on in development. We also managed to host the app early on, allowing some friends to help us beta test. We are very proud of the depth that we were able to accomplish in such a short amount of time, especially in VR development, a field of development that appears on the surface to be very difficult to get into.
A major takeaway from working on mFrame was learning the steps for developing full stack, as well as specific skills with A-Frame, Pug, and mongoDB. We also learned the importance of planning ahead, as we brainstormed and researched for multiple weeks beforehand. Without that planning we most likely would not have gotten a working app, or at least not one with all the features that we were able to accomplish.
For short-term goals, we have not spent much time on the design of the website so we will update the theme to look less mundane and to be more navigable. Additionally some minor bugs have shown up at various points that we can fix. Long-term, there are multiple features we could add. Rearranging images has been something we've wanted to do from the start, but we've been unsuccessful in implementing it through A-Frame so far. This is a major goal for the future. With this, we would also like to be able to have rooms with more images, and maybe scale said images to other sizes. Navigating to other rooms without leaving VR is something we also think would be amazing to add, but this is a far-off goal, as the challenges faced would be very difficult.