No more install button?

The snapcraft store used to feature a install button, this made it easy to install snaps when installing gui’s like snaptastic.
(This install button would open a snap:// url)

I understand a lot of users might not have a application that handles the snap links, but just showing a command line command seems like a downgrade accessibility wise.

Could the button be re-added as alternative option?

Hi @peteruithoven,

Thanks for the feedback. We removed the ‘Install’ button for now while we investigate a better solution. It’s true that the button did provide a quick way to view snaps in supported GUI’s however the alternate experience for users that didn’t have a snap:// protocol handler was a very poor ‘broken’ one, landing them on a browser error page.

We feel the CLI instructions are universal to all snap users so is the best umbrella solution for now but I’ll keep this thread updated as we progress to a better solution.

2 Likes

I understand that dilemma. Looks like browsers are limiting us, since there is no straight forward way to detect support (maybe because of privacy reasons). And there is currently no way to make that unsupported protocol handler more useful for OS’s (I understands Edge automatically searches for apps in the Windows Store).

But, again, why not both? When you’re trying to convert people from Windows / OS X, using the terminal like this really isn’t an option.

I did found this custom-protocol-detection package. It’s ratings aren’t good, but it could enable showing some useful explanation when a link fails (instead of the regular error page).

We’re exploring the possibility of both, however, the browser is the biggest blocker - one option we’re looking in to is messaging around the button explaining caveats but the wording here is important to get right.

The package you linked to looks good on paper (if you print it), but during our investigation Chrome on Linux does not behave as suggested in the README:

Chrome: using window onBlur to detect whether the focus is stolen from the browser. When the focus is stolen, it assumes that the custom protocol launches external app and therefore it exists.

Unfortunately on many Linux systems xdg-open is triggered whether there is a protocol handler or not - suggesting it succeeded when it didn’t.

1 Like

@Lukewh What about giving the user the ability to download a “snap” file that could be installed with a GUI installer like https://github.com/bartzaalberg/snaptastic ?, installing an app shouldn’t require people writing commands in the terminal.

1 Like

I am completely agree. That tool snaptastic, will be usefull to install downloaded snaps :laughing:. Great idea.

It would be cool if snaptastic could be in that apps by default in ubuntu or maybe like snap. :thinking:

How would downloading a file that most users don’t have an app to open help the user friendliness? The reason to move away from a snap:// link was that most people don’t have a application that can handle that.

I can only think of that people might be more used to running across unknown file extensions?

yes, people will use Snaptastic to open and install files, like people use eddy to open/install deb files… @peteruithoven

1 Like

Does snaptastic do the equivalent of “snap install foo --dangerous”? If so, that prevents the user getting software updates, bug fixes & security updates.

Snaptastic could use the published snap API and the store API to discover snaps and install them, rather than rely on the website.

snaptastic use the snap native api.
https://valadoc.org/snapd-glib/index.htm

Note these are the developer APIs used by snapcraft. Snapd APIs are the proper way for other clients to interact with snapd and, by proxy, the store.

But, for now, the Store API don’t work.

That API would be interesting, except that that would turn the app into a stand alone app store. This means it can’t be included into elementary’s AppCenter. That’s one of the policies.

So, I cannot provide more input on the technicalities here. But my own take on the matter is that I’d say that if we want linux (e.g. Ubuntu) to be used by a larger cut of the population (non-specialists), we need to have default options that are purely gui and designed with a human centered approach. In usability literature the terminal is considered a specialist tool, leans heavily on user memory for memorizing commands and is very prone to typo’s, to name a few differences between terminal and gui. I would agree to those.

Therefore I celebrated the coming of snap and the snapstore. Firstly because the snap format bundles all the dependencies into a package (like .exe and .dmg for Windows and Mac), and eliminates “missing dependencies” errors. Also it seems that snaps (at least from the snapstore) will be updated automatically and safely. Secondly, because snaps eliminated the use of the terminal and could be added using simple gui actions through the snapstore.

I understand from the above discussion that something is the matter with Ubuntu having some specific tool and the browser will not distinguish different Linux OSs to offer a different link format to other installation tools, right? Perhaps using the visitors user-agent information to detect OS and changing the link format based on that information would help? But perhaps you thought about that already.

Love for snaps and the snapstore.

Best,
Wouter

Hi @Lukewh @peteruithoven and others in the topic,

From what I got from your above discussion, a good solution for now would be:

  • detecting whether or not the visiting browser/system will handle snap:// urls;
  • having a default gui option: either for installing directly or for downloading the file and using gui installer if the browser is incompatible with snap://;
  • but still keeping the terminal installing option close by;
  • use some short and clear texts as explanation.

I have come up with following idea for a possible interface layout: see the two rough sketches below. Using the detection (user-agent or some other protocol detection script as @peteruithoven proposed) the interface could immediately upon the page visit be loaded into one of these options, depending on if the visitor’s browser/system supports the snap:// link or not.

I am new to this forum and would like to contribute. If I should post these sketches/ideas in another thread or if you would like to see it otherwise, please let me know :wink: Thanks!

Anyways, I am very curious to hear what you think about this. If you have additional questions or suggestions, please let me know as well!

The other picture:

1 Like

We have not found a reliable way to do this. If you know of one, we’d be delighted to read it.

1 Like

Just a quick update to let people know we’ve reimplemented the ‘Install’ button on snap pages and pushed it live.
While this solution isn’t a “smart install button” it should allow those with supported GUI’s to open and install snaps with their prefered GUI.

This implementation simply tries to open the snap://<snap_name> in an iframe, offering the CLI install command alongside. There’s higher level, cross-team, work being done to improve the overall experience but for now, we hope this scratches the itch.

As always, feedback welcomed!

1 Like

@Lukewh Great to see the button back, but it doesn’t work here. I’m using the Firefox snap on 18.04 GNOME Shell desktop. Clicking the “View in desktop store” button does nothing.

1 Like