Design: Creating Simple Websites with IPFS

[lidel]

Websites are cool. Our GUIs should empower users and make it extremely easy to create one with UI "one click away" .

How to make creating simple websites with IPFS feel great?

please provide examples of good design / user experience in comments

Work Outline

• Design user journey and UX for:
  • Creating simple websites
    • "Just works": built in file manager and text/code editor (html/css/js OR markdown)
    • selecting files/directories and "publishing them as a website"
    • feels natural but at the same time native to DWeb
    • available "everywhere": ipfs-webui, ipfs-companion, ipfs-desktop
  • "Forking" existing websites
• IPNS needs to be fast
  • Without this we will be only able to publish static snapshots
  • Lars may have an idea how to improve this: Asks for libp2p team 2019 Roadmap roadmap#18 (comment)
• IPNS Key management should be hidden behind UI. There should be a key per website: user should be able to export/import "website control key" to publish from different machine

Prior Art

• http://neocities.org
  • built-in tools: text/code editor & file manager
  • requires know-how around HTML, provides learning resources: https://neocities.org/tutorials
• Zeronet

  With ZeroNet, you can create your own blog, forum, chat, wiki and many more types of websites you can choose from with just two mouse clicks

• UI in Beaker Browser:
  • One-click publishing
  • Built-in editor
  • “Forking” or copying a website
• Creating tiny websites/notes without knowing any HTML:
  • http://hashify.me (Markdown)
  • https://itty.bitty.site (WYSIWYG)

cc @ipfs/gui-team @kyledrake #35 #34

[lidel]

(A summary of initial discussions with @kyledrake and others during the Q4 Team Week)

Low hanging fruit: Add Publishing Feature to Web UI

If we borrow some abstractions used by Neocities, we already have key components implemented as parts of the New Web UI.

What is missing is wiring them up together as a part of coherent user journey from "website idea" to "having a link to the static website". Mutability via website keys/IPNS support could be introduced in next iteration.

	file manager	text/code editor
Web UI
Neocities

[patrykadas]

I remember that we were experimenting with forking websites with @Gozala, here are the short videos explaining the use case, baked natively in the browsing experience:

Fork & Send:
https://drive.google.com/file/d/0B8pr60831MlMT1JiYlhMZFh2ajg/view?usp=sharing

Receive:
https://drive.google.com/file/d/0B8pr60831MlMUWxTc3ZxU0h3LUk/view?usp=sharing

It's much simplified with a sort of identity system in place, however, the case here was to excite and show possibilities rather than a pragmatic solution. I'm wondering though if this could be utilized with the companion and/or website owners.

I'd be really happy to prepare a design proposal for an uploader with baked-in publishing functionality and highlight some superpowers when the recipient actually opens the shared link. I should have something done by the beginning of next week :)

So far I've found #34, #35, #68 and https://github.com/ipfs/ipfs-gui/blob/master/research/README.md#add-files relevant to this case as well.

EDIT: I feel like changing 'Add' button to a dropdown with multiple options (folder/file/text) would do just fine. I've uploaded the https://www.figma.com/file/YTMV7cOMmDSfqw8BgwoncbJ5/IPFS-Desktop?node-id=0%3A1 to #44, but I think the components will eventually be universal.

@lidel

[lidel]

@patrykadas I really like the idea of sharing annotated websites. FYI a relevant work on web annotations and IPFS is happening in pm-discussify/discussify-browser-extension (p2p version of https://hypothes.is) – you may want to post those demos there. I also like the light feel of minimalist Files browser and Web UI from your figma, added it to #9 for future reference :)

Going back to authoring websites: "Add button as a dropdown" is already a thing in ipfs-webui (screenshot), we probably could reuse that pattern, eg. add option to "Add a website" as an entry point into authoring flow where a new directory with index.html is added behind the scenes and HTML file is opened in editor.

What superpowers you had in mind? (some sort of overlay informing user "this website can be forked"?)

[patrykadas]

@lidel That's great to hear! Feel free to do anything you'd like with these designs - it was just fun/exploration. I agree with the authoring website, it should probably open the editor and provide a convenient place to get a link to the file user's working on.

In terms of superpowers, I've imagined utilizing some peer to peer features. I liked the @Gozala idea about the peer cache that'd allow displaying a website in an offline mode , combined with displaying available versions, edit mode (forking), maybe even a way of discovering the peers. Ideally, it'd be integrated with the browser, like in the Beaker, but perhaps it could be also part of the companion and displayed somewhere within the website as a fixed widget.

[Gozala]

@patrykadas those sketches look nice! I have being wanting something along the lines for the ipfs/in-web-browsers#137 exploration. Idea that sites could emebed "IPFS Access Point" thingy that would allow them to load everything off of IPFS, but I also wanted some way to provide context and ask for permissions. Something similar to what you have in sketches.

Idea is for it to serve multiple duties:

• Provide "ecosystem recognition" - Kind of like you can tell when you're with-in google / amazon ecosystem.
• Connection to your library - In a way that is the portal to your IPFS library.
• Status - Which is what your sketch covers, but also things that could communicate with user what app is doing. Kind of how iOS communicates geo-location is used etc...
• User prompts - When new site / app attempts to access stuff from your library it could expand like 2nd from top on the left to request user consent.
• Pining - If I'm visiting an app first time, one click interaction to "install" it meaning pin it.

[Gozala]

There is probably more but primary goal is to have consistent experience (usually delivered through chrome UI, which we can't without building a browser) that would make it clear that all the things in this system interoperate and all the data produces / accessed is in your library that is fully under your control.

[ericronne]

cc @jessicaschilling (once added to repo)

[jessicaschilling]

Closing this issue in favor of similar meta-issue #77 ... but linking to this issue's valuable info prominently in the open issue's description.