We need to talk about this because of issues with performance and optimization, the MVC model spaghetti code failure (outputting html if a condition exists: the mixture of model code inside view template, too tight coupling between presentation layer and model layer), “don’t repeat yourself” (DRY: repeating code over and over again, i.e., duplicating validation in the client and the server, “any time there is more than one copy of something, one copy is always wrong”), and role separation (wearing multiple skillset hats and mixing contexts–markup/css switch to javascript switch to backend app–without being able to focus on one context at a time).

This isn’t another framework, it’s an optimized/reworked “alternate pattern” of MVC in an attempt to solve some of the weaknesses/problems of MVC. Can we decouple the view from the existing architecture stack?

CVC + JavaScript puts the power of UI architecture in the hands of front-end engineers.

[ session description ]

Presenter(s)

Kyle Simpson

Date

14 March 2010

Tag(s)

#frontandbackofit

#jsarch

Sites

Getify

Demo of HandlebarJS

Speaker Feedback

BikechainJS

HandlebarJS

Traditional: CVC

The MVC model doesn’t have a clear space for client-based JS app (a JS version of the app that is not just the presentation logic, but a representation of the app inside the client).

New: “Clients Views Controllers” (CVC)

Application Layer (black box): doesn’t do anything with the presentation layer, no markup; only concerned with state management/session records and representing the data in a standard format: JSON API. Multiple other layers can talk to JSON API, so make it primary communication interface with application layer.

Web Server Layer: translates protocol request to hand off to rest of stack.

UI Controllers Layer (server): written in javascript, takes care of url routing, data validation. Allows more reuse of code/less rewriting in server/client layers.

View Layer (server/client): written in javascript, view engine decoupled from application, portable to client because of JS to run in browser.

“look up state, hands off to controllers, choose a view”

Clients

Everything is a client of everything else. Each layer is decoupled, modular, scalable.

Views

Templating, portable, DRY, platform agnostic, uses core web tech.

Controllers

Task oriented. Controlled by front-end engineer. Less dependence on backend architecture. Small, independent.

JavaScript on a Server

node.js is a wrapper around the V8 JS engine. Some Python dependencies for build, but not for execute. V8 is just a shared lib. a different way to process web requests: asynchronous events instead of firing a thread for every request. narwhal is a wrapper around the rhino JS engine. Others: javascriptcore, spidermonkey.

Reference implementation: BikechainJS is Kyle’s wrapper around V8. Loads modules to create a hosted environment to run JS. HandlebarJS is a templating engine that uses text/html templates and accepts JSON data input where you cannot call any methods/math. The only logic you can do is to use application “state” for template selection. Compiles templates into JS the first time a template is parsed. Environment agnostic (server or client).

Standards

How do I read/write files, i/o, execute processes, conduct network requests? CommonJS is a standards community. Very young.

Presenters

Christopher Schmitt – Heat Vision

Eric Ellis – Bank of America

Kimberly Blessing – Comcast Interactive Media

Date

Sunday, March 15

Sites

web form elements research

jquery validation

moz monkey

Conversations

Conversations are rooted in trust. Good forms should be structured on trust. Think about people/relationships, and context. The way you speak to your users impacts their excitement/enjoyment. The way you label your forms focused on a label that makes sense to the user not just to you.

Expectation

Apparently expectation is obvious.

Flow

Can a user look at a page in a matter of seconds and understand the pattern of interaction.

[Managed] Noise

Forms that are not initiated or expected; noise is anything that inhibits the user’s ability to complete the task. Marginilization over removal.

Order

Important things (the task) first, then the rest should be add-on. But make sure I have completed something soon.

Progressive Engagement

Lead a user down a path and show them questions only if they are necessary to the context and the type of user you are (if I already know about you, don’t ask me to fill it in again).

HTML5 Form Elements

• Slider
• Input date (calendar) drop-down
• Input time
• Placeholder

Web Form Management

Forms get re-purposed most often. How can you manage all the different form purposes simplistically in a common application pattern library? An editorial style guide for web forms: how do we speak to our customer or about our services?

Pull together the people who care about standards and build a style guide from the ground up.

Validation

Client-side validation doesn’t get it all, and can expose your validation methods to DoS. Split validation between client/server: format v. required. Server-side response for validation errors at top so screen readers see it force.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

Presenter

Paul Annett, clearleft

@nicepaul

Date

Friday, March 13

Sites

podcast

clearleft

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.