Steve Souders - Yahoo Performance - High Performance websites
Posted by rmp at 12:13 3rd Oct 2007
The gist of this presentation was to perform accurate, scientific benchmarking of front- vs. back-end overheads up-front as a developer. This should be common-sense but I don't know *anyone* amongst my colleagues who does this proactively. It's almost always reactive as a result of performance problems post-release.
Steve presented a series of guidelines on streamlining content with the aim of improving performance. Some of these conflict a little in terms of common design practices (e.g. use of javascript/css frameworks). These guidelines are more-or-less what the YSlow Firebug plugin incorporates and in a nutshell look something like this:
fewer http requests
use a cdn
add an expires header
gzip components
put stylesheets at the top
move scripts to the bottom
avoid css expressions
make js and css external
reduce dns lookups
minify js
avoid redirects
remove duplicate scripts
configure etags
make ajax cacheable
split static content across multiple domains
reduce the size of cookies
host static content on a different domain
minify css
avoid iframes
Ref: YSlow firebug plugin!
Book: High Performance Websites
Blog: YUIBlog, YDNBlog
(0 comments)
Psyphi Blog v5
Dion Almaer - How to take your app offline
Posted by rmp at 12:16 3rd Oct 2007
So... caffeined and chocolate-brownied up and with a quick skim around the exhibition floor I'm back on the developer track and interested in what Dion has to say. I think he's going to be talking about AIR the Adobe integrated runtime flash platform. Maybe with some discussion of Microsoft's silverlight and the opensource moonlight which I came across last week.
So.. close. Google Gears is where it's at. I worry about the seemingly mass conversion from evil Microsoft to whiter-than-white Google. Were I choosing an offline platform for my web apps I'm really not sure I'd use Google. Yes, perhaps it's the usual conspiracy/FUD but I fear their power.
Anyway - however ubiquitous today's pervasive connectivity I think these frameworks will be critical in going forward. Hurray for SQLite!
Ref: GearsDB
Ref: GearsORM
Ref: GearShift - DB migrations for Gears
Local databases are great for performance but when the schema is upgraded your users need their local data migrated and their local databases modified. Sounds somewhat sticky to do in terms of web apps.
Ooh. Workerpools - hot - asyncrhonous / thread-like non-blocking semantics for heavy-duty client-side work. This looks great for offloading intensive calculation work from the server onto the client without interrupting the user-experience. I wonder how the cross-origin API stuff really works underneath. Sounds like cross-domain JSON to me, avoiding the single-domain security restrictions which 'real' AJAX enforces.
Syncing - Why is keeping data in sync *always* such a big problem? It seems to me that there has to be a simpler way to do this kind of stuff. On the surface these toolkits seem to work in a very similar way to svn + svk and they have the same conflict resolution problems. Most of the time syncing works ok but in the event of a conflict they'll largely throw all their toys out of the pram and sit there wailing until the user comes along to sort it out.
Could future technology based on this kind of stuff replace classical desktop applications? I think it definitely could for anything interactive. It absolutely makes sense to develop new applications using these toolkits as long as the conflict resolution is fixed and the online/offline data-store handling is transparent to the developer. (0 comments)
So.. close. Google Gears is where it's at. I worry about the seemingly mass conversion from evil Microsoft to whiter-than-white Google. Were I choosing an offline platform for my web apps I'm really not sure I'd use Google. Yes, perhaps it's the usual conspiracy/FUD but I fear their power.
Anyway - however ubiquitous today's pervasive connectivity I think these frameworks will be critical in going forward. Hurray for SQLite!
Ref: GearsDB
Ref: GearsORM
Ref: GearShift - DB migrations for Gears
Local databases are great for performance but when the schema is upgraded your users need their local data migrated and their local databases modified. Sounds somewhat sticky to do in terms of web apps.
Ooh. Workerpools - hot - asyncrhonous / thread-like non-blocking semantics for heavy-duty client-side work. This looks great for offloading intensive calculation work from the server onto the client without interrupting the user-experience. I wonder how the cross-origin API stuff really works underneath. Sounds like cross-domain JSON to me, avoiding the single-domain security restrictions which 'real' AJAX enforces.
Syncing - Why is keeping data in sync *always* such a big problem? It seems to me that there has to be a simpler way to do this kind of stuff. On the surface these toolkits seem to work in a very similar way to svn + svk and they have the same conflict resolution problems. Most of the time syncing works ok but in the event of a conflict they'll largely throw all their toys out of the pram and sit there wailing until the user comes along to sort it out.
Could future technology based on this kind of stuff replace classical desktop applications? I think it definitely could for anything interactive. It absolutely makes sense to develop new applications using these toolkits as long as the conflict resolution is fixed and the online/offline data-store handling is transparent to the developer. (0 comments)
Robin Christopherson (AbilityNet) - The art of attractive yet usable websites
Posted by rmp at 12:43 3rd Oct 2007
Now I think I've seen Robin talk before at either OSCON or Apachecon but it's always an incredible eye-opener to see simple use of a screenreader. Amazon.. how crap is that? That's a stunningly unusable site and it's far from being the only one!
How many developers do you know who actually have a screenreader installed on their development system for testing basic functionality?
Audio descriptions for multimedia & core content/functionality. Must recommend this back at basecamp for at least YourGenome .
Magnifier usage, perhaps something more of us have tinkered with, but usually only as a gimmick/toy not as critical to usability. Check your site's navigation again, but this time through magnifier.
Robin demonstrates a series of high-profile example websites almost all of which fail to meet accessibility requirements. I'm sure I'm as guilty as the next developer of not catering for these users but these are worldwide corporations with buckets of cash to throw at web design and who are immediately alienating a significant proportion of their users. Google comes out of the wash impressively well.
Push keyboard accessibility hard. All those HTML attributes we don't have time to put in are legally required. I'm sure there'd be a huge stink if/when high-profile legal cases start being brought against non-compliant services. (0 comments)
How many developers do you know who actually have a screenreader installed on their development system for testing basic functionality?
Audio descriptions for multimedia & core content/functionality. Must recommend this back at basecamp for at least YourGenome .
Magnifier usage, perhaps something more of us have tinkered with, but usually only as a gimmick/toy not as critical to usability. Check your site's navigation again, but this time through magnifier.
Robin demonstrates a series of high-profile example websites almost all of which fail to meet accessibility requirements. I'm sure I'm as guilty as the next developer of not catering for these users but these are worldwide corporations with buckets of cash to throw at web design and who are immediately alienating a significant proportion of their users. Google comes out of the wash impressively well.
Push keyboard accessibility hard. All those HTML attributes we don't have time to put in are legally required. I'm sure there'd be a huge stink if/when high-profile legal cases start being brought against non-compliant services. (0 comments)
Matthew Haughey (MetaFilter) - Creating and Running Communities
Posted by rmp at 17:00 3rd Oct 2007
Matthew offers a list of ideas and insights based on his personal experience of growing MetaFilter (12m pageviews/week on 2 servers btw) which I'm largely going to stuff in here verbatim.
Any site/app should include a social component - we're social creatures after all. Risks can be big but a successful community is great for everyone involved. Lifecycle - spike at initial launch then drop but slow growth afterwards with three outcomes - continued growth, steady userbase or decline e.g. when community builder leaves. High-level goal: "Be a third place" - home, work, pub/sports/virtual...
Have a compelling idea
Build the best app you can - people are familiar with a baseline set of tools & features
Eat your own dogfood - build for yourself first
Highlight the best - award contributors / power users; recognition helps the readers too. Moderators: your best contributors.
Get out of the way; Build in flexibility, allow unintended uses. Build out based on the edges.
Run it well - guidelines over rules, tailored to community norms; keep emotions out of decisions.
Ownership issues.
Ephemeral happiness. Every community has a revolt eventually.
Customer service - more time spent than coding
Hire others, early if you can
Metrics ease the workload
Be transparent. Have a place to talk about the site/app. Collaborative efforts for new features. Explain changes, over-explain. Acknowledge mistakes
Legal troubles. What's illegal and where? Limited liability, terms of service, privacy policy, digital millenium copyright act, etc. On the positive side, lawsuit threats are many, lawsuits are few.
What's stopping your site/app from building out a community? A successful community can please readers & creators alike. (0 comments)
Any site/app should include a social component - we're social creatures after all. Risks can be big but a successful community is great for everyone involved. Lifecycle - spike at initial launch then drop but slow growth afterwards with three outcomes - continued growth, steady userbase or decline e.g. when community builder leaves. High-level goal: "Be a third place" - home, work, pub/sports/virtual...
Have a compelling idea
Build the best app you can - people are familiar with a baseline set of tools & features
Eat your own dogfood - build for yourself first
Highlight the best - award contributors / power users; recognition helps the readers too. Moderators: your best contributors.
Get out of the way; Build in flexibility, allow unintended uses. Build out based on the edges.
Run it well - guidelines over rules, tailored to community norms; keep emotions out of decisions.
Ownership issues.
Ephemeral happiness. Every community has a revolt eventually.
Customer service - more time spent than coding
Hire others, early if you can
Metrics ease the workload
Be transparent. Have a place to talk about the site/app. Collaborative efforts for new features. Explain changes, over-explain. Acknowledge mistakes
Legal troubles. What's illegal and where? Limited liability, terms of service, privacy policy, digital millenium copyright act, etc. On the positive side, lawsuit threats are many, lawsuits are few.
What's stopping your site/app from building out a community? A successful community can please readers & creators alike. (0 comments)
Heidi Pollock (BluePulse) - Taking Your Application Mobile
Posted by rmp at 17:40 3rd Oct 2007
Interesting resume of experience in terms of mobile devices and development covering Yahoo and Twitter as a background to the "in my experience"-style points.
The biggest growth in mobile use is in places like Africa, far east on a range of low-end, (ugly) phones. A big misconception about mobile web use is that most users are high end and this doesn't hold up in real experience.
About 3000 phones, all with different browsers - every one's unique. So baseline targetted is 176px and 10k page weight limit.
Ref: WURFL
e.g. Arguably the most popular is the Motorola v3 8 lines * 30 characters. For multilingual sites, e.g. German, words can become unworkably long.
Code should be limited to basic XHTML Mobile 1.0 and basic CSS. WML is unworkable (memory limits etc.) unless you know your targetted community is largely WML. Notably missing from XHTML Mobile are things like headings and lists. Semantic Web ideals tend not to stand up. As CSS doesn't work all the time then it can't be relied upon to do things like unindenting lists.
Recommended, appropriate tools: Firefox extensions: Modify headers, user agent switcher, WML Browser, XHTML Mobile Profile.
Users are bored or in need. Preserve your brand with logo, colours & copy. Navigation links are overrated - replace dropdowns with search/autocomplete etc.
Development tips: Target a device list; think like a phone; learn to live with it; mobile acid test http://jwtmp.com/a (0 comments)
The biggest growth in mobile use is in places like Africa, far east on a range of low-end, (ugly) phones. A big misconception about mobile web use is that most users are high end and this doesn't hold up in real experience.
About 3000 phones, all with different browsers - every one's unique. So baseline targetted is 176px and 10k page weight limit.
Ref: WURFL
e.g. Arguably the most popular is the Motorola v3 8 lines * 30 characters. For multilingual sites, e.g. German, words can become unworkably long.
Code should be limited to basic XHTML Mobile 1.0 and basic CSS. WML is unworkable (memory limits etc.) unless you know your targetted community is largely WML. Notably missing from XHTML Mobile are things like headings and lists. Semantic Web ideals tend not to stand up. As CSS doesn't work all the time then it can't be relied upon to do things like unindenting lists.
Recommended, appropriate tools: Firefox extensions: Modify headers, user agent switcher, WML Browser, XHTML Mobile Profile.
Users are bored or in need. Preserve your brand with logo, colours & copy. Navigation links are overrated - replace dropdowns with search/autocomplete etc.
Development tips: Target a device list; think like a phone; learn to live with it; mobile acid test http://jwtmp.com/a (0 comments)
Mark Quirk (Microsoft) - 7 Things You Probably Don't Know About That You Can Use in Your Future Web Apps (for FREE)
Posted by rmp at 22:13 3rd Oct 2007
Microsoft Virtual Earth w/ interactive sdk http://www.microsoft.com/virtualearth/
Popfly snappy mashup graphical code generator rather like Pipes
Visual Web Developer, SQL Server 2005 http://msdn.microsoft.com/express
Python and Ruby on .net http://www.codeplex.com/IronPython/ http://rubyforge.org/projects/ironruby
Live Alerts: http://signup.alerts.live.com/brochure/ email, IM, mobile alerts
Silverlight streamed apps & videos
Astoria online database web services
Seadragon: http://labs.live.com/Seadragon.aspx large virtual screen. Impressive. (0 comments)
Popfly snappy mashup graphical code generator rather like Pipes
Visual Web Developer, SQL Server 2005 http://msdn.microsoft.com/express
Python and Ruby on .net http://www.codeplex.com/IronPython/ http://rubyforge.org/projects/ironruby
Live Alerts: http://signup.alerts.live.com/brochure/ email, IM, mobile alerts
Silverlight streamed apps & videos
Astoria online database web services
Seadragon: http://labs.live.com/Seadragon.aspx large virtual screen. Impressive. (0 comments)
Dave Morin (Facebook) - The story behind the Facebook platform
Posted by rmp at 11:57 4th Oct 2007
Dave's engaging and talking fast so more commentary and less transcription this time.
Facebook is an impressive example of social networking success. Apparently incredible growth, doubling every 6 months with near 50% users returning every day.
Facebook is about enabling mapping of the social graph. The power of the social graph enables near viral transfer of functionality and features. Facebook photos has nearly twice the traffic of all the other photo sites combined.
The Facebook platform aims to allow developers to create applications which leverage and add context to the social graph via deep integration with the platform. Like so many other apps presenting here, it all hinges on open APIs and transparent, open data access.
The Facebook opportunity chain looks something like this: Innovation, growth, engagement, monetisation. (0 comments)
Facebook is about enabling mapping of the social graph. The power of the social graph enables near viral transfer of functionality and features. Facebook photos has nearly twice the traffic of all the other photo sites combined.
The Facebook platform aims to allow developers to create applications which leverage and add context to the social graph via deep integration with the platform. Like so many other apps presenting here, it all hinges on open APIs and transparent, open data access.
The Facebook opportunity chain looks something like this: Innovation, growth, engagement, monetisation. (0 comments)
John Aizen & Eran Shir (Dapper) - Practical Semantic Web (web plumbing 101)
Posted by rmp at 00:08 5th Oct 2007
TBL once said "in the future everyone will write semantically correct websites" but the vision of a world of personalised agents has not come about. Largely things failed to take off because making things semantically correct is expensive - it requires effort.
Luckily current web apps are changing this with APIs, content distribution & aggregation and meaningful search.
How has this come about?
- The Feed
- Light, easily adopted technologies: e.g. REST vs. SOAP; AJAX vs. Server-side; Microformats vs. RDF+OWL
- Increasing openness, encouraging mashups via APis and low-effort semantics
Introducing Dapper: Creating APIs for other websites, mostly community-generated. The users have the time and incentive. Dapper extensions can then be reused as services on top of other platforms, e.g. Pipes, Google gadgets & Facebook.
Example: Semantically linked advertising, e.g. a loaded shopping cart built on a recipe page.
Example: Meaningful search w/ results dissected enabling search, drill-down and filtering by automatically indexed categories
Dapper attempts to address the serious issues of fragility commonly associated with classical screen-scraping using elements of graph theory and community power.
Dapper also incorporates the gamut of CC licensing to better enable site-owners to control their content whilst boosting consumer confidence in reliability of data. (0 comments)
How has this come about?
- The Feed
- Light, easily adopted technologies: e.g. REST vs. SOAP; AJAX vs. Server-side; Microformats vs. RDF+OWL
- Increasing openness, encouraging mashups via APis and low-effort semantics
Introducing Dapper: Creating APIs for other websites, mostly community-generated. The users have the time and incentive. Dapper extensions can then be reused as services on top of other platforms, e.g. Pipes, Google gadgets & Facebook.
Example: Semantically linked advertising, e.g. a loaded shopping cart built on a recipe page.
Example: Meaningful search w/ results dissected enabling search, drill-down and filtering by automatically indexed categories
Dapper attempts to address the serious issues of fragility commonly associated with classical screen-scraping using elements of graph theory and community power.
Dapper also incorporates the gamut of CC licensing to better enable site-owners to control their content whilst boosting consumer confidence in reliability of data. (0 comments)
Atom
