Wix Platform
A new way to build applications for the Wix Editor and extend the Wix ecosystem, using native Editor components and relying on predefined behaviors and abilities
To comply with my confidentiality agreement, I have omitted some information in this case study.
www.wix.com
Background
Wix: a DIY, drag and drop website builder.
The Editor: Wix’s core product. Other than the Editor itself, Wix has teams working on many applications and business solutions for Wix’s users.
In the Editor, a user can have applications. Applications can be different: some built by Wix and some by 3rd party developers. Some are big, like Wix Stores which includes several pages, databases and components, and some are small, like a single component “paypal button”. Each component or App in Wix has main actions, on stage indications (type of bounding box, labels), panels and a certain set of behaviors.
For example: product gallery page and cart component.
The Platform Team & My Role
Up until the Platform project, applications were running inside an iframe and were completely separated from the Editor. This meant every team (3rd party developers or Wix teams) had to develop everything from scratch - nothing could be reused.
We wanted to allow developers to build inside the Editor using native Editor components and panels and relying on predefined behaviors and abilities.
I joined the team in a very early stage, replacing the designer who started the project, and was working with several PMs and developers on setting up the infrastructure of this project.
Goals
We had several goals for this project:
- Improve speed and performance
- Speed up development by allowing reuse of components and behaviors
- Better SEO
- Create a consistent experience for both Wix Users and Users-of-Users
- Make every element fully customizable (users can’t control items inside the iframe)
Our Users
Application Developers
Developers in Wix, working on Editor Apps + 3rd party developers with Apps in the App Market
Wix Users
Anyone installing the App on their site, designing it in the Editor or managing it in the back office.
User-of-User
Site visitors who are using the App (eg, filling up the contact form or buying new sunglasses)
The Process
I was working together with PM’s and developers on defining the rules for this new type of applications; defining missing features; prioritizing and designing those features; creating the appropriate documentation.
I was also responsible for meeting with UX designers and PM’s from the other teams to help them migrate their apps - guiding them about the Platform, the Editor Design System and the Editor UX guidelines; reviewing their work; creating processes for working together and also gathering requirements from them to see how those can fit in with our own roadmap.
Research
I wanted to check what types of apps we have, how the development process looks for developers, how apps are being used by our users and how other app builders approach this issue. This involved:
- Talking to other teams in Wix working on applications, and also the App Market team, which is incharge of 3rd party App developers.
- Gathering data from BI and Support.
- Understanding how the communication between the Editor and the apps works, the problems and the limitations.
Prototypes
Early into the process, we created a few prototypes, some in Invision or even paper, and some with the help of the prototyper on our team, to feel the behaviors we were debating about. We tested them out simply by showing them to the other teams - who were, effectively, our potential users.
Platform Rules & Application Widget
We started with defining the rules - what the application can or can’t override - actions, panel parts, behavior on stage. Then, we needed to define how the applications will be added to the site. We created a new “Application Widget” that has it’s own set of indications and behaviors and “knows” how to work with the elements inside and with the app logic.
The biggest problem we had to solve is how - and should we? - explain to the user this is an app and not a regular component.
There were a lot of questions we had to answer.
How will main actions work? How will the developer decide which actions are available? How will they name and label the components? How will the developer define if an element can be rotated or resized? Should he developer be able to not link to a “help” section? What will be accessible through right click menu?
What happens when the user clicks on an element inside an App (something that wasn’t possible before)? What happens if the user tries to drag an element outside the App Widget or move that element to a different page using cut > paste?
How will the user know which element belongs to the app and which doesn’t? For example, a regular input field can look the same as the input fields inside the app, but the app doesn’t know what they are. How will the user add new elements the app can work with?
How will this work with Corvid (a way to write code inside Wix to enhance the sites)? For example: there is a set of actions that works with the app - and another set that works with the container itself, and therefore 2 IDs. We had to decide if we expose both or create a single ID and a new way for developers to get to the different actions.
Main Takeways
Today, a lot of Wix apps are in the process of moving to the new Platform. The first full-platform app is in the Editor (Wix Forms) and we are watching how our users are interacting with it.
My main take away from this project is to remember to solve the right problems. We have spent a lot of time trying to come up with the best way to show our users the difference between an App and a component. Eventually, we decided to try to go without any visual indications (just a different behavior), with the assumption we can always add an indication if we do see there is a problem. After watching the users using the applications, we’ve realized the different behavior is, indeed, enough and any visual indications would only add clutter and confusion.