Presenters :

• Amy Hoy @amyhoy
• Thomas Fuchs @thomasfuchs

Sites:

• http://mir.aculo.us
• http://slash7.com/about/

photo credit: Chris Shiflett

A quote from Thomas Fuchs’ site… “You’re using my work every day, even if you’re not aware of it”. Thomas is the author of http://script.aculo.us and working group member of prototype.  Funnily enough williegoosen.com uses mootools, which uses prototype.  Amy has also made some rather cool tweet walls http://twistori.com/ and more recently http://letsfreckle.com/ a time sheeting app.

So I knew there were some tricks, having spent some time with ySlow in the weeks before, but was enlightened by the simple techniques that make a lot of difference.  Amy and Thomas did a great job of tag teaming through a rather dry subject and made it rather interesting, with one of the team walking through the slides and the other answering questions on a chat room style back-channel.

The talk started off with one of the rules being “only fix it if you need to” which i suppose makes a lot of sense. Tweaking performance can be a real fickle business, but if the users aren’t happy you have to fix it quick!

Test, don’t guess. benchmark. Make sure you can quantify the issue before you attempt any fixes so you can measure your improvement.

In some cases it will just be impossible to please your users but there are ways to keep people engaged and let them feel you are not ignoring them, while doing the heavy lifting in the background.

Main areas of focus
Loading -  connecting/spinning wheel, back-end speed, dns, latency * easiest win*.
Rendering - white screen of death, you can see items still loading in the status bar.
Execution - site stops responding after is completely rendered.

But to be honest there were just so many “oooh I should be doing that”, “woops shouldn’t be doing that” moments I will try and capture a bunch of them. Non-techy people can stop reading here.

Do’s

• Simple html = simple dom = faster rendering.
• Use yslow and dommonster to identify issues.
• JS scripts at the bottom of your pages.
• Keep external assets to a minimum.
• Set content expiry time frames correctly in the headers.
• Yuicompressor + gzip to reduce .js .css .html size x5 smaller http://refresh-sf.com/yui/.
• Merge .js files into a single .min.js file see http://getsprockets.org/ and http://dailyjs.com/2010/01/27/pro-practices-1/.
• Reduce image size with http://smush.it 30% size reduction no loss.
• Far future cache-headers (resolve updates issues by replacing with new file names).
• Multiple asset hosts – assets on separate hosts than HTML allows for concurrent downloading.
• Focus on whats important to users, webapps(gmail) focus on executing where as static pages (google search) focus on loading/rendering real fast.
• Only HTML and maybe analytics JS should be load in subsequent loads rest should be cached.

Dont’s

• JS in the middle of a page will block the execution of the whole page until its finished running, and can leave the user looking at an unrendered page.
• 404 requests really hurt.
• Avoid slow external assets \ 3rd party libs.
• Watch out for weight of frameworks, try microframeworks instead see underscore.js and emile.js.
• Frameworks and widgets are frowned upon but if you have to script.aculo.us and jquery were mentioned

Interesting

• Cool animation on how browser renders components does multiple sweeps over content to do the layout see http://en.boose.gr/gecko-reflow/.
• Other open tabs can affect your sites performance or crash the whole browser.
• -webkit-transforms are fast and very cool 2/3d stuff at 30-60fps for used on iphone and some android phones similar in jquery animation would be 5-10 fps.
• If it takes long in real life to do something you could get away with a bit of lag, moving between forms and search should be instant.
• Too many page assets becomes a performance hit conciser 3-5 streams for asset downloads being the default in a browser and will require cueing if more assest are required.
• Dynatrace http://ajax.dynatrace.com/ IE tool for testing page loading.

“Silence of more than four seconds become embarrassing because that implies a breaking of the thread of communication.” RB Miller(1968)

And if the conversations is still not happening after all the tuning, then its time to fake it!

• Perception is critical.
• Tell people how long it will take – visual indication of progress can increase patience up to 5x.
• User should feel like they are heard and their input is being considered.
• Instant reaction even if action takes longer for action to complete.
• Never leave the user bored.

Presenter: John Resig
Twitter: @jeresig
Site: ejohn.org
Lead Developer and creator of jQuery, and a JavaScript Evangelist at Mozilla

photo credit: drewm

Second day of workshops at Webstock 2010 was first time i had a look at jQuery, i have had a play with script.aculo.us and mootools in the past, so jumped at the thought of a workshop with a creator of such a frame work, as they make JavaScript sooo much more bearable, especially for someone with a Java background.

My respect only grew for John as he did a 3 hr live demo of jQuery  and jQuery UI, with only one minor hiccup which he fixed within minutes….. a true JavaScript ninja.

In essence jQuery it looked as simple as this:

• Find object
• Do something with the set

Couple of bits that got me interested:

• Lots of people agree jQuery is awesome, its used by Microsoft, Google, Mozilla, IBM, Amazon, HP, Intel, Ruby on Rails, WordPress, Django
• Selectors uses CSS like syntax
• Good looking, easy to read documentation that has recently been reviewed
• Fails gracefully, if you layer jQuery over and already functioning website
• Big community and plugins(use with care)

My rough notes on the presentation on the points that stood out to me, for the full presentation see the link at the bottom of the page.

Finding things

• CSS Selectors with some special selectors like :first :hidden etc
• jQuery Methods
• Both are methods used for traversing the DOM
• Can be chained together 
  

  $("div").hide().css("color","blue");

• Chained Traversal ( pretty cool )

  $("button")
    .parent().css("border", "3px solid red")
    .siblings().css("border", "3px solid green");

Doing Things

• Manipulation
• Event handling(normally user actions)
• Live Events for current and future elements(ajax)
• Effects .animate ( pretty nice )
• Helpers to load xml,  json or html with ajax

Plugins

• Strong Community
• Recomended ones were
  • jQuery UI
  • Validation
  • Ajax Form
  • jqGrid
  • jQuery Tools
• Themeroller – mechanism to style jQuery UI

Tips

• Write in HTML first then layer jQuery over the top
• Apply your jQuery to a fully functional site, this way if JavaScript fails your site is still fully functional
• “return false” Disables the default old behavior
• With server-side code, add conditional to check it the “ajax” header is present, if so strip off header and footer code and only display id=content, to reduce server traffic
• Look at using jquery off CDN minimised and gziped optimized – on Google’s CDN, if its good enough

As a round up I would definitely consider using jQuery on my next project, as with all frameworks im sure there will be some limitations as this kind of ease of use doesn’t come without trade-offs.

The full presentation can be found here http://ejohn.org/apps/workshop/intro/

Presenter : Chris Shiflett
Twitter: @shiflett
Site: shiflet.org / analog.coop

photo credit: Chris Shiflett

Security is always a hot topic, and in today’s world it’s always good to have a fresh look at web security on the first day of the Webstock 2010 workshops. Chris Shiflett is currently part of a web development co-op Analog and has a keen interest in PHP and web security.  He is also a webstock veteran and author of Essential PHP Security.

At risk of missing any of the important points, please check out the full presentation at the end of my notes.

Fundamentals

• Defense in depth, use all safeguards available, use owasp.org.
• Least privilege, lock the system down as much as possible.
• Least complicated, complexity allows mistakes to happen.

Golden Rule, ok more like a golden acronym – FI EO

• Filter input – ensure any inputs are what you expect and no more.
• Escape output – ensure data going out is not misinterpreted.

List of common exploits

• Cross-Site Scripting – an XSS flaw occurs whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites and possibly introduce worms.
• Cross-Site Request Forgeries – a CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
• SQL Injection – injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.
• Session Fixation – attempt to exploit the vulnerability of a system which allows one person to fixate (set) another person’s session identifier.
• Session Hijacking – session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.
• Email Injection – similar to SQL injection.
• Remote Code Injection – similar to SQL injection.

In a lot of  these attacks it is rather trivial to get the basics right by following the golden acronym FIEO, but all posible defences should be used for defence in depth.  The full presentaion goes into the ways to “Stop It”. Also do your own research to pick up on latest trends.  A rather concise resource was mentioned by @nzrob see www.owasp.org Top 10 vulnerabilities which gives large amount option to protect your application.

The full presentation can be found here,  http://shiflett.org/evolution-of-web-security.pdf.

Tips

• Specify character encoding and make sure it is consistant from front to back end.
• Get users to reconfirm password for important actions like changing password.
• Good understanding of http and session management helps with prevention.
• Keep source code short and concise.  Complexity breeds flaws.
• Human peception can also lead to perceved security breaches – see SmugMug example.
• Host static files on separate subdomain to limit session token exposure.

Final thoughs were around trending of user behaviour to identifying abnormalities and maybe using something like https://panopticlick.eff.org/ for uniquely identifying users from bots.

Chris did an excellent job in presenting the information in an easily ledgible format and good concrete examples. I am gutted I prioritised another talk over his “Security-Centered Design” talk at the Webstock conference but I’ll be sure to catch up on it when the video is available and post the link here if I remember.

Be Safe :)

Derek Featherstone
Real world Accessibility for Ajax and Web Apps
Sites : www.boxofchocolates.ca www.furtherahead.com

Right so i got caught out by the title like the typical buzzword try-er-outer. So first thing i read going through the workshops, was …. AJAX. So wow that’s like so now and everyone is doing it so the more AJAX the better right?

Upon closer inspection the workshop was more around the _accessibility_ part. And the first 10 min I thought whoops not quite what I intended to spend a day on, but i was captivated after the intro.

Quick key points
1. Forms
- Watch out for Visual labeling, use element
- “em” inside the “label” and position with CSS
- Replace “em” with a “strong” if its an error.
- Plan error/advisory information carefully (keep in flow or shift focus to it if not in flow)
- Dual purpose interfaces can cause issues.

2. Linear Flow
- feedback on an action should be where your focus is going
- have elements linear in HTML and position with CSS for visual organisation

3. Proximity
- when injecting content with ajax place do so in context.
- avoid injecting content at the end of the document if possible
- best yet avoid ajax if it can be hidden with CSS and revealed

4. Backup plan
- have a fall back option, multiple ways of achieving same goal
- use headings for “rescue point” if user gets lost in document

5. Visual Design vs Structure
- check that your visual design and un-styled document is telling the same story
- turn your CSS off see if site still makes sense
- build linear flow into your wire frames

6. Development Testing
- Test for accessibility from the start.
Design Stage: Color contrasts, general layout
Functional Testing: must work with keyboard
Demo Testing: all alt must be accurate, screen reader emulators, turn off css
Final Test: real people varied needs.
- test success error AND corrective paths
- check for alt tags and that they make sence.

A Tools and Links
- Screen readers Shark and Dragon Natural speaking
- HTML Tidy in Firefox is a good start
- Fangs Firefox plug-in screen reader emulator
- Juicy Studio Firefox plug-in for Luminosity Colour Contrast Ratio Analyser
- www.simplyaccessible.org for some examples
- WCAG the accessibility bible

Soo once again to make some sence of all the random jucy tidbits of knowledge, its definitely something i will be promoting from now on.

At a basic level it costs nothing. Its up to the UX designer and Developers to just take a bit more care in element placement and thinking about the project not just from you users perspective but also the less able users. As a by product this will produce a much higher quality product and the HTML is bound to be more semantic and efficient.

A quote from Derek that summed it up quite well :

Its about whats under the covers

Presenter M. Jackson Wilkinson
Twitter @wafro
Site: www.jounce.net
Developer(Python), Project manager, Agile Man

So i went into this presentation having seen a couple of agile projects in practice, and not quite sure what it was all about i did a couple of googles some time ago. When this opportunity came around i thought it would be rude not too.

Jackson was a great presenter and covered a wide range of topics from various peoples perspectives in the project team. I will not try and repeat it all as i would be here forever and its a bluebird day in welly so i’ll keep it short.

- Collaboration is imperative
- Embrace change
- Choose the team very carefully
- Everybody on the project team must “buy-in” to the goal
- Attention to the technical detail not just a quick hack as more time is spent on the development rather than the process.
- Release _working_ software often to the client to show progress. Not every cycle has a release

We brushed over the how the process works :

1. Cycle Zero
- Research
- Product Design
- Development Prep get ready to start coding
- Moodboards(very cool) for quick look & feel concepts
- Very importantly Defining Done

2. Cycle Planning
- Develop User stories eg. User can search for a photo.
- Test planning – asumption, success criteria, out of scope bits
- Use and index card to capture information gathered so far.
- Estimate is placed on each card and determined which cycle its targeted for.
- Use 1.2.4.8.16.32.64 for giving each storie points.
- Find your teams balance on how many storie points you can complete in a cycle
- Keep team rolling with backlog of the easy 1.2.4 tasks

3. Collaborative UX/UI
- Get business and designers to build mock ups together
- Quick and on paper gives you LOFI wireframes
- You can do more detailed wire frames but risk quibbling over detail
- Mock ups avoids confusion and developers love them

4. Daily Progress
- Focus on YTB, yesterday, today, blocks
- Use time keep it short and standing
- Just Google “scrum” it’s all there i promise
- there are all sorts of rules but use what works.

5. Pairing
- Thinker and Checker and the Does/Executor
- Development – Beter code less bugs
- Wireframes – review asumptions and help brainstorm

6. Test Driven Development
- Is a must
- Every function must have a test
- Selinium and Windmill for frontend test automation

7. Continuous Integration
- Automate Release cycle (cruzecontrol or hudson?)
- Frequent Release cycle (dayly, hourly)
- Check out, Build, Run Test, Notify if errored, Deploy(in Test)

8. Retrospective
- just before start of next cycle
- where are we at now
- reflect on previous cycle
- review story points completion
- review pairing arrangements

Appendix – Artifacts
- This one is still baffeling me as the whole point of agile is to just get into it, and only document what will be reused. But this means that some desision points may be lost because of lack of documentation.
- The code should be self commenting plus enough comments to make the rest understandable, frequent refactoring and good comments should improve this further
- Project wikis was also suggested.
- I do like documentation, so im unconvinced on this point of limited documentation

An interesting new term that was topic for a bit of discussion as it wasn’t on Google yet was “Layered Progress”
It is when you do development for your whole site in high level wire frames in the first pass. Next stage as they become available replace high level wire frames with more detailed ones, and as the final functional pages are available replace them again.
Implementation of this is up to you, if you hunt hard enough something like this may be found somewhere.

Another new one, for me at least, was “Coding Dirty”
It is when you developer builds the functionality and designer does the design afterward. This is fraught with danger as if your html/css is not marked up well it will produce a sub optimal result. Some people in the group has had success with this order.

Soo final thoughts. I’m not totally sold yet, there are some facets to it that i like but i will chew on the methodology a bit longer.

To give it appropriate visibility in an organisation you will need to try it on a small not critical but highly visible project to get the hang of it and get buy-in based on its success.

Now for some rest before day three AJAX and Accessibility shenanigans.

After a mad dash from the airport we made it just in time for the first session on the day. We did luck out on the good seats. But not even the neck wrenching all day long could take away from the sessions content.

I was amazed at the amount of ground that was covered by Russ Weakley. Fast paced and action packed till the last bell rang at 5pm.

Areas of particular interest to me, no i might hear you say du!, but my css and html skills have been hacked togeter like a IE 5 stylesheet.

• I’m slowly getting my head around Inline, Block and Terminal Block elements. I’ll have to go check out that last one again.
• Selectors are your friend, esp descendant selectors save you from needing to assign classes unnecessarily
• Try and use your site without a mouse, for basic accessibility testing
• Check out http://maxdesign.com.au for some css goodness and examples
• display:inline = inflow, display:block = out of flow
• CSS Sprites, have all your icons in one gif file to save round trips to the server. Use ample white space(100px) to avoid strange effects when font size gets increased.
• User more of “em” unit to make site more fluid when font size in the browser gets changed.
• Russ finally got me to make sense of “li” elements for navigation and how easy they are to work with.
• Also see “Sliding Door” for nice and neat little tabs with rounded corners. a and span elements are your friends here.
• Tables in forms are _bad_ for accessablility
• Build for standard compliant browser ALWAYS!!!, you can add IE specific hacks in at IE only style sheet.
• When doing a printable stylesheet see “media” attribute of the link element.

So at the end of a long day im calling it a wrap. The sooner i go to bed the sooner i can go and have a coffee at Delux

Double Margin Float bug is quite bizarre – Russ(Sounding like the Steve Irwin of CSS)