Earlier this year the start-up Elexir reached out to us with their unique vision of creating a more sustainable car. They built a highly customizable and extendable shared car, trying to attain the same experience as of owned, personalised cars. They achieved this by developing a completely new underlying software architecture. By using an open-source software approach they are enabling everybody to contribute to its system and giving customers the ability to replace and add hardware elements and benefit from further software improvements.
Kick Off
I got hooked by their idea right off the bat. At the time we joined in on the project, Elexir had already established their software architecture. Envisioning a new car HMI from scratch seemed like one of the coolest projects I could have imagined. Also, they already set up everything to have full control over every hardware part in the car! Having all those capabilities at the palm of their hand they needed a visual representation to convince stakeholders.
Why Protopie?
With an emphasis on hardware integration and personalisation, we knew we needed an advanced design software, one that went far beyond the limits of static screens. We wanted to create a highly sophisticated prototype, which gives users a good impression of our ideas, allows us to iterate quickly and come up with a solution in an extremely short timeframe. Having worked with ProtoPie before and thus knowing what the software can do brought us directly to the conclusion, that this is the best tool to get the job done. It was just the perfect project to take full use out of ProtoPie’s capabilities in terms of real-time data connection, multiple hardware devices and screens. To meet our deadline, we also needed the possibility to work together at the same time. By making use of ProtoPie’s advanced component features we could develop elements further to use or work on pieces separately and then settle them together into the final piece.
Design
“We did not want to reinvent the wheel” (I guess in this context I can make use of this cheesy pun). We tried to avoid overwhelming the user, by using familiar interaction mechanisms and only displaying necessary information for each use case to generate a lean, minimalistic feeling. On the other hand, we wanted to increase user guidance through three dimensional visualisations and direct feedback. The idea of using visual representations of the real-life objects to manipulate and control a wide range of functions fascinated us and really put things into motion. How cool is it to change the seat position on screen, while feeling it move underneath you?
Workflow
Even at scale, which eventually happens when thinking of modern cars, we tried to stay lean. We took a continuous and additive approach to introducing new components to our library and tried to make them extensible and reusable, so they could be adopted to wider range of use. To achieve this, we took the atomic approach, building small components which eventually are getting nested inside bigger organisms.
To ensure maintainability we were using multiple files for different parts and output devices of the software, each one linked to a global library providing the same components. Instead of spending days on designing static screen designs, we defined a visual language together with Elexir, set up a couple of basic components to test it and moved directly into ProtoPie. Our Workflow from this point was divided into three phases of development:
- Visual design
- Connection with real-time data by using the OBD port
- Integration into the real product, testing and iterating on it
Prototyping has always been a crucial part of my workflow, it helps me to visualize, test and iterate ideas quickly without wasting too much time. Throughout the years I have tested and used a wide range of tools, often resulting in frustration due to technical limitations or a lack of functionality. ProtoPie’s advanced component features allow me to go far beyond just transitioning between more or less static screens. Having a dedicated component library as a single source of truth, building UI components in isolation while still being able to communicate between them, gives me the flexibility I haven’t found anywhere else yet. In addition, being able to test everything directly on the final product using the real hardware was an absolute game changer for us!
Conclusion and Quick Tips
We wanted to showcase a three-dimensional representation of the car and its components for the navigation system as well as for the settings. Using videos or static images wouldn’t have been sufficient, as we needed a lot more flexibility to achieve our needs. While there is no way to integrate three-dimensional data into ProtoPie right now, with its powerful features like variables and functions there is nearly nothing you can’t find a solution for. And apart from that I just love the ProtoPie community. With a quick research I found others who faced the same problem and already came up with solutions for it. (Big thanks @Khonok Lee)
I really like the trigger and response system of ProtoPie. With features like chains, if-conditions, send/response functions and Lottie integration, there is nothing more I could wish for. But things can get messy real quick. I highly recommend everybody to name their layers and further structure designs by splitting things up into components. Especially when working on bigger scopes like in this case, I would have been completely lost without doing so.
Performance is usually not a big issue in ProtoPie. It seems to handle everything I throw at it just fine. At least if you follow a couple of simple rules:
- Don’t integrate images in a larger resolution than they will be displayed.
- Try to use SVGs as much as possible. As well as Lottie files instead of videos.
Except of using variables to store and communicate data, they can also come in handy for debugging. Often, I don’t know what exactly is happening. To get a better understanding, I create a variable and bind the corresponding value I want to read out to it.
