An intuitive development workflow with Shopify Desktop

A concept for my summer 2016 internship application

Designing a solid WYSIWYG editor is challenging. They’re a lot like tablets in the sense that they aim to be productive, but at the cost of some power and utility.

This challenge is to show that — by using stateful views — we can have a product that offers broad utility while still being simple to use.

Research & Hypothesis

Shopify is a retail operating system that specifically appeals to physical retail stores and pop-up shops. Their platform is unique in the way they connect merchants with customers in more ways than most other e-commerce platforms. A lot of Shopify users switch over from platforms like Squarespace, Bigcommerce and Volusion. This means they value tools that are highly visual, but with enough control and customizability.

By looking through the Shopify App Store I noticed that the top apps were marketing related; merchants really wanted to build their online reach from a non-technical standpoint. Apps that catered to SEO, product/ sales, reports, and notifications were especially popular.

After reading the marketing site, my assumption was that merchants wanted to feel as integrated with their online business and physical store as possible. They valued a variety of tools that worked together, were extensible, but also un-opinionated.

I wanted to build a concept that was new, but still consistent with Shopify’s approach as a CMS. As a result I brainstormed a flow where the merchant could manage their entire store, including their theme, from both a visual and “content-first” standpoint.

While tempting — replicating Shopify’s core features adds an un-needed layer of abstraction. The nature of being a desktop tool means that it’s less accessible than web/ mobile. For example, Shopify Mobile manages sales really conveniently but lacks the screen estate to edit themes. Shopify Desktop is stationary and less accessible, but those who use it will appreciate the control it offers.

This means that while you can edit storefront-related data by adding a new product or editing blog posts, you shouldn’t be able to manage inventory or sales. However, it should still integrate with the merchant’s store through instant OSx notifications (E.g. Whenever a sale is made.). Clicking the notification will redirect you to your Shopify Admin where you can take further action.

With these goals in mind I tried to tackle 3 main problems in the theme-editing workflow.

Problem #1: Too much navigation


Shopify is a “content first” interface that makes it easy to edit product, inventory and customer data. However, there’s too much un-needed navigation when I’m later making changes to my storefront.

When I’ve just added a new product and want to change how it looks on my store, I need to navigate three views before getting to the theme editor. When I finally reach the theme editor, I’m able to edit the presentation but no longer the content. As a result I end up constantly switching between two tabs when my objective in both tabs is the same: to modify the product page.

Once I’m at the theme editor I must navigate within a text menu to choose my desired action. For small tweaks, this can feel unproductive.

Theme editor sidebar categories

Suggestion: Offer Stateful Constraints

Instead of having edit/preview actions on different panes — which can get messy — we can keep them on a single pane and afford different actions based on state.

Shopify Desktop has two main modes: edit and preview mode. During preview mode, the designer can navigate the site like a visitor. By pressing the option key, edit mode is enabled and the current page becomes fully editable.

Edit/preview mode

This is intuitive because a switch in state is easier to understand than switching between different contexts.


Problem #2: Visual editors are often messy

While visual editors excel at making changes to content, they can unfortunately clutter screen estate. When each element can take on five different colors, backgrounds, behaviors, and shapes, it can feel overwhelming.

Unnecessary tradeoffs

SquareSpace opens actions in drop downs when an element is hovered over, but this often clutters the preview pane. When the editor always assumes edit mode, too many actions can pop up. It’s also easy to close the dropdown by mistake since it’s size is so small; when testing Facebook reactions users would often close the reactions popup because their thumbs were fidgety. And since a mouse has smaller cursors w/higher sensitivity, we can assume the same annoyance occurs on desktop.

Common solutions like making the dropdown larger also takes up more screen estate; adding a delay on mouse-out makes it feel less unresponsive. In a lose-lose situation, it’s better to rethink a different approach.

Suggestion: Separating Actions from the Preview Pane

When in edit mode, clicking on an element opens up its Liquid options as actions in a sidebar pane. This frees up space from the preview pane while still showing relevant options. A fixed-width sidebar allows itself to update while staying in place, so the user doesn’t feel like they are switching contexts.

Liquid actionbar

Problem #3: Utility is too opinionated for a standard tool

The core Shopify platform intends to offer necessity tools that appeal to all audiences, like managing orders, sales reports, and products. The visual editor and code editor are niche tools because they accomplish the same thing but in different degrees, each appealing to different audiences (non-technical vs technical).

But modifying themes is an essential feature, so a better approach would be to have same interface adapt to different audiences; kind of like how Slack is primarily used as a chat tool, but can also keep your team in sync with iCal reminders, version control or IFTTT task dispatchers.

Simply put, desktop apps offer a sense of belonging, because they’re closely integrated with the user’s other applications.

Suggestion: Offer Utility to Both Technical & Non-technical Users

Integrates with your current code editor

With one click, a designer can open the preview pane’s current Liquid template in their favourite text editor. This means they can make changes to their source code while getting live feedback in the preview pane — without any environment setup.

It’s no longer an issue if the designer isn’t familiar with the theme’s file structure since they can navigate the site like a visitor, rather than by random-file-name.liquid. Also, they get to use the tools they’re already familiar with; hence complementing and not replacing the user’s workflow.

Lastly, it’s an option that’s always available but not forced upon. Different users can use this app in whichever way is most productive for them.

Technical challenges

The toughest challenge was implementing the preview pane. At first I linked the iFrame to the user’s Shopify site, but because iFrames are secured, I wasn’t able to control it’s contents from different domains. Also, Shopify trial users had a private, password-protected site, so I couldn’t even view it without logging in. I couldn’t use the Shopify API, since it returned an unmodified version of the theme (this will pose sync issues later). Also, Liquid objects didn’t hold any merchant data (products, blog posts, etc).

The only way to load store data was to reverse engineer the contents of the Theme from the store. To bypass auth I used a PhantomJS instance to sign-in and pass the proxied theme for the client to render. I also had to isolate the theme’s styles/scripts in the preview pane from the rest of the app, so I hosted the proxied theme on another route and contained it within the iFrame in the preview component.

To interact within the iFrame and the rest of the app I ended up syncing states with Mongo via ReactMeteorData.

My Git commits when I got it working

Final results:

  • theme development is more easier and more productive
  • utility for both developers and non-technical users, but not opinionated
  • live preview your theme without refreshing an iFrame

Try it out

Shopify Desktop was built with Meteor & React, packaged in Electron, and scaffolded while testing Comet. You can view the code on Github.

I don’t work at Shopify; I’m just a mere mortal who wants to become a deeper thinker by writing more. This was purely built off my own research and intuition with WYSIWYG tools.

Update: I’m now at Shopify full time on the Patterns team!