Rethinking the creative web: Part 3 — Towards a new read/write web
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 final article, we look towards a future inhabited by new tools, behaviours, and standards that champion user agency and creativity on the open web. You can also read Part 1 and Part 2.
Part 3: Towards a new read/write web
“I wish Medium was just a platform, a minimal blogging solution with better social affordances than Blogger, Typepad, and Tumblr, and lots of the messiness of the nearly forgotten ‘web culture’ that Facebook stripmined.“ — Stowe Boyd
“Bringing View Source back could empower a new generation of creators to see the web as something they make, not just a place where big companies put up sites that we all dump our personal data into.” — Anil Dash, The missing building blocks of the web
In the months since the Hopscotch project was disbanded (and especially given the current turmoil with larger platforms), we’ve frequently found ourselves thinking of new ways it might have evolved. In fact, the saddest aspect of the project’s cancellation is our belief that it could have played a role in fundamentally resetting the relationship that users have with the web.
This belief stemmed in part from the fact that Hopscotch would’ve been a product by Mozilla — a not-for-profit company whose core principles include upholding the internet “as a global public resource that must remain open and accessible”, and whose day to day activities lead to a host of initiatives that do just that. We were therefore excited to work on a product that considered the web a first class citizen — not for ideological reasons — but because research suggested that helping users make better use of the web would not only help those users, but also contribute to revitalizing and protecting the web as an open global resource.
It is in this spirit that we present the ideas below.
While we in no way suggest all these ideas would work — let alone all work together, we hope that their overarching intent will be clear: explore ways to right the growing imbalance between the interest of users and those of the platforms they currently ‘publish’ through, by providing opportunities to bring user agency back to the web.
Caveat: Unlike parts one and two which outlined the product we actively worked on with Mozilla — these ideas are primarily forward-thinking speculation and not indicative of the initial product roadmap.
1. For everyone
“To compete with one walled garden you have created another and dressed it up as open source” — @ldstevens
Our goal with Hopscotch was to make creating for the web as easy as writing a Facebook post, creating a Musica.ly short, or personalizing content using popular mobile native tools such as Snapchat. In doing so, many users wouldn’t realize they were writing to the web, and we were OK with that. We did however bank on the fact that enough of our audience would appreciate what was under the hood, to challenge us to preserve and improve key aspects of ‘webbiness’ that make the web so universal. (It’s worth clarifying that while some of this was baked-in by design, other aspects — such as full indexability, and sufficient semantics to ensure accessibility — were a work in progress).
Ultimately however, we were still building something that was part tool, and part platform. The content may have been HTML, but users needed our (native) app to create it, and that content would ultimately be hosted on a Firefox domain. It doesn’t therefore take much extrapolation to worry that Hopscotch might have eventually become *just one more* centralized choke point.
Here’s a few ways we might have improved on this.
Make it open
Maybe not all of it. Maybe not all at once. But by enabling structures for open oversight and contribution, users and authors would have had some say in the product’s long-term direction.
We quite like the approach recently taken by Glitch to stage their open source roll-out with an initial focus on remixing the Glitch web site. They’ve even enabled users to do so using Glitch itself as editor (a degree of inception we should all aspire to 😋). As Anil Dash suggests, a key motivation was to keep the social aspects of the tool honest and transparent:
“…the reason we made the @Glitch community open source is so that someday soon, when we suggest apps for you to check out, you’ll be able to see the reason why they were recommended. And if you don’t like it, you can help improve it”.
Enable tangible content ownership
Given the contents of Mozilla’s manifesto, it was likely that a user’s content would always remain their own. There is however a big difference between this being true, and enabling a person to do something useful with that content should they decide to leave. With any luck, open sourcing aspects of Hopscotch would have (if nothing else) enabled the community to experiment with different types of stack editors and renderers, thereby enabling content to outlive the original project should it one day shut down.
While open sourcing the tool would’ve enabled a degree of portability, an interesting stretch goal could have been to enable interested users to host their own stacks from the very start. This could have been as simple as a WordPress or Drupal type of arrangement, where certain users might choose to self-host a Hopscotch instance, while others might retain a more centralized Mozilla-hosted arrangement with the option to pay for additional capabilities, or assign a personal domain name.
An interesting option would also have been to consider how stacks might be stored in a more decentralized manner.
“Decentralizing the Web means that people gain the ability to store their data wherever they want, while still getting the services they need. This requires major changes in the way we develop applications, as we migrate from a closed back-end database to the open Web as our data source” — Ruben Verborgh
We’ll touch on other aspects of decentralization further down, but to better understand the different structures that might enable users to store (and serve) their own content in the context of a wider service, we highly recommend this article which outlines three decentralization paradigm shifts: end users become data owners, apps become views, and interfaces become queries.
2. The web as building block for…more of the web
The Hopscotch product outlined in part 2 only included the barest form of ‘remixing’. While there was nothing to prevent users linking from one stack or card to another (and we very much hoped that they would) this hyperlink would initially render the same as any other. Our longer term hope was to go much further — enabling users to augment their stacks by embedding cards from other stacks.
This idea has been around for a while, but has (amongst other things) been constrained by the fact that ‘web pages’ remain typically huge, ungainly things with (many) dozens of unknown dependencies.
“Those old hypertext theory people had broader ambitions…They thought we might someday be able to pull live, updated pieces of other sites into our own websites, mixing and matching data or even whole apps as needed. This ability to include part of one web page into another was called “transclusion”, and it’s remained a bit of a holy grail for decades…If we can address the security and performance concerns of sharing data this way, we could address one of the biggest unfulfilled promises of the web.” — Anil Dash, The missing building blocks of the web
Reframing a page as a much smaller ‘card’ (that is nonetheless linked to related cards to form a wider stack/‘site’) it’s easier to conceptually imagine how this might begin to work. This then leaves the question of how it might practically work, and for this we see hope in the new Web Package specification. This proposal aims to bundle web sites into a package that can be locally saved, shared peer-to-peer (P2P), or embedded into another context (taking advantage of the package to pre-fetch the content in a privacy-preserving manner).
Interestingly, key uses cases for the Web Package spec were derived from findings similar to Mozilla’s (described in part 1 ) but in Google’s case specific to users in emerging economies who often seek to capture, save, and re-share/sideload web fragments due to poor network connectivity. Google’s Jeffrey Yasskin describes the standard’s intent:
“An author should be able to produce a bundle of their web site, including service workers, JavaScript, CSS, images, then sign it, and let people download it and share it P2P over cheaper connections such as P2P or over bluetooth etc. The recipient then needs to be able to download and install it, connect back to original server, and treat it as same-origin e.g. get the right URL bar, the right JavaScript permissions etc. As individual users should also be able to create these bundles, you will also need to be able to do this unsigned. ” — Jeffrey Yasskin, Google, IETF99 Dispatch (6:03 onwards)
Copy it, fork it…with a built in history
Another feature we hoped to explore, was to enable authors to (with necessary permissions) duplicate a card, and edit its source to create a derivative work. The root reference would (ideally) always remain available, enabling users to access not just the original, but chronologically browse all its derivative versions. (While pretty cautious about the many problems people feel the Blockchain will solve, one could imagine it playing a role in maintaining the integrity of something like this.)
There are also strong parallels between the behaviour we’ve just described and the ‘fork’ functionality built into Beaker — a new P2P browser that leverages the decentralized Dat data sharing protocol to enable users to create or remix apps, then distribute and share them directly with other users.
(Worth noting as well that for users in low-bandwidth areas, a locally hosted Beaker/Dat site might be a good alternative — albeit with a potentially different security profile — to a Web Package. 🤔)
3. A new construct? (or maybe just a new frame of mind)
Five years ago, we were excited to discover ‘lite apps’ (qing ying yong 轻应用) in China: tiny, “one-off, zero-download, hyper-targeted mini-sites” designed to add richness, context, and utility to native platform interactions within the (now 1 billion user strong) WeChat platform.
Fast-forward to the present, and we’ve discovered a host of media-led initiatives to encapsulate longer-form narratives into bite sized chunks.
- The Guardian’s ‘smarticles’ are a dynamic mobile-only story format that displays ‘blocks’ of an evolving story (either chronologically or algorithmically adjusted to prioritize relevance). Clicking a block enables users to dig into sub-topics they are most interested in. (A current limitation of the format is the lack of consistent support for the web notifications API used to notify users of a new segment of the story.)
- The Verge’s “story streams” present evolving aspects of a story using a timeline that users can follow using RSS (and is therefore equally limited, but this time due to a chronic lack of RSS readers).
- Vox story packages group related stories together in curated packages that enable users to broaden their knowledge of a larger topic. This example shows a particularly long series.
- Google’s recently launched “visual AMP stories” (which are quite similar in design to our stacks) is a mobile storytelling format that appears to primarily targets the one-off ‘creator’ use case we discussed in part 2.
Surveying all of these, it’s hard not to wonder if we’re on the cusp of a more fundamental change in the way we think about web sites — not because sites will be replaced by apps — but because our current idea of what qualifies as a site, and the value (or lack thereof) that this implies, may be holding the web back.
The read/write web
From AMP stories, to smarticles and WeChat Lite Apps, a variety of related use cases appear to be converging. Commonalities include the need for smaller, bite-sized content that can thrive on mobile (and within social steams), but whose purpose may be broader, deeper, and more personal in intent to your average ‘single page app’. An experience that can be indexed and shared via URL, like any other web thing — and yet holds the potential for more formal encapsulation, all the better to save and revisit it on the devices we now primarily use to access the web.
One could argue that what we’ve just described is a cross between a progressive web app (PWA) and Google’s recent push to standardize AMP (especially if this results in standardizing AMP Stories). We can imagine a future where a ‘story bundle’ (discovered via search, social, or shared P2P) could be saved to a user’s device (as a PWA, web package, or through P2P tools such as Beaker), complete with built-in updates and notifications. This package might include not just rich media, but collections of even tinier apps — like Tara Vancil’s 2kb word counter which we cheekily included towards the end of our prototype (…this bit was definitely not on the Hopscotch roadmap…at least not yet!)
The key element missing in this story however is the creator. While we can imagine all the technologies we’ve mentioned getting there (they almost always do) what’s less certain is a future where the creative, useful, and highly personal bite sized bundles we’ve described are created by everyone.
“Reading things on the web would be free, sure. But *creating* things on the web? We’d pay venture-backed startup tech companies for the ability to do that, and they’d mediate it for us.” — The missing building blocks of the web
The web Tim Berners Less created was envisioned to be read/write, and for a brief period it truly was.
So here’s a question: What might a new read/write web mean in an era where not only the reading, but writing is mostly mobile?
If we can be so presumptuous, we believe it might look a little bit like Hopscotch — bite sized, created on your device, using a tool from someone you trust, leveraging behaviours you already know to craft something that you can share, and should you want to, keep — forever.
In the absence of a product launch, and the opportunity to see what Hopscotch might have become, we hope the ideas we’ve shared in this series may inspire , and in some way contribute, to such a future.
“Whether the internet is an open space or a closed space, I am not going to -predict. It is up to us. It all depends on what we do now. All the decisions we make now.” — Tim Berners Lee*
*transcribed from an audio clip I heard in a podcast last week — if anyone knows which one, i’d love to credit it.
[If you enjoyed this article, check out our newsletter for a weekly selection of tidbits and research about our evolving relationship with technology.]
