Smashing Magazine Feed

Desktop Wallpaper Calendar: June 2012

2012-05-31T13:04:51Z

We always try our best to challenge your artistic abilities and produce some interesting, beautiful and creative artwork. And as designers we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered the best one—desktop wallpapers that are a little more distinctive than the usual crowd.

This creativity mission has been going on for over four years now, and we are very thankful to all designers who have contributed and are still diligently contributing each month. This post features free desktop wallpapers created by artists across the globe for June 2012. Both versions with a calendar and without a calendar can be downloaded for free. It’s time to freshen up your wallpaper!

Please note that:

All images can be clicked on and lead to the preview of the wallpaper,
You can feature your work in our magazine by taking part in our Desktop Wallpaper Calendar series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?

Without Angry

"This bird is cool not angry :-)." Designed by Tinjo Thomas from India.

preview
with calendar: 320×480, 1024×1024, 1280×1024, 1366×768, 1440×900, 1680×1050, 1920×1080
without calendar: 320×480, 1024×1024, 1280×1024, 1366×768, 1440×900, 1680×1050, 1920×1080

Hello Summer

"Flying people are saying hello to summer." Designed by Paul Capcan from Moldova.

preview
with calendar: 320×480, 1024×1024, 1280×800, 1280×1024, 1920×1080, 1920×1200
without calendar: 320×480, 1024×1024, 1280×800, 1280×1024, 1920×1080, 1920×1200

Chromatic Baba

"Baba(sadhu) is the Hindu ascetic who has renounced caste, social position, money, and authority and occupies a special place in Hindu society.He absorbed all colors from a spiritual life, devoid of material pleasure, mostly engaged in visiting holy places." Designed by Yoshita Singhai from India.

preview
with calendar: 320×480, 1024×768, 1024×1024, 1280×800, 1280×1024, 1440×900, 1680×1050, 1920×1080, 1920×1200
without calendar: 320×480, 1024×768, 1024×1024, 1280×800, 1280×1024, 1440×900, 1680×1050, 1920×1080, 1920×1200

Fontstache

"This piece pays homage to Mr. Roger Hargreaves, creative kids author to such imaginative stories as Mr. Messy and my personal favourite: Mr. Bounce.We utilized the ‘Curly Brackets’ and titled each according to the font type that was used. Appropriate for the month of June as we celebrate Father’s Day this month." Designed by Pop Up Factory from Milton, Ontario, Canada.

preview
with calendar: 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440
without calendar: 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1400×1050, 1440×900, 1600×1200, 1680×1050, 1680×1200, 1920×1080, 1920×1200, 1920×1440, 2560×1440

Go Nuts For Donuts

preview
with calendar: 1366×768, 1280×800, 1440×900, 1680×1050, 1920×1200
without calendar: 1366×768, 1280×800, 1440×900, 1680×1050, 1920×1200

Brjs – Playing Cards

preview
with calendar: 320×480, 1024×1024, 1280×800, 1366×768, 1440×900, 1680×1050, 1920×1080, 1920×1200
without calendar: 320×480, 1024×1024, 1280×800, 1366×768, 1440×900, 1680×1050, 1920×1200

Sunset In Jamaica

"Photo from a recent trip to Jamaica edited to give a retro look and feel." Designed by Tommy Digiovanni from USA.

preview
with calendar: 320×480, 1024×768, 1024×1024, 1280×720, 1280×800, 1280×1024, 1680×1050, 1920×1080, 1920×1200, 2560×1440
without calendar: 320×480, 1024×768, 1024×1024, 1280×720, 1280×800, 1680×1050, 1920×1080, 1920×1200, 2560×1440

Beach

preview
with calendar: 320×480, 1024×768, 1024×1024, 1280×800, 1280×1024, 1440×900, 1680×1050, 1920×1200
without calendar: 320×480, 1024×768, 1024×1024, 1280×800, 1280×1024, 1440×900, 1680×1050, 1920×1200

Dreams

"This is the summer of dreams. Go get them!" Designed by Nandor Tamas from USA.

preview
with calendar: 1280×720, 1280×1024, 1440×900, 1680×1050, 1920×1080
without calendar: 1280×720, 1280×1024, 1440×900, 1680×1050, 1920×1080

Friendly Fire

preview
with calendar: 1280×720, 1280×800, 1366×768, 1440×900, 1680×1050, 1920×1080, 1920×1200
without calendar: 1280×720, 1280×800, 1366×768, 1440×900, 1680×1050, 1920×1080, 1920×1200

June Romance

"Mark and Jenny Linn are, perhaps, the dreamiest and the most romantic couple in the whole world. Their love story began in a vintage San Francisco bookstore 5 years ago and continues till the present day. In June Mark and Jenny usually arrange aspecial dinner to watch the night sky and make a common wish for the future, while watching the falling star." Designed by Maria S. from USA.

preview
with calendar: 1024×768, 1024×1024, 1280×800, 1280×1024, 1366×768, 1680×1050, 1920×1080, 1920×1200
without calendar: 320×480, 1024×768, 1024×1024, 1280×800, 1280×1024, 1366×768, 1680×1050, 1920×1080, 1920×1200

Basketball Nagraj

"Nagraj is an comic superhero in India. In this wallpaper i shows “Nagraj with BasketBall”. I made this a little fun because in india june is a Holiday season for children.Hi,It’s my first time i am submitting my wallpaper in smashing magazine. I hope you like the concept. In this i show Nagraj as a basketball. Nagraj is an comic superhero in India. I made this a little funny because in india june is a Holiday season for children." Designed by Sandeep Virk from India.

preview
with calendar: 1024×768, 1024×1024, 1280×800, 1680×1050, 1920×1080, 1920×1200
without calendar: 1024×768, 1024×1024, 1280×800, 1680×1050, 1920×1080, 1920×1200

Retro Smile

"This is the retro photography of my aunt from 1964 photographed in the beautiful village near the city Nis in Serbia." Designed by Marija Zaric from Serbia.

preview
with calendar: 1024×768, 1280×800, 1280×960, 1440×900, 1680×1050, 1920×1200
without calendar: 1024×768, 1280×800, 1280×960, 1440×900, 1680×1050, 1920×1200

Vidovdan – Folk Festival

preview
with calendar: 480×800, 1024×768, 1024×1024, 1280×800, 1280×1024, 1366×768, 1440×900, 1680×1050, 1920×1080, 1920×1200
without calendar: 480×800, 1024×768, 1024×1024, 1280×800, 1280×1024, 1366×768, 1440×900, 1680×1050, 1920×1080, 1920×1200

I Need Holidays

"After a busy year, we need a long vacation!" Designed by Gopango Networks from Spain.

preview
with calendar: 320×480, 1024×1024, 1280×800, 1440×900, 1680×1050, 1920×1200, 2560×1440
without calendar: 320×480, 1024×1024, 1280×800, 1440×900, 1680×1050, 1920×1200, 2560×1440

Out Of The Box

"Release your creativity!" Designed by Ajan Navaratnasingam from London, UK.

preview
with calendar: 1024×768, 1024×1024, 1280×800, 1280×1024, 1400×900, 1680×1050, 1920×1080, 1920×1200
without calendar: 1024×768, 1024×1024, 1280×800, 1280×1024, 1400×900, 1680×1050, 1920×1080, 1920×1200

Fete De La Musique

"La Fete de la Musique, also known as World Music Day, is a music festival taking place on June 21, read more on wikipedia." Designed by Sherif Saleh from France.

preview
with calendar: 320×480, 640×480, 640×960, 800×480, 800×600, 1024×768, 1024×1024, 1152×864, 1280×720, 1280×800, 1280×960, 1280×1024, 1360×768, 1366×768, 1440×900, 1440×1050, 1600×1200, 1680×1050, 1680×1200

June Pastures

preview
with calendar: 1280×1024, 1440×900, 1680×1050, 1920×1080, 1920×1200
without calendar: 1280×1024, 1440×900, 1680×1050, 1920×1080, 1920×1200

Illustration

"Vector hand drawing illustration of beautiful woman’s face with flowers in her hair and floral pattern behind her." Designed by Jane Lane from Russia.

preview
with calendar: 800×1210, 1024×768, 1024×1024, 1280×800, 1280×1024, 1680×1050
without calendar: 320×480, 1024×768, 1024×1024, 1176×735, 1280×800, 1280×1024

Euro 2012

preview
with calendar: 320×480, 1024×768, 1024×1024, 1280×800, 1440×900, 1680×1050, 1920×1080
without calendar: 320×480, 1024×768, 1280×800, 1440×900, 1680×1050, 1920×1080

Paris Summer

preview
with calendar: 1024×768, 1280×800, 1280×1024, 1440×900, 1680×1050, 1920×1200, 2036×1440
without calendar: 1024×768, 1280×800, 1280×1024, 1440×900, 1680×1050, 1920×1200, 2036×1440

Join In Next Month!

Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.

A big thank you to all designers for their participation. Join in next month!

What’s Your Favourite?

What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below.

Stay creative and keep on smashing!

(il) (vf)

Useful jQuery Function Demos For Your Projects

2012-05-31T17:03:08Z

Every aspiring Web developer should know about the power of JavaScript and how it can be used to enhance the ways in which people see and interact with Web pages. Fortunately, to help us be more productive, we can use the power of JavaScript libraries, and in this article we will take a good look at jQuery in action.

What Is jQuery?

In a nutshell, jQuery is a leading JavaScript library that can perform wonders on your Web pages and make your Web development life much easier and more enjoyable. With the rise in popularity of jQuery since its arrival in 2006, over an estimated 24 million websites (50% of them being the 10,000 most visited websites) currently reap the benefits, and as Google Trends suggests, it’s the most popular JavaScript library.

Thousands of Web developers worldwide use jQuery to innovate on their websites and stay up to date on trends. This surge has been influenced by several jQuery gurus who have helped make jQuery what is today. I would like to personally thank these guys and gals for their hard work and would like to do my part to spread the news about JavaScript and jQuery. In this article, we’ll show you over 50 of jQuery’s most renowned functions, demonstrated with live visual examples. The jQuery library is comprehensive, so hopefully seeing these most frequently used functions in action will improve your understanding of how they can work together to produce excellent results.

jQuery And CSS

Styles play a big part in the look and feel of any website, and jQuery can help us change them dynamically. In this section, we will look at how jQuery can be used to dynamically add and remove style classes and entire cascading style sheets.

.css()

You can change your website’s styles dynamically with jQuery’s .css() function. Either change styles that are already declared inline or in CSS files (such as font-size, color, background-color, etc.) or create new styles for elements.

Demo: Change text color and background color

Blue text with orange background

Demo: Add a style sheet

.addClass() and .toggleClass()

In addition to the .css() function, you can apply currently defined CSS classes by using the .addClass() function. Its counterpart function, .removeClass(), reverses the action.

Demo: Add a CSS class to an element

Click “Run demo” to add the styles to the button. Click “Reset” to remove the styles.

Anchor Button

The .toggleClass() function is a huge time-saver for toggling a state on and off with CSS. The following example sets event handlers for mouseenter (which applies the CSS class img-hover to the image) and mouseleave (which removes it).

Demo: Toggle a CSS class on an element

jQuery Animations And Effects

We can use jQuery to create some very smooth animations and effects with minimal effort. Animations and effects are always best demonstrated with examples, so let’s dive right in.

.animate()

The .animate() function can be used to animate the movement and/or appearance of elements on a Web page. Let’s look at both. You may define the settings parameter with a set duration (in milliseconds) or any of the words slow, normal or fast. The callback, which is the function that runs after the animation has finished, is optional.

Demo: Animate text

Demo: Animate size

Easily change the size of a div.

Demo: Animate movement

The .animate() function is asynchronous, so multiple animations may run at the same time. You can also use the .stop() function to stop the animation. If you click “Run demo” and then “Reset” during the animation, it will demonstrate the .stop() function.

Many pure JavaScript functions are used frequently in animations, such as setInterval(), clearInterval(), setTimeout() and clearTimeout(). Once again, these functions are included in the list because understanding what they can do is important to supporting the jQuery’s animation functions.

setInterval() and clearInterval()

You can automate a task based on time using the JavaScript setInterval() function, which can be used to specify a regular time-based trigger.

Demo: Simple time counter

Click “Run demo” to start the timer, and click “Reset” to stop it.

0 seconds elapsed

Demo: Digital time display

setTimeout() and clearTimeout()

You can also delay a task based on time using the JavaScript setTimeout() function, which can be set to wait for a specified length of time before running the code.

Demo: Do something after a specified length of time.

Click “Run demo” to set the timeout and, click “Reset” to clear it.

This text will disappear after three seconds.

.slideToggle() and .fadeToggle()

jQuery provides various toggle functions that save us heaps of time when we want to bind related events to the same element. For example, .slideToggle() binds both .slideUp() and .slideDown() to the element and also manages that state for us.

Demo: Slide an element in and out of view.

Click “Run demo” to show the paragraph, and click again to hide.

The .slideToggle() function is similar to .slideToggle() but with a fading effect that uses the .fadeIn() and .fadeOut() methods.

Demo: Fade an element in and out of view.

Click “Run demo” to show the paragraph, and click again to hide it.

.delay()

In this demonstration, we’ll mainly use jQuery’s awesome function-chaining ability by running the .fadeOut(), .fadeIn() and .delay() functions together on the same element. This is very similar to the setTimeout() function we saw earlier but without allowing us to easily interrupt the delay.

Demo: Use .delay() to create a delay between function calls.

jQuery And DOM Manipulation

The DOM (document object model) is all of the HTML content that you see on a website (text, images, container elements, etc.). We can use jQuery to perform wonders with the DOM when all page elements have been loaded. The event that captures when the DOM is ready is called .ready(), and there are a few ways to call it. In this section are demos of jQuery functions that change the DOM in some way.

.clone()

The jQuery .clone() function is pretty simple to use; it basically just copies the element that you specify into a new element.

Demo: Clone an element.

.html(), .text() and .empty()

Using .html() is the most common way to get or set the content of an element using jQuery. If you just want the text and not the HTML tags, you can use .text(), which will return a string containing the combined text of all matched elements. These functions are browser-dependent (i.e. .html() uses the browser’s innerHTML property), so the results returned (including white space and line breaks) will always depend on the browser you are using.

In this example, we are also making use of the .empty() function, which is a quick way to get rid of the content within, and .prev(), which can be used to reference the preceding element, in this case the demo buttons.

Demo: Get the content of an element.

.append(), prepend(), .after() and .before()

These function provide the means of inserting content in particular places relative to elements already on the Web page. Although the differences may appear trivial, each has its own purpose, and knowing exactly where they will all place content will save you coding time.

Demo: Insert content onto a Web page.

txt = ‘This is the content we wish to insert.‘

innerDiv.append(txt) | innerDiv.prepend(txt) | innerDiv.after(txt) | innerDiv.before(txt)

outerDiv

innerDiv

jQuery And AJAX

The jQuery library has a full suite of AJAX capabilities that enables us to load data from a server without refreshing the browser page. In this section, we will have a quick look at refreshing page content, loading scripts and retrieving data from different Web pages and servers.

$.ajax()

The $.ajax() function is arguably the most used jQuery function. It gives us a means of dynamically loading content, scripts and data and using them on a live Web page. Other common uses are submitting a form using AJAX and sending data to server-side scripts for storing in a database.

The $.ajax() function has a lot of settings, and the kind team at jQuery has provided many shorthand AJAX methods that already contain the settings we require. Some developers like to write out the full AJAX settings, mainly because they require more options than many shorthand methods provide (such as beforeSubmit()). Also, note that you can use the Firebug NET.panel to analyze HTTP requests for testing, monitoring and debugging AJAX calls.

Demo: Use $.ajax() to load content without reloading the entire page.

For this demo, HTML content is held in separate files, which are inserted below using AJAX. Showing a loading icon while an AJAX request is processing is courteous. The third content block below has a two-second delay to simulate the loading icon.

Content will appear here.

We can also use functions such as $.parseJSON() and JSON.parse() from ECMAScript5, which simplifies JSON parsing. If you’re interested in JSON parsing and tree recursion, see the “Online JSON Tree Viewer Tool.”

.load()

The .load() function is an AJAX shorthand method for inserting HTML straight into a matched element on the Web page.

Demo: Use .load() to grab HTML content from another Web page.

JSONP

AJAX requests are subject to the same origin policy, which means you may only send requests to the same domain. Fortunately, $.ajax() has a property named JSONP (i.e. JSON with padding), which allows a page to request data from a server on a different domain. It works by wrapping the target data in a JavaScript callback function. Note that the response is not parsed as JSON and may be any JavaScript expression.

Demo: Use AJAX and JSONP to load data from an external source.

This demo will load the latest pictures tagged “jQuery” from Flickr’s public feed.

The AJAX shorthand functions $.getJSON and $.getScript and more AJAX examples can be found on my blog.

jQuery And Events

Managing events using regular JavaScript is entirely possible, however, jQuery provides a much more user-friendly interface to manage Web page events. Examples of such events are clicking a hyperlink, moving the mouse over an image and even pressing a key on the keyboard; the list goes on. Here are some examples of key jQuery functions that may be used to manage events.

.bind() and .unbind()

The .bind() function is very useful for adding event triggers and handlers to your DOM elements. In case you didn’t know, you can bind your DOM elements to a whole list of events, such as submit, change, mouseenter and mouseleave.

You may have also seen .click() used in jQuery code. There is no functional difference between .click() and .bind('click'), but with the latter we have the benefits of being able to specify custom events and add data parameters. There is also an .unbind() function to remove any events that have already been bound.

Demo: Trigger an event when the user clicks on or hovers over a div.

Demo: Trigger an event when the user hovers over or double-clicks a div.

Press “Run demo” a few times in a row for some nice effects. Also, double-clicking the boxes will make them disappear!

Demo: Trigger an event when the user presses a key.

Press any key shown in the boxes below.

Note: The key difference between keydown and keypress events is that the latter captures each individual character entered, as opposed to just firing once per key press. To illustrate, this simple tool shows the keycodes for any key that you press.

.live(), .on() and .off()

The .live() function is essentially the same as .bind(), but it can capture events on new elements that didn’t exist on the page when it was loaded; for example, if your Web page has loaded and then you dynamically insert an image onto it. If we used .bind() to attach an event when the mouse hovers over the image, it would not work. But if we used .live(), it would work! As of jQuery 1.7, you are advised to make use of the new .on() and .off() functions, instead of the .live() function, which has a few disadvantages to .on(). See “jQuery 1.7+ .on() vs. .live() Review” for a more detailed explanation of the differences.

Demo: Capture events on new or changed elements.

Click “Run demo” to dynamically insert more images and check that the event still fires on them.

.delegate()

The .delegate() function provides a means of attaching event handlers to new elements (similar to the .live() function covered above). You might find .delegate() to be faster than .live() because the latter searches the entire document namespace for the elements as opposed to a single document. The much more important difference is that .live() is prone to break if used with traversing.

Demo: Delegate events to the child elements of a root element.

The demo area is the root element (orange border) with colored span child elements that have a hover event attached. Click “Run demo” a few times and hover with the mouse to trigger the effects.

.preventDefault()

The .preventDefault() function can be applied to stop any element with a default action from firing: hyperlinks, keyboard shortcuts, form submit buttons, etc. These are probably the most common uses, and the function stops the hyperlink from going to its destination (the href). It’s very useful for stopping those default actions and running your custom JavaScript actions instead.

Demo: Prevent a hyperlink from going to its href.

.stopPropagation()

There are methods that do things similar to .preventDefault() but that behave differently. The .stopPropagation() function prevents the event from occurring on any ancestor elements. This can be used if you have an exception to the rule that you’ve specified for a container element with child elements. This function currently does not work with .live() events because it handles events once they have propagated to the top of the document.

Demo: Prevent a parent container from firing its event when its child is clicked.

Click both the link and div box area to see which event is fired.

This div does not use the .stopPropagation() function.

http://www.smashingmagazine.com

This div does use the .stopPropagation() function.

http://www.smashingmagazine.com

As you can see, when you click the top link it also fires off the div event, but the bottom link uses .stopPropagation(), which prevents the div event from firing. The div event will still fire if you click inside the div, as expected.

.stopImmediatePropagation()

This function is nice for stopping all future bound events. The events will fire in the order they were bound, and when it hits the .stopImmediatePropagation() function, all further bound events are not fired.

Demo: Prevent all future bound events from firing.

Click both the link and div box area to see which event is fired.

This div does not use the .stopImmediatePropagation() function.

Link 1: http://www.smashingmagazine.com

Link 2: http://www.smashingmagazine.com

Link 3: http://www.smashingmagazine.com

This div does use the .stopImmediatePropagation() function.

Link 1: http://www.smashingmagazine.com

Link 2: http://www.smashingmagazine.com

Link 3: http://www.smashingmagazine.com

As you can see, when you click the links in the top div, all of the events fire off. But when you click the links in the bottom div, only the code for all of the links fires off because it calls .stopImmediatePropagation() on the event. This function also prevents the event from firing on any ancestor elements, just like the .stopPropagation() function, as seen in the example where the div click event doesn’t fire on the bottom links.

Finding, Looping And Filtering Results

jQuery gives us fast access to finding anything on the page and the ability to loop through or filter results as we please. It also has powerful functions to manipulate and extend data and functionality associated with JavaScript objects. There are so many things to cover in this section, so we have narrowed them down to a few key functions.

$.each() and .each()

There are two different methods for iterating with jQuery: .each() is used to iterate only over jQuery objects collections, while $.each() is a general function for iterating over JavaScript objects and arrays. I am a big fan of functions such as these and JavaScript shorthand techniques that provide us with a fast alternative to basic JavaScript coding.

Demo: Use $.each() to loop through values in an array.

Output the countries of the world (stored in an array).

Demo: Use .each() to loop through DOM elements.

This demo loops through all of the h2 tags on this Web page and creates a table of contents.

You can use $.each() and .each() on a lot of different things, such as DOM elements, arrays, objects and JSON. For those of you who are keen, you could try five more jQuery .each() examples.

$.data(), .data(), $.hasData() and $.removeData()

Updates to the jQuery library (mainly since 1.4) has brought the ability to attach data of any type to DOM elements. This is a very useful alternative to storing data in JavaScript objects and other such methods. There are two versions: $.data(), which takes in the element as a parameter, and .data(), which can attach directly to matched elements.

Note that $.data() returns a data object to the caller, whereas .data() does not. There are also many utility functions, such as $.hasData(), $.removeData(), that help with data management.

Demo: Attach data to DOM elements.

The following example sets and gets a data object into the div for this demo area.

Set data | Get data | Has data? | Remove data

Data:

.match(), .test() and :contains()

Together with the jQuery :contains() selector, you can use the pure JavaScript functions .match() and .test() to save time when filtering for string values. Let’s look at some examples.

Demo: Extract email addresses from inside HTML (i.e. a string).

We can use .test() to check whether any emails are present, and use .match() to extract them.

Curabitur placerat commodo augue eget congue. Aliquam id ante leo. Duis at libero magna, at dignissim odio. Aliquam aliquet suscipit mollis. Pellentesque libero tortor, elementum id mattis vel, mattis eget metus. somebody1@somewhere.com Nam convallis interdum imperdiet. Fusce at magna tellus. Sed mi ante, aliquam at accumsan ac, tristique sit amet dui. Aliquam eleifend molestie ligula. Vivamus eleifend, somebody2@somewhere.com diam id tincidunt posuere, ipsum dui elementum sapien, posuere pulvinar risus neque id turpis. Nullam volutpat cursus libero, sit amet euismod justo eleifend vitae.

Demo: Use the jQuery :contains() selector to match elements with substrings.

We can use the :contains() selector to match substrings inside any of that element’s descendants (this is case sensitive).

Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Curabitur quis arcu ac justo pellentesque ullamcorper sit amet quis mi.
Nam a lorem quis lacus dapibus egestas et a ipsum.
Phasellus nec magna quis diam cursus egestas quis aliquet tortor.
Ut feugiat vestibulum mi, sit amet consequat orci facilisis ac.
Phasellus et enim ut sem dapibus hendrerit.

Search:

.find()

The .find() function is very useful for matching elements filtered by a selector, jQuery object or element. The .find() function can be used with the functions .children() (which searches only the direct child siblings of the matched elements) and .parents() (which searches the direct parent elements of the matched element).

Demo: Finde specific descendants of matched elements.

Folder 1
- Subfolder 1
  - Item 1.1.1
- Subfolder 2
  - Item 1.2.1
Folder 2
- Item 1.3.1

.filter()

The .filter() function allows us to reduce a set of matched elements based on a jQuery selector. This is useful when you want to process a group of elements and then further process specific child elements. The .filter() function can be used in a few different ways, such as to filter by a class name, function or jQuery object.

Demo: Use .filter() to match subelements.

In this example, .filter() is used to style paragraphs based on their content.

Paragraph 1

Paragraph 2 with span tag

Paragraph 3 with strong tag

Paragraph 4 with highlight class.

Paragraph 5 with span tag

Paragraph 6

Paragraph 7 with strong tag

Paragraph 8 with span tag

Paragraph 9

.slice()

The .slice() function lets us easily specify a subset of elements to perform actions on. It takes two parameters: start and end indices of subelements in a matched parent element.

Demo: Use .slice() to perform actions on a subset of elements.

Slice 1	Slice 2	Slice 3
1	1	1
1	2	3
1	4	2
7	3	0
3	6	1

.prev() and next()

The .prev() and .next() functions can be used to reference the immediately preceding or next element in a set of matched elements (in the DOM hierarchy). You can also add a selector to the functions that acts as a filter on the elements (shown in the demo).

Demo: Reference the previous and next elements in a list.

< Prev | Next >

List item 1
List item 2
List item 3
List item 4
List item 5

$.extend()

The $.extend() function can be used to combine two or more objects into the first object or into a completely new object.

$.extend( target, [object1,] [objectN] )

In the demo, we have a functional contact form on our website, and we want two more forms with similar functionality. Instead of copying all of the code that processes the form, we can use $.extend() to copy the functionality to our new forms, thus avoiding repetitive code. You might have noticed that the target element specified is a blank object; this is a trick that you will often see to create a new object of object1 and extend it with objectN (N representing any number of objects). So, in the example, we want to “copy” the existing functionality of forms.enquiry and simply override the email address.

Demo: Use $.extend() to change the send action on a form to different email addresses based on the form used.

This demo simulates the submission of three forms that all use the same code base.

Demo: Use $.extend() to specify custom settings for a plugin.

This demo shows how to specify the length of paragraph excerpts. The default is 150 characters.

Excerpt length:

Run Excerpts plugin

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Addy Osmani’s book Learning JavaScript Design Patterns gives greater insight into how to use the $.extend() function to override the default values of jQuery plugins.

.serialize() and .serializeArray()

The .serialize() and .serializeArray() functions can create string and array values from form fields in seconds! There are two demos here: the first outputs all of the form’s fields and their values, and the second creates a URL string with the form fields and values appended to the form action ready to be sent.

To run the demo, enter anything into the form and click the “Run demo” buttons below the form.

Demo: Create an array of all of the form’s field values

Demo: Create a URL string with all of the form’s field values

Conclusion

Although we have only scratched the surface of jQuery in this article, we hope you have learned something about some of the most popular jQuery functions and are able to use them to write fantastic code for your next Web development project. Thanks for reading.

(al) (km)

Design Process In The Responsive Age

2012-05-30T12:55:32Z

You cannot plan for and design a responsive, content-focused, mobile-first website the same way you’ve been creating websites for years—you just can’t. If your goal is to produce something that is not fixed-width and serves smaller devices just the styles they require, why would you use a dated process that contradicts those goals?

I’d like to walk you through some problems caused by using old processes with responsive design. Let’s look into an evolving design process we’ve been using with some promising new deliverables and tools. This should provide a starting point for you to freshen up your own process and bring it into the responsive age.

The Problem

The issues caused when trying to force new results from an old process are significant yet, strangely enough, not immediately obvious. We’ve all just gotten used to them, like the annoying quirk we didn’t realize we had, until someone points it out. And from that point forward, it drives you crazy. For example, when we create a desktop-sized, fixed-width site layout in Photoshop and hand it to a developer to interpret into HTML/CSS, we are asking the developer to make a lot of design decisions—possibly without even realizing it. Below is just a small sample:

How should the layout adjust for smaller-sized devices? (It sure would be nice to have a hierarchy of important page elements based on their purpose, huh?)
What is the hierarchy of the content? (Gee, all that “Lorem Ipsum” doesn’t make it obvious?)
How does the navigation respond to smaller screens? (How do I handle ten links with five child pages each revealed on hover with a 320×480 touch device?!)

This can cause major problems if the developer doesn’t feel confident in the visual arena. Even designers/developers who feel comfortable making those calls can get in hot water. In the end, the developer is often forced to make assumptions where plans were not made clear beforehand—sometimes days before feedback from designer or client becomes available. Sometimes it works, sometimes it doesn’t.

Work More or Work Efficiently?

It’s easy to resort to working more to resolve these new challenges. What comes naturally? Do a desktop and mobile-sized wireframe, then turn around and design a desktop and mobile-sized layout. This sort of solves the problem. You and your developer have more to work with, at least. However, what about all the device widths in-between—you’ll have to cover those as well, right?

At this point, you wake up and realize you’re stuck in a familiar loop of ever-increasing deliverables and ever-shrinking profits. Using this old process to tackle new problems doesn’t really solve any of them, and it’s going to kill you from lack of sleep, make you poor from lack of profit, or both.

There are some good ideas floating around dealing with new processes. Some smart folks are of the very sensible opinion that the only answer is to design in the browser. However, other smart folks have admitted for the quiet rest of us that it’s really, really hard to design freely in the browser—at least with current tools.

Of the emerging new process ideas, those that involve responsive HTML/CSS prototypes look very promising. I’m planning to investigate these further. However, there are some definite challenges with this approach, not the least of which is the time it takes to create them when the site content is complex. Most of the examples I’ve seen are fairly generic, which doesn’t translate well to real projects.

Currently, we are successfully using a different approach. It attempts to optimize content, design, and development time, finding a budget-friendly balance of appropriate direction from all disciplines—something that is effective, lean and uses quick, widely-accessible tools.

Solution: The Priority Guide

I used to call this my “mobile-sized content prototype wireframe thingy.” For obvious reasons, however, I was encouraged to change the name by pretty much everyone I know. I liked the specificity of the name, but brevity won out. So, I settled on: Priority Guide.

Essentially, with the priority guide, we create a single deliverable that provides direction for content-focused design and mobile-first development in something resembling a wireframe.

Download a PDF of the guide.

By nature, a mobile-sized approach is narrow and forces more of a single column layout. The single column, in turn, causes a linear display of content and features. This linear display makes priority and hierarchy much more apparent than a desktop-sized wireframe, especially if you attempt to use a draft of real content instead of greek text—hence the content prototype.

At that point, armed with just this priority guide, the designer sets off to create something beautiful. The designer cranks up trusty ol’ Photoshop and begins a new layout at a traditional desktop resolution—just like you may have done for the past ten years. For a good web designer (outfitted with his super-duper powers of visualization), it is a snap to make design decisions for a desktop resolution while looking at a mobile plan. That’s just how their minds work.

Download a hi-res JPG of the final design.

Once the design work is done, the handoff to the developer consists of the completed desktop-sized design and the original mobile-sized wireframe.

Don’t Let the Simplicity Fool You

This approach may sound simple—which is part of the beauty of it—, but it also provides some real benefits:

The developer is provided a sort of bookended direction, both desktop and mobile. Two guides to follow, each offering unique information. Some interpretation still has to be made, which isn’t a bad thing, but there is far less guess work.
The designer is given a wireframe that provides hierarchy but does not dictate desktop-sized layout, where ample real estate allows for more creative room to breathe—designers need to be given their freedom, lest they shrivel up into sad, hollow, hipster-jean-wearing shells of themselves.
From the prototype and their linear approach, hierarchy can be understood fairly quickly, and the foundation for mobile-first markup and style is implied but flexible.
All of this is done in a two-deliverable process, like before, so it saves time and budget. Any method you get better results in the same amount of time (or less) is a good.

A Note About Context

Any conversation concerning mobile web draws questions of context. Is there a “mobile context”? If one does exist, do users actually have different expectations of a website’s content while they are mobile? And, if users do have different expectations, how do we address them? Whew.

In short, those questions aren’t what this article is about. These issues are being discussed in depth elsewhere. I believe that questions of context can be answered very differently, depending on the project. I’ll leave it to you and your team to apply due diligence in addressing context.

What I will suggest, however, is that you tread very carefully when making assumptions about your users and limiting content as a result. Though a mobile context may exist, you can’t make those assumptions based on screen size alone. People surf the web on their phones from their couches, and they have all the time—and expectation—to access all of your site’s content as they sit and watch TV. This is why we believe in a responsive web design approach that acts as a safety net where little to no content is abridged from the experience of the user. This is the approach reflected in the above article—plan for all content in all contexts.

Tools To Consider

Style Tiles

Designer Samantha Warren just recently presented her concept of Style Tiles at SXSW. She was featured just days later on A List Apart discussing the same concept. We love it. It’s one of those concepts that makes you slap your forehead, wondering why you didn’t think of it sooner. It makes sense for web design in general, even more so in responsive design where client delieverables are much more tricky. We are already planning to integrate this into our workflow. We envision this deliverable being presented to a client during the wireframing process, so progress concerning style and layout can be made separately but concurrently.

Keynote for Wireframes

I’ve been loving Keynote for wireframes lately—it’s even great for mobile-sized content prototype wireframe thingies. If you haven’t tried it, give it a shot. It’s quick, easy to learn, and easy to share. A really interesting article was written recently about designing in Keynote. I’m not sure I’m ready to go that far. However, it’s a fantastic wireframing and planning tool, and there are some great kits to get you started. We’ve been using this one from Travis Isaacs.

Conclusion

If you gain nothing more from this article, let me remind you what you already know: don’t be afraid to try new things. No process is a silver bullet—the same is true of tools and deliverables. If the ideas above don’t fit your project, scrap them and try others. However, you must evolve your design process to account for the evolution of the web and users. If you hope to solve new problems, you’re going to need a new approach.

You must also address the very human issue of communication. Earlier and more frequent collaboration among team members and the client must become the rule in your workflow, not the exception. Content, design, and development team members must review and collaborate regularly at every stage in the creation process until the site is live. We can’t ‘throw it over the wall’ anymore—at least, not if we want our sites to be excellent. There are simply too many moving parts now. Go forth and collaborate.

(jc) (fi)

MUD: Minimum Usable Design

2012-05-29T19:07:21Z

There is a paradox that fits my life. Doesn’t matter what aspect of my life I am talking about because it always seems to apply. Even more so when I think about this paradox and the design of this website and other websites. I really hate this paradox.

“To walk through the woods, you first need to walk halfway through. Then, once you’re in the middle of it, you still need to walk half of the remaining distance, then half of the distance again, and then another half, and you can never successfully make it through the woods.”

This example is based off of Zeno’s paradoxes, which are even more mind-boggling than the one above.

No matter what stage of a design I am in, I am always halfway there. This is why you might find yourself always saying that you need two more weeks to finish up all the details. It will always be two more weeks no matter what, because all you did was get halfway from where you were to where you are trying to go. Using this mentality can wear you down, but if you twist it around a bit, it can be used as motivation to achieve a successful design.

A Totally Made Up Theory

Let’s use our good ol’ sparring partner Google as an example. You are about to sit down and create the first home page in Google’s history. If you had an infinite amount of time you could tackle any part of the design that you wanted without any worries. But unfortunately life doesn’t give us non-deadlined projects. Because of this, you know the goal that you are striving to achieve—you know what it looks like once you leave the woods, so first, you just have to get halfway there.

If the very first half makes the design at least 50% usable then what would you design first? The logo? The footer? The obvious choice would be the search box and button. In fact, if you design that, then you are probably over 50% of the way through with the design because the website is now usable. It’s good to get that first 50% out of the way, and now you are halfway to your end goal. Some people like to call this working from the inside out.

Next step is to get halfway from where we are now to where we need to be. I think it’s important that we have some kind of branding on the page so people know where to come back to next time they want to search. That means I put the logo on the page. Once I am done with that I’m 75% of the way to my goal. 75% of the way through and how many people in the world would be satisfied with using Google if it had nothing but a logo, search bar and one button on it? I’m betting more than 75%. But if getting 75% of the way towards our goal can please even 75% of our audience, we might be doing a good job.

If you continue on with this process of knocking out half of what you need to do, eventually you will get close enough to your goal where good enough is as good as you are going to get. I know people argue about what good enough means, but if you are 99% of the way to where you are trying to go, then good enough is good enough.

MUD

In the startup community there is a term called minimum viable product.

“A Minimum Viable Product has just those features (and no more) that allows the product to be deployed.”

Minimum Viable Product, from Wikipedia

I’m coining the term Minimum Usable Design, and that is when you reach your 50% mark for your design. If you can’t use your design after you have reached 50% (or a person can’t understand at least 50% of what is going on) then you haven’t reached the 50% mark yet.

By no means does this imply that you should show your design to the public at the 50% mark, but you can use it as a way to gauge your progress. Sometimes you need to wait untill you are 99% done before showing your work to a larger audience. There is nothing wrong with striving for perfection, but it depends on your design and audience. Apple does minimum viable product with the limited features on their products, but make up for it with maximum viable design (a new term, crown me king).

An Example

Blog design is a very simplistic example, but lets run with it. On my website, Drawar, the main goal is to get people to read the content. If I can do that, I have achieved my number one goal, and it just so happens that this goal will keep the majority of my audience happy. Because of this, I want to make the content easy to get to, and so I need to know what design will help me get there.

The 50% mark. Not much, but it achieves the #1 goal.

With this design, anyone that comes to my website can read the content. That is 50% of my journey, but now I need to go the other half to reach another subset of people coming to my design. I decide next that there should be some branding on the website so that people can know where they are at and remember the website if they visit it again.

Now the design is 75% there.

Now when you visit the website you know where you are at, but notice that the additions didn’t take away from the original MUD that I created. From here I can take another halfway point journey by adding links to other sections of the website, and also provide a bit of context about the website they are on.

87.5% of the way…

Again, the additions do not take away from the original 50%, so that is a good thing. Time for one more halfway journey before I push the website out, and that would be adding some revenue.

93.75% complete (well, at least to me).

Basically the design is finished, but there are additional things I could add to the design to make it more complete to some people. For example, search, social media widgets, and possibly a blogroll. I’ve set the goals of the design though, so I understand the milestones that I want to achieve.

Design Is Never Finished

Although I’m happy with the end result of the design, it doesn’t mean it will work for everyone that visits. Someone will always want to get more out of a design, and that is why a design will never be able to leave the forest. Fortunately, the more halfway points you knock out in a design, the smaller the subset of people that are still wanting more out of it. Be careful though, because adding too much will take away from the original 50%, which was the main purpose of the design from the beginning.

And don’t think that this only applies to “minimalistic” websites—that is just my style of design, but it applies just as much to the designs that add a lot of flare to their aesthetic. Tweetbot, for example, isn’t any less of a usable design than other Twitter clients in my mind, because it adds a bit more flash to its design elements.

Always aim for the next halfway point and you will get closer and closer to the edge of the forest—but remember that you will never reach the end. Designs can always be improved upon, and therefore will always be unfinished.

Image on frontpage created by Libby Levi.

(jvb) (jc)

Develop A One-Of-A-Kind CSS/JS-Based Game Portfolio

2012-05-28T10:58:35Z

A portfolio is a must-have for any designer or developer who wants to stake their claim on the Web. It should be as unique as possible, and with a bit of HTML, CSS and JavaScript, you could have a one-of-a-kind portfolio that capably represents you to potential clients. In this article, I’ll show you how I created my 2-D Web-based game portfolio.

The 2-D Web-based game portfolio of Daniel Sternlicht.

Before getting down to business, let’s talk about portfolios.

A portfolio is a great tool for Web designers and developers to show off their skills. As with any project, spend some time learning to develop a portfolio and doing a little research on what’s going on in the Web design industry, so that the portfolio presents you as an up to date, innovative and inspiring person. All the while, keep in mind that going with the flow isn’t necessarily the best way to stand out from the crowd.

One last thing before we dive into the mystery of my Web-based game portfolio. I use jQuery which has made my life much easier by speeding up development and keeping my code clean and simple.

Now, let’s get our hands dirty with some code.

The HTML

Let’s warm up with a quick overview of some very basic HTML code. It’s a bit long, I know, but let’s take it step by step.

<div id="wrapper">

    
    <hgroup id="myInfo">
        <h1>DANIEL STERNLICHT</h1>
        <h2>Web Designer, Front-End Developer</h2>
    </hgroup>

    
    <div id="startCave" class="cave"></div>
    <div id="startCaveHole" class="caveHole"></div>

    
    <div id="mainRoad" class="road"></div>
    <div id="leftFence"></div>
    <div id="rightFence"></div>

    
    <div id="daniel"></div>

    
    <div id="aboutRoad" class="road side"></div>
    <div id="aboutHouse" class="house">
        <div class="door"></div>
        <div class=”lightbox”>…</div>
    </div>
    <div id="aboutSign" class="sign">
        <span>About Me</span>
    </div>

    
    …

    
    …

    
    <div id="rightTrees" class="trees"></div>
    <div id="leftGrass" class="grass"></div>

    
    <div id="endSea" class="sea"></div>
    <div id="endBridge" class="bridge"></div>

    <div id="boat" class="isMoored">
        <div class="meSail"></div>
    </div>

</div>

The HTML is not very complicated, and I could have used an HTML5 canvas element for this game, but I felt more comfortable using simple HTML DOM elements.

Basically, we have the main #wrapper div, which contains the game’s elements, most of which are represented as div elements (I chose divs because they are easy to manipulate).

Have a quick look at my game. Can you detect what makes up the game view?

The game view

We have roads, trees, fences, water, caves, houses and so on.

Back to our HTML. You’ll find an element for each of these items, with the relevant class and ID. Which brings us to the CSS.

The CSS

First of all, note that I prepared the HTML to follow the principles of object-oriented CSS by determining global classes for styling, and not using IDs as styling hooks. For example, I used the class .road on each element that should look like a road. The CSS for the .road class would be:

.road {
   position: absolute;
   background: url(images/road.png) repeat;
}

Take trees as another example:

.trees {
   position: absolute;
   background: url(images/tree.png) repeat 0 0;
}

Note that almost all of the elements are absolutely positioned on the game’s canvas. Positioning the elements relatively would be impossible for our purposes, especially because we want the game to be as responsive as possible (within limits, of course — the minimum width that I deal with is 640 pixels). We can write a general rule giving all of the DOM elements in the game an absolute position:

#wrapper * {
   position: absolute;
}

This snippet will handle all of the child elements inside the #wrapper div, and it frees us from having to repeat code.

One more word about the CSS. The animations in the game are done with CSS3 transitions and animations, excluding certain features such the lightboxes and player “teleporting.” There are two reasons for this.

The first is that one of the purposes of this portfolio is to demonstrate innovation and up-to-date development, and what’s more innovative than using the power of CSS3?

The second reason is performance. Upon reading Richard Bradshaw’s very interesting article “Using CSS3 Transitions, Transforms and Animation,” I came to the overwhelming conclusion: use CSS3 when you can.

A great example of the power of CSS3 animations in my portfolio is the pattern of movement of the water. The CSS looks like this:

.sea {
   left: 0;
   width: 100%;
   height: 800px;
   background: url(images/sea.png) repeat 0 0;
   -webkit-animation: seamove 6s linear infinite;   /* Webkit support */
   -moz-animation: seamove 6s linear infinite;      /* Firefox support */
   animation: seamove 6s linear infinite;          /* Future browsers support */
}

And here is the code for the animation itself:

/* Webkit support */
@-webkit-keyframes seamove {
   0% {
      background-position: 0 0;
   }
   100% {
      background-position: 65px 0;
   }
}

@-moz-keyframes seamove {…}   /* Firefox support */
@-keyframes seamove {…}       /* Future browsers support */

The sea PNG is marked out.

The repeating sea.png image is 65 pixels wide, so to give the sea a waving effect, we should move it by the same number of pixels. Because the background is repeating, it gives us the effect we want.

Another cool example of CSS3 animations happens when the player steps into the boat and sails off the screen.

The boat sails off the screen, revealing the “Contact” section.

If the player gets back onto the road, you’ll notice that the boat moves in “reverse,” back to its original position. It sounds complicated, but you have no idea how easy it is with CSS3 transitions. All I did was capture the event with JavaScript to determine whether the user is “on board.” If the user is, then we add the class .sail to the boat element, which make it sail off; otherwise, we withhold this class. At the same time, we add a .show class to the #contact wrapper, which smoothly reveals the contact form in the water. The CSS of the boat looks like this:

#boat {
   position: absolute;
   bottom: 500px;
   left: 50%;
   margin-left: -210px;
   width: 420px;
   height: 194px;
   background: url(images/boat.png) no-repeat center;
   -webkit-transition: all 5s linear 1.5s;
   -moz-transition: all 5s linear 1.5s;
   transition: all 5s linear 1.5s;
}

When we add the class .sail to it, all I’m doing is changing its left property.

#boat.sail {
   left: -20%;
}

The same goes for the #contact wrapper with the class .show. Except here, I’m playing with the opacity property:

#contact.show {
   opacity: 1;
}

CSS3 transitions do the rest of the work.

The JavaScript

Because we are dealing with a 2-D game, we might want to base it on a JavaScript game engine, perhaps an existing framework. But the thing about frameworks (excluding jQuery, which I’m using as a base) is that they are usually good for a head start, but they probably won’t fit your needs in the long run.

A good example is the lightboxes in my portfolio, which provide information about me and are activated when the user enters a house.

An example of a lightbox in the game. (Large image)

This kind of functionality doesn’t exist in a regular JavaScript game engine. You could always improve an existing framework with your own code, but diving into someone else’s code sometimes takes longer than writing your own. Moreover, if you rewrite someone else’s code, it could become a problem when a new version is released.

After passing over libraries such as Crafty, LimeJS and Impact, which really are great game engine frameworks, I felt I had no choice but to build my own engine to fit my needs.

Let’s quickly review the main methods that I’m running in the game.

To handle the keyboard arrow events, I use the following code:

$(window).unbind('keydown').bind('keydown', function(event) {
    switch (event.keyCode) {
        event.preventDefault();
        case 37: // Move Left
            me.moveX(me.leftPos - 5, 'left');
        break;

        case 39: // Move Right
            me.moveX(me.leftPos + 5, 'right');
        break;

        case 38: // Move Up
            me.moveY(me.topPos - 5, 'up');
        break;

        case 40: // Move Down
            me.moveY(me.topPos + 5, 'down');
        break;
    }
});

As you can see, the code is very simple. When the user presses the up or down arrow, I call the moveY() function, and when they press right or left, I call moveX().

A quick peek at one of them reveals all the magic:

moveX: function(x, dir) {
    var player = this.player;
    var canMove = this.canImove(x, null);
    if(canMove){
        this.leftPos = x;
        player.animate({'left': x + 'px'}, 10);
    }
    if(dir == 'left') {
        this.startMoving('left', 2);
    }
    else {
        this.startMoving('right', 3);
    }
}

At each step the player takes, I check with a special method named canImove() (i.e. “Can I move?”) to determine whether the character may move over the game canvas. This method include screen boundaries, house positions, road limits and so on, and it gets two variables, including the x and y coordinates of where I want the player to move to. In our example, if I wanted the player to move left, I’d pass to the method their current left position plus 5 pixels. If I wanted them to move right, I’d pass its current position minus 5 pixels.

If the character “can move,” I return true, and the character keeps moving; or else, I return false, and the character remains in their current position.

Note that in the moveX() method, I’m also checking the direction in which the user wants to go, and then I call a method named startMoving():

if(dir == 'left') {
   this.startMoving('left', 2);
}
else {
   this.startMoving('right', 3);
}

You’re probably wondering how the walking effect on the character is achieved. You might have noticed that I’m using CSS sprites. But how do I activate them? It’s actually quite simple, with the help of a jQuery plugin called Spritely. This amazing plugin enables you to animate CSS sprites simply by calling the method on the relevant element and passing it your properties (such as the number of frames).

Back to our startMoving() method:

startMoving: function(dir, state) {
   player.addClass(dir);
   player.sprite({fps: 9, no_of_frames: 3}).spState(state);
}

I simply add a direction class to the player element (which sets the relevant sprite image), and then call the sprite() method from Spritely’s API.

Because we are dealing with the Web, I figured that being able to move with the keyboard arrows would not be enough. You always have to think of the user, your client, who might not have time to hang out in your world. That is why I added both a navigation bar and an option to “teleport” the character to a given point in the game — again, using the canImove() method to check whether the player may move to this point.

Next we’ve got the lightboxes. Recall what the HTML looks like for each house:

<div id="aboutHouse" class="house">
   <div class="door"></div>
   <div class="lightbox">
      <div class="inner about">
         Lightbox content goes here…
      </div>
   </div>
</div>

Did you notice the .lightbox class in the house div? We will use it later. What I basically did was define a “hot spot” for each house. When the player gets to one of those hot spots, the JavaScript activates the lightboxInit(elm) method, which also gets the relevant house’s ID. This method is very simple:

lightboxInit:  function(elm) {
   // Get the relevant content
   var content = $(elm).find('.lightbox').html();

   // Create the lightbox
   $('<div id="dark"></div>').appendTo('body').fadeIn();
   $('<div id="lightbox">' + content + '<span id="closeLB">x</span></div>').insertAfter("#dark").delay(1000).fadeIn();
}

First, I get the relevant content by finding the div.lightbox child of the house element. Then, I create and fade in a blank div, named dark, which gives me the dark background. Finally, I create another div, fill it up with the content (which I had already stored in a variable), and insert it right after the dark background. Clicking the “x” will call another method that fades out the lightbox and removes it from the DOM.

One good practice that I unfortunately learned the hard way is to keep the code as dynamic as possible. Write your code in such a way that if you add more content to the portfolio in future, the code will support it.

Conclusion

As you can see, developing a 2-D Web-based game is fun and not too complicated a task at all. But before rushing to develop your own game portfolio, consider that it doesn’t suit everyone. If your users don’t have any idea what HTML5 is or why IE 5.5 isn’t the “best browser ever,” then your effort will be a waste of time, and perhaps this kind of portfolio would alienate them. Which is bad.

Nevertheless, I learned a lot from this development process and I highly recommend, whatever kind of portfolio you choose, that you invest a few days in developing your own one of a kind portfolio.

(al)

Blueprints For The Web: Specctr Adobe Fireworks Plugin

2012-05-25T13:27:14Z

There is an aspect to Web design that no one likes to talk about: spec’ing. We all do it, we all hate it, but we also understand that specs are vital to both designers and developers.

For those who aren’t familiar with the term in this context, “specs” is short for specifications — in the case of design, they are instructions that specify colors, fonts, sizes, spacing and so on, just like a blueprint. Specs are a crucial part of the design and development process for companies with big teams and for small companies that have to outsource some of their development. Specs function not only as instructions to developers, but also as a reference point to make sure the whole team is on the same page.

However, the process of producing specs is repetitive and time-consuming, especially for creatives. But now this can all change: Specctr, together with Adobe Fireworks, offers a quick and easy way to generate this important information automatically.

The Idea

My idea to make Specctr came from my personal experience working on a design team at a large corporation. Spec’ing was part of my routine. One day, after hours of spec’ing, my eyes hurt and I was bored and frustrated. Suddenly, I realized that this kind of intensive work should be automated, and that a designer’s time is much better spent designing rather than spec’ing.

Specctr is more than a tool: it is a business solution for any company whose designers must generate specs for developers. Specctr facilitates this communication and leaves designers and developers happier and more productive. Making this process quicker frees up the business to focus more intently on its core mission.

Possible time saved using Specctr for Adobe Fireworks.

Time saved using Fireworks and Specctr Pro.

In the process of creating Specctr, I brought my design background and practical experience in spec’ing to bear on the issues and opportunities in automating the process. Meanwhile, my colleague, Dmitriy Fabrikant, engineered the software from the ground up. Working in tandem at On Pixel, we released Specctr Pro in January 2012. Since then, it has received many favorable reviews.

Specctr Lite

In addition to the commercial version of the tool, we’re happy to release a free version called Specctr Lite as a contribution to the community. We chose to highlight width and height as well as text spec’ing abilities, because they are most common to a designer’s workflow. These two feature sets alone will save a lot of valuable time.

The Lite version includes:

Width and height
Text spec (font family, size, color)
Expand canvas feature

Specctr Lite can be downloaded for free from our website, and we’re happy to say that it was created and released as a result of the involvement of Smashing Magazine!

Pro and Lite: a quick comparison

The Lite version is as easy to use as the Pro version, and its features work the same way.

Requirements And Installation

To use Specctr (Pro or Lite), you need:

A Mac or PC
A copy of Adobe Fireworks CS3, CS4, CS5 or CS5.1

The installation process is pretty straightforward:

Download the Specctr installer
Double-click the MXP file to open the Adobe Extension Manager
Click on “Install”
Restart Adobe Fireworks
In Fireworks, go to Window → Specctr to open the Specctr panel.

Please note: If you are using Windows Vista or 7, you might need to launch the Adobe Extension Manager as Administrator, otherwise the extension could fail to install.

If you still have questions, don’t hesitate to consult our online tutorial (PDF, 1.9 MB) or contact us directly!

Specctr Pro

A Brief How-To Guide

Once you install Specctr through the Adobe Extension Manager, restart Fireworks, and then open Specctr from the Window menu. Now that Specctr is open, you can spec a document in a few easy steps.

First, prepare your document by making room for your specs. Select the size of your design’s border, and click on the “Expand Canvas” button.

Select which details to display by toggling them on or off from the panel’s menu.

Now Specctr Pro will automatically display your spec with a click of the button.

To spec a shape (shape, line, dot, etc.) or a text object, select the object (or multiple objects), and click on the “Spec Object” button. The specs will be outputted to the nearest edge of the canvas.

Properties of objects in a spec

You can also spec the spacing between two objects by selecting them and then clicking the “Spacing” button. If you select only one object, Specctr will measure the object’s distance to the edges of the canvas.

Measuring the space between objects

Finally, you can also spec the width and height of any object.

Insight Into The Fireworks Extension Development Process

The process of developing Fireworks extensions consists of the following steps:

First, we design and build the panels in Adobe Flash Pro.
We import the panels into Flash Builder and add the ActionScript code, which makes them run.
Finally, we have to connect with the Fireworks API, which is written in JavaScript, in order to manipulate Fireworks.

Because the development process is spread over three separate environments, integrating the different pieces of the application and debugging the application present some challenges. But in the end, it’s well worth the positive response from our users.

In the next couple of weeks, Dmitriy will release on GitHub a few ActionScript libraries that he has built during the process of developing Specctr. These libraries will hopefully reduce some of the pain points of the tiered development process. We might also write another article that highlights in more detail the development process for building a Fireworks extension.

One of Fireworks’ strengths is its potential as a development platform that leverages the creativity and innovation of its community. We would love to help this process and show that Fireworks is a powerful tool for Web design.

The First Smashing Conference Is Coming: A Community Event For Web Designers

2012-05-29T07:31:34Z

Probably the most remarkable characteristic of our Web design community is that we care about our craft. We care about best practices, about our work, about learning, sharing and improving our skills. This very spirit is the driving force behind our daily work at Smashing Magazine, and this spirit is what has prompted us to organize the very first Smashing Conference: a friendly, valuable and inspiring community event that will help us all become better at what we do.

Whether you are a designer, developer, content strategist or business owner, at the Smashing Conference you’ll explore insights hands on and gain practical tips and new perspectives on our craft. We are very happy to provide an opportunity for you to share and gain practical knowledge in an intimate, informal atmosphere — right in our beautiful home town of Freiburg, Germany, at the foot of the legendary Black Forest.

The legendary Historical Merchants Hall, a late-Gothic building built between 1520 and 1530. Its façade is decorated with statues and the coat of arms of four Habsburg emperors. An exquisite location for the very first Smashing Conference. Image credit.

When and Where?

We’re delighted to invite you to come together for this inspiring, forward-thinking event on 17 to 19 September 2012. The conference will host a two-day single-track conference on September 17th and 18th, as well as three workshops on September 19th. By “we,” we mean Vitaly Friedman, editor-in-chief of Smashing Magazine, and Marc Thiele, who has been running community events such as beyond tellerrand for over 12 years.

The aim of the event is to deliver the same high-quality content that we deliver on Smashing Magazine, in the familiar atmosphere that beyond tellerrand events are known for. This will be a high-caliber yet friendly event that brings great value to everyone involved, and we’d be honored if you took a part in it.

The conference will take place in Freiburg, Germany at the legendary Historical Merchants Hall at the foot of the Black Forest.

The main hall of the venue. 350 tickets are available in all for our two-day single-track event. Image credit

Keeping the conference affordable for everyone is important to us. All tickets includes two full single-track conference days, on Monday and Tuesday. Please note that only 350 seats are available.

We are pleased to announce that the first 70 early-bird tickets are on sale for a price of €249. The regular price after that is €349. And all prices include the German VAT of 19% and booking fees! Get your ticket now before it’s too late. We’d be honored to meet you in September!

Speakers and Topics

If you’ve been following Smashing Magazine for a while, then you won’t be surprised by the focus of the Smashing Conference. We’re aiming to cover a wide variety of Web design topics, such as visual design, front- and back-end development, UX design, mobile, responsive design, the business aspects of running a website, as well as the intricate details of the designer and developer’s workflows. We’re encouraging our dear speakers to share details on how they work, what tools they use, and what their design and coding process looks like. We’re aiming for valuable, practical and inspiring talks.

We’ve handpicked all of the speakers to ensure the high quality of the event. So far, 10 out of 15 speakers are officially confirmed. Please note that the topics presented here are subject to change. More details on the conference, speakers, talks and workshops are available on the conference’s official website.

Speakers

Speaker	Talk	Details
Aarron Walter	The Real Me
Aarron Walter is the lead user experience designer for MailChimp, where he socializes with primates and ponders ways to make interfaces more human. Aarron is the author of Designing for Emotion, the purple stripe in the rainbow of knowledge from A Book Apart. He lives with his wife and son in Athens, Georgia, and is a wannabe barista. He tweets about design under the moniker @aarron.
Chris Heilmann	To be announced
Chris Heilmann has dedicated a lot of his time to making the Web better. Originally from a radio journalism background, he built his first website from scratch in around 1997, and he spent the following years working on a lot of large international websites, and a few years at Yahoo building products and training people; he is now at Mozilla. Chris has written and contributed to four books on Web development and has written many articles and hundreds of blog posts for Ajaxian, Smashing Magazine, Yahoo, Mozilla, ScriptJunkie and many more.
Jeremy Keith	The Spirit of the Web
Jeremy Keith makes websites. He is responsible for the death of the trees used to print the books DOM Scripting, Bulletproof Ajax and, most recently, HTML5 for Web Designers. He also shot a man in Reno just to watch him die. Originally from Ireland, Jeremy now lives in Brighton, England where he pretends to work with Clearleft. Peas grow there.
Jonathan Snook	Your CSS Is a Mess
Jonathan Snook writes about tips, tricks and bookmarks on his blog. He has also written for A List Apart, 24ways, and .net magazine, and he has coauthored two books, The Art and Science of CSS and Accelerated DOM Scripting. Most recently, Snook has written the eBook SMACSS, sharing his experience and best practices on CSS architecture. Snook also works on the design team at Shopify.
Josh Brewer	Responsive Is as Responsive Does
Josh spends his time thinking about, designing and building things that live at the intersection of form, function and aesthetic. He is principal designer at Twitter and is the co-creator of 52 Weeks of UX, Ffffallback and Shares. He is also an advisor and mentor at The Designer Fund.
Lea Verou	To be announced
Lea has a long-standing passion for open Web standards and has been often called a CSS guru. She loves researching new ways to take advantage of modern Web technologies, and she shares her findings on her blog. Lea also makes popular tools and libraries that help Web developers learn and use these standards. She speaks at a number of well-known international Web development conferences and writes for leading industry publications. Lea also co-organized and occasionally lectures in the Web development course at the Athens University of Economics and Business.
Paul Boag	Better Websites, Happier Clients and Improved Job Satisfaction
Paul Boag has been working on the Web since 1993. He is Web Strategist at Headscape Ltd, a Web design agency that he cofounded back in 2002. Paul also produces and hosts the longest-running and award-winning Web design podcast at boagworld. He is a regular speaker at conferences and author of Client-Centric Web Design.
Rachel Andrew	The Future of Content Management
Rachel Andrew is a front- and back-end Web developer, author and speaker. Her books include the bestselling CSS Anthology for SitePoint, and she is a regular contributor to a number of publications both online and off, including Smashing Magazine. She writes about business and technology on her own website.
Stephen Hay	To be announced
Stephen has been designing and developing for the Web since 1995. He currently helps clients with front-end design and development, multi-platform strategy and accessibility through his consultancy, Zero Interface. Aside from his client work, he can be found speaking at industry events about Web design-related topics such as CSS layout and responsive design workflow. Stephen is co-organizer of Mobilism, one of the world’s leading mobile Web development conferences. He is also co-creator of Grip Workshops, a series of two-day intensive workshops for Web project managers on the client side. Stephen has written for publications including A List Apart and .net Magazine. He also coauthored the Smashing Book 3 with a host of super-talented folks. When he makes the time for it, he publishes his thoughts on The Haystack.
Tim Ahrens	Web Fonts Backstage and On Stage
Tim Ahrens is a type designer based in Berlin, where he runs Just Another Foundry with Shoko Mugikura. As a former architect, he is interested in the interplay between technology and design. He develops design software such as the Font Remix Tools and Web applications such as the FontFonter. Since 2010, he has been working as a consultant for Typekit.

Gallery of the speakers at the Smashing Conference.

Workshops

Trainer	Workshop	Details
Aarron Walter	Interface Design Bootcamp
Whether you are designing a Web app or website, following best practices and standard design methodologies will help ensure that your interfaces are usable and engaging. In this workshop, we’ll explore the design process in detail, including user research, wireframing, prototyping and visual design. Through real-world examples, you’ll see how an idea can evolve into an interface.
Andy Clarke	Fashionably Flexible Responsive Web Design
Responsive design has made designing flexible websites fashionable again, but there is more to being fashionably flexible than technology or using CSS3 media queries. So, this unique workshop — hosted by Andy Clarke, designer, author and speaker — puts the design back into responsive design. Andy will teach you how to design from the “content out,” instead of from the “canvas in.” He’ll demonstrate how to separate design from layout; and if you work with designs made in Photoshop, he’ll show how to deconstruct a design into its components (color, texture and typography) before reassembling it for a fluid continuum of devices, from phones to desktops and everything in between.
Jonathan Snook	SMACSS: Scalable and Modular Architecture for CSS
The SMACSS workshop is a full day of instruction and exercises on writing HTML and CSS using a flexible and modular approach that will improve team efficiency and minimize problems with growing projects. It brings the eBook to life with practical examples and in-depth discussion.

Gallery of the workshop experts at the Smashing Conference.

Further Details About the Conference

As we finalize some major details of organization, we are working hard on a plethora of small details to make the event as valuable and memorable as possible. Please expect more speakers to be confirmed soon and more topics to be announced.

Also, we are looking for sponsors of the event, so if you are interested, please get in touch with us. More details on the location, hotels, speakers, talks, workshops and after party are presented on the official Smashing Conference website.

One of the workshop rooms, with medieval decoration and statues of medieval knights. 30 seats are available for each workshop. Image credit.

Facts

In a nutshell: The Smashing Conference is a friendly, valuable and inspiring community event that will help designers and developers become better in their work, be it front- or back-end development, UX design, content strategy or running a business.
Dates: 17 to 19 September 2012 (workshops on the 19th, and conference on the 17th and 18th).
Venue for workshops and conference: “Zum Roten Bären”, Historical Merchants Hall, Freiburg.
Early-bird price (only 70 tickets): €249 ($315) (including German VAT and fees).
Regular price: €349 ($440) (including German VAT and fees).
Each workshop costs €349 ($440) (including German VAT and fees).
Twitter: @smashingconf
Lanyrd: http://lanyrd.com/2012/smashingconf/
Facebook: http://www.facebook.com/smashingconf
Website: http://www.smashingconf.com

“Zum Roten Bären“, one of the locations for the conference’s workshops. Large view.

We’re very excited about the Smashing Conference, and we’ll do our best to make it a valuable, memorable and useful event. We can’t wait to meet you, and please feel free to contact us if you have any questions about participation or sponsorship.

Creating Mobile-Optimized Websites Using WordPress

2012-05-24T15:11:59Z

“Mobile Web design.” Unless you’ve been hiding under a bush for the last 18 months, you’ll know that it’s one of the hottest topics in the industry at the moment. Barely a week goes by without new tips being unveiled to help us hone our skills in making websites work as well — and as fast — as possible on mobile devices.

If you own or have designed a WordPress website for the desktop and are considering going mobile, the process can be fairly daunting. You probably know of responsive design and might have heard of the mobile-first approach developed by Luke Wroblewski, which entails planning the content and design for mobile devices first and then desktops second, rather than the other way round.

But if your WordPress website has a desktop theme in which everything is set in pixels, then the thought of adopting a responsive design might have you running for the hills.

It doesn’t have to be that way.

Here are four ways to make your WordPress blog or website mobile-friendly, ranging from the quick and dirty to the complex but potentially very beautiful. As well as outlining the pros and cons of these methods, we’ll include information on plugins that will help without actually doing all the work for you, and we’ll provide some code that you can use for a responsive design.

Plugins: The Quick Way To Make Your Content Mobile-Friendly

Designing for content is increasingly becoming more common than squeezing content into a pixel-perfect design, as documented here on Smashing Magazine.

If your website is more about content than design (say you run a blog that is content-heavy and designed for reading), then you won’t be too fussed about what your website looks like on mobile devices. You just want people to be able to read it without having to zoom in, move the viewport around or generally tie themselves up in knots until they decide to leave.

If this is the case, then a simple plugin might do the trick. Below are some plugins to consider.

WPtouch

WPtouch, which comes in free and premium versions, strips out your existing theme and displays your content and not much else, but the result is user-friendly, robust and easy to read.

WPtouch is widely used on websites, including Stephen Fry’s blog and Social Media Examiner. You can see below how the plugin renders those two websites. The premium version has options to modify the colors and some styles, including a bespoke menu at the bottom of the screen, as seen on Social Media Examiner.

Social Media Examiner desktop design

Social Media Examiner mobile design, using WPtouch

WordPress Mobile Pack

The WordPress Mobile Pack has some color options and can be used as a mobile switcher if you want a completely different theme for mobile devices. It also has a mobile interface for editing posts, although this has been superseded to some extent by the WordPress apps for iOS and Android.

WordPress Mobile Pack screenshots

BuddyPress Mobile

If your website runs BuddyPress, then you’ll need a plugin to ensure that none of its functionality is lost on mobile devices. BuddyPress Mobile has theming options, and you can edit the style sheet to make the mobile design your own.

BuddyPress Mobile

Mobile Themes: The Next Level Up

If you want a consistent design across desktop and mobile, but you don’t yet have a theme or you want to develop one, then a mobile theme might be the answer.

More and more mobile themes have sprung up over the last year. In particular, Twenty Eleven, WordPress’ default theme since version 3.0, is responsive enough for many websites.

Twenty Eleven on the desktop

Twenty Eleven on mobile

Below are some other themes that include a mobile or responsive style sheet.

Carrington

The Carrington family of themes can be used as parent themes. You can edit the CSS and functions to suit your needs, and it has a mobile version.

Carrington on desktop

Carrington on mobile

Scherzo

Scherzo is clean and minimalist and would be great to use as a parent theme. It uses a mobile-first responsive design.

Scherzo on desktop

Scherzo on mobile

Jigoshop

E-commerce websites are trickier to make mobile-friendly, but Jigoshop can help. It’s a full e-commerce plugin and theme, with a responsive layout that can be tweaked to suit your design.

Jigoshop on desktop

Jigoshop on mobile

A Different Theme For Mobile Devices

In the days before responsive design gained traction, websites commonly had two versions: desktop and mobile. The mobile version might have been on an m. subdomain or have a .mobi extension. Some websites out there still do this, mainly huge news websites that serve different content depending on the device.

Fewer WordPress administrators are choosing to do this now, but if you do want to go down this route, then serving two versions of your website from the same database is possible, by using a mobile switcher.

Here are two plugins that make this possible:

WordPress Mobile Pack
This tool, already mentioned above as a theme that makes your website mobile-friendly, can also be used as a mobile switcher, detecting mobile devices and using a separate theme of your choice.
WPtap Mobile Detector
This targets mobile devices and enables the theme of your choice.

Using one of these plugins enables you to develop a completely separate theme for mobile devices, with its own layout, navigation and content structure.

Or, Finally, Make Your Current Theme Responsive

If you don’t want to throw out your existing theme, then the best way to give mobile users an experience that is at least visually similar to the desktop version is to build responsiveness into your theme.

A responsive theme contains media queries in the theme’s style sheet to define CSS that applies only to devices of a specified maximum or minimum width. A truly responsive theme has a fluid layout that adapts to mobile devices and larger screens to some extent already, but with some extra styling to make the layout optimal for mobile devices.

1. Defining the Media Queries

To get started, you will need to define media queries in the style sheet. Most of the styles already in your style sheet apply to desktop and mobile, so you only need to add CSS that is different for mobile devices. This will go at the end of your theme’s style sheet.

Start by defining the screen width you are developing for. There are two main approaches to this:

Start with the narrowest screen width you are targeting (which will usually be mobile phones in portrait orientation); add all of the CSS needed for this screen width; and then add successive media queries for wider screens. This is known as the mobile-first approach, and it has the benefit of making websites faster on mobile devices because only the CSS needed for those devices is loaded.
Start with the widest screen width (usually desktop monitors) and work down, adding CSS that applies to each screen width in turn. While this might slow down loading on mobile devices, it has the advantage of working in IE 8 and below, which doesn’t understand media queries. At the moment, most websites are developed this way because they involve making an existing desktop design responsive, so this is the approach we’ll cover here.

A media query consists of three main parts:

The @media rule;
The media type (the most common being print and screen — we’ll use screen);
The maximum width of the screen you are targeting.

You could have a media query to target mobile phones (and other small devices such as the iPod Touch) in portrait orientation that have a width of 320 pixels:

@media screen and (max-width: 320px) {

}

The CSS to be applied to that screen width and any screen narrower than it would be written between the braces.

An alternative to the @media rule would be to create a linked style sheet with the CSS for each screen width. But I don’t do that because it adds another server request with the potential to slow the website down; and managing all of the styles becomes harder if they’re in more than one place.

Here are other media queries for commonly targeted screen sizes:

(max-width: 480px)
Works for mobile devices in either portrait or landscape mode, because they are 480 pixels wide in landscape orientation but are still narrower than this maximum width in portrait.
(max-width: 780px)
Works for iPads and other large tablets in portrait mode and any screens narrower than them.
(max-width: 1024px)
Works for iPads in both orientations, as well as for small desktop browsers.

You can run one media query after another so that each change you make applies to the screen size you’re querying, plus any widths queried further down in the style sheet. In this case, you would work with wider screens first. For example:

@media screen and (max-width: 480px) {

}

If you are ignoring tablets, you would include this media query first and add any CSS for mobile phones in both portrait and landscape modes (for example, any changes to graphics or text size). You would then follow it with this:

@media screen and (max-width: 320px) {

}

Here, we’re adding any styles that apply only to phones in portrait mode (such as layout changes). You don’t need to repeat the CSS that applies to both landscape and portrait modes because this will still apply. In the same way, you don’t need to repeat any styles that will stay the same for desktop views because they will cascade down from the earlier parts of the style sheet.

2. Making the Layout Responsive

Phew! So, now we’ve defined media queries, and we’re ready to roll with some mobile-friendly CSS. Below are the main things you will need to work on for a standard WordPress website. Let’s assume your website’s markup is similar to that of the Twenty Eleven theme (i.e. html → body → header (or div #header) → #main → #content → #primary → #secondary → footer (or div #footer). You might need to substitute your own elements and IDs for the ones in the examples below.

Overall width of website
You’ll need to change this so that it displays correctly. Add the following code between the braces of your first media query:

body {
width: 100%;
float: none;
}

This ensures that the website’s body fills the width of the device and removes any floats. At this point, you might also want to change the background image if there is one (more on that shortly).

You will now have the following code at the bottom of your style sheet:

@media screen and (max-width: 480px) {
   body {
   width: 100%;
   float: none;
   }
}

Width of content and sidebar
In portrait mode in particular, there isn’t room for a sidebar to the right of the main content. Add the following code to the media query relating to devices with a maximum width of 320 pixels:

#content, #primary, #secondary {
width: 100%;
float: none;
margin: 10px 0;
}

Footer content, especially widgets
If your footer has widget areas or other elements with floats applied, you will need to override them for mobile devices in portrait mode.

If you want the footer widgets to be full width in both landscape and portrait modes, then simply add footer.widget-area to the CSS for the sidebars and content.

However, you might want the widget areas to be laid out side by side in landscape mode, depending on how many you have. In that case, you’ll need to do the following:

Work out the percentages for the widths, padding and margins (some box-model maths for you!);
Add the relevant code to your media query for devices with a maximum width of 480 pixels;
Add a separate query for devices with a maximum width of 320 pixels after the one you’re working on, with the following code:

footer .widget-area {
width: 100%;
float: none;
margin: 10px 0;
}

You might also need to adjust the text alignment and borders and padding, depending on your existing theme. Margins should be set to 0 on the left and right; suit them to your theme at the top and bottom, but generally they should be smaller than in the desktop version.

Image sizes
The images in your design might still break the layout or break out of their containing elements, making your website shrink when viewed on a mobile device. There is an easy fix for this:

body img {
max-width: 100%;
}

This will ensure that images are never wider than their containing element. You might need to tweak the CSS if images sized further up in the style sheet have greater specificity.

However, this solution isn’t ideal. The images might look smaller, but mobile devices will still have to download their full sizes, which will slow down response times and possibly lose visitors, as well as annoy users on expensive data plans (more of them are out there than you might think). There a number of solutions to this, some of which you will find in this roundup of articles on responsive images. You may recall the mobile-first approach mentioned earlier; one benefit of this approach is that it serves different-sized image files to devices based on screen width.

Text size
So, our layout is working, and everything displays nicely. But now that the website is narrower, the text might appear huge. We’ll need to adjust the text’s size with the following code:

body {
font-size: 60%;
line-height: 1.4em;
}

This sets the font size as a percentage of the size set for it further up in the style sheet.

4. Changing the Navigation Menus and Creating an App-Like Interface

Sometimes mobile users will want to access specific content; for example, visitors to a store’s website will want to find the store’s location easily, and visitors to an e-commerce website will want to shop with a minimum of clicks (or taps). Sometimes you might want to adjust the navigation to make the website look more like an app.

Here are some methods you can follow to do this:

Use CSS to turn menu items that are visible on the desktop into drop-down menus, using code similar to what you would use to create a second-level drop-down menu on a desktop website.
Use conditional PHP or a plugin such as Mobble to display a different menu depending on the device, as seen on the website that I developed for Centenary Lounge:

Centenary Lounge desktop website

Centenary Lounge mobile website
Use CSS to display menu items as a vertical list of buttons to give the website an app-like look, such as on Cafe Blend:

Cafe Blend desktop website

Cafe Blend mobile website
Use a plugin such as Dropdown Menus to display menu items as a drop-down walker, freeing up screen real estate.
Use background images combined with media queries and floats, to create a grid of visual buttons for your navigation, giving the home page an app-like feel.
Use fixed positioning to fix the navigation to the bottom of the screen, minimizing the need for scrolling, as seen earlier on Social Media Examiner.

The possibilities are limited only by your imagination and creativity!

5. A Problem!

You’ve added the media queries above, but your smartphone still displays the desktop version. Don’t worry! This is because many smartphones use a virtual viewport that is equal to the width of a small desktop, which prevents desktop-designed websites from breaking when rendered in the browser. This can be easily fixed by placing the following code in the head of each page. Because yours is a WordPress website, you need to add it only once, to the header.php theme file:

<meta name=”viewport” content=”width=device-width”>

What this does is tell the phone to treat the size of the screen as its actual size, not the virtual size… if that makes sense.

Summary

Here’s what we’ve looked at in this article:

Four different ways to make a WordPress website mobile-friendly: with a plugin, with a prebuilt responsive theme, with a separate mobile theme, and by making the existing theme responsive;
Media queries for responsive design and how they target different device widths;
Some common styles to make a WordPress website responsive in its layout, images and text.

As you can see, no one option is necessarily the best; it will depend on the website, on the budget and on the time and capability of those involved. Over time, most mobile-friendly WordPress websites will have responsiveness built into them, instead of using a separate theme, mobile website or plugin.

Hopefully this article has given you a starting point to make your WordPress website mobile-friendly. This is just the beginning of the possibilities. To further develop your mobile website, you might want to consider a mobile content strategy; a mobile-first design; APIs and native device functionality to create an even more app-like experience; and more.

Enjoy!

(al)

A Beginner’s Guide to Ruby

2012-05-24T11:33:32Z

Ruby is an object-oriented language. What does that even mean? It has unique quirks and characteristics that we’ll explain clearly. This article assumes that you have no programming experience, not even HTML.

An important skill to have when creating a program is translating — translating the desires of the user into the output they are looking for. In order to do that, you have to be able to think like a developer so that you can take what you know instinctively (as a user) and morph it into what the computer needs to be able to do what you want. So, we’ll help you start thinking like a developer. When you are done, you should have a mental model of how Ruby works and be on your way to becoming a successful Rubyista.

We’ll take you through a variety of the fundamental elements of the Ruby language and explain the whys behind the hows.

For all the code samples we go over, you can test them out on Try Ruby (without having to install anything on your computer). You can follow Try Ruby’s tutorial if you want, but you don’t need to in order to understand what we’ll outline below. It’s just a quick way to get your feet wet without the headache of installing anything.

How Is Your Code Evaluated by the Computer?

The interpreter for Ruby — basically, the main brain of the programming language that makes sense of the code you write — reads the code from top to bottom and left to right; meaning, it starts at line 1, character 1, literally, and first reads across line 1 to the last character, then goes down to the next line, and repeats this process until it reaches the last line of your program. If you have any syntax errors — i.e. errors in your code, such as misspelled variable names, improper use of constants (we’ll get to constants in a bit), etc. — it will halt execution and show you an error message, usually with a line number corresponding to the code. Remembering this is important because if you encounter an error report while coding, you will need to know how to decipher it. Figuring this out isn’t always straightforward for beginners.

Fictitious code from The Matrix. (Image: Absolute Chaos)

This top-down parsing also affects the control of the flow of logic in your program. Say you want to calculate the balance of someone’s account before showing it to them. You would have to make sure that you put the method and function that does the calculation before the output of the balance; that is, if you are outputting the balance at line 10, then you would have to do the calculations somewhere between line 1 and 9. We’ll dive into this later.

Objects

An object is a thing. It is at the heart of Ruby. Going back to our earlier statement about Ruby being an object-oriented language, that means that Ruby manipulates all data on the assumption that the data is an object. There are many object-oriented languages, but very few put the object at the center of their universe like Ruby does. In Ruby, everything is an object. I mean everything: every variable, every operation. Every object has different characteristics; that’s what makes them different. A string is an object that has built-in characteristics that make it suitable for handling text. For a more technical definition, check out the article “Object” on Wikipedia.

Methods

A method is simply a definition of an action that can be performed on an object. Ruby has built-in object definitions and methods. One such method is capitalize for the Ruby class strings (we will dive into strings later).

string1 = "this string is awesome"

If you wrote string1.capitalize, the output would look something like this:

"This string is awesome".

All that the capitalize method tells the Ruby interpreter to do is convert the first character of the string from lowercase to uppercase. Check out an example directly from the Ruby documentation. As you can see from the documentation, the string object in Ruby has a ton of methods that you can use right out of the box.

Another thing you should have noticed is the way to call a method, string1.capitalize, which is basically <object name> . <method name>.

In this case, the object is a string variable. If you tried to do capitalize on an object that is not a string, Ruby would throw an error.

You can create any method for any of your objects. Here is the way to do that:

def method_name
     #Enter code here
end

The # basically tells the Ruby interpreter that this is a comment for another human and to ignore it. So, the Ruby interpreter skips lines that begin with a #.

Classes

A class is like a blueprint that allows you to create objects of a particular type and to create methods that relate to those objects. But classes have a special property called “inheritance.” Inheritance means just what you would think. When you inherit something from someone, it likely means a few things:

That you are related in some way (in most cases, it is parent to children or grandparent to grandchildren);
That either you are getting a bunch of stuff (land, money, etc.) or you have gotten some biological attribute (say, a nose shape or hair type).

Classes are like a blueprint for objects. (Image: Todd Ehlers)

Those principles are the same in Ruby. There are parent, grandparent and children classes. As a general rule, children classes inherit all of the attributes of a parent or grandparent class.

In Ruby, an object’s grandparent class is known as its “superclass.” In other words, if you have an object that is a string — meaning that your object inherits the properties of the String class — then the parent class of String is String’s superclass. Be careful not to miss an important distinction here: the superclass of String (which is a class that tells Ruby how to treat strings) is not the same as the superclass of a String object. Here is a demonstration:

> num1 = "this is a string"
=> "this is a string"
> num1.class
=> String
> String.superclass
=> Object
> Object.superclass
=> BasicObject
> BasicObject.superclass
=> nil

What we have done is set the local variables num1 to be a string. When we check the class of num1, by calling the .class method, it tells us that the class of num1 is String. Then, when we checked the superclass of String, it tells us Object, and so on.

Look at what would happen if we tried num1.superclass:

> num1 = "this is a string"
=> "this is a string"
> num1.superclass
=> #<NoMethodError: undefined method `superclass' for "this is a string":String>

The reason this doesn’t work is because num1 is an object (a local variable) that has inherited the properties of the class String. And num1 is not a class, so it has no superclass.

Here is another way to do what we did earlier:

> num1 = "this is a string"
=> "this is a string"
> num1.class
=> String
> num1.class.superclass
=> Object
> num1.class.superclass.superclass
=> BasicObject
> num1.class.superclass.superclass.superclass
=> nil

The reason the last value is nil is because BasicObject has no parent. It inherits nothing from another class, so it stops there.

One key thing we have done here that is different from before is we have “chained” methods, meaning we have continued applying a method to the current statement. That’s another beautiful thing about Ruby: every time it evaluates something, it returns a copy and allows you to continue evaluating it.

Take the last line:

> num1.class.superclass.superclass.superclass
=> nil

Basically, Ruby did this:

What is the class of num1? It’s a string, so return String.
What is the superclass of String? String is a child class of Object, so return Object.
What is the superclass of Object? Object is a child class of BasicObject, so return BasicObject.
What is the superclass of BasicObject? BasicObject is not a child class of anything, so return nil.

All on one line, all in one command. Simple, neat, elegant.

The structure of classes and superclasses is the hierarchy of class inheritance.

Now the question is, how do you define a class and use one? Glad you asked.

class MyClass
# some code logic
end

That’s it.

Basically, you just have the opening keyword, class, followed by the name of your class (MyClass, in this case). Then you have some code. And when you are done, you close it with the keyword end. Make sure that class and end are always all lowercase (i.e. don’t write Class or End or you might get errors).

That’s all there is to it.

If you have a parent class that you want this new class to inherit stuff from, you would define it like this:

class MyChildClass < MyClass
# some code that is specific to the child class
end

Ruby interprets the < operator to mean that the class name on the right side is the parent and the class name on the left is the child (therefore, the child should inherit methods and such from the parent).

Also, remember that class names usually start with an uppercase letter; and if their name has multiple words, you do what is called “CamelCasing” — i.e. instead of using a space or underscore or hyphen, you just start the new word with an uppercase letter.

Class Instances

Now we know how to create a class, which we know is the blueprint of an object type. So, if you think of baking, a class is like a recipe (which contains a list of ingredients and instructions for creating something). But once you create something — say, blueberry muffins — then each muffin may be considered an “instance” of that class.

So, each instance or muffin is an object.

The way to create an instance is like this:

muffin = BlueberryMuffin.new

That’s it.

To be technical, the only part of the statement above that actually creates an instance of the BlueberryMuffin class is BlueberryMuffin.new. In order to use the object, you have to store it somewhere, so we’ve stored it in the local variable muffin so that we can reuse this specific instance (or muffin).

You will need to do more technical things with a class, like set up an initialization method so that whenever you create an object of the class, Ruby knows how to do that exactly. That is a bit beyond the scope of this article — just understand what a class is, how it relates to objects, how to create new objects, etc.

To read up on classes, check out the article about them on Learn Ruby The Hard Way.

Data Structures

How is data structured?

At the core of programming is the manipulation of data. Computer scientists have come up with a way to manipulate data in a structured way by inventing things called “data structures.” A data structure is simply a container for a particular type of data. Words are handled differently than formulas; likewise, characters and letters are handled differently than numbers — in most cases.

Variables

What’s a variable?

A variable is the name of the most basic type of container that you will store data in. Each variable name has to be unique to its scope (i.e. the area in which the variable is allowed to exist). Think of it as a Venn diagram, in which each variable is only valuable in the circle or square within which it is contained.

Say you wanted to create a program (or a part of a program) that is responsible for adding two numbers. From the coder’s point of view, you would need to set up a container for each of those numbers, and then set up the mathematical function between the containers. The reason to do this is because you don’t want the user to have to edit the source code every single time they want to calculate the sum. Although you could do that, the solution is neither practical nor efficient. Most users know what a calculator looks like, so they can just press the buttons or enter the numbers. But editing source code is a no-no.

In Ruby, each of those containers is a variable. So, you would do something like this:

sum = num1 + num2

As opposed to something like this:

sum = 19 + 20

Ruby and many other languages have many types of variables. We’ll go over just a few to be brief and not confuse you too much.

Local
This is a variable that can be used only in a finite part of the program, such as a method or function (we’ll go over what these are later). Once you have exited that part of the program, those variables are destroyed. In fact, say you have a program that has three methods; you could have the same variable — say, num1 — that is used in three different ways in each of those methods and that stores three different values. Going back to the Venn diagram, suppose there are three shapes within the diagram: Circle 1, Circle 2, Square. Also suppose that Circle 1 and Circle 2 are not connected, but both are within Square. A local variable would be confined to its respective circle and would not be able to affect anything outside of its circle. The way to use these variables is to just use them. If you want to use a local variable called sum that stores the sum of the values of num1 and num2, you would simply write sum = num1 + num2.
Global
This is a variable that can be used throughout the entire program. Back to the Venn diagram, these variables would be within the square. This way, if you are inside any of the circles that are within the square, you can access a variable that is outside of the circles but within the square. You use these in Ruby by putting a $ before the name. So, suppose you want to calculate multiple dimensions of a circle, and you want to define the radius beforehand. You would do something like this: $radius = 20. Then, at any other time throughout the program, regardless of whether you are in a subcircle of the square or in the square alone, you can reference $radius. Now, using global variables has a good side and bad side. The good side is that you can read the value of a global variable in any method or function within your program. The bad side is that you can also write to a global variable in any method or function within your program. If you change the value, forgetting that another method or function depends on the previous value could really screw things up. As a rule, then, stay away from global variables unless you are confident that you know where they will be used and how changes would affect the rest of the program.
Constants
These are “sacred” global variables. The values of these variables are supposed to remain constant for the life of your program. Say you wanted to specify a mathematical constant such as pi that you could easily use throughout your program. You would do something like this: PI = 3.14. Constants have to begin with an uppercase letter, and more often than not they are all uppercase, but they don’t have to be. Note that I said that the values of constants are supposed to be constant throughout your entire program, but they can be changed. Ruby doesn’t forbid you from changing the value, but when you do, it gives you a warning because it doesn’t like it. Going back to the Venn diagram, think of PI as being set outside of the square, and it can be used anywhere within the square and anywhere within the circles within the square.
Class
These are variables whose scope is limited to the class that they are defined in. Class variables are defined with @@ at the beginning of the name of the variable.
Instance
These are variables whose scope is limited to one particular instance of a class. They are defined with @ at the beginning of the name of the variable.

Here’s a recap on how to use the variable types:

Local
sum = num1 + num2
Local variable names should start with a lowercase letter or an underscore.
Global
$radius = 20
Global variable names should start with a $.
Constants
PI = 3.14
Constants should start with an uppercase letter, but they are commonly written in full caps.
Class
@@length = 10 #
This denotes the length of a side of an object in a class. I’ve used an imaginary class, called Square, and defined the length of each side for demonstration purposes. What’s important to note here is that all “squares” would have a “length” of 10 by default.
Instance
@length = 5 #
This denotes the length of a side of a particular object. Suppose you wanted to create a red square that had a length of 5 instead of the default 10. You could use this instance variable to specify the length of this particular square, your “Red Square.”

Note that these rules are by no means comprehensive. Some words you can’t use as variable names. They are called “reserved words,” which Ruby uses internally to identify various elements of the language.

To find out more about variables and other do’s and don’ts, check out the following resources:

“The Ruby Language,” Programming Ruby: The Pragmatic Programmer’s Guide
“Variables,” Ruby User’s Guide
“Ruby Programming/Syntax/Variables and Constants,” Wikibooks

Strings

What is a string?

A string is a series or sequence of characters — i.e. a “word” or sequence of words. You might say a sentence, but a string is not just a sentence. For instance:

string1 = 'a'
string2 = 'This is a string'

Two things are happening here. The first is that we are using local variables, and the second thing is that we are using single quotes to define the content of the variable. Even though string1 contains just one letter, it is still a string because it is declared in single quotes. Ruby knows how to treat a variable by the way it is declared. You can use double quotes, but you have to be consistent. You can’t start the string’s declaration with a double quote and end with a single quote, like this: string1 = "This is a string'. But you can do this: string1 = "This is a string", or string2 = 'This too is a string'. Both are valid, and it’s just a matter of taste.

num1 = 9

This sets num1 to the numerical value of 9. So, if you did num1 + 1, the result would be 10.

But if you used single quotes around the 9, like this…

num1 = '9'

… then that would say that 9 is actually a string, not a number. So, if you wrote num1 + 1, it would throw an error along the lines of: => #<TypeError: can’t convert Fixnum into String>. The Ruby interpreter is basically saying that you have given it a number and a string and that it doesn’t know how to add them.

To take that one step further, if you did this…

num1 = '9'
num2 = '1'
num1 + num2

… the result would be this:

"91"

Because Ruby would take the two strings and literally squish them together. When you specify a value in quotes (either single and double quotes), you are telling the Ruby interpreter, “Don’t translate this. Just take the exact content between the beginning and end quotes.” It treats the 9 like any other letter. So, as far as Ruby is concerned…

num1 = '9'

… is more or less the same as this:

num2 = 'a'

As a matter of fact, if you did num1 + num2, the result would be 9a.

In summary, a string is just a combination of letters, numbers and special characters.

Collections

So far, we have covered individual pieces of data, such as one or a handful of items that can be stored in a local variable, or a single object created as an instance of a class.

But what happens if we want to work with many pieces of data — that is, a collection, such as a series of numbers that we need to put in ascending order, or a list of names sorted alphabetically. How does Ruby manage that?

Ruby gives us two tools: hashes and arrays.

Arrays

The easiest way to explain an array is to show an image of what a “typical” one looks like.

Rather than having six different variables for the six food types, we have just one food array that stores each food item in its own container or element. The numbers to the right of the diagram above are the “index” or “keys” (i.e. addresses) of each element ([0] = chicken, [1] = rice, etc). Note that the keys are always integers (whole numbers) and always start at 0 and go up from there. So, the first element is always [0], and [1] is always the second element, etc. So, you will know that the range of keys of any array is always [0] to (length-1) — meaning that the last element is always total length of the array minus 1, because we started at [0].

To create the above in Ruby, we would do something like this:

food = ['chicken', 'rice', 'steak', 'fish', 'shrimp', 'beef']
=> ['chicken', 'rice', 'steak', 'fish', 'shrimp', 'beef']
> food.count
=> 6

Notice that for each element, we use single quotes (we could have used double quotes instead) because we are storing strings in each element. Ruby’s array class has some methods that we can use right out of the box, such as count, as used above. It simply counts the total number of elements in the array and outputs that value. Thus, even though the index goes up to 5, there are 6 elements because the index started at 0.

Now that we have created a food array, we can access each item by invoking the name of the array that we created, followed by the index number.

> food[0]
=> "chicken"
> food[1]
=> "rice"
> food[2]
=> "steak"
> food[6]
=> nil

The reason we get nil at food[6] is because there is no [6] — or, rather, nothing is stored in food[6], so Ruby automagically sets food[6], food[7], food[8] and so on to nil. To add another food item to this array, all you would have to do is set the next element to whatever value you wanted, like so:

> food[6] = 'carrots'
=> "carrots"
> food
=> ["chicken", "rice", "steak", "fish", "shrimp", "beef", "carrots"]
> food.count
=> 7

There is another way to add elements to your array in Ruby. You use the append operator, <<, which basically sticks something at the end of the array. The difference here is that we don’t have to specify an index position when using the append operator. We just do this:

> food << "irish potato"
=> ["chicken", "rice", "steak", "fish", "shrimp", "beef", "carrots", "irish potato"]
> food << 42
=> ["chicken", "rice", "steak", "fish", "shrimp", "beef", "carrots", "irish potato", 42]

Everything that comes after the << is added to the array. This is pretty convenient because you can append variables and other objects to an array without worrying about the content itself. For instance:

> sum = 10 + 23
=> 33
> food << sum
=> ["chicken", "rice", "steak", "fish", "shrimp", "beef", "carrots", "irish potato", 42, 33]

All we did here was create a local variable named sum, and then push the value of sum to the end of the array. We can even add arrays to the end of other arrays:

> name_and_age = ["Marc", "Gayle", 28]
=> ["Marc", "Gayle", 28]
> food
=> ["chicken", "rice", "steak", "fish", "shrimp", "beef", "carrots", "irish potato", 42, 33]
> food.count
=> 10
> food << name_and_age
=> ["chicken", "rice", "steak", "fish", "shrimp", "beef", "carrots", "irish potato", 42, 33, ["Marc", "Gayle", 28]]
> food.last
=> ["Marc", "Gayle", 28]
> food.count
=> 11

Even though the last element is an array with three elements — Marc, Gayle, 28 — it still counts as just one element (i.e. one array) inside the food array. So, the count figure goes from 10 (before name_and_age is added) to 11.

If we wanted to find out how many elements were inside the last element of the food array, we could do something like this:

> food.last.count
=> 3

A few other interesting methods that Ruby allows us to use right out of the box are first, last, length, include? (followed by the object you want to check for), empty?, eql? and sort.

> food
=> ["chicken", "rice", "steak", "fish", "shrimp", "beef", "carrots"]
> food.first
=> "chicken"
> food.last
=> "carrots"
> food.length
=> 7
> food.count
=> 7
> food.include?("chicken")
=> true
> food.include?("filet mignon")
=> false
> food.empty?
=> false
> food[0]
=> "chicken"
> food[0].eql?("chicken")
=> true
> food[0].eql?("beef")
=> false
> food.sort
=> ["beef", "carrots", "chicken", "fish", "rice", "shrimp", "steak"]

In the brackets right after eql?, we put the string in double quotes because we are dealing with a string. Also, sort arranges alphabetically on strings and from lowest to highest for numbers.

We can store anything in each element, not just strings. We can even mix; some elements can be strings, others can be numbers.

Say we wanted an array of numbers. We would do something like this:

numbers = [1, 2, 3, 4, 5, 6]
=> [1, 2, 3, 4, 5, 6]

Remember what we said earlier about always starting the index at 0. You can see here why that is so important. In order to reference the number 1 in this array, the array reference has to be [0] because that is the first element in the array.

> numbers[0]
=> 1
> numbers[1]
=> 2
> numbers[6]
=> nil
> numbers.first
=> 1
> numbers.last
=> 6
> numbers.count
=> 6
> numbers.length
=> 6
> numbers.include?(3)
=> true
> numbers.include?(10)
=> false
> numbers.empty?
=> false
> numbers[1]
=> 2
> numbers[1].eql?(1)
=> false
> numbers[1].eql?(2)
=> true

Because we are evaluating numbers, the objects in the brackets should not be wrapped in double quotes. In fact, if we did use double quotes, Ruby wouldn’t find the items because it would be looking for a string and not a number. Be careful with those quotes!

> numbers.include?("3")
=> false
> numbers[1].eql?("2")
=> false

To see what other Ruby methods are included in the array class, check the documentation on “Array.”

Everything we’ve just discussed covers one-dimensional arrays (i.e. arrays with just one column). These are best used to store lists of items.

As you can imagine, there are multi-dimensional arrays. We’ll just touch on a 2-D array. Once you understand how to use them, you can then extrapolate to 3-D and beyond (if you ever want to go there).

A 2-D array looks like this:

We are storing two things: the name of the dish, along with a price related to that item.

As the diagram suggests, in order to access each element, you would use both keys.

This is how we would declare this array:

> food2 = [["chicken", 10], ["rice", 5], ["steak", 20], ["fish", 15], ["shrimp", 18], ["beef", 9]]
=> [["chicken", 10], ["rice", 5], ["steak", 20], ["fish", 15], ["shrimp", 18], ["beef", 9]]

A few key differences should jump out at you. Essentially, food2 is an array of arrays (meaning that it is an array whose elements are themselves arrays). Huh? Well, look at each element.

> food2[0]
=> ["chicken", 10]
> food2[1]
=> ["rice", 5]
> food2[2]
=> ["steak", 20]
> food2[3]
=> ["fish", 15]

When you access each “single” element, you notice that each has an array inside of it; ["chicken", 10] is an array that has a string (chicken) in the first element and a number (10) in the second element.

So, to access each individual element, we would do something like this:

> food2[0]
=> ["chicken", 10]
> food2[0][0]
=> "chicken"
> food2[0][1]
=> 10

First, food2[0][0] is saying, “Show me the first element of the first element of the array food2.” And food2[0][1] is saying, “Show me the second element of the first element of the array food2.”

You can also use the same methods of the Ruby class array on subarrays.

> food2
=> [["chicken", 10], ["rice", 5], ["steak", 20], ["fish", 15], ["shrimp", 18], ["beef", 9]]
> food2.count
=> 6
> food2[0]
=> ["chicken", 10]
> food2[0].count
=> 2
> food2.last
=> ["beef", 9]
> food2.first
=> ["chicken", 10]

Keep in mind one important distinction for multi-dimensional arrays: Ruby will check whatever you call the method on.

For instance, if you wanted to check whether chicken is in the food2 array, you could not do this:

> food2.include?("chicken")
=> false

The reason is that food2 is just an array of arrays. So, you would have to do something like this:

> food2
=> [["chicken", 10], ["rice", 5], ["steak", 20], ["fish", 15], ["shrimp", 18], ["beef", 9]]
> food2[0].include?("chicken")
=> true

We had to specify the particular element ([0]) that we wanted to check for the string chicken.

In this case, we knew that the string chicken was stored in food2[0] because we put it there. How would we find it if we didn’t know? We’d have to use an iterator.

Iterators

An iterator is a mechanism in Ruby that enables you to cycle through data structures that store multiple elements (such as an array) and examine each element. One of the most commonly used methods is named each. Each is a method in the array class that comes with Ruby.

Let’s start simple. Suppose we wanted to print a list of all of our food items stored in the food array. How would we do this?

> food
=> ["chicken", "rice", "steak", "fish", "beef"]

food.each do |x|
puts x
end

chicken
rice
steak
fish
beef

A few things to be aware of here:

You can only call each on a collection of data.
Once you call each, you have to pass a block to it. A block is just a contained bit of code. Basically, you are saying to apply the code contained within the block to each element that you look at.

Block

There are two ways to use a block. The first is similar to the example above, where you just do this:

do |variable|
#some code
end

Note that you have to use a block with an iterator. You can define a block outside of an iterator, but in order to execute the block, you have to use it in conjunction with an iterator. That’s why we called do |x| after food.each earlier.

You can use one or more variables in your block. Those variables are local to the block alone, so they will be destroyed once you leave. Thus, if you had two blocks, you could use the variable x in both, and one wouldn’t affect the other.

In the example above about food, we have said, for each element in the array food, print it to the screen.

Another way to use a block is on one line, like this:

food.each { |x| puts x }

In this case, the opening curly brace ({) replaces the do, and the closing curly brace replaces the end. If your operation is just one line, then this way is convenient, although I have found that rereading such code in future is sometimes harder; so, I usually just use do and end, but that’s a personal preference. Do whatever makes you most comfortable.

The reason that blocks use variables is because the elements of the collection are actually not modified — unless you specifically chose to do so. Basically, what happens is that for every single iteration through the array, a copy of the new element is stored in x, and then x is used in the block.

Going through the food array, the local block variable x would look something like the following.

First iteration:

food[0] = 'chicken'
x = food[0]
x = 'chicken'

Second iteration:

food[1] = 'rice'
x = food[1]
x = 'rice'

Third iteration:

food[2] = 'steak'
x = food[2]
x = 'steak'

Using numbers would more clearly illustrate that the values aren’t changed in the original array:

> numbers = [1, 2, 3, 4, 5]
=> [1, 2, 3, 4, 5]
> numbers.each do |x|
… x = x + 2
… puts x
… end

3
4
5
6
7

> numbers
=> [1, 2, 3, 4, 5]

Here we’ve printed out the numbers 3, 4, 5, 6, 7 (i.e. 1+2, 2+2, 3+2, etc.); but at the end, the numbers array is the same.

Hashes

A hash is another collection type. It is a collection of “key-value” pairs. A key-value pair is a combination of the name of a container (i.e. the key) and the contents of the container (i.e. the value).

a => "Marc"

In the key-value pair above, the key is a, and the value is Marc.

A hash, then, is basically a list of these key-value pairs, separated by commas. A hash looks like this:

a =>"Marc", b => "Cheyenne", c => "Alexander", d=> "Mia"

Hashes and arrays have some key differences, though, and some things to note:

The keys are not integer keys. They can be characters, integers, strings, etc. — basically, any Ruby object type.
The keys are not ordered. So, you couldn’t say that a is “first” or that it “comes before” b in the example above, because Ruby does not look at the order of keys in hashes.
Even though the keys are not ordered, if you were iterating through a hash (which we will do shortly), Ruby would go through them in the order in which they were added to the hash. In our example, if we were printing out each value, Ruby would print out Marc, Cheyenne, etc. But don’t confuse this with the way in which array keys are ordered.

There are multiple ways to initialize (or initially create) a hash, but the most popular ways look something like the following.

To create an empty hash (i.e. a hash with no values):

> day = Hash.new
=> {}

To create a hash with particular values:

> names = Hash["a" => "Marc", "b" => "Cheyenne", "c" => "Alexander", "d" => "Mia"]
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia"}
> names2 = {"a" => "Marc", "b" => "Cheyenne"}
=> {"a" => "Marc", "b" =>"Cheyenne"}

You will notice that to create the hash, you don’t have to use the keyword Hash or square brackets ([]). You can use them if you like, or you can just use = { }.

For the keys and values, you also don’t need to put the keys in quotes. You need to do that only if you want to use strings as the key. Ruby also requires a => (pronounced “rocket”) to assign the value on the right side of the rocket to the key on the left side.

If you tried to do names2 without the quotes around the keys, you would likely get an error like this:

> names2 = { a => "Marc", b => "Cheyenne"}
=> #<NameError: undefined local variable or method `a' for main:Object>

To access values within the hash, you have to specify the name of the hash, along with the key for the value you are trying to access.

> names
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia"}
> names["a"]
=> "Marc"
> names["c"]
=> "Alexander"
> names[a]
=> #<NameError: undefined local variable or method `a' for main:Object>

Because we didn’t use quotes for names[a], the Ruby interpreter thinks that a is a local variable or a method and so can’t find a value for it, thus throwing an error.

If you tried to access a seemingly legitimate value via a legitimate key that has not been assigned a value, then Ruby would usually return nil.

> day["a"]
=> nil
> day[9]
=> nil  #For you Day9 fans, don't worry… I am a fan too :)

Suppose you wanted to create a hash in which every value has a “default” value. You could do something like this:

> year = Hash.new("2012")
=> {}
> year[0]
=> "2012"
> year[12]
=> "2012"

All we’ve done was call the method new on the Ruby class Hash and pass the default value of 2012 into that method. So, when trying to access a value that doesn’t exist, instead of returning nil, Ruby would return the default value (2012).

You can use a number of methods with hashes:

> names.keys
=> ["a", "b", "c", "d", "e"]
> names.values
=> ["Marc", "Cheyenne", "Alexander", "Mia", "Christopher"]

As you can guess, the keys just returns all of the keys in the hash, and the values returns all of the values.

> names.length
=> 5
> names.has_key?("a")
=> true
> names.has_key?("z")
=> false
> names.has_key("a")
=> #<NoMethodError: undefined method `has_key' for #<Hash:0x55c797d7>>

Note that the name of the has_key method is actually has_key?. If you left out the ?, it would throw an error like the one above.

All that has_key? is doing is checking the hash to see whether any key matches whatever is in the brackets. If it finds a match, then it returns true; if it doesn’t, it returns false.

> f_names = names
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia", "e"=>"Christopher"}
> l_names = {"g" => "Gayle", "h" => "Gayle", "j" => "Jackson", "m" => "Brown"}
=> {"g"=>"Gayle", "h"=>"Gayle", "j"=>"Jackson", "m"=>"Brown"}
> f_names.merge(l_names)
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia", "e"=>"Christopher", "g"=>"Gayle", "h"=>"Gayle","j"=>"Jackson", "m"=>"Brown"}
> f_names
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia", "e"=>"Christopher"}
> l_names
=> {"g"=>"Gayle", "h"=>"Gayle", "j"=>"Jackson", "m"=>"Brown"}

All we’ve done above was create a new hash, f_names, by assigning it the existing names hash. Then, we created another hash, l_names, that has a few last names. Then, we just merged the two hashes to create a master hash. However, because we just ran the merge method without assigning the result to any variable, it wasn’t stored. If you check the values of f_names and l_names after, you will see that they look exactly the same as before we ran merge.

If we wanted to store the value of the merge, we would have had to do something like this:

> master_hash = f_names.merge(l_names)
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia", "e"=>"Christopher", "g"=>"Gayle", "h"=>"Gayle", "j"=>"Jackson", "m"=>"Brown"}

Another approach is to do a “destructive” merge. This is an interesting feature of Ruby. For many (perhaps most) methods, if you add an exclamation point to the end of the method’s call, you actually replace the value of the method’s caller with the returned value. For example:

> f_names
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia", "e"=>"Christopher"}
> l_names
=> {"g"=>"Gayle", "h"=>"Gayle", "j"=>"Jackson", "m"=>"Brown"}
> f_names.merge!(l_names)
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia", "e"=>"Christopher", "g"=>"Gayle", "h"=>"Gayle", "j"=>"Jackson", "m"=>"Brown"}
> f_names
=> {"a"=>"Marc", "b"=>"Cheyenne", "c"=>"Alexander", "d"=>"Mia", "e"=>"Christopher", "g"=>"Gayle", "h"=>"Gayle", "j"=>"Jackson", "m"=>"Brown"}

As you can see, the f_names value after we ran the destructive merge method (merge!) is now the same value as the merged hash.

Another method that you can use with hashes is each. But it is slightly different. With arrays, you just have to pass in one variable to the block (which essentially represents the index of the array). With hashes, you have to pass in two variables: one that represents the key, and another that represents the value.

> f_names.each do |key, value|
.. puts "#{key} is #{value}"
.. end
=> "a is Marcb is Cheyennec is Alexanderd is Miae is Christopherg is Gayleh is Gaylej is Jacksonm is Brown"

This looks a little messy. Here is what’s happening:

Reading from left to right, Ruby reads the left-most and oldest value first, and it stores those values in key and value. So, after the first iteration, key would be a, and value would be Marc.
Then, Ruby goes inside the block and executes top down. The first command is puts, followed by a string. In other words, it will print everything in quotes to the screen.
What is that strange syntax in the quotes after the puts? That’s called “string interpolation.” It basically says, stick the value of this variable into my string at this exact position. Thus, after the first iteration, puts would do this:
1. Look for the key variable.
2. Print the key variable to the screen (i.e. a).
3. Then print a space (because we put a space between the key and the is).
4. Print the next word (is).
5. Then print another space.
6. Then print the value variable (Marc). (The entire string, after the first iteration, would be a is Marc.)
7. Go to the next command because this puts command is done.
8. Sees end, so goes back to the beginning of the block to see whether any more elements are in this hash object.
Because it is in a block, it just repeats this entire process for every key-value pair in the hash until there are no more.
Because we didn’t add a space before the last double quotes on the puts line (and we didn’t put a space after the first quote on the puts line), no space will be between the last character of the first iteration and the first character of the second iteration.
In other words, if puts looks like puts " #{key} is #{value}", then the resulting string might make more sense: a is Marc b is Cheyenne c is Alexander etc.

I intended for the output to make sense, but when I saw the result, I realized that this has tripped me up many times in my career, so I figured to highlight it.

You can use a lot more methods on hashes, many of which you should be familiar with because they look like others we have covered here, such as value? (note the ? — I’m not asking a question here), and they look similar to the methods we went over in the arrays section, such as include?, empty?, eql?, size, etc.

The last element of Ruby that you should be familiar with is an object type called a symbol.

Symbols

A symbol is an object type that resembles a string, but is not quite one. The major difference between a symbol and a string is that a symbol always begins with a colon (like :name). (For more information, see the “Symbol” article in the Ruby documentation and “The Ruby_Newbie Guide to Symbols” on Troubleshooters.com)

Symbols work nicely with hashes because you can use them as the keys instead of strings.

> f_names
=> {:a =>"Marc", :b =>"Cheyenne", :c =>"Alexander", :d =>"Mia", :e =>"Christopher"}
> f_names[:a]
=> "Marc"

The good thing about this is that you no longer have to worry about all of those quotes for both the keys and the values… but you can still remember the words for the keys.

> pets = {:dog => "Cookie", :cat => "Snowy", :fish => "Goldie"}
=> {:dog=>"Cookie", :cat=>"Snowy", :fish=>"Goldie"}
> pets[:dog]
=> "Cookie"
> pets[:fish]
=> "Goldie"

Symbols make dealing with hashes much simpler than using strings as keys. You can, of course, use hashes for anything else in the Ruby language; their main function is to store values and make retrieval easier on the interpreter (since handling strings has many rules).

Conclusion

I hope you have learned a lot here. Remember that this guide to Ruby is not comprehensive, but simply an introduction tailored to those with little or no programming experience. It’s not written in the typical programming tutorial style because I’ve always found that to be a bit difficult. I need to understand the whys behind the whats, so I’ve taken that approach here. I also don’t profess to be a Ruby ninja; I just wanted to learn how to build Web products myself, so I taught myself Ruby and Rails.

You now have the foundation to play with Try Ruby some more or to install Ruby on your system and get started (Google it).

Good luck, and remember that true learning often happens when you are struggling with a problem. When you spend one week stuck on a “very simple” problem and you eventually figure it out, you are guaranteed not to make that mistake again. And when you get stuck, don’t panic. Just take a break; maybe Google it and see what solutions others have had. But don’t just copy and paste code. Figure out why it does what it does and how it can help you. That’s how you learn.

If I was unclear with anything, please let me know in the comments.

Additional Reading

There are fabulous books on Ruby to help get you started. Here are some of my favorites.

Why’s (Poignant) Guide to Ruby
This wonderful comic has become a classic in the Ruby community. In fact, its author (Why the Lucky Stiff — yes, that’s his name) disappeared a few years ago, which created a somewhat cultish mystique around the work that he did. His wife let the world know that he is fine, but he is no longer an active member of the Ruby community (Google him if you are interested in the saga).
Humble Little Ruby Book
Buy the PDF or read it free online. The writing style is engaging.
Eloquent Ruby
This book really helped me wrap my brain around “the Ruby way” of programming. It is a little more advanced than the two resources above, but once you have some of the basics down (i.e. once you have a solid understand of everything we’ve covered in this series), you should be able to learn a lot from this book. Russ’ tone is engaging and his writing easy to understand.
Programming Ruby: The Pragmatic Programmer’s Guide
This is a little drier in presentation and tone, but rich in content. It is also known as Ruby Pickaxe and the Ruby Bible. A solid encyclopedia of all aspects of the Ruby programming language. The reason it is called Pickaxe is because it had a picture of a Pickaxe on the cover. The first version is free to read, although it is a bit outdated.
Programming Ruby 1.9: The Pragmatic Programmer’s Guide
A more up-to-date Programming Ruby (aka Pickaxe). While not free, this one is a must have for all Rubyistas.

(al) (km)

The History Of Usability: From Simplicity To Complexity

2012-05-23T12:55:03Z

The story of usability is a perverse journey from simplicity to complexity. That’s right, from simplicity to complexity—not the other way around.

If you expect a “user-friendly” introduction to usability and that the history of usability is full of well-defined concepts and lean methods, you’re in for a surprise. Usability is a messy, ill-defined, and downright confusing concept. The more you think about it—or practice it—the more confusing it becomes. We learned that the history of usability is a “perverse journey from simplicity to complexity”.

What Is Usability?

Early Roots of Usability

If we go far back in history, Vitruvius (1st century BC) was probably the first person to lay forth systematic and elaborated principles of design. His three core design principles became very influential:

Firmitas: The strength and durability of the design;
Utilitas: A design’s usefulness and suitability for the needs of its intended users;
Venustas: The beauty of the design.

Vitruvius’ work was an inspiration to people like Leonardo da Vinci, who drew the well-known Vitruvian Man (fig. 1 below). By empirically measuring and calculating the proportions of the human body, and emphasising the “utilitas” principle, Vitruvius may be considered the first student of ergonomics and usability.

Figure 1: The Vitruvian Man drawing was created by Leonardo da Vinci circa 1487 based on the work of Vitruvius.

Military Roots

The discipline of usability is also rooted in the discipline called Human Factors, which started as military personnel asked themselves the very morbid question:

“What design do we need to kill more enemies through better matching soldier and weapon? And thus avoid getting killed ourselves.”

Both World War I and World War II fueled research into Human Factors. When designing artillery cannons, for example, usability yielded more precision, greater kills, and shorter training of personnel.

Thus, military designers could extract some very concrete usability metrics. For example:

How quickly will a new crew member learn how to use the artillery cannon (now that the former crew member is dead)?
How many rounds per minute (ordnance) is the cannon able to fire with an inexperienced versus an experienced crew?
How will improving the design of the cannon improve target acquisition (and thus kill more enemies)?
How does a design improvement decrease soldier fatigue (as a consequence of a lighter cognitive load)?

Figure 2: Photograph of the French 320 mm railway gun Cyclone, taken in Belgium in 1917. The gun required not only trained personnel to fire it, but also trained personnel to drive it.

Figure 3: A 155 mm artillery shell fired by a United States 11th Marine Regiment’s M-198 howitzer. The setup time (and thus usability) is essential as anti-artillery weapons necessitate that the position of the howitzer be changed very quickly after firing.

Recent Roots of Usability

The concept of usability has its more recent and direct origins in the falling prices of computers in the 1980s, when for the first time it was feasible for many employees to have their own personal computer. In the 80s, most computer users had practically no, or only basic, training on operating systems and applications software. However, software design practices continued to implicitly assume knowledgeable and competent users, who would be familiar with technical vocabularies and system architectures, and also possess an aptitude for solving problems arising from computer usage.

Such implicit assumptions rapidly became unacceptable. For the average user, interactive computing became associated with constant frustrations and consequent anxieties. Computers were obviously too hard to use for most users, and often absolutely inpractical. Usability thus became a key goal for the design of any interactive software that would not be used by trained technical computer specialists.

The current understanding of usability is different from the early days in the 1980s. Usability used to be a dominant concept but this changed with research increasingly focused on usage contexts. Usage quality no longer appeared to be a simple issue of how inherently usable an interactive system was, but how well it fitted its context of use.

Usability Evaluation: What’s Good And What’s Bad?

Usability is a contested historical term that is difficult to replace. User experience specialists have to refer to usability, since it is a strongly established concept within the IT landscape. In simplified terms, usability work is about finding out what’s good and what’s bad. However, when we examine the hundreds of usability evaluation methods in use, we do see that different approaches to usability result in differences over the causes of good and poor usability. That may sound complicated but let’s take two different approaches to usability:

If you think usability is a feature of an interactive system, your approach to usability may be called essentialist—i.e. poor/good usability resides in the “essense” of the system. You will typically find yourself saying things like “that website is not user-friendly”, “a website or system has poor usability when there is no visibility of system status”, “I can reliably measure which website has the best usability”, etc. This means you think that all causes of user performance are due to technology. In that case, you will typically use system-centered usability inspection methods to identify such causes.
On the other hand, if you think usability is a feature of the interaction between user, computer and the context, your approach to usability is contextual—i.e. depending on the context. This means that you think questions of user performance have different causalities, some due to technologies, and others due to some aspect(s) of usage contexts, but most due to interactions between both. Several evaluation and other methods may be needed to identify and relate a nexus of causes. You will often find yourself saying vague things like “that depends…”, “well… this website checkout procedure is great for male, fact-oriented, middle-aged buyers, but not for an impatient teenager doing the purchase on his smartphone sitting in the bus”, etc.

The reason I mention the essentialist/contextual distinction is that anyone involved with usability should—ideally—be able to say “this website/technology/system is good, that one is bad”. After all, isn’t that what your client or boss is paying you to do?

To answer if the usability of a website is good or bad you have to employ a usability method. And your choice of usability method will depend on your approach to usability—whether you admit it or not. Maybe you’ll deny it and say, “I’ve never heard of any essentialist/contextual approaches to usability.” However, that would be like selling French wine without ever having spent time in a French vineyard. You can do it, but at some point your client or boss will start asking questions you can’t answer. Or your decisions will have unexpected side-effects.

So what usability method should you choose to determine “what’s good and what’s bad”?

Analytical And Empirical Evaluation Methods

Usability work can involve a mix of methods and the mix can be guided by high level distinctions between methods, for example the distinction between analytical and empirical evaluation methods.

Analytical evaluation methods are based on examination of an interactive system and/or potential interactions with it. You analyse the system or analyse the interaction with the system.
Empirical evaluation methods, on the other hand, are based on actual usage data.

Analytical evaluation methods may be system-centred, like Jakob Nielsen’s Heuristic Evaluation or interaction-centred, like the Cognitive Walkthrough method. Design teams use the resources provided by a method (e.g. heuristics) to identify strong and weak elements of a design from a usability perspective.

Three types of analytical evaluation methods:

Inspection methods tend to focus on the causes of good or poor usability.
System-centered inspection methods focus solely on software and hardware features regarding attributes that will promote or obstruct usability.
Interaction-centered methods focus on two or more causal factors (i.e. software features, user characteristics, task demands, or other contextual factors).

Figure 4: Jakob Nielsen’s Heuristic Evaluation is a good example of an analytical evaluation method. Heuristic Evaluation became the most popular user-centered design approach in the 1990s, but has become less prominent with the move away from desktop applications.

Empirical evaluation methods focus on evidence of good or poor usability, i.e. the positive or negative effects of attributes of software, hardware, user capabilities and usage environments. User testing is the principal project-focused method. It uses project-specific resources such as test tasks, users, and also measuring instruments to expose usability problems that can arise in use. Also, empirical experiments can be used to demonstrate superior usability arising from user interface components (e.g. text entry on mobile phones) or to optimise tuning parameters (e.g. timings of animations for windows opening and closing).

Such experiments assume that the test tasks, users and contexts allow generalisation in regards to other users, tasks and contexts. Such assumptions are readily broken, e.g. when users are very young or elderly, or have impaired movement or perception.

How To Balance The Mix: Why Is It Difficult?

Achieving a balanced mix of evaluation methods is not straightforward, and involves more than simply combining analytical and empirical methods. This is because there is more to usability work than simply choosing and using methods.

Evaluation methods are as complete as a Chicken Fajita Kit, which contains very little of what is actually needed to make Chicken Fajitas: no chicken, no onion, no peppers, no cooking oil, etc. Similarly, user testing ‘methods’ miss out equally vital ingredients and project-specific resources such as participant recruitment criteria, screening questionnaires, consent forms, test task selection criteria, test (de)briefing scripts, target thresholds, data analysis methods, or reporting formats.

There is no complete published user testing method that novices can pick up and use ‘as is’. All user testing requires extensive project-specific planning and implementation. Much usability work is about configuring and combining methods for project-specific use.

The Only Methods Are The Ones That You Complete Yourselves

When planning usability work, it is important to recognise that so-called ‘methods’ are simply loose collections of resources better understood as ‘approaches’. There is much work in getting usability work to work, and as with all knowledge-based work, methods cannot be copied from books and applied without a strong understanding of fundamental underlying concepts. All methods must have unique usage settings that require project-specific resources. For user testing, for example, these include participant recruitment, test procedures and (de-)briefings. There are no universal measures of usability that are relevant to every software development project.

The Position So Far

There are fundamental differences on the nature of usability, i.e. it is either an inherent property of interactive systems, or an emergent property of usage. There is no single definitive answer to what usability ‘is’.
There are no universal measures of usability and no fixed thresholds above or below which all interactive systems are or are not usable. There are no universal, robust, objective and reliable metrics. All positions here involve hard won expertise, judgement calls, and project-specific resources beyond what all documented evaluation methods provide.
Usability work is too complex and project-specific to admit generalised methods. What are called ‘methods’ are more realistically ‘approaches’ that provide loose sets of resources that need to be adapted and configured on a project by project basis.

Readers could reasonably draw the conclusion from the above that usability is an attractive idea in principle that has limited real-world application. However, the reality is that we all continue to experience frustrations when using interactive digital technologies, and even we would say that we find them difficult to use. Even so, frustrating user experiences may not be due to some single abstract construct called ‘usability’, but instead be the result of unique complex interactions between people, technology and usage contexts.

Usability In The Design Room

In well directed design teams, there will not be enough work for a pure usability specialist. This is evidenced by a trend within the last decade of a broadening from usability to user experience expertise. User experience work focuses on both positive and negative value, both during usage and after it. A sole focus on negative aspects of interactive experiences is becoming rarer. Useful measures of usage are extending beyond the mostly cognitive problem measures of 1980s usability to include positive and negative effect, attitudes and values, e.g. fun, trust, and self-affirmation. The coupling between evaluation and design is being improved by user experience specialists with design competences.

Many user experience professionals have also developed specific competences in areas such as brand experience, trust markers, search experience/optimisation, usable security and privacy, game experience, self and identity, and human values. We can see two trends here. The first involves complementing human-centered expertise with strong understandings of specific technologies such as search and security. The second involves a broadening of human-centered expertise to include business competences (e.g. branding) and humanistic psychological approaches (e.g. phenomenology, meaning and value).

As such, a usability person is not a lone judge who makes the call “is this usable?” Instead, the usability proficient person will often be a team player taking on many roles in the product development lifecycle.

Figure 6 A-B. From Solo Specialist to Team Member: User Experience—as opposed to Usability—as an integrated part of design teams. Copyright of leftmost picture: Flickr user ‘Tety’ through the Creative Commons Attribution Share-Alike 2.0 licence

Conclusion: Are You Confused?

This Smashing Magazine article is a digested version of the monstrous 25,000 word encyclopedic introduction to the history of Usability Evaluation at Interaction-Design.org. It’s available in a special version for Smashing readers.

Did this article confuse you more than it informed you? Well, it should! If you want an answer to the question of “what is usability?”, it’s just as complicated as asking “what is beauty?” The more you think about it, the less you feel you know. I don’t believe you will ever find the answer to the question “what is usability?”, but I nevertheless hope you—as I—will continue to ask that very question. And be confused again and again. Confusion is—after all—the mother of wisdom.

The concept of usability is a product of millions of designers trying for decades to describe what they are doing to make technology easier and more pleasant. As such, the concept is immensely complex. It may have started out as a simple concept but the more people who are involved with usability, the more multi-faceted the concept will become. Therefore, the history of usability is a journey from simplicity to complexity. Is that journey worth the effort? Certainly! Anyone who masters usability—and all its facets—has a power position when it comes to designing easy/pleasant/cool/useful/usable/etc. technology. As confusing as that endeavour may be!

(jc) (il)

Smashing Magazine Feed

Desktop Wallpaper Calendar: June 2012

Without Angry

Hello Summer

Chromatic Baba

Fontstache

Go Nuts For Donuts

Brjs – Playing Cards

Sunset In Jamaica

Beach

Dreams

Friendly Fire

June Romance

Magic Night

Africa

Fruit Ninja Did This

Basketball Nagraj

Retro Smile

Vidovdan – Folk Festival

I Need Holidays

Out Of The Box

Fete De La Musique

June Pastures

Illustration

Euro 2012

Paris Summer

Join In Next Month!

What’s Your Favourite?

Useful jQuery Function Demos For Your Projects

What Is jQuery?

jQuery And CSS

.css()

.addClass() and .toggleClass()

jQuery Animations And Effects

.animate()

setInterval() and clearInterval()

setTimeout() and clearTimeout()

.slideToggle() and .fadeToggle()

.delay()

jQuery And DOM Manipulation

.clone()

.html(), .text() and .empty()

.append(), prepend(), .after() and .before()

jQuery And AJAX

$.ajax()

.load()

JSONP

jQuery And Events

.bind() and .unbind()

.live(), .on() and .off()

.delegate()

.preventDefault()

.stopPropagation()

.stopImmediatePropagation()

Finding, Looping And Filtering Results

$.each() and .each()

$.data(), .data(), $.hasData() and $.removeData()

.match(), .test() and :contains()

.find()

.filter()

.slice()

.prev() and next()

$.extend()

.serialize() and .serializeArray()

Conclusion

Design Process In The Responsive Age

The Problem

Work More or Work Efficiently?

Solution: The Priority Guide

Don’t Let the Simplicity Fool You

A Note About Context

Tools To Consider

Style Tiles

Keynote for Wireframes

Conclusion

MUD: Minimum Usable Design

A Totally Made Up Theory

MUD

An Example

Design Is Never Finished