Canyon

Creating Pagination in a semi-stateless manner

Let's walkthrough developing the process of paginating results from a server. As we go along we'll identify places where we feel we need state, and I'll show you, how I deal with that problem without being overly dogmatic.

Except where otherwise state, all code examples are fully functional. Just open a developer console on the lodash docs page and you can copy and paste to verify the results.

Start with the data

server = _.range(0,100)

Our result set of numbers 0-100 sits on the server

We want to view a subset of that data on our screen, on the client side.

server = _.range(0,100) client = { subset: [] // <--- server data goes here }

We want to take different slices of the data using an offset and limit property. The offset moves us further into the results, and the limit says how many we want to retrieve.

server = _.range(0,100) client = { subset: [], offset: 0, // <--- Start at the first result limit: 10 // <--- How many we will retrieve }

Now to fetch the data from the server, we need to take a slice based on our offset and limit property.

server = _.range(0,100) client = { subset: [], offset: 0, limit: 10, //assign a slice of the server data to the subset property current: function(){ return this.subset = server.slice(this.offset, this.offset+this.limit) } }

We can now use this new function.

client.current() //=> [0,1,2,3,4,5,6,7,8,9]

Invisible Problems

We've barely started, yet we have run into some problems.

This simple application is already difficult to reason about,

We have to have store what the state of the client is (in our brains!), in order to verify the result is correct.

We are accessing external state via this.subset, this.offset, this.limit and server, inside the function. So calling the same function twice will not guarantee getting the same result twice.

We are modifying external state via this.subset, which means we could clobber the hard work of some other function, and make debugging a nightmare.

We can't easily compose multiple functions together to create new and interesting functionality, because each function could be doing bizarre things that are unrelated to our current process.

At this stage, I think we can live with all these problems for such a trivial application. But with a few small modifications we can keep our state, but also keep our pure functions.

server = _.range(0,100) client = { subset: [], offset: 0, limit: 10, pure: { //Pure function: takes a subset of data from a given server //based on offset and limit parameters current: function(server,offset,limit){ return server.slice(offset, offset+limit) } }, //Stateful function: assigns a subset of server data to //this.subset property current: function(){ return this.subset = this._current(server,this.offset,this.limit) } }

Now our pure function is namespaced as pure.current, and our stateful function can make use of its functionality accordingly. The actual functionality is in pure.current. current is just providing the state and performing an assignment.

Okay! Now our code is composable, testable, less error prone, but still stateful! Huzzah!

On with the pagination

server = _.range(0,100) client = { subset: [], offset: 0, limit: 10, pure: { //Pure function: takes a subset of data from a given server //based on offset and limit parameters current: function(server,offset,limit){ return server.slice(offset, offset+limit) }, //increment the offset by the limit next: function(offset,limit){ return offset+limit } }, //Assigns an increment offset property to this.offset //and then assigns the latest subset data based on the new offset next: function(){ this.offset = this.pure.next(this.offset,this.limit) return this.current() }, //Assigns a subset of server data to //this.subset property current: function(){ return this.subset = this.pure.current(server,this.offset,this.limit) } }

All we've done is add a pure.next that simply increments offset by limit in a stateless manner. And we've now got a stateful next function that calls a pure function with internal state as arguments, and then assigns the result to client.offset.

For convenience client.next() then updates the client.subset property with a call toclient.current(). But if you wanted to be more explicit, you could leave them as separate calls.

Just a quick example on why this is so great.

[client.offset, client.limit] //=> [0, 10] <--- current state of client client.pure.next(client.offset, client.limit) //=> 10 client.pure.next(client.offset, client.limit) //=> 10 // <--- Still 10! client.pure.current(_.range(0,100),client.offset,client.limit) //=> [0,1,2,3,4,5,6,7,8,9] client.pure.current(_.range(0,100),client.offset,client.limit) //=> [0,1,2,3,4,5,6,7,8,9] // <--- Still 0-9 //looking into the future statelessly client.pure.current( _.range(0,100), client.pure.next( client.offset, client.limit ), // <--- Get the next offset client.limit ) //=> [10,11,12,13,14,15,16,17,18,19] <-- Always will be!

This means we can test the functionality of our application without fear of breaking anything. That last one was a little verbose, but in test code that is a good thing. All state is there for the eyes to see!

Easier Refactoring

Next we are going to add the prev and pure.prev functions. But I want to point out, that since our pure functions are pure, we will start to notice common patterns that we can factor out of our code, that would be harder to accomplish if our code was touching external state.

server = _.range(0,100) client = { subset: [], offset: 0, limit: 10, pure: { //Pure function: takes a subset of data from a given server //based on offset and limit parameters current: function(server,offset,limit){ return server.slice(offset, offset+limit) }, //increment the offset by the limit next: function(offset,limit){ return offset+limit }, //decrement the offset by the limit prev: function(offset,limit){ return offset-limit } }, //Assigns an decremented offset property to this.offset //and then assigns the latest subset data based on the new offset prev: function(){ this.offset = this.pure.prev(this.offset,this.limit) return this.current() }, //Assigns an increment offset property to this.offset //and then assigns the latest subset data based on the new offset next: function(){ this.offset = this.pure.next(this.offset,this.limit) return this.current() }, //Assigns a subset of server data to //this.subset property current: function(){ return this.subset = this.pure.current(server,this.offset,this.limit) } }

Let's zoom in on pure.next and pure.prev for a moment.

//client.pure {} //increment the offset by the limit next: function(offset,limit){ return offset+limit }, //decrement the offset by the limit prev: function(offset,limit){ return offset-limit } //...

They are very similar. All that is changing is the polarity.

And let's look at the stateful versions.

prev: function(){ this.offset = this.pure.prev(this.offset,this.limit) return this.current() }, next: function(){ this.offset = this.pure.next(this.offset,this.limit) return this.current() },

They are even easier to refactor. All that is changing is which pure function is being called. We could replace each of these function with a single function called change( 'next'|'prev' ). That might look like this.

change: function( directionName ){ this.offset = this.pure[directionName](this.offset,this.limit) return this.current() }, prev: function(){ return this.change('prev') }, next: function(){ return this.change('next') }

We could do this. But keep in mind, indirection via multiple refactored functions can actually make it harder to reason about your code. So only pull that trigger when you feel complexity is going to be decreased. Here is a great read on this process Compression Oriented Programming by Casey Muratori.

Infinite Scroll

Now our client can paginate statefully through the server data, but usually in pagination we don't completely remove our current dataset, we add a little bit of new data, and remove a little bit of old. This is often referred to as "infinite scroll". Let's see how hard it is to implement this change to our current app.

server = _.range(0,100) client = { subset: [], offset: 0, limit: 5, padding: [1,1], // <--- [paddingAbove, paddingBelow] pure: { //Pure function: takes a subset of data from a given server //based on offset, limit and padding parameters current: function(server,offset,limit,padding){ return server.slice(Math.max(offset-padding[0],0), offset+limit+padding[1]) }, //increment the offset by the limit next: function(offset,limit){ return offset+limit }, //decrement the offset by the limit prev: function(offset,limit){ return offset-limit } }, //Assigns an decremented offset property to this.offset //and then assigns the latest subset data based on the new offset prev: function(){ this.offset = this.pure.prev(this.offset,this.limit) return this.current() }, //Assigns an increment offset property to this.offset //and then assigns the latest subset data based on the new offset next: function(){ this.offset = this.pure.next(this.offset,this.limit) return this.current() }, //Assigns a subset of server data to //this.subset property current: function(){ return this.subset = this.pure.current(server,this.offset,this.limit,this.padding) } }

Here we've added a padding property to client. We've modified the pure.current to addpadding[1] to the limit and subtract padding[0] from the offset. We've also ensured that the subtraction is always >= 0.

We could have done this many different ways. We could have not told pure.current about thepadding and left that up to next and prev. And that could have worked. But I chose to make the most minimal change to the client code as possible. And I wanted as little code duplication as possible.

We also could have performed this with in the stateful current function. But I would advise against that, as our stateful functions are a lot easier to maintain and understand if they only provide and assign state, and leave the logic to the pure functions.

Let's see our padding in action. Note I've updated the limit parameter from 10 to 5 to make it clearer what is going on.

Let's look at the stateful code in action.

[client.limit, client.padding ] //=> [ 5, [1,1] ] client.current() //=> [0,1,2,3,4,5] // <--- Note 5 is padding client.next() //=> [4,5,6,7,8,9,10] <-- Note the overlap of [4,5] from the previous call client.next() //=> [9,10,11,12,13,14,15] <-- Overlap of [9,10] client.prev() //=> [4,5,6,7,8,9,10] <-- Overlap of [9,10]

So it works! And we can adjust our padding very easily. We can pad more on the top than the bottom depending on our scroll direction or vice versa by just setting client.padding = [paddingTop, paddingBottom] and subsequent calls to client.current(), client.next() and client.prev() will obey that constraint.

Possible Confusion

We are finished! We can infinitely scroll through a range of numbers. But creating a simple API is not a simple task.

There could be confusion for the user of this API when they have set the limit to 5 with padding of[1,1] and they end up with a subset.length of 7. This confusion stems from the idea that limit is the maximum length of the subset. But is instead the number of items to fetch from the server. Thepadding is added to the limit and subtracted from the offset, so the max length is really a function ofoffset,padding and limit.

maximumLength: function(padding,offset,limit){ return offset-padding[0] + limit+padding[1] }

It doesn't really make sense to set the maximum length, because then the padding is applied internally, and seeing as you have limitied the size, all you are really doing is shifting the offset to the left.

An illustration:

maximumLength = 5 padding = [1,1] limit = 5 offset = 10 server.slice( offset-padding[0], //shift to the left by the offset limit+padding[1] //expand the limit by the padding <-- pointless ).slice(maximumLength) //ignore the expansion of the limit as we only use up to the max of 5

But say you really just want 5 items, and you want each page to flow into the next page seamlessly. What do you do?

Just ignore padding altogether and move the offset forwards by less than the limit.

overlap = 2 client.limit = 5 client.padding = [0,0] client.offset += client.limit - overlap

And if you are scrolling in the oppositie direction, just subtract the offset instead

overlap = 2 client.limit = 5 client.padding = [0,0] client.offset -= client.limit + overlap

Your "server" is just an Array!

In this example, the server was just a generated array of numbers from 0-100. But that was so we could focus on the algorithm of the pure functions instead of AJAX calls.

That said, it makes sense to have your server code in a separate module and to just think of it as another client side collection of data while interacting with it. That way, the server module can act like an array and handle internal caching and prefetching to make our client module super fast.

Here is a simple implementation of what our server might look like. Note this below code isn't actual code that will work, it is more of an illustration of the concept.

server = { data: [], slice: function(start,end){ if( data[start] && data[end] ){ return Promise.resolve(data.slice(start,end)) } else { return fetch(start,end) } }, handleResponse: function(start,end,response){ return data.splice(start,end,response) }, fetch: function(){ return $.get('https://api.number.com/range?start='+start+'&end='+end) .then(this.handleResponse.bind(this,start,end)) } }

And we'd need to update our client code to call server.slice(start,end).then( ... ) instead ofserver.slice(start,end) But then we'd be able to treat our server as an array, and everything would be great!

In Closing

I am not fully convinced by functional programming's strict adherence to statelessness. I think there is more of a continuum. If you can separate stateful activity from stateless algorithmic activity you can save yourself the vast majority of headaches of both statefullness and functional purity. I personally don't use a pure namespace in my own code. I tend to just keep the majority of functions stateless except for the assignment functions. But I think it could be a good pattern to follow, particular if thepure object was bound to a frozen context to make accidental calls to this harmless.

It seems to me there are plenty of occasions where state is appropriate, particularly for performance. But I have also seen extremely stateful code that is very hard to interact with, and can take a lot of mental fortitude to even attempt to open and contemplate the file. That is why I have taken the middle road, keep your algorithm stateless, but don't shy away from state.

The great thing about this implementation of the client. Is the user has a choice to work statefully or statelessly. Their application could call the pure functions directly, and maintain their own pagination state somewhere else entirely. And they could also just call client.next() and let the object handle it's own concern.

I've been learning WebGL over the weekend. And I wanted to generate some mountains. Everything was a little to adhoc, so I thought I'd write a simple wave function.

The output of this function could be used for many things including:

You can play it here

Yesterday I wrote a mini library that converts the JS object literal into a functional syntax.  It's called O you can check it out here: It has a clean syntax, with the bonus of chaining assignments and change handlers.

The life of a tweet is sometimes a day, sometimes hours, but mostly seconds.

And what does that second serve?  What does it accomplish?  It motivates you, just enough, to provoke you to spend the next second doing the same thing.  That is the value.

It is no accident.  Twitter, Tumblr, and Facebook work, exactly the way they do, intentionally.

My statements are a reaction to an excellent long form piece by Brendan Vance on the soul crushing nature of "content".  

You and I do not benefit in the "eternal now" as history informs our choices.

So, as an act of rebellion against the 1 second economy, I would ask you to contemplate the following:

- Collect things you appreciate, archive them, and share your archive.  Make the home for these findings timeless.

- Encourage others to do the same, and then spend more time in their libraries than the news feed.  Exhaust their histories, and then seek to learn and appreciate more.

I recently read: Why indie gaming’s obsession with moneymaking hurts us all and while I don't exactly disagree, I think the article neglects to mention the positive aspects of its industrial imperative.

What do I appreciate about the industrial focus of the games scene: serious conversations.

This is what I know about "scenes"

A band that I still jam with occasionally, was particularly active a few years ago.  We played a lot of clubs and met a lot of other bands, we played many times on the Sydney independent station (FBI), and always had gig posters around town and in street press.

People usually knew of us... vaguely.

We weren't "all that", but we were there.

I played at the "cool" places with the "cool" bands and with exception to actually playing, found the entire thing quite uncomfortable.

These musicians went to gigs and parties and got drunk.  They rarely mentioned any aesthetic aspects or aspirations - not because they had no interest in exploring, but because there was no environment to facilitate it.

The environment of the music scene I was apart of, encouraged things like; being "quirky", "headlining", "rider" and different brands of guitar pedals.  I am not saying there weren't people around that were into more substantial aspects, I am just saying that in 4 years of heavy gigging, I didn't meet any.

Music is an established medium.  There is no myth of rags to riches anymore, but people still play.  You would think this situation would allow "real artists" to thrive.  But instead, music becomes just became a way to be "cool".

"The only true currency in this bankrupt world is what you share with someone when you are uncool."

Lester Bangs - Almost Famous

Being cool is only starting to be a problem in the games industry.  And it is the problem to avoid. 

When I was first exposed to the games industry, I was overloaded with amazing people, saying amazing things, all the time.

Conversations about "the medium" and how much we need to improve are so frequent that at some point we have to give ourselves some credit for being such harsh critics of ourselves.

Focus on financial constraints or goals is not misguided, it is realistic and while unfortunate, forces you to take what you do seriously.

When you take what you do seriously, and when you expect others to be doing the same, your work improves.

My favourite game is Jedi Knight: Dark Forces II. I was 9 or 10 when it was released. My cousins and brother and I used to play it together whenever we went to eachother's house.

At the time there was an active modding community at http://www.massassi.net/. I would read the forums and hear about upcoming releases. Then we'd install them all and play them when we met up next.

I always wanted to make a level or a mod for that community. I respected them a lot, and I was grateful to them for keeping the game alive well past its use by date.

I downloaded the editing tools and gave it a whirl but I could not make heads or tails of it at the time.

Fast forward 10 years and I am a web developer who has participated in multiple game jams. I wanted to revisit the game and found it didn't run too well on Windows 8.

I'd been down the road of trying to get it running many times before. But this time, instead of reading forums about driver hacks and version downgrades, I opened up a text editor and started to code.

I've been demaking the first level of the game in pixel art for the past few days in my spare time. I am not entirely sure what this will turn into, but it has already helped me improve a level language I have been working on called downplay (pictured above)

I recently moved interstate to start a business with my brother. But there have been a couple of weeks for me to relax before he was available to start.

So instead of taking a break from programming, I've released three projects on github; Crescent, Temple, and Canyon

Crescent is a JSON database with a unique but powerful functional query syntax.

Temple is an extremely simple JS templating library.

Canyon, is the source code for my website canyonthings. Just edit a json config file and it will pull in your tumblr blog feed and link to your twitter in the sidebar.

These projects arose out of other larger projects that are still in development. Crescent and Temple will both be used in these other projects.

Entity Component Systems.

My neurons were hard coded to "think in Objects". And only very recently I heard about an alternative: Entity Component Systems - an idealogical middle ground between Procedural and Object Oriented Programming.

In an Entity Component System, data is divided into hashes called Components. Logic is placed into separate modules called Systems. These systems query the data and manipulate it.

Each system is a specific solution to a specific problem. Each component is a data store. An entity is the primary keys that joins all the components together. These components can be arranged to form a useful arrangement of functionality.

The querying of the component data, is facilitated by an Entity Manager. The Entity Manager associates unique identifiers with various components. The actual application you write is a simple loop that calls various Systems in order.

Lets look at some code shall we?

An example of an Entity Component System:

//Entity Manager EntityManager = { components: { Position: { 1 : {x: 5, y: 0} 2 : {x: -10, y: 10} } Movement: { 1 : {vx: 2, vy: 0} } } } Systems : { Movement: function(){ //get every Movement component EntityManager['Movement'].each(function(movement, id){ //retrieve the matching position component var position = EntityManager['Position'][id]; if(position){ //manipulate the data position.x = position.x + movement.x; position.y = position.y + movement.y; } }); } } function loop(){ Systems.each(function(system,systemName){ system();//calls the Movement system and any other system we define. }); }

The above code shows the state of the EntityManager. There are two entities. Entity 1 has both position and movement, Entity 2 only has position.

At any time I could give Entity 2 the movement ability.

EntityManager['Movement'][2] = { vx: 0, vy: -5};

And I do not have to change anything else. The Movement system will now query the entity Manager for all Movement components, and Entity 2 will move!

In my actual code, I've written some helper functions into the EntityManager to make querying more powerful.But that is the pattern in its simplest form.

At any time I could remove Entity 1's ability to Move:

delete EntityManager['Movement'][1]

This will not break anything, because there are no dependecies, only queries. The Movement System will simply stop Moving Entity 1, because it no longer meets the criteria necessary to be moved.

Because the data and the systems are separated, functionality is more modular than a Class. A system will automatically identify which components are compatible, and modify their data automatically.

In an Object Oriented approach, you cannot easily mix DNA with other objects. As the DNA is heirarchial. This post is not an explanation of this specific problem though, so I am going to assume you can make that comparison yourself.

Entity Component Systems are painfully simple to serialize. Because all the state is in one place - within the Manager

To save the current state of the program in Javascript:

var json = JSON.stringify(EntityManager); //that is all.

The biggest obstacle to effectively using Entity Component Systems is how fundamentally different it is (philosophically) to Object Oriented Programming.

In an Entity Component System, there is no classification, only composition. An Entity is not a "Thing", it is "Stuff"! The idea that code is constructed of "things" that have behaviours and information is so tempting and beautiful that it can blind us from the truth: we are just modifying data.

Say you had to code a Spaceship in a video game. Instead of imagining every possible scenario the spaceship might be in, and creating an elaborate structure that allows you to reuse various traits of that heirarchy for other objects. Just build each part in sequence, changing your design as you go.

var spaceship = 1; EntityManager[Position][spaceship] = { x: 0 , y: 0 } EntityManager[Movement][spaceship] = { vx: 0 , vy: 0 } EntityManager[Guns][spaceship] = { fireRate: 1 } EntityManager[Fuel][spaceship] = { amount: 100, capacity: 200, burnRate: 100 } EntityManager[Damageable][spaceship] = {} EntityManager[Renderable][spaceship] = {} EntityManager[KeyboardControlled][spaceship] = { ... }

And then when you want to program your projectiles...

var projectile = 2; EntityManager[Position][projectile] = { ... } EntityManager[Movement][projectile] = { ... } EntityManager[Renderable][projectile] = { ... }

And then maybe you want a player controlled projectile...

EntityManager[KeyboardControlled][projectile] = { ... }

And then when you want an AI controlled space ship

var spaceship = 3; EntityManager[Position][spaceship] = { ... } EntityManager[Movement][spaceship] = { ... } EntityManager[Guns][spaceship] = { ... } EntityManager[Fuel][spaceship] = { ... } EntityManager[Damageable][spaceship] = { ... } EntityManager[Renderable][spaceship] = { ... } EntityManager[AIControlled][spaceship] = { ... }

It may seem like spaceship is an object that "contains" these components. But that isn't accurate. These components are just data, that could be "associated" to any entity at any time. And a particular grouping of this data (combined with systems that act on them) would functionally be equivalent to OOP code.The Entity Component System approach requires no forethought. There is no code rot. You can change your mind at any time, even during run time.

Another quick illustration of the concept. A Glass of Wine does not inherit from a baseclass called FragileLiquidContainer. It is composed of various traits. Width, height, weight, surface tension, capacity, transparency, material strength etc.

Abstracted heirarchies can make it easier to understand complexity, it can also back us into a uncomfortable, poorly designed corner.

Just a brain dump:

Provider

Provider is up on canyon.itch.io now. And I've got this awesome banner art by Zoe Appleseed

I've been working on some updates for Provider that I am yet to release. But basically touch input and full screen canvas. So I can play it on my phone/tablet.

Will post again when those update are... up?

Invs

Today I've been reading this email thread by the makers of Threes

And seeing how they struggled with the core game has really given me hope for one of my older games, INVS.

INVS is a bit broken. But I think it showed a lot of promise. And after reading this thread I just want to revisit it so bad.

Nano

I've been working on an old game idea recently. It is a real time strategy game with one unit type. You can split that unit to be infinitely small and the game is all about micro management.

I was working feverishly on this project. But I've slowed down a bit as I'm about to move interstate and start a business (pretty insane!)

But I am very excited about the possibilities of this project. And I think it is a good sign that the game idea has stayed with me for years now.

Blend Mode Thing

I've also been fooling around with blend modes and canvas. I've been trying to recreate a image I made the other night, but in real time.

Not sure what this will turn into, maybe just a tech demo of what blend modes can do. But I've started by generating mountain ranges and stuff. Will post updates on that if it goes anywhere.

Maybe Snake?

A couple of weekends ago, I tried to make snake. I lost interest after a while, and instead made it turn based. Not sure if it will go anywhere, but I'll throw the link up anyway:

http://codepen.io/JAForbes/pen/tkoCe

Keyboard Input Thing

Also, I was experimenting with Keyboard Input a bit, and came up with a cool system for swapping out key mappings for directional input.

http://codepen.io/JAForbes/pen/iGfLy?editors=001

That's all for now!

So, I'm a musician, and a songwriter. I am relatively prolific for my age. I've written hundreds of songs and sometimes it depresses me that no-one will hear them.

Each song means a lot to me and therefore it gets me down to think of those songs never having the opportunity to be found by someone who might care about them.

I also, don't really think of my songs as mine.  Once they are written I think they are everyones.  Yes, I wrote them, and yes, they are the result of my self expression.  But, they are also a reflection of everything around me, I am just a filter of a massive vibrating hive.

Getting back on topic.

For the past few months I have been taking a new (at least for me) approach to recording.  It has been a reaction to what I have just discussed, but also to my life priorities expanding.  In a way, my life is becoming more serious, and I thought that was diluting my expression.

But the opposite has occurred.  Me being so busy, has refined my expression.

I have been completely ignoring music.  And then, I suddenly get an impulse to play a song.  I then sit down for a few minutes, record a single take of that song.  And then I get back to what I was doing.

I haven't worried about getting the best take, avoiding mistakes or pauses. I haven't fretted about singing the wrong lyric or going off key or out of tune.  I've allowed myself to record the impulsive energy that made me want to pick up a guitar and record in the first place.  And by not taking a second take, that energy is retained and conveyed in the recording.

I now have recorded, 30 of these rough takes.  And I have been toying with designing a website archive to release them.

And the presentation of the recordings is important to me.

Another one of my interests is game design.  And I think I could convey the value of these recordings more surgically, if the website's underscored the same philosophy.

So my current design idea is as follows.

When you visit the website, there is a large title and description stating what this website is and why it exists.  It is like the first page of a book.

You then click the right or left arrow to listen to a randomly selected song. There is no index, there is no way to get straight to a specific place.  It is all about allowing yourself to experience something unfamiliar and raw. To explore.  And maybe potentially, it is not as curated of an experience, but I think that the lack of curation is more powerful.

There is no progress bar or pause button.  You can play or skip tracks. 

You cannot restart a track.

I do not want the listener to know when a song is going to end.  That reduces that sense of exploration.  I want to encourage wilful patience and an acceptance of the unknown.

Recursion is a strange, but important concept.  It is difficult to explain, so I thought I would write a blog post to tackle the problem.

What do I mean by Recursion?

Recursion can mean different things to different people and in different fields.  Generally it means following the same set of instructions repeatedly but applying those instructions to a nested hierarchy.

Say that I wanted to explain a difficult concept to someone.  In order to explain it, I could write a blog post.  

I could then break up the blog post into separate sections.  And each section into separate paragraphs.

Each paragraph could contain sentences that carefully explains the specifics of a smaller part of a larger concept.

Once the reader understands the sentence, they can then move onto the next sentence.  And when they understand the paragraph, they can move onto the next paragraph.  And when they have understand all the paragraphs of a section, they could move onto the next section.

The reader can then understand the more complex issue, by breaking it down into a smaller ideas that can then be aggregated to form a more complex idea.

I could instruct the reader to simply: "Read the blog post".  And they would recursively traverse all of the sections and paragraphs and sentences without even realising they are doing it!

So you see, recursion can be used to break a large complicated instruction into one or two simpler ones that can be repeated down the chain.

Just have you have done, by reading this very section.

The Best Part

I don't know why.  But I am a stickler for a good user interface.  I appreciate subtle touches, and I often get frustrated (too frustrated) with the smallest details ruining an otherwise consistent experience.

Facebook Paper

Yesterday a client sent me a link to a PR site previewing Facebook Paper.

My client and I are working on a Photo Management Web Site, so we often send each other links to see what the competition are doing, particularly with user interface and touch gestures.

It's worth watching this video and experiencing the PR site before reading the rest of this post.

What is Paper trying to achieve?

Social networks and Photo Management sites are circling Facebook like sharks.  There are more interesting sites and apps that are making Facebook look like a dinosaur.  

Now it is hard for me to judge the app after only watching a video, but indulge me.

I believe Paper's goals are to appear to be innovative, ahead of the crowd, young fresh etc.  But there is little substance to the design choices here. And because the motives behind this UI reboot are so shallow, the design follows suit.

What is so shallow? Looks pretty cool to me!

Before I even get into the product let me discuss the PR website that is representing the product.

The website is gorgeous, a full screen HD video sits underneath four headings.  Each heading takes you to a separate part of the video.  It is simple, clutter free and poorly executed.

The site lags.  If the video cuts out, it does not gracefully degrade to a simpler experience.

When you click 'Watch Video', you cannot pause the video.  There are no media controls, there is no tracker.   You are trapped until Facebook has finished with it's pitch.

I think the PR website is indicative of the design of the App.  Looks great, but isn't great to use.  And I suppose that is the too long didn't read version of this post. Now, onto the app itself.

You can unfold a "story", oh like a Newspaper! Wow!

Onto the actual App.

I think Facebook is now calling posts, stories. And when you are browsing said stories, each story takes up the entire screen.  If there is an article in a story on an external site you can unfold the article to fill the screen.

Before I go into why this is a bad thing, let me go on a small tangent about Skeuomorphism and Faux Flat Design.

Short Aside on Skeuomorphism and Faux Flat Design

Skeuomorphism is when a newer product includes elements that were necessary in the past, that no longer serve a functional purpose in the present.  

This word gets bandied around a lot regarding MacOSX and iOS6 tendencies to lean on analogue visual metaphors to make their products feel more comfortable.  They may have pages that peel as they turn in a reading app.  Or Faux Leather texturing in their Calendar app. 

More recently there has been a flat design movement that attempts to improve clarity by rejecting the shackles of analogue visual metaphors.

Flat design, is a new movement in graphic design.  It's purpose is to convey information - quickly.  It achieves this goal by replacing shadows, textures and lighting with clean shapes and flat colours.  Often text is used in place of iconography.  When symbols are used, they should be universal - something you'd find at an airport or on a subway.

The obvious example of disregarding skeuomorphism is the Windows Live Tile.  Live tiles are a new functional approach to user interface.  A Live Tile serves multiple purposes; app launcher, widget, notification area and as a shortcut to specific content within an app.  You can create a Live Tile by Pinning it to your Start Screen.  A Live Tile can be a contact, a website, a search within a twitter app, a photo, a folder of photos, an album in a music app, a particular inbox in a mail client, etc.  A Live Tile is always created in the same way and can be done so via any app.

These tiles update automatically to display a summary of the apps state. Often this is sufficient enough to take actions without even opening the app.  

A real world example, Melbourne's public transit system uses cards called Myki's. When you travel, the credit is deducted and occasionally must be topped up, if you want to continue to travel.

I can see my Myki Balance on my start screen, so I can decide whether to top it up without opening the App.  This is pretty useful when you are running for a train, and need to make a snap decision.

Because the Live Tile is not trying to be a digital equivalent of a familiar analogue situation, it can be as dynamic, consistent and functional as the designers wish it to be.  There is no anchor of familiarity to burden exploration of more interesting approaches.

Why a tile? Ugh.

The Live Tile is a tile, because, Squares tesselate well.  You can have variable widths and heights and maximise visual space for content.  

If you have more screen real estate you can have large tiles with more detailed information.  There is no gradients, rounded corners, highlights, shading etc.  Because they are visual noise that detract from the information being conveyed.

The Live Tile does not need to rely on visual distractions, its simplicity and functional consistency make it beautiful.  It is not a gimmick, it is a triumph of user interface design.  Consistent, Simple, Functional.

The Live Tile is the perfect example of reinvention, simplification, and rejecting convention to create something more powerful than previous metaphors with less complexity.

Faux Flat

There is also a parallel movement that I call Faux Flat design.  Faux Flat design is simple and visually striking, but does not follow the tenets of flat design (text over symbols, information over metaphors).

Faux Flat design is still bound to expired tropes.  Navigation in the iOS clock app (pictured above) uses old fashioned alarms icons (with actual bells) and analogue stop watches for iconography.  These icons are no longer iconic (Do you own an alarm clock with bells?), they are equivalent to using a floppy disc icon to save a file.

How does this relate to Facebook Paper?

Facebook paper is Faux Flat design because it relies on the folding gestural metaphor to convey intent.  

By Folding an article open, I am reminded of using a Newspaper.  And yes, visually it is quite striking.  But, if it is now more common to read the news in an app, than to unfold a newspaper - why is the reminder necessary?

A deeper approach.

I have established that the folding gesture is unnecessary, but it is also used inconsistently.  I cannot use this gesture to view everything in the system. Some content I need to tap on, some content I need to pinch and zoom, some content I drag up to view, some content I can unfold.

When adding gestures to your app, consider: if it was the sole way of performing an action would it suffice on it's own?

Let's consider for a moment: what if everything could be unfolded?  What if every story, message, etc in the whole app can be folded open and closed.  What if that was the only way of switching content.  What would be the advantage of folding (with a swipe) vs tapping.  Tapping is quicker, keeps your screen cleaner, obeys conventions.  Folding reminds me of using a newspaper, sort of, but has little to no functional benefit.  Tapping also makes sense in all situations, but why would you unfold a photo?

So if it wouldn't work on everything, why apply it to just articles?  Why complicate your application's vocabulary for no benefit?  

If it was applied everywhere, it would quickly have become apparent - that folding is a gimmick - it has no functional substance, it should have been removed.

What is your point?

Live Tiles behave the same throughout the entire Windows ecosystem. They follow the same contract and are reused for multiple situations. The vocabulary of the system is refactored and the ecosystem and the user are all the better for it.

Paper, on the other hand, is an amalgamation of good ideas without the fusion.  It seems to be designed to attract short term attention but not long term satisfaction.  Like a nerd french kissing a cheerleader at the movies. In the end, he discovers she doesn't think The Jerk is funny and he needs to break up with her and find someone cool. 

Paper is without focus, meandering, relying on assumed previous experience to harness familiarity.  Designed for attraction but not long term use.  Design for viewers, not users.

But without Folding? Why call it Paper?

I wrote a story on the weekend.  Here it is:

The Turtle And the Poet by James Forbes

This is my story.  I write it, because I am asked to. What choice do I have? It is all I can do. I must tell the story of the Turtle and the Poet.

The turtle wanted to cross the river.  Why? It is not important. All that is important, is that he wanted to.

He did not know a turtle could swim.

Next to him, was a poet.  The poet knew, if he told the tortoise he could swim he would never believe him.  The tortoise would think: "Why take the risk?"

If the poet lied (which poets often do) the tortoise would surely drown.

The poet instead, wrote a poem for the tortoise, describing the beauty that lay on the other side of the river.

The Tortoise was so inspired by these words, that he felt the sudden, natural urge to get into the water to cross the stream.

As he entered the water, he remembered that he could swim!  And he gently paddled toward the other bank.

When suddenly a crocodile ate the tortoise.

The Moral of the story: Do not trust a poet.

But that is not the end of the story.

For the poet saw this event, and called out to the crocodile.

"Oh great crocodile. Hear my words, here my wisdom. And be enlightened."

"I can not listen to you poet.  For it is known that poets are liars and deceivers.  Besides, I am busy digesting a turtle, or a tortoise, I can never really tell."  Said the alligator, or the crocodile, nobody was really sure.

The poet countered, emphatically.

"I am offended! for I am not a poet but a winder of words and wisdom! You can think of me, as a priest, or a maiden, or a banshee, or a summers mist, or a fallen demi-god."

The alligator, wooed by the words of the not-poet, exhaled.  "Ok, Poet, I will hear you".

"Surely, what stench decays in your belly is not worthy of the acid required for its digestion.  There is much finer food on the better side of the shore.  

For, you have eaten a tortoise, and as everybody knows: Tortoises are disgusting!  To eat one, leads to bad luck... of the bowels!  What you are after is a Turtle."

The poet continued to describe the infinite delectable details specific to only a turtle - and the potential intestinal risk that may ensue if the alligator did not partake in his wisdom.

"On the far side of the shore, there are many turtles.  But in order to truly enjoy this meal.  You must not have a full stomach as it would detract from the experience."

The now enlightened Crocodile (or Alligator) bellowed.  

"Hmmm, I did not know that Turtles tasted better than tortoises.  But as you say, everybody knows such things.  So I will release my tortoise contained in my belly on the other side of the shore.  Then I will go hunting for Turtles instead!"

And the Crocodile did exactly so.  But to his disappointment, there were no Turtles to be found.  As far as the eye could see - Tortoises, only Tortoises.

I have not posted for a while, and it is not because I have stopped doing things.  It is because there have been too many things.

Space To Proceed

Just last week I completed another game jam, Space to Proceed was my entry.  It's all about teleportation with a little bit of meta game (WOAH!)commentary thrown in.

You can check it out here:

https://dl.dropboxusercontent.com/u/4861305/LD28/postcompo/index.html

Podcast

Alexander Muscat (https://twitter.com/AlexanderMuscat) and I have been discussing doing a podcast together.  And we have had a meeting and it looks like a sure thing.

I have been increasingly frustrated with Game Developer talks at the meet ups in Melbourne, and because of this I have met a lot of interesting people who have expressed a desire for a more honest conversation about our medium and our work.

So we'll see where that goes.

Level Language Idea

I've got an idea for a syntax to easily define tile based levels for 2D games. More on that soon.

Song Archive

I've been recording a lot of songs with my phone of late, and I would like to make a website to publish them, but not in the usual way.  I'd like to create a space for publishing demo recordings with liner notes, drawings and lyrics and whatever else.  Like a scrap book.

Bleh