-
Notifications
You must be signed in to change notification settings - Fork 70
Home
-
End users interested in using AppImages, please see https://github.com/probonopd/go-appimage/tree/master/src/appimaged
-
Application deveopers intending to make AppImages, please see https://github.com/probonopd/go-appimage/tree/master/src/appimaged
Target user experience the AppImage founder (probonopd) cares about first and foremost, as (believe it or not) he is an application developer and an end user, too. It is what you get if you just use the tools provided as part of the AppImage core.
We acknowledge that in addition to the Core target UX, a vibrant and diverse community around AppImage has been building different solutions with different target UX, and we want those community-provided solutions to integrate nicely into the larger AppImage ecosystem in a compatible/interoperable way. For this reason, there is also a "Target UX for use in community-provided tools" described further below.
Target persona: Independent application developer with an exisiting build system, e.g., using GitHub and Travis CI. Most likely the developer of a cross-platform application (typically written in Qt, WxWindows, or Electron) that needs to run on Windows, the Mac, and ideally all Linux flavors. (Not: Developer of an application that is made as part of one specific Linux desktop only.)
User story: As an application developer, I want to produce, upload, and publish my application as an AppImage with minimal effort. In doing so, I do not want to change the whole build process; I want to keep my existing (continuous) build pipeline including the tools and servers I already may have in place. Ideally, I can just add a one-liner to my existing (continuous) build pipeline and be done with it. I want the build products to be uploaded to "the usual places" (like GitHub Releases) including signing and updating functionality without me having to do anything special; but I also want to have the freedom to host the build products somewhere else (e.g., my own website). I have no desire (nor the time) to learn the particularities of different Linux flavors (such as operating system vendor policies), I just want my application to reach as many users on as many systems as possible, while I am in full control over the whole process myself. I do not want to be bound to release schedules or random policies of third parties, such as operating system vendors. This is also true regarding the tools for building AppImages.
Target user experience: Add three lines of code to the existing build pipeline: One line to download the tool, one line to make the tool executable, and one line to run the tool. Note that some technical restrictions may make it necessary to deviate somewhat from the ideal user experience.
Target persona: "Mere mortal" Desktop Linux end user coming from the Mac or Windows, e.g., a graphic designer. (Not: Unix expert, Linux distribution fan, system administrator.)
User story: As a user, I want AppImages to "just work" on my system, like .app applications "just work" on the Mac, including being executable, having proper application icons, working file type associations, etc. Especially, I do not want to install anything, nor do I want to have anything be installed or moved around without me explicitly doing so in the file manager. An exception might be adding applications to the menu, for which I might need to deliberately move an application to the system-wide or per-user Applications folder.
Target user experience: Download the tool, double-click to run it. From now on, AppImages are handled like first-class citizens on the Linux desktop, just like .app applications on the Mac.
Target persona 1: A more advanced application developer with specialized needs who needs finer control over how AppImages are put together. A developer of an application written in a scripting language such as Python, Perl, etc.
User story 1: As an application developer, I want to put together an AppDir with manual fine-tuning, e.g., to be able to have fine-grained control over which Python modules go into it. I might be using community-provided tools and workflows (like appimage-builder, appimagecraft, linuxdeploy (and its various plugins), OBS,...) to assist.
Target persona 2: An application developer using Electron, working on a Mac or Windows computer, possibly without even the possibility to run Linux locally. Expects a working AppImage to come out of the Electron app build process without caring about (nor understanding) any of the details.
User story 2: As an Electron application developer, I want to tell the Electron tools to build versions for Mac, Windows, and Linux, and be done with it. Personally I have never seen nor used a Linux desktop, and I have no desire to, but some of my users have asked me to also provide a Linux version of my application. I don't have the time to hink much about it nor to spend much time on it, since less than 3% of my users are Linux users.
Target user experience: An application developer can use specialized community-provided tools and workflows, which use appimagepack under the hood to do the final step in AppImage production - turn an AppImage into an AppDir (including signing, handling update information, publishing etc.).
Functionality: The "create an AppImage from an exisiting AppDir" aspect of appimagebuild without the "prepare an AppDir" aspect.