Well, it was a one-off… a little bit of fun for the Glitch Launch Party and an excuse for me to explore the Arduino platform. However I just noticed today that the in-game shoes have a couple more tricks up their sleeves (do shoes have sleeves?). When you’re away from the keyboard in the game and your Glitch falls asleep, the shoes pulse gently in time with your breathing. Also when you laugh or frown, the lights have their own emotions that mirror your character’s. This got me thinking about ways to extend the project.

One possible project might be to add the control button back into the system – pressing that would override the current effect for a limited amount of time to show an “emotional” effect. Maybe press once for laughing, twice rapidly for angry, three times for sleeping.

Another project might be to explore analogue control of the lights to allow a fading pattern. The Lilypad supports analogue out using a Pulse Width Modulation technique (ie it turns the pin on & off rapidly… more on than off means brighter, more off than on means dimmer) – but the built-in support only works with 6 of the I/O pins so I’d have to investigate controlling the rapid on/off cycling myself.

Another project might be to add some sort of sensor to the system… maybe a resistive chest strap so it can tell my breathing pattern, or a thermo sensor so it can detect my temperature. The board could then alter the light patterns automatically to represent some aspect of my physical state.

What Went Wrong

In general the project went off really really smoothly. From both an electrical and software point of view it was very simple but I know that simple doesn’t always mean free of frustrating faults. I had no significant issues with either the electronics or the software, just a couple of minor niggles.

One ‘gotcha’ was that the USB connection to the computer had to be wiggled just-so or else I would get power but no data to the Lilypad. At this point the Arduino software would see no serial port and fail to download to the board. Having hit this a couple of times I learnt how to spot it and wiggle the cable successfully.

Another hiccup was the power consumption with multiple LEDs on simultaneously. During initial testing with a single AAA cell, I found, at idle, the Lilypad was drawing about 9mA from the power supply board. With 2 LEDs on per side (4 total) that rose to 93mA. Because of the way the step-up electronics work, that worked out at 230mA from the actual cell. If I tried to turn on more LEDs the cell couldn’t supply enough current and the Lilypad reset. I minimised the peak battery loading by careful construction of the flashing patterns to alternate the shoes on/off cycles but I replaced the single AAA cell with a three pack for extra safety. Reading the datasheet for the NCP1400A voltage converter chip says the chip has a 100mA maximum output current so I think I was lucky to be able to get as much out of it as I did.

What Would I Do Differently

There were a couple of things that I’d do differently if I did the project over again.

First, I’d take into account the way that the straps sat on the shoes before I glued the LED ribs on to them. The stretchy straps lean slightly forwards because of the slope of the shoe – I didn’t think of this and I glued the LED ribs onto them at right angles and so they’re on a slope rather than being parallel to the ground. If I’d tried the shoes and straps on first, before I got the glue gun out, I could have glued the LED ribs on at an angle so they remained flush and level to the ground.

Secondly, I’d choose a different power supply. There’s some really nice Lithium Polymer batteries available, supplying 3.7v with a capacity of 1000mAh or more. The power supply board for this is electrically almost identical to the AAA board, the only addition being an over-current protector – which might actually be overkill as the NCP1400A has a 350mA current limiter built-in. I think this would have been a little neater than my contraption with the 3xAAA cells. Although, given that I didn’t have to buy a separate charger, or a battery, the solution I ran with was actually cheaper and more flexible.

All in all, a great success and I’m looking forward to having some more fun with Arduino (Lilypad or otherwise) in the future – as soon as I can think of another excuse!

OK, OK… your patience is finally rewarded, here’s a video of what they look like in action:

If you’re so inclined, here’s a more detailed video walk-through showing all the bits & pieces plus the shoes in action:

In case the videos don’t work for you, the originals are on Flickr and YouTube, here and here.

To bring this to life, I needed two basic set of things:

• something in which to mount the Lilypad, power board and batteries. My original idea was something along the lines of a money belt with the Lilypad in the small of my back and a wire to the button somewhere easily accessible
• something to hold the LEDs and attach to the shoes. I wasn’t going to modify the shoes in any way so my original idea was some sort of a fabric overshoe sewn together and held in place with stretchy straps and velcro.

Really it all comes down to what you can find… you have to be imaginative and flexible with your plans. I took a trip to my local thrift store and mooched around all the aisles. Then I mooched around them all again. After many “maybes”, instead of the money belt, I settled on a small leather camera case with a belt loop and for the shoe end of things I picked up (an awesome find for $1.50) a back support belt. Yes really. The belt was 8 inches wide, had rigid vertical ribs like a corset (once detached, these would be great to mounting the LEDs onto) and was held up by a set of stretchy braces (suspenders for you North Americans) (which would provide all the stretchy straps I needed) and held together by loads of velcro tabs & fasteners. Just perfect – a tripartite triumph.

Shoe Pieces

Once home, I started with the shoe pieces. I cut out a pair of the ribs from the back support belt and hot glued the LEDs in place across the front. The wiring consisted of a common 0v wire running the length of the rib just below the LEDs and the individual signal wires looped up over the top. More hot glue on the back held everything in place. I cut lengths of stretchy strap from the braces and hand-sewed velcro onto the end (note to self: don’t ever hand-sew velcro again… ow ow ow) – this would then wrap around the shoe and fasten back onto itself with the LED rib glued onto the strap at the appropriate point. I cut 8 inches off the end of the ribbon cable and split it into two 5-way wires – one for each foot. These 5 wires I then soldered to the LED wires on the back of the ribs and attached the ribs to the stretchy straps with a big squirt of hot glue, sandwiching all the solder joints in the middle – so no exposed bare wires. Then I soldered the male (PCB mount) half of the Insulation Displacement Connectors onto the other ends of the 5-way wires (the smallest IDCs that Lee’s stocked were 10-way so half the pins were unused but, at under a buck a connector, I’m not complaining). Finally, to protect the soldered joints (and to protect my ankles from the soldered joints) I wrapped an inch of heat-shrink tubing around the connector and squirted another big blob of hot glue up the open end of the heat shrink to act as a strain relief. And the shoe pieces were complete.

Power & control unit

In theory the Lilypad can be run from a single AAA cell fitted to the power supply board. This will step-up anything from as low as 1.2v into the 5.0v needed to power the Lilypad. This worked initially but I found that driving too many LEDs at once required too much current for the single cell to provide reliably and the Lilypad would reset itself. Instead I borrowed a 3xAAA holder from an old flashlight, fitted three 750mAh AAA NiMH cells into that and soldered the output onto the power board. Now I’ve got about 4v and 2000mAh capacity… should be plenty. As a quick test I let the system sit with all 8 LEDs on for a while and it took 90 minutes to drain. Great – I’ll pack a backup set of batteries and I should be fine.

A two foot length cut from the 10-way ribbon cable comes up into the camera case through a small hole I cut in the bottom and is then soldered directly onto the I/O pins of the Lilypad. I decided that it was good to show off the controller so I hot glued a patch of velcro onto the back of it & a corresponding piece onto the front of the case so I could mount it there. This also gave me access to the reset button that I could now easily use for changing modes.

The whole contraption then slips onto a belt with the batteries in the bottom of the camera bag and the power supply board on top of them for easy access to the power switch. The cable comes out of the bottom of the case and attaches to the cable coming up the legs with any excess being easily hidden in a pocket.

Connecting Cable

Connecting the control & power unit to the feet was easy. I took the remaining length of 10-way ribbon cable, ripped it up the middle for most of its length and attached connectors to the three ends. The 10-way will connect to the control & power unit, the two 5-ways will connect to the shoe pieces and most of the wiring will be hidden inside my jeans.

Firstly I needed the ability to change the effects mode using the button. I originally added this by testing to see if the button was down, incrementing a global variable that I used for the mode, a switch statement to divert program flow depending on the current mode value and different functions for each effects mode. The effect was pretty to look at but the code was even worse than the previous test: overly long and the patterns were defined by the actual program logic – meaning that more program code would have to be written in order to add more patterns and the code to control 8 LEDs would be twice as long. You can see that particular iteration here: http://topdownview.com/arduino/glitch/Glitch_multimode

When I was trying to come up with a clever design for storing the LED patterns, I kept wanting to use objects… it was very hard to constrain myself to simple procedural C!

I chose to do a lot of work with arrays. To start with, I could put the pins used by the LEDs into an array:

 int ledPins[] = { 5, 6, 7, 8, 9, 10, 11, 12 };

and then reset them all in setup() like this:

for (int pin = 0 ; pin < numLeds ; pin++) {
  pinMode(ledPins[pin], OUTPUT);
  digitalWrite(ledPins[pin], LOW);
}

And I put the effects modes into an array. The first design looked like this:

int pattern[][5] = { { 100, OFF, OFF, OFF, OFF},
                     { 200,  ON, OFF, OFF, OFF},
                     { 200,  ON,  ON, OFF, OFF},
                     { 200,  ON,  ON,  ON, OFF},
                     { 500,  ON,  ON,  ON,  ON},
                     { 200, OFF,  ON,  ON,  ON},
                     { 200, OFF, OFF,  ON,  ON},
                     { 200, OFF, OFF, OFF,  ON},
                     { 400, OFF, OFF, OFF, OFF}};

with the first parameter being the number of milliseconds to hold a specific display. You can see a version of code that uses that array format here: http://topdownview.com/arduino/glitch/Glitch_pattern_array

Then I realized I could use binary for the individual on/off LEDs (which scaled very easily for the 8 LEDs I needed) plus I needed a way to store the different effects modes. So I ended up with an array structure like this:

 int pattern[][3] = { { 0,9000, B00000000},  // mode 0: Everything off
                      { 1,  80, B10000000},  // mode 1: 2 LEDs run down the length of the line
                      { 1,  80, B11000000},
                      { 1,  80, B01100000},
                      { 1,  80, B00110000},
                      { 1,  80, B00010000},
                      { 1,  80, B00001000},
                      { 1,  80, B00001100},
                      { 1,  80, B00000110},
                      { 1,  80, B00000011},
                      { 1,  80, B00000001},
                      { 2, 150, B10001000},  // mode 2: 1 LED runs down the length of the line
                      { 2, 150, B01000100},
                      { 2, 150, B00100010},
                      { 2, 150, B00010001},
                      { 2, 150, B00100010},
                      { 2, 150, B01000100}};

Here the first parameter of each row is the effects mode that this line refers to, the second parameter is the length of time to hold that display and the third parameter is a binary bit-field for the 8 LEDs. Now any time I want to add a new effects mode it’s as simple as adding new lines to the array – no new program logic required. The program code steps through the array after each timing period looking for the next line that applies to the current effects mode and, if it reaches the end of the array, loops back to the start.

I was able to decouple the program logic from the size of the arrays by having the program work out the array sizes for itself in setup():

    numSteps = sizeof(pattern)/sizeof(pattern[0]);
    numLeds = sizeof(ledPins)/sizeof(ledPins[0]);

Again, in an OO language I’d have just used foreach to step through the arrays, but here I had to work without that luxury.

At one point I had the button generating an interrupt to increment the effects mode. But, as I was wiring up the hardware, I thought “it’s damn awkward having this button floating around… I wish there was some way I could use the button that’s already on the Lilypad board”. That button’s the reset button… so obviously I couldn’t do that because everything’s erased when the board’s reset. Hmmm… except the microcontroller has some EEPROM for storage that isn’t erased on reset. So I changed the code to store the effects mode in the EEPROM and increment the mode each time it resets. Then I didn’t need the separate button at all – every time the reset button’s pressed the Lilypad starts up in the next sequential effects mode. This had another major benefit: if the board reset itself (and I was initially fearing possible power-drain related resets for modes that illuminated too many LEDs at the same time) then when it restarted it would magically skip over the problematic mode.

The only other oddity in the code was how to deal with detecting when we’d stepped through all the available effects modes and had to set the mode back down to zero. In hindsight, I probably should have run through the pattern array in setup() to determine the highest mode value and then compared against that whenever I incremented the current mode. What I actually did was: when I was about to go hunting for the next line that referred to the current pattern, the code memorizes where in the pattern array it’s starting its search and then if it steps all the way around and back to the same line without finding a match, that means the mode variable is now too high and has to be set back to zero. So my “find the next matching pattern line” code looks like:

int startStep = currentStep; // Remember where we started from in the pattern array
 
// Loop through the array looking for the next pattern line that matches our
// current effects mode
while (true) {
  currentStep++; // move to next step
  if (currentStep >= numSteps) currentStep=0; // at end of array, loop back to start
  if (pattern[currentStep][0] == modeGet()) break; // this pattern line applies to this mode, so use it
  if (currentStep == startStep) { // if been all the way around, we have nothing for this mode
    modeSet(0); // so reset the mode back to the first mode
    currentStep = -1; // and start searching from the beginning of the pattern array
    Serial.println("Looped around - clearing mode");
  }
}

The full and final code can be seen here:  http://topdownview.com/arduino/glitch/Glitch_final_code

My first test hardware involved connecting the button and 4 of the LEDs to pads on the Lilypad. I started from the basic Blink program and added more LEDs and more delays to give some visual effects. I also added the ability to detect button presses in order to change the pattern.

I defined a couple of constants in my code:

int pin1 = 9;
int pin2 = 10;
int pin3 = 11;
int pin4 = 3;
int pinButton = 12;

then I needed to add code into setup() to tell the Lilypad how the hardware was configured:

pinMode(pin1, OUTPUT);
pinMode(pin2, OUTPUT);
pinMode(pin3, OUTPUT);
pinMode(pin4, OUTPUT);
pinMode(pinButton, INPUT);
digitalWrite(pinButton, HIGH);

The digitalWrite() for a pin configured as an input might seem counter-intuitive but it’s an important step. It makes the Lilypad connect the input line to an internal pull-up resistor so that, when the line isn’t pulled down to 0v by the button being pressed, the line is at a solid 5v. Omit this line and you’ll get a lot of spurious signals from the button as the Lilypad tries to work out what the floating input line is doing.

Then in the main loop() code I can use

if ((digitalRead(pinButton) == LOW)) {
  // code goes in here for when the button's pressed
} else {
  // code goes in here for when the button's not pressed
}

to detect if the button is down and adjust the output accordingly. The first code block contains

  digitalWrite(pin1, HIGH);  // turn on the first LED
  digitalWrite(pin2, LOW);   
  digitalWrite(pin3, LOW);   
  digitalWrite(pin4, LOW);   
  delay(speed);              
  digitalWrite(pin1, LOW);   // turn on the second LED
  digitalWrite(pin2, HIGH);   
  digitalWrite(pin3, LOW);   
  digitalWrite(pin4, LOW);   
  delay(speed);              
  digitalWrite(pin1, LOW);   // turn on the third LED
  digitalWrite(pin2, LOW);   
  digitalWrite(pin3, HIGH);   
  digitalWrite(pin4, LOW);   
  delay(speed);              
  digitalWrite(pin1, LOW);   // turn on the fourth LED
  digitalWrite(pin2, LOW);   
  digitalWrite(pin3, LOW);   
  digitalWrite(pin4, HIGH);   
  delay(speed);              
  digitalWrite(pin1, LOW);   // and turn them all off
  digitalWrite(pin2, LOW);   
  digitalWrite(pin3, LOW);   
  digitalWrite(pin4, LOW);   
 
  delay(speed2);

and the second code block contains pretty much duplicated code but with the lit LED rotating in the opposite direction.

And yay – ugly but it worked!
See the full source code for this test here: http://topdownview.com/arduino/glitch/Glitch_first_test

The Arduino development environment is super simple to work with. The tools are written in Java so they’re cross-platform. If you’re running Ubuntu then installation is simply a matter of visiting the Software Centre, typing in ‘Arduino’ and clicking the install button for the Arduino IDE program that pops up. If you’re on Windows or Mac then it’s not much more complicated than that either – download the software from the Arduino website and install.

Then plug one end of the programming cable into your Lilypad (be sure to get it the right way round – the board is marked B and G for the Black and Green wires in the cable) and the other end into your computer. At this point your computer discovers a new serial port provided by the USB cable – again if you’re running Ubuntu it just works but if you’re running Windows to Mac there’s help here to guide you through installing the necessary device drivers.

Run the Arduino IDE and go to Tools->Board to select the correct board that you’re programming. In my case it’s the “Lilypad Arduino w/ATmega328″. Then click on Tools->SerialPort to check that your system’s detected and selected the correct serial port.

Now you’re ready to go! The IDE contains over a hundred simple program examples to get you started with whatever piece of code functionality or add-on hardware you’re trying to use. The Arduino equivalent of Hello World is called Blink and we can use it now to test out our Lilypad and workflow. The Lilypad contains an LED already mounted to the board so we can run the Blink program (File->Examples->Basics->Blink) without having to attach any extra hardware.

/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.
This example code is in the public domain.
*/

void setup() {
// initialize the digital pin as an output.
// Pin 13 has an LED connected on most Arduino boards:
  pinMode(13, OUTPUT);
}

void loop() {
  digitalWrite(13, HIGH); // set the LED on
  delay(1000); // wait for a second
  digitalWrite(13, LOW); // set the LED off
  delay(1000); // wait for a second
}

Arduino code is written in C so if you’ve got any programming experience it isn’t going to take long to pick up. The program that you write gets compiled on your computer and then transferred to the Arduino where it’s run by a boot loader program. The boot loader program expects to find two functions in your code:

• setup() is called once when the program starts up. Use this for initializing variables and setting the mode (input or output) of the various I/O pins
• loop() is called repeatedly. Depending on your task and your personal programming style you can keep control within loop() or you can let the program flow fall out the bottom and have the boot loader call you again.

The example Blink program flashes the Lilypad’s on-boad LED: one second on, one second off and repeat until you unplug it.

So what hardware are we going to need?

We’ll need:

• a Lilypad Arduino – the programmable microcontroller that drives everything. It’s got 14 digital I/O pins that can drive LEDs directly
• a power supply – this lovely little board takes a single 1.5v AAA cell and steps it up to 5v to drive the Lilypad. However I think I’d power it differently if I was doing things over again
• a cable to connect it to a computer for programming. This is USB at one end and serial at the other with a connector that plugs directly onto the Lilypad for downloading programs, communication back to the computer and power
• 8 LEDs – I used LEDs specifically designed to complement Lilypad
• a button for changing modes – again this is specifically designed for the Lilypad line, although I ended up not using it in the final design
• lots of wire & connectors

For wiring, I need a signal line for each LED down each leg, plus a common 0v line – so 5 wires per leg. I visited Lee’s Electronics on Main Street in Vancouver for parts (they’ve got loads of Arduino items but if you’re not local then SparkFun are a great online source for everything Arduino) and I took the brave decision to explain to the assistant exactly what I was planning to do with this hardware, rather than just swan in and give him my parts list. He was really helpful and suggested ribbon wire for the wiring. This was a smart move as it’s cheap, low bulk and meant I could use insulation displacement connectors for one half of each connector, eliminating half the fiddly wiring. It also looks cool if you’re into the whole ‘visible electronics’ thing. If you’re into e-textiles then you can actually buy electrically conductive thread and sew your circuit into your clothes. Pretty amazing but I was just looking for a temporary solution and I didn’t fancy the idea of sewing 5 lines down each pant leg.

I bought 9 foot of 10-way ribbon cable which, even allowing for lots of slack in the system, turned out to be about 2 foot too much (but I knew I was buying too much: it’s like haircuts… it’s much easier to take off a little more at the end than it is to add some back on). Another great thing with the ribbon cable: you can just tear it up the middle and suddenly, with no extra work, you’ve got a cable that’s 10-way at one end and splits into two 5-way cables at the other end!

One downside of the insulation displacement connectors is that the male side of the connector is usually soldered into a circuit board. Nobody ever uses them for in-line connectors (as I was trying to do) so the only option I had for the male connector was a PCB mount variant with exposed pins on the back side. This makes for rather fiddly soldering and a connector that’s far from ideal for wearing, so I added a length of heat-shrink tubing to my basket.

And finally, I also bought a pack of crocodile clip test leads for prototyping. I knew I had a set at home somewhere but you can never have enough crocodile clip leads – and actually, even having found the second set I had at home, I didn’t have enough leads to fully wire-up the 8 LED design with crocodile leads.

- the player community is very friendly… it’s not unusual to have strangers give you items or strike up conversations with you as you walk down the street. This is a game where there’s no player-player combat and very little opportunity to cause your fellow players grief so it maybe shouldn’t be surprising that it attracts a different type of player

- the developers are amazingly open and involved… it’s not unusual to see company founder Stewart Butterfield in the forums engaging in debate about a new game addition or to see a player suggestion appearing in the game

I don’t think I’ve ever seen a game that encouraged player-player interactions and the whole concept of “paying it forward” as much as this game. There’s a unique thrill to be got from helping out a less experienced player with some food or advice – it makes them feel valued within the game and you know that they’ll want to repay your kindnesses to others later on. Plus the players create stuff of their own to have fun with: lotteries, casinos, quests, challenges… almost universally group events.

Glitch came out of beta a month ago and the quiet world of the beta testers has been swamped by tens of thousands of new eager players discovering everything for the first time. The developers have done a great job surviving the onslaught and still introducing a whole raft of new features. To celebrate the launch, Tiny Speck put on a party here in Vancouver last night & I was lucky enough to snag myself a ticket.

Hmmmmm… what to wear, what to wear? Well the invite made mention of dress-up and a tickle trunk so I think some sort of costume is called for. The obvious choice is to dress as my Glitch and fortunately that’s not too difficult or outrageous – he basically wears all black LOL. However he does have the most incredible pair of LED shoes with a row of lights that strobe down the sides. Hmmm… actually, you know what… I could absolutely make those. John Biehler introduced me to the Arduino microcontroller platform last year and I’ve been wanting a nice little project to implement with it. Even better, there’s an Arduino variant called Lilypad, created by Leah Buechley at the MIT Media Lab, specifically for wearable electronics.

So yeah – with a little bit of programming, some fairly cheap electronics, a visit to the thrift store and a lot of hot glue, I built myself a set of flashing light shoes. With multiple modes! The shoes were a big hit at the party and I lost count of the number of people who came up to me to comment on them.

Both the Arduino and Glitch communities are heavy on the concept of sharing, so I’ll be posting details of the shoes’ construction and software here (in great detail!). If you’re interested in Arduino then you’ll probably find something of use in each of the posts. If your interest is purely Glitch and non-technical then you might want to skip the geekery and jump straight to the demo video.

The first computers I ever built (and then disassembled and then rebuilt) never seemed to gather any dust. But over the last 5 years I’ve seen an increasing amount of dust gathering inside my computers’ cases. I have no idea why… it seems to have corresponded roughly to when I moved from the UK to Canada so maybe Canada is a dustier country

Over the last year I’ve seen the internal temperatures in my current desktop PC steadily rising:

Before cleaning

These are the Core0 – Core3 temps and two copies of the hard drive temp.

So last week I opened up the case and vacuumed it. I cleaned all the vents, sucked the dust off the fans, sucked all the dust bunnies out and cleaned the processor heatsink.

The heatsink was problematic. The PC has a Core2Quad processor (big heatsink) in an Apevia X-QPack mATX case (small case). As a result there’s not much space and the narrow nozzle of the vacuum cleaner was never going to get anywhere near the heatsink without me disassembling the case. Rather than do that, I used the poor man’s compressed air duster (ie I blew through a straw) and blew the dust out of the heatsink vanes then vacuumed everything up.

With everything reassembled and allowed to run for 24 hours, the temperatures dropped to:

Temperatures after cleaning

Those temperatures are Core0 – Core3, “CPU temp”, “motherboard temp” and the hard drive. [Actually, at time of writing, they're 5C below those numbers - but today's a much colder day]

Not sure where the “CPU temp” and “motherboard temp” sensors are being read from. The case has a front panel temperature LCD and two free-floating sensors which I’ve attached to the top of the hard drive and the chipset heatsink… but those are currently reading 26 and 47 degrees… so apparently not related.

To complicate things slightly, between taking the two sets of readings I also upgraded from Ubuntu 9.10 to Ubuntu 10.04 (more about that later). I’ve seen some reports on the internet from people who noticed the reported sensor temperatures dropping as a result of the upgrade. I did the upgrade a day before I cleaned and didn’t see any fall in reported temperatures afterwards so I don’t believe that that’s a factor in the improvement that I’m seeing.

So there you have it: a year’s worth of dust had clogged up my CPU heatsink and fans to elevate temperatures by approximately 15C. If it’s been over a year since you opened up YOUR computer’s case then maybe you should give it a spring cleaning too?

It’s not a replacement for a laptop:

• it has no USB ports for peripherals
• no multi-tasking (we think)
• limited opportunity to develop applications for it (developers have to work within the walled garden of the AppStore and users have to sync through iTunes)

But it’s too big to be pocketable so it’s not a replacement for a PDA like an iPod Touch.

If I wanted to actually “do” anything then I’d take a laptop along with me, if I wanted to read a book or a PDF then my gut feel is that I’d rather have an eReader (Engadget has a great comparison with the Kindle), if it’s just for casual internet access then a smartphone will do.

I think a major part of the market for the iPad is going to be iPhone users who are finding it too hard to read all the information that they’ve got access to on the screen of their phone.

Besides products, Apple are also great at making markets. Just because few people can see a need for a product today doesn’t mean that they couldn’t take advantage of it if they had one. Lots of Apple fans will buy them regardless, even if they already carry an iPhone and a MacBook around with them. And once they get the product out there in people’s hands in quantity, applications and use-cases will follow. It’s sure to be another winner.

I think most people considering the iPad will already have a smartphone and probably a laptop as well. I think we can also assume that these people carry their smartphone with them everywhere. So, if we’re assuming that technology purchases are made with the intention of simplifying our lives then will you be taking your iPad with you in situations where you previously took your laptop (which I see as a win)? Or will you now be carrying three devices (which I see as a fail)?

Continuing from that… if you’re already carrying your smartphone around with you everywhere, I see the 3G option as unnecessary for most people. Why not save the $130+$30/month (or Canadian equivalent) for iPad 3G access and tether the iPad to your phone? As far as I can see, there’s no definitive statement as to whether or not the iPad can be tethered. But you can bet that any lock-down that Apple put on it will be broken within a month or two and I’m sure tethering is one of the things that the community will enable.

Whilst thinking about phones, one of the features that interested me was the inclusion of a microphone. Whenever I see a microphone on a wireless device, my first thought is of Skype (even though I’ve barely ever used Skype myself!). The lack of a camera might be an issue for some people but, especially now that Apple have graciously allowed VoIP applications to connect over 3G, you could actually use the iPad to make phone calls. It’s probably a little on the large side to replace your mobile phone and the lack of multi-tasking means that you couldn’t talk to someone whilst you get information for them from an email or a webpage but I think it’s an interesting use-case – especially when tied to an unlimited data plan.

Oh, and we can’t talk about the iPad without talking about the horendous name. Everyone seems to have agreed that it’s dreadful.. but then is it much more dreadful than iPod sounded when we first heard it? Heck, look at all the flack that Nintendo took for the Wii and that didn’t stop it flying off the shelves. I suspect in a few months we’ll have forgotten all the feminine hygiene wisecracks and moved on. Breaking out of the i{thing} naming pattern is long overdue for Apple. But the brand recognition of i{thing} is immense… I can’t see Apple having the guts to do it and, as a result, I think it’s actually becoming an Achilles heel of the brand as much as it’s a strength.