building rich user experiences w/o javascript spaghetti

Building Rich User Experienceswithout

JavaScript Spaghetti

by Jared Faris@jaredthenerd

Saturday, March 17, 12

About me


JavaScript


Designers


Developers


The Problem

Developers make it worse by not thinking about design

Designers tend to think in terms of appearance. Good ones think about usability.

Only the very best ones think about programmability.


A Typical Product LifecycleSomewhat dramatized...


Designer Developer


We need this feature


I got this


?


Tweaking time...


I got anothergreat idea


Now you tellme


The developer bolts on some more code


And anotherthing...


grrr


We don’t ‘really’

need this


Uh, yeah wedo


The developer bolts on some more code


Some time passes

‘Some time’ is defined as: Just long enough that the developer doesn’t remember

exactly how his original code works.


I’ve got a new feature


Angry developerscan really do this.IT managers be

warned.


Protective Beret


More messy code


The last bug

Oh wait, one more


Finally


The next day...


Two weeks pass.


I’ve got a new feature Gahh!


No developers were harmed in the makingof this dramatic reenactment.


Additional Features + Short Sighted Architecting= Horrible JavaScript Spaghetti


Why does this happen?

This is where you earn audience participation points.


Some Reasons

• JavaScript isn’t real code• We don’t treat client side things as real features• We can’t easily test it


This really all boils down to one thing.

We developers suck.


Bonus second lesson

We developers suck at interacting with designers(or stakeholders).


Three JavaScript Principles

• Decouple everything• Make it testable• Push events, not state


Decouple Everything

Start thinking about UI pieces as individual JS objects.Remove dependencies between objects.Apply your OO best practices here too.


Make It Testable

Separate DOM dependent stuff into a single layer.Put the rest of the stuff in classes that you can test.


Push Events, Not State

Know about the Law of Demeter.Let controls worry about their own state.

Inform other controls that “X happened to Y”, not “Y is in X state”


Some Patterns


Mediator Pattern

"The essence of the Mediator Pattern is to "Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you

vary their interaction independently."

-Design Patterns: Elements of Reusable Object-Oriented Software


NavControlMediator

itemSelected()

Events from some other object

unselectAll()


Observer Pattern

"Define a one-to-many dependency between objects so that when one object changes state, all its dependents

are notified and updated automatically."

-Design Patterns: Elements of Reusable Object-Oriented Software

Think jQuery $(‘.something’).click()


NavControlMediator

itemSelected()


unselectAll()

viewModel


Knockout.js Template Example


Pub/Sub + Fairy Dust = Service Bus

Pub/Sub is great to make sure events propagate.It stats to get brittle with lots of different controls.


Way Too Much Pubbing and Subbing


Service Bus

A service bus is another layer that sits outside controls.Controls that want to communicate speak through it.Your controls are then only coupled to a single thing.


Postal.js


Service Bus + Mediator

• Controls no longer need to know about others.• We can remove/replace controls individually.• We can add controls that listen to the same events without modifying the publisher.• We can re-use pieces more easily because they work in a standard way.


NavControlMediator

itemSelected()


unselectAll()

viewModel

ReportMediator

itemChanged()

unselectAll()

viewModel

Service Bus


NavControlMediator

itemSelected()


unselectAll()

viewModel

ReportMediator

itemChanged()

unselectAll()

viewModel

Service Bus

HistoryControl


Questions About Patterns?


A Typical Product LifecycleRound Two


We need this feature


I got a fewquestions


?


Tweaking time...


I got anothergreat idea


Ok, Cool


And anotherthing...


Done.


Two weeks pass...


I’ve got a new feature


No worries.


Wha? Ohhhk.


A short time later...


Special thanks to

He did the frame artBlame me for

everything else


Knockout.js - Observer pattern (pub/sub)http://knockoutjs.com/

Postal.js - Service bushttps://github.com/ifandelse/postal.js

My Stuff@jaredthenerd

[email protected]://github.com/jaredfaris

http://jaredthenerd.com


http://knockoutjs.com/

http://knockoutjs.com/

https://github.com/ifandelse/postal.js

https://github.com/ifandelse/postal.js

mailto:[email protected]

mailto:[email protected]

https://github.com/jaredfaris

https://github.com/jaredfaris



building rich user experiences w/o javascript spaghetti

Technology

mediator controls

different controls

service bus pubsub

sure events

mediator pattern

testable push events

angry developers

objects sothat