Active activities as Widgets

[Eben Eliason]

> > There are some activities where the chat is an integral part of the
> > participants' experience. In my case, chatter during the Go game may be
> > nonexistent to multiple lines of interactive tutorial per move to
> > razzing and praise from any of the observers. This is why I plan to have
> > a mute button that mutes all chat from observers. Unchecked, the button
> > allows kibitzing from all XO's in the buddy panel that joined the PlayGo
> > activity.

Well, the exact implementation isn't well defined at this point.
Obviously it's advantageous to be able to chat and work/play at the
same time.  Doing this generically is hard because the screen is
rather small and there is no place where such a chat window can always
be positioned such that it isn't in the way.  The overlay idea,
fullscreen or not, is the best general purpose solution we have so
far.  Perhaps if we gain compositing support it can work somewhat like
growl on OSX; perhaps a global keystroke will initiate a new "chat
bubble" so to speak, so that joining in the conversation doesn't
require clicking a button on screen or shifting contexts.  We're not
sure the details yet, but the more seamless we can make it the better.

> > This is not the functionality that I interpreted from Bert's comment:
> >
> >    I thought this was intended to be a feature similar to the frame (and
> >    actually summoned by the frame key), layered on top of the activity,
> >    so it actually would work for *all* activities, Python or not.
> >
> >    - Bert -
> >
> > I may be wrong in interpreting the ubiquitous chat interface as a full
> > screen overlay on top of the application where the child must either
> > chat into the overlay or switch modes to play the game. Are you
> > suggesting that the ubiquitous chat can be relegated to its own panel on
> > the activity's screen so there is no mode switching between chat and the
> > "underlayed" activity

Obviously you gain the most real-estate for the chat this way.
However, this also cuts off the activity completely, if only
temporarily, which may not be what we want in the end.  I think
something slightly lighter would be desired.  The question remains as
to whether or not it is repositionable, since we have yet to introduce
the idea of "windows."

Obviously the push-to-talk method mitigates this problem, since the
"interface" for such a system requires one onscreen button, or even
one well known shortcut.

> > Would either of the two (or more) participants
> > in the activity be able to mute observers? I find both of these
> > functionalities fundamental to the activity experience and the tutored
> > activity experience.

This is an absolute fundamental requirement to any audio/video chat,
in my opinion, for the sake of privacy.  This requirement needs to
make it into the HIG.

> > Also, being that most of the video processing is offloaded in the Geode,
> > I look forward to morphing the chat panel into a video call to my Go
> > opponent. The PlayGo application takes very little resource, so there is
> > plenty of ommf left over to run the video call. It would be the next
> > best thing to playing in the same room.

I think there's something to be said for activities which don't
require much oomf.  I think the "do one thing, do it well" mantra is a
good one, and one that might apply here.  The screen is small, so
dedicate as much space as possible to the board, which has a large
number of squares.  There is very limited RAM and CPU on these
machines, so just because your game doesn't eat too much doesn't mean
you should assume it will be reasonable to consume a significant
amount of these for "add-ons", not to mention greatly increase network
activity.  I'm not sure that a multi-way video conference is even
feasible yet.

- Eben