Sarah Ward’s Blog

Blimey, keeping on top of this blogging thing is tough. It’s a week late, but here is the rest of my notes from the Future of Web Apps EXPO at London Excel on 3rd and 4th October 2007…

Facebook was mentioned a lot at the conference, and not surprisingly because it has become a very successful web app due to the varied applications a user can install that have been built with the Facebook API. Apparently 50% of Facebook users return to their Facebook homepage every day. There is an app called Scabulous that seemed quite popular with attendees and speakers at the conference. In fact 33% of Facebook users have it installed (not to self - must install and give it a try). There was also the putting down of Facebook and how it creates ‘false’ friendships. Well I am a user of Facebook, and I am under no illusion of the ‘fakeness’. By the way at this point I will say I have never had a MySpace page, perhaps its the snob in me, but I like the way in Facebook you can choose to control your profile and content with people you want rather than the whole world and his dog. I also think its great for finding people who you knew before it was common to have mobile phones. I have found some of my best friends from school on Facebook. I have a feeling this has also done for site such such as Friends Reunited. These sites rarely got updated by members and you had to pay a membership fee to contact someone, where as with Facebook you can just give them a quick poke.

Future of Web Apps prediction from speaker Om Malik: Increased access to email on mobile phones and devices.

The guys from Adobe not only had great presentations on the EXPO floor but were also allocated some time on the main Developer stage. On the Wednesday they did 10 Air/Flex real world web apps in 10 minutes:

1. http://www.sliderocket.com (web based presentation application)

2. http://www.scrapblog.com (scrap book builder)

3. http://www.picnik.com (uses HTML and Flash)

4. http://remix.mtv.com (engine by Adobe Premier Express)

5. http://preview.getbuzzword.com (Adobe liked this so much the bought it, an online wordprocessor and it all works inside the browser)

6. http://www.finetune.com (web streaming music on your desktop)

7. http://desktop.ebay.com (currently in beta)

8. http://labs.adobe.com/downloads/mediaplayer.html (Adobe’s Media Player)

9. http://pownce.com (Air application you can download rather than using the website)

10. http://www.aboutnico.be (Air application for Google Analytics)

Steve Souders presentation on High Performance Websites:

• IBM Page Detailer - Tool that shows developers client-side performance
• Less than 20% of the time is spent dealing with a page request on the server, the rest of the time is spent on the clients’ browser, so 80% to 90% is spent on the end user’s response time. This means the client side has a greater potential for improvement, its simpler to deal with and is proven to work.
• Research has shown than 50% of people come to a website with an empty cache, so it is important to optimise for both cached and non-cached users.

• Rules of best practice (items higher up the list reduces response time the most):

1. Make fewer HTTP requests.
2. Use a CDN (Content Delivery Network for static content).
3. Add an expires header.
4. GZIP components.
5. Put Cascading Style Sheets at the top.
6. Move Scripts to the bottom (browsers will evaluate the scripts before rendering the rest of the page).
7. Avoid CSS expressions.
8. Make JS and CSS external.
9. Reduce DNS lookup.
10. Minify JavaScript.
11. Avoid redirects.
12. Remove duplicate scripts.
13. Remove ETags.
14. Make AJAX cache-able.

• Another tip: set source of IFRAME’s using JavaScript. The onload event is delayed by 40-50ms until the IFRAME’s src responds.
• For more information check out the book ‘High Performance Websites’ (O’Reilly), Yahoo! User Interface Blog, and the Yahoo! Developer Network Blog.
• YSlow - This is an extension to the FireBug extension for Firefox that can help you measure performance and spot bottlenecks.
• Final thoughts - focus on the front end, harvest the low hanging fruit (what people say, eh), you DO control user response times, so be an advocate for your users and LOFNO (look out for number one)!

Dion Almaer in his presentation ‘How to take your app offline’ spoke about Google Gears and how it was, “a little more than just AJAX”. Consisting of 3 main parts: LocalServer, Database and WorkerPool. The WorkerPool allows you to run JavaScript jobs asynchronously in the background. Google Reader already works offline, and it is expected that more is to come, such as Google’s office suite and Google Mail. Read more at Dion’s website at Ajaxian.com.

Robin Christopherson’s presentation ‘The Art of Attractive Yet Usable Websites’ was really interesting and a real eye opener for someone who already understands accessibility issues and an understanding of best practices in relation to these issues because we got to see first hand what it was like for a vision impaired user to not only navigate using a screen reader (he was using IBM’s now defunct Home Page Reader) on websites, but also on an operating system. Here are some bits I picked up:

• It still takes users 20 minutes to get to the main content of Amazon as they still do not have skip to content navigation links. Nor do they have almost all the images in the navigation appropriately labeled with alt tags, so that the screen reader has to tell the user of each image reading aloud all the long filenames.
• Google Mail has a basic version of their core functionality for those using screen readers, and is completely JavaScript free.
• Google Maps has a screen reader friendly version, that hardly any one knows about - try it at http://maps.google.co.uk/?output=html
• Google has an audio alternative for those Catchpas on sign up forms, but are still misinterpreted. Alternatively they provide a helpline via email where they will contact you directly to setup your account if you are still having problems.
• Should include audio descriptions for rich media - demonstrated this using a scene out of star wars with audio description turned on.
• Showed the magnification tool that comes standard with Windows.
• Users are unable to increase text size easily because they don’t know where the functionality is hidden in the browser to do so
• A lot of sites that do allow users to increase the size of text do not allow for large text sizes properly in their layouts, causing text to overlay on top of each other and therefore unreadable.
• Some users choose to ignore website defined colours - Robin showed an example of this on The Apple website where turning off the colours cause some of the main heading to disappear.
• Moving, small target menus/links difficult to navigate to and/or click on and can cause problems for users with arm movement difficulties.
• Websites with bizarre tabbing order can be confusing.
• Problems with user generated content such as MySpace, use of tiled backgrounds, chosen colours choices etc are difficult to read and understand.
• Photosensitive Epilepsy Analysis Tool (PEAT) - Tool from the Trace Center helps developers identify content on their site that might induce seizures in some people.

‘Design for Web apps vs the web’ was Daniel Burka first public speaking presentation at a conference, and it was highly insightful into how they deal with user feedback on Digg and Pownce.

• Only make a change if it is worth it. Makes changes that will benefit the whole community rather than the one user.
• Know your community and stay in touch. Let them know about what bugs or features you are rolling out, and know when to admit when you have got it wrong.
• Measure success of changes, use focus groups and usability studies
• Gather feedback from a range of place: Positive feedback, negative feedback, bug reports, expert feedback and implicit feedback (watch how people use the site)
• How to react to feedback - first don’t do anything! Don’t rush in to change things.

Matt Mullenweg’s presentation on ‘The architecture behind wordpress.com’ did exactly what it says on the tin. He talked about scaling, the platform used, business, community and the people. The main part at the end was a warning not to hire someone you have doubts about.

Mathew Haughey’s ‘Building a community’ presentation was all based on the idea of “social is at the heart of todays web”. He believes that any site or app that you develop should include some form of social component. Problem is that there is a potential for a big disaster, but when it’s right it really becomes successful.

• Need to have a really compelling idea to begin with.
• Build the best app you can.
• “Eat your own dog food” - be the best user of your app.
• Highlight the best bits.
• Recognition helps too - give users who are really passionate about your app some level of responsibility.
• Get your best contributer to help moderate.
• Sometimes it is just best to get out of the way.
• Build it with some flexibility and allow unintended uses.
• Run it well with guidelines, not rules.
• Keep emotions out of decisions.
• Tailor to community norms, whatever they find comfortable.
• It’s a balancing act.
• Going to come across ownership issues, and every community suffers a revolt eventually.
• Customer service is important, and you may end up spending more time on this and coding.
• Hire help early on if you can.
• Use metrics to ease the workload.
• Avoid disaster by being transparent, have a place to talk about the app or site and (over) explain changes.
• Acknowledge mistakes.
• Be prepared for legal trouble. Some things are illegal in some places and not others. There will be many lawsuit threats, though actual lawsuits are few.
• Work out what’s stopping your app or site from building a community. Find a balance and build it to an even keel. Successful communities will create ‘friend revenue’.
• Need good “seed content” to get started and attract a community - highlight the best bits.

I really enjoyed Heidi Pollock’s presentation on ‘Taking your application mobile’, and I remember back in the day when we first were thinking about doing this kind of thing and how shit WML was. Well apparently it is still a struggle to design for mobile. Completely the reverse of how I thought things might be by now - though we no longer have to content with WML. Screens with resolutions of 176px wide and downloads of 10k maximum are the kind of restraints designing for mobile in mind currently have. Mobiles are not anywhere near as advanced as we expected them to be by now. Heidi comments that designing for mobile, “is like throwing a dart at a board and hoping it sticks”. She works for a company called BluePulse, which are currently tracking 3,000 mobile phones. With over 3,000 phones to deal with, you are bound to get errors on some of them. And access to mobile web application are generally not on high end phones.

Coding wise she recommends using XHTML 1.0 mobile - not 1.2, for markup and some basic CSS. Not all off CSS is supported. Don’t expect the code to validate and you will have encounter bugs on some phones. Opposite to what I previously believed, she abandons the idea of semantic web on the mobile platform because it rarely works. Headings are too large and ugly, taking up too much screen real estate, and lists take up to much space in the code. Recommends you stick to ems or small pixels for measurements. Other points raised include:

• Only bring to mobile what your users will use when they are ‘bored’ or actually need.
• Preserve your brand with colours and logos.
• Navigation links are overrated.
• Users prefer search rather than selecting from a 200 option dropdown menu. And not all dropdown menus well function the same on all phones.
• Never go above 16k for page downloads.
• During development produce a device list to test against, think like a phone, learn to live with how it works rather than what you would like it to do.
• Mobile acid test - similar to the browser acid test.
• Expect different behaviors on different phones, even on the same phone on different networks. (And you thought it was bad with Web Browsers )
• JavaScript and AJAX does not yet have a use case on mobile as it takes way too long to download and process with the bandwidth limits.

John Resig talked about the future of Firefox and some of the advances of JavaScript in his presentation on ‘Cross Platform User Interfaces’. Including:

• SVG support in Firefox
• Offline support
• Offline/Online detection
• XMLHttpRequesy++ (cross browser support)
• Desktop Integration
• Firefox 3 support for JavaScript 1.8, Firefox 4 may support JavaScript 2
• Tamarin - the three monkies: ActionMonkey, ScreamingMonkey and IronMonkey

Kevin Rose’s presentation ‘Lessons learned from launching a web app: The stories behind pownce’ were in really lessons learnt from setting up 3 start ups in 4 years. Key points were:

• Make sure you can scale your app easily from the start
• Memcached
• Hire a DBA to review database
• Hire an Admin to review apache configuration
• Work with the community
• Using invitation features such as importing contacts from address books has been important to their user growth
• Use icons that mean and are recognised by users, for example rather than using a mailto: link, use mail program icons instead
• Be transparent and blog what’s going on, improvements and changes
• When Digg was first lauched it was built using PHP, and then moved on to Python.
• Leah at Pownce was excited by Django and so gave it a try for the Pownce site
• Don’t go for VC funding untiyou have a working app
• Plan for success!

Live Diggnation filming was just Awesome!

Notes from day two to follow (sorry for the long post)…

This entry was posted on Monday, October 15th, 2007 at 1:11 pm and is filed under Conference, Web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.