Guidelines draft: Apps and launchers

[Pete Travis]

On Aug 19, 2014 1:52 PM, "Elad Alfassa" <elad at fedoraproject.org> wrote:
>
> Hi all.
>
> Since apparently we can't remove anything from default without having a
"policy", and we can't ask packagers to fix their software either, I have
to write this message.
>
> Apparently, not including a package by default is seen as "punishment".
So, instead of doing actual work on bugfixing or debugging Fedora 21, or
working on our website so it'll be ready for release time, I have to write
this email message. I assumed the whole idea of Fedora.Next was to reduce
bureaucracy and making sure we ship a high quality product. Apparently, I
was wrong, and the point of Fedora.next seems to be *increasing*
bureaucracy and having to discuss and write a policy for every one line
commit we do.
>
> If you are out of the loop of the recent events, look at this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1131248
>
> ---------
> Now, enough bitter sarcasm, here is my draft:
>
> In the following policy, I differentiate between "app launcher" and
"app".
> An "app launcher" is a desktop file+icon that is shown in the application
view, clicking on it would launch the app.
> An "app" is an application as defined by the GNOME 3 HIG (link TBD when
HIG is published)
>
> As always in policies, mandatory items are marked with the words "must"
and "must not", the rest is nice-to-have.
>
> App launchers in Fedora workstation *must*:
>  * Have a unique 64x64 launcher icon (the same icon MUST NOT be used for
one default launcher).
>  * Have a matching High Contrast icon.
>  * Have a name that is either short enough to not be elipsized by the
shell or immediately recognizable even when elipsized.
>  * Have a comment field in the desktop file with a one line summary of
what the app is.
>
> App launchers in Fedora workstation *should*:
>  * Launch software that is an actual app - see the GNOME 3 HIG on the
exact definition (link TBD when the HIG is published)
>  * If the app is not an actual app, it should have the appropriate
desktop file categories to be placed in the Sundry folder in GNOME Shell.
>
> Apps in Fedora Workstation *must*:
>  * Not depend on / pull in other apps OR app launchers.
>  * Have exactly *one* app launcher - ie. two launchers to two separate
parts of the same app is not allowed.
>  * Be packaged separately (subpackages are okay) form other apps OR
plugins.
>  * Installable and removable independently from within GNOME Software,
unless part of the "core applications" set, in which case they must NOT be
removable.
>
> Default apps in Fedora Workstation *should*:
>  * Have appdata metadata (soon to be turned into a must).
>  * Have a good reason for being included in the default set, especially
if not considered part of the core desktop experience by the GNOME upstream.
>  * Start in under than 10 seconds (on modern hardware).
>
> An app or launcher that fails to complies with these guidelines MUST NOT
be included in the default install.
>
> Furthermore, if an app that doesn't follow this policy is include by
default, it should be considered a Final Release blocker until the app is
fixed to conform the policy or removed from the default install.
>
> ----
>
> Each line in this policy has a very good reason behind it, and I hope I
don't have to explain each one of them separately. Following this simple
policy will ensure a polished and good user experience in viewing,
launching and installing applications.
>
> Note that I'm being a bit lax on the requirements here. I'd place "launch
an actual app" in the "must" column but we tried that before and it didn't
work due to (silly) internal project politics, as people want things like
release notes have a launcher by default.
>
>
>
> Feel free to reply with your opinion, and put it in the wiki somewhere
when it's officially approved by the WG (which, to remind all involved
parties, I'm not an official part of)
>
> -
> -Elad Alfassa.
>
> --

First, your approach here comes across as punitive.  Maybe that's just
frustrated delivery tainting good intentions, but between this post and the
bug that prompted it, the connotation is there.  There's an effort going to
improve and create AppData files - a similar approach of offering guidance
and contributions is sure to get more traction.

Back to the issue, you have:

1. A UI that shows all known (via .desktop file) graphical applications,
without restrictions, to the user.

2.  Some packages provide graphical applications of a class that you don't
want to show in the UI by default.

So you have at least two avenues to deal with the situation:

1. Filter or categorize into submenus the applications you don't want to
show in the default UI based on the existing desktop file metadata.

2. Draft a complex and subjective exclusion policy that targets
applications you don't want to present to users, requiring a lot of
packaging effort that may adversely affect other environments.

Okay, maybe *I'm* sounding a little bitter now, but come on.  If something
needs to change to meet your design goals, you can still be considerate and
cooperative, and allow the possibility that the design might need to change
to accommodate the software it presents.

--Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20140819/5c4236c7/attachment.html>