@media 2008, Day1 Notes

4:22p.m., Thu 29 May 2008

My notes from @media 2008 (day 1) - as naked as the moment they came from my fingers - i typed as the presentation was ongoing and, quite frankly, I can't be bothered to sub them (apologies to the ppl I've quoted, don't use my notes as a stick to beat anybody.)

I might add links later. Well... I might!

Here goes...

Indi Young - Mental Models.
10.30am Thu

What is a Mental Model?

a diagram of underlying reason that drives behaviour.

what does a mentalmodel look like? presents model done for dell-corning one for engage.com and 1 for microsoft

the look like wall friezes - long and shalllow.

another pic of a mental model for Macy's built with sticky notes.

Richard Vangyard's 3-Layer CAke.

diabete Management ALignment DIagram by ADaptive Path that maps the emtotions that go with living with the condition.

Next SLide
Looking in detail...
Boxes represent behaviours, philosophies and feelings.

These are grouped into conceptual groups - in this diagram they are grouped into towers

everything above the "horizon line" is worded in the way the users speak. They include colloqiual words and ALWAYS start with a verb (useful for getting into the user's headspace)

Below the horizon.
two types of boxes-
white is a connection
purple is a STRONG connection.

The kindsof things that go into the top half of the diagram - diaries, field data, interview snippets, card sort data,customer feedback emails. Indi uses interviews more than anything else.

Mental Models fed into user tasks, stories and user journeys.

Why Would You Use A Mental Model?

She cites the e.g. of a piece of software that has been developed for cmopanies that manage huge fleets of trucks.

The telephone support were using the same online interface.

ANother e.g. The California State UNiversity site that wa a huge monolithic site for evrybody. The mental moddeling process led to the separation of the site into a colection ( a campus) of different sites for studet/arents/tutors etc.

* Focus on customers, not internal organisaions and business terms/language/politics.

The Mental Model is a document that has a lifespan that is potentially much longer than the old-school product spec. docs which often need to change before they are finished.

CAN IT RESOLVE SOME OF THE PROBLEMS MY TEAM HAS?

We struggle to agree on a common design... eveyron has a different opinion.

A mental model is an independent document - it's a document of real user's lives. nce you have that it's much easier toagree on deicsions to develop products that suports the lives of yr users.

We have difficulty taking our employee hat off. Some times we cross our fingers that desin will be successful - Indi compares design to throwing a piece of speghetti at the wall and hoping it sticks.

The Mental Model can make design decisions more informed decisions and give a greater confidence to the decisions that have been taken.

A mental model can informa broader understanding of users lives - meaning that your less likely to miss crucial parts of the user XP.

Indi presents an application that searches for properties for sale that allows users to search by cost and commute time.

BUt a mental model could have unovered more search criteria. For e.g.

fid commute time by public transport.
find suitability of local schools.

the mental model can help broaden your perspective as a business.

"EMPATHY IS FOR BETAZOIDS, RIGHT?"

We're software designers!

Well....

hear stories - feel empathy.
When you can empathise with somebody, that's when you're empowered to make decisions that will benefit them.

The example of online dating: engagecom
A mental model that figured out "how to handlle an attraction"

how do ppl make decisions about how to react?
in a normal situation all the reactions are physical.

The next step was that ppl asked a potential mate's friend about them.

Tackle this engage.com alowed ppl to corall their friends t post testimonies. Other users could also ask a person's friends questions: "you know, on their profile, it says they smoke occasionally - is that true?"

A lot of ppl stoad on the sidelines and watch before really engaging.

To tackle this in an online sphere engage allowed users to post a snippet stati ng where they'll be at a given time.

Then there's the first date - the stories here: "Feel shocked!', "Lose spark", ::"

HOW DO I DECIDE TO MAKE AMENTAL MODEL OR NOT?

shows a grid of type of research (preference, evaluative, generative) vs techniques and uses.

Diff types of research for differnt types of projects. E.g preference research for a branding diesign project.

Mental Models are NOT used for...

* Evaluating usability
* showing cyclical relationships.
* depcting detailedtask flow.
* creating art

What a mental model IS for...

understanding:

behaviour
philosophy
feeling

(these aren't always expresed directly, they maybe implied through behaviour)

Indi shows a transcript of an interview. She highlights the 'important', key phrses to extract and feed into a mental model.

HOW A MENTAL MODEL CAN INNOVATE

Innovation cannot be forced.
Change needs to be understandable (something so new an revolutionary just cannot be understood and accepted easily)

Book recommednation: "The Wisdom Of Innovation" by Scott ?

Look at the mental model for gaps/possibilities.
You might want to map your innovations over time - a gradual incremental change that users will accept.

Documentation includes quotes direct from users

book: Mental Models by Indi Young.

===============================

 

HTML5 by James Hunt & Lachlan Young

why not xhtml? working to merge html and xhtml - smae syntax, dif vocab.

design principles:
when whatwg joined wth w3c, developed design principes to facilitate working together

* compatibiity
easy migration

* utility
add features that are useful

* interoperability
ensure that everything works the same way across all browsers

Spporting Existing Content
Browser absolutely must remain compatilbility with existing content.
Cites the example of move from IE6 to IE7. Lots of sites broke - Microsoft felt that went really badly and don't want that to happen again.

Degrade gracefully
ensuring that new features don't break in older browsers.

DON'T REINVENT THE WHEEL
If it already exists, don't reinvent it.
We need to standardise the canvas element that apple originally developed for their dashboard widget.
Canvas was then picked up by exisitng browsers, delivered in different ways.

 

Lok at whay authoers are trying to do and improve he soutions where necessary.
Good example here is the representation of dates and times in Microformats. HTML 5 has incorporated a TIME element.

 

EVOLUTION, NOT REVOLUTION
the developemt of html5 is aimed at being incremental improvements ather thtan throwing html4 away and stating again.

browsers are still going to have to support html4 and xhtml1 for the forseeable future.

SOLVE REAL PROBLEMS
within the html wg, ppl come up with solutions for imaginary problems.
This has been a huge issue.
For e.g. ppl with ideas about metadata elements for search engines.
But, actually, search engines are more interested i the data that is readable by humans rather than processing hidden, or none displayed data.

PRIORITY OF CONSTITUENCIES
priorities the needs of:
users, authors, implementers, spec writers, theoretical purity.

All solutions need to benefit (or not inconvenience) the stakeholders.
You can't seprate the needs of all these stakeholders into lovely seprate groups

SECURE BY DESIGN
protecting end users from malicious intent - the html5 spec cannot introduce vulnerabilities - security has to be forefront of the consideration

 

SEPARATION OF CONCERNS
This isn't a strict guidline. but you can't hardline this in html5 - the <b> is in ther, as it what was in html4.01.

DOM Consistency
at the mo the way the DOM works with html4 is somewhat diff in xhtml - lots of differences in namespacing and case-insinsitivity. SOme of these have to continute - it's important that we don;t add to those differences though.

AVOID NEEDLESS COMPLEXITY
Authors don't use complex solutions.
It's also easier for browser vendors to implement simple solutions that work, rather than a more complex solution.

 

WEL-DEFINED BEHAVIOUR
90%% of the web is syntactically level (google study)
The push for HTML5 development is making sure that browsers do exactly the same thing with all possible input. For a lot of the invalid web browsers make a guess as to how to render the code. The push is to ensure that different browsers make the same guess.

 

HANDLE ERRORS
With HTML we want to make sure we're andling all the errors that are out there and new ones that will occur.
The spec will define how errors are handled as much as is practical.
HTML5 has algorithms that defines how to handle input even if the input is "crazy"

MEDIA INDEPENDENCE
HTML aims to support all diff media, devices and platfoms to a reasonable level.

SUPPORT WORLD LANGAUGES Support for bi-directinal text
Pages in any language

 

ACCESSIBILITY
Avoid solutions that require authors to make additional effort to make HTML accessible.

Where possible we want to focus on built-in accessibility.

Some of the work we've done, partic in relation to table headers - to take a more specific, data-orientated approach. The impression I get is that

 

WHEN CAN WE START USING HTML5? As soon as the browser you care about implement the feaure.

In practice, Firefox3, Opera 9.5, Safari3, IE8 all have some support for some of the HTML5 spec.

DEMO Example page with a page header, nav, article, sidebar, footer.

For these you'd used <div><b>s in HTML4. A div is a none semantic element.

But it would be nice if a screen read could jump straight to the content.navigation.

Presents a survey of commonly used class names for elements in html4

top results include: footer menu, title, small, text, content, header, nav, copyright

new element called:

<header>
a wrapper for type stuff.

<nav>
an easily identifiable elemnt - useful for screen readers as perviously mentioned

<article>
fairly obvious

<aside>
could be used for a pullquote. IN this example it's the wrapper for a list of links to archive pages of a blog.

The example of a pullquote is a good one - in HTML 4 you're interrupting the natural flow of body copy. Using an aside element could allow a user to preview asieds, or go back and read them after the body copy has been read out.

<footer>
again, we're paving a cowpath here.

<section>
used to mark out a subsection of something.

This allows authors to easily manage the hierarchy of &ht;hx> elements.
the nesting within the section element can be understood by the use agent.

<time>
The Microformats communty has used the element to store time. That has usability repurcussions. This is a more useful, semantically specific element.

It's designed to integrate with existing Microformats.

<figure>
currently in html there's no way of marking up text that relates it to another element.

Now we can repurpose the legend element to o that by nesting it in a element.

E.g.

<figure>
&&t;img src="http://www.blogger.com/mycat.jpg" />
this is my cat
<figure>

<meter>
for measurement systems - for ratings, capacity (like on a gmail account) example use:

<meter>3/5</meter>

Could automatically render graphical representations.

This could be used for loading bars too.

VIDEO

The push for native support for video in browsers.

We're looking for moving away from the dependence on flash. BBC research has shown a surprising level of users without the necessary plug-ins.

<video>
allows an author to casually include video easily.

If you want to build a really exciting video interface there's a DOM API to alloww the construction of advanced controls

CANVAS

Used to dynamically draw graphics and text.
There will be a graphicaly-oriented DOM API.

Three major browser vendors have very quickly implemented this.

A new feature is support for text - there's a JS plotting library.

EXAMPLE - a first person shooter written in JS

 

OFFLINE WEB APPLICATIONS

It sounds crazy to be adding offline support in a web spec.

Example: composing emails, reading emails offline, and then syncing when you go onlie - sending emails that are waiting to be sent.

SO we've introduced an API that allows authors to specifiy files which need to be hosted locally to allow the application to work.

To do somethig like compose msgs in gmail you need some way of supporting data. You coul use cookies I guess but ut would be horrendous.
So we've added some local storage APIs.
Each domain can have a persistent JS object. What you can do is add name:value properties to that JS object.

There's also a whole load of events defined that tell the browser when an internet connection is lost/resurrected.

For certain applications just using name:value pairs isn't adequate. There's also a formal SQL api. Both of these have been implemented in various places - ecent Safari builds have support.

 

DEVELOPER TOOLS

Validator.nu

Exceeds the capabilites of trad DTD-based validators - gives more valuable & specific feedback to authors.

 

PARSING HTML5

There;s an eco-system of tools building that allow the parsing of html5 - written in Ruby and Python/

An Off-the-shelf parserreduces reliance on RegExp hacks.

w3.org.html
* whatwg.org
* blog.whatwg.org
(absolutely anyone can contribute here)

* forums.whatwg.org
* wiki.whatwg.org

There's mailing lists and IRC.

 

=====================================

Drew NcLellan - content management systems (without the killing)

edgeofymseat.com

this presentation will cover the content management side of the CMS - not the 'building a website and presenting content effectively' side.

A content management system could be a physicalprocess with a person wandering around the office collecting papers and putting them in a folder. Very quckly these systems hit physical limitations.

First....

I'll mention EGGs.

Not sure how you like your eggs. Poaching an egg is a tricky business isn't it?
I tried it once and it was a mistake.

We we need more predictable results - when we need something to work well and work well everytime we look to a tool to help us to do that.

In the film Chitty Chitty Bang Bang Caractacus Potts prepares a machine to prepare the eggs just as he likes them.

[Plays a cLip from said film. The incredibly over-complicated machine messes up, delivering a hrd-boiled egg instead of a fried egg, much to the machine's inventor's puzzlement.]

As tools get increasingly more complex - the results aren't necessarily those you'd expect.

Caractacus Potts over-complicated his machine.

He cites the invention of James Seddon, his toaster for eggs.

He takes a very simple process and tries to make it simpler by introducing more automation. With disastrous results.

a good CMS should be as simple as possible, but no simpler.

What I'm going to talk about today is bulding a CMS to a client's needs, without bloodshed.

WHEN DO WE NEED A CMS?

A case wherby a site simply has so much content, turning over at such a rate that it's too much to handle - this may be news stories, blog posts, whatver.

A case whereby you want to publish the same content in a variety of formats e.g. an RSS feed.

These repetitive tasks are exactly the sort of things that computers are good at.

CONTROLLING you could use a CMS for increade control - rights management, scheduling, versioning...

There are all sorts of types of CMS.

OFFLINE MANAGEMENT

Most basic is offline content management - Adobe Dreamweaver with Contribute for e.g.

This allows non technical users to edit content. Can include rudimentary tools like link checkers.

This can come into it's own for large static sites - especially sites that are already existing.

What this won't give you is the ability to schedule content publishing, multiple language support. But it can be a good option.

ONLINE MANAGEMENT

Far more common - a web app that's running a site.
A request comes in for a page and it's that system's job to decide how to respond.

This is what we typically think about when we talk about CMSs - online formas that manage content that is stored in a database.

These can generally be divided into 2 types of systems:

AN OFF-THE-SHELF SOLUTION:

for sites that fit a common pattern - a blog or a news site for e.g.g this system falls down whenever you need some kind of customisation. MOsys systems offer some way of extending functionality, but in practice this won't extend far enough.

A CUSTOM CMS

2 important things I've learnt about CMSs.
- everyone hates their CMS.
- no CMS is forever.

attempting to find a solution that works for today's needs and will work for a future set of undefined needs - it's almost impossible.

COMMON FEATURES OF CMSs

the headline things to look for:

the ability to publish clean URLs.
/shiny/happy/urls

We've often seen CMSs that don't deliver clean urls - usually built by software engineers who don't understand the web.

Tom Coates -
"Use readable, reliable and hackable URLs"

for usability and searchability.
Once you publish something to the wild - that URL should stay the same FOREVER ideally.

URLs should be hackable - users should be intuitivley look at a URL and change it in order to get to content they think SHOULD be there.

Good URLs are beautiful and a mark of design quality.

DATA FEEDS
RSS, atom JSON - all good to publish your lovely content in hackable formats. This is something that is not necessarily driven by a client's needs, but that doesn't mean it's not important.

DATA FORMATS
data should be stored in an open format - so you can gete data out for your next CMS, and, perhaps more importantly, you can get legacy data in.

A CUSTOMISABLE & ACCESSIBLE ADMIN UI.

Any admin interface should be optimised so that a client can maximise their staffs efficiency.

SEARCH
The more content you have - the more key being able to search content.

MULTI-SITE SUPPORT
An awful lot of CMS sites are designed to generate and manage content for one site - some want to publish content over more than one site or over a network of sites.

MULTI-LANGUAGE SUPPORT
As long as you have good unicode support for the way data is storied, multi-language support comes much easier further down the road.

CACHING
For performance. We have a client who has a sleepy little site that comes alive once a year. You might think that performance isn't a key factor. However, there was a possibility that a whole slew of new traffic was going to be targeted at the site. Think of cahcing early on becasue it's much harder to retro-fit.

WEB 2.0
Ajax and microformats support.

USER GENERATED CONTENT (cringe)
As soon as you start accepting UGC the system needs to manage this info, commonly alongside some kind of user account.
Once you're dealing with user accounts this opens a can of worms.
You have to enable to manage & delete their personal data.
Comments have to be managed too.
This is an area that might possibly expand a great deal - this is an area were it really pays to consider the future.

OFF THE SHELF SYSTEMS
There are hundereds. As needs vary they vary in price and scale.
At the bottom end there's blog systesm - very specialised CMS. e.g. textpattern, wordpress, chirp.
Managing posts, articles, tags, sections.
they typicaly have fairly flat strucutres - but they are simple to set-up and use. BUt....

BEWARE THE PIMPED OUT BLOG SITE
It can cause real problems.

Case Study: webstandards.org
It used to be based on Moveable type with some static HTML pages stored in CVS.

CVS proved too difficult for casual edits. Workable, but a pain.
Moveable Type was painfully slow to publish - it re-published the entire collection of pages every update.
Even the public userXP was bad for posting comments.

We decided to move to WordPress.
Over and above the blogging capabilities it had a new "pages" feature which would allow us to manage the largely static sites.

It wasn't a fantastic experience - the pages feature was immature and needed hacking. It proved slow. Especially on the CMS side.

Dynamic rendering is a lot more xpensive.

Hacking WodPress was a bad idea. It compromised security. Whenever a new security update for WordPress was released we couldn't upgrade because of our customisation/hacking.

The crucial lesson we learned was this - avoid getting into an unsupportable configuration at all costs.

MEDIUM WEIGHT CMSs
Mambo, Druple, ExpressionEngine, Typo

typically these deal with user/membership stuff.
plus, they offer strucutre/hierarchy management, search, workflows, versioning of content.

beware!

these can be a complicated way to cook an egg.
more power = less simplicity.

set-up and oncifg is more complex. mantenance and patching becomes an issue.

ENTERPRISE LEVEL CMSs

Red Dot

Can be stupidly expensive!

BUILDING YOR OWN CMS

Which you could base on an existing framework: Django, Ruby On Rails, Cake, Symfony

BUt we've decided to develop our own CMS from the ground up.
Typically we work with design agencies who design something and then come to us.

We wanted a CMS that could handle a lot of bespoke requirements. A lot of projects are design-led - any solution we implement has to take care of that.
We also decided to build for phased development and extensibility...
At the core is a lot of functionality to handle the monotonous tasks: login/forotten password etc. We wanted to decrease the skil level need to deply new projects.
We wanted to be competitive on small projects
And we want projects to perform well....

DO WE BUY OR BUILD?

We looked at ExpressionEngine - but the downside was that for every project the question was "can we do this in expression engine?" NOT "how do we do this in expression engine?"

we decided to build.

- it's PHP5/2, MySQL 4.1
- with flexible templating.
- structure & extensible data types
- embeddable applications
- ability to control the IA
- simple admin concepts

TOP TIPS (if you're building a cms)

* know your plug-ins - authenticity, licensing & support
* be a licensing boffin
* plan for the future, but don't buy it today
* don't push your limits from day 1
* be aware of any design constraints
* avoid per user licensing
* speak with existing customers (but remember that anyone hates their CMS)
* know your exit route (store data in an open format)

 

=========================================

Details Make The Difference
Dan Rubin of Sidebar Creative.

What I'll be talking about:
Proportional Design
Brders, Lines & Layer Modes
Texture tricks
some other stuff....

We're gonna talk about how a design <em>feels</em>
It's all abot balance - finding the right point where a deisng works.

Proportion:

When you're talking about detailed things like margins & padding - these things MEAN something.

Create patterns for margins and padding.

Presents CNN.com re-design.

They use padding to cerate flow - to guid the user around the site.
A lot of their margins are 6, 9 and 12px

He zooms into the top-left corner.

They've created this natural balnce with the spacing.
Highlights where the consisten paddings kick in.

It creates a visual pattern for everything to be ground into. This is a style guide for the site.

Back in the day I arbitrarily picked 13px as my standard padding and font-size (because it was my lucky number!)

Patterns make it easier to do the right thing.

It results in something that looks and feels <em>right</em>. There's balance where ppl don't notice the design anymore - it's the message that's trying to get thru that shouts.

He presents a bad example: the foxnews site.
The entire site is left-aligned, the nav center-aligned.
A lot of the text isn't allowed to breathe.

 

TYPOGRAPHY

Use relative text sizes to create balance.

tracking of letter-spacing.
In CSS we don't have a lot of control over letter-spacng yet, but I've found that text looks better with a little smidge of negative letter-spacing - maybe only 1px on 14px headline copy.

GRIDS

I love grids! They're awesome for a number of different reasons - they create order.

Presents a basic example from guardian.co.uk - has a 7 column structure (with the first two column of content spanning two columns.)

Shows another site with columns overlaid on the design: the monocle site.

REALITY IS RARELY SMOOTH - Using Textures.

Everything has a texture. Obviously we can;t use real textures on the computer screen. But we can use texture in a visual way.

Presents milemarker.com

One of the things tat we're working on with tis site is to introduce ore texture to this site.
We've got a lot of light effects and subtle shaows - detail that most ppl won't notice, but they're there.

A lot of ppl fall into the trap of thinking drop-shadows are bad - they're not, just use them with love and care.

If we remove the sutble effects, imediately you see how flat the site looks.

(he's hampered by the poor quality of the projected display here)

the little design details really lift the page. Ever used the "add noise" filter in Photoshop? It's the easiest way of creating texture. It can be sued to create texture that users don't necessarily see, but they definitely feel.

LINES & GRADIENTS

the livtopia sites is presented.

the line above the nav - the tiny arrow pointing to the "current" section.

I'll spend hours sometimes messing around with different blending layers and opacities.
No matter what your team or corporate structure - you have to be responsible to yourself - you have to be happy with the work you do before you hand it over - so spend the time on the detail.

LAYER STYLES IN PHOTOSHOP
Styles added to a layer- handy because they can be added to a flat colour, once a client asks: "I'm not sure about the red, can we try blue?" we can change that with one flood fill - the layer style handles the gradient for example. You can copy-and-paste layer styles too.

I've had instances when I've been in client meetings when they've made requests that I've been able to do them in the smae meeting (sometimes not a good idea when you're being paid by the hour ;)

TACTILE

The diffrence between something thats flat and boring and something that ppl can feel.

Buttons should look like buttons.
One good example is the MINT product for tracking.
One thing that is done here is those little details that make buttons something that ppl want to click.

BUttons with drop-shadows and bevels - these are not just photoshop tricks, they are real, physical things, we just need to remember that when we're using photoshop.

LIGHT EFFECTS

He's a tip - a really simple technique.

He randomly picks a photo of tomatoes from a stock photo site. It doesn't matter what the photo is - just the lighting that's interesting.

He takes a single pixel high slice of the image, copies it, pastes it and then stretches it vertically - it gives him a texture wiht a lightig effect.

Now he fills a new layer with a solid blue.

Takes his tomato layer and plonks that on top, and switches among the blending modes. He chooses Luminosity and gets an image he's pleased with.

This is a technique he used on THE ARIES PROJECT.

PUTTING IT TO USE

He goes back to the foxnews site, and then shows a ock-up with the paddings fixed.
It took 20 minutes.

NOw he fixes some text-tracking.

Any of you can do this - it's just basic, basic math.

I've done this before in a presentation, so here's all my fixes for the foxnews site.....

2 Hours work and he shows a marked improvement, just my impsing the grid, sorting the text and moving a few page elements around. Some subtle lines and shadows around the FoxNews brand. We (ahem) redesigned the logo slightly.

KNowing when to stop is an important skil - that goes back to the "feel" of a design - when it feels right, stop.

That's it.

The pdf wil be available on superfluousbanter.org

Q&A

Q - this feels a lot like print design - is that what you're advocating?

A - no, good design is good design, good typography is good typography. I come from a background of print design - but in print design I have a different style - I use a lot of flat colours because I like the way those work in that medium. Online flat colours don't work in the same way.