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.
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.
@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.
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?
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.
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 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!
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.