Perpetual Web Browser UX — Editing and Publishing Sites

I see what you are saying now, you want the ability to publish data, with no link back to the original account, not even within the account itself.

Yes, that should be possible, but whether it would be desirable as a default is another question… it would mean, for example, only ever being able to publish to a public name / site once, and then never again.

This could be done with just publishing to a XOR address, a kind of ‘data drop’ mode, completely hands off, and that is something that we’ve discussed in the past… it’s just not for this set of personas.


I’d vote for a data drop mode, I’d consider it an essential feature… however you choose to implement.

I have just been watching the video, I really like the idea of having an editor within the browser !
Little detail maybe but I have to agree with @piluso about the placement of the “add” button, it feels a bit weird that it is in the url bar. Maybe it would indeed more intuitive to have it in the left “files” panel.

1 Like

Yeah, we’re still working through some of the finer details of the interactions around adding pages/files/directories.

Initially it started life as a way for the user to interact solely through the address bar… “I’d like the create a new page with this URL please”, and it makes sense in that context. But adding ‘folders’ and files, may feel more natural in the left pane, where the overall structure is laid out. We we’re planning to have designs on both.

Which would be more intuitive for the user? Do they think about a site structure more as an address string, or a hierarchy of folders? Does having both lead to confusion? Does the URL bar become less useful or polluted with an edit control within? We’ll only get the answers this by testing, and test we will!


To me, a hierarchy of folders is more intuitive.
Yes, having both could be confusing.


I think it depends on whether we maintain the old workflow/UX or if we can provide a simpler UX that works for one simple job. I think it’s too early to decide, so would like to see the new ideas taken forward to find out, without trying at this stage to keep within existing UX expectations (eg folders).

Folders are used for good reason, but maybe for this we don’t need them.

For example, we don’t manage the elements inside a Word document using folders. The document itself provides the UI to manage and manipulate the images and other objects it contains.

At the moment, Tony 's use case looks more like document editing rather than document management, so I’m not sure he needs folders for the document content. They may come in for a more complex use cases, and for document management.


@JimCollinson I imagine you are already, but if not, please follow what Paul Frazee and his team are doing in this same area. It might also be worth pooling ideas.

Also, Aral Balkan is excellent on good UX (and dark patterns), so might be worth reaching out to him at some point.

Yeah, I’m familiar with their great work, and we studied it a bit before embarking on this work.

It’s a tricky balance, and why I mention testing. You can often start out with the basic building block of something quite simple and elegant for a very basic, or narrow usecase, but it can be deferring complexity to a usecase further down the line, so and it can get worse from there.

The starting point we had with this was really just simple pages, built from the address bar, in the same way that a user might think about urls. And it can feel quite natural; type an address you’d like content to live, then just drag in a file, or start typing and there you go!

But then things start to feel a little more disorienting once you want to make adjacent directories in the tree structure, or deal with large containers of images say, or linked things like CSS. It becomes harder to comprehend, navigate, and find things you need, if you can’t see the site structure in some visually mapped form; especially while there is no front-end to navigate around.

So, then you get to questions of representing that structure, getting around it, seeing which files have been changed within it… and then also how it’ll work with a structure of private files you already have uploaded to the network, and other related tools that are used to navigate them.

So, sometimes you end up gravitating back to a tried and true, in order to spread the load of complexity a bit, which might be to the detriment of a really simple usecase. As much as it is my desire to push the boat out some times, and forge a new path (often a desire probably tinged with ego if I’m honest).

It’s gonna be really interesting to watch people using all this though… and have our assumptions proved laughable!

Also, on top of this, there it’s worth remembering that there will be a lot of brand new paradigms for users get their head round, with a significant cognitive load that’ll come along with it e.g. perpetual data, and version histories of sites etc. So sticking to a tried and true, even if it’s a bit clunky, might be the right decision… not only for the user, but also for the team to focus more on the more radical parts of the picture.


Even if it is only useful for something simple - like a public homepage - being able to just type that, drop an image, make it a background, click to add text, edit some metadata (default font etc) I think this could be worth doing.

It can bring simple web publishing to everyone, and that’s a lot of new users - and undermines the power of Facebook et al who exploit the difficulty to get people to do this kind of stuff on their platforms.

Then you can build in that.


Yeah, that’s certainly the aim. And we’ll try and look a bit more at the really simple site build flows once we get on to the new site creation workflow etc.

I’d been wondering if we could do a markdown mode, and then just layer on a basic stylesheet/template choice etc, and how this could perhaps interface with a notes type app. (We haven’t forgotten those parts of Tony’s persona BTW, just biting of sensible chunks).

I think we could do something really elegant and fast to use there, and especially when it could be pre-baked with linked data, and then hooking in to a SafeID profile for a feed of posts etc…

Super simple and fun for the user, normally means a boat more work in design stage though… so I can’t promise this all from the get-go. Exciting nonetheless!


Expectation management - check
Delivery - …!