[Sugar-devel] [DESIGN] Record UI

[Gary Martin]

Hi Gonzalo,

On 31 Mar 2011, at 14:29, Gonzalo Odiard <gonzalo at laptop.org> wrote:

> Thanks Gary and all the team.
> 
> On Thu, Mar 31, 2011 at 9:56 AM, Gary Martin <garycmartin at googlemail.com> wrote:
> Hi Gonzalo,
> 
> On 18 Mar 2011, at 15:15, Gonzalo Odiard wrote:
> 
> > I have prepared mockups about the changes I want to do in the Record UI. [1]
> > The changes were discussed with Simon Schampijer and we take ideas from
> > Tom Staubitz.
> 
> Just following up from Sunday's design meeting:
> 
>        http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-03-27T15:04:42
> 
> See the above log for details, but here's a quick summary:
> 
> - place the chronometer combo in the secondary toolbars, as opposed to the main toolbar
> 
> 
> Ok.
>  
> - write each object to Journal upon its creation rather than trying to write all of them at once on an Activity switch or Stop (which can feel like a crash/hang if you have recorded more than a few new objects)
> 
> Ok.
>  
> 
> - remove the (i) info icon from the toolbar and instead badge each media thumbnail on the bottom right corner with an info widget (icon still to be decided)
> 
> The idea with the (i) button in the main toolbar was make a explicit difference in the UI between the play/reproduce use and the recording use.

If we go with the 'edit details' badges on each media thumb (that with the current api takes the user to the Journal details view), is this still a valid thought? Sorry if I  have misunderstood your intent here (perhaps describe a short use case).

> The icon is not good (was a temporary icon only)
> - use the Journal detail view API explicitly for editing individual object metadata information, rather than the custom info/take notes side bar, see Browse and its download complete alert for example code. We standardise on an edit details UI for all Activities that want to edit their metadata at any time, an existing proposal already being worked on [1].
> 
> Are you talking about the "Show in Journal" button? I think is not a good idea for the workflow, but can be a fist step, until we have the detail view [1] implemented.

I agree that 'Show in Journal' is a less optimal workflow than directly editing inside the activity using your own custom details view UI, but the new 'invoke details view from anywhere' proposal should remove that argument (over time). The major benefit is that we standardise on the metadata editing UI for all Activities that need it, share code, maintenance, and pickup some free features — seeing the file size, file type are useful free extras for Record, we might even implement the atomised tag display some day ;-)

> - camera icon should be the one as seen in sugar-artwork for camera-external, need a similar styled icon for video (Walter has also recently started using camera-external in Turtle Art/Blocks)
> 
> 
> Ok. 
> 
> - I suggested the sugar-artwork microphone icon (lips) would be good for the audio recording icon (I believe it was originally designed for use as the device icon for a proposed microphone input gain control palette). We didn't formally +1 in the meeting, but worth considering if you don't find it controversial
> 
> 
> I think the lips icons is better to text to speech (I am using it in Read now). 
> We need a coherent set of metaphor here. 
> What will be represent the icon? The action done by computer or the action done by the child?
> Also, we can record music too, no only talking. 

All good points (I didn't know about the Read text to speech — that's a nice use for the icon to standardise on), I stand corrected. We just need a matching styled microphone and video icon then (shout if you want a hand with them).

>  
> There is still some concern over the user interaction for a primary tool, with sub-toolbar, triggering a full screen canvas change (e.g. as mocked up in your Record camera vs video vs audio, and my Memorize play vs create UI modes), as it might be confusing to get back out of a mode (especially when triggered unexpectedly by hover delay). I'll make a test activity with this interaction for next Sunday's design meeting and see how it feels.
> 
> 
> Yes. Can we disable the hover delay triggered change? May be we can use a RadioToolButton and display the sub-toolbars when the button is toggled?

Pass, not sure, but I think the approach for Record where camera/video/audio are radio buttons and we trigger secondary toolbars for them (along with the canvas mode changes) could the viable alternative.

Regards,
--Gary

> Regards
> 
> Gonzalo
>  
> 
> 
> [1] Option 1. from Christian's 'detail view anywhere' mockups http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20110401/d63e24c2/attachment.html>