How to use Twine/Tweecode Variables and Macros from Custom Macro

This tutorial is aimed at people wanting to use JavaScript in their Twine stories. This is advanced topic and is not necessary for writing most stories. Twine's ease in integrating JavaScript was a key factor when I was evaluating interaction fiction systems. Please read the tutorial on creating a custom macro in Twine first.

Twine/Tweecode has the ability to use macros and variables. In the Responsive, Sugarcane and Jonah StoryFormats macros and variables are stored in a place where they are accessible by custom macros for both reading and writing.

All custom macros are stored in a global object called "macros". They can be referred to by name. The actual macro code is in the "handler" property.

macros["custommacro"].handler(place, macroName, params, parser);
macros["display"].handler(place, "display", [ "SomePassage" ], parser);

In most cases it is sufficient to pass the place and parser arguments given to your custom macro into the macro you are calling.

Now, onto Tweecode variables. In tweecode variables are prefixed with a dollar sign so that the parser knows to lookup the variablename.

<<set $variablename = 1>><<print $variablename>>
<<if $variablename eq 1>>Success<<endif>>

Tweecode stores variables in the JavaScript object: state.history[0].variables. They are stored without the $ dollar sign "sigil".

state.history[0].variables["customvariables"] = 1;
if(state.history[0].variables["customvariables"] == 1) { 

Knowing how to reuse Twine's macros and working with variables set in Tweecode from within JavaScript custom macros (and vice versa) opens many possibilities.


How to use Parameters and Variables in Custom Twine Macros

The last article looked at basic macros in Twine. We'll expand on that article by looking at parameters and using an internal variable. First the code example:

try {
  version.extensions['recallMacro'] = { major:1, minor:0, revision:0 };
  macros['recall'] = {
    handler: function(place, macroName, params, parser) {
      if(params.length > 0) {
        this.m = params[0];
      new Wikifier(place, this.m);
    init: function() {
      this.m = "A blank slate";
    m: null,
} catch(e) {
  throwError(place,"recall Setup Error: "+e.message); 

Let's go through the code a piece at a time (not necessarily in written order).

try {
  version.extensions['recallMacro'] = { major:1, minor:0, revision:0 };
  macros['recall'] = {
} catch(e) {
  throwError(place,"recall Setup Error: "+e.message); 

This is boilerplate code that is explained in the last article.

    init: function() {
      this.m = "A blank slate";
    m: null,

This code declares a variable as part of the macro called "m". Throughout the macro we refer to this variable using this.m. The variable is declared within the macro to avoid polluting the global namespace and to avoid variable name clashes there. Note that m is declared with an initial value of null and the value of m is set within the init() method. This practice makes the macro work better if the story is restarted without refreshing the page.

    handler: function(place, macroName, params, parser) {
      if(params.length > 0) {
        this.m = params[0];
      new Wikifier(place, this.m);

This code checks the length of the params array. If there is something in the params array then the first parameter is saved into this.m. In all cases the contents of this.m are printed.

Once you have added this macro to your story then try adding the following tweecode to a passage in your story:

Initial state: <<recall>>
Store John: <<recall John>>
Store Ben: <<recall Ben>>
What is stored?: <<recall>>

Using parameters and variables in Twine macros is a great way to increase the power of the macro. Storing variables as properties inside the macro object avoids any name clashes with other macros.

How to Create Custom Macros in Twine

This post is a technical article for the Twine hypertext authoring system. I will assume a passing knowledge of Twine/Tweecode and an intermediate knowledge of Javascript. This tutorial applies to version 1.3.5 of Twine - and even further still I assume the latest betas.

There is a bug in the current v1.3.5 Sugarcane and Jonah story formats; custom macros will not work during the display of the "Start" passage. The Responsive story format does not have this problem.

I'll start with a simple macro example then explain it line by line. Put this code into it's own passage. The passage title can be anything. Give the passage the tag "script"

try {
  version.extensions['macrodemoMacro'] = { 
    major:1, minor:0, revision:0 
  macros['macrodemo'] = {
    handler: function(place, macroName, params, parser) {
      new Wikifier(place, "Hello World!");
    init: function() { },
} catch(e) {
  throwError(place,"macrodemo Setup Error: "+e.message); 

Let's go through the code a piece at a time (not necessarily in written order).

try {
} catch(e) {
  throwError(place,"macrodemo Setup Error: "+e.message); 

This code sets up basic Javascript exception handling to let you know via a popup dialog when there is a problem in the macro code. Custom macros are inserted into the page at runtime so they can be difficult to debug. This exception handler makes things a bit easier. Technically this is optional, but trust me, it's worth adding. Just change the "macrodemo" text to the name of your macro so you can tell multiple custom macros apart.

  version.extensions['macrodemoMacro'] = { 
    major:1, minor:0, revision:0 

This statement registers the macro with an extensions array. This is totally optional and appears to currently have no effect. If you are making a macro for re-use in many stories then it's a good idea to store version information so why not do it here. Maybe one day it'll be useful. I've taken the macro name and appended "Macro" just to be consistent with the way Twine's in built macros are registered.

  macros['macrodemo'] = {

This creates the javascript object that holds the custom macro. The macro name in this case is "macrodemo" and you should change this to suit. The title of a macro should not contain spaces, double quotes or any characters that might confuse twine. There are two required functions and you can also add any other macro related variables inside the object.

    init: function() { },

This function is called when Twine is setting up the macro object when the story is started. This is where you should also initialise any variables because init() is called whenever the story is restarted. In many cases an empty function (as above) works just fine. There is no guarantee which order init() functions will be called, except that generally the inbuilt macros have their init() method called first.

    handler: function(place, macroName, params, parser) {
      new Wikifier(place, "Hello World!");

This is the actual code that is executed when your macro is called. A macro is passed four parameters, the most important of which are "place" (an HTMLContainer where text is currently being output to) and "params" (any parameters passed to the macro). Parameters are split into an array on space characters except within "double quotes". The macroName parameter is self-explanatory. The parser gives a reference to the current Tiddlywiki parser object - which is useful only for some advanced cases; e.g. if you were writing a macro that has a corresponding end macro: see the inbuilt if, else and endif macros or my while loop macro for examples.

The example code here shows how to do simple text output which is added in place of the macro call. Most Twine macros will want to do something similar to this.

Once the macro is in place then somewhere in your Twine story go:

Custom macro: <<macrodemo>> 

Rebuild the story and you should see Hello World! Congratulations you have written your first macro.

BUG: Backslash characters do not encode / decode correctly from the passage store. Use a workaround such as: String.fromCharCode(92).

TIP: Since the latest betas support multiple source files via StoryIncludes, I like to put macros into separate text (.twee) files just to make organisation and reuse easier.

Macros are a powerful way of adding functionality to your Twine stories. The full power of Javascript is available to you. If you make a good macro then please share.


Arduino LCD: Defuse

This games is about finding a bomb in a 100 x 100 x 100 cube. That's 1 million possibilities. To help out the player is given a mysterious bomb detector. There is 200 seconds (20 turns) to find the bomb. Each turn the player gives coordinates and the scanner returns a new reading.

Code: http://eturnerx.com/files/arduino/014_defuse_eturnerx_arduino_lcd.html

This time I made some quite big changes to the game. I cut some of the flavour text for illegal moves. For example, if you input numbers too large or small then you'd accidentally step outside the building and fall to your death. Also, the original game uses a fixed algorithm for building the scanner reading. Once you know this algorithm them you can theoretically win in one turn. Instead I made the scanner algorithm change every game. This gives much more replay than the original. It is still very easy to win though and 20 turns is perhaps too many. In my first attempt I won in 8 turns and that included making many errors and inefficient plays.

HINT1: The scanner does not give a pythagorean distance, but it is a strength reading.

HINT2: Get each digit of the scanner to a 9

SPOILER: Each scanner digit is the nine minus the difference between the bomb's position and the scanned position for that digit. The order of the digits is intentionally mixed up. Work digit by digit. Go with "9 minus the most common digit" as your first guess. Once you've located the coordinate digit on the scanner then you can test for value at the same time you locate the next coordinate digit.

Checkout the other games I have converted.


Arduino LCD: Game Conversion Recap

I have completed converting seven old text based games for the Freetronics 16x2 LCD Arduino Shield. I choose this era of gaming because it was perfect for the LCD Shield and to pay my dues. As a child, I learnt to program by copying these types of games from books and modifying them. It's almost duty to give a new life to these things that helped form me. I got better and faster at making such conversions and learned some good lessons along the way.

A main loop controlled by a switch() statement is a good way to organise a program. They allow extensibility and focus. I already knew this from my other programming experience and it was no different here.

Arduino's have limited heap memory of about 1Kb. You get no warning that the heap is exhausted, instead variables end up with weird values and you won't know why. Text strings use up heap memory too. In a few games I needed to used PROGMEM to get around this limitation.

Showing a routine message on a delay is better than making the user click through them. The earlier games require more clicking and the later games just felt better because they were less "clicky". Of course non-routine messages should require a click.

It's easy to flash the backlight, but it's not always a good idea because it can throw a user's comprehension of text out. Save it for the really important stuff only.

Keep videos short. Everybody loves videos and code, but they won't watch an epic. In later conversions I aimed for a minute and treated it more like a teaser than a play through. Youtube analytics shows this approach seems to be paying off when it comes to audience retention. My skills with Windows Live Moviemaker also increased; it's perfectly fine for this type of work and much cheaper than the pro-packages I have at my workplace.

I think that today's gamers expect more of a challenge. Or maybe that's because gamers are much older than the 1970s. I made Hunt the Wumpus, Acey Deucey, Mugwump and Defuse more difficult than the originals while trying to preserve the original spirit of the game.

It did take some thinking to fit UI onto the 16x2 char screens. Many games had a lot of text and status to show and it became a matter of focusing on the key variables that drive the game. Text lines often needed rewording and this was done to preserve as much flavour as possible. A few of the games (Wumpus, Highnoon, Camel)use a side scrolling menu.

The list of games are:

I enjoyed doing this series but it's now time to move onto other Arduino related projects. I may continue to do old game conversions into HTML using Twine as a break from my other priorities. Keep watching the Games Conversions label on my blog. Thanks for watching.


Design Demons: The Pragmatist Demon

An earlier post gave an overview of the design demons: Creative, Critic and Pragmatist. This post takes a closer look at the Pragmatist Demon. A designer should develop ability in each of the each of their demons so that the overall team is stronger.

The Pragmatist demon ensures that things gets done. The Pragmatist can be overly economical and un-ambitious in the quest to get things completed. When the Critic Demon is insisting on quality and the Creative demon is insisting on novelty, an overly strong pragmatist can overrule these to complete a solution that is too watered down. The Critic demon is most useful at the beginning of a project (feasibility) and at near the end (deadline crunch). The Pragmatist demon will stifle good ideas from the Creative demon if the Pragmatist is too loud during the concepting phase. The Pragmatist demon's favourite word is: trade-off.

The problem with trade-offs is that the value of a project can be deleteriously compromised if the novelty or quality is watered down.

The underdeveloped Pragmatist demon is unable to set and meet deadlines. The underdeveloped Pragmatist will allow the Creative demon too long to discover the perfect idea and allow the Critic demon to continually nitpick at problems in the design. A person with a weak Pragmatist demon may be full of good ideas and even have some projects started - but little is actually finished.

The strength of the Pragmatist demon can be improved through practice. Set clear constraints (budget, materials, deadlines) for projects and stick to them. Completing work is the life-force of this demon. Any study into process, workflow and project management will permanently strengthen this demon. Writing proposals and problem solving in constrained situations are the Pragmatic demon's gym workout.

The noisy pragmatist will unnecessarily hurry the Creative and Critic demons into doing substandard work. The noisy Pragmatist will discourage the Creative demon by saying the ideas are impractical. By prematurely constraining the Creative demons then concepts might be unnecessary weak. The noisy Pragmatist might overrule the quality decisions of the Critic and this could ruin the polish of the project. However, a noisy pragmatist that gets work out the door is probably the least worst noisy demon because getting stuff done matters most.

A noisy Pragmatist demon can be taught to speak only in turn. Force yourself to use a standard process for projects and do not deviate from the standard process without permission from a mentor. Allow the Creative and Critic demons space to speak before applying "practical" constraints.

A weak Pragmatist demon is best trained through the successful completion of many projects. One way to do this by setting constrained projects (time, budget, other) that must have an output. This will improve the Pragmatist's ability to estimate feasibility going into a project and the constraints will force the Pragmatist to balance priorities in the later stages.

A strong Pragmatist demon is important for a designer to select good projects and complete them on time and in budget. Working to improve the Critic demon will give long term benefit to the designer because completed projects are better than incomplete projects.


Arduino LCD: Nicomachus

This is a game that is a simple "guess your number" game based on an algorithm published in 90AD. Think of a number between 1 and 100 then answer three questions about it. The original BASIC game is by David Ahl.

Code: http://eturnerx.com/files/arduino/013_nicomachus_eturnerx_arduino_lcd.html

This was a pretty quick conversion. I cut much of the flavour text - including a taunt to recheck your arithmetic if you disagreed with Nicomachus' answer. Having said that, I was surprised at how often people would get a remainder wrong during testing. Maybe the taunt should've stayed. If you'd like to play a more faithful conversion then try my online playable version of Nicomachus.

Checkout the other games I have converted.


Arduino LCD: Camel

This is a game that is kinda like a cross between Oregon Trail and Highnoon (arduino, html). Make your way 200 hundred miles across a desert without dying in deliciously anachronistic ways.

Code: http://eturnerx.com/files/arduino/012_camel_eturnerx_arduino_lcd.html

I had to alter the text to suit the smaller screen, but did try to preserve the tone and flavour. There are some minor differences to the original game. I used the PROGMEM technique used in my Highnoon conversion to fit all the text into memory. See my Camel Conversion for Twine writeup for more details on the game logic changes and information about optimal strategy.

Checkout the other games I have converted
I have also converted an online playable version of Camel.


How to Simulate for, while or do loops in Twine

UPDATE:I have written a proper <<while>> macro. The techniques below will still work but you'll probably find the new macro much easier.

Tweecode (used by Twine) does not have any notion of a loop but they can be simulated with <<if>>, <<set>> and <<display>> macros. The trick is a computer science trick called recursion where a piece of code repeatedly calls itself. So just think of passages as pieces of tweecode (functions) and the <<display>> macro as the "Call Function" command.

An example while loop

You knock at the door; <<display "WhileLoopDemo">>
The door is answered by a sleepy giant.

<<if Math.floor(Math.random()*100) lt 70>>
knock <<display "WhileLoopDemo">>

The Math.floor(Math.random()*100) code selects a random number from 0 to 99. See how the loop passage keeps on calling itself, until finally there will be a random number 70 or greater and the passage will exit back to where it left off in the start passage.
Demo, Code: .tws | .twee

An example for loop

Example for loop demo. <<set $i = 0>><<display "ForLoopDemo">>

<<if $i lte 5>>
<<print $i>>... <<set $i = $i + 1>><<display "ForLoopDemo">>

The for loop example is slightly more complex because it must setup a counting variable and increment this on every iteration of the loop.
Demo, Code: .tws | .twee

Note: The double-colon :: denotes the start of a new passage. The rest of the line following the double-colon, up to an option opening square bracket [, is the passage title. This text following the start of passage (until the passage start) is a the body of the passage.

It is possible to create custom macros that would make loops in tweecode much easier; I might even do this one day. However, if your Interactive Fiction work is relying heavily on tons of loops then it is probably time to look at implementing that functionality in JavaScript directly for efficiency reasons.

The Nicomachus includes a demonstration of a loop in a fairly simple piece of code. If you're a JavaScript wiz then you might be interested in how to create your own macros. Let me know in the comments if there are other Twine related topics you'd like covered.


Joust Conversion for Twine

Here is a conversion of Joust. This is another one of those games I copied from source in a book to learn how to program as a kid. Bringing these old games back to life is like paying my dues.

This is not a difficult game - you will play through it in just a few minutes. There is also not too much in the way of flavour text compared to other games. I'd rate it as about the same as Highnoon in terms of depth but the game play feels much less varied.

SPOILER: Once you work out a winning attack / defense combo then keep repeating it and let luck do the rest.

The game logic is entirely implemented in Twine/twee code. This could've been much simplified by using custom javascript macros to handle the logic branching or even by coding a "switch...case" macro system for twine to substitute for "ON X GOTO line, line ..." code from the original. I used if, else, endif blocks and despite being a bit complicated and verbose they did handle the task well enough.

Debugging something with such tricky logic wasn't easy but I used a couple of tricks. These might be useful to other Twine/twee code authors too.

TIP1: Debug nested if, else, endif blocks by copying into another text editor and indenting like a regular programming language.
Complex nesting of if, else, endif blocks can be annoying to debug. The are formatted in non-obvious ways to suit the needs of end display, not the programming. So, just for the purposes of debugging, try indenting it as if it is a programming language.

TIP2: Debug nested <<display>> chains with html comments. e.g. <html><!-- PassageNameX --></html>
Chasing around through multiple display macros gets hard. Add html comments to insert invisible stuff into the code so that you can inspect the page and track where the display macros are leading. It helps narrow down where the bugs are really quickly.

Checkout the other games I have converted


Camel Conversion for Twine

Here is a conversion of Camel. I can vaguely remember coding and playing this game as a kid in the early '80s. If it left that kind of impression then it must've been a fun game so I decided to give this a shot for a Twine conversion. It is similar in many ways to Highnoon in that there is an underlying game system represented by some quirky text.

The game play can be frustrating! Oases appear frequently enough that water is almost never a problem (just don't forget to drink). The biggest problem is the pygmies. They have a 10% speed advantage on your moderate speed, but running your camel at full speed burns it out three times faster.

SPOLIER: The mathematically optimal strategy is to go full speed twice, moderate speed once then rest. Drink when warned (actually the turn after). If you are captured then wait for the ransom. Even with an optimal strategy a win is not assured. In this game the player loses more often than not. Prepare for frustration.

I made extensive use of the custom macro <<randomp>> that I made for another project. This simplified a lot of the handling where things were triggered by random events.

I intentionally left as much logic in place as it is in the BASIC code with a couple of small changes. The capture submenu display the request for sub-command before the menu and the "Miles travelled" text appears more than in the original. There was also something where asking for a status report would fall through to also taking a drink. I assumed that this was a bug and changed status report to not force a drink at the same time.

From the viewpoint of 2012 the text could appear offensive. I prefer to think of it is ironically anachronistic because there are many obviously mismatched facts and intentional mispellings. Many of the other books edited by David Ahl do contain some quite detailed information about the historical context of the games so I do not assume the authors of this game were naively flavouring the game they way they did.

Checkout the other games I have converted


Nicomachus Conversion for Twine

Here is a conversion of Nicomachus for Twine. This was a much simpler program than Highnoon so I further restricted myself to making all program logic happen in Twine's tweecode.

Twine surprised me with its arithmetic handling. Up until now I had been ducking into Javascript for all but the simplest of expressions. Twine was easily able to handle an arithmetic statement with three sets of parentheses and about six terms.

Twine does lack a loop function (like a while). I was able to simulate this with an if, else, endif macro that keep displaying another passage (itself) until the condition expired. You can check the code for how I implemented this. The technique is known in computer science as recursion.

The verdict; A fun quick conversion.

Checkout the other games I have converted


Arduino LCD: Mugwump

This is an old game I never recall playing but it was one of the inspirations for Hunt the Wumpus and it has some elements of a game I was thinking of writing. There are four mugwumps hiding at random locations in a 10x10 grid. The user supplied an x & y coordinate to scan and is told if they have located a mugwump. The user is also told the distance to any mugwumps not yet found. The game ends after all mugwumps are found or then turns.

Code: http://eturnerx.com/files/arduino/011_mugwump_eturnerx_arduino_lcd.html

Mine differs from the original in a few minor respects; distances are rounded to the nearest integer in order to fit the display. Distances over 9 are simply not given. These small changes only make the game slightly tougher and most games can be completed in seven turns.

This looked like an easy game to convert; and it certainly is much less complex than many others. The kicker is that much of the supporting historical information is not in place and the game is kinda tough. I spent more time writing a wikipedia article and creating an HTML5 based game cheater *cough* helper than doing the Arduino code.

Checkout the other games I have converted


Arduino LCD: Acey Deucey

There's something satisfying the challenge of fitting games into the limits of a 16x2 character display. This week I did a version of a card game called Acey-Deucey. The basic rules of the game are: first the player antes into the pot. Then two cards are dealt. The player may then bet on whether or not a third card will be between the first two cards. All you need to do is outlast an Arduino-AI opponent.

Code: http://eturnerx.com/files/arduino/005_acey_deucey_eturnerx_arduino_lcd.html

I did make some small changes to the game as it is played live:

  1. Ace is always higher than King and never lower than 2
  2. Pairs do not result in an automatic penalty
  3. The ante increases every few turns

A player can pass by betting "0". A player's maximum bet is limited by the size of their stack and the amount still left in the pot. The AI will bet only when the spread (distance between the two cards) is seven or greater. The AI bets more with wider spreads but will bet only up to half its stack. This is not a bad default strategy.

Since this game is mathematically solveable for optimal long-term play I intentionally made the Arduino-AI a little stupid; the AI does not count cards. There is a single standard 52 deck (4 suits, 13 ranks) being tracked and you are told when the deck is reshuffled.

You can gain a big advantage by simple card counting. Counting 234|QKA versus 6789T should do better than chance. You gain even more of an edge by tracking ALL cards and counting the ratio of good vs bad cards; Just how poker players count "outs". If you're really nerdy you might even try Kelly betting. Hey, whatever you find fun :)

Checkout the other games I have converted


Highnoon Conversion for Twine

This week's creative project is a conversion of Highnoon for the Twine interactive fiction system. While I was converting/reimagining for Arduino I had two thoughts. The first was that I'd like to do a more faithful conversion with the original dialogue and secondly that such a conversion would be a way to demonstrate the power of Twine.

So, you know the game; You're in a showdown with Black Bart. You each have four shells and are 100 paces apart. In this original version there are more win/loss conditions than straight death.

Twine allows quite a lot of expressiveness and flexibility when writing interactive fiction. It also outputs the results to a single .html file that require no supporting libraries or other files. If you are interested in the basics of Twine then I'd suggest looking at this tutorial.

The conversion to Twine was fairly straightforward. I used the Jonah Story Format because it places passages one after the other without clearing the screen like Sugarcane does. I made a few tweaks to the inbuilt functions; the first to totally suppress the output of passage titles and the second to totally deactivate old choices. This was not difficult; it was more a matter of removing the bits of code from existing functions that I did not need.

I also based passage names around the line numbers in the original code. This eased moving from the GOTO style of the original code to the structured coding style of Twine.

The verdict; a very playable old-style game.

Checkout the other games I have converted


Arduino LCD: Highnoon Conversion

This week is a conversion (strictly a re-imagining) of a game from 1970 called High Noon. Try to kill Bart in a shoot out! Your have a range of options that can be accessed using the left, right and select buttons on the Freetronics 16x2 LCD shield. After your turn Bart has his turn. The video shows only a few of the things that happen in the game.

Code: http://eturnerx.com/files/arduino/004_high_noon_eturnerx_arduino_lcd.html

The AI is probably tougher than the original. The text prompts were shortened to fit the screen and a few new things added for flavour though the essential game is the same. A few edge cases (running away) were changed and the being shot in the back was also changed. Any action the fails, standing still or walking/running 0 paces results in a penalty making you easier to hit.

The implementation uses a state machine in the main loop in the same way that the Hunt the Wumpus conversion did. In addtion, the static string data grew too big for the working memory on the Arduino so I needed to use the PROGMEM trick and create a string table.

If you are interested in a more faithful, online playable version then check out my HTML conversion of Highnoon.

Checkout the other games I have converted


DPI & Compression Problems - demo PDF

Seasoned print designers know all about DPI, but it is difficult to convince design students unless they are shown an example as to what can go wrong. I made this sheet where the same image is shown at the same size except in 300dpi, 70dpi and 30dpi. I also included a badly compressed JPEG so that students will know what to look for.

The correct DPI to use will always depend on the printer that is being used so ask! If the DPI is too small then some blurring and pixellation will occur. This can be seen where the text is not clear and where there are square step blocks.

The poorly compressed JPEG shows how the textural detail in the wall and sky are flattened out and bruising artefacts appear where there is a change in contrast (e.g. around the text).

Having a poorly compressed JPEG and DPI that is too low is a double blow to the quality of the output image.

Feel free to share the document. Link: The DPI Problems PDF

maximum_display_size_in_inches = pixel_size divided by the DPI
   (there are 2.5cm in an inch. So, approximately 4 inches in 10cm)


WorkOut Poker Episode 3: HUD

Continuing on with first steps towards an ExerciseUI, this episode adds on a HUD to give stats that help decision making while playing.

The HUD shows VPIP / PFR & AGR / 3Bet stats. These are only basic but there was not much room for any more since the size of the numbers needed to be increased.

I had the dreaded problem where the Kinect would stop updating in FAAST. It turns out that the shortcut I was using to launch FAAST lost "Run in Administrator" mode and you should disconnect the Kinect power USB converter from the computer after a reboot. It was fiddly but once it was running it was rock solid.

Getting the HUD running was not trivial. It causes a huge load on the computer to run FAAST, PokerStars and Holdem Manager 2 at the same time (while I was recording). The FAAST display would sputter and gestures would not be recognised. The solution was to use ImDisk and move the HEM2 database into RAM. I also made a different ImDisk RAMdisk and recorded the video straight to that. Time to buy an SSD.

The HUD stats were useful. There were not many hands on the other players but even still some information was better than none.

Episode List
Episode One: Basic Functionality
Episode Two: Bet Sizing
Episode Three: HUD


A Question of Professional Ethics and Friends

Professionalism and ethics questions between two parties are fairly cut and dried. However, things can very quickly get murky when muliple parties are involved. Justice asked me to advise on a situation.

Justice works for DesignStudio and they have a large client account BigClient. Recently BigClient employed an in-house designer called Riley. Coincidentally Justice and Riley happen to be friends who both move in the same active social circles. One day Justice overhears the DesignStudio execs wondering why they are now getting less work out of BigClient than before. They are discussing the latest design outputs of BigClient and wondering where they are coming from. Justice knows from social conversation with Riley that Riley turned out better than BigClient expected so BigClient is giving more work to Riley instead of taking it to DesignStudio.

Should Justice tell the DesignStudio bosses or not? I would say no.

Telling DesignStudio bosses might win some brownie points and demonstrate loyalty towards DesignStudio. But Riley probably did not intend the information about extra work to go any further than the social group. If DesignStudio bosses acted on this information and spoke with BigClient then that might make things difficult between BigClient and Riley.

One could think that Riley should be more careful with what they say but add in a couple of drinks and people toasting each other's accomplishments for the week and it's easy to let things slip. Telling the DesignStudio bosses is acting in the employer's best interests but loyalty between friends should count too.

There needs to be some leeway and forgiveness between friends. Firstly it would be a sad world where friends could not privately discuss some aspects of their work out of fear of being taken advantage of. People need safe places to vent their excess emotions; happy or sad. Secondly this time Riley let slip some information, next time it could be Justice innocently doing the same. Friendship is not about one-foot-wrong and you get taken advantage of. A good friendship will outlast a job.

For these reasons, if I was Justice, I would not tell my bosses about Riley. DesignStudio's Account Managers will probably be told if they contact BigClient directly and ask.

(Scenario based on a true story, real names not used)


“Should I study graphic design?” Jobs, Career, Money

Having a suitable personality is only one part of the decision to study design. In these economic times (Economic Crisis during 2012) students thinking going to design school need more certainty that there are jobs, careers and money after graduation.

There are jobs in graphic design in the skills NZ employers want. These are; advanced web, mobile, and cross-media design. There are some jobs in other media and the competition for these jobs is fierce.

In 2012 Web design is no longer a specialist role – it is now part of the overall package expected of an entry level designer. Many first jobs expect a cross-media designer who can apply a consistent visual look across many mediums. Specialist web design roles require advanced HTML/CSS with at least one of the following; mobile design, front-end development (such a jQuery), serverside skills or CMS skinning.

The NZ Government Careers advice section now says:

Number of design graduates increasing, which has created more competition for jobs. Because of the high numbers of design graduates, competition for most entry-level design jobs is high. Employers often prefer to hire people who have specialist knowledge and/or experience with design programs. People wanting to enter design jobs may have work on a short-term or freelance basis, or volunteer their time, before they can get full-time work.
Why is website gloomy? Their definition of graphic design is narrow and outdated. Print is seen as key and web only gets the barest mention. This does not reflect the reality of the job market.

Now entry level jobs pay less, expect more and require new hires to be immediately profitable. There is no time or patience to train because employers can be choosy. A new entrant designer might earn just over minimum wage until they have proven themselves. Employers now use word of mouth to fill entry-level positions because they do not want to deal with the hundreds of unsuitable applicants who apply to any and every design job ad. How does this affect the decision where to study design?

Does the design school have specific training in the skills, mediums and technology that are currently employing. One red-flag phrase you might hear is: “Technology changes but good design does not”. This view ignores the rising role of the aesthetics of time and interaction and neglects how a viewer's relationship with a medium affects communication. Each medium has its own peculiarities that require specific skill masteries. Furthermore, that red-flag line would be unaffected if the students were trained in more employable mediums. It is simply no longer enough to hope an overall strong aesthetic sense will be enough without employable media skills. Consider also how the school is working with future technology. Graphic design and technology have always gone hand in hand and big changes are coming.

A good design school will have a strong visual culture. Most will claim they do but check the work by attending their graduate exhibitions. Look at the typography. Look for a variety of work in different styles. Look for consistency of design across mediums. The work should be aesthetically rounded and conceptually pushing boundaries.

How successful are graduates of the school jobs in design? While finding you a job is not the design school's role, the percentages of graduates transitioning from study to jobs in graphic design within six months of graduation can be telling. Beware of the super-star stories; “Famous Person studied here”, "we have graduates working for Famous Company". A few super-stars is not a good indicator of an excellent course because some people will just succeed despite their education. Instead look at what happens to the average graduate. How are the B students doing?

There are far easier ways to make a living than graphic design but it is a very rewarding field full of change and challenge.

Read more articles about graphic design careers.


WorkOut Poker Episode 2: Bet Sizing

Continuing on with first steps towards an ExerciseUI, this episode makes some improvements to existing gestures and adds gestures for bet sizing.

Some of the existing gestures needed a bit of fine tuning so that they would trigger more reliably and not trigger at unwanted times. The gesture for fold changed into three raises of the knees in either a left-right-left or right-left-right pattern. This is to allow some variation in the marching step used to fold. The previous left-right pattern just didn't quite feel right when playing.

In the last episode the Kinect would stop updating in FAAST. This was edited out of the video, but having to restart FAAST every seven or eight hands was tiresome. To anybody else having this problem, the answer is to run FAAST in administrator mode and to plug the Kinect into a USB that connects directly to the motherboard. Usually these will be on the back of the computer. It seems that the Kinect does not play nicely when going through intermediary USB hubs.

There are four betsizing actions for 33%, 50%, 75% and 100% of the pot. It was ticky getting the 50% and 75% actions to distinguish from each other. Doing cross hand above the shoulders move would trigger both the 50% and 75% pot size bets. I did manage to get something workable, though some care must be taken such as; squarely facing the Kinect camera, pausing after raising hands and pausing after hands are crossed. I hope to make this even more robust in future.

The increased stability meant I got in a 50min poker session. I ended this voluntarily - the software was rock solid this time. The activity level is still very low but it does beat sitting around. The next episode will experiment with multi-tabling to see if that improves the activity level to something more resembling a workout.

Episode List
Episode One: Basic Functionality
Episode Two: Bet Sizing
Episode Three: HUD


WorkOut Poker Episode 1: Basic Functionality

In a previous article "The ExerciseUI" I explored the idea that exercise should be something integrated into our daily workload. Technology is becoming cheaper and easier to use. Here are some baby steps.

I happen to really like Poker, so I made some custom gestures in the FAAST Kinect software for PokerStars. The three man gestures are: fold, check/call and bet.

Playing one table of Zoom poker creates a low tempo of activity. The most common poker action is folding so this is linked to the most common exercise: walking on the spot. The other actions require big hand movements with energy levels that correspond to the severity of the action.

This is early days yet; there is much more to do. While the activity levels are low, making this control more than one table will improve the tempo considerably. I also hope to estimate loads placed on different muscle groups to vary the gestures for actions to meet exercise goals. In this way we can work AND exercise.

Episode List
Episode One: Basic Functionality
Episode Two: Bet Sizing
Episode Three: HUD


PhD Progress Report to August 2012

It's been awhile since I have posted on this topic so here's what I've been doing with my PhD. I have since made several improvement to the semantic web browser described in my last PhD update and have been experimenting with techniques to reduce information overload.

Reminder: My research tries to reduce information overload when displaying data where the structure of that data is not known ahead of time.

There is a good body of research in linking determining how related text strings are by meaning (the linguistics meaning of semantics). The problem for me is that the speed is not fast enough for building displays at runtime in a web-browser. I instead went with lexical methods that use naïve rules to just compare characters in a label. There are well establish algorithms for this; Dice, Levenshtein to name a two. My implementation of Dice in Javascript is now in the WikiBook project called Algorithm Implementation

What is not immediately clear is how these algorithms should determine similarity when two triplets with labels resolved are compared. Assuming that the subject is equal/equivalent then just how does x->firstname:John relate to x-->surname:Xeedown? My most recent chapter took Dice and Levenshtein string similarity algorithms and then compared an averaging of the predicate and object similarities versus simply taking the higher of the predicate or object similarities. I conducted a study with twenty human participants and have analysed the data. The data is indicating that a naïve lexical algorithm can give acceptable (i.e. “usefully better than random”) results in line with what human participants would say about the same triplet pairs. This is encouraging.

In that study I also tested any algorithm for determining if triplets were redundant. This is used to subsume (not display) triplets when it is deemed that other triplets contain equivalent information. I already had built such an algorithm using intuition and voodoo – and the testing on humans indicates that the algorithm is usefully better than random at matching what humans also rank as redundant data. This is also encouraging.

Using the redundancy algorithms I now manage to avoid displaying quite a number of triplets. In some cases, using data from dbpedia, about 55% of triplets are simply not displayed because they contain redundant information or are turned into lists.

I also used the similarity algorithms (actually the inverse) as the distance metric in hierarchical clustering of triplets. The cluster hierarchy is then flattened which results in groups of related triplets. While not giving perfect results, for a “first naïve attempt” at grouping triplets the results appear to be better than random – though I have not tested this.

I am currently writing up research results and learning tons about statistics as I go. It is particularly interesting to read about the debates in statistics for multi-rater agreement in Likert scales. After trying to come to grips with so much math I eventually went with the old method of just just looking at the shape of the of raters histogram.

Going forward from here is the next chapter. This one leaps off from the “first attempt” approaches described above and attempts to find algorithms that learn the user's preferences for ordering, grouping and redundancy. Recommender systems research has some particularly interesting avenues to explore here. I currently invisage a conversational User Interface that allows the user to express their data display preferences (order, grouping, redundancy etc) via direct manipulation.

The performance of any algorithms found and adjusted will then be tested against human raters. Once that study is complete I then theoretically switch into “write up” mode for the thesis but will need the ocassional coding distraction of actually implementing the results of the studies into Eme. Things are looking promising.

Arduino LCD: Hunt the Wumpus Conversion

This week I recreated an old text game that I remember as a kid in the '80s: Hunt the Wumpus. The game is apparently from 1971. Basically you wander around a map trying not to fall into a pit trap or get eaten by the wumpus. You win by shooting the wumpus - but don't shoot yourself!

Code: http://eturnerx.com/files/arduino/003_wumpus_hunt_eturnerx_arduino_lcd.html

The map is a squashed Dodecahedron. Arranged into three rings. The inner and outer rings have five rooms while the ring between them has ten rooms. Every room links to exactly three others; back and forth on the current ring and another to change the ring. While the interconnections in the map never change, my version of the game scrambles the room names whenever a new map is generated (on power up or when selected at game over). A new map also randomises the starting positions of the player, the pit, the bats and the wumpus.

Shots can travel up to five rooms, but can only travel into rooms that you have already visited and or have been one room away from. It is possible to shoot yourself.

The implementation uses a state machine in the main loop. It's a pretty big one but things don't seem to get out of hand. That's why I love the state machine approach; it allows the programmer to think of the overall structure but then just concentrate on the single task they were working on. For a much simpler state machine check out the previous video.

Checkout the other games I have converted


Arduino LCD & State Machine Demo: Life & Poison counters

Continuing on from the last video; adding a hidden Poison counter is a good chance to build a simple switch()...case state machine.

The code: http://eturnerx.com/files/arduino/002_mtg_lifepoisoncounter_eturnerx_arduino_lcd.html
Last video: http://youtu.be/t6Y_GCoSUt4

A more comprehensive example of a state machine is in the next video; A Hunt the Wumpus game conversion.


Design Demons: The Critic Demon

An earlier post gave an overview of the design demons: Creative, Critic and Pragmatist. This post takes a closer look at the Critic Demon. A designer should also seek to develop ability in each of the each of their demons so that the overall team is stronger.

The Critic Demon is more strongly related with the left side of the brain. It is the analytic thinker that evaluates and judges the ideas flowing from the Creative demon. The Critic demon can be overly picky and will have impossibly high standards. When the Critic demon is rejecting all ideas then perhaps trade-offs should be made in the design. The Critic demon is most suited to the development and refinement stages of the design process. The Critic demon will cripple the Creative demon if the Critic demon has influence during the Concepting phases. The Critic demon's favourite word is: Perfection.

The problem with perfection is that there is never a single solution and design is often a trade off between many competing factors.

The underdeveloped Critic demon will be unable to properly evaluate the ideas of the Creative demon. The underdeveloped Critic will allow poorly resolved and aesthetically unpolished work to progress. A person with a weak critic demon and good execution skills will make a high volume of rough work. They might be successful through volume alone.

The strength of the Critic demon can be improved through education, reflection and critique (see the critique section). Critical analysis and logical thought is the life-force of this demon. Any study into understanding of design theory, history and case studies will permanently strengthen this demon. The act of reviewing and thinking about design work - especially honest criticism confirmed by trusted peers - is the Critic demon's gym workout.

The noisy Critic will distract the Creative demon and may war with the Pragmatist demon during the later stages of the project. The Critic will discourage the Creative demon by saying how each idea of stupid and this will stop the Creative demon from leaping from idea to idea. The pragmatist will want to finish a project but the Critic demon will insist that it is completed properly before it can be released - even if this means expending more resources than allowed for the project. This can delay the delivery of a project.

A noisy Critic demon can be taught to speak only in turn. Use good conceptualizing procedures where the Creative is free to talk for a set period of time before the Critic can judge the ideas. Standard brainstorming technique is to simply record all ideas without judgment or editing for a set period of time and only then allow for the Critic to speak. Focusing on the resources allowed for a project (esp. the deadline) gives the Pragmatist demon enough power to overcome the Critic. A beginner design can delegate the critic function to a trusted and more experienced peer. This should eventually train the critic to influence at the most useful times.

A strong Critic demon is important for a designer to produce professionally polished works that are executed well. Working to improve the Critic demon will give long term benefit to the designer.


Design Demons: The Creative Demon

An earlier post gave an overview of the design demons: Creative, Critic and Pragmatist. This post takes a closer look at the Creative Demon.

Each of the demons has their own levels of ability and influence. Ability is the strength of the demon in their specialisation. Influence is how likely the designer is to listen to demon. Each demon‘s talents are better suited for different parts of the design process therefore a designer should train themselves to minimise the influence of each demon and instead judge when their advice is most appropriate. A designer should also seek to develop strength in each of the each of their demons so that the overall team is stronger.

The Creative Demon is strongly related with the right side of the brain. It is the lateral thinker that comes up with the original ideas. Many of the Creative demons ideas are impractical, but one should not discourage the Creative demon from making them. When somebody has Designer's Block then their Creative demon is tired and out of ideas (see the Creativity section for help). The Creative Demon gets enthusiasm and rewards from coming up with many cool ideas. This makes the Creative demon very useful during the concept stage of the design process but a distracting influence during the development and production stages. However, the Creative demon can be useful during problem solving that can happen during production. The Creative demon's favourite word is Freedom.

The underdeveloped creative demon can come up with only derivative ideas occupying a limited range. A person with a underdeveloped creative demon but with strong execution skills will be very good within a small number of visual styles. This person will follow tutorials on the internet on how to produce some effect in popular software.

The strength of the Creative demon can be improved through stimulation and exposure to many different ideas. Inspiration is the life-force of this demon and it must be constantly replenished. Viewing the design works of others, visual art, music, culture and new experiences all provide inspirational fuel. Increasing the visual knowlege of the designer makes their creative demon permanently stronger. Also the act of creation in itself - especially when creating with others - is the equivalent of sending the Creative demon to the gym.

The noisy creative demon will continue to distract the designer way past the time concepting is completed. A noisy creative demon will always interupt with a completely different approach while the designer is trying to develop and produce an already selected idea. This can pull the designer off track and if they are seduced by their Creative demon's voice then they will always come with something new instead of finishing what they have started. This can delay the execution and delivery of a project.

A noisy creative demon can be taught to speak only in turn. Until the Creative demon knows to only speak in turn or when something is very important, the designer should move deliberately through each stage of the design process. At the end of each stage the designer should force themselves to make a decision that is not reversible without a second opinion from a more experienced colleague/friend. This should eventually train the Creative dragon to be noisy and quiet at the right times.

A strong creative demon is important for a designer to produce works that go beyond the mundane and ordinary. Working to improve the Creative demon will give long term benefit to the designer.


PokerStars on an iPad (including HUD)

Some people are curious as to how I play PokerStars on the iPad - complete with Holdem Manager HUD and TableNinja. The answer is easy: remote desktop. I use this setup to play from around my home, any place with wifi, and even over 3G (tethered to my cheapo Android phone). Sure there's the brilliant PokerStars app, but that doesn't have ZOOM, HUD or TableNinja.

Specifically: I use the LogMeIn Ignition product. Install the free LogMeIn client on the desktop computer, grab the LogMeIn Ignition app from the app store, set up an account and you're good to go. And it only costs a few dollars total to do. You can probably use other free/cheap remote desktop products (e.g. VNC, RDP) but I like LogMeIn Ignition because I don't have to worry about firewalls and other complications because it just works.

This technique should work for any Poker site.

TIP: On the iPad, once you're running Igntion, use the settings to force the connection to use 1024x768 screen resolution. That's the iPad1/iPad2's native resolutions so you'll have less problems with things being too small. Ignition will reset the desktop computer to it's original resolution when it ends the remote desktop session.

TIP: TableNinja works brilliantly in this setup. No keyboard? fine it still does default bet-sizing for you.

TIP: TableNinja and a wireless keyboard is where it's at. Connect the iPad to the big TV (or a projector), sit back on the couch with a beer and it's game on!

Multitabling does work - but due to the low screen-res you'll want to do this in stacked mode.

Result: ZOOM poker - anytime anywhere. Oh yes we can :)

If you like this article then perhaps you'll also like WorkOut Poker where I use a Kinect to play poker by waving my arms around.


The “Temp” Designer

Many industries already use skilled pools of temporary workers. This allows employers to temporarily fill capacity or skill needs. There are many labourer pools that allow construction companies to have a more flexible workforce where they can scale capability where needed. New Zealand schools have shared pools of relief teachers. The IT industry contracts specialist workers into their customer companies. There is a business opportunity here for design studios.

The default answer for a flexible workforce in graphic design is to employ freelancers. But freelancers can be a risky hit and miss affair for companies who are less able to judge the abilities of freelancers. One solution could be for studios to provide contracted “temp” designers to their client companies. Instead of contracting by project the contract covers a temp in-house designer for set hours who works at the client premises. The designer remains an employee of the studio (not the client).

This enables a client to add capability or skills to an existing in-house design team or to have the advantages of an in-house designer with few of the downsides. The general advantages of in-house designers include; set budget, low overheads per project and quicker communication.

There are benefits for the clients that are unique to the temp. The first is that the studio provides a guarantee to the skill and ability level of the placement designer. This eliminates the risky hit and miss of hiring an in-house designer or engaging directly with freelancers. The temporary designer contract can also include some oversight; the designer is mentored by senior members of the studio. This gives experienced insight without much additional cost.

There are other benefits: the temp designer can be in the client placement part-time so that they are working alongside other designers some of the time. This will help in keeping their creative and technical skills sharp. The temp designer maintains access to advice from specialist colleagues. The studio also takes care of cover during holidays.

Where a client has an on-going need for graphic design work but cannot necessarily afford a fulltime designer then a temp designer can fill this need. Because the temp designer is probably a fulltime employee of their studio then the churn common with part-time employees is less of a risk.

Small design jobs can accumulate within a client organisation. Unfortunately the overheads in setting these up as projects under the usual studio-client relationship can be prohibitive relative to the size of the job. A temp in-house designer has much lower per-project overheads so can clear away these accumulated jobs quickly.

The temp designer is another service that a design studio can offer their clients. When used in the right situations then it can provide good value to the client and simplify the studio-client relationship for collections of small jobs. Temp designers can become another tool for the studio to keep their clients happy.


Scope Creep is your Friend

We all have those clients – the ones that have a huge idea but only a tiny budget. It is impossible to deliver on their grand vision but maybe you can help them with a first step. And then there is the “just had a cool idea” client who creates scope creep.

As design projects get larger with more deliverables and much more coding scope creep becomes a real issue. The default answer is to contract tightly so scope creep is prohibited. But without some scope creep the project risks becoming irrelevant to the client. The unhappy client then might look elsewhere for the next job.

Both these clients can be dealt with in much the same way. Project management techniques currently being explored in software development (Agile and Lean) have direct parallels to design projects. We can start with some fuzzy overall goals and then iterate towards them learning as we go. This means that what was once evil scope creep is now considered a vital part of thinking and learning about the needs of the project.

Some of the commercial designers I have spoken to recently have started doing something similar though the iteration was more driven by a sales need to generate more income from previous customers. The subtle shift in iterative design projects is to treat every customer as a relationship where you are both journeying together. Each small project is another step closer to the goal.

The sales script goes like this: Keep selling the customer on their enthusiasm for their big idea. Talk universe conquering stuff. Then get the client talking about a small first step. Make it something of real value but requiring little risk/effort by either side. Fit within the tiny budget.

Completing that first step project is like dating. Each party gets to see if things with the other will work out without having wasted too much energy. There is an implied expectation that further work will arise but client or designer are both free to depart at this point. That is the sales advantage of this approach – the client is already thinking about the next small job to do with your design company.

After that first step hold a "retrospective"/reflection both within the design studio and with the client. Were their processes that could be improved? What worked well? What could be improved? What did we learn from this project? What are the new ideas we have for the next small project? – see no longer evil scope creep but friendly extra business.

As small tasks are completed (and presumably you’ve been paid) momentum and energy begin to build around the project. Listen to the client and together agree on “next steps” that will bring value to their business.

For the free-lancer a few tasks will tell you if the client is worth building a relationship with. If the client has complex needs then consider offering to go on retainer so that they (and you) have greater control over the budget.

Working in small iterative projects with retrospection before quickly iterating helps to build stronger relationships and should result in projects that are more relevant. Treating scope creep as a positive thing will eliminate a source of negativity in the client-designer relationship. Scope creep is then your friend because it brings repeat business to you.


Responsive Web Design: Design Theory's Experimental Frontier

Some questions to ponder while reading:

  • How does our understanding of grids change if the page size is no longer fixed?
  • How does our understanding of typographic layout change if column sizes are no longer fixed?
  • How does our understanding of visual hierarchy change if layouts are no longer fixed?

Important advances in simplifying the understanding of aesthetic formalism have often come about by quantifying design in mathematical terms. From the Greek golden section, to Müller-Brockmann's grids, the photographer's rule of thirds, the typographic scale, W3C colour contrast algorithms and Donald Knuth's work in computer typesetting - these all distil aesthetic ideas into formulas.

Traditionally the output mediums were of limited fixed sizes and so a sensible designer could redesign for a different size without much needed to quantify layout in response to weird output sizes. A few general rules of thumb and a good sense of aesthetics was all that was necessary.

Things have changed; Websites are now displayed on a wide variety of devices with different screen sizes and proportions. It used to be that a designer would simply ignore anything but desktop or design a second site for mobile. For over fifteen years web designers have been able to largely ignore increasing desktop screen-resolution by fixing their designs at a certain size within the browser window - effectively ignoring the live resizing of browser windows. This meant no difficult decisions regarding text-line lengths and image sizes relative to column sizes because this could all be fixed at design time. But as the number of devices increase (and thus variety of screen size) many web designers are realising that they should design responsively.

The gateway drug for responsive web design is the flexible grid. Designers are forced to think in terms of ratios (expressed in percentages) instead of pixels. Further to this as the web browser window size is moved into previously nonsensical proportions, the responsive web designer is faced with unique challenges to preserve "design integrity". Solving these challenges via flexible grids, media queries, typographic hacks and even changes to the visual hierarchy are forcing designers to express these visual relationships in code.

Responsive web design at its highest craft is about flexing within specified constraints then having alternative plans when those constraints are violated. How narrow can the browser window get before a column is dropped? How small can the logo go? How wide can a line of text be? All these decisions made by the responsive web designer and codified in CSS and JavaScript provide a living source of data for new understandings in layout and proportion.

Web designers are pragmatic people and don't like doing things twice. So as the body of aesthetic approaches in responsive web design grows many of these heuristics are becoming encoded into behaviours in JavaScript frameworks that are freely shared. Here, JavaScript and CSS code provide good documentation of the ratios and formulas at work. So while web designers pragmatically solve the problems of non-constant screen sizes, their experimentation leads to a new way to look at layout, proportion and hierarchy and this will lead to a greater understanding of mathematics of layout aesthetics.


Designer Work Style.

Nearly 20 years ago I was in a management paper and learned that workers exist on a continuum between the consistent 9-5er and the inconsistent burst worker. It is no surprise that creatives are burst workers. A person whose natural tendency is to work in bursts but who has learned to fit into the 9-5 paradigm will have significant swings in productivity and motivation during the workday. It's almost axiomatic that the more creative a person the less consistent they are.

Designers rise to the challenge of completing deadlines but can become easily exhausted. Much of our training of designers instils into them the primacy of the deadline above all else and this reinforces the burst personality. For the industry this is helpful in that it helps "get projects out the door" and the downtime is necessary for rest, recovery and reflection. The danger is that overwork is much more difficult to detect and burnout is a real risk.

Burst work is fine when project are of generally short duration (i.e. not months or years) and deadlines are not daily. But as our deadlines extend (larger projects particularly web and development) then burst working is less desirable. IT has the "deathmarch project" where the deadline is far away but everybody is pushed into overwork to make it and larger design projects carry the same risks.

My own experience is that there are very few designers who find the consistency of 9-5 easy who are also great visual creatives. The consistent 9-5ers are normally competent and reliable but lack that creative spark or flair. They may be great technically and/or quite good visually but they're likely never going to win a creative award.

Don't knock them because their consistent workers are an important part of a design team. Not only do they handle the routine jobs more accurately and with less frustration, they also provide a yardstick of "normalcy" to their peers. They remind people that families are waiting, the sun goes up and down and the tides go in and out. They are living examples that despite our obsessive tendencies towards our projects and deadlines that there are more important things.

Burst work could be why we place so much emphasis on professionalism - particularly punctuality and attendance. Just to try and counter-act the tendency towards relying on burst work instead of proper planning. Perhaps this is the Confucian balance to the natural tendency of designers. The Confucian education principle here is that education often involves strategies for handling imbalanced tendencies. "Be more aggressive" a passive person and "Be more passive" to an aggressive person. In this aspect design is pragmatic: we need to work together at overlapping times in a team and we should do that when our clients are active (i.e. the working day). It helps our socialisation to even loosely fit a working pattern common in our culture.

There is a danger: if we do successfully turn these normally naturally burst workers into consistent 9-5ers then we may kill what it is that gives them the creative spark. Mindless consistency is the enemy of creativity. Therefore a mixed burst-consistent approach might provide a compromise; the creative bursters are allowed an equivalent but more irregular schedule provided they meet deadlines.

This is just another of those things that makes design hard: the right amounts of consistency and burst, unbounded creativity and creative pragmatism, obssessiveness but with perspective maintained. And this provides important decisions for employers building a team: it's often not just about the skill set, but how their work-style fits the work you do.


My PhD: The Simple Version

I have been struggling to come up with a simple way to explain my PhD but I think I have it.

My research tries to reduce information overload when displaying data where the structure of that data is not known ahead of time.

This is a particular problem for the Semantic Web because of the Innumerable Corpus property. That is: there is an innumerable amount of data expressed using innumerable ontologies (structures). This research will help in the construction of a general purpose semantic web browser.

What is the scale of the problem? If an ontology is well known then a human can hand-craft a display for that ontology but that display is fragile and fixed. Fragile meaning that it will only work for that one ontology and will not display data that only partially uses the ontology (and what is data is used from multiple ontologies?). A fixed display will not necessarily suit the needs of all users.

Where ontological enrichment research expands the amount of data available about a subject, my research reduces data to the minimally most useful set compared to what is known about user goals. My research then attempts to select displays that reduce information overload by taking into account user needs.

I currently (Feb 2012) have a beta semantic web browser (Eme) suitable for continued experimentation. I am currently working on algorithms to make intelligent decisions for the display by discovering how data triplets are related.

Are triplets related somehow? completely independant? members of the same set/list? redundant equivalents? or a related alternative? Knowing this allows us to make intelligent decisions about the display; related triplets can be grouped together, members of a set can be displayed as a list, redundant triplets can be eliminated and alternative need only one of the alternatives displayed.


Best time to join cash tables

On PokerStars I've noticed a little bit of a trend on the lower limit tables. These limits are just full of regulars with 11/8 stats that are annoying to play against when there are too many on the table. Ideally you want tables with at least two fish that you can exploit. Here's my tip:

Join tables in the five minutes before the half hour or the whole hour.

Why does this work? Well it turns out the people with these stats are grinders. They play a fairly predictable game over a large number of tables. They also tend to play to for a set length of time which incidentally tends to end on the half or whole hour. These are the times when seats might open up on tables with the fish. With so many seats opening up it might even attract a few new fish to your tables.