Showing posts with label Electronics. Show all posts
Showing posts with label Electronics. Show all posts

Thursday, 10 May 2012

Meeting 10/5

Topics covered:

  • IDATER content
  • Learning, teaching and the 2 decades of technology darkness 
  • The focus and purpose of prototyping for FYDP
  • Resource and Prototype matrices
  • Curriculum summary report
IDATER content:
Interviews happening next week, Wednesday. Prepare questions for then, run them past Tom.

Podcast - Not compulsory because not many people use them, but a good idea to encourage people to submit various types of media. Peter talking about recording it, really it can be done in our own time because of the basic technology that it needs. 
- Best done with two people discussing the subject and covering key points? Casual, very much like a friendly discussion, ad hoc.

Paper to be submitted to be my final year report. 

Trip to Limerick for the main event. Instead of a conference booklet, hand out CD's memory sticks. Alternatively, create an app (iOS, Android) that mimics the website, presents all the content inc. videos, picture galleries, etc.  No point creating it ourselves, can you get app templates? Similar to Wordpress templates but in app form? We pick a theme then add the content. Maybe several apps/volumes based on the subject area; reduces size and download time of each app.

Learning and teaching electronics- Discussion with Nigel:
Much of electronic teaching in design starts with learning the components first and then building up to the systems. Much of what Arduino and Sparkfun is about is only providing small subsystems that go together - no need to teach the individual component part.

Looking at it from a top down approach rather than bottom up. Grounded Theory.
Teach systems first > identify the system > what subsystems are required > what components make that subsystem.

Upside it is more efficient - more time is spent learning the system that is required for the project.
Downside is that the systems are understood but how they work is not.

2 Decades of Darkness:

During the 80's programming was taught on BBC computers, programming, creating games, devising problems. Papert, LOGO.
Then the 90's and 00's brought Microsoft based computers going into schools with word processing and spreadsheet programs - The idea of computing became to write reports and organise data. 
Only now with the introduction of Arduino and Raspberry Pi into schools are people realising what computing really is. Chance to properly implement Papert's ideas?
-Nigel is writing a paper on this.

Investigate Deep and Surface learning
- Link to that paper by that guy pulling apart PBL stating that it only works surface/shallow memory.

The purpose of prototyping in FYDP:
Shouldn't students be focusing their prototypes on delivering relevant user data, rather than focusing on making it at close to the proposed design as possible?

The FYDP prototype fulfils many roles:
Aesthetic, representative & showcasing lboro design
User testing
Representative of its functions
Demonstration of what has been learnt from many modules and disciplines.

A student might get more marks creating a prototype that has embedded electronics but still offers good potential for user testing, rather than a prototype that 'cuts corners' in regards to embedded technology but still has good potential for high quality user testing results.

Prototyping can't be reduced down to be purely user testing focused, but more focus can go on to user testing. More consideration at the start of each project the purpose of the prototype, embedded system based upon that while other criteria still met?

Resource and Prototype matrices:
Two matrices proposed:
  1. Resources Matrix - a subjective representation of the relations between resources suitable for classroom teaching of electronics, prototyping and interace design. Ordered by skill level / ability.
  2. Prototype Matrix - a graph used to mark the efficiency of any given prototype based upon the fidelity (overall finish, inc. cost and time spent on it) vs. the quality of the data drawn from user testing. 

Prototype matrix looks effective, could possibly be used in FYDP or form a basis of a paper. 
Resources matrix is a fine way of putting resources in context of one another. Subjective and some explanation for the boundary choices may be required.

Curriculum Summary Report:
Report to be written up summarising the collected curriculums from the selected universities and also from the FE subjects identified. This will make a portion of the final year report.

Jon Rogers contacted for module information, possibly visiting lboro soon, worth sitting down and discussing some of this.

Tuesday, 8 May 2012

Meeting with Steve Gill, Cardiff Met


Last Friday, the 4th May, I visited Professor Steve Gill at Cardiff Metropolitan University's Product Design Research (PDR) Centre. Steve heads the Programme for Advanced Interactive Prototype Research (PAIPR, pronounced 'paper') group which develops quick prototyping technologies and techniques for designing devices that involve physical-to-virtual interfaces such as mobile phones, remote controls, medical technology or anything that involves screens and other outputs reacting to buttons.

The key aim of the resulting work is to initiate the design of a product's user interface as early on in the product development process as possible. This involves lots of user testing on prototypes of increasing fidelity to assess the overall functionality and to ensure the final product is functional and easy to use.

But the problem with this has always been a case of the proverbial chicken and its egg. Product development of electronic interfaces have typically been tackled from a 'bottom up' approach, whereby the inner workings of the device is developed first, then tested, and then case and interface built around it. That is partly because in the past very little could be tested until something usable was made; how can someone fully test how easy a mobile phone is to use without a working mobile phone?

The problem with this bottom up approach is that even once the electronics is all working and being tested by a focus group of 'end users', it becomes very difficult and expensive to then alter all those electronic parts and functionality once it's found that none of the users can use it. So sacrifices are made, and more often than not its the usability that suffers.

The alternative method is from a 'top down' approach, where the design, usability and interface are all but defined at the start and then the technology built in afterwards. The work Steve and PAIPR are doing provides the tools that allow this approach to work.

Several tools and systems have come out of the work at Cardiff. One of them is called the IE4 (pictured above). This is a small, battery powered device, which on its own is no bigger than a small pack of matches. As the name suggests, the IE4 is in its forth generation after nearly 10 years of development. It contains a Bluetooth module and has a 20-pin connection at the back along with a breakout-board to make it easier to work with in the early stages of prototyping.

The IE4 interface Prototyping tool
The device works by simply connecting to a computer via Bluetooth and acting as a control device, such as a mouse or keyboard. The inputs can be added to the pins of the IE4 in the form of buttons, sliders, joysticks, sensors or other input components. These can then be arranged on the surface of a to scale appearance model with the IE4 neatly tucked inside of it out of the way. 

The computer reads the inputs as mouse movements or keyboard presses, and these can be configured to trigger on-screen actions such as menu systems, animations or control dragable objects. In theory anything can be controlled, and the complexity and difficulty of the virtual mock-up is determined only by how far you want to take the simulation and what program you use to do it. You can make something quite complex in Adobe Flash, or save time but still get a decent result in something such as Microsoft PowerPoint.

Photo from paipr.wordpress.com 
The IE4 allows you to create devices that are meant to control virtual interfaces wirelessly from a distance, or just use the computer screen as an effective example of how a screen built into the device would respond - all while being able to quickly build and test mock-ups that effectively trial interface designs of a product.

The facilities for user-centred design testing and analysis at Cardiff are very good. They even have a room which contains 4 HD cameras focused at one desk in the middle of the room. Scenes and scenarios can be set up and users or focus groups can test products and prototypes while being monitored remotely from a room elsewhere in the building. As well as simply recording the actions visually onto tape, data can be collected indicating things like the number of time certain controls were used, or time the user spent reading each menu screen. This gives designers and clients a very detailed analysis of the performance of any one interface.

Summary

The work done at Cardiff is very applicable to my work and I can learn much from it. It has made me think much about the kind of prototyping I am trying to teach with my resources. A prototype can come in many forms, not just a polished, fully to scale, working model that fully represents the finished product, but it can also be an off-cut of polystyrene foam formed roughly to fit in a human hand. And from a usability perspective, there is no reason why as much can be learned from the latter as the former.

Questions arise over the real purpose of a prototype, and what information we as designers need to get from them. Does the test user even have to control the device themselves? What if they only think they are controlling the device, and actually someone else is manipulating the prototype like a puppet, reacting to what the user does. This technique, dubbed the 'Wizard of Oz' method, is very powerful because the 'puppeteer' can control the system in real time, react to the user and simulate as many different scenarios as he or she likes without stopping the simulation to alter the prototype. They can throw in bugs, alternate routes navigation or different functions very quickly without the test subject knowing any different.

Shouldn't we be teaching designers the most effective ways of prototyping for designing and then support it with the necessary electronics and interface design skills? Rather than teach them that the polished end product is really the only real kind of prototype, when really its just the one that would matter in a sales meeting.

Sunday, 1 April 2012

Meeting 29/3/12

Topics covered in the meeting on Thursday:




Data thats currently being collected:

  • Module specifications from Design and Technology courses from selected Universities
  • Structures and covered topics from relevant subjects from Further Education curriculums 

1) A proforma needs to be created that accommodates all this data so it can be effectively compared.

2) Current mind map should be put into a document

These two deliverables completed by the 16th April and sent to Richard Bibb, along with the current aims and objectives of the research.


Lit review/End of year report:

Add a section about applied teaching techniques within Electronics and Interface design education

Sections order:

  1. Cognitive/Learning Theory (General)
  2. Applied Teaching Techniques
  3. Subject topics/required lesson content
  4. Physical Resources

Teaching:

How does teaching school pupils (<19yrs old) compare to teaching university students?
How do their Intellectual Level & Learning Style differ?
How should the approach to learning differ?

What Further Education courses are equivalent in content and skill level to Electronics and Interface design modules in BA undergraduate Design and Technology?
                  - This can be found after the module and curriculum data is put into proformas


Current Final Year Design Projects (FYDP)

What is the scope for FYDP?
Is there a limit to the functionality that students can give to their products?
Therefore, is there a limit to what we teach them to do?
ie, Resources exist that allow for quite complex systems. Do we assume that some students will want to build them therefore teach them what is required? What is the limit?

Arrange a meeting with key lectures/students/ex students to discuss this.


Meeting with Thomas Jun, LEGO mindstorms used as a teaching tool:

How do we capture a accurate picture of students, skills/knowledge/understanding of Electronics, Interface Design, Mechatronics?

Questionnaires:
Use real-life, relatable examples? - this demonstrates skills and not understanding
Use scales of ability/understanding of key skill or subject area, Plot to a graph

What questions are we asking, how are we asking them?

Sunday, 4 March 2012

MIT launch a free electronics course

MIT are trialling a little thing; They are running an online version of their undergraduate analog electronics course, 6.002: Circuits and Electronics.

Its running from the 5th March (tomorrow) until June the 8th, free of charge to anyone who wants to do it.

I've signed up just so I can get a cool downloadable certificate from MIT and ya know, maybe learn something.

https://6002x.mitx.mit.edu/