1

Y! v. Y! Yahoo! Case Studies

Across the Page—App Spectrum, One Size Does Not Fit All

Nate Koechley – @Media 2006, London – June 16th, 2006

nate@koechley.com | http://nate.koechley.com/blog

2

Y! v. Y! v. Y! Three Yahoo! Case Studies

Across the Page—App Spectrum, One Size Does Not Fit All

Nate Koechley – @Media 2006, London – June 16th, 2006

nate@koechley.com | http://nate.koechley.com/blog

3

Nate Koechley

4

It’s Pronounced “Kek’lee”

5

Hello, World

• Nate Koechley

– At Yahoo! since 2001

– Charter member of Web Development team

– On Yahoo! User Interface Library (YUI) team

• Three roles:

– Senior Frontend Engineer

– Technical Evangelist

– Design Liaison

6

Yahoo! User Interface Library (uh, thanks Simon)

• A la carte– Event ~ 2k

• onAvailable

• Custom Events / Pub-Sub

– DOM ~ 3k• Add/replace Class

• Utilities vs. Controls, also CSS

• “There’s no shortage of better things to spend time on.”

7

The DHTML Universeby Dojo’s Alex Russell (work in progress)

http://alex.dojotoolkit.org/DHTML_universe.pdf

8

12345678

9

12345678

10

12345678

11

12345678

12

12345678

13

12345678

14

12345678

15

12345678

16

A Great Community at Yahoo!

17

Praise Them, Blame Me

18

You?

19

OK then, a quick history:

20

1994

A bit of evolution over the years…

21

1994

1995

A bit of evolution over the years…

22

1994

1995

1997

A bit of evolution over the years…

23

1994

1995

1997

2000

A bit of evolution over the years…

24

1994

1995

1997

2000

2002

A bit of evolution over the years…

25

1994

1995

1997

2000

2002

2004

A bit of evolution over the years…

26

1994

1995

1997

2000

2002

2004

…into the page that today welcomes 188m users every month, 5.2 billion times

A bit of evolution over the years…

Source: Comscore, Feb. 2006

27

The New Yahoo! Home Page

Video: http://nate.koechley.com/talks/20060616_atmedia/fp_2.avi

28

It is immensely telling that the new Yahoo! homepage

is a DHTML homepage.

29

“Getting It Right The Second Time”

30

Three Case Studies

31

Case Study 1:

• History

– “Preview” release exactly one month ago today

– From scratch

– Newest development effort to be released

• Massive Scale

– 5.2 billion views per month

– 188 million unique users

• Major DHMTL and Ajax Implementation

32

Case Study 1:

Yahoo! Home Page Preview

Video: http://nate.koechley.com/talks/20060616_atmedia/fp_2.avi

33

Case Study 2:

• History

– Beta release exactly eight days ago

– From scratch

– Long development timeline

• Massive Scale

– 30 million unique users

– 2 billion photos

• Major DHTML and Ajax Implementation

34

Case Study 2:

Yahoo! Photos Beta

Video: http://nate.koechley.com/talks/20060616_atmedia/photos3_2.avi

35

Case Study 3:

• History– Beta release about one year ago

– Legacy-ish, was Oddpost.com

– Oddpost development began in 1999

• Massive Scale– World’s largest email provider

– Available in 21 languages

• Preeminent DHTML and Ajax Application

36

Case Study 3:

Yahoo! Mail Beta

Video: http://nate.koechley.com/talks/20060616_atmedia/mail_1.avi

37

do not worry – not a product pitch

38

Common Goals:

39

Common Goals:

1) Performance (x3)

40

Common Goals:

1) Performance 2) Interactivity

41

Common Goals:

1) Performance 2) Interactivity3) Stay true to our beliefs

42

Common Approaches:

43

The Basics

NoNoNoAbsolute Pos

YesYesYesCompression

YesNoNoObfuscation

YesYesYesMinimization

YesYesYesKeyboard

NoYesYesFont-size Responsive

YesYesYesCSS Sprites

QuirksStrictStrictRender Mode

NoneXHTML 1.0 Strict

HTML 4.01 Strict

Doctype

44

From Documents to Applications

45

Page—Application Spectrum

• Historically Web

• Shallow Interaction

• Simple Idioms

• For Consumption

• Markup + Skin

• Sequential Nav

• Passive

• Historically Desktop

• Deep Interaction

• Powerful Idioms

• For Productivity

• JS, DHTML, Ajax, DOM

• Self Contained

• Active

ApplicationApplicationPagePage

46

Page—Application Spectrum

ApplicationApplicationPagePage

47

Looking Across the Spectrum

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

48

Looking Across the Spectrum:Tracking Events

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

49

From Page-Granular to Event-Granular Interfaces

50

Tracking Events:Event Utilities

• Don’t piss off the DOM Scripting Task Force– No JS in attribute space / markup!

• Watch out for memory leaks!!! (yes, three !’s)

• Many great utilities– YUI Event Utility

– Dojo

– Scott Andrew

– many more…

51

Tracking Events:Event Attachment

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

52

Browsers die when there are too many (objects + listeners)

53

Tracking Events:Lots and lots

• Objects can have many events:

– Multiple keyboard listeners

– Down+drag

– Down+key

– Down+doubleclick

– Down+click+key

– More…

• Multiple by countless number of objects!

54

Tracking Events:Event Delegation

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

55

Tracking Events:Event Delegation

Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj

56

Tracking Events:Event Delegation

Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj

Event

57

More on “Delegation”

Addressing Object Count1. Listen to document.onmousedown (native)

2. Note which event.target (native)

Addressing Handler Count

3. Then delegate and attach the handlers you need, just in time.

58

Event Delegation Example:

• Mousedown in vicinity of thumbnail

– If on <img>

• If MouseMove

–Assign Drag and Drop

– If on whitespace

• If MouseMove

–Assign Selection Rectangle

59

Event Delegation Example:

• Is the click on a photo thumbnail?

• If so, delegate to its related Javascript controller object eg: photoItems[this.index].mousedown();

• Where "this" is the thumbnail <img> clicked, via event.target/srcElement etc.

60

Tracking Events:Event Delegation

Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj

Event

61

Tracking Events:Details

ApplicationApplicationPagePage

•Few Objects with Simple Handlers

•Event Attachment

•Many Objects w/ Multiple Handlers

•Event Delegation

•Many Objects w/ Multiple Handlers

•Event Delegation

62

Looking Across the Spectrum:Memory Management

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

63

Memory Management

• With extensive DOM and JS work, there’s the potential for things to get out of hand.

• Goals:

– Don’t leak memory• Also, keep overall memory footprint small

– Offer a quickly-responsive interface

– Stability

64

Memory Management:General Best Practices

For each constructor have a destructor

1. Create Objects

2. Unhook

3. Remove Handlers

4. Remove References

65

Memory Management:Three Approaches

1. Destruction (general best practice)

2. Conservation (niche)

3. Recycling (niche)

66

Memory Management:Details

ApplicationApplicationPagePage

•Conservation

•Destruction

•Destruction, but…

•Recycle iframes (about:blank)

67

Memory Management Tip:

• Measure and Test

– Drip is a great tool

– Test extreme object counts

– Test long interactions

– Test extensive navigation

68

Looking Across the Spectrum:Delivering JS and CSS

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

69

Delivering JS and CSS:General Best Practices

• A single large file loads fastest.

– HTTP requests are the nemesis of a well-tuned site.

– Build process is, therefore, very important.

• CSS files as close to the top as possible.

• JS files as close to </body> as possible.

70

Delivering JS and CSS:Three Other Approaches

1) Many small files at once

– Enables atomic/team development

– Enables partial caching if parts change

71

Delivering JS and CSS:Three Other Approaches

2) Many small files on demand

– Some demanded functionality may be subtly slower

– Allows tuning in response to use cases and task analysis

72

Delivering JS and CSS:Three Other Approaches

3) Inline in the <head>

– Caching is not as effective as we imagine, especially on pages set as browser home pages

73

Delivering CSS and JS:Details

ApplicationApplicationPagePage

•Many smaller files, on demand. Some inline.

•Every feature not used every time. Content is key.

•Uber file of interface JS/CSS. Pay once.

•Objects/data on demand

•Single File (anti-example)

•Functionality is key. Highly interconnected.

74

Looking Across the Spectrum:Data Format

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

75

Data Format:General Best Practice

• Use JSON for data interchange

– Natively understood

– “The fat-free alternative to XML”

• http://www.json.org

– Tools in every known programming language

76

Data Format:Other Approaches

• Somebody is going to have to pay the CPU price to render the View– Faster to pass a string that expresses a DOM state

directly than trying to parse and create on the fly.

– Consider client and server in tandem when making architectural choices

• Parsing XML degrades performance greater-than-linearly as XML size increases.

77

Data Format:Details

ApplicationApplicationPagePage

“JSON rocks”

“We want to move to JSON”

“We’re using some JSON, and will be much more soon”

Recognize strengths of client and server

78

Looking Across the Spectrum:Pagination

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

79

“Ajax is awesome!! Hmmm, I know: we can do

pagination without refreshing the page!!

Sweet, we’re so totally Web 2.0 now!!”

80

Could does not equal

should.

81

Pagination:Details

ApplicationApplicationPagePage

•Single page, so basically not applicable.

•Some Ajax pagination in Personal Assistant module

•Heavy Objects

•Ajax Pagination; No refresh but new collection.

•Light Objects

•Endless-scrolling (and clever caching)

82

Looking Across the Spectrum:Browser Support

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

83

Which browser to support?

84http://developer.yahoo.com/yui/articles/gbs/gbs.html

85

Graded Browser Support:Two Key Ideas

1) Support does not mean “the same”

“Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web.”

2) Support must not be binary!

86

Graded Browser Support:General Best Practice

• 3 Grades of Browser Support

C-grade support (core support, 2%)

A-grade support (advanced support, 97%)

X-grade support (the X-Factor, 1%)

87http://developer.yahoo.com/yui/articles/gbs/gbs.html

88

A bit about browser stats…

89

A bit about browser stats…

• More 5.0 than 5.5;

– We consider 5.0 C-Grade

• Note by-country skews

• Note by-content skews

• IE7 already moved the needle

– Historically, SP2 rollout out very quickly

90

Browser as Development Environment?

91

Browser Support:Summary

• Still a huge pain in the ass.– The Web is the most hostile software

engineering environment imaginable. (Douglas Crockford)

• Same answer for everybody.– Develop to standards, then patch.

• Maintain discipline in the face of heterogeneity.

92

The price is always higher to say “no” to Safari and Opera

93

Browser Support:Details

ApplicationApplicationPagePage

•GBS A-grade

•Developed in Gecko

•GBS A-grade

•Developed in Gecko

•IE and FF

•Developed in IE, then built IE-emulation layer.

94

We're in this for the long haul.

95

Quality is OUR job. Be belligerent.

96

Today’s bad decisions will be tomorrow’s constraints

97

Thank you. Questions?

Nate Koechley– natek@yahoo-inc.com

• http://developer.yahoo.com/yui

• http://yuiblog.com

– nate@koechley.com• http://nate.koechley.com/blog

This presentation is available at http://nate.koechley.com/talks/20060616_atmedia/atmedia2006.ppt http://nate.koechley.com/talks/20060616_atmedia/atmedia2006.pdf