Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

January 29 2014

14:00

Optimising Front End Performance for Mobile Devices

greenman

Most front-end developers will be familiar with at least some of the options available to them when it comes to enhancing front end performance. Performance in this sense is not referring to the speed at which a given page loads, but instead how smooth and responsive it feels when a user interacts with it. A specific example would be the frame rate a user experiences when scrolling down your home page; if it’s consistently high, then performance is considered good.

There is a chance you may not have experienced a need to address performance issues before. Maybe you haven’t worked on a site that has suffered from such issues, or maybe removing that small bit of lag or recovering those dropped frames just isn’t at the top of your priorities. Either way, with the increasing amount of animation and complex styles being built into modern websites coupled with the adaptation of responsive design, there is a high chance you’ll run into sluggish mobile performance at some point. This article will suggest a few things to consider when working on websites and web apps that need to balance complexity and performance when running on less powerful mobile devices.

“It Runs Smoothly on My iPhone 5″

Does it really? Well that’s great! Here are some recent statistics provided by the W3Schools (not to be confused with the W3C) that illustrate the most active mobile operating systems.

mobiledevices

Obviously our use of this data is limited. It’s only explicit about two operating systems; iOS and Android. This leaves Windows Phone, Blackberry and other even less popular mobile OSes out of view.

What we can see is that Android’s market share is a somewhat larger than that of iOS. Again, we’re missing further specifics here such as version numbers and device names, but it gives us a good start when determining where our support is most needed.

No only does Android hold the highest market share of active devices, it also suffers enormously from device fragmentation. Recent data shows that in 2013 alone 11,868 distinct Android devices have been spotted in the wild (out of a sample size of 682,000 devices). On these devices, eight different versions of the Android OS were being used.

The point being that when it comes to assessing the performance of your site you have to test on a suitable range of devices. Exactly which devices can only be determined per website, and should be based around real visitor data (if you can get hold of some) that relates to your target audience.

In a perfect world, we would have our sites running fluidly on every single device. In reality, this is not possible due to the usual constraints of time and finance. It’s up to you to decide where to draw the line and to choose what is acceptable.

Common Causes of Poor Performance

Here are a couple of things to look out for when debugging performance issues on mobile devices.

1. Large, Complex CSS Declarations

For all the awesomeness that CSS3 brings to the world of front end development, all these fancy new style declarations are forcing our CPUs to work harder than ever before. Juriy Zaytsev wrote a great article on CSS profiling and optimisation which covers this nicely, however do note this piece was published in January 2012.

The profiler that Juriy uses is Opera Dragonfly’s Profiler, but you can now profile your styles more easily using Chrome DevTools by simply visiting Profiles in the DevTools nav, and select your preferred option.

To see the impacts of CSS for yourself, run a big fancy site through the DevTools Profiler (if you have time, profile your paint times too) and you will see the performance issues I’m talking about. Let’s take a look at an example.

“I can run Battlefield 3 on ultra settings (a very large image), but the Green Man Festival home page scrolls at 24fps. What’s up with that?”

What’s up with that indeed?

greenman

As beautiful as the site looks, the developers have had to sacrifice performance somewhat to achieve the visual look and feel they were going for. The performance loss is small. However, if a site like this can slow down performance on a powerful desktop computer, then what can we expect on a mobile phone running on a 1Ghz processor?

Of course, most sites with fancy desktop features will quite rightly provide a more simplified experience when viewed on mobile devices.

In the case of Green Man, mobile browsers will have smaller images to deal with, fewer or more simplified animations, and a reduced amount of dynamic content. As a result, it scrolls perfectly smoothly and looks great.

If your site feels sluggish on mobile, the first thing to look at is your CSS declarations. In terms of finding the culprits, combinations of text-shadow, box-shadow, border-radius, gradients, transparency and other similar properties spanning multiple elements on a page can increase the amount of repaints the browser is required to carry out and as a result make your website’s UI appear sluggish and unresponsive. These repaints will certainly be more apparent on mobile.

It’s down to you to determine what styles you are willing to keep and which you can comfortably drop. It all comes down to whether the performance increase is sufficient to warrant a slight simplification in visual styles. More often than not, dropping performance heavy declarations can work in favour of the overall experience your users will receive.

2. Complex JavaScript Animations

jQuery is now a standard library used by many developers who want to integrate animation into their designs. The main reason being it’s so easy to use. You don’t really need to know JavaScript to use jQuery. Of course it’s easy to see why this can lead to problems. Poor JavaScript can be one cause of jagged animations, which is why it’s important to make sure your scripts are as optimised as possible.

If JavaScript isn’t leaving you with the results you want, you might want to turn to CSS 3D transforms, support for which is already pretty good in the mobile market.

Using 3D transforms allows for smooth transitions not always capable by libraries such as jQuery. Why? Because they allow you to trigger hardware accelerated rendering which while not a magic solution for all your animation issues, can be used to good effect in certain scenarios. Check out this comparison demo to see just how much performance can differ between the two.

For anyone who hasn’t used 3D transforms before, let’s take a look at a code example to get you started. Here’s some basic CSS you might use to animate the vertical position of an element on hover.

CSS Example

.translate-me {

    transition-property: transform;

    transition-duration: 0.2s;

    transition-timing-function: ease-out;

    transform: translate3d(0, -85px, 0);

}

    .translate-me:hover {

        transform: translate3d(0, 0, 0);

}

I’ve set up a live demo on CSSDesk with all the vendor prefixes included. Please note that some prefixes may no longer be required by the time you read this. If you have time, Flickr’s dev blog contains a great case study surrounding this topic and is well worth a read.

3. Progressive Enhancement Vs. Graceful Degradation

Here we have two “not so new” terms (progressive enhancement is currently celebrating its 10th anniversary, after being coined in 2003) that still hold a lot of relevance today. Both concepts are particularly relevant when developing responsive websites and as the number of devices and OSes available continues to increase, progressive enhancement in particular is going to be a must on many projects.

Aren’t They Both the Same Thing?

Almost. The key difference here is the order in which you approach your design. Planning features to function on all devices and then adding some sparkles for those that can handle it is an example of progressive enhancement. Creating a fancy JavaScript only feature and proceeding to bolt on a <noscript></noscript> alternative at the end; graceful degradation.

Which method should you employ? In my experience progressive enhancement almost always results in a better and cleaner solution. Chris Heilmann has written a pretty good summary on this which now sits over at Web Platform Docs.

What Next?

The ideas in this article are basic but will get you on the right track when it comes to sniffing out causes of poor performance.

If you want to learn more, the best place to start would be to learn the ins and outs of how a web browser works at a technical level. After all, it’s the browser that’s parsing the code you write. If you can understand what it needs in order to be able to run your site smoothly, you’ll be able to factor your code to work with it.

How Browsers Work: Behind the scenes of modern web browsers is a fantastic and comprehensive article that goes into a great amount of detail on this subject. Good luck!

December 10 2013

01:42

Why Bother with Accessibility?

Laura Kalbag stamps the snow off the boots of web accessibility, making positive cases for its foundational place in our work. Accessibility is like the washing up after dinner on Christmas Day: you could leave it to someone else, but it won’t be done right.

December 03 2013

12:00

Coding Towards Accessibility

Charlie Perrins reminds us of a fundamental requirement of our work: accessibility; and that there’s more to accessible interfaces than screen readers. Want to unplug at Christmas? Start with your mouse and don’t look back.

August 27 2013

13:30

Reimagining the 21st-century classroom

Education in America faces tough challenges. Innovative solutions to these challenges can be found when teachers and students apply service design to the classroom, solving short-term problems while also giving students long-term skills.

The 21st-century, American classroom faces major challenges. The threat of the privatization of schools1), the lack of funding, and the erosion of traditional societal institutions, has forced schools to take on the roles of “priests, psychologists, therapists, political reformers, social workers, sex advisers, or parents.”2 Now more than ever, schools are expected to not only teach children subject matter, but to teach life skills as well.

This, in turn, fundamentally changes the teacher’s role in the classroom. Further, legal mandates for test-based performance evaluation have not only trickled down to the teacher’s workload, but threatened their very job. After all, if a computer can teach individualized math better than a teacher and students get higher test scores, why are teachers needed?3 This threat is most acutely manifest by the proliferation of online courses. Michael Sandel of San Jose State University recently foreshadowed the future of higher education in an open letter to fellow professors stating, “Let us not kid ourselves…administrators at C.S.U. are beginning a process of replacing faculty with cheap online education.”4 For teachers at all levels, overcoming internal and external pressures and continuing to provide fundamental value requires an innovative re-envisioning of the classroom and making it a shared experience, one that cannot be replicated by an automaton.

Teachers must overcome the digital-age metaphor of learning, one which compares the human to a computer, putting knowledge into memory, emphasizing logic and measurable outcomes. Teachers must define their role not as data providers, but service providers. The two-fold purpose of education is to teach students to think critically about their world and, ultimately, to teach them to become good citizens. The Service Design techniques and tools – building empathy, customer journey maps, and prototyping – which originally arose to help businesses ideate on tough, multi-faceted problems, should now be used in the classroom to help teachers re-imagine and co-create the student experience.

Class in empathy

Before starting any service design project, designers work to understand the primary actors in their system – indeed, this is a foundational premise for any human-centered design endeavor.

Despite this, teacher‘s often overlook the classroom‘s primary actors, the students. After all, most teachers reason, “I was once a student myself. How could my students experience differ from our own? Neil Postman, the educational scholar and cultural critic, points out the fallacy in this logic:

Most teachers…teach subjects they were good at in school. They found the subject both easy and pleasurable. As a result, they are not likely to understand how the subject appears to those who are not good at it, or don’t care about it, or both.

Teachers, while well-intentioned, may have trouble empathizing with students struggling to understand the curricula or how it relates to them. As a practice in empathy, Postman goes so far as to suggest that teachers teach a subject they are bad at for a year as a way to gain understanding of how many students might feel in their classroom.

From a service-design perspective, teachers can bring more empathy into the classroom by giving students a voice. What do students like to do? What do students want to learn? A simple interview or class discussion can prove quite enlightening. Even switching roles where the student teaches for a day would prove to be enlightening of the other’s experience for both student and teacher.

The student journey

For further insight, students and teacher could employ another service design tool known as the Customer Journey Map. Customer Journey Maps trace the main actors in a system as they interact with its various touchpoints. This, in turn, helps designers discover opportunity areas that might benefit from creative problem solving.

As a classroom activity, a teacher can guide students in groups through making their own “student” journey map of several different time periods: the student’s experience in the teacher’s class, the school day, the student’s year, or even the student‘s entire school career. Doing so provides the teacher with deep insights about what students do outside of his or her classroom. If History class comes after an English class, for example, there might be an opportunity for cross-disciplinary learning cross-class relevant topics might emerge. Understanding the context of the class and getting insights from other classrooms can lead teachers to discover techniques students enjoy in other classrooms and use them in their own. Teachers may even get tough critique and suggestions on how to improve their own classroom from the stakeholders that really matter, the students.

A student journey map exercise also carries the potential to provide deep insight into a student’s life outside of the school environment: what other challenges do students face that might affect their academic performance? By identifying pain points, students and teachers can collaboratively brainstorm possible solutions, creating the ideal journey map to understand how students might better enjoy their school experience. This exercise places both student and teacher in a design mindset understanding that the classroom setting does not have to remain in the status quo. Furthermore, even if student ideas are not implemented, students will be left with the notion that their voice was important, was heard, and did contribute to the structure of their classroom experience.

Life imitates life

Once the teacher and students have created a new classroom model, they should try it out to see if it works. If it’s a success, great. If it’s a failure, even better. As John Dewey, the great 20th-century philosopher and educational theorist wrote, “Failure is instructive. The person who really thinks learns quite as much from his failures as from his successes.” Furthermore, this trial-and-error mentality cultivates one of the principle purposes of education, critical thinking.

Postman, again, writes:

When we incorporate the lives of our ancestors in our education, we discover that some of them were great error-makers, some great error-correctors, some both. And in discovering this, we accomplish three things. First, we help students to see that knowledge is a stage in human development, with a past and a future. Second…we acquaint students with the people and ideas that comprise “cultural literacy” – that is to say, give them some understanding of where their ideas come from and how we came by them. And third, we show them that error is no disgrace, that it is the agency through which we increase understanding.5

Teachers should encourage the prototyping of an idea and create an environment that allows for failure. This should permeate not only into the ideas and environment that students and their teachers co-create, but also into the students’ ability to jump into new learning feeling comfortable with the possibility of failure.

When students and teachers use service design tools to re-imagine their classrooms they fulfill the key purposes of education: thinking critically and being a productive member of society. Through collaboration and group decision making, students learn what it takes to organize and empathize. This makes them better citizens. By being part of their own classroom’s design, students understand that they have an important voice that can lead to change, skills applicable well beyond the classroom.

Designers think critically, and students and teachers must, too. By using Service Design techniques, teachers learn to better understand their students and their changing role in the 21st-century classroom. Instead of the “authoritarian ruler” in charge of imparting a narrow set of knowledge, the teacher becomes a choreographer, setting up the environment to teach and take into account the whole student. Through the Service Design process, both student and teacher realize that the classroom is a prototype that might sometimes fail but never fails to produce some kind of learning.

Excited about the intersection of service design and the classroom? Curious about how to further apply Service Design in Education? Check out these resources and examples:

Note: Service Design Tools are referenced from http://servicedesigntools.org/repository.

Footnotes

  1. “Secondly, we have seen an increased role for national nonprofit and for-profit organizations in providing educational services, and in acting as self-interested players in school politics.” John Thompson, “Seismic Shifts in Education Policy”
  2. Neil Postman, The End of Education, 143.
  3. Motoko Rich, “Study Gauges Value of Technology in Schools.” http://www.nytimes.com/2013/06/14/education/study-gauges-value-of-technology-in-schools.html?_r=0
  4. Let us not kid ourselves,” the letter said, “administrators at C.S.U. are beginning a process of replacing faculty with cheap online education.” http://www.nytimes.com/2013/06/20/education/online-classes-fuel-a-campus-debate.html
  5. Neil Postman, The End of Education, 125.

The post Reimagining the 21st-century classroom appeared first on UX Booth.

May 28 2013

13:30

The Complete Beginner’s Guide to Universal Design

Like countless others, I initially perceived user experience design through the lens of usability: as a “science,” devoid of the subjectivity of “users.” If a door equipped with a push bar actually required me to pull on it in order to open it, I became upset. I considered it a bad experience. And while this does describe a bad experience due to poor usability, my viewpoint was also incredibly myopic.

Unusable or inaccessible, what’s the difference?

As many within our community have pointed out, the things we might normally think of as well designed are often only “well designed” within a certain context. People with limited use of their arms, for example, might find a standard keyboard difficult to employ. Ditto those using browsers that might lack support for web standards. They often incur barriers when accessing the web.

Obviously, this is less than ideal. Design shouldn’t serve merely a subset of its audience – it should serve everyone, equally. Doing that, however, requires thoughtful conversations before, during, and after development begins.

That’s where this article comes in. Like others in this series, The Complete Beginner’s Guide to Universal Design won’t provide a comprehensive look at the subject. Instead, it’s written as a springboard, introducing universal design and its close cousin, accessibility. For context’s sake, we’ll take a look at some of the ways in which universal design manifests itself – both online and off – and then close with some thoughts on approaching design more in a more universal way.

Ready? Let’s get started.

What is universal design?

Universal design describes a set of considerations made to ensure that a product, service, and/or environment is usable by everyone, to the greatest extent possible, without the need for adaptation or specialized design. Accessibility is only slightly different, describing the degree to which a product, service, and/or environment is made available to everyone. So whereas the former is a design methodology (similar to user-centered design), the latter is its most commonly associated metric.

Colloquially, accessibility refers to the degree to which a design functions for people with disabilities – those who can’t see, can’t hear, can’t use a keyboard or mouse, or those who have a cognitive or speech disability. Although these people have historically experienced a marginalized web, the times appear to be changing. The recent rise in popularity of mobile devices has forced organizations to finally give due consideration to the idea of dynamic context: usage in a variety of environments under a variety of conditions. This, in turn, blurs the lines between “people” and people with disabilities. Product designer and mobile strategist Luke Wroblewski has taken to describing his target audience as having “one eyeball and one thumb.”

Both universal design (in general) and mobile-first design (as a case in point) make products and services more accessible, paving the way for what the web community calls “one web.” One web is an increasingly pragmatic vision of a browser- and device-agnostic future which, many believe, is the only future-friendly way forward.

What does universal design “look” like?

All this abstract talk about universal design has probably got you thinking: what does this stuff actually look like? Let’s start by looking at universal design in the real world.

During California State University at Northridge’s annual CSUN conference, accessibility champion Wendy Chisholm pointed out that “stairs make the building inaccessible, not a wheelchair.”

Sloped sidewalks are a design detail accompanying contemporary pedestrian walkways. Physically, they’re nothing more than ramps that are added to sidewalks to make things easier for people using a wheelchair; but their actual utility runs far deeper. By addressing the need for people confined to wheelchairs, designers have also made life easier for moms with strollers, people with handtrucks, etc. This is a good example of how designing for the “extreme” case makes the experience better for everyone.

The digital equivalent of sloped sidewalks is progressive enhancement. Web designers and developers (smartly) assume nothing about their target audience and initially deliver a barebones, semantic website. After the page loads, we use feature detection to determine whether or not a richer experience can supersede it.

Like most universal design considerations, progressive enhancement (when done well) isn’t “visible” unless you know how to look for it. Nevertheless, understanding the thinking that goes into universal design for the web makes all the difference with regards to our approach.

What things shape a universal approach?

Many people have given thought as to what constitutes universal design: Alan Cooper mentions some considerations in his book, About Face 3, and NC State hosts a set of principles on their website. Here, I’ll briefly cover some of the aspects I’ve found useful.

Accessibility begins with content. Accessible content is defined as content that’s perceivable (visible or otherwise), operable (usable), understandable (learnable, logically sound), and robust (well described, available in multiple formats). It is, likewise, made available via an accessible service. Accessible services deliver content to people, browsers, and other applications via a user interface (UI) and/or an application interface (API).

Designing content and services so that they meet these criteria isn’t easy. Instead of the normal, user-centered approach with which readers here are likely familiar, universal designers take an opportunistic point of view, asking who are the people/systems that could possibly use this content or service, and what are the barriers that could possibly stand in their way? I’ve found that this breaks down into a few, key activities: building the business case, measuring accessibility, understanding content, understanding code, and, finally, sharing skills. To be sure, all of these revolve around learning about, developing, and adhering to “best” practices.

Building the business case

To build the business case for universal design, user-centered designers might first measure the content or service’s accessibility (see below) and, second, convince stakeholders that it’s a worthwhile investment. Some arguments include:

  • Accessible content is more findable (SEO benefits) and more shareable (social media benefits).
  • Because they’re standards-based, accessible services are comprised of more interchangeable parts (making for more efficient collaboration).
  • Governments legislate against inaccessible products.
  • For some customers / organizations, accessibility directly drives their purchasing decisions.

Measuring accessibility

Universal design is measured by way of accessibility. Designers can begin to understand this link by developing a working knowledge of the accessibility testing tools available and then using them to evaluate the content or service under question. Finally, they might define an accessibility testing heuristic to ensure consistent measurement.

Accessibility testing tools include – but are certainly not limited to – device labs, screenreaders (such as Chromevox), and disability simulators (such as Etre’s colorblindness simulator). These are just the tip of the iceberg, though. I recommend working with stakeholders to determine the range of disabilities that might apply to their target audience.

After determining which accessibility testing tools provide a useful assessment of their content or service, designers can develop a set of testing heuristics to ensure their consistent use. These could be as simple as checklists or step-by-step guides; they could be as complex as a set of video tutorials.

Understanding content

To improve the accessibility of content, designers must first understand what’s wrong from an accessibility standpoint – if anything – with an organization’s content strategy: how content is planned for, created, published, and maintained. Instead of testing for compliance after the fact, they can embed accessibility considerations into the editorial process from the beginning.

This flowchart shows how determining the content of an image’s alt text requires a bit of thought.

Understanding code

To improve our code we must first understand it. After measuring our service’s accessibility, designers should pair with developers (see below) to better understand – and eventually improve – their development lifecycle. Some organizations do this by creating more modular designs, maintaining pattern libraries. Others adhere to standard application architectures, providing RESTful APIs. Still others use developer frameworks such as Quail.js to ensure that their front-end code is accessible.

Sharing skills

Accessible patterns and company-wide conventions are usually developed ad hoc. While creating an instructive CMS or a set of design/development patterns goes a long way towards ensuring things are accessible, documentation alone is no panacea.

As Julie Dirksen points out in her book, Design for How People Learn, facts are learned differently than skills. Because accessibility problems are potentially introduced whenever content is created – whenever code is written – it’s imperative that team members engage in pair programming or pair writing sessions to share their knowledge.

Go forth

So there you have it. Although it feels like we’ve covered a lot, we’ve actually only scratched the surface. I’ve intentionally left many parts out of this article, parts that are much better covered by entire books written on this subject. If you’re interested in learning more, I recommend giving them a read or perusing the related resource list, below.

Thanks to both Matt May and Derek Featherstone who provided feedback on earlier drafts of this article.

Related Resources


The post The Complete Beginner’s Guide to Universal Design appeared first on UX Booth.

March 05 2013

14:30

The Sound of One Hand Typing

Without a second thought, most people can sit down at a computer keyboard and begin to type. For a person with only one arm or hand, however, computers present an obstacle that is not easily overcome. Those lacking the use of an arm or hand can adapt to using a standard keyboard, but options that might better serve them are severely limited by availability, price, and portability. It’s a void that user experience designers are in a unique position to fill.

With bass drum banging, snare tapping, and cymbals splashing, Alex Wegman1 has expressive stage presence and natural talent. He can do drum rolls and fills, and he loves to play along with the hits. He performs for his YouTube subscribers and his tracks are on iTunes. He’s even had a few moments of fame playing drums on national television in Holland. Alex uses his website to promote his music.

Alex Wegman

Tasha Books2 keeps a near-daily blog with a large following. She writes articles about her life: from current events to her relationships. Tasha’s style is witty, airy, and enjoyable to read. She has developed her own voice as well a steady stream of followers who regularly comment on her posts.

Tasha Books

Alex was born with both arms. At age 16, he was diagnosed with bone cancer in his left arm and, to save his life, his arm was amputated. Tasha was born with phocomelia, a very rare congenital disorder. Her right arm is normal, while her left arm is only about six inches long with three, webbed fingers. Alex and Tasha are both bright and energetic. While their disabilities have changed the way they live, neither would admit to suffering.

The sound of one hand typing

Alex and Tasha live one-armed in a two-armed world. While many of us find it relatively easy to do things that require both hands like tie our shoes or button a shirt, Alex and Tasha have had to adapt to overcome these everyday obstacles.

Determining exactly how many people suffer from disabilities similar to those affecting Alex and Tasha is difficult, but a report released in in 2012 (based on data collected during the 2010 United States Census) suggests that nearly twenty million Americans (or about 6.5%) suffer from upper body disabilities. Of that number, 6.7 million reported having difficulty grasping objects and another 900,000 were unable to grasp objects at all.3

But for better or for worse, the keyboard – a primarily two-handed device – still largely defines how people interact with computers. Need to enter a password? Use a keyboard. Need to fill out a form? Keyboard. Need to email a friend? Probably best to use a keyboard. Because computers help them express themselves, both Alex and Tasha have spent a good deal of time exploring keyboards and keyboard alternates.

Alex currently uses a standard keyboard. Since he originally learned to type using two hands, his transition into one-handed typing wasn’t easy. His parents tried to help by buying a special keyboard, but Alex protested, saying that the keyboard was bulky and old-fashioned. “That would [also] mean I had to take that [special] keyboard to every place I use a computer.”

One-handed keyboards (such as the Maltron model depicted above) are often cumbersome.

Before starting college, Tasha taught herself how to type using an alternate keyboard layout called Dvorak. Unlike the default Qwerty layout (thus named for the keys appearing above the home row), Dvorak efficiently maps the most frequently accessed letters in the English language to the home row. Further, the layout can be installed on any modern, desktop computer which means that Tasha can easily use most computers outside her home.

Unfortunately, Dvorak isn’t available on her iPhone and iPad. As a result, Tasha has to be able to switch back to Qwerty on a moment’s notice. So while Dvorak affords Tasha a degree of accessibility, it is not universally available. Like many other options, it does not fully address her needs.

Having to cope with two-handed keyboards puts stress on more than just Alex and Tasha’s minds. As Tasha explains: “I think the hardest thing about one-handed typing is the same as doing anything with only one hand, it’s just a lot to ask of only one. I know a couple people with only one arm who have developed muscular [or] structural issues over time, and sometimes chronic pain. I’m trying not to overuse my arm, but it’s difficult when you are the kind of person, like me, with endless ideas.”

Keyboard alternatives

One feasible solution to the typing obstacles faced by one-handed or one-armed users is speech recognition software. Speech recognition projects began in the 1950s, but only in the 1990s did the technology become inexpensive enough – and common enough – to impact everyday users.4 In the past few years, Google and Siri have changed the focus of speech recognition to mobile, so the technology can be carried in one’s pocket and the price is inexpensive. But this only solves part of the problem. Google’s Voice Search and Apple’s Siri have proven useful – even practical – for people who want to conduct a quick search, but what about writing an e-mail, coding a website, or writing and editing a term paper?

Tasha says she would be open to using speech recognition software in the future. Software such as Dragon Dictation5 – a popular speech-recognition program – has come a long way, she notes, but it’s not a complete solution. While some tasks could be improved through speech recognition, this option is currently, at best, a piece of the puzzle rather than a comprehensive solution.

In the same vein, specialized keyboards, like the one Alex’s parents bought him, are sorely lacking in their range for users with one arm or hand. While a wide variety of specialized keyboards have been marketed to people who lack the use of an arm or hand, their expense and styles limit their use. Much in the same way that speech-recognition software isn’t portable, specialized keyboard are even less so, and few, if any, have been popular amongst users.

The half-QWERTY keyboard from Matias

The half QWERTY keyboard from Matias6, which essentially provides half of a keyboard with the shift-function allowing access to the missing keys (as in “A”+SHIFT = “J” or “;”), might be the best possible option, since it is small and portable. The price of the half-keyboard, however, is over six-hundred dollars ($600) and that severely limits its availability.

While the one-handed keyboard direction does not seem to be gaining steam, one-handed typing for mobile is improving and could offer the solution that neither specialized keyboards nor speech recognition software has been able to provide. Perhaps the most fascinating possibility for the future of one-handed typing is Android’s Swype7.

Swype allows users to drag their finger from letter to letter and then autocorrects if necessary based on an enormous internal dictionary coupled with user set words. The response time is quick, it doesn’t cost anything extra on an Android device, and it can be used quickly and efficiently after just a small amount of practice.

The future of one-handed typing

Perhaps the best possible design solution currently available is inexpensive, specialized software. “One Hand Keyboard8,” a software product created by a computer programmer who feared that a hurt hand or finger could leave him out of work, operates like a combination of a mobile keyboard’s auto-correct and a regular keyboard cut in half.

The “One Hand Keyboard” software employs a “mirror” key to indicate which key the user meant. Then it auto-corrects. So, for example, the ring finger is used to press the letter “S” with the left hand and “L” with the right hand, to type the word “SALAD” the user would type “SASAD” and the program would autocorrect.

The program relies on past muscle memory, so while it might be an excellent option for someone like Alex, it is likely to be less useful to someone like Tasha. It costs around 150 dollars, but like special keyboards and speech recognition software, it is not portable. If this project were to become an open-source project, or was built in to Mac or PC, however, this could eventually become a lasting solution for typing on a computer. This evolution seems possible, but it is much more likely that the solution to the one-handed typing obstacle will be found for mobile or tablet before computers.

In our hands

Considering accessibility allows designers a way to not only draw in isolated users, but also to challenge existing designs to think outside the box. Is Swype, or a similar program, the future of one-handed typing? Could tablet-based keyboard software or portable hardware built for people who lack the use of an arm or a hand present itself as a legitimate option? Will speech-recognition software take a leap forward and convince even two-handed people to stop using their keyboards?

While there are a plethora of possibilities for the future of one-handed typing, none of the current options serve as truly universal solutions. Obstacles such as learning curves, price, and especially portability force people who lack the use of an arm or hand to adapt themselves to systems built for people with two-arms and two-hands.

Alex and Tasha have attempted to fit themselves to systems that were, at best, partially made accessible to them, and both continue to try to fit a square peg into a round hole. By carefully considering the needs of all users and then crafting inclusive designs, user experience designers can take the first steps toward creating a better typing experience for one-handed typists.

Footnotes

  1. http://www.onearmed.nl/
  2. http://www.theonearmgirl.com
  3. http://www.census.gov (Page 8)
  4. http://www.pcworld.com
  5. http://www.nuance.com/
  6. http://www.matias.ca/halfkeyboard/index.php?refID=7
  7. http://www.swype.com/
  8. http://www.onehandkeyboard.org/

The post The Sound of One Hand Typing appeared first on UX Booth.

December 04 2012

12:00

Colour Accessibility

Geri Coady extends goodwill to all with some insights about colour and how it impacts everyone using our sites and apps. Full of practical tips and tools, this gift keeps on giving.

July 26 2012

10:00

Should We Kill the CAPTCHA?

screenshot

Do you like CAPTCHAs? Don’t lie, of course you don’t. On a fun scale, you rank them right up there with dentists and IRS agents. However, as an intelligent web designer or developer you understand that they are a necessary annoyance.

But wait, are they really? Given the collective talent and intelligence of the web design community, is a fuzzy string of letters really the best that we can up up with? If users hate these things so much, why not come up with something new? Let’s explore this idea and see if we can inject some fresh ideas into the conversation.

Are CAPTCHAs Evil?

We’ve all been there before. You’re trying to log into a website or fill out a form and you’re thrown a piece of text that looks like it was hit by a tornado and informed that you have to decipher it in order to go any further.

Some people pretend that they don’t really mind this “necessary” step, but others turn green and go into a flat out Hulk rage at the mere site of one of these evil gateways. And for good reason, just look at the screenshot below! In prepping for this article, I went to a site that contains a CAPTCHA that I wrestle with frequently. I kid you not, this is what I found right away:

screenshot

Is that not the best CAPTCHA you’ve ever seen? The first part is pretty garbled, but I could probably guess my way through it. The second part though is almost entirely outside of the visible frame! Wondering how often this happens, I hit the refresh button twice and came up with another gem:

screenshot

I’m not just being a jerk here, these are literally impossible to pass. On the occasions when the blasted thing managed to get all of the letters inside of the window, I would get something like this:

screenshot

Easy right? So that’s “a-t-u-t… ummm… t-e-r-i?” I feel like a nearsighted kid at the optometrist making haphazard guesses at the letters across the room. Only there’s no courtesy piece of candy granted to me at the end of this traumatic experience.

For the sake of one last laugh, a friend of mine claims to have encountered this awesome CAPTCHA a few days ago. Apparently we’ve moved past simple words and into complex equations!

screenshot

Not All Bad

“As you answer the CAPTCHA, you’re helping to turn scanned books into live digital text.”

</ br>

To be fair, CAPTCHAs aren’t really evil. They serve a very valuable purpose. Spam is the real terror at work here and CAPTCHAs are merely the best way we can think up to prevent it.

You see, there are these clever bastards out there that dream up of ways to make the world worse and in doing so they invent spam bots that crawl all over the web and generally muck things up. With CAPTCHAs, we have a supposedly simple way to make sure that users are in fact humans and not blood-sucking spam demons.

Some CAPTCHAs even go further than that and make an attempt to further the world through humanitarian pursuits. For instance, the CAPTCHAs above are a specific breed known as a “reCAPTCHA.” These CAPTCHAs actually use people as OCR scanners. As you answer the CAPTCHA, you’re helping to turn scanned books into live digital text, a noble pursuit that helps the written treasures of the past live on in the digital age.

Is This The Best We Can Do?

“Sure, you can say that someone’s solution to a problem sucks, but can you come up with something better?”

</ br>

It’s easy to complain when we encounter annoyances like CAPTCHAs online, especially if we fail to consider the valuable function they’re performing. However, it’s not valuable to whine just for the sake of getting it off your chest. Sure, you can say that someone’s solution to a problem sucks, but can you come up with something better?

I honestly believe we can. The CAPTCHA is a great idea in theory, but in practice it sucks and we all hate it when we encounter one. Unfortunately, it seems to be the spam prevention method that the web development community has settled on. They’re extremely popular and I have seen almost no one making any solid suggestions for how to move on to something else.

Alternative Ideas

My problem is not necessarily that the CAPTCHA exists, or even that it’s popular, it’s that we don’t seem to be innovating around it. Great idea folks, but let’s move onto something that sucks a little less shall we?

In light of this, I’d like to start a discussion on some alternatives that might be a little easier on a user’s state of mental heath. The following are some basic ideas that come to mind.

Random Trivia Question

Why not just ask users a question? It shouldn’t be some difficult Trivial Pursuit head scratcher but a simple query that virtually anyone who can read that language can answer with little to no effort. Here’s an example:

screenshot

This is much easier to deal with than the messed up atrocities of usability that we saw above. Granted, this is a simplified example that might be possible for a computer to parse on its own (Wolfram Alpha didn’t pass my test), but I’m sure you can come up with some better questions. If every CAPTCHA presents questions like this at random, it’ll be difficult for the spam hell hounds to keep up.

Multiple Choice Image Question

The current CAPTCHA system essentially just asks you a question about an image, so let’s run with that idea, but in a different direction that doesn’t make you want to pour Mountain Dew all over your keyboard just to watch it die. Here’s a quick example that I cooked up using a multiple choice format:

screenshot

photo source: Cristian Ghe

As you can see, this is an extremely easy question for a human to answer correctly. Even young children can ace this test. However, programming a computer to interpret the image is much trickier. You could make it even more difficult by using a really abstract representation of an object, perhaps a sketch or some cartoony clipart.

Simple Image Question

If you don’t like the multiple choice route for some reason, scrap it! We can still use simple images to create questions for users to answer. The example below shows how this could be done:

screenshot

photo source: keepon

How many bananas? Three of course! It’s that simple. The great thing about this format is that you could have a bunch of different questions for the same image and the spam bot would never know which one is coming. How many bananas? Does the photo above contain any oranges?

You could get really creative and ask about the nature of the image: Photograph or crayon drawing? The possibilities are endless and they’re almost all easier than deciphering the examples we saw earlier in this article.

Arbitrary Instruction

Let’s drop the image ideas for a second and go back to exploring our plain text options. What if we just gave the user a random series of instructions to carry out?

screenshot

Yet again, this is very easy for a human to do but a bot would quickly become confused. Even if you increased the complexity a little here, you’d still be well in the range of something that can be done quickly and easily.

A Note on Accessibility

Obviously, as with all CAPTCHAs, these ideas would need to be tweaked and improved so that the seeing and visual impaired would have options to pursue as well.

How Would You Make a Better CAPTCHA?

I’m just riffing here, I’m not remotely a security expert. It could be that all of these ideas are horrible, and that’s great! Give me some better ones! All I’m seeking to show is that we can and should be moving on past the annoying solution that our users hate by developing alternative methods that are easier, more fun and just as effective.

Now that you’ve seen some of my crazy ideas for killing the CAPTCHA and beating spam bots, I want to hear yours! Maybe you want to make CAPTCHAs fun and turn them into a game, or eliminate them completely in favor of some other type of security measure. Speak up and make the web suck less.

November 21 2011

07:00

October 31 2011

07:00

Create a Typography Based Blog Layout in HTML5

Last week I posted part one of this tutorial series covering the process of creating a typography based blog design in HTML5 and CSS3. We finished off the Photoshop concept with the design based on a strict grid and text laid out in our desired typeface. Now let’s replicate the design in a static HTML5 and CSS3 prototype before finishing it all off as a fully working WordPress theme.

View the Typo blog design Photoshop tutorial

Head back to last week’s tutorial post if you want to follow the step by step process of building this design in Photoshop. The WordPress theme we’re creating is called Typo. It’s a design that’s entirely based on typography to allow the content to shine. To allow the design to work without the use of any graphical interface elements it is based on a strict grid to balance the design and tie everything together.

View the Typo blog design Photoshop tutorial

Preparing the concept

With this design being pretty minimal and largely typography based there’s not much in the way of background image files that need exporting. The only files we’ll need to save are the background texture file and a couple of icons. However, to make life easier while coding up the design we can also export copies of the columns and grid lines so we can quickly align our elements.

This particular layout will be built with HTML5 elements, so it’s important to take a moment to familiarise yourself with the elements and check whether they fit into the layout semantically.

The HTML5 Structure

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Typo</title>

<link href="style.css" rel="stylesheet" />

<link href='http://fonts.googleapis.com/css?family=Droid+Serif:400,400italic' rel='stylesheet' type='text/css'>

<script src="js/scripts.js"></script>
</head>

<body>
<div id="container">

The static HTML file begins with a HTML5 Doctype and the usual content for the <head> section of the document, including the page title and link to the CSS stylesheet. Our design is using a somewhat unusual font courtesy of Google’s Web Fonts library, so the relevant code is also added. It’s important not to just straight swap your <div> tags for <section> tags when coding in HTML5, sometimes a <div> is still the most semantic choice, like when adding a wrapper or container div to your code.

<header>
	<h1><a href="#" title="Return to the homepage">Typo</a></h1>

	<nav>
		<ul>
			<li><a href="#">Home</a></li>
			<li><a href="#">About</a></li>
			<li><a href="#">Archives</a></li>
			<li><a href="#">Contact</a></li>
		</ul>
	</nav>
</header>

One new HTML5 element we can make use of in place on a standard div is the <header> element, which can also contain a <nav> element to wrap our main navigation menu. The h1 is marked up as the blog title, with a handy anchor title describing where the link goes. If you remember in our concept we numbered the menu items, an obvious option would be to use an <ol> element, but semantically this isn’t correct because there’s no consecutive relationship between our menu links, the number is just for visual flair so we’ll add them later with CSS.

<div id="content" role="main">
	<article>
		<h2><a href="#">Getting your stock photos seen</a></h2>

		<p>Lorem ipsum dolor sit amet[...]leo placerat.</p>

		<ul class="postinfo">
			<li>17th October 2011</li>
			<li>Posted in <a href="#">Articles</a></li>
			<li><a href="#">Continue Reading &raquo;</a></li>
		</ul>
	</article>

I originally used a <section> element to contain my page content, but after some reading it turned out this wasn’t 100% semantic. The preferred method would be to use a plain old <div>, but the addition of the ARIA role attribute of ‘content’ gives a little extra meaning to the tag. Inside the content area each blog post can be contained in its own <article> tags with the usual HTML elements mocking up the dummy content.

	<nav id="pagination">
		<ul>
			<li class="older"><a href="#">&laquo; Older posts</a></li>
			<li class="newer"><a href="#">Newer posts &raquo;</a></li>
		</ul>
	</nav>

</div>

Underneath the series of blog posts is a couple of pagination links. Usually pagination links wouldn’t qualify as being important enough for the <nav> element (which can be used in multiple places, not just for the main menu), but for a blog layout I see pagination links as one of the primary navigation elements to access further content.

<aside id="sidebar">
	<section id="about">
		<h3>About me</h3>
		<p>Typo is a WordPress theme based entirely on a balanced typographic design. A strict grid layout keeps everything tidy, allowing the content to shine. <a href="#" class="more">Find out more &raquo;</a></p>
	</section>

	<section id="categories">
		<h3>Categories</h3>
		<ul>
			<li><a href="#">Articles</a></li>
			<li><a href="#">Design</a></li>
			<li><a href="#">Graphics</a></li>
			<li><a href="#">Inspiration</a></li>
			<li><a href="#">Retro</a></li>
		</ul>
	</section>

Until the <aside> spec was revised it didn’t have a semantic use as a sidebar, but it can now be safely used without the semantic police knocking at your door. The sidebar in this design contains a number of various sections, which lend themselves well to being marked up with <section> tags over plain old divs.

	<section id="search">
		<h3>Search</h3>

		<form method="get" action="#">
			<fieldset>
				<input type="text" id="searchbar" placeholder="I'm looking for&hellip;" />
				<input type="submit" id="searchsubmit" value="Search" />
			</fieldset>
		</form>

	</section>

</aside>

At the bottom of the sidebar is a simple search bar, which allows us to touch on some of the handy new form related features in HTML5. The one feature we can make use of is the placeholder attribute, which allows us to enter a passage of text to create the popular in-field label effect.

</div>

<div id="footer-container">
	<footer>
		<ul id="credits">
			<li class="wordpress"><a href="http://wordpress.org">Powered by WordPress</a></li>
			<li class="spoongraphics"><a href="http://www.blog.spoongraphics.co.uk">Theme by SpoonGraphics</a></li>
		</ul>

		<p id="back-top"><a href="#">Back to top</a></p>
	</footer>
</div>

The layout is then finished off with the footer area, which in the case of this design needs to be outside of the main container area to allow it to span across the whole page. The footer area itself fits well as a <footer> element and contains a couple of handy links.

The full HTML layout

View the full annotated HTML5 code

View the full annotated HTML5 code

The CSS Styling

With the HTML structure in place the document can now be styled to match the Photoshop design concept.

body, div, h1, h2, h3, h4, h5, h6, p, ul, ol, li, dl, dt, dd, img, form, fieldset, input, textarea, blockquote {
	margin: 0; padding: 0; border: 0;
}

body {
	background: #dedede url(images/bg.jpg);
	font-family: 'Droid Serif', serif; font-size: 14px;
	line-height: 24px;
	color: #666;
}

a {
	color: #4b7ea9; font-style: italic;
}
	a:hover {
		color: #105896;
	}

header a, h2 a {
	color: #666; font-style: normal; text-decoration: none;
}

#container {
	width: 916px; margin: 0 auto; padding: 48px 22px 0 22px;

	background: url(images/grid.jpg); overflow: hidden;
}

The CSS file begins with a simple reset, then the global styling is added to the body. The Google Web Fonts code has already been added to the HTML, so our desired font can be called directly in the CSS. The subtle texture background is added and the body text styling set to 14px #666 with a 24px line-height to match the baseline grid. Global link styling is set up, but is removed from links in the header and blog post H2 titles to match the concept. The container div is then centred up and a temporary grid image added as a background to make it easy to line up page elements according to the original grid based design.

header {
	margin: 0 0 98px 0;
}

	header h1 {
		float: left; font-size: 36px;
		font-weight: normal;
	}

	header nav {
		float: right; text-align: right;
		padding: 6px 0 0 0;
	}
		header nav ul {
			list-style: none;
		}
			header nav li {
				float: left; font-size: 18px;
				width: 136px; margin: 0 0 0 20px;
			}

			header nav li:nth-child(1):before {
				content: "1. ";
				color: #a2a2a2;
			}
			header nav li:nth-child(2):before {
				content: "2. ";
				color: #a2a2a2;
			}
			header nav li:nth-child(3):before {
				content: "3. ";
				color: #a2a2a2;
			}
			header nav li:nth-child(4):before {
				content: "4. ";
				color: #a2a2a2;
			}
			header nav li:nth-child(5):before {
				content: "5. ";
				color: #a2a2a2;
			}

Margins and padding are used to line up the elements according to the grid lines, with random figures like 98px being needed to ensure everything lines up correctly. Making live adjustments with the help of plugins such as Firebug is much easier than confusing your brain with complex calculations. Earlier we talked about those visual numbers next to the menu items. They aren’t anything important so they can be added using CSS so they don’t actually appear in the HTML markup, this is done using :nth-child and :before selectors to add the numbers using the content property.

#content {
	float: left; width: 526px;
	margin: 0 98px 0 0;
}

	#content article {
		margin: 0 0 67px 0;
	}
		#content article h2 {
			font-size: 30px; margin: 0 0 29px 0;
			font-weight: normal;
		}

		#content p {
			margin: 0 0 24px 0;
		}

		#content .postinfo {
			list-style: none; overflow: hidden;
		}
			#content .postinfo li {
				float: left; width: 136px; margin: 0 20px 0 0;
				font-style: italic; color: #a2a2a2;
			}

#pagination {
	overflow: hidden; margin: 0 0 120px 0;
}
	#pagination ul {
		list-style: none;
	}
		#pagination li {
			font-size: 18px;
		}
			#pagination li.older {
				float: left;
			}
			#pagination li.newer {
				float: right;
			}

The CSS to style up the dummy blog posts is then added, starting with the content div. A width is calculated according to the columns and gutters, which when combined with the width of the sidebar and any margins equals the width of the container div. The font styling of the H2 elements is added and margins used to keep everything tight to the baseline grid.

#sidebar {
	width: 292px; float: left;
	padding: 4px 0 0 0;
}
	#sidebar h3 {
		font-size: 18px; font-weight: normal;
		margin: 0 0 25px 0;
	}		

	#sidebar ul {
		list-style: none;
	}

	#sidebar section {
		margin: 0 0 47px 0;
	}

	#sidebar #about a.more {
		display: block; text-align: right;
	}

	#sidebar #categories {
		width: 136px; float: left;
		margin: 0 20px 0 0;
	}

	#sidebar #social {
		width: 136px; float: left;
	}

The sidebar element is then floated alongside the main content div and any content not already styled is given treatment to match the Photoshop concept. Some sidebar elements such as the categories and social links and placed side by side, so specific widths are added according to the grid.

#sidebar #search #searchbar {
	width: 230px; height: 36px; float: left;
	border: 1px solid #c7c7c7; padding: 0 45px 0 15px; margin: -8px 0 0 0;
	background: #e2e2e2; /* Old browsers */
	background: -moz-linear-gradient(top, #e2e2e2 0%, #ffffff 16%); /* FF3.6+ */
	background: -webkit-linear-gradient(top, #e2e2e2 0%,#ffffff 16%); /* Chrome10+,Safari5.1+ */

	font-size: 14px; font-style: italic; color: #a2a2a2;
}
	#sidebar #search #searchsubmit {
		width: 17px; height: 17px; float: right; margin: -27px 15px 0 0;
		background: url(images/search-icon.png); text-indent: -9999px;
	}

The search bar in the concept is the only element with visual styling other than typographic tweaks. The gradient effect added to the sidebar can be easily replicated with CSS gradients, whereas the small icon image can be quickly added with good old image replacement techniques.

#footer-container {
	background: rgba(0,0,0,0.2);
	overflow: hidden;
}
	footer {
		width: 916px; margin: 0 auto; padding: 10px 22px 50px 22px;
	}
	footer #credits {
		list-style: none; float: left;
		}
		footer #credits li {
			float: left; margin: 0 6px 0 0;
		}
			footer #credits li.wordpress a {
				display: block; width: 20px; height: 20px;
				background: url(images/credits.png) no-repeat 0 0; text-indent: -9999px;
			}
			footer #credits li.spoongraphics a {
				display: block; width: 25px; height: 20px;
				background: url(images/credits.png) no-repeat -30px 0; text-indent: -9999px;
			}

		footer #back-top {
			float: right; font-size: 12px;
		}

The footer area of the design is filled with a darker texture, which can be replicated with CSS using the RGBa color mode with a 20% alpha opacity on a black fill. The footer-container div will span the full page, so the footer div requires new widths and margins to match the main content container area. Finally the footer credits are added using image replacement techniques and the back to top link is moved into place with a right float.

The full CSS stylesheet

View the full annotated CSS stylesheet

View the full annotated CSS stylesheet

The Final HTML5/CSS3 Prototype

View the HTML5/CSS3 prototype

The final working prototype is now ready for testing before the design is converted into a full WordPress theme. Everything appears to be working as it should in Firefox, Safari and Chrome, and unbelievably IE9 has no problem rendering those HTML5 elements too. Some additional work is required for Internet Explorers 7 and 8, but I’ll save those for a rainy day.

View the HTML5/CSS3 prototype

September 26 2011

07:00

You’re Doing it Wrong: Common HTML Tag Misuses

View the source code of a hand full of websites featured in CSS galleries today and you’ll often see the same errors appear time and time again. These mistakes are usually habits we picked up during our early days of coding that have stuck around due to lack of clarification. This post rounds up a collection of common HTML tag and element misuses and describes the best practice to correctly and semantically use them in your markup.

Misuse of the <br> tag

The <br> HTML tag

How not to use the <br> tag

A common misuse of the <br> tag is to use it to create spaces or gaps in your content. WYSIWYG editors are notorious for injecting multiple line breaks or empty paragraph tags.

How to properly use the <br> tag

The <br> is used to insert a line break in a sentence. Examples might be to correctly lay out an address. Use paragraph elements to split up your content and use CSS margins to alter the spacing between them.

Misuse of the <div> tag

The <div> HTML tag

How not to use the <div> tag

When we first get to grips with HTML and coding in CSS we often get carried away with our divs and surround almost every page item with its own div tags.

How to properly use the <div> tag

The <div> tag is perfectly acceptable to use to define the main page structure, but always try to use more suitable tags for your page elements. Paragraph tags, ordered/unordered lists and definition lists can be more semantic choices.

Misuse of the <small> tag

The <small> HTML tag

How not to use the <small> tag

The <small> tag is often wrongly used as its name suggests, to create text that’s small in size.

How to properly use the <small> tag

CSS should always be used for presentational styling, so use the font-size CSS property to control your text sizes. The <small> HTML tag is reserved for defining “smallprint” or legal text.

Misuse of the <hr> tag

The <hr> HTML tag

How not to use the <hr> tag

The use of the <hr> is pretty rare these days, but when you do see it you can guarantee it’s being misused as a presentational line between sections of a page.

How to properly use the <hr> tag

These days the CSS border property is the correct solution in most situations, however the <hr> tags still has its use in specific situations when defining layouts containing copy such as book chapters or poetry stanzas.

Misuse of the <title> tag

The <title> HTML tag

How not to use the <title> tag

In most cases the HTML <title> tag (not the attribute) is misused in two extremes. It either contains no valuable information, or it’s packed full of endless keywords for “SEO”.

How to properly use the <title> tag

The <title> should accurately but concisely describe the contents of the page. It’s important to include keywords that relate to the content as it is recognised by search engines, but it shouldn’t be abused.

Misuse of the <img> tag

The <img> HTML tag

How not to use the <img> tag

The misuse of the <img> is actually more to do with the misuse of its alt attribute. Often the text within the alt attribute is completely irrelevant (if it exists at all!).

How to properly use the <img> tag

<img> tag alt attributes should contain an accurate description of the image. If the image is being used as a link give an insight to where the link will go. If the image has no importance an empty alt attribute is acceptable.

Misuse of the <label> tag

The <label> HTML tag

How not to use the <label> tag

<label> is another tag that is often left out altogether rather than being misused. When it does appear it rarely includes the for attribute.

How to properly use the <label> tag

Use the <label> tag to relate a field to its descriptive label. For extra usability points add the for attribute to allow the user to click the label to activate the relevant input field.

Misuse of the <address> tag

The <address> HTML tag

How not to use the <address> tag

The name of the <address> wrongly suggests that it should be used to surround a postal address on a contact page.

How to properly use the <address> tag

The correct use of the <address> tag is to define the author or owner of the document. Therefore it’s usually wrapped around their name along with their contact email address or telephone number.

July 25 2011

07:00

How To Create a Slick Features Table in HTML & CSS

We’ve all grown up as web designers staying well away from table based layouts, but we don’t often brush up on our table building skills ready for when we will actually need them. Follow this step by step tutorial to create a slick looking data table to compare the features of various Harley Davidson motorcycles. We’ll build the table in clean HTML then polish it up with CSS to create a cool and easily readable HTML table.

Harley Davidson features table demo

The table we’ll be building compares a bunch of features between three Harley Davidson Sportster motorcycle models. Other than the slick design we’re putting together for the sake of this demo, the table will be built with clean HTML then styled with CSS to make the data easily readable.

View the final HTML/CSS features table

For the design of this particular demo there’s a few files we need from my original PSD concept. These include a patterned PNG graphic we’ll use as a background, the large black and white photo to fill up the demo background, the Harley Davidson logo and photos of the three bike models we’re comparing.

The demo file begins with a typical HTML structure including Doctype, page title and a link to the CSS stylesheet. The page content begins with a <h1>, which will later be converted to the HD logo, then a container div is added to help house and centre up the content.

Next the <table> element is inserted, followed by a <thead> to outline the titles and headings in our table. The <thead> contains two rows, one with the bike photos and the second with titles of each model in <h2> tags. The overall table has three columns, but the first cells in the header are empty so a &nbsp; character is added. To help us style the table and aid the readability of the table data while in code view relevant classes are added to the cells.

After the closing of the <thead> the <tbody> begins. Where <th> elements are used in the <thead>, <td> elements are used in the <tbody>. Each series of cells is contained within a row, and our classes help identify the different columns. All the rows of data are added to finish off the HTML.

The complete HTML

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Harley Davidson Sportster Motorcycle Model Comparison</title>

<link href="style.css" rel="stylesheet" />

</head>

<body>

<h1>Harley Davidson Motorcycles</h1>

<div id="container">

	<table>
		<thead>
			<tr>
				<th>&nbsp;</th>
				<th class="iron"><img src="images/iron.jpg" alt="Harley Davidson Iron 883" /></th>
				<th class="nightster"><img src="images/nightster.jpg" alt="Harley Davidson Nightster" /></th>
				<th class="fortyeight"><img src="images/forty-eight.jpg" alt="Harley Davidson Forty-Eight" /></th>
			</tr>
			<tr>
				<th>&nbsp;</th>
				<th class="iron"><h2>Iron 883</h2></th>
				<th class="nightster"><h2>Nightster</h2></th>
				<th class="fortyeight"><h2>Forty-Eight</h2></th>
			</tr>
		</thead>

		<tbody>
			<tr>
				<td class="feature">Engine</td>
				<td class="iron">883cc</td>
				<td class="nightster">1202cc</td>
				<td class="fortyeight">1202cc</td>
			</tr>

			<tr>
				<td class="feature">Torque</td>
				<td class="iron">70Nm</td>
				<td class="nightster">98Nm</td>
				<td class="fortyeight">98Nm</td>
			</tr>

			<tr>
				<td class="feature">Exhaust</td>
				<td class="iron">Chrome, staggered shorty exhaust with dual mufflers</td>
				<td class="nightster">Chrome, slash-cut exhaust with dual mufflers</td>
				<td class="fortyeight">Chrome, staggered shorty exhaust with dual slash-cut mufflers</td>
			</tr>

			<tr>
				<td class="feature">Wheels</td>
				<td class="iron">Black, 13-Spoke Cast Aluminum</td>
				<td class="nightster">Black, Laced Steel</td>
				<td class="fortyeight">Black, Laced Steel</td>
			</tr>

			<tr>
				<td class="feature">Ground Clearance</td>
				<td class="iron">120mm</td>
				<td class="nightster">130mm</td>
				<td class="fortyeight">100mm</td>
			</tr>

			<tr>
				<td class="feature">Price</td>
				<td class="iron">£6,699</td>
				<td class="nightster">£8,099</td>
				<td class="fortyeight">£8,849</td>
			</tr>
		</tbody>

	</table>

</div>

</body>
</html>

The CSS begins with a simple CSS to remove any default browser styling, then the global styling for this particular demo file is set up. The large background image is added to the page body and overall font styling set up as 16px Georgia in grey.

The <h1> element is then converted to the Harley Davidson logo using the image replacement technique, then the container div is styled to sit centrally on the page. The patterned background image is used as a fill and a CSS3 box-shadow is created to replicate the Photoshop drop shadow effect.

By default the table displays with small gaps between the table cells. Our design requires a kind of margin between the columns but no gaps between the rows. The border-spacing property allows us to designate an exact amount of spacing on both the Y and X axis. Padding is added and text centred on all <th> and <td> elements, then this is overwritten for the cells with the class “feature”, sending the text back to left alignment. These cells are also given an exact width to alter the proportions of the table, making this column the largest.

Our classes of “iron”, “nightster” and “fortyeight” are all given a background fill of transparent white using RGBa colour selection. We could have used a single class for all these cells, but the name specific classes help us navigate the table data while in code view. To add a finishing touch to the table, the same transparent fill is also added to table rows, but only when they’re hovered by the user’s mouse. This simple effect boosts the usability of the table, helping the user easily cross reference and compare the data.

The complete CSS

body, div, h1, h2, h3, h4, h5, h6, p, ul, ol, li, dl, dt, dd, img, form, fieldset, input, textarea, blockquote, table, tr, td, th {
	margin: 0; padding: 0; border: 0;
}

body {
	background: #000 url(images/bg.jpg) center top fixed no-repeat;
	font: 16px Georgia, Serif; color: #ccc;
}

h1 {
	width: 168px; height: 130px; margin: 30px auto; position: relative;
	background: url(images/harley-davidson.png); text-indent: -9999px;
}

#container {
	width: 940px; margin: -115px auto; padding: 110px 10px 50px 10px;
	background: url(images/bg-pattern.png);
	box-shadow: 0px 0px 15px #000;
}

table {
	border-spacing: 10px 0px;
}

th, td {
	text-align: center; padding: 10px;
}

.feature {
	width: 183px; text-align: right;
	font-size: 24px; font-weight: normal; color: #fff;
}

.iron, .nightster, .fortyeight {
	background: rgba(255,255,255,0.05);
}

h2 {
	font-size: 24px; font-weight: normal; color: #fff;
}

tr:hover {
	background: rgba(255,255,255,0.05);
}
	thead tr:hover {
		background: none;
	}

The final HTML/CSS feature table

Harley Davidson features table demo

Check out the complete demo file to see the feature table in action with its hover effect. The use of transparency from the PNG24 files and RGBa colouring really helps create a sleek design when combined with the large background image. Overall these simple table styling techniques can be used on any project to display your tabular data in a readable and easily digestible manner.

View the feature table demo

July 03 2011

10:00

How to Author a Super Accessible Website

Helen Keller, the deaf-blind and renowned American author and lecturer, who became world-famous for her passion towards preaching the importance of living a good life, conveyed an important message to the world through her life by overcoming the odds of sight and hearing deprivation. Hers was truly an outstanding case of determination and confidence. There are thousands of Helen Keller’s with hearing, sight, movement and cognitive disabilities out there in the world, dreaming and striving to lead a normal life as others.

With internet now becoming a necessity in the modern life, it’s really important to create applications that are easy to use for all equally – yes those Helen Kellers too. As a web designer we create experiences for the users and put them in the front seat, with our decisions relating to the interface. Equally important as following best practices and standards is to design UI for systems that are accessible to all types of users – Accessible Design, is what we should be aiming for.

What is accessibility?

Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. For this to happen, the system should be:

  • Perceivable – Information and user interface components must be presentable to users in ways they can perceive
  • Operable - User interface components and navigation must be operable
  • Understandable – Information and the operation of user interface must be understandable
  • Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies

This is a really important aspect of web design, and making your site accessible to all the users means you are seriously supporting the concept of ‘Universality’.

What are Accessibility guidelines?

The governing body of web standards and best practices – W3C, have recommended some guidelines, that each web author should be aware of in order to create interfaces that are accessible to all. These guidelines cover some important challenges towards making a web page accessible, and recommends some techniques which can help us to overcome them.

Creating a system that follows all these guidelines may not be feasible, due to the wider array of technologies and constraints that exist from time to time. But a sincere effort should be made to stick to these guidelines and let’s try to make things easier for all users alike.

Following are the 12 accessibility guidelines set forth by the www consortium, categorized upon the 4 principles:

  • Perceivable
    • Guideline 1.1: Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language
    • Guideline 1.2: Time-based Media: Provide alternatives for time-based media.
    • Guideline 1.3: Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
    • Guideline 1.4: Distinguishable: Make it easier for users to see and hear content including separating foreground from background
  • Operable
    • Guideline 2.1: Keyboard Accessible: Make all functionality available from a keyboard
    • Guideline 2.2: Enough Time: Provide users enough time to read and use content.
    • Guideline 2.3: Seizures: Do not design content in a way that is known to cause seizures
    • Guideline 2.4: Navigable: Provide ways to help users navigate, find content, and determine where they are
  • Understandable
    • Guideline 3.1: Readable: Make text content readable and understandable
    • Guideline 3.2: Predictable: Make Web pages appear and operate in predictable ways
    • Guideline 3.3: Input Assistance: Help users avoid and correct mistakes
  • Robust
    • Guideline 4.1: Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

Techniques for attaining accessibility

Importance of alternate text

Internet is evolving fast and so is the type of content on it. Every day millions of video, audio, graphics are generated and uploaded to the web. Making this huge amount of data accessible to users with some kind of disability is certainly a challenge. Most of the disabled users access web pages, with the help of some kind of assistive technologies / devices (eg. Screen readers, Speech synthesizers, Braille display etc), and the most widely absorbed/recognized content type for such assistive technologies is, ‘Text’.

So its important to provide text equivalent alternatives to such content, and following are some techniques that can be used to achieve this:

  • Alt text – ‘Alternate’ text (short text description) should be given for non-text elements, so that assistive technologies like screen readers can read the same and access the information. There are various instances where an alt text can be used
    • images
      Syntax: <img src=”path” alt=”alternate text comes here”/>
    • Submit buttons (since input type=”submit” is not accessible by text readers, it’s better to give images as submit buttons, so that we can give alt text to the same)
      Syntax: <input type=”image” name=”submit” src=”image path” alt=”alternate text comes here” >
  • Text-indent – while using CSS, it’s common to use text as images for headers and similar elements, where complex typography is involved, and in some cases, where the font is not available for a specific browser to be rendered. In such cases, we can make use of ‘text-indent’ property to increase accessibility of such elements. Here, we provide the text equivalent of the element as a normal HTML text, but hide it from being shown by giving a large negative indent value, so that it is out of the viewable area of the element.
    • Example:

HTML markup:
<h3>This is the html text for the header</h3>
CSS markup:
h3{text-indent:-999px; background:url(path to the text as image) no-repeat left top;}

Another advantage of using such a technique is, it gives more semantic meaning to the markup, as this text gets rendered to the page, when viewed without CSS, and hence will help search engines to index the content properly. Therefore this is a SEO technique too.

  • Longdesc – Though this is a poorly supported attribute, I believe this should be given more support in times to come. ‘Longdesc’ helps us to point to a URL, with a much detailed description of the non-text element.
    Syntax: <img longdesc=”url”/>

  • Audio / Video content – Every audio content (pre-recorded) link, should be followed by a text transcript, so that it is accessible to users with hearing disability. Also, if it’s a video-only content (pre-recorded), its recommended to have a synchronized sound track and subtitle which announces the relevant actions in the video.

Semantically and Sequentially correct markup

Choose the right markup for the right scenario. Semantic correctness of a markup plays an important role when the page is being accessed by other assistive means like screen readers and similar tools. Eg, a header which is being rendered to the browser by using a bg image looks fine for a normal user, but for a user dependent on a screen reader the information will not be conveyed unless the element is rendered using a header (h1 – h6) HTML tag, with the relevant text in it (you could use the text-indent technique to use the bg image and still retain the text in the markup).

This would require the author to be well versed with the meanings of the markup tags, so as to implement it in a scenario that is suitable.

Also, it’s important to maintain the logical flow of the content in the markup. ie, content should be marked up in the flow in a way which is meaningful. Eg. A visual design may have the footer in the top near to the header, depending on the designer’s imagination, but logically a footer should be the last part of a page, and should be the last element in the DOM. The same should be positioned to the top, using CSS, which also means, there should be a clear separation between the content and presentation of the page!

Here are some tools that would help you to validate and make sure the markup is neat and correct:

Don’t rely on colors alone

Color is a good design element to communicate ideas, but it’s not always a good idea to rely only on colors to communicate something to the user, as there may be users with partial or complete color blindness who would find it difficult to differentiate certain contrast ratios.

Therefore, it’s recommended to use other visual cues like border, bg image, prefix text etc. for differentiating elements, in addition to using colors. Also,  W3C has recommended a minimum contrast ratio of 4.5:1, for a visual presentation of text and images of text (logos, large-scale text and decorative text are exceptions).

There are a plethora of tools to validate the contrast ratio and other color related accessibility issues.

Keyboard Accessibility

All functionality of the content should be accessible by the user using a keyboard. Some instances where keyboard accessibility plays an important role are:

  • Access –key enabled pages: Access-keys are super useful in instances of repetitive workflows, where the user is required to do the same actions multiple times, and where there is a large amount of data. The technique is to assign functionality of moving the cursor to particular sections of the page, or to focus on various input elements of an HTML form.
  • Functionalities, which supports keyboard shortcuts like, Carousel navigation, Slideshow gallery

Related links:

Moving, Blinking, Scrolling content

User should be able to pause, stop, or hide content which moves, blinks or scrolls, thereby giving the user enough time to read and use content.

Some instances where this guidelines will come handy:

  • While using a carousel based slideshow. There should be a pause button, where the user can control the slides
  • Any gallery where there is an auto enabled moving set of content. The user should be given the option to stop the slide.

Don’t disable ‘outline’ of links

The links by default have a dotted line around it, in case it is active. CSS can disable this property of an anchor tag, by using :focus{outline:none;}. This would compromise the accessibility of the page, by removing the visual cue that helps to make the content navigable.

Readable text

It’s important to have the content of your page readable, and when I talk about content, I am referring to textual content specifically. Following are some tips for readable text:

  • Maintain a healthy line width (the no. of characters per line). Normally 65- 70 characters per line is considered readable. The key behind setting an optimal line width, is to make it easy for the reader to read a line and then locate the next line, which would be difficult, if the line is too wide in length
  • Make sure, you have an optimal line-height for your textual content. This is also referred to as “leading“. It’s always better to set the line-height 3-6 points larger than the type size. ie, if your font-size is 12pts, 17 pts would be an ideal line-height. Use the “line-height” property of CSS for this.
  • Always make it a practice to set your font-size using ‘em‘ CSS unit. This is for seamless rendering of the text-size when the page is zoomed in and out.

Some links that can shed some light on readable typography:

Usage of accessibility tools and services

There are a lot of tools and services available online, to keep a tab on the accessibility of your web page. Some are:

Conclusion

With the help of all these guidelines, tools and techniques, we should be able to build impressive and accessible online experiences that constantly push the boundaries of existing technologies all the time. Time and again, the change in technology forces more and more additions and deletions to the guidelines, and it is bound to happen. Whatever the guidelines may be, lets just make sure that the content available on the internet is accessible to all users out there … after all, that’s what the concept of universality tells us to do :)

June 20 2011

07:00

10 HTML Entity Crimes You Really Shouldn’t Commit

It has been over a couple of years since I posted my HTML tag and usability crimes posts, both of which are amongst the most popular articles here on Line25. There’s something about this title people just can’t resist! Let’s take a look at ten crimes you may be committing in your HTML content. These won’t exactly land you a life sentence, but I bet almost every one of us will be guilty of at least one of these petty crimes.

Crime 1: Not converting your ampersands

Ampersand

One of the most common HTML validation errors I see when checking the code behind Sites of the Week features are unconverted ampersand characters. It’s easy to simply paste in your content from an external document and forget to transform your & characters into the correct &amp; HTML entity.

Crime 2: Making your own ellipsis

Ellipsis

Did you know those three dots used to indicate a pause in a sentence are called an ‘ellipsis’? Rather than typing three periods or full stops it actually has it’s own glyph as the &hellip; HTML entity. The spacing between the dots in the entity is much tighter than the standard spacing between three full stops or periods. Remember, there’s only ever three dots (four in certain situations), don’t be the person who extends their ellipsis to 6+ dots………..

Crime 3: Incorrect use of the em dash

Em dash

I’m definitely guilty of this one myself. I can never remember when to use Em dashes over En dashes, and what’s worse I tend to stick in a plain old hyphen which makes the crime even more serious! The Em dash or &mdash; in HTML entity format is typically used to separate a break of thought in a sentence.

Crime 4: Incorrect use of the en dash

En dash

Similar to the Em dash crime, the En dash is another form of dash often misused in our body copy. The En dash or &ndash; in its HTML entity form is used to express a range of values or a distance, so essentially the En dash is placed where you would say the word “to” when talking about age ranges or a journey between two places.

Crime 5: DIY Copyright symbol

Copyright symbol

I’m sure we’re all familiar with the international copyright symbol—the letter C with a circle around it ©. Rather than use this standardised symbol, sometimes people decide to construct their own with brackets, (c), probably because they couldn’t figure out the keyboard combination to insert the symbol in Word. Thankfully it’s much easier for web designers with the easy to remember HTML entity of &copy;.

Crime 6: DIY Trademark symbols

Trademark symbol

Similar to the copyright symbol, the trademark symbol has its own HTML entity glyph as &trade;, so there’s no need to design your own from styled <sup> or <span> tags.

Crime 7: Plain text fractions

Half fraction

Another common addition to every day body text is the use of fractions to show quarter, half or three quarters in their shorthand, numeric format. I’m sure we’re all guilty of writing 1/4, 1/2 or 3/4 as opposed to their HTML entity counterparts of ¼, ½ & ¾ as &frac14;, &frac12; & &frac34;.

Crime 8: Plain text mathematics symbols

Divide symbol

Common mathematical symbols such as add, minus, multiply and divide are also misused in general body text. The add and minus symbols not so much, as they’re easily created with their designated keyboard buttons, but multiply and divide are usually seen as the letter x, an asterisk *, or a slash /. × and ÷ symbols can be easily created with the HTML entities of &times; and &divide;.

Crime 9: Supersized degree symbols

Degree symbol

The degree symbol is not the most common glyph used in every day body text, but it’s necessary when talking about temperature, angles or longitude/latitude map locations. We often see the degree format in disguise as a plain old letter o, but it can be created correctly using the &deg; HTML entity like so: 45°.

Crime 10: Somewhat straight curly quotes

Curly quotes

A massive pet peeve for many, the incorrect use of quotes in textual content is one of the most common typographic errors on earth. The standard quotation marks entered with our keyboards are the numerical type which indicate a unit of measurement such as 5′10″. When quoting people, curly quotes should be used with the &ldquo; and &rdquo; entities: “Now I, Skeletor, am master of the universe”, or for single quotes the &lsquo; and &rsquo; entities.

HTML Entity names vs entity number

Every HTML entity can be written as its name value &copy; or as its numerical value &169;. The main advantage of using an entity name is the character is easily recognisable as the name often relates to the actual entity in question (copy = copyright). However entity names aren’t as well supported as entity numbers, which have good all round support.

May 23 2011

06:00

Create a Grid Based Web Design in HTML5 & CSS3

Follow this step by step walkthrough of the making of a sleek website design for an eyewear brand in HTML5 and CSS3. We’ll build the HTML structure with the latest elements then style up the appearance of the site with CSS3 affects to match the original Photoshop concept with minimal use of background images.

The design concept

Optik website design concept

The design we’ll be coding up is for a fictional eyewear brand named OPTIK. If you’re interested in seeing how the design concept was created in Photoshop, head over to Blog.SpoonGraphics so see part one of the tutorial. Essentially the page is based on an underlying grid and features a few key focal elements to direct the user towards the various ranges of eyewear.

View the Photoshop design tutorial

Exporting the images

I know I mentioned we’d build the website with minimal background images, but there’s still a few graphics that need pulling out of the Photoshop concept that just can’t be recreated in HTML or CSS (…yet!). The first of those graphics is the patterned background. Copy and export a selection so that the pattern will repeat seamlessly when tiled.

We’ll create the gradients used on the feature area with CSS3, but we’ll need to export the actual photograph. Draw a tight selection around the character and save for web as a JPEG.

In the original concept we saved two versions of the range graphics. Copy both into a new document to create mini sprite images then export as JPEGs.

This design was created according to columns and a baseline grid. Export a copy of the grid image from Photoshop. We’ll add this as a temporary background image so we can easily line up the elements with CSS to replicate the grid based layout.

The HTML structure

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>OPTIK</title>

<link href="style.css" rel="stylesheet" />

</head>

<body>

</body>
</html>

The HTML file begins with a typical document structure of Doctype, page title, link to CSS stylesheet and the opening & closing body tags. The simple HTML5 Doctype really looks great when compared to the long versions of HTML4 and XHTML.

<div id="container">
	<header>
		<h1><a href="#"><img src="images/optik-logo.png" alt="Return to the homepage" /></a></h1>

		<nav>
			<ul>
				<li><a href="#">Sun</a></li>
				<li><a href="#">Sport</a></li>
				<li><a href="#">Tech</a></li>
				<li><a href="#">Special</a></li>
			</ul>
		</nav>
	</header>

A typical container div is added to ‘contain’ the elements to help centre everything up, then we can get stuck in to some fancy HTML5 tags/elements with <header>. As the name suggests, <header> is used to outline an introduction or group of navigation elements and is used in place of the traditional <div id="header"> code we usually use.
<nav> is another new element we can make use of, which identifies a section of navigation. Inside this element a normal unordered list lays out the four navigation links.

	<section id="feature">
		<a href="#"><img src="images/feature-image.jpg" alt="Man wearing Hydrotek sunglasses" /></a>
		<div id="feature-info">
			<a href="#"><h2>Hydrotek</h2></a>
			<p>HYDRO-TEK sports eyewear from OPTIK optimizes the flow of perspiration for an increased aerodynamic advantage over your competition.</p>
			<p class="btn"><a href="#">Find out more</a></p>
		</div>
	</section>

Where we would previously use divs to create major structural areas of a webpage, in HTML5 we can use the <section> tag. <section> is used along with an ID to identify a clear ‘section’ of the document, such as the feature area at the top of the page. The photo of the guy wearing sunglasses could be added as a background image, but I expect users to naturally try to click it, so adding it as an <img> inside an anchor will allow us to link it up to its relative content.
A <h2> and <p> elements semtantically lay out the few lines of content, with a class of ‘btn’ allowing us to style up that particular link as a button graphic later. All these elements will need floating next to the image, so a simple div helps group them all together.

	<section id="content">
		<div class="bucket">
			<a href="#" id="sun">Sun range of OPTIK eyewear</a>

			<p>Enjoy the summer sun in style with OPTIK's range of casual eyewear. Choose from an array of fashionable frames and styles.</p>

			<p><a href="#">View the SUN range</a></p>
		</div>

		<div class="bucket">
			<a href="#" id="sport">Sport range of OPTIK eyewear</a>

			<p>Protect and enhance your vision with the SPORT range of eyewear from OPTIK to give yourself the edge over your competition.</p>

			<p><a href="#">View the SPORT range</a></p>
		</div>

		<div class="bucket">
			<a href="#" id="tech">Technicaly information about OPTIK eyewear</a>

			<p>Find out more about the science behind the materials, geometry and coatings that make OPTIK lenses so technologically advanced.</p>

			<p><a href="#">View the TECH info</a></p>
		</div>

		<div class="bucket">
			<a href="#" id="special">Special range of OPTIK eyewear</a>

			<p>OPTIK also design eyewear for specific industries where eye protection is crucial. Make sure your team has the best optical safety.</p>

			<p><a href="#">View the SPECIAL range</a></p>
		</div>
	</section>

Another <section> tag outlines the main content area, followed by four separate divs with a class of ‘bucket’ to lay out the four boxes seen on the design concept. Inside each of these boxes the images will need adding with CSS to allow the sprite hover effects to work, so they are created in HTML as simple anchors with a descriptive anchor text introducing the section.

</div>

<footer>
	<p id="copyright">&copy; Copyright OPTIK 2011</p>
	<ul>
		<li><a href="#">About</a></li>
		<li><a href="#">Retailers</a></li>
		<li><a href="#">Corporate</a></li>
		<li><a href="#">Warranty</a></li>
		<li><a href="#">News</a></li>
		<li><a href="#">Contact</a></li>
	</ul>

	<p id="back-top"><a href="#">Back to top</a></p>

</footer>

</body>
</html>

The footer appears below the main content panel in the concept so the container div is closed before the <footer> tag opens. Just like <header>, <footer> is a new structural tag that replaces the old method of <div id="footer">.
The <ul> in the footer isn’t enclosed in a <nav> element because of guidelines in the HTML5 spec:

It is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases.

The complete HTML

View the complete HTML

The CSS styling

body, div, h1, h2, h3, h4, h5, h6, p, ul, ol, li, dl, dt, dd, img, form, fieldset, input, textarea, blockquote {
	margin: 0; padding: 0; border: 0;
}

body {
	font: 14px Helvetica, Sans-Serif; line-height: 24px; color: #a6a6a6;
	background: #000 url(images/bg-pattern.png);
}

#container {
	width: 960px; margin: 0 auto 24px auto; background: #000; /*background: url(images/grid.png) center top no-repeat;*/
	box-shadow: 0px 5px 45px #343434;
	-moz-box-shadow: 0px 5px 45px #343434;
	-webkit-box-shadow: 0px 5px 45px #343434;
}

a {
	color: #abe2ff; text-decoration: none;
}
	a:hover {
		color: #5db5e3;
	}

Onto the CSS! First we clean things up with a simple reset and declarations to the body to set the global styling. Then the container div is centered up and given the outer glow styling from the Photoshop concept with CSS3 box-shadow. Remember that grid used in Photoshop? We can add that as a temporary background image to allow us to align all the page elements exactly into place.

header h1 {
	margin: 54px 0 0 21px; float: left;
}

header nav {
	float: left;
	margin: 79px 0 17px 0;
}
	header nav ul li {
		float: left; list-style: none;
		width: 58px; margin: 0 0 0 98px;
	}
		header nav ul li a {
			text-transform: uppercase;
		}

Next up the header items are moved into place according to the grid with simple margins. This is where the Firebug plugin for Firefox comes in handy so you can edit the figures live in order to achieve pixel perfection.

#feature {
	clear: both; height: 431px; overflow: hidden; margin: 0 0 48px 0;
	background: #000;
	background: -moz-linear-gradient(top, #000 0%, #191919 5%, #000 5%, #000 94%, #191919 94%, #000 100%);
	background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#000), color-stop(5%,#191919), color-stop(5%,#000), color-stop(94%,#000), color-stop(94%,#191919), color-stop(100%,#000));
	background: -webkit-linear-gradient(top, #000 0%,#191919 5%,#000 5%,#000 94%,#191919 94%,#000 100%);
	/*opacity: 0.5;*/
}
	#feature h2 {
		width: 216px; height: 30px; margin: 0 0 31px 0;
		background: url(images/hydrotek.png); text-indent: -9999px;
	}
	#feature img {
		float: right; margin: 22px 0 0 0;
	}
	#feature-info {
		float: left; width: 370px; margin: 89px 0 0 100px;
	}
		#feature-info p {
			margin: 0 0 34px 0; font-size: 16px;
		}
		#feature-info p.btn a {
			display: block; width: 170px; height: 35px;
			background: #497389;
			background: -moz-linear-gradient(top, #497389 0%, #151e36 100%);
			background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#497389), color-stop(100%,#151e36), color-stop(100%,#000));
			background: -webkit-linear-gradient(top, #497389 0%,#151e36 100%);
			border: 1px solid #313e52;
			border-radius: 10px;
			-moz-border-radius: 10px;
			-webkit-border-radius: 10px;
			text-transform: uppercase; text-align: center; padding: 12px 0 0 0;
		}

We can really start going to town with CSS3 styling on the feature section. In the concept there’s a gradient glow above and below the feature area. We could replicate this in CSS3 with box-shadow or CSS gradients. Here I’ve gone for the gradient approach with the help of the handy CSS Gradient Generator tool, which makes it easy to match the format from Photoshop.
The <h2> uses a non-web font so a simple CSS image replacement technique switches the default H2 text for an image. The text content and image is moved into place, then the “btn” class is given some styling to convert it into a button style graphic. display:block; converts it into a block element so a width and height can be added, then another CSS gradient is generated to flow from dark to light blue. border-radius then rounds off the corners and the text is set to uppercase and bumped into position vertically using a touch of padding.
Tip: Use opacity: 0.5; as a temporary declaration on the feature section so you can see the underlying grid lines.

#content {
	overflow: hidden; clear: both;
}
	#content .bucket {
		width: 212px; float: left; margin: 0 0 48px 20px;
		border: 1px solid #262626;
		background: #000;
		background: -moz-linear-gradient(top, #000 0%, #000 39%, #191919 39%, #000 100%);
		background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#000), color-stop(39%,#000), color-stop(39%,#191919), color-stop(100%,#000));
		background: -webkit-linear-gradient(top, #000 0%,#000 39%,#191919 39%,#000 100%);
	}
		#content .bucket:first-child {
			margin: 0 0 0 22px;
		}

	#content #sun, #content #sport, #content #tech, #content #special {
		display: block; width: 212px; height: 143px;
		margin: 0 0 32px 0; text-indent: -9999px;
	}
		#content #sun { background: url(images/sun.jpg); }
		#content #sport { background: url(images/sport.jpg); }
		#content #tech { background: url(images/tech.jpg); }
		#content #special { background: url(images/special.jpg); }

		#content #sun:hover, #content #sport:hover, #content #tech:hover, #content #special:hover {
			background-position: 0 -143px;
		}

		#content .bucket p {
			margin: 0 0 24px 0; padding: 0 13px 0 13px;
		}

The four buckets in the content area can then be styled up with a specific width and margin and floated side by side. A simple border and another background gradient help replicate the shadow underneath the header images in the concept. To match the layout to the grid the first bucket’s margin is adjusted using the first-child selector.
All the header images can be grouped together for some general CSS such as the width, height and margin. text-indent: -9999px; shifts the default text off screen, then the specific background image for each link is added. These images has a hover state included in the basic sprite, so all anchors are set to move the background position on hover.

footer {
	width: 960px; margin: 0 auto; height: 80px;
	font-size: 12px;
}
	footer #copyright {
		float: left; margin: 0 0 0 22px;
	}

	footer ul {
		float: left; margin: 0 0 0 134px; list-style: none; overflow: hidden;

	}
		footer li {
			float: left; margin: 0 10px 0 10px;
		}

	footer #back-top {
		float: right; margin: 0 22px 0 0;
	}
		footer #back-top a {
			background: url(images/optik-logo-sm.png) left no-repeat; padding: 5px 0 5px 40px;
		}

Finally the footer area can be styled to finish off the page. Because it’s outside the container div it first needs moving into position with the 960px width and margin: 0 auto; declarations. Then each of the three elements can be floated side by side and moved into place with margins.

The complete CSS

View the complete CSS

Patching up IE

Needless to say, Internet Explorer doesn’t support these fancy new HTML5 and CSS3 goodies. Our CSS will simply degrade back to non CSS3 styling, so there will be no gradients or round corners. The HTML5 tags on the other hand won’t be recognised at all, which will bork the layout altogether. Luckily there’s a snippet of code you can add to the head of your page to render the tags as normal elements:

<!--[if IE]>
<script>
  document.createElement('header');
  document.createElement('footer');
  document.createElement('section');
  document.createElement('nav');
</script>
<![endif]-->

Then you can simply create a conditional stylesheet to fix up the mess IE makes of your standard CSS. With this tutorial being a HTML5/CSS3 demonstration, I’ll leave those exciting fixes for another time…

The final website design

View the demo

Our final coded website matches the original Photoshop concept identically with the help of a few CSS3 features and looks cool under the hood with the new HTML5 tags. Check out the demo in the latest Firefox, Safari or Chrome browsers.

View the HTML5/CSS3 website demo

May 16 2011

07:00

How To Build a Sliding Feature Slideshow with jQuery

Javascript slideshows are one of the best ways to display lots of information in a relatively small space while adding cool functionality to a web page. Let’s build our own slideshow with sliding panels navigatable by button links. You could use the slideshow to showcase featured content on your homepage, or as a simple image gallery. Either way it’s quick and easy to create with the help of a couple of handy jQuery plugins.

View the jQuery slideshow demo

Last year I created a slideshow of my dream motorcycle, a Harley Davidson Sportster. This time let’s base the slideshow on my dream car, a Lamborghini Gallardo (or Murcielago – I’m not fussy!). Last time we built the slideshow with an automatic cycling effect with manual controls. This time we’ll create a sliding effect with navigation buttons that allow the user to jump immediately to any slide.

View the jQuery slideshow demo

How it works

The slideshow we’ll be building is created from some simple HTML and CSS, then the cool sliding functionality is powered by the jQuery Javascript library. The LocalScroll and ScrollTo plugins by Ariel Flesler in particular are what provide the underlying effects, with just a few lines of our own code being needed to activate the plugins and put everything into play.
LocalScroll and ScrollTo work hand in hand to provide the overall slideshow functionality. LocalScroll allows the anchors to jump the slideshow to the correct slide according to the targeted ID, while ScrollTo provides the cool sliding functionality to smoothly transition the slides rather than simply jump between them.

We want to keep basic accessibility in mind when building the slideshow, so the user will still be able to navigate and view all the slides even when Javascript is turned off. This means we’ll have to get the basic HTML and CSS in place first, before tarting it all up with jQuery.

The HTML structure

View the HTML code

The HTML for the demo page begins with the usual items of Doctype, title and link to CSS stylesheet. The jQuery library, the two plugins and our own empty scripts.js file can then be linked up so they’re ready to bring the slideshow to life later.
The HTML that makes up the actual slideshow is split into two sections, a div with an ID of slideshow and one with and ID of slideshow-nav. The slideshow div contains an unordered list of linked images, with with <li> having an ID that corresponds to the slideshow-nav anchors below.
Viewing the page in a browser without any CSS or Javascript will show a crude version of the slideshow where the links will jump the page to the correct image.

The CSS styling

View the CSS code

The CSS will style the page into something them resembles a slideshow. First the width and height of the slideshow div is set to the same dimensions as the image slides. Each of these slides is floated side by side, making the total width of the unordered list 4590px (918px x 5 images). To prevent this long line of images running across the whole page the overflow property is used. In the CSS we’ll set it to overflow: scroll; so the slideshow will still work without Javascript, albeit with an ugly scrollbar rather than the cool sliding functionality.
To finish off the demo a cool shadow is added using CSS3 box-shadow.

View the CSS code

The slideshow-nav div is then moved into position underneath the main slideshow section. These buttons will only be used along with the Javascript version, so we don’t want a series of buttons that don’t work appearing if the user doesn’t have Javascript enabled. visibility: hidden; will hide these buttons by default, then we can make them visible again later if the user has Javascript turned on.
The anchors of each of the navigation list are then transformed into circular buttons using CSS3 border-radius and the default text shifted off screen with negative text-indent. Non-supporting browsers will see a square button instead, but to keep things super compatible across all browsers a simple image could have been used.

Slideshow without Javascript enabled

The slideshow so far can be seen in a working state without Javascript with just the crude scroll bar allowing the user to move back and forth between the images. The majority of Javascript slideshows on the web break when Javascript is disabled, leaving buttons that don’t work and content that can’t be accessed, so we’ll get extra accessibility points when our content is still viewable.

The jQuery functionality

View the jQuery code

Before getting into the main slideshow functionality we have a little housekeeping to set things up for users with Javascript enabled. First the CSS of the slideshow div is changed from overflow: scroll; to overflow: hidden; to remove that scrollbar. Then the visibility of the nav buttons is set to visible and an ‘active’ class is automatically added to the first button.

The LocalScroll and ScrollTo plugins are then activated with one simple line. We’re applying the localScroll functionality to the slideshow-nav items and telling them to target the slideshow items by moving them along the X axis. There’s plenty more options to choose from including various easing effects, but this is basically all we need to get things up and running.

Finally we want to make sure our buttons light up with the relevant active class whenever they’re clicked, so a simple jQuery rule removes the active class from all buttons then adds it to whichever anchor was clicked. This active class then appears in the CSS stylesheet to give the button a grey background fill.

The complete jQuery slideshow

View the jQuery slideshow demo

A quick test in the browser shows the complete slideshow working in all its jQuery glory. Slides will smoothly transition between each other and the navigation buttons will highlight according to the active slide. Our slideshow not only looks great here, but also degrades and is still accessible even if Javascript and CSS is turned off. Users with older browsers will see the slideshow too, with just fancy CSS3 touches of box-shadow and border-radius not being visible, but they’ll probably never know what they’re missing!

Feel free to view source and copy/paste the HTML, CSS and jQuery from the demo for use in your own projects. Don’t forget to download the awesome jQuery plugins of LocalScroll and ScrollTo from Arial Flesler.

View the jQuery slideshow demo

April 04 2011

07:00

CSS Basics: How to Design & Code a Stylish Button

Some of my most popular articles and tutorials are those that cover the basics. In this post we’ll go through the process of designing a stylish button graphic in Photoshop, then build a complete working example in HTML and CSS. We’ll be looking at pseudo selectors in particular to create hover and active states for the button.

View the CSS button demo

The button we’ll be designing is built with lots of detail to create a semi-realistic three dimensional appearance. The button has three states – normal, hover and active. In the normal state the button is made entirely of blue, when hovered the text within the logo turns to purple, then when the button is clicked it moves to give visual feedback that relates to how a button would react in real life.

View the CSS button demo

The Photoshop concept

Open up Adobe Photoshop and create a new document. Fill the background with grey and add a white highlight to the centre using a soft brush. On a new layer draw a rounded rectangle with 10px corner radius.

Double click the layer to open up the Layer Styles window and add a Gradient Overlay. Enter the colours #0730a5 and #a4c9f3 then adjust the angle to 90 degrees.

Give the button an Inner Shadow to create more of a three dimensional appearance. Adjust the settings to 2px Distance and 9px Size using the colour #d9f7ff.

Add a thin 1px Stroke to the inside using the colour #8eb4f2 to give the button a fine outlining border.

Finally, use the Drop Shadow feature to add a fine 1px highlight on the bottom edge. Change the settings to Normal, 100% Opacity, 90 degrees, 1px Distance and 0px Size using the colour #4285bd;

Create a new layer underneath the current button and draw another rounded rectangle. Match the new rectangle to the top and sides but extend it slightly on the bottom edge.

Add a Gradient Overlay layer style to this new rectangle. Use the colours #174994 and #3c64bf at the outer edges of the gradient bar to create realistic shading.

Give this lower button shape a thin 1px Stroke with the colour #315a99. Align the stroke to the Center.

Finally add a soft Drop Shadow to create more shading to provide a touch of realism to the design. Adjust the settings to 30% Opacity, 5px Distance and 18px Size.

Use the Text tool to add some wording to the button, then give the text a Gradient Overlay using the colours #3062ae and #557ac9.

Add an Inner Shadow to the text to give it an inset appearance. Use the settings #5c8fdf, 100% Opacity, 3px Distance and 4px Size.

Finish off the inset effect by adding a highlight to the bottom edge. This is done using the Drop Shadow feature with the settings Normal, #8eb4f2, 100% Opacity, 90 degrees, 1px Distance and 1px Size.

Group all the elements that make up the button, then duplicate the group. CMD+Click the text layer and fill a new layer with purple (#6c3a9c).

Change this layer’s blending mode to Color. This variation of the button will appear when the button is hovered by the cursor.

Duplicate the group again, this version will be the active state when the button is pressed. Move the upper layer of the button downwards.

Draw a selection around the excess left above the button and nudge it downwards to match the outline. This essentially shortens the button’s height.

Toggle off the background layers and draw a selection around the button. Toggle on just the normal button layer group and Copy Merged (CMD+Shift+C).

Copy and Paste all three button states into a new file. Each selection should be exactly the same size. Save this file for web as a PNG-24 with alpha transparency.

The HTML structure

View the HTML code

Being a demo file with just one button the HTML is very simple. First we start with the basic document structure of Doctype, title and link to the CSS stylesheet. The container div will help centre up our demo while the actual button is created from a simple anchor. This <a> is given a class of “btn” so it can be targeted for special CSS treatment.

The CSS styling

View the CSS code

The CSS stylesheet begins with a simple CSS reset to remove the browser defaults from the elements in use. The demo file is then set up with the grey background and centred container div.

View the CSS code

The anchor with the class of btn is targeted with CSS using a.btn. It is first converted from an inline element to a block element to allow for a width and height to be added and furthermore to increase the clickable area. The height of the anchor matches the height of a single button graphic in the sprite image, creating a kind of window which will mask the other two button states. The image sprite is added as a background image and text-indent: -9999px; used to shift the default text off screen.

The different button states are created using CSS pseudo selectors. For anchor elements these include :hover, :active, :visited and :focus. The background image is shifted into place for both the :hover and :active states for the button to show the relevant image in each sitation.

If you test the button in the browser you’ll see an ugly dotted border around the element. This can be fixed using overflow: hidden; to prevent the border extending across the page, or it can be removed altogether by adding outline: none; to all anchor elements. Remember that this visual cue is important for users browsing with a keyboard and/or screenreader, so a backup should be provided using the :focus selector. By adding the :focus selector to the same code as :hover, we can simply replicate the visual change on both mouse hover and keyboard focus.

The final CSS button demo

View the CSS button demo

Check out the demo to see the complete CSS button in action. Notice how the default blue button state is shown until it is hovered by the mouse. The text then changes to purple, then if the button is clicked, the :active state switches the background image to give the impression that the button has been physically pressed.

View the CSS button demo

March 29 2011

14:00

4 Tips and Tricks for more Legible Content

These tips and tricks will help you design more readable content for screen readers.

These tips and tricks will help you design more readable content for screen readers.

Readability & legibility are both areas of interest in accessibility and typographic design, and many resources exist that attempt to define what constitutes well designed copy. In this post, we go over a few commonly overlooked and newer ways to implement more legible type on the web.

1. Add Text-Shadow to Custom Fonts

With a growing number of web fonts to choose from, and new ways to implement custom fonts into sites using CSS instead of Javascript or Flash, it’s becoming increasingly popular to stray from traditional common fonts in exchange for fonts that help define a more unique and consistent brand.

This is great for many reasons, and quite a few font foundries have already begun selling web font licenses making the potential for custom fonts substantial. However, for the time being, there are drawbacks.

Perhaps the most overlooked problem about using these custom fonts is how different devices go about rendering fonts differently. Some devices such as recent Apple computers apply font antialiasing that strongly favors reproducing pixel-perfect letter forms, while other systems (such as Windows computers) render font in a way that favors more legible characters at the cost of non-precise letter forms. In short, this means that fonts look considerably different on Apple and Windows operating systems.

For many common web fonts, this isn’t a big concern. These fonts render well on the web as they are. For newer custom web fonts, this becomes a concern as they will not always render as expected across different devices (or even across different browsers). For instance, take a look at how the Typekit font library renders between different setups:

Browsers that use the default font rendering system implemented in Windows sometimes render custom fonts with seemingly jagged edges.

There seem to be several popular views on this specific inconsistency across browsers and operating systems. Some believe that letterforms should be optimized for legibility, while others prefer an approach where letters are reproduced as they were intended to be displayed. Others suggest that the problem lies with fonts that don’t have proper hinting.

Whatever the case, there is a simple way to create smooth custom fonts in some instances despite font rendering implementations. By simply adding a 1px or greater text shadow, custom fonts will often become much more legible on configurations like Chrome on Windows 7. Take a look at the example below:

In this example, Droid Serif is rendered using no text shadow (top) and a 1px transparent text shadow (below).

This is easily implemented in CSS:

      h1 { /* Your selector */
      	font-family:"Some Custom Font", serif;
        text-shadow:0 0 1px transparent;

        /* Or, if you need to apply a 0px hard shadow,
         * you can use multiple text shadows */
        text-shadow:0 0 0 #f00, 0 0 1px transparent;
      }
      

In the future, it is likely that this issue will be solved with CSS properties such as font-smoothing, or by browsers implementing their own font rendering engines. For instance, IE9 has made huge improvements to its own font rendering with hardware-acceleration, which makes use of “DirectWrite, ClearType, and sub-pixel positioning to improve font quality and readability“. Until becomes less of an issue, it should be noted that using text-shadows isn’t a fix that works 100% of the time. Some fonts will simply not render well between devices and browsers at all sizes, and should be tested to ensure content can be read effectively (especially in long copy).

2. Use the “text-rendering” CSS property

This is another relatively new way CSS property, with limited browser support. By using the text-rendering property, it is possible to favor rendering speed, legibility, and in the future it should also be possible to emphasize geometric precision of rendered type.

Currently, text-rendering can be used to optimize legibility in Webkit and Firefox 3. By setting the property’s value to “optimizeLegibility”, the user agent will emphasize legibility, sometimes by enabling ligatures, or adjusting kerning in type.

Anthony Kolber has put together a useful demo for seeing how optimizeLegibility affects type at large sizes.

3. Choosing number of words/characters per line

Determining an ideal number of characters per line and accompanying line space is a subject of much debate. While some suggest that 45-75 characters per line is the ideal length, other studies show that longer line lengths can result in faster reading speeds. At the same time, it’s suggested that while longer lines may result in faster reading speeds, users report that they actually prefer shorter line lengths.

Perhaps there really is an ideal number of characters per line and we simply haven’t found it yet (or at least agreed on it), but it’s almost assuredly related to other properties such as line spacing. Line spacing (leading), or line height, determines the height of a line of text. A taller line height means more space between lines.

Line spacing can greatly influence the appearance of large blocks of text.

Depending on the font being used, the size of the font, and other properties, it may be necessary to tweak line-height, but it’s generally accepted that longer lines require more leading. Adjusting the line-height of blocks of text is very simple using CSS:

      p { /* Your selector */
      	line-height:24px; /* This could also use other units such as "em" */
      }
      

4. Choosing text with appropriate contrast

Choosing appropriate font and background combination colors/brightness is another subject of debate for screen media. A point that is generally agreed upon is that text must meet a minimum contrast ratio in order to be read effectively by a large audience.

According to the Web Content Accessibility Guidelines 2.0 (WCAG20), text should have a minimum contrast ratio of 4.5:1:

A contrast ratio of 3:1 is the minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988] for standard text and vision. The 4.5:1 ratio is used in this provision to account for the loss in contrast that results from moderately low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity that typically accompanies aging.

w3.org

Determining the contrast ratio of two colors (text and background color) is easily done with an online tool. Contrast ratio is determined by comparing the relative luminance of the text and background colors.

While these rules imply that higher contrast ratios are ultimately better, some people suggest that too high of contrast actually hurts to read, and use off-white backgrounds, or off-black text instead of 100% black on white. There is however not much quantitative data in this regard. A few sources claim that too much contrast can be difficult for dyslexic readers to view. With these considerations in mind, some designers opt to use #333 instead of #000 (or similar off-blacks) in attempt to make reading more pleasant.

An example of using off-black (#333) text on a white background from the Google Blog.

Useful resources

The Elements of Typographic Style is applauded by many as an incredibly useful resource for graphic and typographic designers. Robert Bringhurst does a wonderful job teaching the fundamentals of typographic style, and much of the information presented in the book can be useful when designing for the web.

WCAG 2.0 provides recommendations for making web content more accessible. While it isn’t exactly loved by everyone, guidelines offered by WCAG still seem to be useful for the most part.

The Effects of Line Length on Reading Online News is a study that examines “the effects of line length on reading speed, comprehension, and user satisfaction of online news articles”. While this is an interesting read, the study only samples twenty college-age students, which could easily not make it relevant for all readers.

March 07 2011

07:00

Create a Stylish Contact Form with HTML5 & CSS3

Follow this step by step process to create your own stylish contact form completely out of HTML5 and CSS3. We’ll be using a couple of the handy new features in HTML5 to add cool functionality to our form, while making use of cool CSS3 properties to recreate our Photoshop concept purely in code.

View the HTML and CSS form demo

The design we’ll be building features all the things that make a rich interface; gradients, highlights and shadows! We’ll create a visual concept in Photoshop first of all, but when it comes to building the form we’ll recreate every effect with HTML5 and CSS3.

View the HTML5/CSS3 form demo

The PSD Concept

Open up Photoshop and create a new document. Add a dark to light blue gradient to the background, then draw a rectangle in the centre to contain the form.

Use Photoshop layer styles to add a subtle drop shadow at around 30% opacity and a thin 1px stroke using a very light grey.

Add a title to the design using the darker blue colour swatch. Spruce up this text with a inset effect by tweaking the Drop Shadow settings to create a 1px light grey outline along the bottom edge of the text.

Use the same font styling on each of the labels, then draw a rounded rectangle with 5px corner radius to create an input field. Add a soft Inner Shadow to add depth to the design.

Copy the elements to lay out the form with a series of input fields, then a slightly larger text area.

Modify one of the input fields to visualise how the field would look when in use. Give it a lighter blue colour overlay and style up the text with an inset shadow. Use the Drop Shadow feature so the shadow appears on the outside of the text (not the inside as Inner Shadow does). Remember to uncheck the Use Global Light option so the -90 degree angle doesn’t also affect all the other gradients.

Add lines of text inside the other fields to represent the placeholders, but give them a darker blue fill to lower their contrast against the input fields.

Draw a smaller button shape with the rounded rectangle tool and style it up with a gradient, thin 1px stroke and a subtle shadow.

The visual concept is now complete. We won’t be using any of the graphics as background images, but the PSD will be handy to refer back to for Hex colour codes when recreating the design in CSS.

The HTML5 Structure

View the HTML code

Every web project starts with the HTML structure. Here we’ll be using some fancy HTML5 features to spice up the design. Lay out a basic document structure with Doctype and CSS stylesheet link. House the contact form inside a contaning div so we can centre it up in the demo. Each label element should have a for attribute that relates to an ID of each input field – This boosts the accessibility of the form and allows the user to click the label to activate the correct field.
One new HTML5 feature we’re making use of is the placeholder attribute. Simply enter your desired message and it will appear in each field, when the user has focus on that field the text is automatically cleared. This feature is currently only supported in Safari and Chrome, but is soon to appear in Firefox4.

The CSS Styling

View the HTML code

The CSS stylesheet first sets up the basic document with a reset to remove any browser defaults, then the body is given the blue gradient using CSS3. Currently different code is required for Webkit and Mozilla, but the handy CSS3 Gradient Generator website helps save time.
The containing div is given specific dimensions and centred up using margin: 0 auto;, then the shadow and stroke from Photoshop is replicated using box-shadow and a border.
Basic CSS font styling matches up the text to the concept, then the CSS3 text-shadow property replicates the inset text effect by adding a 1px highlight to the bottom edge.

View the HTML code

Continuing on, the label elements are given similar styling to the h1, then the input elements are styled up with dimensions and padding to match the Photoshop concept. CSS3 gradients come into play once again to recreate the inner shadow effect, simply adjusting the location of the gradient handles can create the impression of subtle shading.
The HTML5 placeholders can also be targeted using vendor specific CSS for both Webkit and Mozilla. The colours for these placeholders are colour picked from the PSD concept.
The CSS used on the input elements can be copied directly onto the textarea, the only difference being the larger height dimensions.

View the HTML code

To give the user visual feedback when the input elements are active, the :focus pseudo selector can be used to give the fields different CSS styling. Here the CSS3 gradients are adjusted using lighter blue colours.
The submit button will currently be styled with the generic CSS used on the input fields, so to target this field in particular the [type=submit] advanced selector is used to attach unique styling to this element in particular. Such styling includes a different width and height, a new gradient background, a subtle box-shadow and a thin 1px border. cursor: pointer; is then added to make the button seem clickable by displaying the ‘pointer’ style of cursor when the element is hovered.

The Complete Code

HTML

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>CSS3 Contact Form</title>

<link href="style.css" rel="stylesheet" type="text/css" media="screen" />
</head>

<body>

<div id="contact">
	<h1>Send an email</h1>
	<form action="#" method="post">
		<fieldset>
			<label for="name">Name:</label>
			<input type="text" id="name" placeholder="Enter your full name" />

			<label for="email">Email:</label>
			<input type="email" id="email" placeholder="Enter your email address" />

			<label for="message">Message:</label>
			<textarea id="message" placeholder="What's on your mind?"></textarea>

			<input type="submit" value="Send message" />

		</fieldset>
	</form>
</div>

</body>
</html>

CSS

body, div, h1, form, fieldset, input, textarea {
	margin: 0; padding: 0; border: 0; outline: none;
}

html {
	height: 100%;
}

body {
	background: #728eaa;
	background: -moz-linear-gradient(top, #25303C 0%, #728EAA 100%); /* firefox */
	background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#25303C), color-stop(100%,#728EAA)); /* webkit */
	font-family: sans-serif;
}

#contact {
	width: 430px; margin: 60px auto; padding: 60px 30px;
	background: #c9d0de; border: 1px solid #e1e1e1;
	-moz-box-shadow: 0px 0px 8px #444;
	-webkit-box-shadow: 0px 0px 8px #444;
}

h1 {
	font-size: 35px; color: #445668; text-transform: uppercase;
	text-align: center; margin: 0 0 35px 0; text-shadow: 0px 1px 0px #f2f2f2;
}

label {
	float: left; clear: left; margin: 11px 20px 0 0; width: 95px;
	text-align: right; font-size: 16px; color: #445668;
	text-transform: uppercase; text-shadow: 0px 1px 0px #f2f2f2;
}

input {
	width: 260px; height: 35px; padding: 5px 20px 0px 20px; margin: 0 0 20px 0;
	background: #5E768D;
	background: -moz-linear-gradient(top, #546A7F 0%, #5E768D 20%); /* firefox */
	background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#546A7F), color-stop(20%,#5E768D)); /* webkit */
	border-radius: 5px; -moz-border-radius: 5px; -webkit-border-radius: 5px;
	-moz-box-shadow: 0px 1px 0px #f2f2f2;-webkit-box-shadow: 0px 1px 0px #f2f2f2;
	font-family: sans-serif; font-size: 16px; color: #f2f2f2; text-transform: uppercase; text-shadow: 0px -1px 0px #334f71;
}
	input::-webkit-input-placeholder  {
    	color: #a1b2c3; text-shadow: 0px -1px 0px #38506b;
	}
	input:-moz-placeholder {
	    color: #a1b2c3; text-shadow: 0px -1px 0px #38506b;
	}

textarea {
	width: 260px; height: 170px; padding: 12px 20px 0px 20px; margin: 0 0 20px 0;
	background: #5E768D;
	background: -moz-linear-gradient(top, #546A7F 0%, #5E768D 20%); /* firefox */
	background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#546A7F), color-stop(20%,#5E768D)); /* webkit */
	border-radius: 5px; -moz-border-radius: 5px; -webkit-border-radius: 5px;
	-moz-box-shadow: 0px 1px 0px #f2f2f2;-webkit-box-shadow: 0px 1px 0px #f2f2f2;
	font-family: sans-serif; font-size: 16px; color: #f2f2f2; text-transform: uppercase; text-shadow: 0px -1px 0px #334f71;
}
	textarea::-webkit-input-placeholder  {
    	color: #a1b2c3; text-shadow: 0px -1px 0px #38506b;
	}
	textarea:-moz-placeholder {
	    color: #a1b2c3; text-shadow: 0px -1px 0px #38506b;
	}

input:focus, textarea:focus {
	background: #728eaa;
	background: -moz-linear-gradient(top, #668099 0%, #728eaa 20%); /* firefox */
	background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#668099), color-stop(20%,#728eaa)); /* webkit */
}

input[type=submit] {
	width: 185px; height: 52px; float: right; padding: 10px 15px; margin: 0 15px 0 0;
	-moz-box-shadow: 0px 0px 5px #999;-webkit-box-shadow: 0px 0px 5px #999;
	border: 1px solid #556f8c;
	background: -moz-linear-gradient(top, #718DA9 0%, #415D79 100%); /* firefox */
	background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#718DA9), color-stop(100%,#415D79)); /* webkit */
	cursor: pointer;
}

The Final HTML5/CSS3 Form

View the HTML and CSS form demo

Preview the final web page in your browser to see the form completely rendered in HTML and CSS. Browsers such as Safari and Chrome will see every detail, whereas Firefox won’t see the placeholders until the release of Firefox 4. The styling will slowly degrade as we go through Internet Explorer until we see a basic and flat form, but the overall functionality is still usable and accessible.

View the HTML5/CSS3 form demo

January 24 2011

07:00

How To Create a Cool Animated Menu with jQuery

In this tutorial we’ll be building a cool navigation list complete with a sliding hover effect. Learn how to build the concept in Photoshop, lay out the basic HTML elements, style everything up in CSS then tie it all together with a few lines of jQuery to create a semantic, accessible and degradable menu design.

View the animated menu demo

The design we’ll be building features a cool label image that slides into place under each navigation item on hover. We’ll build the design to work without jQuery first of all to ensure it’s widely accessible to users without Javascript enabled, then enhance the effect with jQuery for the majority of users.

View the animated menu demo

Build the Photoshop concept

Create a new document and fill the background with a light beige. Add a subtle 1.5% noise texture by going to Filter > Noise > Add Noise.

Use a subtle grunge Photoshop brush to add a little extra texture to the top centre of the canvas. Adjust the opacity to tone down the distressed effect.

Draw and fill a rectangle to create the base of the label graphic. Press CMD+T to transform the shape, then drag a guide to highlight the centre point.

Use the Polygonal Lasso tool to draw a small triangle. Use this triangle to clip out the bottom edges. Flip the selection horizontally and align with the guide to ensure the clipping is symmetrical.

Begin adding a range of Layer Style effects to bring the label to life. Start with a Gradient Overlay to add a range of dark to light red tones.

Add a thin stroke using a dark red colour selection with settings of 2px width and aligned to the inside.

Set up an Inner Glow using a slightly lighter red with 100% opacity, Normal blending mode, 50% Choke and 3px in size.

Add a soft Drop Shadow aligned to 90 degrees to give the impression of depth. Reduce the opacity to around 20% to tone down the effect.

Finish off the label with a distressed texture using the subtle grunge brushes. Load the selection of the label shape, inverse and delete out the excess. Change the blending mode to Lighter Color at 35%.

All the menu needs now is a series of text links. Set the fonts up with Helvetica Bold and choose a fill colour from the label. Simulate the hover effect by switching the fill to beige on the active link.

Make a selection of the label graphic and export the image as a PNG24 file with Alpha transparency.

The demo file uses just three images: A textured background image, the red label graphic and a repeating noise texture.

Create the basic HTML structure

View the HTML code

The basic menu system first needs to be laid out as a HTML skeleton. Begin the page with a Doctype, followed by page title and a link to the CSS stylesheet. Write out the menu itself as a good old Unordered List element, with each <li> item containing an anchor.

Style up the design with CSS

View the CSS code

Next, the CSS brings the design to life. Begin the CSS file with a quick reset to remove any default browser styling, then set up the surrounding page design by adding the repeating noise background texture to the page body. Centre up the <ul> with margin: auto; and text-align: center; and clear the element using overflow: hidden;.
Float each <li> item to the left to place each nav item side by side. The rest of the styling can then go directly onto the anchors. Each anchor needs to have the exact dimensions of the label graphic, taking into consideration any padding used to position the text into place. Replicate the font styling from Photoshop using the same bold Helvetica styling, and use the CSS3 text-shadow property to recreate the Photoshop Drop Shadow. Finally, add the label graphic as a background image and set the position to -149px so it is hidden off screen until the mouse hovers the nav item.
Set up the styling for the :hover effects by moving the background back into position and alter the colour of the font and shadow to ensure they can still be seen when the background colour changes.

A preview of the HTML file so far will show a fully working menu design, albeit with basic CSS styling where the label immediately appears and disappears without any cool sliding effects. It’s important to first develop this basic fall back so users without Javascript enabled will still see a hover effect.

Spice up the effect with jQuery

View the Javascript code

In order to add some fancy Javascript effects we first need to head back to the HTML file and link up some JS files. We’ll require three files: The jQuery library, a handy plugin allowing background position animation, and finally our own blank scripts.js file where we’ll write our own code.

View the jQuery code

The first thing to add to our jQuery code is a simple line to turn off the basic CSS effect. Adding a special ‘.js’ class to the anchor with Javascript allows us to add an extra line of CSS to overwrite the original styling. With this out of the way we can then style the actual sliding hover effect. Add a hover function to the anchors within the menu list. On hover, use .animate() to set the backgroundPosition to 0 0, then back off screen on hover-out. A speed of 200 keeps things nice and swift. One extra snippet to add is a .stop(true,true) to prevent the effect looping if the mouse passes over the menu quickly.

View the extra jQuery code

A preview of the effect in the browser will show the label sliding in and out on hover. We can add one extra line to really spruce up the effect. Adding an extra animation to move the label by just 5px creates a cool little bounce effect. Similar effects can also be achieved using easing plugins, but to save linking up extra files this little trick works nicely.

The complete HTML, CSS & jQuery code

HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Animated Label Navigation Menu</title>

<link href="style.css" rel="stylesheet" type="text/css" media="screen" />

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js" type="text/javascript"></script>
<script src="js/animate-bg.js" type="text/javascript"></script>
<script src="js/scripts.js" type="text/javascript"></script>
</head>

<body>

<div id="container">
	<ul id="nav">
		<li><a href="#">Home</a></li>
		<li><a href="#">About</a></li>
		<li><a href="#">Work</a></li>
		<li><a href="#">Contact</a></li>
	</ul>
</div>

</body>
</html>

CSS

body, div, h1, h2, h3, h4, h5, h6, p, ul, ol, li, dl, dt, dd, img, form, fieldset, input, textarea, blockquote {
	margin: 0; padding: 0; border: 0;
}

body {
	background: #f5f0e0 url(images/noise.png);
}

#container {
	height: 800px;
	background: url(images/bg.jpg) center top no-repeat;
}

ul#nav {
	width: 700px; margin: 0 auto; text-align: center; overflow: hidden;
}
	ul#nav li {
		float: left; list-style: none;
	}
		ul#nav li a {
			display: block; width: 97px; height: 77px;
			padding: 72px 0 0 0; margin: 0 32px 0 32px;
			font: bold 16px Helvetica, Arial, Sans-Serif; text-transform: uppercase;
			color: #9c5959; text-shadow: 0 1px 3px #c4bda6; text-decoration: none;

			background: url(images/label.png) 0 -149px no-repeat;
		}
			ul#nav li a:hover {
				background: url(images/label.png) 0 0 no-repeat;
				color: #eee9d9; text-shadow: 0 2px 3px #4c2222;
			}

			ul#nav li a.js:hover {
				background: url(images/label.png) 0 -149px no-repeat;
			}

jQuery

$(document).ready(function() {
	$("ul#nav li a").addClass("js");
	$("ul#nav li a").hover(
      function () {
        $(this).stop(true,true).animate({backgroundPosition:"(0 0)"}, 200);
        $(this).animate({backgroundPosition:"(0 -5px)"}, 150);
      },
      function () {
        $(this).animate({backgroundPosition:"(0 -149px)"}, 200);

      }
    );

});

The final animated menu design

View the animated menu demo

View the animated menu demo

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
Get rid of the ads (sfw)

Don't be the product, buy the product!

Schweinderl