Flathub Goals

Allan Day edited this page Oct 7, 2016 · 36 revisions

This is a UX design page for Flathub. It details user experience and functional goals for the design, along with possible workflows.

High-level goals

  • Easy and obvious for an application developer new to Flatpak to build and publish an app .
  • Site organisation should be clear and as simple as possible
  • Reflect and reinforce Flatpak concepts and workflows
  • Modern and attractive in appearance/experience
  • Integrate with developer tools

What's Flathub for?

  • Part of the process of getting an application into the Flatpak Store
  • A way to make builds available to others for testing - making an app public but not offering to every user through the store
  • Shared builds between team members
  • Automated builds
  • Builds on multiple architectures
  • A way to explore other people's builds

Developers are likely to start using Flathub after their application is already in development, and after they have started using Flatpak and flatpak-builder.

Users

  • Application developers - build, test and publish applications
  • Admins - monitor the infrastructure, review published applications
  • End users
    • Applications will typically be installed through a local app store app
    • Will likely want to use Flathub as a public/web presence for Flatpak apps
    • Might need information about how to get Flatpak apps, depending on their distribution/desktop environment

Initial feature set

Accounts and project admin

  • Register and authenticate as a user
    • Required information: name, email address, password
  • Edit user details
    • Picture, name, email address, website/Github URL, bio, password...
    • Possibly upload a GPG key for your user account; need to figure out the signing story before deciding about this
  • Create apps (each app is a single OSTree repository)
    • Identify yourself as the author of the app, or as a member of the official development team (will likely have to be done through the domain)
    • We're only going to accept open source projects in the first instance; will need a statement about this somewhere
    • Might need to be some statement or argeement about licence compliance
  • Edit app properties
  • Remove apps
  • Apps always belong to a user (or a team, but that'll come later); this is reflected in the URL. Example: "flathub.com/alexl/gnome-contacts"
    • This makes it possible for different people to have builds of the same app; or people to fork a build
    • Needs to be possible to migrate apps from user to user - say if someone wants to pass on maintainership

Branches

  • Add and remove branches
  • Each branch points to a build configuration (made up of a build file and optional dependent files) that is stored in a Git repo (somewhere else)
  • Guide developers to use standard branch organization and naming
  • Allow branches to be set up as nightly builds
  • Make branches available to install for testing purposes (could be presented as a "public" property)
  • Migrate a commit from one repo/branch to another. For instance, you may have a testing repo where you build things. Once tested you can then take the latest build from that and put (+re-sign) in the stable repo that you give to users. (This is the build-commit-from flatpak command.)
  • We might want to require branch names to be prefixed with the username/teamname (at least for builds not verified as official). This ensures that they are always parallel installable, and it makes it obvious where the build comes from.

Building

  • Trigger a build in a branch through the website, a CLI or an IDE
  • Notify developers when a build has finished
  • View information about previous builds
    • Which version of each module was built
    • Useful debug information if a build fails
    • Logs for later debug use
  • See an overview of builds for each app - build history, queued builds, which builds have been pushed where

Publishing

  • Publish an app in the Flatpak Store for the first time; each new app must be reviewed:
    • Ensure that the publisher is the app author
    • Check that the app is what it claims to be
    • Check that it has appropriate permissions
    • Possibly some automatic security tests
    • Inform the publisher when their app is on the store (or has been denied)
  • Push updates to the Flatpak Store version
    • These won't usually require review; possible exceptions - if permissions/app name/icon changes
    • Might want to run automated tests each time
  • Revert an update to the Flatpak Store version
  • Remove an app from the Flatpak Store? How would this work?

Tooling and integration

  • Commandline utility to upload build inputs, trigger builds
  • Application reporting and revocation - users need a way to report an application if it misbehaves in a serious way; it should be possible to remove apps from the store and notify users who already have it installed
  • Automatic scanning of builds, useful for everyone, but very important as a first step in reviewing for pushing to the app store

Documentation/public face

  • Present an attractive, easy to understand landing page for new visitors to the site
    • Should explain Flathub to potential users, invite them to try it out
  • Browse and search for apps and show details about each one
    • What details to show?
  • Developer documentation will be needed for the site; how will this fit with developer documentation on flatpak.org?

Site administration

  • Interface for reviewing apps before they are published in the Flatpak Store
  • Notifications for admins when new apps require review
  • ???
  • ???

To be figured out

  • Allow releases to be signed using GPG. Current running theory: the infrastructure will automatically generate a key for each repository. The user will then optionally be able to authenticate using their personal GPG key in order to make a release.
    • What gets signed exactly: branches, repos, releases?
    • Will we require installable versions to be signed? This could just apply to the Store or to any installable version.

Future feature set

Functionality and features that we might want to add later:

  • Organizations - to make it easy for groups of people to work on multiple projects at the same time
    • It will be possible for apps to belong to either a user or an organization
    • Will need to include permissions for organization members: start builds, add/remove branches, publish to the store, add/remove apps, able to install certain builds (beta/alpha, etc), and so on
  • For users: a web-front end for the app store, which allows apps to be installed and managed on your device via the website, like Google Play
  • Conflict resolution for claims to names and trademarks - in case someone who isn't the author registers the name of an app
  • Allow app developers to view status information about the apps they've published in the Flatpak Store
    • Ratings
    • Number of installations (segmented by distro, version, etc)