improving front-end architecture

SRO! and I was out in the hall during break, so now I’m in the front row.

housekeeping, blah blah blah. I should be in the back, given how much I type, but I’ll just have to be light of fingers.

long I in Dimon, fyi.

investment in the future, for the long term. (hey, that sounds like my work!) takes more time to build something correctly.

short-term costs cross with long-term costs. I know all about those long-term costs! training others to know what’s in your head.

“nobody wants to go near it” (hmmm, I’m thinking about the crazy underlying code on a couple of projects….)

entropy! once it’s built it’s done: not true. ah, “total cost of ownership” broken window theory. less investment in fixing problems: and before you know it, it’s just trash.

stop and think: “what’s this going to cost me?”

myth of separation. to some extent it’s true, as an ideal…a target.

be looking for the simplest solution. example: the print stylesheet.

grid of typographic choices. considering the limitations of various options. oh, hey, that’s a great chart to print out and share. any time you want to have “beautiful headlines” you need to go through this sort of decision process. (rework that grid as a decision tree?)


Dallas Morning News. “if they didn’t have exclusive content on the Mavericks, I wouldn’t ever go there” can’t tell the difference between content & advertising. hard to click on the navigation items. code view: bleh! “heavy, ugly, hard to read”

contrast: NYT. “it feels like a newspaper” and the underlying code is easy to read.

and DMN hasn’t updated in ages, while NYT has been able to change.

myspace. craziest selector in custom(user) CSS I have EVER seen.

bubbles! all the elements of front-end design. backend bleeds into frontend.

useragents: touch of some of those. what you support influences how you construct your site. (on Pierce: IE 6 is close to 90%, Firefox is closing on 10%.) and “how much sleep you’ll lose”

“I, for one, welcome our browser overlords.” — knowing that IE 6 is going to take another 3 hours of our time. (sigh.)

but hey, it’s gotten better!

markup is the technical foundation. treat it like a craft. (hell yeah!) “is this really the right tag for this job.”

first front-end improvement: ditch the (layout) tables.

microformats…might not take off, but any time you invest in learning, the better your markup will be.

accessibility, and again markup is the foundation/root.

css also touches a few areas in the bubble chart.

the problems of browser hacks: what is the cost?

being bulletproof; go Dan C.! scaling. (always an issue with navigation, I think.) encouraging reading Dan’s book.

lots of crazy options.

scripting. oh, the dark days. (and one reason why I never quite got my brain around JS.) photo of Jeremy Keith & his book. now we can do clean beautiful things across browsers. renaissance! “can’t recommend this book (JK) enough.” (me too.)

and the libraries & frameworks. handcoding is like a hand tool (saw), libraries are a power tool (circular saw): powerful but potentially dangerous. (hm. I can’t use our circular saw at home, because it’s too damn heavy.)

not the best investment to use JS to make dropdowns look pretty. just because you CAN doesn’t mean you SHOULD. scripting is for behavior. is the font tag of DOM Scripting. 🙂 this.className! CSS where it belongs.

AJAX is what got him thinking about front-end architecture.

Jurassic Park quote! again, not thinking about “should”

traditional model graph. vs. partial page loads. quote from JK, about planning for AJAX from beginning, but implementing at end. Hijax.

response format options. XML, HTML, or JSON? know advantages & disadvantages. if API in place, maybe use XML (also: “pure”), etc. quirksmode article link.

macroom used 32 GB with AJAX instead of 196GB of bandwidth during live keynote. (how?)

accessibility & ajax? ideally, it would just work great. but screenreaders want to start at a page, read through, link, etc. (lather, rinse, repeat). keep an eye out!

accessibility. most people, first response: screenreaders. but it’s bigger than that! 2nd only to project management in areas that it touches.

reiterate…vision isn’t the only disability.

example, plazes. uses google maps to represent your friends, who’s nearby. “this map is never going to be accessible to someone who can’t see” and it becomes a contact issue. the addition (that they never implemented) is to include text that describes where your friends are in relation to you. and then use that content & microformats to generate the map info! (whoa.) is the content even on the page that people need access to. (remember this for the map discussion with Carolyn when I get back.)

labels are just the beginning. what happens with error messages? he’s working with featherstone to find the happy medium: accessible & attractive.

social responsibility. also legal? (it’s in our guidelines!) validators are only a start…too much that you have to *understand* to make right. example of color-blindness.

inherent benefits beyond… theoretically, better markup, usability (fitt’s law — do people know about clicking on label text?!), SEO.

design — softer topics. we can do more usable things than in the greenscreen days!

engineers vs. designers. (I *think* I tend to slip right in the middle there.) seeing the big picture.

“undesign is the new black” — ebay, craigslist, myspace. the right design for the job.

WaMu redesigned to look like craigslist? yipes! building trust involves the right design.

usability. user testing doesn’t necessarily get us what we need. lies, damn lies & stats. more important to understand the people. (one good reason to videotape.)

heat maps? isn’t it 80% common sense? don’t necessarily NEED these tools to get there.

(neilson) good info, but take w/grain of salt? why? because he’s so tunnel-vision.

IA. google news vs. google finance. design driven by content. prototyping choices. another one of those cool grids. includes “getting real”! what’s a PDD?

tagging in a bugtracker? crazy idea! (bad crazy) because this is an application that needs precision.

content: red-headed stepchild. (no sh!t) content dominoes: cool design, great IA, but yeah, yeah, yeah, we’ll drop the content in later, and it doesn’t fit! and you have to change everything else. (this is the reason that Don & I do greyscale.)

content will change. build pages that accomodate that.

flash. he doesn’t love it a whole lot, but it can fit in nicely. sIFR. takes tinkering, touches a lot of areas, but balances issues nicely.

backend. presentation layer. .Net tags output markup on their own. disconnects! engineers need to understand what happens.

elegant integration. “oh, wow, I’ll have this integrated in like 20 minutes.”

IA & content affect the database, presentation can effect (a/e?!) queries.

project mgmt. loosely related, but touches everything. managing change, costs.

need specialists, managing them and their “special egos” — need to take the objective view to make the right decision.

whole > sum(parts).

is the form project done? no. IE6 is the big problem.

selling accessibility? yes/no. if required: easy. if not: sell other benefits. clients latch on to SEO bennies. rarely is it a lot more expensive; easy just to do as you go w/out telling, and then you look good later.

web designer at a software co, engineers are all into agile design & think front-end design is archaic. help? it’s a conversation, showing articles, ongoing education. open the line of communication. spend more time with them. introduce them to 37signals concepts, because they combine “getting real” (agile-like) with a focus on design.