Top-level package names, UX questions

[Martin Albisetti]

On Mon, Mar 16, 2015 at 7:31 PM, Mark Shuttleworth <mark at ubuntu.com> wrote:
>
>  * you can only install one foo at a time (choose foo.beuno or foo.jamie)
>  * you must use it as foo.command

After talking to Alexander for a bit, I still feel this is the best
trade off for the command line experience but broadening the view a
bit to the phone and desktop, there's something worth thinking about
as well.

In the command line, the commands are the UI. This works great, feels snappy.
However, in a GUI (webdm, touch, future desktop), you install apps by
looking at titles, descriptions and icons. You will be, unless we make
some changes, unaware of what an app's package name is. You don't care
on GUIs where you see icons and names what a package's name is, you
click on icons and titles.
The proposal we have on the table pushes an awkward interaction there,
where all GUIs will need to be aware of the fact that the same package
name can be provided by many developers and you can only run one at a
time. You'll essentially see 3 "calculator" apps, but 2 of them will
have the same package name when a third doesn't. The result of
installing one or the other, which all look alike, will be different
(one will be co-runnable, the other will want to replace your current
one). On the desktop it'll be even more awkward, as sometimes you'll
use the command line, sometimes you'll install from the scope.

I think if we felt this was the right path to go down, even in GUI
scenarios, we could think about how to make sure developers understand
that when they pick a package name, they are potentially becoming an
alternative to an existing set of apps. I fear it might make things
harder down the line for us, as we might end up with a dozen apps that
are called "evolution", none of which we feel is the correct use of
that package name, and we have to rename a dozen existing applications
with a user base.

I can think of 2 paths to follow:

1) Circle back to unique package names, drop developer extensions for
them and have people create their own forks with a different package
name "apache_beuno".
2) Allow running apps both by package name "apache.command" or full
package name "apache.beuno.command", the latter used by GUIs and the
former by humans from a command line

1 feels cleaner from top to bottom, but it puts a bit too much
emphasis on picking the right name from the beginning, going back to
Gustavo's comment on "people should be able to pick an identifier
without being concerned about future unintended conflicts".
2 I think addresses both sets of UIs, at the expense of a difference
in behaviour if you switch from the GUI to the command line.

There might be more options, I'd love to hear them!

-- 
Martin