Y! v. Y! Yahoo! Case Studies Across the Page

1
Y! v. Y! Yahoo! Case Studies Across the
PageApp Spectrum, One Size Does Not Fit All
Nate Koechley _at_Media 2006, London June 16th,
2006 nate_at_koechley.com http//nate.koechley.com/
blog
2
Y! v. Y! v. Y! Three Yahoo! Case Studies
Across the PageApp Spectrum, One Size Does
Not Fit All
Nate Koechley _at_Media 2006, London June 16th,
2006 nate_at_koechley.com http//nate.koechley.com/
blog
3
Nate Koechley
4
Its Pronounced Keklee
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
• Theres no shortage of better things to spend
  time on.

7
The DHTML Universeby Dojos 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
A bit of evolution over the years
1994
21
A bit of evolution over the years
1994
1995
22
A bit of evolution over the years
1994
1995
1997
23
A bit of evolution over the years
1994
1995
1997
2000
24
A bit of evolution over the years
1994
1995
1997
2000
2002
25
A bit of evolution over the years
1994
1995
1997
2000
2002
2004
26
A bit of evolution over the years
1994
1995
1997
2000
2002
2004
into the page that today welcomes 188m users
every month, 5.2 billion times
Source Comscore, Feb. 2006
27
The New Yahoo! Home Page

Video http//nate.koechley.com/talks/20060616_atm
edia/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 1Yahoo! Home Page Preview
Video http//nate.koechley.com/talks/20060616_atm
edia/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 2Yahoo! Photos Beta
Video http//nate.koechley.com/talks/20060616_atm
edia/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
• Worlds largest email provider
• Available in 21 languages
• Preeminent DHTML and Ajax Application

36
Case Study 3Yahoo! Mail Beta
Video http//nate.koechley.com/talks/20060616_atm
edia/mail_1.avi
37
do not worry not a product pitch
38
Common Goals
39
Common Goals1) Performance (x3)
40
Common Goals1) Performance 2) Interactivity
41
Common Goals1) Performance 2)
Interactivity3) Stay true to our beliefs
42
Common Approaches
43
The Basics
None
XHTML 1.0 Strict
HTML 4.01 Strict
Doctype
Quirks
Strict
Strict
Render Mode
Yes
Yes
Yes
CSS Sprites
No
Yes
Yes
Font-size Responsive
Yes
Yes
Yes
Keyboard
No
No
No
Absolute Pos
Yes
Yes
Yes
Minimization
Yes
No
No
Obfuscation
Yes
Yes
Yes
Compression
44
From Documents to Applications
45
PageApplication 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

46
PageApplication Spectrum
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 SpectrumTracking 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 EventsEvent Utilities

• Dont 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 EventsEvent 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 EventsLots and lots

• Objects can have many events
• Multiple keyboard listeners
• Downdrag
• Downkey
• Downdoubleclick
• Downclickkey
• More
• Multiple by countless number of objects!

54
Tracking EventsEvent 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 EventsEvent Delegation
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
56
Tracking EventsEvent Delegation
Event
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
57
More on Delegation

• Addressing Object Count
• Listen to document.onmousedown (native)
• Note which event.target (native)
• Addressing Handler Count
• Then delegate and attach the handlers you need,
  just in time.

58
Event Delegation Example

• Mousedown in vicinity of thumbnail
• If on ltimggt
• 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 photoItemsthis.index.mous
  edown()
• Where "this" is the thumbnail ltimggt clicked, via
  event.target/srcElement etc.

60
Tracking EventsEvent Delegation
Event
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
Obj
61
Tracking EventsDetails

• 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 SpectrumMemory 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, theres the
  potential for things to get out of hand.
• Goals
• Dont leak memory
• Also, keep overall memory footprint small
• Offer a quickly-responsive interface
• Stability

64
Memory ManagementGeneral Best Practices

• For each constructor have a destructor
• Create Objects
• Unhook
• Remove Handlers
• Remove References

65
Memory ManagementThree Approaches

1. Destruction (general best practice)
2. Conservation (niche)
3. Recycling (niche)

66
Memory ManagementDetails

• Conservation

• Destruction

• Destruction, but
• Recycle iframes (aboutblank)

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 SpectrumDelivering 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 CSSGeneral 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 lt/bodygt as possible.

70
Delivering JS and CSSThree Other Approaches

• 1) Many small files at once
• Enables atomic/team development
• Enables partial caching if parts change

71
Delivering JS and CSSThree 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 CSSThree Other Approaches

• 3) Inline in the ltheadgt
• Caching is not as effective as we imagine,
  especially on pages set as browser home pages

73
Delivering CSS and JSDetails

• 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 SpectrumData Format

1. Tracking Events
2. Memory Management
3. Delivering JS and CSS
4. Data Format
5. Pagination
6. Browser Support

75
Data FormatGeneral 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 FormatOther 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 FormatDetails
JSON rocks
We want to move to JSON
Were using some JSON, and will be much more
soon Recognize strengths of client and server
78
Looking Across the SpectrumPagination

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,
were so totally Web 2.0 now!!
80
Could does not equal should.
81
PaginationDetails

• 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 SpectrumBrowser 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?
84
http//developer.yahoo.com/yui/articles/gbs/gbs.ht
ml
85
Graded Browser SupportTwo 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 SupportGeneral 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)

87
http//developer.yahoo.com/yui/articles/gbs/gbs.ht
ml
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 SupportSummary

• 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 SupportDetails

• 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
Todays bad decisions will be tomorrows
constraints
97
Thank you. Questions?

• Nate Koechley
• natek_at_yahoo-inc.com
• http//developer.yahoo.com/yui
• http//yuiblog.com
• nate_at_koechley.com
• http//nate.koechley.com/blog
• This presentation is available at
  http//nate.koechley.com/talks/20060616_atmedia/at
  media2006.ppt http//nate.koechley.com/talks/20060
  616_atmedia/atmedia2006.pdf