Electron user stories

[groundwater]

Hi all, I saw some of you at Blink On, and I promised to come up with a few user stories. Rather than trying help shape the implementation, I thought I could just outline why electron is looking at this format. Here's my first pass at some user stories.

App Installer Story

Developer Kim builds a new electron app, and wants to host it on her site. She wants to make the install as easy as possible, and a new hot installation tool some people have downloaded knows how to take a web package, and install it like a desktop app. Right now, every electron app comes with its own chromium. A web package format distribution could link out to the required chromium, which may already be installed on the users desktop.

The end-user downloads the .electron bundle, double-clicks it, and the installer installs a new app.

Both the installer, and the operating system should be validating the package and checking code signatures. (Open question if the dynamic installer messes up the signature story)

A new icon is placed wherever there operating system installs applications, and double-clicking it opens the app.

Lifecycle with shared resources

Kim is at it again, but this time her users have demanded an even slimmer after install experience. Kim builds the next web package bundle, but instead of including everything in node_modules the web package simply links out to indicate that a requires these and PM modules at specific versions. To complicate matters, some of these modules require compilation.

Kim knows that not all of her users have developer tools installed, but also doesn't want to set up CI on numerous different platforms. That's okay, we have your back. The top 100 electron modules that require compilation have been precompiled on common platforms packaged into a web package format.

User Angela downloads Kim's latest web package, which only includes the core app code. The installer understands the outbound links in the web package, and first attempts to satisfy them with a local cache on disk. One of the compiled dependencies is missing however, and the installer has to downloaded fresh. Instead of pulling from npm directly, the installer is able to resolve the location of a precompiled version and use that.

BigCorp

Big Corp once control over every last bit of their installed application. They want to block every last piece down. They want a self-contained packaging format, where everything gets shipped altogether.

This is the situation we have now, which is why it's worth putting down.

BigCrop Internal

Internally at big Corp, they have a lot of internal tools developers that wish to distribute quick one-off applications. Because everything is running behind their firewall, they only want vetted code. Developers love the hotlinking that the web package can do, but all links should resolve to an internal npm mirror and an internal blob store for precompiled modules.

[jyasskin]

I think these have been incorporated into the use cases document.