Thesis, Twitter, Bugzilla

Thinking about the mash-up I've got to do for CSCW. Need an archive to recorded the coding process. Using twiotter as an updater. Planning on using it like a private bugzilla.

Sry to the person following.

-SRE

Break up and Build Order

1. Main Screen and Settings with Winamp using arbitrary input
1. Input is the buttions of the Wiimote. This removes the gesture significance and allows for the base system to be build around easily defined input and output.
   
2. Main Screen and Settings with Winamp using gesture input
1. Include gestures into the control method. This adds the gesture significance of both arbitrary gesture control (I.E. volume/position setting) and cognitive gesture control (I.E. gesture representing what the user wants to do). Also demonstrates the modular nature of the program.
   
3. Picture mode
   
1. Add multimodal interaction using the gestur
4. GUI Interface
1. This is either adding a wrapper for the Main and Setting screens or adding the playlist control screen
5. TV Mode
1. Adds Mutlimode with a different control method
   
6. Video Mode
1. Highlights some of the other problem in multimodal interaction such as mode dominance

Well thats the build process. Looking at it theres a lot to get done so I'm getting started.

-SRE

1. 
   

Latest UML Design

Still haven't started the conversion. Been working on the class's in UML. Been having trouble trying to link the modular gesture to actions. But I think I have it now. Redesign the gesture recogniser. Going to have to recode and test all the gestures...Sigh. but since the gestures I've got now work ok the new gen gesture recogniser should be much better.

Even through the links aren't there this shows the separation away from device specific input and output. Going to run it to trouble when I add a new mode.

-SRE

Hackt Build Evaluation

Got the Hackt version running. The actual gestures require some work. Order of comparson is going to be important. Think I need something better than an if statement. Not looking forwards to that.

Biggest noticeable stuff:

1. Stop need most work, the gesture's to subtle
2. Make it so/Playball, roll out still makes sense for play got to check how people think of it for representaiton.
3. Shuffle on and off as separate gesture is actually how winamp implements shuffle. I.E. it's not a toggle functions.
   
4. Shuffle is going to need an onscreen prompt if people are going to use it for the first time. Alternately skip, and volume are performed by people as the expect. Justiufication. Gave someone the remote and said goto the next track, goto the previsou track and turn vol up and down and got the right actions.
   
5. Down and up are not as their seem. Down actually is more natural as swipe left because of the way the wiimote is held. (This prompts the need for orientation when doing the clean gesture module)
6. No fast forwards in winamp only skip a set amount. Could prove people difficulty, especially when looking for a point in a song. I.E People would use the continuous setting more possibly
7. On the coding side the gesture needs a bigger array. Overflow error occurs each time the wiimote is held(?) in constant motion. Might be fixiable with higher break points.
   

Really need a gesture to auto play something or an alarm to use around the house. Currently not included on the thesis but jeez that would be good. But I think I'm going to run into problems concering battery power of the wiimote. Have the program running with the wiimote connected, say overnight, the program is constantly pinging the wiimote and therefore draining the battery. The problem is stringly related to the gesture module and how to know when a gesture is being read. Ideally, I want a sleep function on the remote itself, maybe better control of the heartbeat is possible. For the Final project, might be able to tie the ping to the refresh function in GLUT, if I end up going that way.

On a personal note,
This kicks ass, seriously.

Cleaning the Hackt version in UML

The code as it stands is sloppy. This is a UML to clean it up. It's just been so long since I've done any UML. Having a bit of trouble separating the input/output device from the gestures and tasks respectively.

Major differences are the abstraction towards the screen state and the modularization of the input/output devices. Any hints welcome. Going to make the hackt version represent the gestures from user studies (where the gestures are already resolved, IE no shuffle/repeat). Then convert the whole thing to this map if no comments appear.

The break down of parts

I'm pretty sure there is a better way of doing this, but at this time of night this will do. It needs to be redone using the topic focus of the parts. I.E. multi-mode, gestural, Gestures based on the tasks vs gestures based on design etc...

1. Single Mode - Main Screen - No Gestures - Text Interface
2. Single Mode - Setting Screens - No Gestures - Text Interface
3. Single Mode - Main Screen - Basic Gesture Control - Text Interface
4. Single Mode - Setting Screens - All Gestures - Text Interface
5. Single Mode - Main Screen - Most Gestures (no link) - Text Interface
6. Single Mode - PlayList Display - Minimal Gesture - Text Interface
7. Single Mode - Gesture Links - There and return - Text Interface
8. Single Mode - Mode Display - Add from Single List - Text Interface
9. Single Mode - Mode Display - Add Item Sorting and Gestures - Text interface
10. Dual Mode - Main Screen - Basic Mode Gestures - Text Interface
11. Dual Mode - Setting Screens - All Gestures - Text Interface
12. Dual Mode - PlayList Display - Minimal Gesture - Text Interface
13. Dual Mode - Gesture Links - There and Return and Swap - Text Interface
14. Dual Mode - Mode Display - Add from Single Lists - Text Interface
15. Dual Mode - Mode Display - Add Item Sorting and Gestures - Text interface
16. TV Mode - Main Screen - Gesture Mapping - Text Interface
17. Multi Mode - Main Screen - All Gestures - Text Interface
18. Multi Mode - Setting Screens - All Gestures - Text Interface
19. Multi Mode - PlayList Display - Minimal Gesture - Text Interface
20. Multi Mode - Gesture Links - There and Return and Swap - Text Interface
21. Multi Mode - Mode Display - Add from Single Lists - Text Interface
22. Multi Mode - Mode Display - Add Item Sorting and Gestures - Text interface
23. Basic Gesture Creation - Main Screen - Play, Pause, FF, Rewind, Skip, Volume, Zoom (Keep gestures separate, keep it modular)
24. Advanced Gesture Creation - Mode representations, Swap Mode, Repeat, Random On, Random Off
25. Subtle Gesture Creation - Open Drawer, Close Drawer, Reset, Next Item, Prev Item, Add Item, Remove Item
26. Basic Wrapper for Text Interface
27. Advanced Wrapper for Text Interface (Use jpg textures, keep it skinable)
28. Create a Library sorting/addition Tool to go with

The Design for Online Access

Looks like the photo's aren't going to upload. O-well Fix it soon. As an Aside got the new Bluetooth dongle.

Working like a dream, Got the Wiimote back up. Threw some vids of it test programs onto F8.

Not to speak to soon but 2 week seems do-able. Though the final gestures are going to be death to program and since the program runs around them the break-up of of modules will have to be Dependant on them. Problem is going to come when adding extra gestures. The subtle gesture only occur in a few places and aren't needed with the gross gestures. I hope this is going to help differentiating them during coding. I stress hope.

-SRE

Note from Aug 21st

These notes are getting a bit abstract.

Fodder
Understand how the TV is, and understand the the TV is not how it used to be

Understanding the Thesis Document.

• Given the problem space, with enough levels of abstraction the main topics/chapters for the document can emerge.
• All Information must back up the Design
• Don't make the same mistakes as others, I.E. Use previous research and understanding as a guide and justification method
• Use the document to communicate what you have learnt
  
• "Standing on the shoulders of giants" - Take what is known and extend on it, or take what is already known and proved the inherent problems with it or test the inherent problems if thier can be
  

Basic outline from other theses

• Background/Background --> Factors effecting the links between the background (What makes up the connections) --> How can these factor be addressed to create a solution --> What is the solution (design, implemention , Evaluation, Conclusion)
• Concurrent development of Ideas may lend itself towards a map of the document, either a classical text or pictorial view. As long as the representation aids in the readers understanding of the document.
• For mine, Media/ Control Interaction --> Remote Slatings --> Differnt devices --> Wiimote
• The Poster for demo day is aimed at 3 people. Title --> abstract --> content - Hook: Get people curios about the topic, Line: Explain the concptes involved, Sinker: Tell them what happen. Not using too many word but not using too little.
  

Task for the Week
1. Brake up the specs into logical build order pieces that expanse incrementally on the scope of the project. IE. One Mode (Simple Menu deisgn) --> One Mode with Gestures (Getural Control)--> Two Modes (Mode Error) etc.
2. Build half so the other half can be built next week.

Simple

Social Design - The servient developer

Note to self.
Remember to ask Stephen about the place of Social Design. It seems to be right in the middle of the subject, but not really in either.

I'm sure there is a movie being produced (or script at least) using only user contributions. Thinking it could be an interesting project to look at and see what comes from it. The link on f8 is yielding little interest, but I think if users could be engaged some really amazing apps could be created. The idea of involveing users in the deveoplment process is always problematic because of their lack of experience and difficulty because of numbers. Using social tools to develop something would increase the timeframe, but ...

if done correctly could remove the designer from the process and focus purely on the user. Problems of course are going to come from the moderation of how the development progresses.

The set of users would stroingly influence the application developed. f8 took off because it suited the needs of the users and changes to reflect this. It changes "have an idea then have user then use the users to aid development" to "Let the users have an idea and then aid the users in development". Sound similar to the idea of Servient leadership, basically a lead from behind approach.

From Web 2.0 group on f8 "Your idea is not original". If I can';t think of something new, find the non-original ideas people have and help them make it happen. It's like Joe Everyman coming to a software developer and saying here's my idea except there could be hundreds of Joe Everyman saying, but what if it did this.

Where I am

Not going to make it out to Ipswich today. Woke up to late this morning after a late night at work. I will definitely be enrolled in both subjects this semester. Sitting here doing the social assignment.

Plans for the Weekend is;
1. Get the Wiimote working again on my PC
2. Get the Outline into something usable (I'll need you to check because I'm still not sure about the topics to include in a thesis)
3. Build the specs for the non-gesture bit of the project. I'm pretty sure the gesture specs will have to reverse engineered because I have no clue of the levels needed for the new gestures.

-SRE

Blogger Topics / Thesis Overview

I know this is looking very sloppy. Got a head act and am going to bed. I'll sort in out tomorrow.

• Possible Directions
• Critical view of 2D vs. 3D mismatch
• Using New technology in old format
  
• Media Player Examples
• The Wii Menu Structure
  
• Exploring the Problem Space
  
• Wii Characteristic View
• Current System Characteristic
  
• Problem Space and Description
• Effect of Wiimote of Menu Design
• Modification of Current menu to use Wiimote
  
• Media Center Reviews
  
• User centered design based around a Media Center
• Methods of Prototyping and performing surveys
• I.E. Flash, sketching, Internet survey
• Other examples of Wiimote usage
• How to build a gesture Capture device
• Definitions of 'word' to be used for a gestural syntax
• Movement Classification
  
• Task Definitions
• Mode Error
• Possible Solutions
  
• Physically possible Gesture Set Definition
• Task List Classification
• Basic UML Overview
• Similar Thesis Project
• project Plan
• Uasability Test 1
• Menu Idea 1
• Which came first mode or Task
• Interaction as a conversation
• Gesture Set Usable basic list
• Mapping Actions to Display
• Menu Hierarchy
  
• Gesture Notation
• Labanian
• Baineriff
  
• Movement Analysis
  
• Gesture Applicability with Sal
  
• Gesture Pattern Recognizer
  
• Application Wrapper
  
• Other Application Commands (Win amp command calls)
• User interviews and gesture suggestions
• Wiimote Ergonomics (Alternative Grip)
• Participatory Design
• Aesthetic Usability Effects

Concerns about not actually doing new stuff

Not really concerns but an idea to keep me doping new and different stuff concerning with usability and desing. From the UCD facebook group there is a topic about Aesthetic Usabilty Effect. This may be added as the system ius designed. Building a text version of the system then adding the graphics gives the opportunity to examine the phenomenon.

This give usability stuff I never thought about to the thesis and the opportunity for User Evaluations.

Notes from Matt

Problems
1. Does Shuffle shuffle both modes? If it cycles what order.
Their will be a dominant mode. Music will usually be dominant over pictures who's order rarely needs to be changed and videos less so

2. Does play begin both modes or 1?
Both

3. Does zoom remain constant or reset for each picture
Remain constant

4. If seeking is the system Paused?
Music = Playing
Video = Paused
Pictures= Paused

5. How is the dominant mode shown?
No Idea, Some form of on-screen icon.

6. How doe people sort their media?
Music = Artist, Albums, Singles
Video = Genre, Actors
Pictures = Location, Chronologically, Who, When

New Gestures:
1. Repeat Cycle works around the vertical plane
2. Play /Go = Create a unique gesture to represent the system ie branding / refs whistle still unknown or Go by pointing forward
3. Playlist = Since everyone said that skip was left and right this implies the playlist should be represented in a horizontal fashion., Therefore the gesture decided on was a pulling up action that lifts the playlist from lying down
4. HUD = the same as the Playlist. No Need to have Playlist without the volume and seek
5. Hide = the opposite action from pulling the HUD up was to push it down, this can be used from volume, seek, and the HUD
6. Swap = the word swap implies 2 modes other words were exchange, alternate, cycle. The gestures suggested were folding a corner of the page over, spin a coin around, rotation and Duffman (participant has had previous use of the system ) which represent flipping the page over and turning a page over like a book
7. Go To Playlist creation = Creation of playlist = "Something magical" DaDa (?), Using a Wand Settled on waving (which represent saying hello lets begin, wipe this slate clean or goodbye to the current playlist)
8 The gestures to represent the modes were thus:
8.1 TV -> point a remote
8.2 Video -> Charades Video
8.3 Camera -> Hands holding a camera and pumping down representing the button press
8.4 Music -> Cupping the Ear
NOTE: Because Cupping the Ear is the same as the volume control, their nbeeds to be the gesture for bringing up the Playlist menu, Going to try and find a new gesture for volume or music so I can remove the dependence on an arbitrary action to access the mode/Playlist Menu
8.5 Add = Come Here, Bringing hands towards yourself
8.7 Remove = Go Away, Flicking hands away from yourself

Photo 1. Development of the Playlist Screen with Matt.
The idea is to pull CD/Videos Picture albums out of a draw and onto the floor.



Photo 2. Playlist Screen Development 2 with Matt
Similar to the bottom right of previous, Draws at the top of screen to flick through, Come brings the current selection down screen into the playlist. A Playlist gesture is needed to select the Playlist to remove items, this may be solved by an undo function. The Drawers to the sides at the top sort the media in different fashion depending on the media type. IE. Movies are Actors, Titles, Genres etc... At the bottom right show the available gestures for a beginner user. The Playlist is sorted by the meiea which is added to it.


Photo 3. Beginner User Gesture Icons with Matt
Wanted to do some participatory design with someone. These Icons are based roughly on my original Headphones, camera, video recorder and TV. The icon is superimposed with a representation of the action needed to be performed by the Wiimote.
Ideas directly taken from Matt include the Axis of the video camera, The hands to represent the Wiimote and then the Wiimote to represent the Wiimote, I was using arrows, Matt wants animations.

A set of these icons from each of the other actions needs to be developed and tested.

Exception to the rule

Yah for Eames (/Eames rolls his Eyes),
I just remembered the exception to the rule for the problem of A DVD playing with Music playing at the same time. I've been working off the assumption that mute is not needed and the no-one would every want music playing while a video is playing.

Remember them playing Floyd in a chill out section of splendor and recalled the interesting concept of watching "The Wizard of OZ" with "The Dark Side of the Moon Playing". Every time I tried doing it syncing became a problem. This media player can solve that through connecting play to the same action but thanks to user studies mute has been removed.

Brilliant. Oh well....who would every want to watch the cash register of "Money" kick in when the movie goes from back and white to color. Might plan for at one "undocumented feature".

Altrnative grip

To preface this I got a digital camera yesterday and have been playing around with it.

I remeber reading a web page about token usability design awards. I'm trying to find the page but one awards was for a kids camera which had plastic bumps on it. The caption was something like "It looks like it wants to be held." These bumps are common on most cameras you can find today, I.E. where you right hand curls around the side.

Tries to test some gestures with mum yesterday but she kept pressing the buttons saying I would point in and press up. Not to helpful but....
I took the Wiimote and turned it around so she couldn't press the button. BAM the depression from where the B-button is melded into her palm.

Two side effects from this. She stopped pressing the buttons and also she grips the remote when performing most gestures. The grip presses the b button automatically. What a sweet and simple way to understand some gestures are being performed.

The Alternative grip


The Depression into the hand.

Sry bout the darkness (I still can't find flash)

People are also puting this ideas into remotes being designed now. Just wish I could find the camera example

http://uselog.blogspot.com/2007/06/i-love-my-remote-control.html

Let get started again.

Coming back to bris tonite. Time to get back into gear. In respect to thesis fodder, I saw the add fro mario party aznd also wario something gmae on the Wii. What struck me as curious is that my friends where surporise at all the gestures you could do. While it seem like a lot the reason it picks them up is that they only need to recognise one at a time. I think a section looking into the difficulties around differentiating between gesture for the wiimote will be good fodder because previous devices will be different from the wiimote. Even a look into the action uised in the games compared to each other might be appropriate.