Rethinking the creative web: Part 2 — Designing Hopscotch
In early 2017, yiibu began an ambitious piece of work for a small group of Mozilla stakeholders. This project (which came to be known as Hopscotch by Firefox) was shelved in early 2018, but in the spirit of making the web a better place, we’d like to share some of the research, concepts, and future facing ideas, that led to the project.(Big thanks to Mozilla for allowing us to publish this).
In this, the second of three articles, we delve into the design of the product itself, the content it enabled users to create, and key behaviours related to sharing within social platforms and on the open web. You can also read Part 1 and Part 3.
Part 2 — Designing Hopscotch
In early 2017, Mozilla engaged a small team (consisting of ourselves, Steamclock Software, &Yet and Variable) to build an MVP of Hopscotch for Firefox:
…a creative toolkit, empowering people of any skill level to create and remix bite-sized, visually rich content for the open web using their mobile.
Before we discuss the product itself, let’s begin with an overview of the high level principles that informed the design.
The stars we steered by
From the onset, we foresaw Hopscotch aligning with two key use cases: the creation of original content, and the curation (which might include often personalizing and remixing) of content discovered on the web as users go about their day.
The content created with Hopscotch, and the tools used to do so, would need to feel inherently mobile — not as a gimmick, but to better align with user’s existing skills, mental models, and consumption patterns. To better guide the design, we therefore set out the following principles:
- Make meaning: Create tools to enable expression and clarification of intent — to create meaning for a user, and help them easily do the same for their audience.
- Assist chunking: Create opportunities to reduce noise, increase signal, make content easily digestible/browsable.
- Encourage flow: Reduce cognitive friction, make it enjoyable, but balanced. Be mindful of dark or addictive patterns that promote over-consumption.
- Promote agency: An environment that feels welcoming, adaptable, and open to diversity of use, workflow, and intent.
Translating this into a firm concept took a while, but after a bit of iteration, we ended up with a new visual storytelling format we called Stacks.
The design of stacks drew on a range of influences:
Conceptual: The mixtape era was a great source of inspiration, as an early embodiment of encapsulated acts of curation that could be further personalized, and universally shared.
Structural: It was hard not to also be drawn to Apple’s Hypercard, which provided simple tools to create small, interactive bundles of knowledge and utility (…also called ‘stacks’).
Visual: We were also greatly inspired by so-called “electric information age books” of the 1970s. These highly visual books leveraged graphic design, and the low cost medium of paperbacks to render complex topics about science, economics, and society more accessible to the masses.
Anatomy of a stack
A stack is a collection of tiny web pages (we call them cards) that combine to create a narrative or longer collection. Each stack begins with a cover, that introduces the content, and ends with a colophon that enables users to follow the stack and/or its author. On mobile, stacks are displayed full screen, and users swipe right and left to browse from card to card.
Users create stacks using the (initially iOS) Hopscotch client, but once shared, stacks can be viewed in any browser. This makes them available to users who haven’t downloaded the client, and permits sharing in a wide range of contexts — including within social apps, chat and messaging clients, productivity apps such as Slack, and by email.
Although simple in structure, stacks are quite versatile, and can be used to create a wide range of content. Our goal for launch, was to however focus on two use cases that enabled the creation of both one-off, and long-lived stacks.
One-off creation
- A single act of authorship. A (probably shorter) stack with a beginning, middle, and end. Published once and rarely/never updated.
- What people might create: visual essays, visual alternatives to a traditional newsletter, poems, fan fiction, comics, micro-fiction.
Long-lived curation
- Long-lived, (probably) topical stacks with periodic (i.e. daily/weekly) updates.
- What people might create: topical micro ‘blogs’, richer Tweestorms or more versatile Moments, event-specific publications (users had lots of suggestions here — including stacks to chronicle the planning/‘scenes from’/aftermath of a holiday, workshop, or wedding).
Included within the Hopscotch client were simple mechanisms to enable re-engagement with authors, and notification of updates to longer-lived stacks. While an author was free to create many stacks, and users could follow an author to receive all of them, they could instead choose to simply follow random stacks they found interesting. We hoped this would enable authors to experiment more liberally with content, while giving users the flexibility to choose both the volume, and type of content they preferred to see.
To better understand the true versatility of stacks, let’s now delve a bit further into the design and creative possibilities of the cards within them.
Anatomy of a card
Cards are tiny, rich media web ‘canvases’ that can contain multiple media types, including rich text, images, animated GIFs, video, a generic OpenGraph hyperlink object, a more user-customizable hyperlink object called a web clipping, and (eventually) stickers 😍.
Using the Hopscotch editor, users could combine these elements to create rich compositions that took advantage of the various editable areas of a card:
- An editable background that could contain a color, image, animated GIF, or video.
- Two flexible ‘panels’ floating above the background (i.e. on the z axis) whose height users could adjust by dragging a handle. Each panel could contain any one of our supported media formats.
As shown below, most media within a panel was also sensitive to the resizing of its parent container. For example, text would grow/shrink to fit its container, and OpenGraph objects would expand/collapse into new layouts — complete with stylistic micro-adaptations to improve legibility and ensure a more balanced layout.
Dragging panels wasn’t the only interaction that took advantage of the touchscreen. Where possible, we explored ways to leverage common gestural interactions in an effort to improve learnability, and imbue interactions with a bit of fun. As illustrated above, users could swipe to adjust text alignment, pinch/spread to resize text (including any inline emoji), and (not shown) do the same to adjust the size and position of images, animated GIFs, and (we eventually hoped) video.
This combination of tools, layouts, and media formats enabled users to easily create rich bite-sized nuggets of narrative that could easily pivot into even richer storytelling by embedding short videos, or linking to longer-form external media such as podcasts, PDF, and longer-form article.
The prototype below shows how this all came together (along with a few future-facing ideas, that we’ll discuss further in part 3).
PROTOTYPE NOTE: This is not a formal project artifact. It’s merely a quick prototype created to demonstrate a stack’s creative capabilities, and its behaviour within the browser. Please see the notes below for a few gotchas, and feel free to also fork the project on Glitch, or download the source on GitHub.
Stacks out in the world (social, and in the browser)
A truly unique aspect of Hopscotch was that — although content creation took place within a native app (and was to this end facilitated by iOS components) — the web remained a first class citizen of the overall product. While we hoped to enable similar degrees of creativity as tools such as Snapchat, Facebook Stories, or Musica.ly — unlike these tools — our output would not consist of a lone video artifact. Making this work wasn’t without it’s challenges (and could easily span an article of its own that would best be written the project’s web team at &Yet). For this reason, we will only provide a brief overview of key design principles that underpinned the functionality we aimed to enable.
Made for mobile
Within the Hopscotch client, a stack’s content was both crafted and rendered using native components. When viewed on the web however, it was pure HTML, CSS and JavaScrip, so would need to be lightweight, quick to load, and render well on a range of browsers and devices.
Made for sharing
As each card within a stack was imbued with its own creative intent, it was important that users be able to share not just the stack — but any card within it. We felt it was therefore important that artifacts representing that card (e.g. within social feeds) should also aim to represent the author’s intent. To enable this, the team used a headless browser to generate thumbnails of each and every card, which were then provided through OpenGraph on the web.
With social feeds sorted, the next challenge was to then ensure Stacks would be equally representative of user intent when consumed within 3rd party app web views.
Fluid, but not responsive
The hard constraints of our card based design proved both a blessing and a curse.
- Cards were in effect, tiny fragments of web pages — with app-like characteristics.
- But unlike physical cards, ours would never have a fixed size, or aspect ratio.
- And unlike typical web pages, they would also never vertically scroll.
To comfortably fit within any social viewport, the content within the card would therefore need to flex both vertically, and horizontally, while maintaining sufficient layout and content cohesion for the author to recognize — and remain happy with their creation (we internally referred to this as ‘capturing creative intent’). While there were technical challenges to making this work, there were also deeply cultural ones. Would users ‘get it’, or would they find it weird when cards looked a bit different within Facebook compared to Slack or Pinterest?
This was still to be determined, but feedback within our (admittedly entirely Mozillian) Beta audience was quite positive. We also saw it as an opportunity to make the nature of the web more real to a new generation of users who might not understand why the web is in fact designed, from the ground up, for such behaviours — in ways that a binary Snapchat ‘Story’ might not be.
Beyond mobile
Deciding how to render stacks on larger (desktop and tablet) screens was comparatively simple. We concluded early on that it would be counterproductive to build full responsiveness into cards, and decided to focus our energy on supporting a great small screen experience. The experience at larger (post ‘phablet-ish’) sizes would consist of a simple, aspect-ratio-constrained card rendering (similar to AMP Stories). Cards did however look pretty awesome when viewed in a grid — something we were keen to eventually try. (For a peek at how this might work, click the ‘grid view’ button in the top right corner of our Glitch prototype. Note: you may need to reload once you toggle back to single card view.)
Being social *within* Hopscotch
While Hopscotch was primarily a creative tool, it did include a degree of social ‘glue’. Striking the right balance here proved immediately challenging. Some Beta users wanted more social stuff, while others felt we already had too much. Others still (and we found this particularly interesting) saw “social looking stuff”, immediately thought “closed platform”😱, and began to ask questions about silos, advertising, and degree of content ownership. (And were then thankfully…pleasantly surprised by our answers.)
Hopscotch’s social features were designed to perform very specific jobs that we hoped would improve the experience for both users and authors.
- Follow — “As a user I want to easily find out when a favourite author posts something new” Providing a chronological list of new content within the app, and enabling interested users to opt-in to push notifications, seemed a good way to respectfully enable author-to-audience engagement, and notify users of new entries within long-lived stack.
- Like — “As a user, I like to collect things I find interesting”. As in many products, Like did double duty as a public signal of appreciation, and a means to collect stuff you like. There’s plenty of evidence to show that this isn’t ideal, but in early testing a dual (private) Bookmark + (public) Like scheme (as Twitter recently implemented) received mixed results. Future plans to enable embedding of a card from one stack into another, did however suggest bookmarking might reappear to enable “As an author, I want to easily collect material to re-use in my own stacks” use cases.)
Beyond these two features, we made the implicit decision to steer clear of too much social interaction. While there’s good evidence that likes are useful as social signals, and that follow mechanisms are an easy way for users to fashion a personalized ‘discovery stream’ (something we were keen to encourage, instead of immediately heading the algorithmic route) our ultimate goal, was to encourage propagation of stacks throughout the wider internet.
The team therefore felt it best to stay away from features that might either immediately make Hopscotch feel like a silo, lead to more sharing within the app than outside of it, or inadvertently engineer pathways to in-app over-consumption.
All this said, one would be forgiven for looking at Hopscotch and saying: “Meh. It might be made by Mozilla, and be underpinned by all sorts of values, but what’s to stop it from becoming *yet another platform*”.
Which brings us to part 3. In this final segment, we take a slightly different angle and look to a speculative future inhabited by new kinds of apps, behaviours, and standards that champion user agency and creativity on the open web.
[If you enjoyed this article, check out our newsletter for a weekly selection of tidbits and research about our evolving relationship with technology.]
