[Sugar-devel] [DESIGN] meeting proposal to discuss Journal features for 0.96

[Walter Bender]

On Tue, Nov 22, 2011 at 9:29 AM, Gary Martin <garycmartin at googlemail.com> wrote:
> On 18 Nov 2011, at 13:54, Walter Bender wrote:
>
>> Over the past month, Gonzalo and I have had weekly discussions
>> with the Learning Team about proposed enhancements to the Journal
>> [1]. The discussion has been mostly focused on the theme of the
>> use of the Journal for assessment and reflection, although a few
>> usability issues have been raised as well. The result is the
>> compilation of a collection of Feature Requests [2]. While some
>> of these proposals have been on the table for quite some
>> time (e.g. Write to Journal any time) and some are only
>> tangential to the theme of assessment (e.g. Journal volume
>> toolbar enhancement), Gonzalo and I thought it would make sense
>> to discuss them as a group with the Design Team.
>>
>> (Note that there are other Design-related feature proposals, but
>> we thought a meeting focusing exclusively on the Journal would
>> be most efficient.)
>>
>> Gary, since your calendar is most constrained, could you propose
>> some meeting times that might work for you? Also, any additional
>> up-front work we might do in preparation for the discussion?
>
> I'm going to try and chip away at this, bit by bit, via email. I find realtime chat is too rushed and shallow for these types of feature discussion.
>
>> A brief summary of the features:
>>
>> 1. Write to Journal anytime: The intent is to enable editing the
>> description, tags or the title at any time easily from the activity,
>> and not have to wait to close the activity. The pedagogical goal is to
>> facilitate the use of the Journal as a lab notebook, where notes can
>> be recorded while the user is actively doing something, not just after
>> the fact. We've been around the block on this one but I think we are
>> still lacking consensus on how best to do this. One POV is to have a
>> toolbar button (and/or Frame submenu) to involve the modal Journal
>> detail view [3]. A second POV is to add a toolbar mechanism for simply
>> adding text to the description field much the way we already have a
>> mechanism for updating the title (Simon had a mockup of this at one
>> point.). (Regardless of our approach, it is proposed that we add a hot key
>> as well, perhaps the unused Bulletin-board key.)
>
> +1 for a toolbar button, frame submenu, and Bulletin-board key – though we also
> need to decide what the non-XO hardware shortcut key should be, noting that the
> new XO clicky keyboards do not have a Bulletin-board key marked.

Maybe F7 ?  (We use F5 for Journal, F6 for Frame.)

> We would need an icon visual that works both at the toolbar button, and menu item
> scale. Perhaps go with the Bulletin-board key visual (overlapping rectangles) – this
> might be fine if we are going with the dialogue like overlay, has anyone found a solution
> to dimming the background window yet (I'm sure Daniel mentioned you could tweak
> an individual gtk windows gamma value for the effect, no alpha/compositing tricks
> needed)?
>
> My understanding was Write to Journal anytime feature was blocking more on
> implementation, in that the sugar shell can not currently identify the correct entry ID
> if the old 'keep' feature had been used to make multiple entries with the same ID?

Yes... but from a workflow POV, I am not convinced the Frame menu item
is the right solution. I had proposed it originally because I didn't
want to have to add any new buttons to the toolbar. But with the
removal of the Keep button, we have room on the Activity toolbar.

I am also not convinced that the modal overlay is the right solution.
Again, from the workflow POV, one wants to add notes to one's lab
notebook as one proceeds. This would argue for something inline, like
a text entry box. If you want to edit the entire listing, hitting the
bulletin board key would take you directly to the Journal entry detail
view. Hitting resume would return you to the activity. Simon had a
mock up of the text entry at one point. Still haven't located it yet.

>
>> 2a. Journal tagging private or public: A problem raised by some
>> teachers is that student Journals (and school servers) are filled with
>> music or games. With this proposal, a student would mark school work
>> as "public" and personal work as "private". These tags could be used
>> as a filter in the Journal and during the backup process.
>
> -1 as I think this feature will be a fail in practise. From all my past experience of people manually flagging/managing file backups, they rarely remember to include the correct items and you end up with incorrect backups that are only discovered when data is needed for a restore. Adults can't remember (or be bothered) to do this reliably, so I doubt this manual tagging idea would work for kids either.
>
> My first question would be ask what backup solution is being used, just to make sure the right one is being targeted. There are several backup approaches floating around. Is this the original hidden background rsync cron job; or the school server Journal volume widget as in Dextrose; or perhaps one of the Backup activities (though I think they only work for USB devices so likely it's one of the first two cases).
>
> To offer at least some suggestion on moving forward, I'd be looking at the backup server first. If it's kids filling up the server with music and video files, and perhaps large activity bundles, the chances are there are many duplicate files across the machines. Is the server only storing one copy of each unique file? By checking a hash of a file and hard linking duplicates, it could save a large amount of space with no need for manual user intervention at the client end.
>
>> 2b. Tags in Journal: a collection of predefined tags that can be
>> associated (dragged onto?) with a Journal entry. Teachers would like
>> students to use tags to organize their work, bu the current mechanism
>> is too unwieldy to use.
>
> As in some past design discussions, the tag UI would benefit from tokenising in the display fields, (tag1) (tag2) (tagN), to make it clear that the space is the tag break character, and that tags are 'or' searches e.g. if you have two entries, one tagged (big) (cat), and the other tagged (red) (dog), you can display both by searching for (cat) (dog). Once we are clearly tokenising our tags (so they don't just look like plane text), having an extra UI next to the details view tag input field with some initial suggestions would make sense. It could start with a small number of defaults (~five?), which then get replaced based on user created tag's frequency. That way we avoid the need for extra manual 'add new default', 'delete default' tag UI.
>
>> 2c. Activity-specific metadata: The idea is to record data
>> related to the use of activity and display it in the detail view
>> of the Journal.
>
> +1 to recording it. -1 for displaying it (yet).
>
> An activity (or background script) can cover the case of extracting this new usage
> data depending on the educational goals.

Presumably we can agree to a standard way of recording? I my current
implementation, it is to add a public key to the activity's metadata
which lists those metadata fields to be displayed. I can write an
activity for displaying detailed Journal entries but it will
essentially be a replica of the current Journal code. Seems redundant.
But it also made lead us down the path where the Journal is just
another activity. I'll sketch something ASAP.

>
>> These are old (and new) proposals, somewhat outside of the scope of
>> the pedagogical discussion, but they have a big impact on the general
>> usability of the Journal:
>>
>> 3. Journal volume-toolbar enhancement: The intent is to make it easier
>> to find example programs and media objects associated with an
>> activity. If an activity can mount a directory on the Journal volume
>> toolbar, the files in the directory would be available to the Object
>> Chooser. This is both an aesthetic and work-flow issue. We would be
>> able to eliminate the GNOME file selector and, as with the
>> $HOME/Documents enhancement we made in 0.94, we make moving
>> back and forth between the Journal and the file system much more fluid.
>
> I quite like this idea, but worry it would be too well hidden for those that need it, and too confusing for the rest (why has a turtle suddenly magically appeared in the Journal, where did it vanish too). I wonder if it is possible to modify the Object Chooser so that it can be directly invoked with a directory path inside the current bundle? Or is there a good use case for accessing the insides of that directory from the Journal?

Sharing clip art (and other files, e.g., csound orchestras) is one
advantage to access from the Journal.

The mechanism to add it only to the chooser would be much the same as
adding it to the Journal, only it would introduce lots of redundant
code.

>
>> 4. Multi-selection in Journal: Allow selecting multiple files for
>> operations in the Journal.
>
> +1, the UI screenshots I last saw for this seemed to be pretty close to finished.
>
>> 5. Thumbnail view in Journal: Several ways of approaching this, but
>> some visualization of the contents from a list-like view would make it
>> much easier to browse the Journal contents.
>
> +1, perhaps showing the thumbnail (if available) in the item's palette would be an easier goal to land than a full on new thumbnail grid view? I think the amount of Journal code changes required for a full thumbnail view was why the otherwise working thumb view patch from alsroot was originally rejected.
>
> --Gary
>
>> [1] http://wiki.laptop.org/go/Chat_Espanol_2011#Charla_35:_Evaluaci.C3.B3n_.E2.80.93Metadatos_Actividades
>> [2] http://wiki.sugarlabs.org/go/Features/Journal_features_for_0.96
>> [3] http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf
>>
>> regards.
>>
>> -walter and gonzalo
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>
>

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org