cazmockett.com

A couple of days ago, Dan threw down the gauntlet asking if anyone could come up with a logo for the pub standardistas to use on their blogs. Here’e one of my efforts, which will henceforth grace this blog.

You can see some alternatives in the Playpen #8 page.

Hopefully, some more folks will have a go at designing some logos too. When they are available, I’ll let you know – the more the merrier

I’m also very pleased to have secured my place for @media 2007 europe europe this morning! I really enjoyed the 2006 conference, and look forward to all the new sessions on offer. You can read some of my past posts for @media 2006.

Closing panel for the conference. Just a mixture of random thoughts and questions.

• CSS is still an undiscovered country – progressive CSS should come. IE7 is playing catchup with a lot of the other browsers.
• Evangelising on the use of CSS is done – it should be a given (ha ha ha in some places)
• We’re now waiting for the next leap forward in what we can depend on as far as browser support for the standards.
• Tantek demonstrated cutting edge css in Safari – a honeycomb pattern (yes, hexagons!) with rollover change of state – done entirely with CSS and not a graphic in sight. Blimey! That man has an enormous brain…
• Wireframing applications with XHTML/CSS is the only way to test fluid and changable size of text etc.
• What’s missing from WebUI – Tantek would like an “undo” analagous function – plus CTL-S to save text in a form as you’re going along (how many times have forms bombed on send, much to our cussing?) Or even better, persist it in the browser so its still there when you come back next time.
• Yahoo Libraries – no idea why I wrote this down, will have to Google for enlightenment
• Can Ajax be made accessible? Questioner wondered whether inaccessibility was a fundamental problem of Ajax, or just how it is implemented on any given site. User Agents are not really fully Ajax capable. Refs, Derek Featherstone/Joe Clarke basecamphq.com
• According to technorati.com ’s user stats, 15% of users have Javascript turned OFF!
• It’s best to specialise, but be aware of the designer/developer “trench”

What’s Coming Up?

• We need real, practical solutions for web designers
• Best practices
• Microformats, iCal
• OpenData – µ-formats, mashing, GoogleMaps release API, giving us frappr.com
  
• hCards hCalendars and RSS

There should be podcasts of the seminars out in due course, available from the @media website.

Andy Clarke of Stuff & Nonsense / And All That Malarkey

Andy’s an odd fish! But he thinks of things in different ways, and from different viewpoints. He sees inspiration for web design all over, not just online. “Art is design without compromise” – Jeffrey Veen.

Bound By Boxes
We are hampered every which way by boxes, stemming from:

• The environment – ie a 2D screen, which is inflexible
• The Materials – ie the limits of Markup+CSS
• Medium – poor CSS support in older browsers
• Ourselves! – unlearning what we have already learned.
• Refs: Blue Robot’s Reservior, Web Standards Awards

Grid Design
It is a fundamental skill of any designer – using the grid (see also the writeup on Good Design vs Great Design). BUT, what do we end up with?

becomes

Should we look at the web for inspiration, at places like cssreboot, or csszengarden?
Or should we look elsewhere? Maybe a right nav and vertical header could work for your site!

Keep a Scrapbook – could be magazine cuttings, etc, just to give inspiration from other areas. Showed example of page layout which was thus – just an ordered list, effectively – think how this below could be marked up with CSS?

Sometimes the juxtaposition of lines and curves can be quite interesting to think about.

Markup In The Real World
Markup needs to be technically valid but contain elements that have been chosen to convey meaning, semantically. If its tabular data – present it in a table!

Progressive Enhancement
Name given to technique were basic stuff is marked up for styling in IE, plus bells and whistles for other more capable browsers – eg Moz browsers can cope with the :hover class on any element, not just anchors; round corners on boxes are coming!

Transcendent CSS makes full use of all the most up to date CSS techniques. In CSS2.1 this could mean attribute selectors, parent/child/sibling selecctors, pseudo classes eg first/last child etc. Only use hacks to target browsers to turn things off.

Graded Browser Support
Doesn’t mean everyone gets the same thing – but so what if it works and is usable in older browsers. IE7 will level the playing field a bit more (we hope!).

Refs: Yahoo DevNet – Browser Grades
stuffandnonsense.co.uk/downloads/transcendingcss.pdf

Panel with Roger Johansson, Rachel Andrew and Dave Shea.

Always use basic vanilla CSS and HTML files as your starting point for any project. Then work on repurposing this to suit your bespoke application. This gives you a basic framework on which to build each time. Ref: undohtml.css (google for it or go to the end of this page) zaps all of the default browser formatting. Tantek developed it. Use to copy and paste into all new projects.

Next, stuff in the markup and some greeked content and validate

How to break up multiple CSS files
Several ways to do it, including:

• by typography, colours, layout (clear:left does this I think)
• Rachel puts most of her css in one file and pulls out the hacks into a separate one.
• Divide the sheet up with comments when its more complex.
• If its a very big sheet – put a Table of Contents at the top with these sort of comments /* page:=Header */ – as CTL-F will find “=name” very easily (equals not otherwise used in the CSS markup so you won’t end up with spurious finds).
• Dave breaks it up into sections: global nav; sidebar nav; basic html; then will use a separate file for a specific section such as the shopping cart function – he finds it easier to find things again afterwards.
• List colours @ top of stylesheet in a comment – that way its much easier to do a global search and replace if needed.

One problem arises when you edit a stylesheet – you might rid the markup of a div, but rarely do you then weed out the associated css in the stylsheet – so it can end up rather bloated with old stuff you’re no longer using. Try and use some sort of methodology to see if you can rid yourself of the extras.

Using Dreamweaver & Contribute in a collaborative environment
Some partcipants have DW and Contribute, and break the CSS up so that the typography is in one sheet which the dumb users can see – Contribute users will be able to apply these styles when choosing from their CMS, and so won’t apply a page structure style to something that would blow up. The human factor has to come into play – there’s no right or wrong way – you may choose to have one stylesheet for a small site, but split it up for a CMS-driven one.

COMMENT the CSS so you know what’s what – its boring but very necessary when you come back (or someone else does) six months later and you can’t remember what you did! Dave also finds it useful to comment the markup with div ends such as as you’re not always sure which is the closing </div> tag (felt smug as I’ve already started to do that!).

• ALWAYS ALWAYS comment Hacks so you remember why they’re there. Useful to include the download/explanation URL in there too, for your future reference.
• IF you use comments to break up the CSS, use lots of TABs to shift them over to the RHS – they are much easier to scan for quickly that way.
• If you are a large team, comment the CSS with your name and the date when you make changes

Class/id Naming Conventions
Stick to a scheme, be consistent across projects so you are not left looking for something months later (also stems from using one vanilla template to seed each project). Use names such as .sidebar, #navigation, .menu ie keep the name structural rather than related to how it looks. If there were rigid or ideal naming conventions, it would be great for accessibility as users could then more easily override a given style on a page – but that’s Utopia, it ain’t gonna happen.

You can (if you’re clever) use Server-side scripting to change styles on the fly, but none of the panel had much experience of that.

Code Order
Within your CSS, try and be structural about your layout order – start with wrapper, header, then the rest.
Pick an order that makes sense for global sheets, or global, generic then section-specific.
Within a rule, try and stick to a set order for properties (its just good organisation, doesn’t make any difference); position, float, colour, text align etc.
Specifity- when using rules which override previous ones directly, try and put them near each other, if possible, so you’re not hunting all over the stylesheet. – you can still see the styles which will override the properties.
Or group by elements – H1, H2,… Li…<a href> etc.

Tools
Text editors are OK! Or Topstyle, Firefox Web Developer toolbar (switch sheets on and off stupidly easily) .
Testing
Browsercam – its just like having multiple boxes running different browsers (VM ware?)

Presented by Molly E. Holzschlag

Benefits of Internationalisation/Local language version

• Sales – Users are three times more likely to buy something from a site in their own language.
• Customer Service – costs drop with translation of manuals etc, as people don’t contact Customer Services so much.
• Increased Revenue – from both of the above factors. Look at your site’s stats and see if any one country is hitting the site, then set up a local language version for them (eg one site’s revenue rose 8% from a Korean-version of the site
• Better User Experience – leads to a happier user – always a good thing.

Design & Development Considerations
Try to design and develop the product, application oro document content such that it enables easy localisation for audiences from different cultures, religions or language.
Encourage design & development which removes barriers to local and international access – this process is sometimes referred to as globalisation.

i18n = internationalisation (in the jargon); l10n = localisation (number refers to number of letters left out).

Accessibility with i18n can mean providing the technology for features relating to local standards – such as change of date/time formats, numeral systems, personal names and forms of address.
Separate Content – if you separate out local from global info, it makes it much easier to repurpose for different versions Localisation can also mean the adaption of a product (site) to meet local requirements, or a specific target market. It can also mean specifying prices (for instance) in the local currency, or making allowances for different keyboard usage.

Localisation does NOT just mean Translation!
Semantics can differ hugely from one language to the next, and a straight translation might not convey the right meaning.

Symbols, Icons & Colour
Sensitivity to cultural perceptions, language and visual imagery is a must. What do upright and inverted triangles imply in various cultures?

Web Standards and i18n
Best practices are of course:

• Use structural, semantic markup and validate it.
• Separate out presentation using CSS
• Separate out behaviours via JavaScript (external file – don’t bloat up the markup with it – see Behavioural Separation article on A List Apart).

Structure
International sites rely on document structure, which requires proper encoding. Use the lang or xml:lang attributes to declare. This give te ability to handle monolingual as well as multilingual documents.

<html lang=”en”>
<meta equiv=”content-language” contents=”en”> [check this syntax]
<p>The French word for cat is <em lang=”fr”>chat</em>

Semantic Elements
Presentational html can wreak havoc for local content – using <i> for italic instead of <em> means Japanese would not understand the context of <i> (no italics) but they would comprehend that <em> meant emphasis. So always use <em> and then use CSS to style it in italics.

Semantic Naming
Advisable to use meaningful naming convention for class and ID selectors.
Choose a name which reflects the element’s function not its presentation style as this is unlikely to change in different locales.

The Cross-Cultural Challenge
It can be difficult to understand another culture. For good i18n implementation, you will need a qualified representative (preferably a native) of that culture, who can adequately represent the cultural values of the target market.

Language
Use official and local language for the target market (not neccessarily overlapping with the geographical locale – how many folks in the USA speak Spanish?). Use jargon or slang only where the target market can understand it.

Screen Usage Concerns
Different languages behave differently on screen – the equivalent text for a form label might be twice as long in German as English, for instance => be careful of expansion/collapse of text, and the direction of reading.
Colours and imagery – ideally overlay local text over and image, rather than embedding into the graphic. Some colours/symbols mean different things to different cultures. If in doubt, use Blue (like the BBC!).

Why bother at all?
i18n and l10n can improve exposure and revenue. There are complex issues, but begin it early in the design process, right from the start of development. Inform the W3C if there are problems and issues.

Refs: w3.org/international/ and WaSP (Web Standards Project)