Define the focus and scope of each app

[olizilla]

What is the main purpose of WebUI, or whatever it will become? WebUI has a lot of good ideas in it, but it's due to some UX & perf issues and some missing features, I don't think it is able to do a great job yet.

Companion's purpose is clear as it is greatly limited in what it can do by being confined to the WebExtension apis. It is to integrate IPFS functionality into the browser. It can offer IPFS info to the user about content that is in the current tab, and it can provide a drop-down menu of options. Significant features (add / share file, browse files) have to be offloaded to a web ui, either custom to Companion and bundled with it (as per the current impl of file upload) or it can directly hand off to a separate app (WebUI... or possibly Desktop via protocol handlers? @lidel @hacdias is that possible?)

Desktop as a standalone app, has the most freedom in how we build it, what it does, and how it looks. We could rethink it as a minimal menubar application, with it's main purpose to keep an ipfs daemon running and indicate to the user at the OS level that IPFS is available, along with OS integration so it shows up in the native file browsers. This is how Dropbox works right now

Alternatively, we could make it a full screen, desktop app, and have it do everything (file-browser, dag explorer, ipfs node manager, PIN a dataset). This'd be more like an IPFS Workbench app (think db explorer).

There is a desire to decouple to WebUI from go-ipfs deployment, to allow us to iterate on it separately, and to avoid sending the message that people should open api ports on their own ipfs gateways! There is clearly a desire for an IPFS node management app, that let's a gateway admin see what's going on with a given IPFS node. But we could rethink that as a single app that could be pointed at any IPFS node (there is a missing authentication story here, but we should come up with with the best apps we can think of and then describe what's needed to get there, and bump the priority on issues we need to fix to make it happen)

[olizilla]

Do we want a minimal desktop app with OS integration + super deluxe WebUI rebuild with all the features, and have desktop and companion hand off to this nu-webui for significant features?

Or... do we want to remove / reduce WebUI and replace it with a super deluxe Desktop app that operates as a node admin / dashboard / workbench and general purpose IPFS / IPLD explorer. Could Companion hand-off to a Desktop if available?

Or some other combo?

[lidel]

IPFS Desktop

This app is the most important from UX perspective.
Here are my thoughts:

• It is "the entry drug" for casual users. It will shape perception of IPFS in a wide audience.
• Key features of MVP IPFS Desktop:
  • UI for starting/stoping IPFS node and displaying its basic health and status
  • UI for managing ipfs.files API ([Discussion archive] File Browser #9)
    • UI for adding files to ipfs.files (Make file-adding experience consistent across our tools #35)
    • UI for sharing files from ipfs.files (Design: Share files via IPFS #34)
• Should feel light and easy on system resources, so that people are ok with leaving it running in the background all the time (just like they do with Dropbox)
  • this implies that welcome screen needs to be minimalist and uncluttered:
    • "storage quota" gauge should be moved to "Settings" screen (Settings page: add UI controls for common settings from config file #15)
    • basic IPFS Node info and stats (Summary-style status screen (1/2) #33) with links to WebUI for more details
      • eg. if peer count > 0, then it is a clickable link to Peer List (Design: Connections / Peers List #38) at WebUI
    • easy access to File Manager and other items via intuitive icons + labels
  • being "light" includes go-ipfs spawned by Desktop – I propose to run it with dhtclient profile to limit use of idle bandwidth (Minimize DHT bandwidth usage: switch node to dhtclient profile ipfs-desktop#619)
• Design Focus should be on our key features, especially UI for adding and managing files via ipfs.files API (File Manager).
  There is one specific I'd like to highlight:
  • native OS integration for ipfs.files can be added in future, but for now it will be too expensive to make it a seamless experience for all platforms. We should focus on making web version of File Manager great ([Discussion archive] File Browser #9). And at least for now, it should be bundled with Desktop (see "Offline First" below)

Offline First

Regarding bundling and deciding what things should be delegated to WebUI in general, I want to channel concern raised by @lgierth in PR about Landing Page for browser extension (ipfs/ipfs-companion#326 (comment)):

Another concern: people might simply be offline while installing the extension. We should approach this from an offline-first perspective.

There was a great presentation at 34C3 about SNET / Street Network in Cuba [1] but there's plenty of other cases where users are permanently or intermittently disconnected from the internet at large.

This does not mean we can't delegate things to WebUI, but we should think which features won't work in offline environments and make sure initial experience is not full of Page Not Found errors :)

[hacdias]

Answering to your first question, @olizilla, I believe it is. I think we've talked about that once (cc @lidel).

Now, about WebUI and Desktop.

Desktop

In my opinion, Desktop should be the smallest - in terms of size it can't be due to Electron... - and the entry point to IPFS. With it, you could:

• Install IPFS
• See the basic info about your peer
• Manage your files
• Pin through MFS ([META] Solidify mental model/language for MFS add vs IPFS pin #10). We have to be careful naming this one because the command line users will be expecting that this would use ipfs pin but we may not use it.
• Have the nice features and shortcuts we have:
  • Download copied hash
  • Auto add screenshot
  • Launch at startup
• Peers should be shown in a very small list or shown in WebUI.
• The Node configuration should be edited through WebUI (or local editor?).

WebUI

My first feeling is about the name of this piece of software. We've discussed this before and we didn't really change the name (ipfs/ipfs-webui#612). Although, I don't find "WebUI" the best word to describe what this does.

Something I would like to be done was to untie WebUI from the go-ipfs release so it could be worked on easily and new releases would be easier to get out. Isn't it possible to have a domain (like ipfsadmin.com for example - I don't like it) pointing to the most recent version of WebUI and use it through that URL? I know it would mean exposing the API somehow and that the WebUI is just meant to be used locally.

But... what is webUI supposed to do?

• DHT Explorer
• Friendly Configuration editor
• File Browser
• Detailed information about the peers
• Graphs and other beautiful and useful things for Stats

[olizilla]

Ace 👍

We're going to focus on making WebUI awesome (name could change at some point, but we're not gonna focus on that right now).

It's going to have a responsive, accessible, file-browser and make sharing files directly with friends super easy. It's going to have a IPLD Explorer to show what makes IPFS work, to help people build a mental model, and inspire them to dream up radical new uses-cases for hash linked data. It'll help you publish websites and co-host content you love. For metrics that you can influence it'll provide simple controls to manage them. Power users will be able to fully customise their node, from a validating config editor.

A little bit like it is now, but totally rad. 🚀✨✨✨

We're going to start wireframing these flows tomorrow. The current thinking is to have Desktop embed the new WebUI to minimise the duplication of effort and reduce the documentation burden. To keep the lightweight menubar app feeling, we'll consider creating a minimal Desktop specific UI. It could provide the most interesting stats and list recently added files. Actions would open up a separate window to hand off file-browsing / upload'n'share / IPLD exploring and all, to the embedded WebUI.

WebUI will use the new window.ipfs proxy where available. That'll allow us to use the it from Companion for sharing / browsing / IPLD exploring etc, as it'll be able to work with either a remote node via js-ipfs-api or an embedded js-ipfs node.

We may explicitly bundle a version of the WebUI code with Desktop, so that it can work offline, and provide a mechanism to announce a new CID for the latest WebUI release and have Desktop pin it and update to that.

We'll look at decoupling WebUI from go-ipfs and possibly publishing it to it's own domain or subdomain of ipfs.io, along with creating a mechanism to let it communicate with a local api.

This is deliberately described at a high-level; the details are subject to change, but from recent conversations and the discussions here, this is the direction we're heading in.

[akrych]

Sorry for late reply, my thoughts and summary a bit:

IPFS Desktop
In my opinion the most important application from UX perspective and the first “wow” contact with more new users. I think this app will be main used by none-technical person (correct me if I’m wrong) so it should be the most intuitive and explaining what's going on in IPFS :)

About the “size” of application - I agree that is should be light and complex, but we also need to remember that is should have quite developed file management. So we need to combine the available functions with a small size in a smart way - so that the interface does not lose its readability.

Key features of MVP:

• Easy install IPFS
• Menu: home, files, settings,
• Basic node info: peer ID, public key, number of peers, protocol version (in always visible place)
• Link to Webgui
• File management: adding files, adding patch(“pinning” [META] Solidify mental model/language for MFS add vs IPFS pin #10 ), sharing files,
• Easy start/stop
• Basic settings: storage in GB, launch on startup, gateway
• Additionally: customised download page to share with friend, that should have: IPFS logo, file name and size of shared file/directory, link to the file, file preview, short explanation of IPFS (Design: Share files via IPFS #34 )

WebUI

In my opinion this application should be the biggest and the most advance with all. It will be a little hard to design because it should be a place that none-technical person can make some more advance operations and also for advance user.

• Node info
• Peers list and visualisation
• Advance File Browser (with pinning) - like @hacdias, work https://filebrowser.github.io
• IPLD Explorer (Dag)
• Easy start/stop
• Settings (with form but an option to switch to raw config JSON editor)

Let me know what do you think about it :) 👍

[alanshaw]

So to reiterate, what we're thinking is that IPFS Desktop will sit in the tray, on click, it'll show a minimal drop down to show some basic node health info, and from the dropdown you can click to open a bigger window which embeds a new WebUI for all other functionality.

I can get behind this, I was worried that this felt a little clunky at first but it's literally what all my other tray apps do so I guess it's fine 😛

---

Test to ensure we can inject a window.ipfs into a web app using electron:
https://github.com/tableflip/electron-window.ipfs

The cool thing about using window.ipfs is that we can decouple the implementation details of the IPFS node we're talking to from the WebUI app, allowing it to be used in Desktop, as a standalone web app (with IPFS companion installed to provide window.ipfs), or within IPFS Companion itself, linking to specific pages for certain actions.

It can also fallback to js-ipfs-api so it can still be bundled with go-ipfs if necessary (although I think we'll recommend that it isn't) and can be used to administer a js-ipfs node running in the browser FTW.

[jessicaschilling]

Closing this in favor of the more recent ipfs/ipfs-desktop#1389 - but linking to it there for reference.