[Sugar-devel] [DESIGN] Record UI

Gonzalo Odiard gonzalo at laptop.org
Fri Apr 1 13:39:13 EDT 2011


On Fri, Apr 1, 2011 at 1:55 PM, Gary Martin <garycmartin at googlemail.com>wrote:

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

Yes, it is not necessary if we use the Deail View in the Journal.


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

Yes! We need standard icons for video and microphone in sugar-artwork

Gonzalo



>
>
>
>> 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>
>> 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/9bb81919/attachment.html>


More information about the Sugar-devel mailing list