Re: [Sugar-devel] [DESIGN] Record UI
On May 3, 2011, at 2:56 AM, James Cameron wrote: On Mon, May 02, 2011 at 09:40:18AM -0300, Gonzalo Odiard wrote: I think this design resolve the principal issue of my mockups, we can't identify easily what function is in use. Perhaps Record might be split into three activities ... still images, moving images with sound, and sound. Deployments might then choose which of four variants of the activity to include in favourites. This solution would also make it easier for the children to find an audio recorder. During our radio play workshop none of the 24 children suspected Record to be an audio recording tool. None of them had difficulties to find Record as a tool to take Photographs. This was due to Record's eye icon. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
On Sat, May 7, 2011 at 5:04 AM, tom.staub...@fhtw-berlin.de tom.staub...@fhtw-berlin.de wrote: On May 3, 2011, at 2:56 AM, James Cameron wrote: On Mon, May 02, 2011 at 09:40:18AM -0300, Gonzalo Odiard wrote: I think this design resolve the principal issue of my mockups, we can't identify easily what function is in use. Perhaps Record might be split into three activities ... still images, moving images with sound, and sound. Deployments might then choose which of four variants of the activity to include in favourites. This solution would also make it easier for the children to find an audio recorder. During our radio play workshop none of the 24 children suspected Record to be an audio recording tool. None of them had difficulties to find Record as a tool to take Photographs. This was due to Record's eye icon. One supposes that the icon could be changed to an eye and an ear, providing a better visual cue. cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Thanks Gary. I think this design resolve the principal issue of my mockups, we can' t identify easily what function is in use. Perhaps, we can use a secondary toolbar to the less used options if necessary (quality, or new features like effects...) Gonzalo On Sun, May 1, 2011 at 10:43 PM, Gary Martin garycmar...@googlemail.comwrote: 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 wanted to post this Record mockup variation: http://wiki.sugarlabs.org/go/File:Record_toolbar_mockup_(gary).jpg Key point is that it avoids using primary toolbar icons with secondary toolbars for the three different canvas state modes. Instead it presents photo/video/audio as three radio buttons, you'd mentioned you were going to look at radio buttons elsewhere, photo is the one currently active. The quality/timer/duration options are provided in the primary toolbar, but would disable/ghost if the current mode does not support that setting. Record and fullscreen widgets are back in the canvas as per original design, as is the choice of a black canvas colour. I'm missing the info/detail view widgets in this mockup (could use the original 'i' placement on the canvas, or badge the thumbs). Main cons. with this design are the use of text widgets in the toolbar, longer text translations could cause the toolbar to overflow. There's also less space options for adding new features – your mockup showed things like Effects: Sepia in a secondary toolbar – though these are likely more post process effects you might or might not want to enable/disable after making a recording (so could be buttons in the edit or possibly view sub-toolbars). Just food for thought – I'm trying to avoid the design issue re:'tools with secondary toolbars that also trigger a canvas mode state change' issue. If you think this might be the right path for Record, I can try a similar mockup treatment for Memorise, so it has play/create radio tool button canvas states. Regards, --Gary Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
A pending issue: I think the start/stop button must be in the toolbar, and not in the canvas. What you think? Gonzalo On Mon, May 2, 2011 at 9:40 AM, Gonzalo Odiard gonz...@laptop.org wrote: Thanks Gary. I think this design resolve the principal issue of my mockups, we can' t identify easily what function is in use. Perhaps, we can use a secondary toolbar to the less used options if necessary (quality, or new features like effects...) Gonzalo On Sun, May 1, 2011 at 10:43 PM, Gary Martin garycmar...@googlemail.comwrote: 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 wanted to post this Record mockup variation: http://wiki.sugarlabs.org/go/File:Record_toolbar_mockup_(gary).jpg Key point is that it avoids using primary toolbar icons with secondary toolbars for the three different canvas state modes. Instead it presents photo/video/audio as three radio buttons, you'd mentioned you were going to look at radio buttons elsewhere, photo is the one currently active. The quality/timer/duration options are provided in the primary toolbar, but would disable/ghost if the current mode does not support that setting. Record and fullscreen widgets are back in the canvas as per original design, as is the choice of a black canvas colour. I'm missing the info/detail view widgets in this mockup (could use the original 'i' placement on the canvas, or badge the thumbs). Main cons. with this design are the use of text widgets in the toolbar, longer text translations could cause the toolbar to overflow. There's also less space options for adding new features – your mockup showed things like Effects: Sepia in a secondary toolbar – though these are likely more post process effects you might or might not want to enable/disable after making a recording (so could be buttons in the edit or possibly view sub-toolbars). Just food for thought – I'm trying to avoid the design issue re:'tools with secondary toolbars that also trigger a canvas mode state change' issue. If you think this might be the right path for Record, I can try a similar mockup treatment for Memorise, so it has play/create radio tool button canvas states. Regards, --Gary Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Hi Gonzalo, On 2 May 2011, at 13:41, Gonzalo Odiard wrote: A pending issue: I think the start/stop button must be in the toolbar, and not in the canvas. What you think? Personally, I'm fine with having some widgets on the canvas, the start/stop makes sense to be there centred under the image. There was me... thinking you were going to complain abut the fullscreen widget composited over the corner of the image ;-p Re: your comment on where to put advanced features. Yes, advanced options could be moved to a new secondary toolbar if space is an issue, perhaps with the cog icon (or whatever activity customise/modify icon we standardise on)? Out of the current options, Quality: is the only one I'd consider OK to move, Timer: and especially Duration: need to be primary e.g. why did my video just stop recording after 2min? If you are considering adding a range of new effects features (BW, sepia, etc) at the same time as the toolbar update work, then a new icon with secondary toolbar space would be needed. Regards, --Gary Gonzalo On Mon, May 2, 2011 at 9:40 AM, Gonzalo Odiard gonz...@laptop.org wrote: Thanks Gary. I think this design resolve the principal issue of my mockups, we can' t identify easily what function is in use. Perhaps, we can use a secondary toolbar to the less used options if necessary (quality, or new features like effects...) Gonzalo On Sun, May 1, 2011 at 10:43 PM, Gary Martin garycmar...@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 wanted to post this Record mockup variation: http://wiki.sugarlabs.org/go/File:Record_toolbar_mockup_(gary).jpg Key point is that it avoids using primary toolbar icons with secondary toolbars for the three different canvas state modes. Instead it presents photo/video/audio as three radio buttons, you'd mentioned you were going to look at radio buttons elsewhere, photo is the one currently active. The quality/timer/duration options are provided in the primary toolbar, but would disable/ghost if the current mode does not support that setting. Record and fullscreen widgets are back in the canvas as per original design, as is the choice of a black canvas colour. I'm missing the info/detail view widgets in this mockup (could use the original 'i' placement on the canvas, or badge the thumbs). Main cons. with this design are the use of text widgets in the toolbar, longer text translations could cause the toolbar to overflow. There's also less space options for adding new features – your mockup showed things like Effects: Sepia in a secondary toolbar – though these are likely more post process effects you might or might not want to enable/disable after making a recording (so could be buttons in the edit or possibly view sub-toolbars). Just food for thought – I'm trying to avoid the design issue re:'tools with secondary toolbars that also trigger a canvas mode state change' issue. If you think this might be the right path for Record, I can try a similar mockup treatment for Memorise, so it has play/create radio tool button canvas states. Regards, --Gary Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
On Mon, May 02, 2011 at 09:40:18AM -0300, Gonzalo Odiard wrote: I think this design resolve the principal issue of my mockups, we can't identify easily what function is in use. Perhaps Record might be split into three activities ... still images, moving images with sound, and sound. Deployments might then choose which of four variants of the activity to include in favourites. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
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 wanted to post this Record mockup variation: http://wiki.sugarlabs.org/go/File:Record_toolbar_mockup_(gary).jpg Key point is that it avoids using primary toolbar icons with secondary toolbars for the three different canvas state modes. Instead it presents photo/video/audio as three radio buttons, you'd mentioned you were going to look at radio buttons elsewhere, photo is the one currently active. The quality/timer/duration options are provided in the primary toolbar, but would disable/ghost if the current mode does not support that setting. Record and fullscreen widgets are back in the canvas as per original design, as is the choice of a black canvas colour. I'm missing the info/detail view widgets in this mockup (could use the original 'i' placement on the canvas, or badge the thumbs). Main cons. with this design are the use of text widgets in the toolbar, longer text translations could cause the toolbar to overflow. There's also less space options for adding new features – your mockup showed things like Effects: Sepia in a secondary toolbar – though these are likely more post process effects you might or might not want to enable/disable after making a recording (so could be buttons in the edit or possibly view sub-toolbars). Just food for thought – I'm trying to avoid the design issue re:'tools with secondary toolbars that also trigger a canvas mode state change' issue. If you think this might be the right path for Record, I can try a similar mockup treatment for Memorise, so it has play/create radio tool button canvas states. Regards, --Gary Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
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? Would it be an option to separate audio recording completely from Record into a new activity? I have experienced that the children did not suspect Record to be able to record audio due to the activity's icon. The problem here would be, that it would make more sense to keep the name Record for audio recording, combining it with a new icon. Photo and Video would need a new name and keep the old icon. Might be a little disorientating at the beginning, but on the long term it would be a cleaner solution in my eyes. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
On Mar 31, 2011, at 6:41 PM, Art Hunkins wrote: Comments/suggestions regarding the Record UI: 1) I think Tom's ideas (http://www.flatlandfarm.de/blog/?p=283) are right on target in re: audio recording. +1. 2) I'm unclear as to whether the oscilloscope (measure-type) display is a preview only, That's exactly how it was intended. or is active during the entire record process. During the recording process I'd prefer a graph that displays what has been recorded similar to the one in Audacity or other recording tools. If the latter, I fear for audio glitches (and if Record ends up audio-glitching, you are likely to hear from me about it indefinitely!) Probably safer would be to display oscilloscope only in preview mode, for setting appropriate record level, and demoing (or otherwise exploring) other aspects of sound. (By preview here, I refer to testing the record level.) Of course the recording itself should not be affected by any visuals. 3) Let's keep in mind that Audacity is available as a Suger activity - at least from the command line. It's full-featured, can edit soundfiles and be used for all kinds of sound demos and displays. In my view, we should not worry that Record doesn't include these features. Audacity's UI under Sugar is absolutely unusable. The texts often are too big for their boxes. Either they protrude or they are cut. Sometimes they are way too small. In all cases they are unreadable. Besides that, Audacity also is not very stable under Sugar, it often crashed on me. In my opinion Audacity is also way too complex for smaller children, even if all the UI issues were fixed. 4) I dislike the lips icon intensely. Besides otherwise being misleading, it suggests *voice* recording only (and probably only speech). The ear seems much more appropriate, or (for that matter) a stylized waveform or oscilloscope display. I see the primary application as the recording of environmental (often nature) sounds, i.e., exploring the *world* of sound. Why not use the microphone icon that is currently used in Record's audio section? Art Hunkins - Original Message - From: Gary Martin garycmar...@googlemail.com To: Gonzalo Odiard gonz...@laptop.org Cc: Sugar-dev Devel sugar-devel@lists.sugarlabs.org Sent: Thursday, March 31, 2011 8:56 AM Subject: Re: [Sugar-devel] [DESIGN] Record UI 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 - 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) - 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) - 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]. - 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) - 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 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. Regards, --Gary [1] Option 1. from Christian's 'detail view anywhere' mockups http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf Regards Gonzalo
Re: [Sugar-devel] [DESIGN] Record UI
as a former audio engineer, I agree visual feedback during recording is vital. There are lots of ways to do this minimally: * a red light on in standby, red light blinking when recording * green blinking light for recording within level, yellow blinking for close to saturation, red blinking for saturation * 5-bar pseudo LEDs; 3 green, 1 yellow, 1 red, valid for recording and playback * a single light varying in intensity, size, or spectrum from green to red, small to large FWIW, I also feel the lips are not an intuitive representation of a microphone. A microphone would best represent mic input. Sean On Fri, Apr 1, 2011 at 12:54 AM, C. Scott Ananian csc...@laptop.org wrote: On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins abhun...@uncg.edu wrote: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Thanks, Gonzalo; that's a very good idea. I'll look forward to testing. Art Hunkins - Original Message - From: Gonzalo Odiard To: Art Hunkins Cc: C. Scott Ananian ; Sugar-dev Devel Sent: Thursday, March 31, 2011 11:39 PM Subject: Re: [Sugar-devel] [DESIGN] Record UI Art, I don't know if i will see the glitches when we do the visual representation. I agree, in a tool to record audio, is important the audio is well recorded. And when I have anything to show, I will inform and we can test it and see what can we do. Regards Gonzalo On Thu, Mar 31, 2011 at 10:15 PM, Art Hunkins abhun...@uncg.edu wrote: - Original Message - From: C. Scott Ananian csc...@laptop.org To: Art Hunkins abhun...@uncg.edu Cc: Gonzalo Odiard gonz...@laptop.org; Sugar-dev Devel sugar-devel@lists.sugarlabs.org Sent: Thursday, March 31, 2011 6:54 PM Subject: Re: [Sugar-devel] [DESIGN] Record UI On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins abhun...@uncg.edu wrote: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott If it works right, fine. Otherwise, there is the elapsed time indicator that is the something that needs to be changing. Also there are visual changes when you start and stop recording - all sorts of visual cues. I too rather like the waveform display - it does have some pedagogical value; it just *must not* interrupt smooth audio flow. Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Hi Gonzalo, On 31 Mar 2011, at 14:29, Gonzalo Odiard gonz...@laptop.org wrote: Thanks Gary and all the team. On Thu, Mar 31, 2011 at 9:56 AM, Gary Martin garycmar...@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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
On Fri, Apr 1, 2011 at 1:55 PM, Gary Martin garycmar...@googlemail.comwrote: Hi Gonzalo, On 31 Mar 2011, at 14:29, Gonzalo Odiard gonz...@laptop.org wrote: Thanks Gary and all the team. On Thu, Mar 31, 2011 at 9:56 AM, Gary Martin garycmar...@googlemail.com garycmar...@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
Re: [Sugar-devel] [DESIGN] Record UI
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 - 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) - 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) - 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]. - 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) inline: camera-external.png - 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 inline: microphone.png 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. Regards, --Gary [1] Option 1. from Christian's 'detail view anywhere' mockups http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Thanks Gary and all the team. On Thu, Mar 31, 2011 at 9:56 AM, Gary Martin garycmar...@googlemail.comwrote: 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. 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. - 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. 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? Regards Gonzalo [1] Option 1. from Christian's 'detail view anywhere' mockups http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Comments/suggestions regarding the Record UI: 1) I think Tom's ideas (http://www.flatlandfarm.de/blog/?p=283) are right on target in re: audio recording. +1. 2) I'm unclear as to whether the oscilloscope (measure-type) display is a preview only, or is active during the entire record process. If the latter, I fear for audio glitches (and if Record ends up audio-glitching, you are likely to hear from me about it indefinitely!) Probably safer would be to display oscilloscope only in preview mode, for setting appropriate record level, and demoing (or otherwise exploring) other aspects of sound. (By preview here, I refer to testing the record level.) 3) Let's keep in mind that Audacity is available as a Suger activity - at least from the command line. It's full-featured, can edit soundfiles and be used for all kinds of sound demos and displays. In my view, we should not worry that Record doesn't include these features. 4) I dislike the lips icon intensely. Besides otherwise being misleading, it suggests *voice* recording only (and probably only speech). The ear seems much more appropriate, or (for that matter) a stylized waveform or oscilloscope display. I see the primary application as the recording of environmental (often nature) sounds, i.e., exploring the *world* of sound. Art Hunkins - Original Message - From: Gary Martin garycmar...@googlemail.com To: Gonzalo Odiard gonz...@laptop.org Cc: Sugar-dev Devel sugar-devel@lists.sugarlabs.org Sent: Thursday, March 31, 2011 8:56 AM Subject: Re: [Sugar-devel] [DESIGN] Record UI 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 - 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) - 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) - 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]. - 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) - 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 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. Regards, --Gary [1] Option 1. from Christian's 'detail view anywhere' mockups http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
- Original Message - From: Gonzalo Odiard To: Gary Martin Cc: Sugar-dev Devel Sent: Thursday, March 31, 2011 9:29 AM Subject: Re: [Sugar-devel] [DESIGN] Record UI - 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. I totally agree with Gonzalo about the lips icon (see my previous mail) - for these and other reasons. Frankly, I really like the microphone icon. Any reason not to use (reuse) it? (Otherwise, perhaps the ear.) Art Hunkins___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins abhun...@uncg.edu wrote: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
- Original Message - From: C. Scott Ananian csc...@laptop.org To: Art Hunkins abhun...@uncg.edu Cc: Gonzalo Odiard gonz...@laptop.org; Sugar-dev Devel sugar-devel@lists.sugarlabs.org Sent: Thursday, March 31, 2011 6:54 PM Subject: Re: [Sugar-devel] [DESIGN] Record UI On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins abhun...@uncg.edu wrote: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott If it works right, fine. Otherwise, there is the elapsed time indicator that is the something that needs to be changing. Also there are visual changes when you start and stop recording - all sorts of visual cues. I too rather like the waveform display - it does have some pedagogical value; it just *must not* interrupt smooth audio flow. Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Art, I don't know if i will see the glitches when we do the visual representation. I agree, in a tool to record audio, is important the audio is well recorded. And when I have anything to show, I will inform and we can test it and see what can we do. Regards Gonzalo On Thu, Mar 31, 2011 at 10:15 PM, Art Hunkins abhun...@uncg.edu wrote: - Original Message - From: C. Scott Ananian csc...@laptop.org To: Art Hunkins abhun...@uncg.edu Cc: Gonzalo Odiard gonz...@laptop.org; Sugar-dev Devel sugar-devel@lists.sugarlabs.org Sent: Thursday, March 31, 2011 6:54 PM Subject: Re: [Sugar-devel] [DESIGN] Record UI On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins abhun...@uncg.edu wrote: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott If it works right, fine. Otherwise, there is the elapsed time indicator that is the something that needs to be changing. Also there are visual changes when you start and stop recording - all sorts of visual cues. I too rather like the waveform display - it does have some pedagogical value; it just *must not* interrupt smooth audio flow. Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Record UI
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. Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
A request concerning the new design of Record: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. Also, please ensure that there is no such interruption for *all audio recording resolutions*, as well as for all Sugar releases that this version of Record targets. Art Hunkins - Original Message - From: Gonzalo Odiard To: Sugar-dev Devel Sent: Friday, March 18, 2011 11:15 AM Subject: [Sugar-devel] [DESIGN] Record UI 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. Regards Gonzalo [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar -- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
