Guiding slides for the hour-long presentation on ‘What is jQuery’ that I’ve been giving to backend teams.

Dav­id Flanagan, @__DavidFlanagan
BLOB (Bin­ary Large OB­jects) APIs
Use case: file sys­tem, BLOB, DOM. User se­lects im­age from hard drive, runs it through the API, then sees im­age dis­played in a web page; All files are BLOBs but not all BLOBs are files; Get files the same way we al­ways have: with in­put tag (and on­change)… or with drag and drop; XHR2; new URL ob­ject; blob://; FileRead­er ob­ject can be used to ex­am­ine and ma­nip­u­late con­tents of BLOBs; Text files can now be read; readAs­Text, readAsAr­ray­Buf­fer, typed ar­rays, Ar­ray­Buf­fer­View; “en­di­an­ness”; Blob­Build­er; Web apps can im­ple­ment their own sand­boxed file sys­tems.

John Hann, @un­script­able and Bri­an Cava­lier, @bri­an­cava­lier
Mod­ules > Frame­works
Frame­work vs lib­rary vs mod­ule; Switch­ing cost of mov­ing from a lib­rary or frame­work like jQuery is HUGE; “cod­ing dys­ent­ary” – get yer shit outta my code; cod­ing uto­pia – stan­dalone, small, fast, in­ter­change­able, no glob­als; load­ers and namespa­cing; JavaS­cript stand­ard APIs/in­ter­faces – ecma, json…; html5/css3 – querySe­lect­or­All…; Com­monJS pro­posed stand­ards; AMD – Asyn­chron­ous Mod­ule Defin­i­tion; Mod­ules today – re­quire.js, curl.js, pinf, bd­load, mLAB; prom­ises; in­ver­sion con­trol.

Paul Ir­ish, @paul_irish
Chrome Dev Tools
Tab auto­com­ple­tion; click col­or box to it­er­ate through dif­fer­ent col­or format defin­i­tions; new groups by type AND re­vi­sion his­tory; …and free­form stylesheet edit­ing un­der re­sources; see con­sole api doc for all avail­able con­sole meth­ods; con­sole.dir = DOM view; ESA to hide/show con­sole on all tabs; $0; ‘copy’ in con­sole view => clip­board; ‘?’ in con­sole = help on key­board short­cuts; –re­mote-de­bug­ging = for ex­ample, de­bug­ging tab­let apps via desktop; right-click pretty print of mini­fied js.

Dave Balmer, @balmer
Jo, Light­weight Mo­bile Frame­work
Web is the SDK; He’s look­ing for code con­trib­ut­ors; See ‘JavaS­cript, The Good Parts’ ex­tend meth­od; lessc­ss, sass; css3 for an­im­a­tions and trans­form­a­tions to save the mo­bile JS en­gine (and give bet­ter res­ults); joapp.com; light­er weight than en­yo.

Fa­bi­an Jakobs, @fjakobs
Cloud9IDE

Bri­an Cava­lier
wire.js
In­ver­sion con­trol; “boot­strap­per”; As­pect Ori­ented Pro­gram­ming (AOP) – aug­ment­a­tion of ex­ist­ing com­pon­ents (wheth­er or not source code is avail­able/con­trol­lable); De­pend­en­cies – in­teg­ral, con­fig­ur­able, re­quired, op­tion­al; Com­ple­ments AMD by provid­ing fur­ther flex­ib­il­ity; Or­der­ing and prom­ises; Con­nect­ors.

Dav­id Kaneda, @Dav­idKaneda
Sen­cha Touch
“De­tails Mat­ter”; sass and com­pass.

Bor­is Bokowski, @bokowski
Or­i­on Dev En­vir­on­ment
Use the web it­self as a plat­form for tool ag­greg­a­tion; js­beau­ti­fer.org, etc; ec­lipse.org/or­i­on

Ant­on Kovalyo, @ant­onkovalyo
Code Qual­ity Tools
Gofmt, pylint…; Lin­ters and doc tools (MDC, Bet­ter JS); JSH­int, a po­liter fork of JSLint;

Gaurav Seth, Mi­cros­fot
Chakra JS En­gine
Bet­ter use of dual cores for JS pro­cessing/com­pil­ing; See IE9 dev guide; ecmascript.org – ecmascripttest262; IE10 now avail­able.

Test­ing
Fun­cUnit; qunit;

Ray Mor­gan, @rayc­mor­gan
App vs Web
Zap­pos; App = nat­ive, web = html5; “Nat­ive apps aren’t that hard to write”; “Nat­ive Apps are easy to get per­form­ant”; “Should mo­bile web really be try­ing to emu­late nat­ive apps..?”; Be­ware broken ex­pect­a­tions; An­droid vs iphone vs Win­dows; back to ba­sics – se­mant­ic html; pro­gress­ive en­hance­ment – test on the older tech­no­lo­gies; Us­ab­il­ity and sim­pli­city; Flickr does it right and cap­tures what the web is about; Hash­bang (and Google’s spec on); keep the web the web; flex box.

Dave Her­man, @little­cal­culist
Mod­ules for JS.Next
Lib­rar­ies are a lan­guage’s lifeblood; NPM; JavaS­cript ba­sic­ally hands you a chunk of clay and leaves it up to you; Mod­ule pat­tern – (func­tion(glob­al){…glob­al.var=var={};}(win­dow)); Com­monJS on serv­er side is tak­ing off; for(i=0;…) = WRONG b/c of the leaked glob­al; un­der­score.js; I/O; Next.Js lets you de­clare re­quires and pull them without block­ing the main thread; har­mony.js, next.js…; ev­al is NOT evil (though ir­re­spons­ible/un­educated use of it may be); cof­fescript, scheme, ex­amples of de­clar­at­ively ex­tend­ing html with oth­er lan­guages.

Toby Ho, @air­portyh
Tutti, Mul­tiple Browser JS Test­ing

Adam Bald­win, @adam_baldwin
Se­cur­ity in Web Apps
CORS head­ers now al­low for cross-do­main script­ing and this can screw you if you’re work­ing with hash bang nav tech­niques; evilpack­et.net; OWASP/ES­API en­coder; out­put en­cod­ing != val­id­a­tion; FF has new con­tent se­cur­ity policy.

Dan Webb, @dan­wrong
Design­ing Non-Shit JS APIs
jQuery today is pretty much the de­facto stand­ard be­cause, even though it’s cobbled to­geth­er un­der the hood; its in­ter­face is amaz­ing; A good API = pre­dict­ab­il­ity, sim­pli­city, flex­ib­il­ity; Don’t buck lan­guage con­ven­tions or stand­ards.

Thomas Fuchs, @thomas­fuchs
Zepto Mo­bile Frame­work
All ma­jor JS frame­works we know/use today came out be­fore phones had real browsers, so in de­vel­op­ing for a single plat­form (es­sen­tially, what mo­bile is today with Web­kit) get rid of the x-browser bloat/poly­fills; pro­pri­et­ary fea­tures can be killer – WK’s doc­u­ment.querySe­lect­or­All, for ex­ample, re­places a huge JS foot­print and is faster; nat­ive JSON sup­port; ar­ray it­er­a­tion gets rid of loops FTW; Some func­tion­al­ity (win­dow.res­ize, for ex­ample) is not mean­ing­ful/rel­ev­ant in the mo­bile con­text; SO, don’t down­load a whold bunch of code that isn’t needed (though let’s have a fall­back plan for if code is run on a non-WK browser) – Zepto provides easy mech­an­ism for re­pla­cing it­self with jQuery, for ex­ample; querySe­lect­or­All re­turns a node list that Fuchs turns in­to an ar­racy with slice.call; ajax, events, css, poly­fills, mod­u­lar, and web­kit only; base­camp mo­bile = zepto and back­bone; Small is beau­ti­ful, easi­er to un­der­stand, and comes with less bugs; mus­tache.js, lawn­chair.js, back­bone.js; mi­crojs.com.

But with our ap­proach we had, in ef­fect, only treated one of the axes of a tra­di­tion­al grid sys­tem. Early con­cep­tu­al­iz­a­tion and pro­to­typ­ing of­ten eli­cit the columns, or ho­ri­zont­al rhythm in our designs. We should real­ize, however, that the con­tent that will oc­cupy those columns will be sub­ject to an in­ter­sect­ing rhythm. This is the ver­tic­al rhythm de­rived from ty­po­graph­ic font sizes and line spa­cings.

Be­cause of its de­pend­ence on doc­u­ment struc­ture and mul­tiple css rules, nail­ing ver­tic­al rhythm with an off-the-shelf solu­tion is pretty hard to do. While there are frame­works that in­cor­por­ate the no­tion of ver­tic­al rhythm, ex­tra-frame­work css de­vi­ations by de­velopers will of­ten break the math, and there­fore the grid. I think a more real­ist­ic (and less bloat-sus­cept­ible) ap­proach is to simply keep an eye on the rhythm through de­vel­op­ment it­er­a­tions. To that end, here’s a simple de­vel­op­ment tool that draws grid­lines on a can­vas over­laid on the page. Use it, get rhythm, gain con­trol, and shed the bloat.

ht­tps://git­hub.com/aaitken/Baseline

A couple of years back I half-yawned my way through a UX­Week break­out ses­sion on di­git­al strategy led by Hen­ning Fisc­her from Ad­apt­ive Path. Root cause ana­lys­is fea­tured. The group also went through a couple of mock spend­ing ex­er­cises. Then I re­mem­ber a Venn Dia­gram that had me say­ing, “I have to re­mem­ber this,” be­fore I skipped out early for some San Fran Chinese.

The yawns wer­en’t Fisc­her’s fault – I was just in a time and place that made it hard for me to take the 30,000-foot view. But the Venn stirred in me a sense of re­cog­ni­tion. It showed the over­lap of teams in­volved in design­ing and mak­ing on­line products. If the groups wer­en’t labeled as they are above they were pretty close, and the spot in the middle, Fisc­her stressed, was where the ten­sion of con­cerns was equal and the product was in­formed by its user ad­voc­ates, and busi­ness and tech­nic­al stake­hold­ers.

Part of the reas­on per­spect­ive can be dif­fi­cult, es­pe­cially for mem­bers of in-house teams, is be­cause we of­ten sub­scribe to a sort of jin­go­ist­ic world view that frames the pur­suit of user/busi­ness/tech­nic­al in­terests as a zero-sum com­pet­i­tion. In ef­fect, the Venn is sub­ject to ex­pans­ive, out­ward pres­sures as teams pur­sue their goals over the oth­ers.’ And in en­vir­on­ments where one group has a dis­pro­por­tion­ate amount of power or con­trol, this view en­sures that that group’s con­cerns are dis­pro­por­tion­ately rep­res­en­ted in the fi­nal product. Google’s products smell of en­gin­eer­ing. Most oth­ers leave us won­der­ing why re­gis­tra­tion is re­quired be­fore we’re offered con­tent, or why they simply aren’t bet­ter…

If we’re able to do a 180 and turn from na­tion­al­ists in­to glob­al­ists, the fo­cus for all teams be­comes max­im­iz­a­tion of the Venn over­lap. Pri­or­it­ies con­tin­ue to dif­fer­ but they’re no longer at odds by defin­i­tion. Busi­ness stake­hold­ers re­cog­nize that UX, though no­tori­ously dif­fi­cult to quanti­fy, is in­teg­ral to the bot­tom line and the UX guys in turn seek coun­sel from their backend coun­ter­parts. Each re­gion of the Venn is in­formed by the oth­er two as UX goals be­come Busi­ness goals be­come De­vel­op­ment goals. “What could be a four-step pro­cess has turned in to nine… Are we sure that the busi­ness value in users who com­plete these off­sets the im­plied tech­nic­al chal­lenges and user in­con­veni­en­ce and fal­lout?” Con­struct­ive de­bate on that kind of ques­tion puts us on our way to the right bal­ance of busi­ness and cus­tom­er needs.

I’ve per­son­ally fallen in­to the trap of think­ing I needed to de­fend UI/UX ter­rit­ory as part of my job. What I’ve later come to re­cog­nize-through ex­per­i­ence, read­ing, con­fer­ences, and UCD course audits-is that even in en­vir­on­ments that don’t in­vest heav­ily in user stud­ies or re­search, that UI/UX re­gion doesn’t be­long to us but rather to the user. Ac­know­ledge­ment of this real­ity can free today’s UI/UX de­sign­er to ad­voc­ate on be­half of the user, but with unique in­sight in­to busi­ness and tech­nic­al con­cerns-in oth­er words, to take the 30,000-foot view. And in fact, as the de­sign­ers of today’s di­git­al products, this is our ob­lig­a­tion. It’s up to us to be first in­to the over­lap.

Related

The three-legged stool
im­ple­ment­a­tion, men­tal, and rep­res­en­ted mod­els

Rear-wheel drive from Denver to Vail in surprise 12-30 storm.
5:45am 12-31 de­par­ture for 9:00am 0-de­gree As­pen trail­head.
REM, Dylan, Jimmy Vaughn, Son Volt, Tokyo Po­lice.
21 ski­ers, 4.5 hours, 2,000 feet…
16 beds, 2 days, 42 ski boots.
East Coast Rockies time zone.
Sparklers and down coats.
Eu­k­er, Pigs, Celebrity, Comet, Jenga, Dice, Hearts…
Laphroaig, Red Bull, Vodka, Egg­plant, Ba­con, Pine­apple Ex­press.
Skins, skis, snow.
Blisters, tape, and short on joe.
High­lands Bowl…
And a wrinkle in time.
Thanks y’all… and Happy 2011!

Al­most all ap­plicatons we in­ter­act with on the web are form driv­en. User-sup­plied data in; sys­tem con­clu­sion out. To be sure, a dec­ade plus of ex­per­i­en­ce and in­nov­a­tion has seen UX im­prove by leaps and bounds. But we’re still build­ing forms, and to that end I al­ways en­joy re-vis­it­ing the ba­sic ques­tion of how to build them well. Here’s the es­sence of a re­cent stab.

Re­quire­ment

A con­fer­ence re­gis­tra­tion form to be used by ad­mins from at­tend­ing schools to sub­mit school info, names and de­tails for event at­tendees, and at­tendee ‘Pre-Con­fer­ence’ and ‘In­sti­tute’ choices for each of the con­fer­ence’s three days. Form sub­mit­tal de­liv­ers an email re­ceipt to the ad­min as well as the con­fer­ence or­gan­izers.

Chal­lenges

1. In­form­a­tion There was a lot. From form sub­mit­ters we re­quired school info, point of con­tact info, at­tendees’ de­tails and con­tact info, and at­tendees’ choices for each of the three days. We also needed to give a de­tailed break­down of the choices along with cost in­form­a­tion.
2. Ac­cu­mu­la­tion The form needed to ac­com­mod­ate mul­tiple at­tendees from a school, and track each at­tendee’s choices for each day of the con­fer­ence.
3. De­pend­ency While at­tendees would be able to choose only a single Pre-Con­fer­ence or In­sti­tute for each of the first two days of the event, it would be pos­sible to choose two In­sti­tutes for the third day. Pos­sib­il­it­ies for a second would de­pend on the choice made for the first.
4. Cal­cu­la­tion Cost de­term­in­ants in­clude a school’s ‘mem­ber’ status, the num­ber of at­tendees it sends, wheth­er its at­tendees are also ‘presenters,’ and which ses­sions its at­tendees re­gister for. Each of these vari­ables needed to be tracked so that be­fore form sub­mis­sion we can present sum­mary info in­clud­ing total cost.
5. Val­id­a­tion …as al­ways.

Solu­tions

1. Wiz­ard & Se­greg­a­tion Chunking long forms in to steps with wiz­ards is a tried and true ap­proach that works well here. And rather than blur the line between in­form­a­tion we are re­quest­ing and in­form­a­tion we are de­liv­er­ing, we sharpen it with two dis­tinct views (‘Con­fer­ence Re­gis­tra­tion’ and ‘Con­fer­ence & Re­gis­tra­tion De­tails’).
2. Ad­apt­ab­il­ity We handle mul­tiple at­tendees as they come, with a tabled lay­out. After an at­tendee has been entered with re­quired info, we let the form user ‘Add Next At­tendee’ by ap­pend­ing a new row to the ta­ble. With this ap­proach we al­low for an un­lim­ited num­ber of at­tendees but nev­er present more fields than are re­quired. In the single-page form, at­tendee ses­sion choices are re­cor­ded in a second ta­ble that synchs to the first.
3. Cus­tom Con­trols Ba­sic­ally we want drop­downs with Pre-Con­fer­ence/In­sti­tute op­tions for each of the three days… ex­cept that for the last day, mul­tiple se­lec­tions may be val­id. Here, a cus­tom con­trol emu­lates the stand­ard drop­down but ties lo­gic to each se­lec­tion/un-se­lec­tion so that the user can nev­er make an in­val­id se­lec­tion. For visu­al con­sist­ency and great­er flex­ib­il­ity, we use a vari­ation of this con­trol for the first two days also.
4. JavaS­cript The lan­guage has al­ways been great for cli­ent-side cal­cu­lat­ors. It still is.
5. Min­im­al, Some­times Live Feed­back We de­cided that val­id emails were im­port­ant and that bey­ond that, we simply wanted to en­force com­ple­tion of re­quired fields. This stripped down set of re­quire­ments meant we could de­liv­er a single, stand­ard mes­sage for all er­ror scen­ari­os. When an er­ror mes­sage dis­plays, val­id­a­tion switches to a ‘live’ mode that re­moves er­ror in­dic­at­ors as source data is cor­rec­ted.

Clos­ing Notes

Some as­pects of the design get a little bit cheated when presen­ted in the iframe pulled up by the demo but­ton above. For IE, we de­cided on re­quir­ing users to use an­oth­er browser or else to in­stall Google Chrome Frame. While Chrome Frame de­tec­tion works from with­in the iframe, Chrome Frame itself ap­par­ently does not.

Cross-Site Re­quest For­ger­ies (CSRF) ex­ploit the trust that a site has with­in a user’s browser. By in­du­cing clicks on links to sites where users are sus­pec­ted to be au­then­tic­ated, per­pet­rat­ors can ex­ecute trans­ac­tions un­der the um­brella of a user’s cur­rent ses­sion. Re­quir­ing newly gen­er­ated para­met­er val­ues with each new POST or GET is one way for pro­gram­mers to pro­tect against CSRF. But while im­ple­ment­ing this re­quire­ment in page-driv­en ap­plic­a­tions is fairly straight-for­ward, ajaxi­fied apps make things more com­plic­ated. The fol­low­ing ap­proach lets us ab­stract the com­plic­a­tions out of our day-to-day so we can code both cur­rently and se­curely.

In­stead of

bank.com/with­draw?ac­count=bob&amount=1000000&for=mal­lory

we’re now go­ing to re­quire

bank.com/with­draw?ac­count=bob&amount=1000000&for=mal­lory&csr­f­Pro­tect=1234567890

where the csr­f­Pro­tect value is up­dated with each serv­er hit. As new pages are con­struc­ted on the ap­plic­a­tion serv­er, the csr­f­Pro­tect para­met­er and latest value are ap­pen­ded to any stat­ic links or ac­tions that kick off GETs or POSTs. Thus when le­git users fire the re­quests from the pages re­turned to their browsers, they also sup­ply a cur­rent csr­f­Pro­tect value that sig­nals all is above­board.

The com­plic­a­tion in these be­ing fired through ajax is two­fold. First, for each re­quest we need to dy­nam­ic­ally de­tect and in­clude a cur­rent csr­f­Pro­tect value. Then on the re­sponse, be­cause the app serv­er isn’t giv­en the chance to con­struct a new page, we need to it­er­ate through in-page links and ac­tions and up­date their para­met­er value.

The easi­est way I’ve found to keep up with the chan­ging csr­f­Pro­tect value is to simply re­quire it be sup­plied in any page that might in­stig­ate ajax re­quests, and as part of the data in any ajax re­sponse (in the code be­low, the value is trans­por­ted with in­put[type=hid­den].csr­f­Pro­tect). With these hooks and a stand­ard­iz­a­tion of IE’s im­ple­ment­a­tion in place, we can modi­fy the XM­L­Ht­tpRe­quest ob­ject’s pro­to­type with a new csr­f­Pro­tect prop­erty and a cus­tom open meth­od that in­ter­cepts and up­dates re­quests be­fore they are sent to the serv­er. jQuery’s ajax­Com­plete meth­od keeps XM­L­Ht­tpRe­quest.pro­to­type.csr­f­Pro­tect up-to-date and ready for the next re­quest.

  1: /*

  2: in­clude jQuery

  3: in­clude ht­tp://code.google.com/p/xm­l­ht­tpre­quest to stand­ard­ize XM­L­Ht­tpRe­quest as con­struct­or func­tion in IE<7 (info at ht­tp://www.il­in­sky.com/art­icles/XM­L­Ht­tpRe­quest/)

  4: */

  5:

  6: //over­ride jQuery's de­fault IE<7 call for the Act­iveX ob­ject with stand­ard con­struct­or (avail­able to IE<7 via il­in­sky.com script)

  7: $.ajax­Setup({

  8:   xhr:func­tion(){re­turn new XM­L­Ht­tpRe­quest();}

  9: });

 10:

 11: (func­tion(){

 12:   var $links,//in-page ele­ments whose csr­f­Pro­tect param value needs up­dat­ing on ajax re­sponses 

 13:     b;//'?' or '&' de­pend­ing on if re­ques­ted URL already has params

 14:

 15:   //Store off nat­ive XM­L­Ht­tpRe­quest.open as XM­L­Ht­tpRe­quest.nat­i­ve­Open

 16:   XM­L­Ht­tpRe­quest.pro­to­type.nat­i­ve­Open = (func­tion(){

 17:     re­turn XM­L­Ht­tpRe­quest.pro­to­type.open;

 18:   }());

 19:

 20:   //Re­define XM­L­Ht­tpRe­quest.open to in­ter­cept and modi­fy re­quest

 21:   XM­L­Ht­tpRe­quest.pro­to­type.open = func­tion(){

 22:

 23:     var a=ar­gu­ments;//ori­gin­ally sup­plied ajax ar­gu­ments

 24:

 25:     //Mutate first in­stance (ini­tial re­quest) of XM­L­Ht­tpRe­quest with csr­f­Pro­tect prop­erty and value if 'csr­f­Pro­tect' class is found with­in the page

 26:     if(!this.csr­f­Pro­tect&&$('.csr­f­Pro­tect').length>0){

 27:       this.csr­f­Pro­tect=$('.csr­f­Pro­tect:eq(0)').val();

 28:     }

 29:

 30:     if(this.csr­f­Pro­tect){

 31:       a[1]=a[1]+(func­tion(){a[1].in­dex­Of('?')>0?b='&':b='?';re­turn b}())+'csr­f­Pro­tect='+this.csr­f­Pro­tect;//ap­pend csr­f­Pro­tect para­met­er and value to re­ques­ted url

 32:     }

 33:     this.nat­i­ve­Open(a[0],a[1],a[2],a[3],a[4]);//open re­quest

 34:   };

 35:

 36:   $(win­dow).ajax­Com­plete(func­tion(event,xhr,set­tings){

 37:     var csrf­Split=xhr.re­spon­se­Text.split('class="csr­f­Pro­tect" VALUE='),

 38:       csr­f­Value;

 39:     if(csrf­Split.length>1){

 40:       csr­f­Value=csrf­Split[1].split('>')[0];

 41:       this.XM­L­Ht­tpRe­quest.pro­to­type.csr­f­Pro­tect=csr­f­Value;

 42:     }

 43:     //up­date page links with latest csr­f­Pro­tect value

 44:     $links.each(func­tion(){

 45:       if(this.href){this.href=this.href.re­place(/csr­f­Pro­tect.*/,'csr­f­Pro­tect='+this.XM­L­Ht­tpRe­quest.pro­to­type.csr­f­Pro­tect);}//this re­place makes the as­sump­tion that csr­f­Pro­tect param and value are al­ways last in URL

 46:     });

 47:

 48:   });

 49:

 50:   //links

 51:   $(doc­u­ment).ready(func­tion(){

 52:     $links=$('a');//modi­fy this se­lect­or and $(win­dow).ajax­Com­plete lo­gic per ele­ments that need up­dat­ing

 53:   });

 54: }());

The sleep­er in this im­ple­ment­a­tion is Sergey Il­in­sky’s script, which not only ex­poses the XM­L­Ht­tpRe­quest’s pro­to­type prop­erty in IE but stand­ard­izes the ajax im­ple­ment­a­tion across all browsers. In the code above we take ad­vant­age of the jQuery wrap­per and meth­ods be­cause we’re work­ing in a jQuery shop. XM­L­Ht­tpRe­quest.js, however, gives us the same cross-browser ac­cess to ajax states that jQuery does. If we wer­en’t already in­cur­ring the jQuery over­head, we could achieve the same res­ults with some slightly raw­er JavaS­cript.

I’ve come to be­lieve in a trin­ity. To stand out, today’s apps re­quire tran­scend­ant visu­al design, front-end markup and script­ing, and backend ar­chi­tec­ture. I’m pas­sion­ate (and opin­ion­ated) when it comes to UI ap­pear­ance and have a healthy ap­pre­ci­ation for what con­sti­tutes re­spons­ible serv­er-side prac­tice. For the last sev­en years of my ca­reer, however, I’ve been de­voted to mak­ing the present­a­tion lay­er hap­pen with web stand­ard html, css, and JavaS­cript. Oth­er­wise put, a single ele­ment of the trin­ity has kept me oc­cu­pied full-time. And with the new html5, css3, ECMAscript5, and myri­ad frame­works sup­port­ing these, I’m con­fid­ent I could con­tin­ue my ded­ic­ated front end fo­cus without ever scrap­ing the bot­tom of the know­ledge bar­rel.

One of the com­ments on Car­son’s ori­gin­al blog post likened the evol­u­tion of web spe­cial­iz­a­tions to what’s happened in the med­ic­al field over the past fifty years.  It used to be that a sur­geon was a sur­geon; today we have heart sur­geons, brain sur­geons, left knee oth­o­pods, right knee oth­o­pods… While the de­gree to which this spe­cial­iz­a­tion needs to hap­pen is de­bat­able, spe­cial­iz­a­tion it­self is less so. As prac­tices and tech­no­lo­gies ma­ture so do the bod­ies of know­ledge that sur­round them, un­til even­tu­ally it be­comes too much to ex­pect that a single phys­i­cian or pro­gram­mer be ex­pertly pro­fi­cient across the spec­trum. Doc­tors be­come neur­o­lo­gists or rheum­at­o­lo­gists. Soft­ware de­sign­ers be­come UI de­velopers or backend en­gin­eers.

In the end it comes down to the level of care the pa­tient or cli­ent ex­pects. I’ve built end-to-end LAMP stack solu­tions that seem to per­form ad­equately. As a php/DB dilletante, however I know that the back end ar­chi­tec­ture of these sys­tems should be im­proved and will prob­ably hinder scal­ing ef­forts, for ex­ample, un­til the im­prove­ments hap­pen. I’ve like­wise worked in en­vir­on­ments where JAVA pro­gram­mers have been asked to as­semble and pro­gram User In­ter­faces. Here, the res­ult­ing prob­lem can ar­gu­ably be more ser­i­ous since design and in­ter­ac­tion blun­ders land dir­ectly in the user’s lap.

So when I think about per­fectly di­vid­ing web app labor (in a nimble or­gan­iz­a­tion) I have three people in mind. The first is Car­son’s afore­men­tioned ‘web de­sign­er,’ who is kick-ass in all things pho­toshop and il­lus­trat­or on top of be­ing a true visu­al artist. The second gets off on and is ex­pert at all things serv­er-side in­clud­ing DB design and im­ple­ment­a­tion, SQL, and php. Last is me do­ing the things I’m pas­sion­ate about and ex­pert at: UI and in­ter­ac­tion design, markup, css, and JavaS­cript. We move around in each oth­er’s ter­rit­or­ies and do bet­ter work in our own be­cause of this. But the concept of the trin­ity and its areas of ex­pert­ise un­der­pin beau­ti­ful, in­tu­it­ive, per­form­ant, scal­able, and main­tain­able ap­plic­a­tions. Now Car­son may well have at­trac­ted a su­per­star crew com­pris­ing the (ever) rare(er) kit­chen sink de­veloper. I simply don’t think the two-man team is gen­er­ally a vi­able pre­scrip­tion for well-de­signed ap­plic­a­tions. In my book it takes three. That is, un­til cross-chan­nel ini­ti­at­ives re­quire the stra­tegic per­spect­ive that a real UX Pro will of­fer…