What should “create” do?

29 September 2021

We use web apps to make a ridiculous quantity of content every day; videos, blogposts, statuses, documents. We’re ceaselessly clicking “new post”, “upload video”, “start a new document”.

I had an epiphany about what should happen when you click “create” on a web app these days. This epiphany mainly applies when the content takes a long time to create, like writing a document, making a codepen, or, in my app, creating a quiz.

Originally in my quiz app, the “create” link would direct you to a page with a form. You could use this form to build out multi-choice quiz questions then hit “submit” when finished. The new data would get posted to the backend, validated, and added to the database. The backend would then send the data back to confirm the submission was successful. After this, you would have the option to either host the quiz, or further edit the form.

This all sounds pretty sensible. Right?

But the experience I had created felt more like using the web in 2006 than in 2021. In what ways did this user experience transport the user back 15 years?

• If you were halfway through the form and refreshed the page or navigated to another page, you would lose everything you had created
• It was unclear what the “submit” button would actually do. Would the user be able to keep editing the quiz after it was submitted?
• There was no indication to the user suggesting how they might write half the quiz, save, then come back and finish it later

This experience subverted expectations we place on modern web apps. It was tense. It made it feel like you had to get the whole quiz right on the first sitting - like the content was made of delicate china and could break at the smallest push.

We want to be able to take a break and know our work will still be there when we get back. My app used simple CRUD functionality which was similar to what you'd do in old server-rendered applications in the early noughties. We shouldn’t build apps like this any more.

When you’re using google docs, dropbox paper, or codepen and you hit the “create” (or the equivalent button) something different happens. A new space for the item has already been created on the backend by the time you see the page. If you look at the URL for these services, it’s already built out some kind of hashed ID for the content.

None of these services have a “submit” button. A submit button would feel completely out of place. What does submitting mean when I can see it’s been autosaved? The user feels like they’re looking directly at the canonical version of their work. It’s like they’re looking into the database - like the real function of all of these apps is to be a glorified database GUI.

I realise now that my quiz app shouldn’t have separate “create” and “edit” pages. In all the cloud-first content-creation services there is one page to adjust the content whether you are creating it, or you’re coming back to it. In my quiz app when you click the “create” link, it should cause the backend to create a new empty quiz first, then show you the page to edit it.

As you build your quiz, it should be obvious that there is a button that will save your progress and allow you to keep working on it. Or even better, an indication that the quiz is getting autosaved.

I don’t think this is at all a new idea. I think web apps have been using this pattern for years. But I think this little epiphany is highlights one of many details that can decide whether your app will spark anxiety, or spark joy.