UX improvements

[SolarLiner]

I think this launcher is the better option for integrating AppImage-packaged applications into the system (see my comment in AppImageCommunity/appimaged#5), however, there are a few tweaks which I believe will improve User Experience in using the launcher and AppImage in general.

I think the most "visible" tweak would be an overhaul of the integration prompt. Right now there is too much text, and especially when it comes to computers, reading is hard; as a result, users will just click through the prompt without reading. Instead, by presenting information about what matters to the user (mainly, Application metadata), with an expendable "more info" panel with some information, and a link to appimage.org. I've designed an example prompt in Glade, using GTK - maybe a version of that could be made in Qt following KDE design guidelines (for best results, both prompts could be available in -gtk and -qt packages).

A similar prompt could be shown before removing the application:

In order to bypass the integration step, the user could manually set the executable bit, allowing the application to be launched directly.

[2635599]

a bit limited. should ask if the user actually wants to integrate / uninstall. make them think before doing.

[SolarLiner]

That's what the prompt is doing. Users don't really care or want to know the specifics of AppImage vs. other means of installation is. They want their app accessible like all others. This way, the launcher provides what the user expects (an installation process, even though technically it's just the integration to the system), and besides, the action is really not critical since all the launcher does is put a desktop file and move the AppImage to the Applications folder. Clearer information on how to remove the application could be needed, but if the option is there in the desktop file it's a non-issue since "right-clicking for more options" is behavior that's learned pretty quickly when using a computer (but that doesn't prevent documenting the feature).

[SolarLiner]

Also, I should add that it being limited is the point. Too much text or information and the user will more likely refrain from doing anything rather than read.

[2635599]

"That's what the prompt is doing", that's pure bull. do you have any idea how many peeps need that? i deal with people not thinking before they click through on a daily basis.

[SolarLiner]

But what's the worst that could happen as a result here? The launcher moves the AppImage file into ~/Applications and copies the desktop file from within it. That's nothing so critical it should have a warning dialog.

Furthermore, non-legitimate uses of warning and error dialogs is what causes users to "not think before they click through". By putting a warning dialog here I would make the problem worse, not better.

[2635599]

it's not a warning dualog and you know it. and the bottom half of your post is a flat out lie.

[SolarLiner]

¯\_(ツ)_/¯ man, please put forward arguments on why having a "warning dialog" (that's the name I'll stick with unless you tell me what it is) is good in this case, despite the low-risk integration step.

[Lvaskz]

I really like this

[Lvaskz]

It looks great!!!

[TheAssassin]

The UI looks nice, no questions there. Also, @azubieta's old PR contained a lot of what's needed to make something like that.

UX wise, a few remarks:

• we may not lose the "run once" feature, I'd rather have "run once" instead of "integrate without running"
  • you're double clicking an AppImage, so anything you'd be prompted there should eventually lead to an execution of that app
  • please consider adding a "don't ask again" question, so people can permanently opt out of the dialog when they don't want to integrate the AppImage at all
• do buttons really have to be on top? is that modern nowadays; can you please link a reference where this is discussed?

[SolarLiner]

you're double clicking an AppImage, so anything you'd be prompted there should eventually lead to an execution of that app

That is a good point. My point of view was that the user wants to integrate the apps, and optionally use them as well. Since the Launcher would only register a MIME handler, making the AppImage executable would bypass the Launcher entirely and just run the application once. However if the Launcher also hooks into binfmt, this point is moot.

If we are to "reverse" the action/checkbox, I'd need to find a good label text for the checkbox ("Also make available to the system"? "Also install into the system"?). Remember that the user isn't expected to either know or care about AppImage, therefore any technical jargon or AppImage-specific language should be avoided.

please consider adding a "don't ask again" question, so people can permanently opt out of the dialog when they don't want to integrate the AppImage at all

I don't think that is a good idea. The use needs an explicit call to action because the change is significant (installers on Windows are never silent, and the various software centers at least ask for root access (as necessary) therefore teaching users the behavior that it will be asked to confirm before continuing. Therefore even though integration in AppImage isn't really a critical action, it helps feeding into that learned behavior. Also, adding an option to not show again means we need a way to undo that setting - which is hard without having a settings page, which in turn might be overkill for just a launcher.

Even in the case where we finally add a "don't ask again" checkbox, we'd still need to notify the user about doing something (through a notification, most probably).

do buttons really have to be on top? is that modern nowadays; can you please link a reference where this is discussed?

This is me using the GTK Header bar because I like it, and it follows the GNOME HIG. As I mentioned in the issue the most important issue is that the dialog feels integrated with the DE, and therefore it must respect GTK/Qt HIGs for the respective dialogs.

[TheAssassin]

If we are to "reverse" the action/checkbox, I'd need to find a good label text for the checkbox ("Also make available to the system"? "Also install into the system"?). Remember that the user isn't expected to either know or care about AppImage, therefore any technical jargon or AppImage-specific language should be avoided.

"reverse" is the wrong term. What we call "integration" is basically a) move into ~/Applications and b) integrate into launcher. If you want to integrate, both actions will be executed. If not, the AppImage is left unmodified, and it's just run.

If you need a user story, think of mine: I often test AppImages I build locally, and many others do, too. I don't want each of them to be moved around and integrated: in 50% of all cases, the AppImages just shall be run once, and integration would make things only complicated. If there were no opt-out for the integration, I'd probably never consider installing/using AIL.

Regarding "do not ask again", that's a commonly requested UX element, and I can understand that very well. You don't necessarily want to be asked on every invocation whether to integrate or not; there should be a way to say "yes, I'm sure I never want this to be integrated". In the end, you can still move the file to ~/Applications and it'll be integrated by appimagelauncherd. It's not a "final" decision.

Even in the case where we finally add a "don't ask again" checkbox, we'd still need to notify the user about doing something (through a notification, most probably).

Not sure what you mean, can you elaborate please?

This is me using the GTK Header bar because I like it, and it follows the GNOME HIG. As I mentioned in the issue the most important issue is that the dialog feels integrated with the DE, and therefore it must respect GTK/Qt HIGs for the respective dialogs.

I see, this is a GNOME 3 weirdness then. Welp, I'm open to using whatever HIG is there. I am not a GNOME 3 user, so in the end, I won't see it, right? I can continue to use the Qt version of the app on my XFCE. And you're absolutely right, a consistent look and feel is important.

[SolarLiner]

"reverse" is the wrong term. What we call "integration" is basically a) move into ~/Applications and b) integrate into launcher. If you want to integrate, both actions will be executed. If not, the AppImage is left unmodified, and it's just run.

Hah, I didn't write what I meant - by "reversing" I meant "Making the button be 'Launch' and the checkbox be 'integrate', instead of the currently proposed way". I do agree that launching the application is important, however, this is why I initially thought of letting the user chmod +x the AppImage as a power user feature to run without integrating. I don't think anybody not working with AppImages would need that feature.

The problem with having the button say "Run" is that the user will perceive the dialog as an unnecessary hurdle - however "Install" or "Integrate" would indicate more clearly the intent of the dialog, and of AppImageLauncher. I guess I could add a second button with "Just Run" instead.

Regarding "do not ask again", that's a commonly requested UX element, and I can understand that very well. You don't necessarily want to be asked on every invocation whether to integrate or not; there should be a way to say "yes, I'm sure I never want this to be integrated". In the end, you can still move the file to ~/Applications and it'll be integrated by appimagelauncherd. It's not a "final" decision.

So the daemon takes care of the actual integration? I guess manually moving the AppImage to ~/Applications might be a good way to bypass the dialog then. Also that means that the "move to ~/Applications` checkbox can't be effectively be tied to any dialog action since the daemon is what does the integration.

Not sure what you mean, can you elaborate please?

I'm going from the point of view of someone using the system without knowing anything about it - without any notifications, the user downloads an AppImage, double click it, and uses it once, and never realizes the system now has an entry pointing to the AppImage, and worst, AIL has moved the file away and the user doesn't know what happened to it. I can imagine one of two things happening:

• The user thinks the computer ate away the file, and redownloads it
• The user thinks the computer is broken ("clearly the file was there last time, why is it not showing it?")

In both cases this would lead to frustration, and for some users with the know-how, a bug report on the file manager, the DE or the distribution, which is a waste of their time. Therefore AIL needs to notify the user about what it's doing in a way that is intuitive (read: doesn't need the user to think). The dialog is the most expressive way to deal with this, as it clearly shows the user something is going to happen when it clicks the "integrate" button, but in the case where a "don't show again" option exists, we'd need to still notify the user about taking action, because they might not be the user who configured the machine or AIL / might not remember AIL is installed or that they checked the box.

I see, this is a GNOME 3 weirdness then. Welp, I'm open to using whatever HIG is there. I am not a GNOME 3 user, so in the end, I won't see it, right? I can continue to use the Qt version of the app on my XFCE. And you're absolutely right, a consistent look and feel is important.

Agreed. I see the headerbar is a bit controversial, but I actually like it and since it's used throughout GNOME, I'd figure I'd use it.

[probonopd]

Check how it works on the Mac. No such dialogs needed at all. Much more elegant.