vortex dot net dot en zed

The first presentation I attended was Che Tamahori’s - he spoke about giving credit where credit is due on the web, while babysitting his youngest at the same time.

How do we credit people’s contributions to projects - freelancers, peer recognition, and even just portfolios. There are frameworks for other industries whether it’s awards or Admedia type listings…but how do we fit this together for our industry, especially when there are so many players. There are organisational politics even within web companies - some allow singular credits, whereas others prefer to view it as a group exercise.

What are the ways we can do this - footer links? Metatags? You definitely can’t do it with government sites, but we want to know who did that. There are elaborate metadata standards which exist in different places, e.g. for museum artifacts.

Our job roles are not well-defined…does this complicate matters even further? It is easier for designers and developers to define their effort on the project but what about analysts, project managers, people who aren’t so easily identified?

Che presented some ideas for solutions:

• Registration of participants and roles on a registry
• Credits page which lives on the server and is human readable, as well as being based on XML/web standards or utilising something like OpenID.

Dan had an idea about portfolio validation - adding people from the project to it and they need to accept that relationship. Limited by the frameworks that people use and it does have more credence if it is attached to the site that it relates to.

Who governs the registry and makes rules around situations where for example the website work has been won by another company & what if they are only modifying the site, not doing a full redesign?

Consensus was reached at the end of the session - everyone is pretty interested in the registry and being able to validate their participation in the work we do every day. It’s just now that how that will or can actually happen needs to be identified.

Andrew Hedges, UI developer from Vianet.travel, ran a session about a project management method for agile software development called Scrum.

Scrum features:

• self-organising, cross-functional teams and team members
• product backlog of prioritised work
• sprints of approx 2 week long phases/iterations
• features are called “user stories” (I like this terminology)
• daily check-ins and catch-up: what I did yesterday, what happened, why I’m stuck, milestones reached
• pig and chicken metaphor: pigs are committed, chickens are just interested parties
• a lot of releases means directed, regular feedback

There was some disagreement about whether agile or Big Design Up Front (BDUF) processes are more about achieving client expectations. I think agile as compared to BDUF does require a lot more buy-in from the outset - and trust that you’re not going to end up half way through and find out that there is a different system/website being built than what you expected. A counter point was that no matter where a budget cuts off or timing is rigid, the approach means that features are prioritised so there is always a complete system…there aren’t a lot of loose ends to tie up.

The website Travelbug was built in partnership between Vianet.Travel and Trademe. The first version is now live and the post-launch iterations are underway.

Andrew feels that usability was dealt with by the short iterations and feedback from the client being added in during sprints. Retrospective and planning sessions would be the place to add the stories in.

Scrum is lightweight on documentation - Andrew feels they could have done more business analysis potentially, but a lot of the user stories and commits to the repository were tracked through Mantis.

Design and analysis teams need to be in scrums as well working through issues one iteration ahead of the development to smooth the process. It needs to be very iterative and chunked in small enough cycles - but then also keeping an eye on the overarching vision.

Darren Wood’s presentation was posed as a conversation on CSS design patterns. Frameworks have been around for awhile but one hit the scene & everyone went “mental”. Blueprint was the one which started the fire - CSS files which are useful for a basis.

CSS frameworks are supposed to make things easier - however, Darren feels it’s not that useful for people building commercial web apps because you’re being forced to use other people’s methodologies. The suggestion is that you build your own from scratch and develop something that you and your team understand.

Darren’s design pattern exists as below:

• reset all elements to a common value
• cut them all back to their default state = you can use resetting tools like Yahoo’s YUI and Eric Meyer’s
• accessibility
• toolbox of default classes which are used all the time - colours, sizes etc
• layout styles - generic styles
• page related styles - home page, another page

Doug Bowman’s three column layout is a favourite - it has source ordering which for SEO is better since you have the navigation after content. This is good for accessibility also (though this is contentious in terms of skip links and who likes what).

Reference from Dan to recommendations against using frameworks (such as from Jeremy Keith) due to issues with non-semantic code, unused parts of the code and non-relevance to some projects.

At the end of the project, the file isn’t going to be 132 lines. It’s going to be much larger than that, so Darren suggests having really sweet navigation in your comments so you can get to know the numbers/references so that you can quickly jump around. If not just for yourself - think of those who come later, or even do yourself a favour for when you come back to the file later.

Do things need to move faster so we can do cooler stuff or do we need to encourage standardisation in browser support for CSS? The coders here in the audience seem to want more stuff - and think that Browser Wars II may help in a lot of ways.

Darren’s holy trinity of Internet Explorer Hacks:

• display:inline for the 10 pixel jog bug
• position:relative
• overflow:hidden

Quote of the presentation from the audience: “Firebug should be the tip of the day…no…every day.”

Darren Wood on DIY CSS frameworks at dontcom.com

Mat Allen designed the awesome tshirts everyone got today and was kind enough to explain what he was thinking, so I was keen to see how that had all come together. There is a lot of conversation about spaghetti VERSUS meatball concepts that Mata put together, but I’ve kind of used these terms as a way to describe elements of his design. (Confidential to Mat: if you hate it, tell me how to describe it & I’ll fix this).

He notes that sometimes design rationale comes after the fact - especially when you need to appeal to so many different people interested in a disparate range of things and be completely representative.

Mata showed early design patterns before they were finished off - the base structure of the design. The end result is not even 1 continuous line - it’s four continuous circles which don’t close, even if it doesn’t look like it (spaghetti).

There are heaps of icons with different things/subjects represented in them, as well as representing people all coming together (meatballs). Eggs are the birth of ideas, shapes are the ideas emerging. The basis of the style for the icons are from Poppy.

By this time the look is coming together - spaghetti, meatballs, icon style - and another layer of interactivity is added with wifi and USB logos for example to show networks of communication as well as of people. The words on the tshirt are verbs to prompt people to do things.

Even the sponsorship logos proved a challenge - as with all sponsorship setups (at least I think this seems universal), people who pay the most get the most space for their logo display. Mata dealt with this awesomely by pulling through the spaghetti device to even deal with the differing heights of the main two sponsor logos.

The second afternoon session I attended was about Charles, run by Karl von Randow.

Charles is a proxy which sits between your browser and the internet - you can see all the communication between websites like Twitter and Twitter apps like Twitterific. It does a whole lot of things in that space to make development a lot easier - especially for Flash developers. It has been in development for 7 years. Most of the updates and new features are developed directly related to user feedback.

Karl discussed the pricing and reason for making it an application that you need to purchase. The licensing is perpetual and entitles you to free upgrades - it’s also shareware. Apple, the BBC, Yahoo!, Boeing, AOL, Adobe, Google and Shift are just some of the companies who have single or multiple user licences. It does 30GB of traffic a month of 1MB downloads.

Seems like it has a lot of uses and if Shift wasn’t already using it, I’d definitely recommend it. I have decided however not to show my development ignorance by trying to add some of the examples here, but if anyone wants to, please add in the comments