Consider abandoning Web UI? #4
Comments
Regardless of abandoning Web UI, we absolutely should ship ipfs-companion with at least go-ipfs. |
|
It's a desktop app, right? That'll increase the distribution size
significantly. The WebUI is nice because it can be fetched on-demand.
…On Thu, Dec 14, 2017 at 5:47 PM, Lars Gierth ***@***.***> wrote:
We could instead ship ipfs-companion with go-ipfs and js-ipfs
Regardless of abandoning Web UI, we absolutely should ship ipfs-companion
with at least go-ipfs.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAS8eWR3NgLBG1vCYvPi9lZNe98bQVdpks5tAV8tgaJpZM4RCbht>
.
|
How would that work? Ship the installation files of the extension? I think both Firefox and Chrome forces you do jump through additional hoops if you don't install from their extension "stores", which makes the installation process a bit more complicated. |
|
I'm not sure if I can see what is being proposed here:
Are you switching them up? |
|
(I didn't read up on what new names you came up with in that call today.)
Nah.
I was just thinking maybe we could live with just 2 of the 3. They all have more overlapping features than distinct features. This probably originates from their organic growth over the course of the last few years. There was never really a cohesive plan of which ground each of the three apps should cover (aka design). Before we sink time and attention into it: is there a plan now? The triangle in the readme isn't very convincing to be honest :) The Web UI came to mind because 1) it can't be updated independently of go-ipfs, 2) it's current deployment is a huge hack, and 3) it kind of encourages people to open up the API port 5001 to other hosts (I stopped counting how often I told people on IRC not to do that).
Yeah forget what I said for now -- I still think it's an idea worth evaluating, but I don't wanna clutter up this issue. |
|
Just some random thoughts on this: what if Station could literally be a station? Despite its functionality as a menubar application, it could also be a full fledged desktop application where you could control your IPFS node, update the ipfs version, and so on, replacing the WebUI. |
|
@hacdias the reality is that given that Station is an Electron App and that WebUI is just a browser page, you can spawn an Electron page that looks like a native app that is just that Web page, making station feel like a fully fledged desktop application. @lgierth got it. I was missing your point because as @victorbjelkholm pointed out, we can't install a browser extension on people's browser by installing a binary. |
|
Something that might work would be to move webui into something like ipfs-ui, and have it load in the browser just like it works today with go-ipfs, but also load it in ipfs-station. ipfs-station and webui would have the same UI and the same functionality, except webui only connects to external nodes (not bundled) and ipfs-station ships with a go-ipfs node. That way, we can keep webui functionality (drag and drag files in browser with go-ipfs for example) and station, while only having to develop and maintain one ui. |
|
But do we want to maintain a management web app while also maintaing a browser extension and desktop app with the same functionality?
|
My argument was that we could maintain one UI + wrappers + extension way easier than maintaining two UIs + wrappers + extension, while keeping the same functionality as we have today. Many folks appreciate being able to use the webui without any bloaty desktop applications + if we in the future have API tokens (or with ssh today) you can access a nice UI for your remote daemon with very little effort. More of a personal argument but I prefer applications that can work directly in the browser as it's easier to install, update, takes up less space and I basically live in the browser already. Although, I can see the value for other people to have a desktop application. |
|
This was a key question that came up in the meeting. We can take a moment to review the role of webui, companion and dashboard and figure out which chunks of UX can be re-used, and which will have to be duplicated because of the specific needs of desktop/addon/webui. I feel like there is growing support for re-considering station as the default ipfs installable that we point most users to. It can be responsible for integrating ipfs into the users live in a visually pleasing way (so they want to use it) and it has the option of installing the command line version, and potentially provide a bridge to the I think it's useful to have a web app that provides a dashboard for the ipfs in command line flavour, but it's worth reviewing in terms of how we might share chunks of it with os integration. I think we need all 3 parts. The command line tool benefits from the existence of the webui, as it is (currently) commonly used without any other app. The os integration would be the obvious place to put more edcational / onboarding content and to do a load of work on making the UX super nice and explaining what ipfs does under the hood for those that are interested. I'm pretty sure we need the add-on in order to get push towards a seamless experience of using ipfs as part of your daily life on the web. |
|
A lot changed since December. Namely, Closing this one, as follow-up discussion continued in #41. tl;dr starts from #41 (comment) |
We could instead ship ipfs-companion with go-ipfs and js-ipfs. There's a ton of overlap and we could avoid some of that, as well as the burden of maintenance and harmonization.
The text was updated successfully, but these errors were encountered: