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