Mudlet: Enable two-click Mudlet connection for Windows

[vadi2]

We need to be competitive with web clients in terms of ease of use for new players. Compare how easy it is for a modern MUD website to get connected:

1) go to https://www.lusternia.com
2) hit "Play now"
3) enter character login info

That's it, you're done.

Compare this to Mudlet for Windows:
1) Go to MUD website
2) Click on Mudlet download link
3) Run Mudlet installer
4) Hit "Yes" to UAC prompt
5) Click Next > to start the wizard
6) Agree to the GPL license
7) Click Next > to agree to the install location
8) Click Next > to get past shortcuts selection
9) Click Next > to begin the setup
10) Finally click Finish to launch Mudlet
11) If you're lucky, select the MUD you were hoping to play. If you're not, copy/paste the server and port settings.
12) Finally hit Connect
13) Enter character login info

As you can see, the time it takes is significantly longer - and any second more decreases the likelyhood of someone going through. It's obvious, a web client is a ton easier to get started with.

I think we can do a lot better here and reduce it down to 2 clicks:
1) Go to MUD Website
2) hit "Play now"
3) Run .exe that gets downloaded
4) enter character login info

2 clicks because the first one is to hit "play now" and the second one is to just run the .exe. That's it - installation is seamless and Mudlet magically knows which game to connect to!

How? The details of the implementation are flexible, one idea I have is:
1) Provide a service for MUDs to register their MUD with Mudlet. When they register, they give the server and port, and get a name
2) Then give them a link they can use on their website that'll download the latest Mudlet
3) This Mudlet will be called Mudlet-3.5.0-for-lusternia.exe or something like that
4) On the first launch, Mudlet will download the the map of mud name: {server, port} from mudlet.org
5) On the first launch, Mudlet will also inspect the name of the binary. If it has for-%s in the name, compare the name to the list, autocreate the profile and autoconnect to the said server and port.

I'm targetting Windows specifically since on Linux and macOS we don't have an annoying wizard to deal with, and as 70% of the 3.4 downloads were for Windows, we'd cover a lot of users by improving it there first.

[vadi2]

Thoughts @Mudlet/core-cpp @Mudlet/infrastructure?

[keneanung]

The idea is good, but the proposed solution sounds problematic.

The Mudlet.exe doesn't know the installer name, so we have to re-package a number of differently named Mudlet.exe and store them all on mudlet.org. It also means that people using this way of getting Mudlet can end up with multiple versions of Mudlet installed. If we solve this, it only works for the first installation of Mudlet.

Maybe a three-click approach for first installation and one-click for subsequent uses would be easier: When we switch to squirrel, download and installation are 2 clicks. And if we manage to register Mudlet to telnet:// URLs, it's the third click (and the only one if Mudlet is installed).

[vadi2]

I want it to be smoother. Squirrel is assumed for sure, it cuts down on the installation fuss by a lot.

We wouldn't have to re-package Mudlet, just literally rename the installer on-demand as we serve it. We'd also need to make the installer clever to just launch Mudlet if the same version is already installed.

What do you think?

[keneanung]

But as I said, the application doesn't know anything about the installer's name. And there's an additional pitfall: What if the user renames the installer when saving to the computer?

[vadi2]

Need to think about the application and installers name. Maybe we really will need to generate this per-MUD - but at least not for every user, so it'll be a doable thing. If we go down that path we don't have to worry about embedding the MUD in the name either.

telnet:// support is nice of course but it'll be complementary to this: I'd really like to avoid installing, going back to the website, then going back to Mudlet if possible.

[SlySven]

1. Agree to the GPL license

📄 Well that is one stage that shouldn't be there IMVHO :rage: - __the terms of the GPL are that you do _not_ have to accept any terms or conditions to _USE_ the application__ - they only apply if you wish to _distribute_ what you have got to other people or use the code of the licensed software in anything else that you wish to distribute to others (outside your organisation if that is relevant)...!

[Kebap]

Having that information in the installer's file-name only seems problematic indeed. Not sure if there is another way without building many different installers, each with the respective MUD hard-wired into them

[vadi2]

We wouldn't need to build Mudlet every time, just the Squirrel wrapper and sign it. That seems pretty fast to do - something we could afford I think. However it would require infrastructure in place so people wouldn't just spam it nilly-willy - so you'd have to sign up with a captcha and be rate-limited. Sounds like a lot of work to do for the whole thing...

[Kebap]

How many MUDs would we expect to use such feature? If it is in low region, we could handle that manually and gauge interest, before developting another whole uinfrastructure around it. Manual contact to MUDs developers seems helpful in other regards as well

[vadi2]

Well, that's a fair question. I'll ask around.

[vadi2]

So moving this discussion on - you no longer have to agree to the GPL license and the new installer significantly cuts down on the steps needed in Windows:

1) Go to MUD website
2) Click on Mudlet download link
3) Run Mudlet installer
4) Installer does not require UAC permissions, installs and launches Mudlet automatically within 5s. If you're lucky, select the MUD you were hoping to play. If you're not, copy/paste the server and port settings.
5) Finally hit Connect
6) Enter character login info

I still want to cut it all the way down to 3 steps. Ideas?

[Kebap]

It seems like steps 1, 2, 3 are hard to get rid of, so any way to include configuration in the downloader already would remove steps 4 and maybe 5 . Maybe have multiple downloads available with dropdowns on the website. On the other hand, not make it too complicated for new exploring folks. Then again, step 6 seems necessary for privacy reasons. This step is also included in web-clients. I say, we are already stellar when we get to 5 steps or less. Even now it is awesome. The main point to improve is around step 4 and 5, this is also quite confusing or can be to new users, with the automatic popup and suggested connections, can be confusing where to go from there. I also heard it is hard to grasp for the visually impaired users. Maybe think on this some. Sorry for rambling, just my $0.02

[hluaces]

My two cents (thinking outside the box, I guess?):

1- Make Mudlet register a custom browser protocol, something like: mudlet://yourmud.org:port which, on click, would ask Mudlet to connect to said mud, creating a new profile on the fly if one with those connection values does not exist. If this is not possible then the rest of this post is bogus.

2- Create a web service that could be distributed to the muds which does the following:

• Checks if the visitor has the mudlet:// browser protocol running.
• If it does, output a mudlet://yourmud.org:port link via Javascript, which should open Mudlet and connect with no more hassle.
• If it does not, instead serve the mudlet custom installer for the mud.

3- Either distribute the web service to the muds so that they host and tweak it (note sure if desirable as it involves playing around with installers) or create a mudlet.org/play where MUDs could register to create their own "play now package". The register option is optional just to prevent abuse or to gather some stats.

If this is possible it would result in the following flow:

The user does not have mudlet installed:
1- Users goes to their mud's website.
2- They click on "play now" wich redirects them to "mudlet play" or their on self-hosted webservice. A custom installer is served.
3- Installer is executed and profile is loaded and connected.
4- Login info.

The user does have mudlet installed:
1- User goes to their mud's website.
2- They click on "play now". A mudlet:// browser handler is served.
3- Mudlet is executed and the profile is loaded.
4- Login info.

[SlySven]

Um, I was just looking up on the details for the mudlet.desktop file and started reading through Freedesktop.org's _Desktop entry specification_ - that is interesting and it seems that we could register the Mudlet application against some mime types - it might be that we should add a DBus interface but I think there is a QDBus class for that. That may give the leverage needed to allow telnet: scheme URLs to work - but we ought/will need to extend the command line interface to at least allow existing profiles to be activated if not to also allow _new_ ones to be defined; the latter will then make connecting to a new MUD a lot simpler. I think this should be a 4.0 target.

[vadi2]

Okay, but this ticket is about Windows as it says in the title, since every OS is very different in how they handle this let's keep the conversation separate so it doesn't get confusing.

[SlySven]

Ah, I hadn't realised that the underlying DBus port to Windows was incomplete otherwise it might have provide some of the links in the chain...