A-Frame GUI

This project started at a WebVR NY hackathon. The nature of a hackathon is that they’re very time sensitive. This one span a weekend. My teammates Roland Dubois (UI developer), Leonardo Malave (developer) and I came together with similar interests in WebVR interfaces; specifically if we can take Graphical User Interface (GUI) elements from the 2D web and translate them for VR. We asked questions like; what is currently available as far as frameworks for developers and designers to help them create WebVR experiences? What needs can be addressed and how can we create something designers, developers and users all benefit? Much of the research done was to compile existing findings and techniques to help define what we were going to make.

DEFINE

---

Goals & Focus

One thing we knew to be a requirement for ourselves was for our project to be to scalable; for it to work monoscopically and stereoscopically, on devices ranging from mobile to desktop, in contexts ranging from seated 180° Field of View (FOV) on a 3 Degrees of Freedom (DOF) device with gaze or pointer input to a standing 6DOF room-scale experiences with gesture input. A-Frame (from Mozilla) was an obvious choice for us to use, build for and center our focus on as it is very accessible to learn and quickly creating things for WebVR experiences while also allowing for this progressive enhancement.

• 
• 
• 

Another focus was comfort and accessibility. The web has excellent standards and practices to reference. Looking at other WebVR GUI frameworks available at the time we wanted to bridge the gap in providing something familiar to web designers & developers while using the same best practices found on the web to create an interface framework.

Under a short timeframe we decided to only focus on the seated gazed controlled setting for a user in VR but to also build a foundation for possible further VR user settings like 6DOF and different input devices.

Amper Music was one of the sponsors of the hackathon and we decided to use their API for generating original music as a demonstration of our framework.

RESEARCH

---

Comfort

With comfort in mind we wanted the framework to be mostly agnostic in regards to styling & layout but have some defaults to ensure a comfortable experience.

When it comes to establishing good sizing for typography, button hit size and layout we all wanted to explore Google’s established measurement unit of Distance Independant Millimeters (dmm) for a seated VR experience to help design our interface. There is some research online to look to for comfortable readability in VR as a guideline, though one should always constantly check and inevitably user test with a diverse group of people.

It became apparent early on that our framework needed to adhere to similar accessibility standards that the traditional web has. When it comes to accessibility ensuring comfort means text is comfortable to read, interface is comfortable to use and the user can define their own parameters based on their needs.

Reticle Behavior

VR interface design has really just begun and I believe we are only beginning to scratch the surface of the potential interactive behaviors VR affords in any context; from seated to walking around a room or from gaze only controls to gesture based VR input devices. That said, it was a hackathon and using a reticle is familiar and sound method for gazed inputs. I looked at reticle behavior across existing products and the corresponding tasks users preformed to decide on best practices for our project, common design patterns & interactions for us to use to create a foundation for a framework.

DESIGN

---

Wireframes & Comps

At a certain point we realized we were creeping in scope and decided to only focus on getting a solid foundation for the framework and creating the Amper music demo thus dropping another feature of in-VR GUI customization.

TiltBrush is a great tool for many things, one of which is quickly sketching ideas in 3D space and—in our case—guess what are some comfortable sizes and distances to use for the layout of our scene.

DEMO

---

Lessons Learned

I fortunately was apart of a team that valued comfort and accessibility but realized overall during the hackathon getting in VR and trying out your project continuously is unquestionable but surprisingly gets forgotten since we are on desktop or laptop screens currently to do most of our work. Game engines and other content creation tools are already or will be implementing in-VR design & development workspaces for immediate feedback. This seems more apparently needed for WebVR at the time of this writing.

Another note;—again fortunately not necessary for my team—a lesson I have ingrained in my skull is that if you are the sole UX designer for a VR project your primary focus is the comfort of your users. You have to be the loud mouth in the room making sure simulator sickness, eye strain or other physiological discomfort doesn’t creep up; doing usability testing with this is a must and the highest priority. That is your primary duty; hopefully everyone involved with the project is aware and knowledgeable on the design and technical factors but you as a UX Designer have to know the causes & design considerations the most.