Learning by Making: Notes from the First Wobble Web Workshop
How do you see if a tool for making websites feels right? For us, the answer is simple: invite people to make things with it and see what happens.
WobbleWeb is a hybrid graphics editor and coding environment. It’s built on open-source components and is meant to feel more like a sketchbook than a production tool—something for zines, flyers, small games, or personal sites. We recently held a small workshop where people tried making a web zine cover with it. We wanted to see what felt intuitive, what felt confusing, and where the process broke down.
The session was structured as a hands-on hack: a short intro, 40 minutes of making, and a shared reflection (with berry crisp and vanilla ice cream!). Afterward, participants shared candid feedback through a survey. What we learned is already helping us shape the next steps for the project.
What Felt Good: Directness and Play
Section titled “What Felt Good: Directness and Play”The most exciting result was that every single participant said they could imagine using WobbleWeb again and would recommend it to a friend. People enjoyed the directness of the editor—dragging elements, adjusting sliders, and seeing changes happen in real time. One person mentioned it gave them “access to all the css-magic without having to remember syntax.” Another compared it to “making quick messy fliers” you can instantly share as HTML.
The fact that people could create and share tangible things so quickly, with no prior experience, is the best validation we could have asked for. It suggests the tool is aligning with its purpose: lowering the threshold for making and publishing online, while leaving room for expressive mess.
What Needs Work: Stability and Clarity
Section titled “What Needs Work: Stability and Clarity”We also heard clear, specific feedback about what didn’t work. This is exactly what we hoped for.
- The most critical issue: export sometimes freezes, especially when publishing to the web using Codeberg pages. This is a clear blocker, and we’re treating it as a top priority.
- People also missed basic features like undo, and standard keyboard commands for copy/paste—a huge priority for both workflow and web accessibility.
- Some found parts of the interface confusing, like not seeing how to scroll in the styling panel to find all the options.
These aren’t abstract complaints; they’re concrete moments where the tool interrupted someone’s flow. Fixing them is necessary to make the editor feel reliable and respectful of people’s time.
Thinking About Learning and Potential
Section titled “Thinking About Learning and Potential”Our initial users were technically proficient. A key insight was that only one of the five users switched to the code view during the session. This tells us two things: the visual tools are engaging and sufficient for a wide range of tasks, but we also have an opportunity to better expose the coding power underneath.
Rather than simplifying language (like changing “text-decoration” to “underline”), we’re focusing on building better learning resources inside the editor itself. The goal is to make the existing terminology discoverable and understandable, turning a moment of confusion into a moment of learning.
We are also prioritizing:
- A non-restrictive integrated guiding tutorial that introduces concepts like adding interactivity or custom elements in the code editor.
- Making the code more visible as you make visual edits, to strengthen the connection between the two views.
- Translating visual concepts into code: Showing how a drag-and-drop action changes the CSS.
- Adding undo button and copy / paste function for elements
The goal isn’t to remove complexity, but to make it available when people are ready for it.
User Workshop Sample: Trash by paupowpow
Section titled “User Workshop Sample: Trash by paupowpow”
User Workshop Sample: A Fool’s Errand by GOD69
Section titled “User Workshop Sample: A Fool’s Errand by GOD69”This workshop was just the beginning. We’ve already created a remote survey to replicate the zine challenge and will be distributing it over the coming months to gather data from a wider and less experienced audience. We want to better understand how people expect to share and collaborate on small web projects. By embedding this continuous feedback loop into our process, we can better understand what makes a tool feel intuitive and empowering for making things online.
WobbleWeb is a research lab that is evolving through making and shared learning. It’s a collection of ideas, demos, and experiments.This process of building in the open, with a community of makers, is how we ensure WobbleWeb evolves into something both powerful and accessible. If you’d like to follow along or try it yourself, you can find the open-source project at wwwobble.org.