W.I.R.E.

W.I.R.E. or 'Web for Interdisciplinary Research and Enterprise' is a think tank based in Zurich that sees itself as 'a platform between science and practice'. Their research is interested in global developments which positively effect individuals, communities and industry. This includes looking into interdisciplinary methods that empower people, enhance our lives and help provide for a better future. Their site says:

W.I.R.E. sees itself as a laboratory for the development of new concepts for the creation and dissemination of knowledge. The foundations for this are to be found in the breaking down of traditional boundaries between academic disciplines, the abandonment of hierarchical concepts and the integration of content and form.

I like them.

Cargo-Bot - Programming game for iPad

I should probably stop surfing the net today, but I keep finding cool things. This is Cargo-Bot, a game that encourages the player to think like a programmer should. The player is given a stack of blocks, a grabber arm and a image of how the blocks should be stacked. 

The player then needs to drag and drop a series of commands that when executed, controls the arm so it stacks the blocks to match the image given. This is a perfect representation of Papert's constructionist ideas of learning theory.

I want to get this but I dont have an iPad :(

On a separate but just as interesting note, this is the first ever app to be made entirely on an iPad. Done with an app called Codea.

Technology Will Save Us - Interview

Ever since I got my Lumiphone Kit, I have been really interested in the work of Technology Will Save Us, a small group of guys who set up communal workshops usually in empty shop spaces, aimed at members of the public who want to learn more about electronics and making things themselves.

The above video is an interview with Daniel Hirshmann, one of the Cofounders of the company, where he talks about the reasons for setting up the project as well as how well its doing.

He starts by talking about how he wanted to start a company that did not only make a profit, but also gave back to society with more than just more products that will later end up in a landfill. Their goal was to create some kits that encourage people to learn more about technology, learn to be more creative technology and learn to produce it, not only consume it.

He says with the increased complexity of technology, along with the recession, there is a growing public interest in becoming more hands-on and learning new skills that save money and help people become more self dependent.

So now they set up workshops that help teach people how to put the kits together, as well as creating a fun, inclusive, communal atmosphere. Whats interesting is how he talks about the huge cross-section of people that come to the workshops; he mentions that not once have there been no women in a workshop session, yet there has been sessions with no men.

He talks about how their work can influence larger corporate companies by showing them that there are ways of producing while also giving back to the community and engaging with your customers. TWSU are selling a product that a customer buys, but also gets taught new skills and knowledge that they can take away to help improve their lives.

He then touches on open source communities online and the vast resources available to anyone who wants to take on something like electronic prototyping, but makes a good point by saying that many people struggle to pick that up when it is a list of steps or lessons online, but find it easier when it is booked out as a fixed time and place where the learning takes place. That is where the workshops come in.

People Shouldn't Learn To Code

A debate has come about recently, spawned firstly from a tweet by the major of New York City, Mike Bloomberg, and then a response by a guy called Jeff Atwood. The original tweet is below:

Great, the guy wants to learn code, lets leave it at that. But Jeff Atwood thinks not. Jeff is a bit of a superstar in the coding community, and on his blog he posted a piece called Please Don't Learn to Code.

His points seem to mainly revolve around his dislike for inexperienced programmers being employed and messing it up for the rest of them.

• It assumes that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the workforce is a net positive for the world. I guess that's true if you consider that one bad programmer can easily create two new jobs a year. And for that matter, most people who already call themselves programmers can't even code, so please pardon my skepticism of the sentiment that "everyone can learn to code".

• It implies that there's a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.

True, its not good to dilute the skill level of a workforce by flooding the sector with unqualified workers, but that might be more a problem with employers not hiring the right staff. Or if it is about there being too many under-qualified coders, surely that will mean there will be an increase in perfectly good coders who will no doubt float to the top.  Jeff seems to be inferring that if more people learn to code casually, everyone will want to be a professional coder.

Some people in the comments of this article can see his point and attributes this to the Dunning-Kruger effect, whereby incompetent people have a tendency to overestimate the level of their skill, and fail to realise where they fall short. This could well be true, but I digress.

What Jeff only touches on however, is the move to push programming into the forefront of education, and making it as an important as Maths, English and Science, something that Papert would advocate. Jeff says this wrong, as well as 'learning to code for the sake of learning how to code'.

As the writer of this post points out, learning to code is does not mean seeking to become a professional programmer, but is about gaining a better understanding of the technology that we use, and by gaining a whole host of transferrable skills that are applicable to thinking and solving all sorts of problems and as a way of approaching learning itself.

So, while I highly doubt Mike Bloomberg is really ever going to learn how to code, the question is should he? Yes, I think he should. I think many of us could do with understanding more of the basics of what makes the things we hold in our hands, the displays we read off every day, work (and also not work).

esmoove puts it well:

Learning new skills opens up new perceptual avenues and cognitive spaces. I'm learning to sew right now, not because the world needs another tailor but because I want to be able to recognize quality in clothing and create pieces that I can't find. Novice coders feel the same way about their digital goods and should be encouraged to continue. Learn to program.

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.

Technology and the Development of Teaching

As Seymour Papert inquired in 'The Children's Machine' (1993), if using a time machine and you were to bring a group of teachers and a group of surgeons from 100 years past into present time, how would they fair at their craft?
The surgeons would probably have a hard time adapting to the new tools and techniques used in hospital theatres today, but despite the new technologies in today's classrooms, the teachers would probably find it easier to adapt and teach nearly as effectively as teachers do now (apart from getting overwhelmed with the increase in unruly, undisciplined, knife-wielding kids).

If this were they case, Papert asks, then why? Why has medicine developed far more than education? Is it because the ways we used a century ago were the best ways to teach? Is it because the pressure to improve surgical methods has been greater than for education? Or maybe the success of new medical procedures are far more quantitative and obvious than a new teaching technique.

Possibly for medicine in many ways, the tools have dictated the techniques. New technologies have directly influenced how a medical professional works on their patients; from making diagnoses easier to making incitions smaller. In schools however, the influx of technology has only recently been making a direct effect on teaching methods.

This, I expect, is due mostly to how the technology is packaged. Desktop computers have been in most classrooms for nearly a decade, but its only until the screens could be projected onto whiteboards did the power really be injected into every lesson. Now with the new wave of tablets, the technology is not hindering the learning experience but complementing it.

The development of technology:

The fast development of technology is most certainly a double edged sword. In one sense it is greatly enabling;  the stuff only realised by science fiction authors a short time ago is entering our homes (and classrooms), providing us with media and services in ever more convenient and fast ways. But on the other hand, the speed of progress makes everything around it seem dated as quickly as version 2.0 comes out.

Look at any physics textbook thats 5 years old, and apart from the omission of Pluto you will most likely see very little difference between that and a book published yesterday. Do the same with a book on ICT and you would have a hard time following it. Despite a PC now having very simliar tools to one 5 years ago, the volatility of software has caused those to be changed and updated beyond recognition.

Therefore, learning resources associated with such technologies must be built so they utilise technology rather than rely on it. Rather, the learning resources must be backed up by a skill-set, methods rather than specific tools should be the backbone of this work.