Re: Named, persistent workspaces
- From: Elia Cogodi <elia cogodi gmail com>
- To: David Prieto <frandavid100 gmail com>
- Cc: gnome-shell-list gnome org
- Subject: Re: Named, persistent workspaces
- Date: Thu, 28 Apr 2011 11:43:06 +0200
On Thu, Apr 28, 2011 at 10:35 AM, David Prieto <frandavid100 gmail com> wrote:
> How about you could assign a tag not only to an app, but also to a file or
> even to a web bookmark?
>
> That way when you opened a tagged app (regardless of the file), web bookmark
> or file (regardless of the app) it would go to the named workspace, or
> create it if it didn't exist.
>
> That, combined with assigning key shortcuts in order to switch to a
> workspace, should solve most of your issues while still respecting the
> current approach. How would you like that?
>
We've already seen that tagging applications doesn't always work,
because the same app has meaning in different contexts and thus
spaces.
But the same is true of files, only even more: the same HTML file
could be opened with an editor in one workspace where I work on it,
with a browser in another workspace where I preview my site. What
should I tag it? "editor" or "web site preview"?
Or let's say that I have a media file, such as a video clip. Sometimes
I'm editing it, sometimes I'm transcoding it, sometimes I'm just
viewing it. For which space should it be tagged?
Note that tools such as Zeitgeist work on the principle that what is
important to identify a user activity (and possibly related ones) is
_the coupling_ between a document and an application (and maybe even
the context should be taken in consideration: workspace used,
geolocation, available networks...). Neither the files nor the
applications by themselves can give you the same high-level
information. But maybe that's best left for a different discussion.
I think you're the one who's now going for a quite complicated model,
full of edge and corner cases, just for the sake of one so-called
"pinnacle" of the dynamic treatment, that is collecting empty
workspaces.
But let's think of what that _really_ means: the system helps you by
removing an empty space automatically because that's devoid of any
informational content. You would do it by yourself, but the system can
do that without asking because you're losing _nothing_ in the
operation.
As soon as you give a names to workspaces and keep them in an planned
order this is no longer true: an empty workspace just by its label and
positioning still carries information, and as such the system won't
collect it until you clear its name/purpose explicitly. Even
_visually_ in the overview a named empty space does at least contain
one piece of information, that is its label.
Learning that it isn't scrapped like ad-hoc ones doesn't sound that
alien to the real underlying meaning of the model, nor that complex
for any user that wishes to use them in a more advanced way. On the
contrary a mechanism of auto-opening and auto-hiding named spaces
according to tags placed elsewhere, and that I still have to reorder
to fit my spacial memory surely is.
Whatever my organizational principles for activities are, they are
high-level ideas much more easily left to the user to handle (giving
her enough tools to make it hassle free) rather than flattened on the
low level objects of applications and files in a very static way.
It's all in the context, and most people seem to be able to handle it
just by labels, key shortcuts, visual overview and spacial memory. I
can't see the great usefulness of all the automatic machinery you're
proposing, sorry. Not for a beginner, nor for a more expert user.
--
Elia
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]