Re: Cheap Open Source Morae Alternative

Hi all,

I suggested different tabs because showing all features at once could 
create clutter.

The* record* tab is where everything is configured before the researcher 
and participant start the session. What the *observe* tab does is to 
show what's happening in the remote desktop and maybe the webcam feed. 
The *view* tab will play the record(s) back. The *analyze* tab will show 
statistics. The *present* will show the findings in a 
presentation-friendly format.

Here's my new suggestion:
Record http://i.imagehost.org/0394/record.png
Observe http://i.imagehost.org/view/0534/record
View http://i.imagehost.org/0323/view.png

Can someone s

On Thursday, 17 December, 2009 05:35 PM, James Moschou wrote:
> Hello,
>
> I'm not sure tabs on a non document-based app is a good idea just
> because that's how Morae does it.
>
> Here's mine:
> http://img94.imageshack.us/img94/1713/laby.png
>
> The way I see it, the tester opens the app and is presented with live
> previews of each feed, so they can position the webcam etc.
> They press record and maybe press pause.
> When they press stop the record button changes to a play button.
> because once the recording is finished, that's it there's nothing more
> to do. Which is why I think having "record" and "observe" as two
> separate tabs is redundant. To record another session, then they could
> go "File>  Save Session", "File>  New Session"
>
> I'm not sure what the difference between Observe, View and Present
> are. Also I'm not sure what would happen in Analyse but if it's
> detailed I don't see why it can't go in a separate window, or even the
> sidebar if it's brief.
>
> To me having thumbnails in the timeline is a good idea if you're
> splicing together clips from lots of different sources, so you can see
> what's what. But here there's just one source, and they're all going
> to look pretty similar, except for the position of the cursor most of
> the time.
>
> I also think having preset configurations is overkill, but I haven't
> really thought about all the other cases like mobile devices etc.
>
>
> Well feel free to tear mine to shreds.
>
>
> - James
>
>
>
>
>
> 2009/12/16 Allan caeg<[email protected]>:
>    
>> Here's a newer version :)
>>
>> On Wednesday, 16 December, 2009 01:16 PM, Máirín Duffy wrote:
>>      
>>> Allan caeg wrote:
>>>        
>>>> On Wednesday, 16 December, 2009 11:02 AM, Kirk Bridger wrote:
>>>>          
>>>>> I believe you've touched on the first to-do, and I don't agree that it
>>>>> is mockups.
>>>>>            
>>>> Exactly. I was having a hard time coming up with mockups, because I
>>>> didn't know what features to include in the first place.
>>>>          
>>> When working on something remotely like this, sometimes I like starting
>>> with some exploratory mockups first to tease out what kinds of features
>>> might be needed (people tend to get excited when they see them and call out
>>> suggestions :) ) Then you can go back and figuring out which are really
>>> needed, yadda.
>>>
>>> Whatever process works is fine, though, of course! As long as we get
>>> somewhere!! I'm sorry for forcing my notion of the way to go - I was just
>>> trying to make sure things didn't die :)
>>>        
>>>>> First we need to know what the tasks are going to be in the application.
>>>>>   You've listed:
>>>>>
>>>>> - check audio is working
>>>>> - check video is working
>>>>> - check video runtime (current length)
>>>>> - start, pause, and stop recording video (and associated audio I assume)
>>>>> - replay video with audio
>>>>> - mark timestamps in video
>>>>>            
>>> Well they don't have to be overlayed on the video - just bookmarked, using
>>> CMML. Then when you analyze you can click on the bookmarks to jump the
>>> playhead to where you want to go... ?
>>>
>>>        
>>>>> - add notes to specific timestamps in video
>>>>> - stitch videos together
>>>>>            
>>> Are we assuming just one video stream?
>>>
>>> Also we need screen capture as well! So we could do the video of the
>>> screen on the left, the video of the user on the right, record them into one
>>> video and letterbox it so it has a standard aspect ratio?
>>>
>>> So then there should be an option maybe, screen capture only, or screen
>>> capture AND user on the webcam right? Is there ever a reason to record just
>>> the user on the webcam? I don't think so - but - you might want to aim the
>>> webcam at a mobile device and record only that. So the options are:
>>>
>>> - screencast only
>>> - webcam only
>>> - screencast + webcam
>>>
>>> We are also assuming write videos to disk right? Is there any possibility
>>> to stream them so folks can watch remotely? (I don't know. It should be
>>> possible technically.)
>>>
>>>        
>>>> That's correct. This is a good starting point. Other than those features,
>>>> it would be nice to have presets for different purposes like FGDs,
>>>> software/website, mobile device (captured by webcam), etc.
>>>>          
>>> What is FGDs?
>>>        
>>>> I suggest having four tabs in the app. Those are record, view (or
>>>> playback), analyze, and present. I got that idea from the Morae apps.
>>>>          
>>>>> This is just summarizing your points.  I think we should come up with a
>>>>> good starting list (maybe a little more than this) before we start mocking
>>>>> things up.  Or we can start mocking up these tasks and build from there..
>>>>>            
>>> Either approach works!
>>>
>>> Do you have any interesting / inspiration screenshots to show from Morae?
>>>        
>>>>> Should we move this to a dedicated mailing list rather than crowd the
>>>>> usability ML?
>>>>>
>>>>>            
>>>> Maybe. I just don't know how to set that up. Who can help here?
>>>>          
>>> Let's wait until we have something.
>>>        
>>>> Btw, I refer to thewidgetfactory for available gtk+ widgets. Is there a
>>>> better reference?
>>>>          
>>> There's also gtk-demo....
>>>
>>> ~m
>>>        
>>
>> _______________________________________________
>> Usability mailing list
>> [email protected]
>> http://mail.gnome.org/mailman/listinfo/usability
>>
>>
>>

_______________________________________________
Usability mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/usability