Developing for the WebDeveloping for the WebAleem Bawany

July 20, 2008

P@SHA Career Expo, Marriot Karachi

aleemb@gmail.com

OutlineOutlineDevelopment Methodologies

◦ Always beta; Iterative design; Top down design; Tools &

APIs.

AJAX

◦ Intro; Selling points; Good practices

Performance

◦ Caching; GZIP; Images etc

Usability

◦ Basic usability guidelines to adhere to

Development Development Methodologies: Always BetaMethodologies: Always Beta Develop early

Deploy early

Fail fast and cheap

Get early feedback

Benchmark performance

Develop Early…Develop Early… Don’t go out building a ship, build a boat first.

Web dev is cheap. Cheaper to fix bugs, cheaper to deploy,

cheaper to prototype, cheaper to test. Bigger community,

more tools, more source code.

If windows finds a bug, it has to ship a patch to millions of

PCs. It’s cheaper to spend a month testing the hell out of it

than to find a bug later. Hence the waterfall cycle and release

scheduling.

Gmail has fixed bugs in under 24 hours! That’s fast

turnaround.

Simplicity is beauty. Occam’s razor: Everything should be

made as simple as possible, but not simpler.

… … and Deploy Earlyand Deploy Early Doesn’t mean you deploy a half baked design.

Target a quicker launch. Features can come later. Deliver a

strong core product now.

You get early feedback. User feedback is a great motivator

and provides insight.

You can measure conversions & metrics early.

Fail fast. Failing fast is failing cheaply. If your drag and drop

widget layout gets a poor response, focus on higher yield

features. If it gets a good response, offer more

customization features.

DE & DE: Wrap-upDE & DE: Wrap-up Get things done economically.

Don’t neglect scale and performance.

What if initial design can’t scale? It’s a sign of success.

Good problem to have. Continually outgrow yourself.

Besides, designing for a million daily hits is diff from

designing for 10K.

Exceeding personal expectations is healthy. Realizing time

spent was not worth it is a bummer.

User Centric DesignUser Centric Design Developers like to focus on the architecture and neglect the

user.

Developers aren’t user friendly.

Linux is developer oriented. Great for students & techies but

lousy for everyone else (lawyers, chemists, parents,

accountants)

Apple, Microsoft spend millions on usability studies (v-buffer,

icon shadows, infinite edges etc). Users first, databases later.

Not a stipulation but please be considerate.

“Any sufficiently advanced technology is indistinguishable

from magic.” – Arthur C. Clark

Why AJAXWhy AJAX The web has been longing for it. Why refresh/repaint the

whole interface if the user wants to delete a single line (e.g.

delete mail in GMail).

Asynchronous overcomes the screen refresh problem.

JAvascript over comes screen repaint problem. DOM

updates small bits of UI on the fly. JS also facilitates async

plumbing.

XML enables data interchange. Being taken over by JSON

(more later)

AJAX HistoryAJAX History Netscape introduced LiveScript later named JavaScript (SUN

+ NS)

XMLHttpRequest was released as part of IE 5 (Mar, 1999).

Originally developed for Outlook Web Access 2000:

var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");

Freed JS to talk to the outside world

GMail and Google Maps brought this to the masses

Came to be labelled as AJAX and gained notoriety and gave

rise to a new breed of web apps

Neat hacks prior to XMLHttpRequest: Progressively rendered

GIF/iFrames to achieve similar affect?

The X in AJAXThe X in AJAX XML used as data interchange

XML to manage and manipulate data

Early demos used JS to render XML as HTML formatted pages

XHTML allowed the DOM to be predictable and proper

JSON is now preferred for many scenarios

JSON is intuitive and fast. Can pass objects between PHP/ASP/etc

and JS

XML has overheads: parsing, validating, converting to object,

updating in-memory XML Tree and converting back to XML string

Working with Person object simpler than an XML representation

AJAX is fastAJAX is fast AJAX requests are small. Can updates a single line instead

of the whole page. Granular updates.

The bigger the page, higher the performance gain.

Leads to better designLeads to better design Leads to better design. Server/Client decoupling. Web

Services model.

RESTful architecture simply works (GET/POST/PUT over

HTTP). No firewall issues etc.

Promotes good API design. GMail has a great web API.

Works cross-platform: to GTalk (Desktop client), Google ig

(Web), iPhone (OS X gadget), etc.

Has led to a lot of cross-browser libraries/APIs: Prototype,

JQuery, MooTools, Dojo, Scriptaculous (use

transitions/animations sparingly).

Fewer HTTP connections to server to download js/css only

once.

LimitationsLimitations AJAX request limited to current domain (just like cookies) to

avoid security hacks

Dynamically rendered/updated pages have no browser

history or bookmarking. Can be worked around using URL

fragments # which update URL without refreshing the page)

Web Crawlers cannot get to content (neither can email

harvesters)

AJAX DemoAJAX Demo Simple server/client (client.php, script.js)

JSON (emails.php, scriptc.js)

Prototype.js (Protoclient.js)

Performance (big ones)Performance (big ones) Use GZIP Compression

◦ .htaccess, ASP/PHP

◦ The web is mostly text data which is great for

compression

Smart Caching

◦ Leverage client caching (HTTP expires header)

◦ Use cached HTML instead of re-rendering ASP/PHP pages

If you aren’t doing these two and focusing on other

optimizations, you may want to reconsider

PerformancePerformance Be wary of JS memory leaks

Preloading images in the background (flickr). Performance is

client oriented (even though image may never be loaded).

Using caching and expiration smartly (set expire 10 years

ahead to utilize client caching)

Be wary of load order of page elements. Load content first

then focus on loading advertisements etc. Again, user-

centric design.

Optimize Images (JPEG quality, GIF color palette). Use

Progressive rendering. Break up large images into multiple

images (allows parallel loading)

UsabilityUsability Inverse pyramid writing style. Conclusion of article first, details

later

Page above screen fold (no scrolling required) is prime real

estate

Use live bread crumbs (live meaning they can be clicked)

Keep the information hierarchical and menus nested (organized

navigation will automatically promote organized design)

Users should know where they are, how they got there and

where they can go from here. Give users context.

Be wary of fonts faces, good use of white space, long lines

User friendly errors (users don’t understand .NET or SQL errors)

Wrap UpWrap Up Rethink the way you are developing web apps and target

quick a launch

Design should be user-centric

Start using AJAX

Evaluate and adopt a library (prototype.js). Build APIs

Start using compression (GZIP)

Use smarter Caching

Thank youThank you Contact me at aleemb@gmail.com

Slides will be sent via email

Please provide your email addresses. We won’t send more

than 2 emails to you asking you if you are interested in

continuing the discussion