I wouldn't consider that proposal controversial - in my opinion, a huge
change like that is simply not an option. One of the defining
principles of the design is to put the focus on the current task, with
as little distractions as possible. In order to achieve that goal, the
interface was split into two "modes" - one to focus on the activity at
hand, and one to manage activities. There is actually not much novelty
inside the activities overview - almost everything there has an
equivalent in gnome-panel. The novelty is the activities overview
itself - a fullscreen super menu to separate managing workflow from the
actual work (oh well, or play ;-).
Of course you can argue that the concept of the overview is wrong - but
given that it is at the core of the shell's design, you won't have an
easy time taking a stand against it.
Currently, with the exception of the activities button, every element
in the top bar:
- reflects the current "state" of the desktop (currently active
application, current time, current (system/hardware) status,
current user status)
- has predictable behavior as part of a "system menu bar"
(though admittedly the calendar stretches the definition of
a menu)
- allows users to adjust the system to the current task (e.g.
change the volume, adjust the currently used application[0],
indicate that even less distractions are wanted by setting the
user status to "busy", ...)
Moving the view selector buttons into the top bar does not fit any of the
above.
Also the assumption that there is a lot of unused space in the top bar
is wrong - when I change my netbook's display to portrait orientation
(a.k.a. poor man's tablet), both application and user status menu end
up ellipsized[1]. While we are not at a point where GNOME is a valid
option for tablets yet (or any upcoming mobile craze), we shouldn't
discard the possibility for the future[2].
So any Shell UI additions in the context of "Finding and Reminding" will
have to go to the overview - obviously this conflicts with the intended
interaction, where the Journal is accessed constantly[3], but not
surprisingly I see that as a challenge[4] to come up with a better fitting
interaction rather than an invitation to make changes to the core of
the Shell design (and I don't think calling it "core change" is overly
dramatic considering that much of the above has been consistent from
the very beginning[5]).
In my opinion it's also important to keep in mind that we don't need to
restrict ourselves to GNOME Shell - we have an entire desktop to
interact with[6]. For instances, rather than requiring interaction with
the Journal as the primary mean to add reminders, applications which
deal with "incoming" files (file manager, browser, mail, messaging,
...) could offer the functionality. The file chooser currently provides
access to recently used files - does it make sense to expose reminders
there as well? When launched without opening a file, applications could
provide quick access to previously used/reminded files (similar to
Chromium's default tab).
At least from my point of view, "Finding and Reminding" is not about
adding zeitgeist support to GNOME Shell - it is about improving GNOME's
story for dealing with files. Before we can decide which part we want
the Shell to play, we need to figure out the story itself.
Florian
[0]
https://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu
[1] See
https://bugzilla.gnome.org/show_bug.cgi?id=651299[2] Near future actually - it's something actively being worked on
[3] To be honest though, picking an example from you narrative:
- saving attachments
- opening the Journal and locating them
- creating a reminder for them
sounds like dealing quite a lot with something I decided *not* to
deal with now ;-)
[4] Luckily, that one's for the designers, not me
[5]
https://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore[6] Some call it GNOME OS...
