Updated Fedora Workstation PRD draft

[Marcel Oliver]

Christoph Wickert writes:
 > Am Montag, den 09.12.2013, 16:21 +0000 schrieb "Jóhann B. Guðmundsson":
 > > On 12/09/2013 04:20 PM, Christoph Wickert wrote:
 > > > I think that GNOME is the DE suited best to become the default
 > > 
 > > why do you think it's a) best for it to become the default and
 > 
 > Because I consider GNOME
 >       * fully featured: It offers everything a user needs and has a
 >         large ecosystem of applications you can install if you really
 >         miss something. When it comes to features, only KDE can compete
 >         with GNOME.
 >       * simple to use: The default user experience is straight forward.
 >         KDE offers more configuration option, but configuration is ten
 >         times harder.

In principle I agree with your sentiment.  I am personally biased
toward Gnome's cleaner and more minimalistic interface.  BUT:

For the better or worse, Gnome has forked itself into two user facing
desktops, Gnome and Gnome classic (my suspicion is that the hard split
is more politically than technically motivated, but that's not the
point here).

To summarize an earlier post of mine in this thread: Gnome "modern"
has ambitious, in parts even refreshing concepts, but fails to support
certain workflows (I think this is undisputed) which I believe fall
into the category "workstation usage" (this is up for necessary
debate).

Gnome "classic" is modeled on the old Gnome 2, but feels like a bit
like the unloved stepchild.  It's certainly not as polished as Gnome 2
was in its late incarnations with still significant usability
regressions in direct comparison with old Gnome 2 or modern
competition Cinnamon (which has its own set of stability problems, so
I am not advocating it here as a default, but as something to look at
for good ideas).

So, unfortunately, when saying "default to Gnome" you have to say
which one.  The underlying infrastructure may be the same, but
user-facing it makes a big difference.

 >       * tightly integrated: GNOME developers are trying to design a
 >         user experience, that is not only a desktop but a whole
 >         system.

While I do not dispute this as a worthy goal, when it comes to
usability vs. uniformity/integration, I'd always go with the first.
Unfortunately Gnome applications do not always shine in this respect
(Most of them do, but there are outliers: I mentioned evince in an
earlier post, another example is simplescan with persistent stability
problems and wierd seemingly stateless cropping behavior).  Anyway,
the only point I want make here is that a "workstation" product can,
when in doubt, err more easily in the direction of the more capable
alternative than in a product aimed at the novice user where tight
integration is a more urgent goal.

 > And last but not least we need manpower for it's development and
 > maintenance. And this is where no other desktop can beat GNOME.
 > 
 > >  b) we continue to have a single default to begin with?
 > 
 > The word "default" implies that we need to make a choice and it
 > there can only be a single default. "The Fedora workstation" is
 > supposed to be a unique, consistent user experience.
 > 
 > For me the discussion is not if we need a default or not, I think
 > we hav ea consensus in the working group. And I don't care if the
 > default is GNOME or something else, I care about having integrating
 > all desktops into Fedora without getting in each others way.

I take it as a given that there must be a default, and that this
default must be based on Gnome as this is the default on stock Fedora
and RHEL.  Everything else would be a maintenance nightmare.  Giving the
option to install and use multiple desktops without nasty side effects
is also a good idea, but that goes already for Fedora as a whole.

What is currently missing is a debate what desktop requirements for
workstation use exist, and what could/should be retrofitted into the
DEFAULT install (via extensions/patches/addons...) to make the best
possible workstation product BEYOND what is currently available.  Not
as endless menus of configuration options, but as thought-through
workflow support which covers as wide base as possible without being
arbitrary.

I thought about workstation desktop issues a bit more, and here are
some probably crazy ideas which are come from looking at the
bottlenecks of day-to-day work:

* Right-click launching of applications from the desktop.  Early
  versions of Gnome 2 could launch terminal windows via right click,
  which is obviously inconsistent, so it got removed years ago, but it
  was so incredibly convenient that it still gives me phantom pains to
  this day.  So one needs something better, possibly the taskbar
  shortcuts (or equivalently the applications for which Gnome "modern"
  has special launchers on the left hand side of the application
  screen) could be there, frequently used applications, or frequently
  used documents.  The point is that on systems with multiple screens
  ("workstation"), one really wants to control where to place newly
  launched applications and have the pointer right there to start
  doing work.  Minimizing pointer travel distance is also very useful
  for laptops with high resolution screens and trackpad.

* Confluence of terminal and file browser.  Old nautilus had the
  "spatial" mode which apparently fell out of favor.  I quite liked
  it, although I would not put it on my grandma, for the reason that
  it gave a similar feel to file browsing as it has when using
  different terminal windows when doing CLI interaction on different
  directories or even machines.  So maybe the concept can be brought
  back coming from the terminal side: I usually find CLI work much
  more efficient than visual file browsing, but sometimes the previews
  offered by the latter are incredibly useful.  So what if I could
  switch from the shell to the visual file browser in the same window
  (and back) on pressing a key (or on a mouse click).  So I could
  switch from file browsing to a full-window CLI and back seamlessly,
  and launched applications would behave exactly the same whether they
  are launched from the shell or from the browser - see next point.

* Hierarchical taskbar/window hierarchy.  Both the taskbar and Gnome
  overview mode come to their limits with too many open windows (as
  noted earlier, I find the taskbar somewhat more robust in this
  scenario, but still...).  Windows 7 seems to group windows in the
  taskbar by application - I am not sure about the details because I
  have never really used it, but I have watched people use it.  That
  seems to be somewhat counterintuitive.  I would like windows to be
  logically hierarchical, i.e., windows launched from a terminal should
  be visually the children of that terminal (after all, in Unix they
  die when I close the terminal, so the task would be to make this
  relationship explicit).  In the same way, windows launched from a
  file manager directory view should become the children of that
  directory view.  In this way, one could structure the workflow in
  more than a linear way, send a whole working set of windows to
  another workspace, close a particular project view, etc.  There
  would be many details to be discussed here, but the goal would be to
  improve scalability to workflows involving a large number of
  windows.  (Workspaces address this only partly as it imposes either
  an atomic switch in the visible working set or a joint taskbar which
  does not address the too-many-open windows limitations.)

I am not saying that these concepts must be implemented as described
or as soon as possible.  These are rough ideas which may or may not be
workable, but I would like to draw attention to the need to discuss
"modern desktop trends" driven by the advent of large and multiple
screens, of continuing importance of the CLI and ways to better
integrate it with the rest of the desktop, and of supporting "big" and
"complex" tasks.  It is certainly fashionable to discuss convergence
between desktop and mobile these days, but one needs to include the
"big" end in the discussion as well...

--Marcel