Creating an Multitouch Interactive Graphic

Assessment of my Interface and Information Design subject this semester required that we create a Multitouch interactive graphic which promoted social change. This post will detail that process from beginning to end.

Choosing an Area of Interest/Gathering Data:

The direction of the assignment was fairly broad, as far as content material goes. Whilst it had to be persuasive, and it had to be designed for a touch screen, it was otherwise quite open ended. Eventually, I settled on the rather fascinating question of how we go about dying. Whilst everyone will, eventually, most of us rather try and avoid it, with the unintended side affect that no one really knows, off the top of their head, what’s killing us. I headed to google and punched in ’causes of death,’ which led me almost immediately to The Australian Bureau of Statistics. They had compiled, from 1999-2009 the way every person who had expired in the last year. They’d also grouped them into categories (different types of cancer, external causes etc). You can find that spreadsheet on their website here; http://www.abs.gov.au/AUSSTATS/abs@.nsf/DetailsPage/3303.02009?OpenDocument.

Identifying Inspirational Works

There’s a lot of really good examples of information design around the internet, and it comes in all shapes and sizes. I’d seen We Feel Fine back when it first launched, and was suitably impressed. They’d done some work since then, so I had another play when we were shown it in the lecture. It was even better than when it first launched – clean and tidy, yet allows you to drill down for really detailed looks at specific feelings or areas. I’d also long followed the work of The Oatmeal. While technically a webcomic, many of the strips take the form of (static) infographics, such as this one – a quick guide to diagnosing a computer.

Both of those where examples that I already knew of from my own experiences. GapMinder.org was unknown to me (though I vaguely remember seeing a TED talk from Hans Rosling at some point). The information design that they do tends to be less flashy than some other examples, but all the examples on that site (well worth looking at, if you’re interested), very clearly articulate the respective points they are trying to make.

Identifying an Assumption

Having already chosen to explore what was killing us, I began to focus on what I was wanting to show with the information graphic. It struck me that, perhaps as a correlation of our phobia of death – no one seemed to have any perspective on what killed us. While a death from drug overdose, violence or, heaven forbid, a celebrity, made the news, someone passing away in a hospital bed did not. A quick look of the numbers showed that what I believed was correct – infinetely more people expired from ‘natural’ causes, such as disease, than accidents or foul play. But I wanted to show this clearly, hopefully finally putting to rest every conversation that begins with, “You know, they say more people die from (x) than ever before)”

Substitute (x) for whatever’s been trending in the news lately, and you get uninformed drivel that sounds right, but really isn’t.

Developing a Use Case Scenario

We’d been told that the information graphic would be displayed on the yet-to-be-complete ‘Cube’ in the new Science and Technology Precinct, and that it would be open to the public. As such, I decided that it would be best to avoid using horrifying imagery, and animated sequences of Death cutting people’s head’s off with a Scythe. I elected for a light, bright colour scheme and stick figures to represent the categories of dead people. The idea was for people of all ages to see this, play around with it a little and come away a *little* better educated on what was killing us all. It didn’t have to tell them anything much more complicated, as that would probably just bounce anyway. I believed, for a public display, the simpler the better.

Developing an Interface

In case there were any trends on certain types of death being more popular in given years, I decided to use a timeline slider, to give people the ability to scroll through the given data. I also had a though to include some tickboxes – if someone just wanted to see people that had been killed versus the people that had died in accidents, they should be allowed to.

I also had a thought that I wanted this to be seen as a crowd of people, rather than a few people representing by their scale or position the rest. This resulted in an initial mockup that looked like this.

In order to find out what the person had died from, the idea was that you dragged a man into a circle in the middle, and more information would come up – kind of like a magnifying glass. I then thought to make better use of the multitouch capabilities, and make each ‘person’ expandable with a two fingered anti-pinch gesture, allowing the user to see information that had been recorded on him the whole time.

That, when I pushed it into flash and got it (mostly) working, looked like this:

Unfortunately, there where a few key things that DIDN’T work:

• It was supposed to scale up – deselecting ‘disease’ should put more men on the screen.
• I couldn’t remove old ‘people’ from the stage – no, its not ageism. There was a way to do it, but I ran out of time to find it. This broke both the timeline slider and the check boxes.
• It wasn’t displaying anywhere near enough people, and if it was, it wasn’t displaying them big enough. Something was wrong with my math, and despite calling in some outside help for the formulas, I couldn’t figure out what.

So with limited time left on the clock, I elected for a more simplified arrangement I’d earlier skipped over. There would be 3 ‘People’ on the stage, and they’d be scaled up according to how many of the dead they where representing.

This meant some fairly radical changes to the code, rendering useless great swathes of what I’d done previously.

Whilst changing the code, I realised it would be more visually effective to instead create a ‘man’ for each type of disease or accident, and then scale each one appropriately as to the number that had died from it.

It still didn’t perform quite as expected:

• The visible properties of the men didn’t seem to keen on changing – this broke both the timeline slider and the checkboxes
• The scaleamount was supposed to adjust according to what was on the screen – again, this wasn’t working.
• The man had a text label above his head (currently statically set to Example COD)* which was supposed to give the name of the disease he was dying from. Unfortunately, this didn’t work either.

On the plus side:

• Resizing the men was a much more powerful visual tool than my initial idea of using a swarm
• There is a lot less complexity in the code (at least 3 less arrays, less calls back to the Arrays), and it performs much better for that.
• Because of the above, its a lot easier to code – if I had an additional day, I could probably get the bugs out – but alas, I’m out of time.

The code in its entirety is included below.

Main.as

package
{

	import flash.display.MovieClip;
	import flash.events.Event;
	import flash.net.URLRequest;
	import flash.display.Sprite;
	import com.shortybmc.data.parser.CSV;
	import flash.events.MouseEvent;
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import fl.transitions.Tween;
	import fl.transitions.easing.*;
	import fl.transitions.TweenEvent;
	import fl.events.SliderEvent;
	import flash.display.IBitmapDrawable;

	public class Main extends MovieClip
	{
		//A variable to hold the CSV file
		var csv:CSV;

		//an array for the number of deaths in all years
		var totalDeaths:Array;

		//For pointing to the appropriate part of the array/CSV file
		var startIndex:int;
		var rowLength:int = 44;

		//For pointing to the right year
		var thisYear:int = 2003;

		//ScaleAmount (used later when drawing)
		var scaleAmount:Number = 0.01;

		//create an array to store the dead men from this year
		var deadMen:Array = new Array;

		public function Main()
		{
			//Import the CSV File
			csv = new CSV(new URLRequest('../data/causes_of_death.csv'));

			//EVENT LISTENERS
			//When the data has loaded in, extract the useful parts
			csv.addEventListener(Event.COMPLETE, completeHandler);

			this.TimelineSlider.addEventListener(Event.CHANGE, TimelineUpdater);

		} //Close off the main function

		function completeHandler(e:Event)
		{
			trace("completeHandler has executed"); //debugging

			//Set the TimelineSlider somewhere aesthetically pleasing
			TimelineSlider.value = 2003;

			//set the start index (year 2003)
			this.startIndex = 20; //Column 21

			//Read in the data from the spreadsheet, to save having to do it every time slider moves (big performance hit)
			readCSV();

			//give focus to the timeline slider
			stage.focus = TimelineSlider

			//Add the event listeners we weren't ready for yet
			//Checkbox Event Listeners
			this.ChAccident.addEventListener(MouseEvent.CLICK, setFilter);
			this.ChFoulPlay.addEventListener(MouseEvent.CLICK, setFilter);
			this.ChDisease.addEventListener(MouseEvent.CLICK, setFilter);

			//Do the Initial update
			update()

			trace("completeHandler has stopped executing"); //debugging
		}

		function setFilter(e:Event)
		{
			//Make all the dead people visible by default, if this is their year
			for (var i in this.deadMen)
			{
				if(deadMen[i].inYear == thisYear)
				{
					deadMen[i].visible = true;
				}
			}

			//reset the scale amount
			scaleAmount = .01;

			//If the Filter is NOT selected, set its variable to false (used later by the update function)
			if(this.ChAccident.selected == false)
			{
				trace("filterAccident = false");
				for(i in this.deadMen)
				{
					if(deadMen[i].COD == "accident")
					{
						deadMen[i].visible == "false";
					}
				}
			}
			if(this.ChFoulPlay.selected == false)
			{
				trace("filterFoulPlay = false");
				for(i in this.deadMen)
				{
					if(deadMen[i].COD == "foulplay")
					{
						deadMen[i].visible == "false";
					}
				}
			}
			if(this.ChDisease.selected == false)
			{
				trace("filterDisease = false");
				//no need to be so skingy with the scale amount if this is deselected
				scaleAmount = .5;
				for(i in this.deadMen)
				{
					if(deadMen[i].COD == "disease")
					{
						deadMen[i].visible == "false";
					}
				}
			}
			update();
		}

		function TimelineUpdater(e:Event)
		{
			//Each additional year from 1999 is 4 over from the index of 5;
			//Get the TimelineSlider, and adjust the index accordingly.
			switch(TimelineSlider.value)
			{
				case 1999:
					startIndex = 4;
					thisYear = 1999;
					trace("StartIndex = 4");
					break;
				case 2000:
					startIndex = 8;
					thisYear = 2000;
					trace("StartIndex = 8");
					break;
				case 2001:
					startIndex = 12;
					thisYear = 2001;
					trace("StartIndex = 12");
					break;
				case 2002:
					startIndex = 16;
					thisYear = 2002;
					trace("StartIndex = 16");
					break;
				case 2003:
					startIndex = 20;
					thisYear = 2003;
					trace("StartIndex = 20");
					break;
				case 2004:
					startIndex = 24;
					thisYear = 2004;
					trace("StartIndex = 24");
					break;
				case 2005:
					startIndex = 28;
					thisYear = 2005;
					trace("StartIndex = 28");
					break;
				case 2006:
					startIndex = 32;
					thisYear = 2006;
					trace("StartIndex = 32");
					break;
				case 2007:
					startIndex = 36;
					thisYear = 2007;
					trace("StartIndex = 36");
					break;
				case 2008:
					startIndex = 40;
					thisYear = 2008;
					trace("StartIndex = 40");
					break;
				case 2009:
					startIndex = 44;
					thisYear = 2009;
					trace("StartIndex = 44");
					break;
			}
			update();
		}

		function readCSV()
		{
			//Arrays for search terms, to do the classification
			var keyDisease:Array;
			var keyFoulPlay:Array;
			var keyAccident:Array;

			//Fill the search terms to use later
			keyDisease = ["CHAPTER I Certain infectious and parasitic diseases (A00-B99)", "CHAPTER II Neoplasms (C00-D48)",
						"CHAPTER III Diseases of the blood and blood-forming organs and certain disorders involving the immune mechanism (D50-D89)",
						"CHAPTER IV Endocrine, nutritional and metabolic diseases (E00-E90)", "CHAPTER V Mental and behavioural disorders (F00-F99)",
						"CHAPTER VI Diseases of the nervous system (G00-G99)", "CHAPTER VII Diseases of the eye and adnexa (H00-H59)",
						"CHAPTER VIII Diseases of the ear and mastoid process (H60-H95)", "CHAPTER IX Diseases of the circulatory system (I00-I99)",
						"CHAPTER X Diseases of the respiratory system (J00-J99)", "CHAPTER XI Diseases of the digestive system (K00-K93)",
						"CHAPTER XII Diseases of the skin and subcutaneous tissue (L00-L99)", "CHAPTER XIII Diseases of the musculoskeletal system and connective tissue (M00-M99)",
						"CHAPTER XIV Diseases of the genitourinary system (N00-N99)", "CHAPTER XVI Certain conditions originating in the perinatal period (P00-P96)",
						"CHAPTER XVII Congenital malformations, deformations and chromosomal abnormalities (Q00-Q99)"]

			keyAccident = ["CHAPTER XV Pregnancy, childbirth and the puerperium (O00-O99)",
						"CHAPTER XVIII Symptoms, signs and abnormal clinical and laboratory findings, not elsewhere classified (R00-R99)",
						"Transport accidents (V01-V99)", "Other land transport accidents (V80-V89)", "Falls (W00-W19)", "Exposure to inanimate mechanical forces (W20-W49)",
						"Exposure to animate mechanical forces (W50-W64)", "Accidental drowning and submersion (W65-W74)", "Other accidental threats to breathing (W75-W84)",
						"Exposure to electric current, radiation and extreme ambient air temperature and pressure (W85-W99)", "Contact with heat and hot substances (X10-X19)",
						"Contact with venomous animals and plants (X20-X29)", "Exposure to forces of nature (X30-X39)",
						"Accidental poisoning by and exposure to noxious substances (X40-X49)", "Overexertion, travel and privation (X50-X57)",
						"Exposure to other specified factors (X58)", "Exposure to unspecified factor (X59)", "Complications of medical and surgical care (Y40-Y84)",
						"Sequelae of transport accidents (Y85)", "Sequelae of other accidents (Y86)",
						"Supplementary factors related to causes of morbidity and mortality classified elsewhere (Y90-Y98)", "Nosocomial condition (Y95)",
						"Work-related condition (Y96)", "Lifestyle-related condition (Y98)"]

			keyFoulPlay = ["Handgun discharge (W32)", "Rifle, shotgun and larger firearm discharge (W33)", "Discharge from other and unspecified firearms (W34)",
						"Hit, struck, kicked, twisted, bitten or scratched by another person (W50)", "Striking against or bumped into by another person (W51)",
						"Crushed, pushed or stepped on by crowd or human stampede (W52)", "Exposure to smoke, fire and flames (X00-X09)", "Intentional self-harm (X60-X84)(f)",
						"Assault (X85-Y09)", "Event of undetermined intent (Y10-Y34)", "Legal intervention and operations of war (Y35-Y36)",
						"Sequelae of intentional self-harm, assault and events of undetermined intent (Y87)", "Sequelae with surgical and medical care as external cause (Y88)",
						"Sequelae of other external causes (Y89)", "Evidence of alcohol involvement determined by blood alcohol level (Y90)",
						"Evidence of alcohol involvement determined by level of intoxication (Y91)", "Environmental-pollution-related condition (Y97)"]

			//keep track of the ManID
			var ManID:int;

			//Variables to store the information read from the CSV (so we only need to do it once)
			var diseaseDeaths:Array = [];
			var accidentalDeaths:Array = [];
			var foulPlayDeaths:Array = [];

			//For each entry found in the array, create a man
			for(var i in keyDisease)
			{
				//For some reason, valid search keys return a null result sometimes. Searching by the row manually still works.
				//For now, throwing in a if statement to catch null results (or it breaks things later)
				if(csv.search(keyDisease[i], false) [0] != null)
				{
					//Get the array for the search result so we can create individual men for each year
					var deadFromThis:Array = csv.search(keyDisease[i], false);
					//trace(deadFromThis);
					//Start at 4 (first index), increment by 3
					for (var t:int = 4; t < deadFromThis[0].length; t = t+4)
					{
						deadMen.push(new Man(ManID, "disease", keyDisease[i], deadFromThis[0][t], t));
						ManID = ManID + 1;
					}
				}
			}

			for(var i in keyAccident)
			{
				//For some reason, valid search keys return a null result sometimes. Searching by the row manually still works.
				//For now, throwing in a if statement to catch null results (or it breaks things later)
				if(csv.search(keyAccident[i], false) [0] != null)
				{
					//Get the array for the search result so we can create individual men for each year
					var deadFromThis:Array = csv.search(keyAccident[i], false);
					//trace(deadFromThis);
					//Start at 4 (first index), increment by 3
					for (var t:int = 4; t < deadFromThis[0].length; t = t+4)
					{
						deadMen.push(new Man(ManID, "accident", keyAccident[i], deadFromThis[0][t], t));
						ManID = ManID + 1;
					}
				}
			}

			for(var i in keyFoulPlay)
			{
				//For some reason, valid search keys return a null result sometimes. Searching by the row manually still works.
				//For now, throwing in a if statement to catch null results (or it breaks things later)
				if(csv.search(keyFoulPlay[i], false) [0] != null)
				{
					//Get the array for the search result so we can create individual men for each year
					var deadFromThis:Array = csv.search(keyFoulPlay[i], false);
					//trace(deadFromThis);
					//Start at 4 (first index), increment by 3
					for (var t:int = 4; t < deadFromThis[0].length; t = t+4)
					{
						deadMen.push(new Man(ManID, "foulplay", keyFoulPlay[i], deadFromThis[0][t], t));
						ManID = ManID + 1;
					}
				}
			}

			trace(deadMen);

			//Get the total deaths for all the years
			var index = startIndex;
			//trace(index); //debugging
			totalDeaths = csv.search("Total deaths") [0];
			//trace(totalDeaths[index]);
		}

		//fill the screen with little men
		function update()
		{
			trace("update has started running"); //debugging

			//Go through the array and spawn a man on the stage for each entry.
			for(var i:String in deadMen)
			{
				var currentPerson:Man = deadMen[i];
				trace(currentPerson)

				currentPerson.update(scaleAmount);

				//set the y position
				currentPerson.y = stage.stageHeight - 500;

				//Determine the x position
				var newX:Number = (currentPerson.width/2) + Number(i) * ((stage.stageWidth - deadMen[deadMen.length-1].width - currentPerson.width)/(deadMen.length-1)) + (currentPerson.width/2);
				//set the xposition
				currentPerson.x = newX;
				//add to the stage
				this.addChild(currentPerson);
				//send it to the back
				setChildIndex(currentPerson, 0);

				//set everyone to visible by default
				currentPerson.visible = true;
				//hide anyone that isn't dead in this year
				if(currentPerson.inYear != thisYear)
				{
					trace("That person wasn't born this year");
					currentPerson.visible = false;
				}

			trace("update has finished running"); //debugging
			}
		}

	} //Close off the public class Main
}

Man.as

package
{

	import flash.display.MovieClip;

	public class Man extends MovieClip
	{
		public var id:int; // unique ID
		public var COD:String; //The cause of death (kept uniform in the calling function)
		public var diseaseName:String; //The detailed cause of death (infection, stabbity stabbing etc)
		public var deadFromThis:int;
		public var inYear:int;

		public function Man(id:int, expiryReason:String, detailDeath:String, numberDead:int, thisYear:int)
		{
			// constructor code
			this.id = id;
			this.COD = expiryReason;
			this.diseaseName = detailDeath;
			this.deadFromThis = numberDead;
			this.inYear = thisYear;

			//Display what disease the man has
			switch(COD)
			{
				case "disease":
					gotoAndStop(3);
					break;
				case "accident":
					gotoAndStop(2);
					break;
				case "foulplay":
					gotoAndStop(1);
					break;
			}

			//Get the index value and turn it into a year
			switch(thisYear)
			{
				case 4:
					inYear = 4;
					break;
				case 8:
					inYear = 2000;
					break;
				case 12:
					inYear = 2001;
					break;
				case 16:
					inYear = 2002;
					break;
				case 20:
					inYear = 2003;
					break;
				case 24:
					inYear = 2004;
					break;
				case 28:
					inYear = 2005;
					break;
				case 32:
					inYear = 2006;
					break;
				case 36:
					inYear = 2007;
					break;
				case 40:
					inYear = 2008;
					break;
				case 44:
					inYear = 2009;
					break;
			}
			//this.LabelCOD.text = diseaseName;
			//Each man is 3 times as high as he is wide
			this.height = this.deadFromThis;
			this.width = this.deadFromThis / 3;
		}

		//Assign the specific properties to the man
		public function update(scaleAmount:Number)
		{
			this.height = this.height * scaleAmount;
			this.width = this.width * scaleAmount;
			//Additional display charecteristics for the disease
		}

		// trace all property values of this person to the output window
		public override function toString():String
		{
			var str:String = "";
			str += "Person:";
			str += "\n   id = " + this.id;
			str += "\n   Cause of Death = " + this.COD;
			str += "\n   Disease = " + this.diseaseName;
			str += "\n   Dead From this = " + this.deadFromThis;
			str += "\n   Died in the year = " + this.inYear;
			return str;
		}

	}

}

Assignment 2 Ideas

The second assignment that I have to complete for this subject is a fairly exciting one. It’s an interactive information display, designed for use on a large, multi-touch screen. And by large, I don’t mean iPad large. I mean t-rex large.

The application is to be written in Flash, and has to be themed along the lines of ‘Social Good.’ With that in mind, here’s 3 ideas that I’ve brainstormed up. Only one will actually get made into an application, but I’d like to thank all these thoughts for trying. Just making it through the alcohol soaked sponge that is my brain is a fairly impressive feat, and for that they should be congratulated.

1. How big is that, anyway? The idea behind this is that it shows the user how big certain things are, in scales that they’ll understand. Semi-inspired by the Wolfram|Alpha search engine, which gives comparisons when you give it a measurement in units. For example, entering ‘petabyte,’ gives the user the comparative measurement that its ‘.5 times the contents of the Internet Wayback Machine in 2006.‘ It could be used to give a comparative measurement on just how much water was pushed over Japan by the tsunami, or how much food is consumed by a Western Nation in a day. Or all of these examples.
2. Where does your $1 go? This would basically trace ~5 popular western products back to their origins. For example, a can of Cocoa costs about $4 in Australia. Using lines to connect it visually back to the countries it originated in or passed through, the diagram should show how much of that $4 actually made it back to the source of the product, and who collected the money at each stage. The user should be able to select the product, and see some additional details about each stage.
3. What happens to taxes? This should demonstrate where our tax dollars actually go. Keeping it Australia centric or it would escape the scope of the assignment, it should show both a percentage and a numerical value of which categories our tax money goes to: For example – Defense, Healthcare or Infrastructure. Preferably with subcategories – for Defense, I could use Navy, Airforce and Army. I think this would be particularly worthwhile, as, much as everyone grumbles about having to pay taxes, few people really think about what happens to that money.

Internet Thinks Development

My final piece of work for this assessment was to create a mashup of my very own, from scratch. Like most people on the internet, I’d been using mashups for some time without even realising it. My all time favourite was digg.com, which could be said to be the first popular news aggregation site. Like an estranged couple, Digg and I grew apart several years ago, when I started to lack the time to commit to the relationship. Since then, I’ve used any number of mashups with varying levels of commitment – the iTunes Podcast store, Google News, and Google Maps to name a few.

I was inspired by some of the examples we were shown in class – mashups that bought content from all over the internet that was related in some way, together in one simple page. However, to my (often wrong) mind, they all seemed too specific. People don’t want to bookmark 20 pages, one for each interest of their lives. A mashup for a favourite band, and mashup for finding what movies were worth seeing, a mashup for which bathrooms were nearest – it just seemed to go against the concept of simplicity that is the driving force behind many of these mashups.

With that in mind, I started pondering what I could create myself. It’s all very well to stand back and criticize what others have created, but as a friend that I lose poker to says, ‘put up or shut up.’ I had another vague notion that the point of the internet, for many people, is to hear the opinions of others. Either those we know, which is what a site like Facebook ultimately enables, or a site like Twitter, which gives the opinions of complete strangers.

The concept that was haltingly drawn out of the depths of my consciousness was this: A keyword driven search that returned Just What The Internet Thought About That.

I started by creating one pipe. The early days of my attempts at pipe creation are detailed here, so I won’t rehash in this blog post. Having created three separate pipes for the positive, negative and count results, I realised as soon as I started pulling the PHP out that the count pipe wasn’t necessary, as the PHP output of negative and positive already provided a count of how many results it had returned. Getting rid of the 3rd pipe sped the page up, but not by as much as I’d like. Unfortunately, because of the amount of sources the pipe has (twitter, Yahoo Search, Google Base, Flickr and Google News), and the amount of keyword checking it does (26 keywords a pipe), the page remains quite sluggish.

With the PHP outputting data to the page, I started work on formatting that data into something vaguely presentable. You can see the first results of that process on the left. A summary of what it found is presented to the user at the top of the page, followed by two vertical columns of actual results.

I decided to go for a dark look, and initially set a dark grey background. This didn’t look so good, so I went back to white. Remembering the transparent ‘plate’ on which results from the Tutor’s Movie Mashup pipe (blogged about here) sat, I was again inspired. I placed the ‘results’ on top of a dark plate, and the search box atop another (much smaller) plate. I initially played around with the transparencies to try and get a Windows Aero feel, but it didn’t turn out too well. In the end, I opted to make the plates opaque, with a drop shadow border.

The individual results themselves also got the ‘plate’ treatment. Here I ditched

the drop shadow border (partly because it wasn’t rendering properly in any of the web browsers I tested it in), and opted for a solid green for positive results, and a solid red for negative results.

Color coding them in such an obvious fashion allowed me to ditch the column header names, making the overall design look considerably cleaner.

I found, and shamelessly used, a small web based tool for generating the CSS properties for rounded borders, available here: http://border-radius.com/. I played around with this in an attempt to get a shape that was vaguely reminiscent of a speech bubble.

The final results of the CSS styling can be found on the right.

The target audience of the mashup is quite broad. Despite the weeks of work I put into it (mostly because I’m not very good at this), it remains extremely simple:  The user enters the name of a politician, band, movie, book, or anything else that strikes their fancy. The mashup tells them what the Internet Thinks about the object in question.

As always, anyone interested that happens to have a QUT login can view the pipe here.

Movies Mashup

This exercise was again involving Yahoo Pipes. This time, the point was to get the data out using a bit of CSS scripting. I completed this exercise outside of class time, using the tutor’s (dmwallace.wordpress.com) example as a visual guide. I also took a peek at his CSS when I got stuck.

I started with a template file we had been given in class. I pointed it at the appropriate pipe (available here) and then set to work adjusting the PHP loop to extract all the information I wanted to use from the pipe data into distinct variable names. I then dumped the output, more or less unformatted into the webpage. I did spend a bit of time getting the external links and that sort of thing working properly, but at this stage it was a webpage only a mother could love.

I took the liberty of adjusting a few things – not because they were bad in the sample given, but because the less elements on page I had to deal with, the easier it was for me to create the page. For example, instead of having a separate link to see the trailer, I made the poster art for the movie the link.

Other minor changes were made for the ‘reviews section’ (visible in the screenshot on the left underneath the poster art, but that was just in phraseology to make the page a little more personal. I like webpages that ask, and preferably answer the question ‘what do people think.’ My interpretation for this page may have been a bit too literal in that regard though.

Not visible without visiting the actual page is a bit of JavaScript fanciness I ‘borrowed’ (my interpretation of ‘borrow’ is that I lifted the code straight off the example page we were given). It’s a simple enough little animation that zooms out from whatever link you clicked and shows you the YouTube trailer in an overlay to the webpage. Quite pretty, all things considered.

The next step was making it look a little less 90′s. CSS is such a powerful tool, but sadly enough, I’m still a little nooby at it. I got hung up for a long time just getting the elements to position right (in the end, the errors where in the HTML, frustratingly enough). The end result isn’t exactly pretty, but its workable and has a visual direction I’d love to follow-up on if I had the time. As far as proof of concepts go, it’ll just about do though.

There’s a lot of pro’s of using this method over the JavaScript badge method that we were shown last week.

• Can select exactly which parts of the output that you want, and where. Can insert into different Div’s in multiple parts of the page, multiple times if you are so inclined.
• Accepts user input. Though not demoed with this example, you can allow the user to refine search results or do just about anything else using PHP
• Can display the output of multiple pipes side by side if necessary, without any visual difference between them for the user.
• Can perform computational functions – The tutor’s version had a neat average of the Critic score and audience score that I wasn’t sure how to implement.

There’s also a few con’s:

• More complicated, even if not by much.
• Requires a web server that can execute PHP, which is sometimes sold as a premium feature by web hosts.
• Requires some basic knowledge of programming.

Of course, there’s nothing to stop one using a combination of the two methods if one was so inclined. For anyone interested in what this would look like done properly, here’s a screen shot of the tutor’s version:

If you happen to be a QUT student, you can play with my version here.

Yahoo Pipes Exported as Javascript

One of the weekly exercises I was asked to complete as part of my Interface and Information Design subject was a mashup of a number of web sources into a singular ‘one stop shop’ for the Japanese Tsunami/Earthquake disaster.

The screenshot you see on the left, (and the pipe itself, which is available to view here [QUT Student/Staff account required]) consists of four pipes, exported from Yahoo Pipes as ‘Badges.’

It’s one of a number of export options Yahoo is kind enough to give you. There’s some fairly minimal HTML to get the page pointing in the right direction, and the rest was playing with CSS to get the formating right. Much of that work was purely in styling what had been handed to the page by Yahoo so it wasn’t so jarring. It also meant that much of the hard work in presenting the information, such as the geo-tagged map and the image slideshow, was already done by Yahoo.

This is the third version of this project I built – the first I built on the fly in class, and subsequently lost, the second I built about a week later so I could play with it (that version was much prettier, but also went missing somewhere in the depths of my computer). The third was constructed today, as I realised I’d need some evidence I’d actually completed the exercise.

Pros of Javascript Badges over PHP

• ‘Advanced’ formatting (like image maps and slide shows) already done.
• Simple to export with limited knowledge of HTML – Yahoo gives you the code to insert to any HTML page.
• Can run on web servers with less than advanced capabilities (i.e – no PHP engine).
• Lovely ‘pipes’ graphic while waiting for data to file in.

Cons of Javascript Badges in comparison to PHP

• Quite a bit of CSS work to filter out some of Yahoo’s FAP.
• Have to deal with someone else’s coding (YBF – who thought, ‘hey, this is a meaningful div name?’).
• Can only display the data. Cannot accept user input.
• Cannot perform any other computational functions on the data – it has already been generated.

I, Stick.

If I was a stick with a top hat, my life would look something like this.

For those wondering if I’ve finally completely lost my mind and started day dreaming about living in a (mostly) 2D world, you’re completely right, I have. And I blame university: This was actually part of an assignment. As was posting it on the internet, so people could look upon it with a mixture of disgust, dismay and condescension.

I borrowed heavily from this drawing which I found on Imgur, which (according to the comments), borrows heavily from something else which the author wasn’t kind enough to credit.

The exercise was a bit of practice at iconography – simplifying sometimes complicated concepts into simple drawings that can communicate across barriers of language and ignorance (of the specific subject).

I suspect I may have failed a bit there, as I had to include English labels of what exactly was going on, or you might just think an ant with uppity ideas about himself was just going about his day. But hopefully the point gets across.

Yahoo Pipes – Definitely Not Drugs.

Yahoo Pipes. No, kids, despite the best wishes of many, and the suspicious title, it’s not drugs.

Pipes is simply another way of doing a very old thing – aggregating the results of RSS feeds into a single, convenient feed. Unlike m

any such projects, it’s not designed with the end-user in mind, but rather website administrators that are looking for a simple, convenient way to add aggregated web feeds (with some intelligence behind them), to their sites.

As part of the first assignment for this unit (for any hypothetical readers that aren’t reading this because they’re marking it, I’m not writing this blog because I actually think I have anything worthwhile to say, it’s because its assessment for a university course), I have to create a site that aggregates several RSS feeds together into something vaguely approaching usefulness.

After some fairly disastrous first attempts at getting all the output I needed from one pipe, I decided it would be best to attend a tutorial. Through some sort of bizarre process I’m told is called ‘learning,’ I realised that it would be simpler to create several different ‘pipes,’ then add them together in a user interface later. The pipes that I created are freely available (though you will need a Yahoo account), and available here.

The idea behind the three feeds (the HTML interface being something I’m working on currently), is that the user can input a keyword. It then searches a variety of web sources for positive and negative mentions, counting both. It then provides the total count and examples of the positive and negative mentions to the user.

It’s a generalised sort of approach to other projects that allowed one to search twitter for positive mentions of movies or music, except it (should) search more sources, decide whether they are happy or sad about it, and let the user know.

Stay tuned (or don’t).

Lightweight Models and Cost-Effective Scalability

We’ve all gone cloud computing mad.

It seems that it’s just not cool to be a web service these days (though, it was never particularly cool being a web service) unless you’re somehow ‘in the cloud,’ or ‘using a cloud,’ or ‘integrating with a cloud.’ And what is this mysterious cloud anyway? All it means is that there is a server farm somewhere, whose racks (and thus, processor and storage space) are sold off piecemeal, usually for a monthly fee as opposed to an upfront cost. This sort of thing has always been available, but when you think about, its easy to see why it’s recently become so popular.

You see, server gear is expensive. And heavy. Really bloody heavy, and that’s coming from someone who spent 4 hours today helping install it. When you’re carting the 5th 55kg box down some stairs, into a Ute, to a separate building, across a courtyard, into a lift, out of lift, through a door, into a cage, then spend an hour figuring out how to bend the rails into shape to make the $10,000 bricks fit into a cabinet, you gain a new appreciation for the concept of ‘cloud computing.’ Because if the company I work for, instead of an initial outlay of $50,000 and an obligation to support the servers themselves, just paid someone else $1000 dollars a month to do it for them, I might still be able to stand up straight without making ‘old man noises.’

But I digress. But you can see how that makes a huge amount of sense from a business perspective. But please. Could we PLEASE stop calling it ‘cloud computing.’ The term is completely meaningless. It’s just a partial shift, of some services back to a server-client model. That’s it. That’s all it is. The server (or ‘cloud,’ if we really must) simply provides a service to the clients (the users, or businesses). There is nothing new or revolutionary to see here. What is revolutionary is the way that some people are leveraging this model to create *really* incredible things, often on a small budget.

Because big companies like Microsoft, with their Azure platform, have the resources to spend big. Really, really big. To the tune of 12 billion dollars big. And then sell it off, to thousands of smaller companies for as little, or as much as they want to spend each month. Site running slow? No problem, 3 clicks and you’ve got another 8 processors at your disposal. Run out of storage? No issue, rent some more, just hand over the credit card. Hardware outdated – we take care of that, it’s not your problem anymore. It is, literally, an IT managers dream. Or anyone that needs somewhere to run a website from. As cheaply, or as expensively as you like.

One of the better examples of scalability (starting small, becoming big) is ThinkFree Office. It wasn’t started by any company that anyone had ever heard of outside of South Korea. But it rapidly grew, and as it grew, added more storage space and processing power as it needed it, to allow people access to a fully functional office suite from wherever they are. It was a revolutionary product when it was first released in 2001, and the bigger players like Google and Microsoft went on to create very similar products, which many of us use today.

To wrap things up, because I’m quite sure everyone stopped reading a while back there, anyone that tells you ‘Cloud Computing is the future’ is full of bollocks. It’s the past, it’s just the Server Client model coming around again, bigger and better than ever before.

But the past never looked so bright… About as bright as this metaphor is confused.

The Looooonnnnnnggggg Tail

Long Cat is almost as long as the long tail. Which should be enough to tell you just how stupendously long the ‘long tail’ is.

For those saying to themselves, ‘This guy’s onto something. And it’s probably crack,’ hear me out. The long tail is an actual economical and sociological phenomena, that sadly, has very little to do with cats. The wiki article can explain it better than I can, for those that care, but to shorten the explanation into something a bit more manageable, the theory behind Long Tail basically states that ‘The more people buying things, the more people will want to buy very specific things, which previously wouldn’t have existed for lack of a market.‘

Contrary to popular belief, both long cats and long tails DID exist before the internet. The easiest example is that of an antiques store. An antiques store exists mostly to sell dead peoples furniture that no one wants anymore, but somehow, its still a financial proposition.

Of course, the internet is much bigger than any single city. And thus, the long tail is quite a bit longer, and instead of Antiques stores, we have Ebay, the iTunes App Store and web comics. Web comics being by far my favourite. You don’t even have to be a tremendously popular comic, like xkcd or Cyanide and Happiness, to make money off a talent that would previously have only earned you a few laughs and possibly a few rounds at a pub. By selling merchandise and advertising space, even smaller, less popular comics like Saturday Morning Breakfast Cereal, can start making money off their daily nuggets of comedic genius.

Then you have stores like TopatoCo that sell merchandise on behalf of these smaller comics, taking over the initial expenses of setting up credit processing facilities, liaising with manufacturers and all the other nomenclature that goes with making a living in the hectic, pressuring underbelly that is the comedic t-shirt game. They then take their profit off the top, and send the rest of the proceeds on to the makers of the web comics themselves, to keep them well fed with Mi Goreng and other, inferior brands of pot noodles.

All of these websites, in some way, are selling something that the vast majority of the world just isn’t all that interested in. And yet, they are fast becoming an important part of the internet economy.

Perpetual Beta

It seems to be trendy today to keep a product in beta for years and years, even if it’s perfectly serviceable. So much so, I’m contemplating just printing a ‘beta’ tag across my head whenever I try to speak to women. The thing is, no one seems quite sure why products are kept in this limbo.

Take Gmail. It was first released as an invitation-only service on April 1st, 2004, which caused some uproar, with much of the internet thinking it was an April fools joke. 1gb of storage? For free? Absurdity. It was eventually released to the public in February 2007, but stayed in ‘beta’ for another 2 years.

I was using Gmail from when I scored an invite, 2 months after its ‘invitation only’ release, to now. In that time, I have not encountered a single bug (that was their fault, had some file-upload issues with ubuntu – and even that they had a work around). In a side note, I’ve ‘archived’ pretty much every message I ever received. 7950 emails, and 975mb used.

The point is, if it was that bug free, why on earth was it in beta? No one seems quite sure, and it seems they are now going to pull the same trick with Google Wave. Wiser people than I have asked this question before, and it turns out that Google actually answered it at one point, here.

For those too lazy to open a new page, and scroll to the bottom (so much effort, I know), the Google spokes(wo)man stated that, ‘We have very high internal metrics our consumer products have to meet before coming out of beta.‘ Sweet zombie jesus, they must be some very, very high standards. All told, 4 years of beta for a product that they could update at any time?

That said, maybe its  best not to question everyone’s favourite benevolent overlords. They might hear you, with their camera vans regularly patrolling every major city and town in the world.

…that didn’t seem as terrifying before I thought about it.