CSS peppers his daily routine with studying his favourite subject matter: HTML Elements.  The Elements are a curious set of creatures to CSS, and nowhere is this curiosity more evident than in CSS’s regular [and published I might add] fashion reports on his subject matter. Reading like the annals of an Ethnographer, CSS describes what it was like when he first encountered The Elements…

“[...] The Elements arrange themselves in similar and yet strange-fitting uniforms, some of the uniforms stretch rather badly over the more robust figures (such as the fat one I call ‘Textarea’) and yet they continue to wear these uniforms day by day.  [I must do something to avert this fashion crisis - it's a g'damn tragedy!]“

Before CSS set about clothing The Elements in the latest trendy garb, he decided to investigate why The Elements were wearing those strange uniforms in the first place. CSS needed to witness the birth and early life of an Element. His findings were logged as such:

“[...] These elements all start out in life as simple naked objects, never trying to distinguish themselves from their peers. [They look so boring, so same-y!] Early in their lives, these elements are visited by the clothes merchants (for some reason called ‘Browsers’) and they dress the elements in various lines of fashion (at a price).  These merchants have their own style guidelines for the various elements, and curiously, each merchant’s style guideline shows very little difference from the next. [Maybe all the merchants got together one day and agreed upon how they'd style these Elements.  Must investigate further.]“

CSS went about correcting the bland fashion mistakes perpetuated by the Browsers, setting new life into The Elements. Can you picture CSS flitting about, his paintbrush splurging a spectrum of colour over his new creations?
Some of these creations were boxy, intended for the ones he called Div, Pee and so.
Other creations took on a more fluid nature, a special ocean blue one intended for the charismatic Anchor element was weaved and it was gorgeous!

One day, as CSS recalls, something strange happened:

“[...] Span, that loose character, came in to my shop asking for a change of clothes again, as he usually does. [He's always changing his mind about what he wears, it's so irritating!] I was absorbed in my latest creation, so I motioned for Span to have a look around.
‘Waddayathink?’ I heard a little later; there was Span dressed to the nines, looking just like that handsome devil: H1.
I couldn’t believe it at first.  How did Span fill out into H1′s figure?”

It was a revelation – the impact would be profound!
It was then that CSS realised he had made a huge mistake…

“I had been stupidly using the Merchant’s (or Browsers) clothes as a base for all my own creations as if they were boxy underpants.  In a way, I was inheriting their forms, their textures.  I can’t believe I didn’t realise that all these Elements are amourphous – I can style them as I see fit! (within reason ofc)”

With the limits removed, CSS became an even more talented designer.
A flowing robe was weaved with love and dedication for Pee.
Anchor took on new heights and stature with his new box-cut jeans.
In short, CSS transcended fashion design and his impact on the fashion world have indeed been profound.

CSS’s works have set the bar for all aspiring designers, even to this day. His reports formed the basis for all studies in fashion design.
Meeting CSS in person is a rare treat for younger designers.  ”Don’t forget…”, he would say to them, “an element is an element is an element.  Dress them as you see fit, not by what they’re fitting into.”

It has been more than 8 months since www.yola.com went live with a redesign, built and designed by a small team of people here in Cape Town.
Before we started the build (after months of design by committee), a simple decision was made: Let’s abandon Internet Explorer 6. This simple decision has had a significant impact on our development and design work at Yola, all for the better.

The effects of IE6 on a company

IE6 affects many areas of a web development company, not just its engineers. You’ll feel its cold, evil touch in:

• Product and Design
• Development / Engineering
• QA
• …and even Customer Support.

Let me explain…

The influence of IE6 on web design

Any good web designer will tell you how limiting it is having to design with IE6 in mind. IE6 feels boxy, slow and above all else: ancient. One of the single biggest limitations it has (from an aesthetics point-of-view) is the lack of native blended transparency support typically afforded by PNG-24.

IE6 adds obstacles to the QA cycle

Not only do your QA engineers have to have an additional IE6-ready VM (or physical machines if you’re kicking it old-school style) but so too do your developers.
IE6′s impressive list of 119 bugs are encountered any time you, for example, use a CSS float or influence an element’s box properties. Testing in IE6 is relatively easy, when it works, but debugging is another matter entirely.

IE6: the thorn in the side of every web developer

Microsoft created the Developer Toolbar for IE 6 and 7 (which feels archaic compared to Firebug). Without this toolbar, simple as it is, dev-life would be even harder working with IE.
If you work towards Standards-based HTML and CSS development, your handiwork will look great in Standards-compliant browsers, and then completely crap in IE6 – often causing a refactoring of the CSS and HTML so that sensible IE6 fixes can be applied.
To add to the frustration, the fixes for IE6 incompatibility are typically inconsistent and unreliable. Take our blended transparency issue above… Developers usually get around this IE6 limitation by using png-fixes – which lead to more headaches – try using a pngfix on a blended background image with an offset background-position!

Dealing with IE6 users

Bugs do sometimes slip through to production environments, and these bugs usually occur in IE. Those poor Customer Service people have to deal with IE6 too, but primarily through its frustrated users.

What did we gain by dropping IE6?

I think the primary benefit for me was the reduced frustration. IE6 is incredibly frustrating to develop for, which is a feeling so contradictory to the one accompanied by building a well-mannered website.

So, a rudimentary list of benefits in dropping IE6 support:

• Fewer design limitations allowing design work to push the envelope
• All supported browsers can now use blended transparency without the need for hacks / fixes
• Improved development turn-around times – less time wasted by testing and fixing IE6 bugs
• Fully native CSS1, greatly improved CSS2.1 and even improved native CSS3 selector support!
• Improved CSS selector support puts less strain on HTML development
• One less VM for QA peeps and Engineers
• One less browser officially supported by CS peeps
• …and less frustration!

Someday I’ll create a nice fat blog post on the CSS selector changes we saw. (It makes me giddy just thinking of the impact this has had on the CSS and markup development for yola.com)

To conclude

Some web developers will be locked into IE6 for good, others will find it worth the effort to develop for. All I can say now is that I’m glad we turned our back on IE6, in a way, we’re doing our part to make IE6 less of a necessity on the web.

Touch Screen Interfaces - a big 'Up Yours' to non-sighted users. Photo by Steven Rhodes

The iPad will hopefully be bundled with Apple’s Shining Knight of Accessibility dubbed VoiceOver; which should belay some fears of it being truly inaccessible, but I can’t help but think that visually impaired users are getting the shaft once again. Sure, you could plug in an external keyboard, and use the headphones to hear your way through the system, but that detracts from the portability and practicality of a device such as the iPad.

Accessibility and Responsibility

This weekend also saw the introduction of a Technology-based Bill of Rights for the Blind in the United States. Such a bill would put some limits on what devices government-run institutions can purchase, tending towards devices that can be used by every member of society.

The iPad is more than just a portable information consuming device, it is a powerful application platform. These apps, will they be accessible to visually-impaired users? Will there, or should there be guidelines towards creating accessible applications?
Creating hardware that is accessible is relatively easy compared to enforcing policy or creating guidelines in software accessibility standards. It’s been done for the web through the WCAG, but will we see a SAAG emerge any time soon?

This problem of neglecting the needs of non-seeing users has its roots in the touch interface – it’s a flat, almost-non-tactile surface. You can feel it’s there, but you can’t feel where it begins, ends or is different.
As the hype machine accelerates to our material oblivion, we’ll see more touch-based devices enter the market – devices founded out of jealous and incompetent mimicry for the sole purpose of making money. Do you think these competing devices will be coupled with an Accessibility plugin? Highly doubtful.

So, what can we do about not leaving the visually-impaired behind in our gadget-driven pursuit? Well, for one, the visually-impaired will buy devices they can use effectively. For truly holistic user interfaces, what we really need here is a miracle, and I’m not necessarily talking about restoring sight to the blind.

Waiting for a miracle

The majority of possible solutions could be ones born in Sci-fi, such concepts as:

• Tactile display-surfaces,
• Retinal or Visual Cortex Implants,
• and the unholy-grail: The Neural Interface

Tactile display-surfaces

Imagine a molten-glass-like surface, cool to the touch, that could grow out of the surface towards the user as the visuals underneath it required these height differences. A height-map would accompany the visuals, describing the pits and mounds of such things as buttons and form input fields. When you focus on a text field, a keyboard would rise out of the display surface. You would be able to feel where the home-keys are.
Think of this surface as a mix between an LED display panel and an Refreshable Braille Display. Apple have shown their commitment to visually-impaired users by supporting Braille Displays and creating such wonderful software as VoiceOver: I wonder if they’ve filed a patent for a truly tactile display surface? I imagine it won’t be long before such a device is available to the general public.

Retinal or Visual Cortex Implants

It also won’t be long before ‘Visual Prosthesis’ becomes more than just a research term. Visually-impaired patients could have an electronic retina implanted, or instead opt for the Rolls Royce of artificial sight: a Visual Cortex Implant. By the time these implants become available, I reckon we would have grown out of our fad-like needs to use non-tactile touch screens, instead opting for the unholy grail of cyborgism: The Neural Interface.

The Neural Interface

No Sci-Fi attribution would be complete without a mention of Peter F. Hamilton’s epic:The Night’s Dawn Trilogy. In it, he described a neural implant dubbed a Sensevise – a full and recorded sensory experience was shareable to anyone else with the same implant. With such a device, gone are the needs of eyes and fingers if we can interface such experiences directly to the brain. Hamilton took the concept even further by describing a gene that would allow the bearer an ability called Affinity – a form of telepathy. As time has shown, it’s just a matter of discipline, imagination and believing the impossible possible before we ‘see’ such advancements.

Back to Reality

In the meantime, let’s start getting realistic about including every member of society in these technology-driven times. If you create software or hardware, I implore you to consider those on the periphery of our ‘norms’ by creating holistic computing experiences. Accessible computing is good computing.

CSS Reset

Eric Meyer is one of the original Web Standards Gurus. His work is good, and pure, and great time savers for us minions. Case in point: Eric’s work on reset.css.

What reset.css essentially does is set a common foundation in all browsers by removing the browser’s default rendering of HTML elements.  This makes it easier to author a web document so that it can look very similar in each separate browser.

The problem

I’ve been happily using reset.css on many projects, never noticing along the way the time I’ve spent on redefining margins on <ul> and <p> elements – time that could have been saved by defining a ‘Sensible Default‘.

Here’s an example…

ul {margin:0; padding:0; list-style:none; /*etc*/}

Reset.css would set all Unordered-Lists (<ul>) to have no margins, and no list-style.  This was great for defining semantic menus in the navigation and footer blocks, but…
the rule would cascade! (DUH!) and each time I wanted to have default rendering of a <ul> I’d have to define it explicitly. This situation would be exacerbated for each case when an <ul> needed to be displayed as expected, e.g. in a sidebar:

#sidebar ul {margin:1em 0 1em 2em; list-style:disc;}

The situation

I started working with Christo on a Django web-app, where I basically had to handle the templates, HTML and CSS + Supporting Images. I was using reset.css as normal.
Christo started voicing his frustrations with having to rely on me to define each and every case where a paragraph was needing margins, or an unordered-list was missing its bullets. It came down to a point where he asked me to remove reset.css. My Standards Zeal kicked in and I refused it, saying I’d have to create more exceptions than the rule by not using reset.css.
It ended up in a stalemate, so I thought I’d open up the dialogue to the StackOverflow audience. I put together a quick question and waited 24 hours for the answers to roll in.

Enter: Sensible Defaults

It turns out that the practice of defining Sensible Defaults is a common Programming tip. (This just goes to show my lack of formal programming experience!) Defaults can save a lot of headaches, and this situation of mine was no different.

The solution

Christo and I met half way by overriding the Reset rules just for the content area.

#content ul {margin:1em 0 1em 2em; list-style:disc;}
#content p {margin:1em 0;}
/* etc */

This way I could rely on Reset.css to ease the styling of header and footer elements, and then reset the reset by providing default styling to any content items such as paragraphs and unordered-lists.

TLDR? A warning as a conclusion

So, if you want to use reset.css then please, do The Right Thing™:

• Don’t be an idiot and implement something without understanding it
• Define sensible defaults for where they’re needed.

That is all.

I’m not going to go into detail about it’s function, but what I will do is give a review, highlight its pros and cons and maybe even offer some mixins you can use.

Setting up

Installing LESS.app was a breeze, and being familiar with installing Ruby Gems, the command-line app LESSCSS was also swiftly installed.
My initial reasons for using LESS was to use the Mixin functionality, and create a library of common mixins I tend to use on each project. I was hoping that I could store this ‘common library’ in a central place and reference it from all my projects – this was not the case, as all LESS imports have to be sourced from the same folder.

Pros and Cons

In these 2 weeks of using LESS, I’ve noticed a few limitations – they’re not deal-breakers, but then I haven’t used LESS in a team-environment yet.

Pros:

• LESS Syntax is very similar to CSS, which makes it easier to use than SASS.
• Storing your common mixins in a separate file speeds up development on subsequent projects
• Non-invasive file monitoring means your LESS files are compiled as you save them.  No need for compiling manually.

Cons:

• No support as yet for some dynamic mixins that use proprietary properties such as Microsoft’s alpha(opacity) property
• Multiple comma-separated ancestral selectors are converted into multiple selectors, dropping the comma in the selector and repeating the rule each time over.
• Larger, more numerous imports and more complex LESS files take longer to compile.  I find I’m often refreshing my browser twice because I refreshed before the CSS was compiled.

Talking of a team-environment… everyone who touches the CSS would have to use LESS, else there’ll be some crazy merging going on when someone updates the CSS and not the source LESS files.

All that said, I’d recommend using LESS to anyone who’s working on their CSS independently.

Further exploration

The compiling side of LESS CSS must  surely be able to minify the output!  At the moment it dumps each property on a new line, leading to horrendously long CSS files with lots of whitespace.  (I’m a big fan of multiple properties per line for each selector)  I’ll see what I can find in terms of lessc options, but for now it’s not a big issue.

Momentum

After I subscribed to the LESSCSS Google Group and read through a few of the discussions, I noticed that there seems to be some momentum in the project, but not a lot.  There are plenty of new users asking questions, but not a lot of active developer feedback. (Probably because cloudhead is working on LESS.js at the moment)  Maybe that’s a call for more community involvement in the app.  If you’ve done work on Ruby gems before, why not get involved with LESS on GitHub?

As promised…

…some mixins I use already:

Cross-browser border-radius, still no IE support though

.border-radius (@radius:5px) {border-radius:@radius; -moz-border-radius:@radius; -webkit-border-radius:@radius;}
.border-radius-top-left (@radius:5px) {border-radius-top-left:@radius; -moz-border-radius-topleft:@radius; -webkit-border-top-left-radius:@radius; }
.border-radius-top-right (@radius:5px) {border-radius-top-right:@radius; -moz-border-radius-topright:@radius; -webkit-border-top-right-radius:@radius;}
.border-radius-bottom-left (@radius:5px) {border-radius-bottom-left:@radius; -moz-border-radius-bottomleft:@radius; -webkit-border-bottom-left-radius:@radius;}
.border-radius-bottom-right (@radius:5px) {border-radius-bottom-right:@radius; -moz-border-radius-bottomright:@radius; -webkit-border-bottom-right-radius:@radius;}

IE 6 & 7 hack to support min-height

.ie_min-height (@height:300px) {height:auto !important; height:@height;}

Malarkey Image Replacement

.mir () {text-indent:-1000em; letter-spacing:-1000em; overflow:hidden;}

‘Off-left’ screen-reader supporting layer hiding

.off_left () {display:block; position:absolute; top:0; left:-9999em;}

Cross-browser Opacity – Missing IE filters: not supported in LESS yet.

.opacity (@opacity_percent:50) {-moz-opacity:@opacity_percent / 100; opacity:@opacity_percent / 100;}

Self-clearing for Non-IE browsers: Apply to :after the float container

.self_clearing () {content:"."; display:block; clear:left; visibility:hidden; height:0; width:0;}

60 chairs were laid out at the Bandwidth Barn tonight, we had wine sponsored by the CITI and snacks + drinks available.  We were expecting less than 60, but in the end 75 UX-keen people showed up. This meant a dash for more space and seating,  somehow we just managed to squeeze everyone in.

Why all the interest?

Phil Barrett’s infectious charm has a lot to do with it. He managed to scoop up Professor Uli Weinberg (who was on an African holiday) for a talk on Design Thinking.  I didn’t get to see or hear much of the Professor’s talk, but the audience seemed well engaged for the ~45 minute talk on collaborative and innovative thinking.  [I did notice the Professor was using one of those complex annimated image-map-type slides for the visual part of his talk.  I'm not sure I like those, they're very distracting!]

The caterers were waiting patiently for us after the first talk which ended at 8:30pm.  A lot of folks were networking and the general mood was pleasant.

Jason Hobbs, one of the Johannesburg SA UX big-wigs, then gave a talk after the break on “The door, the wind, the bird and the valise.”.  What had that to do with anything?  Well, Jason likes his Academia, Information Architecture and the thinking behind the thinking.  His talk tied in well with Prof. Weinberg’s, in that it was exploring the periphery of our UX thinking and research methods.  Jason highlighted Practice-orientated or Practice-led Research as a way to help build knowledge bases, but also to help us understand our respective UX disciplines and therefore apply more academic methodologies to our work.

User Experience and its varied disciplines are very much in their infancy, when compared to established industries such as medical or financial ones.  There’s a growing need for solidifying and understanding our work as Web Designers, Information Architects and User Experience Consultants from an academic point of view.  We’re getting there, albeit slowly.  [I'd love to do a specialised and associated degree on the subject(s)!]

Back to the event itself, sound clarity wasn’t great, some folks couldn’t hear our two speakers very clearly, partly because the air-conditioners were working overtime, and not really accomplishing much – our venue was busting at the seams.

What next?

We’re taking notes and had a lot to learn from tonight.  In terms of the next event, we’ve got some talks offered already, it’s just a case of finding a venue and a date.  I think we’d actually like to run two types of events:

• A chin-wag, social event for a small crowd.  Food and drinks
• Small evening conferences such as tonights.

We’re always looking for initiative from the SA UX community, so if you’ve got a talk, know of a decent venue or would like to help organise the next event, stand up and be noticed!

Until the next time…