Hacker News new | past | comments | ask | show | jobs | submit login

>Especially with the landscape now, asking a likely non-technical user to download, install and launch software is a lot to ask and will impact your conversions if you're not an established product.

With the landscape now, installing and launching software involves clicking on it in the app store and waiting a few seconds for the installer to finish.

With the previous landscape, installing and launching software involved, for Windows, downloading an installer, double clicking on it, maybe going through some default settings, and waiting for installer to finish. For Linux, instead of downloading an installer, you pull it with a package manager, maybe go through some default settings, and maybe wait for the installer to finish.

It was never that complicated unless you were compiling all of your software from source, but that's an extreme fringe minority in the whole universe of software consumers.

The process of "installation" in the SAAS model is merely replaced with registration. Instead of downloading the program, you're uploading your credentials. The complexity is still there, because it has to be, but it was never that difficult for the end user to begin with. And the process of registering for a site is, arguably, more complicated than native software in many cases. I don't have to deal with individual passwords for each of my native apps, for instance.




Downloading is the problem. Twenty years ago, you would go on the internet and find an installer and just trust it.

Now days, you have to figure out which of the 10 download buttons is the real one. And then you have check hashes if you want to validate that you actually downloaded the installer that the publisher released.

I think that browser based software is a huge step backward in terms of richness of user experience. I can't believe that, in the year 2019, GSuite has usurped Outlook and the traditional native office applications in the corporate environment that i work in. But here we are.

But, there's no denying that any friction for the user getting the software will drastically reduce their likelihood of using it at all.


>But, there's no denying that any friction for the user getting the software will drastically reduce their likelihood of using it at all.

I'm sorry, but the fact that the dominant paradigm for software use has been, and still is native (I'm counting apps as native here, because they're installed, even though in some cases apps are just wrappers around a website) disputes it.

If people want to use some software, moreso if they need to, they'll put up with installing it. What you're describing is really only an issue for web services, and would maybe only =apply to native software that worked according to a subscription model, which most doesn't.


> For Linux, instead of downloading an installer, you pull it with a package manager, maybe go through some default settings, and maybe wait for the installer to finish.

You are assuming that the software in question is both packaged for the distribution you use and that it is available from the default servers for your package manager (and that the packaged version is recent-enough for your purposes).

The software installation landscape for Linux is a lot more complex than this, and for rather a lot of software, these assumptions break down.

Here are the Linux install pages for just a few examples of popular end-user applications that are actually available for Linux:

https://calibre-ebook.com/download_linux

https://www.dropbox.com/install-linux

https://www.openshot.org/download/

Snap and Flatpak promise to simplify the provision of binary installers for Linux so that developers don't have to create both a DEB and an RPM, much less an install script that has to be run as root, but that ends up pushing users even further away from the package manager, not closer.


> With the landscape now, installing and launching software involves clicking on it in the app store and waiting a few seconds for the installer to finish.

Even when it really is that simple, any extra steps are going to increase drop-offs.

> I don't have to deal with individual passwords for each of my native apps, for instance.

Single sign-on solves this and you can create web apps that don't require initial sign up to use. Any desktop software that allows collaboration is likely to require a sign-up process as well so the desktop solution is always going to be more complex to set up.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: