Scott's Portfolio

Github Profile LinkedIn Profile Go home

Quick Mocks - Challenges

Back to original article here

Saving Pages

By far the hardest challenge with Quick Mocks (QM) was saving and re-editing mocks. it was the critical feature necessary for widespread adoption. My dream was to save websites as a single file which could be shared and easily re-edited. In the end it wasn’t technically hard, but it took a long time to perfect.

Websites are dynamic and multi-content beasts. Often they have dozens of external images, stylesheets, Iframes, you name it.

How can we save these? Is this even possible?
- Me at the time

Try right click and save a website. You’ll see it creates a directory with dozens of files and images. And when you open it? Often the styling is broken and un-usable for mocks.

Thankfully developers are awesome and I was able to achieve my dream in the end. Some challenges I faced:

Video Save and compression into a single file.

Designing for Designers

Intuitive UX can be hard to design. It’s even harder when there’s no UI! QM was originally made for devs but quickly found use by more visual users - like designers. All functionality was hidden behind keyboard shortcuts which made it hard for new and graphically inclined users. Looking back, this is likely what limited its adoption further.

Many steps were taken to improve usability, for example:

  1. Created an extensive documentation page to list all commands and functionality. The problem is that most people don’t want to read.
  2. Prettied the documentation page and added gifs for every action to provide visual examples.
  3. Created a playground page which users could use to experiment and practice their skills in a friendly environment. All gifs used the ‘playground’ in order to provide a direct and reproducible reference.

Had I continued with QM development I would have liked to build a UI to make selection and actioning more visual. Subsequent tools such a Visbug implement this well.

Quick Mocks features page QM feature search and explanation page.

Other challenges involved getting users to think about a website’s structure. Block elements typically display vertically, but inline ones horizontally. The sibling selector action used the left/right arrows, so if elements were displayed vertically, then pressing right to select the element underneath was confusing.

A UI might have helped solve the problem, but I resorted to running small QM sessions to users who wanted it.


The idea for QM was that it had to function on any webpage and be ready at any time. To achieve this, QM had to sit silently until a user selected or actioned something.

To achieve the ALT + Click select action for example, a ‘click’ event needs to be set on an element or parent element.

“Do we set an event to EVERY element on the page?” Dynamic elements won’t work + this will likely impact performance.

“Do we set one on the body element and find the target on click?” Elements with existing click events will run their action first (i.e. button and links).

What did I do? Added click events as the mouse hovers into elements. This worked for all elements AND the event could be placed first in the event queue to override buttons etc.

What’s the problem you ask? Over time I noticed that all webpages started to slow down the more I used them. Click events were being added to thousands of elements and each click caused a significant performance impact. Not good!

How did I fix it? Clean up! Not only did I have to add click events, I needed to remove old ones when leaving elements.

QM had lots of impact potential as it ran on all websites. Lots of work like this was made to ensure QM was completely invisible until needed.

The feature that never was

The number one requested feature? Undo. This was the biggest feature that I never got to work on.

QM can be very dynamic. Users can select an element, the element’s parent, that element’s parent, then perform actions on all three at once. Dealing with nested data types like this is uncommon. The implementation always seemed tricky and I departed the company before being able to implement it.

The Memento algorithm saves and restore states to implement undo. Websites can be LARGE though, do you really want to save a whole copy of the HTML each time you duplicate a button? If not the entire website, how would one save the state of multiple potentially nested elements?

Something akin to the Command Pattern seemed more suitable. One solution that might have worked is as follows:

Some problems:

All-in-all a delicious problem, it would have been great to solve!

Back to original article here