[sugar] alt-tabbing to the Journal

[Eben Eliason]

On Wed, Oct 8, 2008 at 3:26 AM, Gary C Martin <gary at garycmartin.com> wrote:
> On 8 Oct 2008, at 03:51, Walter Bender wrote:
>
>> The bottom line is that, at least as far as the XO is concerned (and
>> other machines with limited memory and no swap) the list of activities
>> to tab through, with or without the Journal, is going to be a short
>> list, so is it really such a pressing issue?
>
> For tabbing, I think one frustration here is the current issue with tabbing
> where the delay is way too short before an Activity you're tabbing past is
> pulled into focus (I'd argue there should be no auto delay focus, only focus
> when alt key is lifted, allowing you to easily skip items in the stack).
> Currently in 8.2, accidentally tabbing the 'wrong way' through the active
> instances on the XO and getting shown the wrong thing (usually Journal given
> only having a few activities running) is painful enough time wise to
> distract you from whatever goal you had in mind. Example: TurtleArt, and 2 x
> ImageViewers showing some screen shots of different brick code you want to
> reference. Tabbing between TurtleArt and the images you trying to reference
> is constantly intruded upon by the redraw, and update of Journal – if you're
> just mucking around, it's less of a pain, but if you're actually trying to
> 'get stuff done' it can get quite annoying pretty quickly.
>
>> I'd love the same passion developed to some of the issues/topics that
>> impact the learning. How can we make the Journal better, regardless of
>> how we open it and regardless of whether we consider it an activity or
>> part of Sugar core?
>
>
> I guess most interested parties on the sugar list are more technical than
> pedagogical types. Both my parents were teachers, and when computers started
> to make their way into some of their lessons/labs, way back when, I seem to
> remember they would come home somewhat bemused, having been handed boxes of
> cables and computer kit. As an ~11yr old I would set it up, get things
> going, and show them how to load-up and use the software. It's an
> interesting generational shift, I wonder what new idea is going to come
> along and be so far from our expectations that we'll be too inflexible as
> adults to really pick it up well (here already?). Maybe it's just a
> personality trait thing and not age at all; I guess I know enough people my
> age who I wouldn't trust to safely 'shut down' an operating system without
> being given a lesson or two first ;-)
>
> OK. Journal, and its related use, have some UI improvement possibilities
> that could be targeted (and I think a few might be targeted already for
> work), without having to solve the big 'impact on learning' type wider
> research/study goals. Some things that come to mind just now (in no special
> order and I'm sure most have been discussed already at some point):
>
> - Sort view by creation date, not just by last modification date. Currently
> when you resume something, even just  to take a look, it pulls it out of the
> time context of other entries it was created alongside. One click, and last
> weeks essays narrative/reflection is lost (the photos you took, the chat
> discussions you had with classmates, the audio you recorded, the picture you
> painted etc).

This is a big part of the need for versions.  What you really get when
you worked on something last week, and also today, are two versions of
that thing, distributed in time appropriately.  Sorting by either
creation or modification date is incorrect.

> - Filter view for starred items only, a single click way to quickly hide the
> unwanted.

Yes!  I had hoped this would make 8.2, but we didn't have time to
finish it.  Right now, starring is utterly useless, apart from the
visual indication to the user that they might care about it.  Being
able to filter to only starred items will be a big big advantage for
usability of the Journal.

> - Improve the 'Anything' pop-up UI. It takes me about 4-5sec of scrolling to
> get to the bottom of the Activity and mime file type list. And worse, if you
> do scroll way down, it takes just as long to get the Journal back to default
> after your search. I guess ideally this would become a custom palette grid
> of some kind, perhaps with just icons and mouse over text for the full names
> to save space. Another option could be for a short list of the most

That's an interesting idea.  In fact, we might consider something like
that for all of the filters.  They're kind of ugly as is, and take up
a lot of horizontal space that could be better used.  I'll try some
mockups.  The time popup, then, could even have a calendar in it, so
that in addition to some basic ranges, you could say "show me
everything I made the month of december last year."

> frequently used N activities (or the current Home view favourites), and then
> a 'more...' end item that would reveal a large slide-out, below toolbar
> dialogue with all installed activities and file types listed. Actually, you
> could cut to the chase and have an 'Anything' button that just triggers a
> slide down alert panel with all installed activities.
>
> - Realtime scrolling so you can just grab, drag, and look as it goes past.

Indeed.  I have never been satisfied with the row-by-row scrolling,
but we couldn't do better in terms of performance before.  In
redesigning the Journal, it was very important to us (to me, at the
very least) that smooth pixel-scrolling was part of the plan. Tomeu,
do you think we can make a transition like this for 9.1?  I think it
would be another big boost to using the Journal.

The main problem here is potential length of the scrolling page.  Its
unbounded, except by space constraints, right now.  There are two
viable options here that we've talked about.  First, we could
introduce the notion of paging, so that after scrolling to the bottom
of a page in the Journal, you have (older) and (newer) buttons to get
to other results.

Second, and my preference, we could introduce temporal section
headers.  After scrolling far enough back in time, there might be
sections for each month, and further back, for each year, etc., with
each section being represented by a header only, and a disclosure
button.  Clicking on a section would open it inline, closing the
currently open section, thus keeping everything in the Journal
temporally ordered on a single "infinite" page, but allowing one to
dive into it in any range of time.

Thoughts on these approaches are most welcome.

> Currently, if what I'm after is not on the first page, and I think it's more
> than a page or two away, it might as well be infinitely far away. It's then
> time to try and remember the activity object type, or some text/metadata and
> start typing until it (hopefully) makes it onto page one.
>
> - Text search works reasonably well for me, but as mentioned already, some
> kind of slide-out alert to prompt for an Activity title, tags, star,
> possibly description (though I can't say I've ever meaningfully used the
> description field) would make a large difference in Journal entry quality.
> Think the dialogue will need to auto countdown and dismiss with sensible
> default values where ever possible. This feature could be really tough to
> make work without annoying everyone. Perhaps could also do with a "don't
> keep" button there for quick dismissal of unwanted work when stopping.

That's my plan. ;)  The alert would only appear a) when the document
is being stopped for the first time and b) no custom title has yet
been defined.  This really should keep the annoyance down to a low
level, and the added utility it will bring to the Journal should
quickly pull people past any initial annoyance, I hope.

Activities would be encouraged to provide reasonable default titles
(better than "Paint activity"), perhaps by specifying some format
strings in .info.  This would allow them to pass defaults like
"<nick>'s painting <n>", which Sugar/Journal/DS would translate to
"Eben's painting 5" (if 1 through 4 already existed in the Journal).
Then, beyond the default, children would be encouraged to do better
themselves, or just accept the default, or (perhaps, though this has
been controversial) toss out the entry.

> - Inline, or same context detail view. Switching content to get to the
> detail view, and then having to switch back again seems to put the details
> too far out of normal use/view.

We've fought with this for a long time, back and forth.  I think we
need to give it some more thought.  As a possible interim solution,
which would be really nice to have anyway, I'd like to make the
palette for a given object contain more useful information about it,
including its preview (and perhaps its type, filesize, etc.).  This
isn't super exposed, but once you learn you can find out some details
about an object from its palette it could be really nice to have.

Thanks for your great feedback!

- Eben

> --Gary
>
>