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

[Simon Schampijer]

El 22/11/11 15:29, Gary Martin escribió:
> 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. 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?

+1 from me for working on this, we already spent so much time on this 
one, would be great to finish it.

I started with implementing the design listed in this mockup: 
http://wiki.sugarlabs.org/images/e/e2/Detailview_20110313.pdf

The model alert can be invoked from the Journal entry palette (show 
details), the detail button of the Journal entry and via a button in the 
activity toolbar.

>> 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.

Good point, I tend to agree here.

> 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.
>
>> 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?
>
>> 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.

Agreed here. The thumbnail view had many implications code wise. The 
Journal needs a big restructure for this to happen. I like your proposal 
of showing the thumbnail in the palette.

Regards,
    Simon