Re: Ideas and mockups for desktop contexts

[William Jon McCann <william jon mccann gmail com>]

Hi,

Sorry for the super slow response.

On Mon, Nov 16, 2009 at 7:09 PM, David Mend <milarupa yahoo es> wrote:
> Hello everybody.
>
> I hope these ideas might be of interest. This intends to be a shot at the
> "desktop context" concept. I took ideas from these mockups but this one is
> simpler. It is also similar to the recently posted mockup by Jimmy
> Forrester.
>
> The main idea is using Contexts to tell the computer what you are doing, in
> your terms. The only task you will need to do is writing.
>
>
> Naming a Context
> The mechanism to tell the computer what you are doing is naming the Context.
> Every Context has a name. Before you specify what you are doing, the
> computer automatically creates a Generic Context. The names of currently
> open Contexts are visible:
>
> • In the overlay view, next to each workspace.
> • In the normal view, the name of the current Context should be visible in
> the panel; maybe instead of "Activities", but it could go somewhere else,
> specially if breadcrumbs were implemented.
>
> There are two ways to name a Context:
>
> • New workspace: in the overlay, when you create a new workspace with the
> (+) icon, cursor automatically is on the Context name field:
>
> 1. If you don't write anything, the new workspace will belong to the Generic
> Context.
> 2. If you write a new Context name, that new Context will be created,
> opened, and the workspace assigned to it.
> 3. If you write the name of a previously existing Context (whether it is
> open at the moment or not) the new workspace will be assigned to it. The
> name field has autocomplete function.
>
> • Existing workspace: existing workspaces could be renamed with right button
> click or with the "Edit Name" button next to the name (pencil icon in
> mockup). Two situations:
>
> 1. Renaming the Generic Context: whatever you have in the workspace in that
> moment (applications and documents) is assigned to the new name, whether
> it's a new Context or an existing Context. Previous events within that
> workspace will remain within the Generic Context (in recent documents,
> Zeitgeist, etc.).
> 2. Renaming a non Generic Context: this will simply change the name of the
> Context. Names of already existing Contexts should not be allowed.
>
> To underline the difference between Contexts, some eye candy clues could be
> allowed: different colors and backgrounds for desktop, panel, overlay and
> "Activities" button.
>
>
> The Context manager
> Once a Context has a name it can be "managed": see all the existing
> Contexts, reopen them, erase if you are not using them anymore, advanced
> setup if more options are available... I put the "Context manager" below the
> panel and right of the "Find" button. It works more or less like the
> Applications menu. It immediately provides a list of favourite or most
> recent Contexts. To browse everything and do the advanced stuff, you use the
> "More" button.
> The main function here is launching the Contexts. I think the minimum would
> be two options:
>
> • Start: a new workspace for the Context with nothing on it, no windows,
> applications or documents.
> • Resume: a new workspace for the Context, resuming all applications and
> documents that were open the last time the user closed the workspace. Resume
> all last Contexts could be an automatic option when you log in on GNOME. I
> hope you can work this out, I have read about the difficulties.
>
> What Contexts could do for you
> Contexts can remind you the thing you are doing, what you have been doing
> lately, and what you have to do. Things, not applications or documents. I
> think this was more or less the original GNOME Shell concept. The ways
>
> • Remember which documents you opened: different recent documents for each
> Context. This could extend to web history, chats, etc. I am assuming
> Zeitgeist will be aware of Contexts at some point.
> • Remember the applications you opened.
> • Let you stop your work and resume it in the same point with a single
> click. If possible.
> • Limit the applications you can launch, if necessary (I'm thinking of
> parental control and work concentration).
> • Time tracking: Shell could measure the time you spend in each Context,
> like Hamster does now. You could have simple statistics such as: "yesterday
> you spent 1h12min doing <Everyday browsing> and 2h23min doing <Dad's Youtube
> video>". You could see the duration of all Contexts in any given period.
> Measuring the time you spend doing things would become intuitive and
> integrated with your use (it's neither nowadays), and that would be useful
> at professional and personal level.
>
> These basic features would be provided by GNOME Shell but, if third-party
> applications could interact with Contexts, such as a project management
> application, the enhancements and possibilities could be unending.
>
>
> This is all. I'd be flattered if this could inspire any good idea from you.
> Great work, I was far from sold before trying, but now I'm liking the thing
> more and more each day. Thank you!

Surely some good ideas here.  Ideas related to this have come up a few
times.  It was even discussed during the original UX hackfest.  They
are, however, not without problems.  Some of these I expect to be
quite hard to solve - understanding the goal, designing an elegant
solution, and with implementation.  I think that it is pretty clear
that these features would not be a very good match for a large number
of people - at least the way they use computers today.  And even for
the people who are organizers and planners I'm not sure we can come up
with one system that will fit them all.  I suspect (but don't know)
that these habits are idiosyncratic.  Or even where they are not, we
have multiple competing strategies today - theories if you will - and
we need a way for them to be tested and refined before we adopt them.
I think the best way to handle this is to make use of the forthcoming
extension system.  If such an activity group management / workflow
extension to the Shell proves successful then I think we can consider
pulling parts of it into the core design.

Another way to look at this is that boy do we ever have a lot of work
to do already.  :)   And in my judgement these things are higher value
targets for now.  There is always a difficult balance to find between
optimized/focused and modular/extensible architectures.  I think given
our current goals and constraints we are probably doing the right
thing by making sure we get the standard/default design right before
spending too much time on internal interfaces.  But Owen can give the
authoritative answer about where an extension system fits on the
roadmap.

That said, I highly encourage you or others to continue to pursue
these experiments.   They do sound cool.  Hopefully I didn't come off
as too dismissive - just trying to explain how I see it.

Thanks,
Jon