Re: a list!!?!

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

Hey Bryan!

2009/4/1 Bryan Clark <clarkbw gnome org>:
...
> How do you handle new contributions?  In terms of code is there an
> extensions system? planned or real.  I read about the "Activities" however
> it still seems unclear to me, likely that I haven't been following closely,
> what an activity is or how I create it.  Is it best to just dig into the
> code and see what I can make?  If so is there a hello world of sorts?
> Related to extensions is everything going into the gnome-shell core or are
> there outer parts planned?

I'm a bit out of the loop too but here's some background.  One of the
ideas of the Activities overlay is greatly simplify and consolidate
the many ways of switching context.  In the current desktop we have a
very strange and complex combination of menus, launchers, notification
area applets, applets, taskbars, workspace switchers, task lists,
alt-tab, alt-F2, and in some cases a mediocre expose clone.  Very
strange things happen when say, for example, an application is
minimized on another workspace - how do you find it?  Well, one could
always go to Activities to "do something else".  It should show
current windows, currently running applications (though we don't
really have an application-centric system at the moment), recently
used documents, provide access to the full set of applications, have a
rich integrated search feature (spotlightish or google desktopish -
should even search the web as a fallback), and your workspaces.  One
idea that I had that I quickly rejected, as requiring a mental model
that is too complex, is for workspaces to be activity bundles.  Others
seemed to have liked this idea but I remain deeply sceptical.  Another
goal was to try to reduce the reliance on workspaces by defaulting to
only one and allow adding them as needed.  I think that trying to
design around the one workspace model is important for a few reasons:
a) most non-geeks will probably only use one b) it greatly simplifies
the navigational complexity of the system c) it forces us to be more
creative in solving window / task management issues.  I think a lot
more focus has been put on workspace management in the shell
implementation than some of us in the hackfest would have liked (or
maybe it is just me).

Entry into the Activities overlay was to be from either:
 * Windows key
 * Hardware button (a la iPhone)
 * Hot corner in upper left - chosen so that the Activities would
"own" the corner and be far away from other controls such as the
window close button

While reducing the total number of places to navigate to we need to be
careful that a new fullscreen mode isn't disorienting.  So, the design
includes two things that may help.  One is a navigational signpost
always visible at the top of the screen - the Activities button.  It
should look pressed in when in the overlay mode.  This anchors the
user and hopefully simplifies the mental model of where am I.  Another
thing is that the current workspace zooms out as the overlay comes in.
 The idea is to provide a spatial model for this as an "overview".

Another important goal of the Activities was to better support
scenarios where there are only a very limited set of things to do on
the system.  Our current system is designed to have dozens of
applications installed and used.  Menus (especially
cascading/categorized ones) really don't work when you have, say,
three applications installed and used.

General goals that not only apply to the Activities but the rest of
the design include: some degree of resolution independence, supporting
a variety of form factors (with at least some basic design
similarities - reference points), rotational independence, attempting
to be more goal oriented, diminishing antiquated office desk
metaphors, avoiding the "blank slate" problem, and greatly reducing
navigational complexity.

I've been thinking about these things for a few years now and some of
the inspiration comes from studying: the Novell slab, OLPC, OS X,
gmail and Google docs, the Bigboard design wiki, the youtube overlay,
and the iPhone.  And lately a lot of good information on the Windows 7
development blog.

> Outside of code what is the project recommended way to develop docs on the
> wiki?  Do I just add / change things?  I have some of proposed changes that
> I'll let you guys decide how they should be used, if at all.  I probably
> only have an hour or two a week I can put in, but it's yours if you want me
> to help.

> 1) The D word. I wouldn't be afraid to use the word "desktop".  The first
> section of the wiki talks about the "around" the applications in a very
> sophisticated manner that I think intends to avoid the word.  Desktop is an
> overloaded word that you may want to avoid, I can understand the hesitation;
> but it also brings some clarity. YMMV.  However you're replacing the panel
> and the WM; I've always said the desktop isn't much more than that.
>
> 2) Design direction.  You probably don't want me trying to arrange this
> stuff for you, but I'd recommend gathering the existing docs and blog posts
> you have into something more consumable.  For this concept I've lately been
> talking about the Obama campaign and how it had a single phrase that meant a
> lot of things to a lot of people.  "Change we can believe in".  STOP! before
> you read this and this I want to talk politics, sure I do, but not here or
> now.  I'm talking about the design / communication strategy used by the
> Obama campaign.  That phrase they used meant a broad range of things to a
> lot of people.  I'm sure you have already done lots of this already, but I'd
> suggest sharing these ideas in a reduction form like that.  I'm willing to
> try to facilitate anything if you want any help during the process.  I'd
> like to see you have a phrase that inspires and people can believe in.  Some
> quick pointers if I can.  Don't use the word desktop in this part. :)  It
> will only hurt you.  That would be like Obama using the phrase "Democrats we
> can believe in"; not wise.  Your phrase, or as my dear antagonist Burney
> might have said, your "verb" needs to be broad and inspiring, not full of
> details.  Details come later.

Yeah, very much agree with this.

> 3) Your contract.  I fully believe in the kind help that David Eaves (
> http://eaves.ca/ ) has been lending our team and I think it can help any
> other project, especially at the initial stages.  I think you have a healthy
> and excellent community growing so far and I want it to remain that way.  A
> contract simply creates a place you can reference when dealing with issues
> outside of what you feel is fair.  In our projects we're trying to draft
> such contracts.  They started as simple as: "Be excellent to each other" and
> then adapt the contract to fit as we engage further.  This isn't about
> poisonous people, people shouldn't be ingested!  This helps to define your
> project goals and how people or efforts outside those goals can interact.
> I'd recommend reading some of eaves' posts and watching the video to get a
> feel for it.  I believe this is supposed to be (somewhat) easy to write at
> first and continually amended, like a constitution (if that was easy).
>
> dealing with difficult comments:
> http://eaves.ca/2009/03/25/blogging-dealing-with-difficult-comments/
> the video:
> http://brucesharpe.blogspot.com/2009/03/sock-puppets-spammers-and-trolls.html
>
> 4) How can I contribute.  This goes to what I was asking before and is
> likely part of your contract.  I would like to either be with your "core"
> effort, or along side it as an 'Activity' / 'Add-on', or fighting you with
> my own goneme-shell project (tm).  I'm sure the project is moving too
> quickly to have real dev docs, but a couple quick notes on how to get a
> 'Hello World' started and how you expect my type of application could fit in
> to your scheme would be useful. If those exist already, just point me to
> them.  I could make notes on the wiki as needed as well.
>
> 5) Videos.  I've been reading Owen's posts on the shell and they give great
> background.  I think you guys aren't doing yourselves justice without a
> couple intro videos on the wiki page.  I know those are a pain to do or
> maybe there's another project page around that I don't know about with
> those.  But Marina's got a great voice for videos with that accent, Owen can
> do a killer naration voice and then you have Colin as the pretty boy in
> front of the camera.  Just my suggestions :)  You're starting people's
> computer system from scratch so I think selling yourselves correctly is
> vital.
>
> Other than those things, from a technical point of view the Gnome Shell page
> has lots of great information for getting me building and running.  I really
> appreciate your attention to detail on those parts.  Hope I'm being helpful
> and not a bother.

Jon