Fables, Myths And Narratives: Converting Our Stories Into Multi-Screen Experiences

Posted by Smashing Magazine Feed at 05-13-2013

Storytelling takes many forms. In the past, stories were told orally, with people telling and retelling myths, fables and even histories. As writing technology became more prevalent, we began to record our stories, and we told them in the pages of books. Now, our society is awash in different devices and technologies, and those traditions of spoken stories and printed stories are blurring.

Multi-screen narratives are being told across all kinds of platforms, pages and devices, making for truly immersive experiences. We are watching them, tapping them and learning from them. They immerse us in the storyteller’s world. This article outlines what I believe are the five essentials of telling multi-screen stories.

How I Fell In Love With Interactive Storytelling

First, a little background. My childhood was spent in Nigeria, West Africa. I am a member of the Tiv tribe, a group of about 6 million people clustered in Nigeria’s Benue River Valley. As a child, I heard a lot of Nigerian folktales, about animals, humans and even magic. In Nigerian narrative tradition, stories are often told orally, in front of a gathered audience. During festivals and cultural events, men even dress up in elaborate costumes and perform stories for the crowds. I have vivid memories of these stories and have always been curious about how they could be translated into something digital and interactive.

The Kwagh Hir, or Thing of Magic, my tribe’s largest cultural festival (Image: Naptu2)

Those fables are a piece of my cultural inheritance. They always seemed to contain essential truths about humans. Take the story of the Ear and the Mosquito. One day, the Ear steals food from the Mosquito and refuses to pay it back. In anger, the Mosquito visits the Ear every evening, demanding the food to be returned, annoying Ear all night with his buzzing. It’s an old tale, with many versions, but the moral is consistent: don’t steal from your friends.

Creating modern, interactive versions of these stories is possible, but how exactly do we do that? Let’s begin by talking about what I mean by the word “multi-screen.”

A Bit About Context And Screens

When speaking about multi-screen storytelling, remember that screens have different contexts, not only different capabilities. The same screen on which you carelessly watch videos at home becomes a closely guarded viewport when you’re watching a movie on a crowded train. The context in which people view stories is more important than the device’s specifications. When we tell interactive stories, we need to be aware of this, and embrace it.

I like to focus on the following screens:

• Sensors (Twine, GPS, Arduino, motion detectors, etc.)
• Mobiles and tablets (phones, tablets, laptops and everything in between)
• Flat-screens (desktops, TVs, etc.)
• Public and immersive displays (store kiosks, large stadium screens, projectors, Kinects, etc.)

Not all of these need to be used at the same time, because they won’t all be appropriate to the story you are telling. Context is extremely important.

Now, as promised, here are the five essentials of multi-screen storytelling.

1. Divide Your Story Into Separate Content Blocks

When we create multi-screen narratives, we need to find natural breakpoints in the story, places where the visual or narrative content can easily be separated. This enables us to deliver different segments to different devices, in different contexts.

Kolobok is a Slavic children’s story about the adventures of a round yellow cake. For the Moscow International Festival, a large team of designers and animators from SilaSveta Studio incorporated it into a truly fascinating demonstration of storytelling. Before the show, the team set up a large touchscreen at the children’s height. With their hands, the kids could manipulate parts of the animation by adding movement and color.

A public display for children to play with

For the show itself, the full story was projected onto the facade of a large building, allowing the crowd of adults and their children to watch the narrative unfold. Along with sound, it made for another discrete content block, one that closely resembled a 3-D movie.

The full animated story in front of a large festival crowd

While the touchscreen and the movie were different views of the same content, they could exist as independent pieces and did not have to appear next to each other. The SilaSveta team found the natural breakpoints in its story and created two separate visual experiences to match them.

Questions to Ask

• Where are the breakpoints in the story? Divide your content so that it makes sense in context. The practice of responsive design gives us numerous guidelines on how to do this.
• Can those content blocks exist independently? Sometimes, the answer is no, but it depends on the story. In the Kolobok example above, they can. In other interactive stories, such as Snow Fall from the New York Times, the blocks are chapters in a single story and should be kept together.

2. Offer People Multiple Perspectives

Bear 71 is an award-winning multi-screen experience created by Jeremy Mendes and Leanne Allison. The creators tell the story of a bear living in Banff National Park in Canada. It feels like a cross between a role-playing game and a TV documentary, and as a linear narrative with a non-linear interface, it works beautifully.

The Bear 71 story is told in a highly abstracted interface.

Multiple viewpoints are accessible. Online, you roam in a stylized landscape, watch crittercam footage from the forest, and otherwise live as bears do — freely. Even though it may look like a game interface, you are not so much “playing” as you are participating in a story. Watching real crittercam footage, you see what the forest silently sees. You also have the option to turn on your webcam (“stealth mode”) to see other users around the world, all watching the same story online.

During shows and installations, the team responsible for Bear 71 set up augmented-reality applications and motion-detection cameras, so that visitors could experience what it’s like to have their pictures taken with one. By playing with the augmented-reality apps and the motion-detection cameras at the installations, users got a bit of the same physical experience that the bears had.

Questions to Ask

• Does the narrative change when viewed from a different perspective? A variety of perspectives can make a narrative much more fascinating. Bear 71 forces us to see the world first from the bear’s perspective and to sympathize with its loss of habitat, but other viewpoints take a slightly different angle. The voyeurism common in our digital sharing culture takes on a different meaning when used for animal surveillance.
• What data sets can be used in the narrative? Bear 71 cleverly combines crittercam video, GPS data, cell tower data, augmented reality, and topographical data. The photographs of visitors to the installation provide an additional emotional layer of data. The data we bring into our stories helps to define additional viewpoints and characters.

3. Redefine A Tradition

As Western culture has moved more deeply into Nigeria, Nigeria’s traditions are weakening. I wanted to take a piece of my culture and put it in the cloud, instead of leaving it locked in the heads of our oral storytellers. That meant redefining how the stories are relayed, how they are saved and, most importantly, what messages they convey to the audience.

In 2011, I started a project named Pixel Fable in which I take those traditional stories and reinterpret them online. In essence, I’m creating an interactive archive of Nigerian stories. As mentioned earlier, the oral histories of Nigerians are rich, but capturing them and translating them into digital stories means they will reach a wider audience. About 25% of my website’s visitors come from the US, while another 25% come from Japan. Canada, France and Germany also send a fair amount of traffic.

Pixel Fable uses responsive websites, iOS apps and augmented-reality animations to reinterpret Nigeria’s oral history.

An introductory screen from “Cricket and Mud Brick,” a new Pixel Fable story built with the Tapestry app

I’ve relied on two primary contexts to reinterpret the old Nigerian storytelling tradition. The first is people on their tablets and phones, clicking on and reading the stories. The spread of mobile devices makes this inevitable — why not tell African fables in a more accessible context? The second is my attempt to update the moral lessons for our modern age. While the original story of the Ear and the Mosquito may be a funny tale about annoying insects, the lesson can be updated to speak about how mosquitoes spread malaria in Nigeria. There’s room to redefine our old myths for the 21st century.

Questions to Ask

• Will people love or hate the reimagined version? Not every fable or myth can (or should) be recreated digitally. However, if people have an emotional reaction to a story that you have designed and pushed out to multiple screens, that is usually a good sign.
• If people talk about your narrative, will it bring about change in society? Each Pixel Fable story has a message. Most fables do. Some revolve around love triangles, others around the wisdom of elders, and there’s even one about why you shouldn’t get angry at your friends. They are small messages, but put together, they force us to reconsider how we treat the narrative history of people in Nigeria and West Africa.

4. Immerse People In The Narrative

The Walking Dead, the famous comic and now TV show, used a polling Web app (AMC’s Story Sync, if you like marketing-speak) to ask viewers questions and show related content as an episode was being broadcast on TV. While the app was simply timed to each scene, it was an experiment in multi-screen storytelling that invited audience participation, not just audience attention. Polling has a gimmicky feel to it, but that probably came about as a result of Hollywood pressure and doesn’t reflect the value of the concept in general.

Polling and syncing apps extend narratives from the TV to the couch.

The creators also added mobile gaming to the mix, bringing viewers “into” the story in a completely different way, in different contexts.

All of these facets of each story’s arc enabled people to immerse themselves in this apocalyptic narrative. Jason Spero of Google notes the need for a seamless experience as users move between devices. Other people, however, say that a second-screen experience can be extremely distracting, forcing viewers to miss key parts of the TV show. It is the opposite of an immersive experience, they say, and is confusing to use. In my opinion, each content block should work independently to avoid putting users in this position.

Questions to Ask

• Will people forget where they are? I’ll be the first to admit that this is not always a good thing. I can’t count the number of times that I’ve almost missed my train stop because my head was buried in my phone. Context, not only device capability, is key. Do you want users to get lost in the story or just engage in a manageable chunk?
• Do the screens you have chosen feel natural? By this, I’m not referring to pixel density. That is simply impossible to control, and if the story if good, it won’t matter anyway. The screens that people choose will depend a lot on the tasks they want to complete, so make your story feel natural for whatever content block they are interacting with.

5. Design Contextual Interactions

Recently, a number of storytelling apps have relied on location to serve additional content, much in the same way that Foursquare or Google Maps do. The Silent History is a dystopian science-fiction story about children who do not speak. The iPad app contains the whole story, but by visiting certain geo-tagged locations, users can access additional content.

For a novel about children all over the US, inviting readers to physically go to where the story’s kids are makes perfect sense. The additional contextual interaction makes the story more layered and thought-provoking, in a way that a simple app would not be.

We use map data every day, to look for restaurants, check the weather, see road conditions and even check for public transit delays. Other contextual interactions make sense when creating digital stories: taking photographs, texting, sharing and saving information, even body motion. Use these, along with your UI and UX skill sets, to devise new storytelling methods.

Questions to Ask

• Does the device matter? With the rise of responsive design workflows, our content should not be device-dependent. Some things, however, such as camera or GPS functionality, may be integral to a part of your story, and so the device would need to be factored in.
• Should the interface be designed as a seamless part of the narrative? As people who work on the Web, we really have a strength here. If we choose to make the interface part of the story, then we can rely on our experience in building websites and content management systems.
• Will your story “remember” anything? As a child, I folded over the top corner of the page when I had to put a book down. It was a simple way to keep my place. With a narrative split across multiple devices, it might be necessary to design an interaction that flags where you’ve gotten to and then returns you there when you visit again. That all depends on the content, but the question does need to be asked. Everyone hates losing their place on the Internet and having to navigate back, so perhaps we should enable a memory in our stories as well.

Conclusion

We have conceptualized different uses of multiple screens to tell stories. All of us, from every corner of the globe, have intensely rich cultures filled with stories and fables. Using them to create interactive narratives is another way to explore the power of the Web, to wow people and to record our cultural history.

I would love to see what you come up with, or hear about other examples of clever digital storytelling.

(al) (ea)

---

© Senongo Akpem for Smashing Magazine, 2013.

Posted in Design | Add Comments »

Freebie Friday: 4 Spiky Polygonal Brushes

Posted by BittBox at 05-10-2013

Advertise here with BSA

Download .ZIP

Posted in Design | Add Comments »

Sharing Your Experiences: How To Contribute To WordPress

Posted by Smashing Magazine Feed at 05-10-2013

WordPress is built by volunteers. People from all over the world collaborate to create the core software, write the documentation, provide support, translate WordPress, organize events and generally keep the project running. Individuals work on WordPress in their free time, and companies ask their employees to get involved.

Part of WordPress’ success is that the community consists not only of developers, but of designers, user experience experts, support volunteers, writers, users, accessibility experts and enthusiasts. This diverse input strengthens the project. It also means you have more space to get involved. Whatever your skill set, the WordPress community has room for you.

A bunch of WordPress contributors.

In this article, we’ll talk about the different contributor groups and how you can take part. I spoke with the current team reps and project leads, who have offered advice on how to get started with their contributor groups. But first, why should you get involved with WordPress?

Why Get Involved?

I had a chat with Matt Mullenweg, one of the founding developers of WordPress, about contributing to the project. We started off talking about the mix of people who contribute to WordPress. There are contributors who are sponsored by businesses that use WordPress, such as Automattic, Dreamhost and 10up, and then there are passionate individuals who dedicate their own time to the project.

“People who use WordPress are passionate about open source, want to democratize publishing and like to learn. I would say that’s the number-one biggest characteristic, because contributing to open source, and particularly the WordPress project, is probably one of the best learning opportunities on the Internet.”

Matt chats about the future of WordPress at the WordPress Community Summit 2012. (Image: konsobe)

For Matt, this is the greatest benefit you will get from contributing. You get to be part of a large, supportive community that has an impact on the lives of millions and millions of people. Something you do in an afternoon can have an effect on people all over the world.

“You can’t knock on the door at Google and say, “Hey, do you mind if I help you out with your home page? I have some ideas for you.” But you could come to us and say, “Hey, I have some ideas for your dashboard, and here are some patches.””

A number of challenges face the WordPress project:

• Contributor balance
  Currently, the number of contributors is skewed towards people involved with code. Plenty of opportunities lie in other areas — support, documentation and marketing, for example — but not so many people are getting involved.
• Mobile
  Not enough people are getting involved with mobile. Most of the people involved with mobile are currently sponsored by Automattic. Because mobile is fast becoming the way that people interact with the Internet, this is a crucial group and currently has a dearth of contributors.

With that in mind, let’s look at the ways you can get involved with WordPress.

Core

Mark Jaquith is an independent developer and one of the lead developers of WordPress. These days, he is a jack of all trades in the project, working closely with younger and newer developers, helping to point them in the right direction. He was also the release lead for the 3.6 release cycle. The core team comprises all sorts of developers and designers — PHP and JavaScript developers and front-end developers and designers. These are the people who build the WordPress that you install on your server.

Being a lead WordPress developer makes Mark Jaquith happy. (Image: Michael Yoshitaka Erlewine)

I asked Mark how the the core contributor team works. He describes it as a set of concentric rings:

“You have the leads in the inner sanctum, and then you have the people with permanent commit access, and then you have the people to whom we give temporary commit access for release, and then there are the people whose patches are implicitly trusted and go in without too much inspection. It just keeps going out from there. Those are very fluid boundaries, so people flow between them.”

Challenges

As much as possible, the core team tries to work by consensus. Issues are discussed, publicly if possible, although anything contentious may be addressed in private discussion.

One of the biggest challenges facing WordPress is that not everyone is on the project full time. Even Automattic employees have other responsibilities within Automattic. This means that people can contribute varying amounts of time. If a lot of people see a dip in their free time, this can cause problems for the project. The core team tries to mitigate this by having more contributors and more people who can commit. However, a balance has to be struck because if there are too many committers, no one would know what’s going on.

Get Involved

You can start getting involved in a number of ways:

• Live chats
  Tap into the weekly live chats (Wednesdays 21:00 UTC, irc.freenode.net, #wordpress-dev). Before diving in, you should gauge at what point in the release cycle the project is at:
  • Early stages
    Planning the next release.
  • Middle stages
    Guiding the features and checking on progress.
  • Final stages
    Bug scrubs.
  • After a release
    Mostly an open forum, a good time to ask for advice on moving your ticket forward.
• Firehose
  You can subscribe to trac notifications and get notified of every comment in every ticket. It’s a lot of data to process, but you should get an idea of how the project works, various people’s roles, how much authority they have, and best practices.
• Ideas
  If you have an idea for a feature or anything else WordPress-related, a good place to start is to write a blog post about it. There is an ideas forum, but it’s not very well used. If you have a concrete idea, with a vision of how to implement it, a blog post may well get you more traction. It will give you space to flesh out the idea and provide an opportunity for other community members to comment on it.

Ready to get involved with WordPress core? Other than development skills, I asked Mark what skills someone should have:

“The number one skill you need for just about any job, but specifically working on open source, is communication skills. You need to have clarity, consistency, compassion, relatability, a little bit of a thick skin and a decent sense of humor.”

User Interface

In recent history, the UI group has been separate to core, but there has been discussion about merging it into the core group. UI handles WordPress’ user interface, user experience, and other elements related to quality, accessibility and graphic design.

The UI group talks UI in Georgia. (Image: konsobe)

Helen Hou-Sandi is the lead user interface developer at 10up, and is also involved in WordPress’ core with a focus on UI. She outlined six areas that the UI group currently focuses on:

• Graphic design
  This is only occasional work.
• UX design
  Including wireframes, storyboards and concepts.
• User testing
  Dave Martin from Automattic has been running a lot of user tests recently to help identify issues.
• Front-end development
  The HTML and particularly CSS to create the admin interface.
• Quality assurance
  While this is within the purview of the UI group, Helen noted that improvements could be made in this area.
• Accessibility
  This has its own group, but the UI group also tries to ensure that accessibility gets the attention it deserves.

The UI group has a number of different challenges. A particular problem for contributors can be that the CSS is huge. Jumping into them can be scary for some people.

I asked Helen what she gets out of contributing to WordPress:

“I love the community, and I think that the basic premise that WordPress is built on — democratizing publishing for everybody — is a really important one.… The premise that it’s making content management and creation easier and more accessible for more people was something that I loved, and altruism wins out.”

Get Involved

There are a number of ways to get involved:

• IRC
  Stop by the UI chat (Tuesdays at 19:00 UTC) or the chat room and introduce yourself, although doing it outside of meeting hours is usually best.
• Make blog
  Stop by the Make blog and introduce yourself. Offer to get involved with projects that are starting up.

Those are the two official places to get involved, but Helen said that she doesn’t mind someone reaching out on Twitter or even chatting about getting involved at WordCamps.

The UI group needs people with a lot of different skills, including CSS and PHP development. What the group really needs right now are JavaScript developers. Anyone who’s comfortable with things like Backbone.js or TinyMCE would be a huge asset.

UX designers are extremely valuable to the team because they are focused on the user’s perspective, rather than the designer’s perspective. Of particular value are people with a good sense of how an interface and workflow should work. As with all of the groups, being able to function as part of a team is important:

“Good communication skills are pretty important. They should be willing to chase something for a while, because things get lost all the time. We forget or we drop the ball, so somebody who’s willing to almost nag in a way and is confident enough to ask, “Hey, what’s going on with this?” is really good to have on board. To watch someone develop that kind of confidence is a really good thing to see.”

Mobile

The mobile group builds apps for six different platforms: iOS, Android, BlackBerry, Nokia, Windows, WebOS. It also helps to expand the API and XML-RPC layer, and it investigates new APIs and ways of tackling mobile. Its rep is Isaac Keyet, a mobile designer at Automattic. The mobile group isn’t currently involved in the move towards responsiveness in WordPress core, but Isaac would like to see the team becoming more involved in it in the future.

Isaac Keyet leads the WordPress mobile group. (Image Michael Yoshitaka Erlewine)

Given that mobile is growing exponentially, it’s crucial that more people volunteer for the WordPress mobile group. In addition to Isaac, only six developers are in the group. If you’re a mobile developer and you’d like to be involved in an open-source project, then WordPress is a great place to start.

Challenges

A number of technical issues affect development of the native apps. This is particularly true when dealing with XML-RPC or the API. Any plugin or theme can add to or modify the XML-RPC layer. This means that the app has to deal with malfunctions and improper responses in the XML-RPC layer and in the responses that are returned from the blog.

To deal with this, the team is using client-side clean-up libraries, which take the responses and clean them up. But the XML-RPC layer can fail in so many different ways that the libraries are not complete. This makes it a constant struggle to ensure that everything works in all possible instances.

Get Involved

As with the other groups, there are two ports of call for getting involved:

• Make WordPress Mobile
• The WordPress Mobile IRC Chat: 16:00 UTC on freenode, #wordpress-mobile

It’s no surprise that WordPress attracts PHP developers, and it’s not a place that mobile developers would instinctively think to look. The mobile apps are written in:

• Java: BlackBerry and Android
• Objective-C: iOS
• C#: Windows

Contributors with coding skills in any of these languages are extremely welcome. And there is a particular need for Windows Phone developers right now. This is the fastest-growing app at the moment; so, if you’re a C# developer, visit the weekly chat and see how you can help out.

Another skill that the group currently needs is graphic design. Isaac is the only person currently working on graphic design for the group. As he is overloaded with work, which means that designs can’t be escalated as quickly as the group would like.

If you really want to make a difference to the future of WordPress, the mobile group is a great place to start.

Polyglots

The polyglots team is responsible for translating WordPress and for wider global outreach. It is led by Zé Fontainhas, a Portuguese WordPress consultant who speaks countless languages and is very active in the global community.

Zé Fontainhas speaks all of the languages. (Image: Michael Yoshitaka Erlewine)

Zé identifies three major areas that the Polyglots team is responsible for:

• Translations
  The team translates WordPress core, as well as a number of plugins, such as BuddyPress and the import/export plugins.
• GlotPress
  GlotPress is the translation tool that makes collaborating on a translation of WordPress possible. It is open source, just like WordPress. Developers and designers are needed to test patches, suggest features and fix bugs.
• Community
  The global team will be a new branch of the polyglots team, focusing on increasing WordPress’ visibility worldwide and on connecting people from worldwide communities.

Challenges

Many of the challenges facing the polyglots team have to do with raising awareness and managing perceptions. Around 40% of all downloads of WordPress are not for the English language version, yet WordPress continues to be very US-centric.

“The proof of that is that we are talking about “international” as if it were an objective concept. It isn’t; it’s meaning really depends on where you’re looking from. So, when someone in the US says “international,” it means the world outside of the States, but when I say it, “rest of the world” includes the US. We need to first stop using that term. It means different things to different people.”

Other challenges include ensuring that developers prepare their code for translation. This means implementing proper practices for plugins, themes and even core code to be ready for translation.

Of course, things will always get lost in translation:

“The “Howdy” of the dashboard screen is untranslatable for mostly everybody in another language because the spirit gets lost. There’s no real translation for that.”

Get Involved

All you need to get involved is a WordPress.org user name. Then think about what you’d like to do:

• Translation
  Check whether a team is translating into your chosen language. Get in touch with them to see how you can help out. [find list of teams/contacts]
• GlotPress
  Head to GlotPress trac to see what tickets you feel you can help out with.
• Community
  Keep an eye out for the new global blog, which will be launching soon.

Essential skills for translating WordPress are pretty obvious: language skills and knowledge of how to translate. You have to understand context, and you have to understand English. With the community, you need to have an awareness of how communities work and how they can better interact with each other.

Support

Support forum volunteers are the backbone of WordPress. They patiently answer questions like “OMG my site is broken! Can you fix it?” in WordPress.org’s support forum. The team is currently led by Mika Epstein, the in-house WordPress expert at Dreamhost. Mika also reviews plugins for the plugin repository — she’s one busy lady!

For Mika Epstein, support never stops. (Image: konsobe)

Around 30 moderators are currently in the WordPress.org support forums. Only about 12 of the moderators are active, answering queries every day. About 200 people actively answer questions.

WordPress’ support volunteers focus on the following areas:

• WordPress.org support forums
  This is often the first port of call for people looking for WordPress support. Volunteers help people with things ranging from forming their request correctly to writing code. There’s room for volunteers at every level of the WordPress experience.
• IRC Chatroom
  Some people prefer to request support via the chatroom. If you want to instantly give feedback to people, you could start hanging out in the IRC chatroom on freenode at #wordpress.
• WordPress Stack Exchange
  Questions that used to show up on the wp-hackers mailing list have now found a home on WordPress Stack Exchange. If you’re keen to answer more advanced questions, you could dive in here.

Since the Community Summit, there has been discussion on how to create training courses on different aspects of WordPress. This now comes under the purview of the support group. The material will be available to anyone who wants to use it for teaching or training, but also anyone who wants to learn from it. Both online and offline training material will be created. These are intended to help people do more with WordPress and make it easier for them to contribute.

Challenges

The biggest challenge facing the support team is the signal-to-noise ratio. Many more people are asking questions than answering them. People get impatient and start bumping their threads or getting snarky. They expect fast responses, or they want a phone number to call. When people get irate, it’s easy for a supporter to get irate, too. After all, the volunteer is spending their own free time helping.

Another issue is that people think they don’t have enough knowledge to sufficiently answer questions. But, as Mika says:

“It’s hard to know everything. And that actually scares a lot of people off. They think, “Well, I don’t know everything, so I can’t answer anything.” No, no, no. Just answer the one thing. That would make us really happy.”

Get Involved

The first step is to create an account and dig around the support forums.

“It’s always scary when you’re trying to join a new community. You feel like you’re in high school all over again. You’re this itty bitty freshman, and everybody else is a great huge, hulking senior. They’re adults. They know what they’re doing. And you’re like, “There is no way I can ever be that cool.””

If you remember high school, four years go by, and all of a sudden you were the cool guy. You were the great person. Everybody looked up to you. You have to remember that you don’t start out being an expert. None of us did.

Just look around and see if there are discussions you could get involved in. If a discussion is more than a couple of months old, just leave it alone because the person who made the request has probably moved on.

If you want to do more than poke around the forums and you want to be really useful, go to the forums and click the “No Replies” link.

Be super-helpful by answering unanswered questions.

Some supporters just go to the last page of queries with no replies and work their way up.

Another way to be helpful is to flag posts as spam, or to alert a moderator when someone double-posts a lot. On the right side of the post, you’ll see a section called “Tags.” Just add the tag “ModLook” (all one word), and a moderator will know to look at it.

To get involved in the new training initiative, stop by the post “Training Group, Team Reps, and Growing the Team” in the support section.

Theme Review

The theme review team sets guidelines for the quality of themes hosted in WordPress’ Theme Directory. It reviews every submitted theme against those guidelines and, if it meets the standard, pushes it to the repository.

Chip Bennett talks about theme review. (Image: konsobe)

The representative of the theme review team is Chip Bennett, the developer behind the Oenology theme. I chatted with him recently about how the theme review process works:

1. A developer submits a theme on WordPress.org, using the “Theme Authors” link. The uploader runs the theme through a script, unpacks it and puts it through a bunch of tests. If it passes the tests, the theme is repacked and stored in a special subversion repository for themes. It then generates a ticket in the Theme Trac.
2. The ticket goes into a queue. The queue is prioritized based on whether the theme is currently approved, whether it has been reviewed before, and how long it has been in the queue.
3. A reviewer will take on the highest priority theme. They review the ticket, which includes a link to the ZIP file, or a link to a diff file if the theme has been previously submitted.
4. In reviewing the theme against the guidelines, the reviewer looks for the following things:
   • code quality,
   • theme files,
   • front-end tests,
   • theme unit test data.
5. If the theme passes the review criteria, then the ticket is closed and resolved as “Approved.”
6. If the theme doesn’t pass, the reviewer posts comments on the ticket, explaining the issues and what is required and perhaps making some recommendations.

The longest theme reviews take around two to three hours, the whole way through. If there are major issues, the review will be stopped early, and the reviewer will note the issues for the developer to address.

Currently, about 70 to 80 people can close tickets. Around 10 people have reviewed more than 50 or 100 tickets. This means that participation is wide but shallow. The goal is to not leave a ticket in the queue for longer than a few days. On average, 10 tickets are submitted per day.

Challenges

A major challenge for the theme review team is the sheer volume of submissions, making reviews take longer than they would like. There are also occasional challenges to the review guidelines, although that has lessened in the past two years.

“Hopefully people have seen the benefits that the improved theme review guidelines have brought to the directory and overall code themes, so we don’t get a whole lot of challenges on the theme review guidelines themselves.”

We constantly have to review them as WordPress changes. Each release cycle, we have to look at them, find out what needs to change and understand how the various changes to core will impact themes to make sure we incorporate those.

Get Involved

The first place to start is the Make WordPress Themes blog, which is becoming the hub of activity for the theme review team. You’ll find a link to the reviewers mailing list, where a lot of the communication happens.

If you’re just starting out, you won’t have trac privileges to close tickets, so you’ll need to request a ticket to be assigned to you. To do this, post a comment on the “Trac Ticket Request Queue” page with your trac user name, and then one of the admins will assign the next ticket to you. Once you’ve done a few, you’ll get review privileges and be able to do it on your own.

You may also want to get involved in discussions about guidelines:

“We always welcome more people to contribute by reviewing themes, submitting themes and taking part in the discussion. The more developers we have participating in discussion about the guidelines and the process, it can only make it better.”

Plugin Directory

The plugin directory team is a relatively small group that is responsible for WordPress’ Plugin Directory. Its current rep is Scott Rielly.

Scott Reilly helps to secure and monitor WordPress’ plugin directory. (Image: konsobe)

The team does the following:

• Processes all incoming plugin submissions. There could be more than 40 submissions in a day. Each plugin is reviewed for guideline violations and coding best practices. If there is a problem with the plugin and it isn’t malicious, the team works with the author to fix the issue.
• Deals with support requests sent to plugins@wordpress.org.
• Monitors and curates the plugin directory, including looking for guideline violations and security exploits.
• Monitors the security-exploit database and announcements for anything relating to plugins.

Challenges

The biggest challenge facing the team, says Scott, is not having enough time in the day.

“Given the volume of newly submitted plugins each day, the constant updates by plugin developers and the support emails, it’s a constant effort to stay on top of everything — particularly because we’ll all just volunteers to the team. But we’ve been working to remedy this with enhanced admin tools and, eventually, additional team members.”

Another challenge is that spammers always try to game the system. The plugin directory is a target for people who want to inject spam into the websites of WordPress users. “In many ways, it’s an arms race,” says Scott. “They keep trying new stuff, and we keep shutting them down once we become aware of it”

Get Involved

The first way to help out with the plugin directory is to check out plugins and evaluate code. If you find any guideline violations or malicious code, send an email plugins@wordpress.org. Include the name of the plugin and a link to its page, as well as a list of the issues. The team will get in touch with the plugin’s author and get the issues fixed.

The team isn’t currently set up to accept many new people in an official capacity, Scott says:

“Part of it is getting internal tools and documentation organized in order to facilitate a larger team, and part of it is that we need to be selective of candidates since full membership grants capabilities that require adequate vetting.”

But the team is on the lookout for new members. Recently, Pippin Williamson was brought on board. The team keeps an eye out for potential team members amongst WordPress contributors who have demonstrated their ability through “code, competence and trustworthiness.” If you want to be invited to join the plugin directory team, help out across the community, showing off your technical expertise. Anyone who wants to get involved with reviewing plugins will need a deep knowledge of WordPress, of PHP and its best practices and of the plugin guidelines. Security expertise and the ability to understand other developers’ code are also desired. “Not just to understand what it does and what it’s supposed to do, but also how it may be wayward or exploitable in its implementation.”

Documentation

Often, when people think about WordPress documentation, the first thing they think of is the Codex. While the Codex is the cornerstone of WordPress documentation, it’s one element of a wider drive towards improving documentation. I’m currently the acting rep for documentation, which means that I’m responsible for reporting back to the community on the week’s activities.

Me, telling people they should use fewer words. (Image: Michael Yoshitaka Erlewine)

As with getting involved in any aspect of WordPress, contributing to documentation will improve your WordPress skills, not to mention your technical writing skills. It’s also a great way to give back to the community. Currently, there are a few ways to get involved:

• Codex
  The Codex always needs updating to maintain it as a useful resource for users. There’s always a flurry of activity around a new WordPress release as the Codex is updated to reflect any changes. Anyone can edit the Codex; all you need is a WordPress.org account. Lorelle VanFossen has listed all of the tasks in the Codex that currently need completing.
• Handbooks
  The handbooks are a collection of guides that teach people how to contribute to WordPress. There will also be handbooks for theme development and plugin development. This project will be active over the coming year.

We are also discussing the possibility of conducting a review of the inline help tabs, and looking at other ways that we can generally be helpful with documentation.

Challenges

A major challenge for the documentation team is to keep everything updated. WordPress has a fast release cycle, so the docs team has to be quick to stay on top of updating the Codex. Another challenge is that the Codex itself is such a huge resource. Keeping abreast of what needs to be done can be hard. A lot of functions lack practical examples, which people would find very useful for learning.

Also, sometimes the problem is that people don’t realize they can edit the Codex — you can, and you definitely should!

Get Involved

The easiest way to help out with documentation is to go to the Codex and log in with your WordPress.org user name. Once you’re logged in, you’ll see an “Edit” link at the top of the right sidebar. Click that button and you’re editing the Codex!

Editing the Codex is easy — go try it!

Even fixing a typo improves the documentation. If you’re using the Codex and you see an issue, fix it. If you have had to go elsewhere to find a solution, add that solution to the Codex so that others will benefit from it.

You could also stop by the Make WordPress Documentation blog, where you can say hello and get involved with the docs team. There is currently a major push to get the handbooks together, but you’ll find other projects that you can get involved with on the blog. We also have a weekly chat with the support team. This takes place on Thursdays at 9:00 pm UTC in the freenode IRC channel #wordpress-sfd.

Events

WordCamps and meetups are events at which WordPress users can get together to share knowledge, learn and socialize. One of the current reps for the Events blog is Andrea Middleton. She works on the WordCamp program, reviewing applications and providing a point of contact for organizing teams. The events contributor group consists of people who have organized WordCamps and meetups.

Events organizers have to deal with a lot of people standing around, staring at stuff. (Image: konsobe)

Challenges

Organizing an event has many challenges — you’ve got to get good speakers who will engage the audience, find sponsors and a venue, sort out catering, arrange AV, manage a budget, organize a team of volunteers. You’ve got to get a lot of details right in order to organize a successful event. Once you’ve been through the baptism of fire, you’ll be an experienced event organizer, which is a great time to get involved with the events contributor group.

Get Involved

Having experience as an organizer of meetups or any volunteer-run event is a great asset if you want to get involved with the events group. Having good accounting and communication skills also helps. As Andrea says:

“I think anyone looking to get involved with an ongoing open-source project, from whatever area of contribution, should come bearing humility, tolerance, patience, respect and a healthy sense of humor. We’re a meritocracy, and we value civil discourse.”

If you want to organize a WordCamp but don’t have a local community, start with a meetup. These will get people out of their house and talking about WordPress. WordCamps are most successful in regions that have vibrant WordPress communities. WordCamps are great, but they are just once a year — meetups happen every month and, as Andrea points out, they “sometimes have a more persistent effect on people’s lives and how they interact with WordPress.”

To get involved with the events group, stop by the blog and say hi.

Accessibility

The accessibility group was created to support core developers with issues regarding accessibility. Its rep is currently Mel Pedley. I asked Mel about the motivation for creating the group:

“Because a11y [accessibility] isn’t a binary subject but one based on experience, best practice, judgement and balance, the core devs were being hit with conflicting opinions that just caused even more confusion. They needed one point of contact with regard to tackling a11y problems — hence, the group.”

The group comprises technical developers and assistive-technology users. The group looks at issues and figure out solutions, passing answers back to the core developers.

The team is in the process of expanding to cover themes and plugins, and one day it would like to cover everything that falls under WordPress.org.

Challenges

Mel identified three major challenges facing the accessibility group. First:

“Wrangling any group of a11y experts is always a challenge. Put four of them in a room and you’ll get five opinions. :-) It’s also quite slow, in my experience, to create real change. Things tend to change very slowly. So, keeping momentum is a major issue. I hope that we can address this by throwing a wider net — publishing best practice support documents and getting involved in outlying a11y projects — like Joseph O’Connor’s “Cites” project, which involves teams in cities across the world each developing an accessible theme.”

Secondly, the teams needs to get users with a greater range of assistive technology involved. There are screen reader users, but Mel is keen to get VR, braille and switch users involved, as well as dyslexics, so that there is a pan-disability user group. Successful accessibility is all about getting the right mix of people.

The third challenge is to convince the large community that accessibility doesn’t mean boring design or ugly UIs. You can have beautiful, graphically rich and accessible designs. Mel has been involved in Accessites.org to prove this point, and she wants to showcase what was learned there on WordPress.

Get Involved

To get involved, start following the Make WordPress Accessibility/ blog. You can also get in touch with Mel. The group is happy to hear from anyone interested in promoting accessibility and making WordPress more accessible.

There are two distinct streams for getting involved:

• Users
  This includes anyone who uses assistive technologies to access the Web. The group would value your feedback on existing issues and solutions.
• Technical
  This is any WordPress developer. You can translate users’ needs into practical solutions.

And a note to any WordPress developers:

“If you want to develop more accessible themes or plugins but aren’t sure where to start or how to tackle a particular problem, we’re here to help.”

Community

The community builders group was set up after the WordPress Community Summit to focus on outreach, mentorship programs and contributor engagement. The group’s current reps are Jane Wells and Andrea Rennick. Some of the things that the community group will be tackling are mentorship programs, college outreach, diversity, school programs, WordPress.org improvements, and finding new contributors at events.

Andrea likes hugging people. (Image: Andrea Rennick)

I asked Andrea what the group will be doing:

“Mostly it involves finding new members in the community who want to contribute and directing them to where they need to go. It also means answering a lot of questions. This requires a broad understanding of how each of the current groups works and what each group entails.”

Challenges

I asked Andrea about what challenges she thinks the group will face:

“At the minute, there’s no one spot where people can go to with their questions about getting involved with WordPress. Also, there are issues around dissemination, which really needs to be improved. The new Make WordPress.org Updates blog is an example of attempts to improve communication. Reps will post weekly updates so that everyone stays informed of what’s going on across the groups.”

But those aren’t the only challenges:

“Other sticky spots I can see being a challenge are things that are present in any large group of passionate people; things can be misinterpreted, feelings are hurt, tempers flare, and sometimes someone is needed to help smooth things over.”

Get Involved

Because the group is currently being formed, there are plenty of opportunities to get involved. People of any skill level are needed — even if your limit is installing WordPress and navigating the admin area, you still have enough skill to help others. Stop by the Make WordPress Community blog, leave your name in the comments, and say how you would like to help out.

BuddyPress and bbPress

BuddyPress and bbPress are the younger siblings of WordPress. If you get excited about social networking, communities and forums, they could be the places to get your feet wet. BuddyPress is “social networking in a box.” You can use it to build a community around WordPress. bbPress is a forum plugin for WordPress.

The lead developer of BuddyPress and bbPress is John James Jacoby (aka JJJ or J-Trip). JJJ manages the overall direction of the project, gets more contributors involved and helps out with development. The role he focuses on the most is building an active contributor community so that everyone can make the most of their unique skills and abilities.

JJJ leads the BuddyPress and bbPress projects. (Image: Andrea Rennick)

BuddyPress and bbPress are like microcosms of WordPress itself, with contributors needed in many of the same areas, just on a smaller scale. There are a lot of ways to get involved with the plugins: refactoring code, helping in the support forums, developing new features and functionality, working on user experience and design, helping with the codices, and writing plugins.

Challenges

The biggest challenge facing bbPress has been maintaining momentum. There isn’t always a lot of focus on it, and other distractions come up for developers. This is frustrating for JJJ because people assume that the project is dead when it is still active.

The biggest challenge with BuddyPress is that the code has changed so much since it was launched. Its direction has changed, and the code has been adapted. This means that a bunch of code is hanging around that they want to get rid of but can’t because doing so would break everyone’s installation.

“I like the house to be presentable when I have visitors come over. And when I know the house is not very clean, even though people might not really see it, we feel like we can do a better job with it. That might just be me. But for the project as a whole, because we have so much code, our release cycles are not as quick as we’d like them to be. We always have to fix a bunch of things, or we linger in beta for too long, or we don’t get to beta fast enough.”

Get Involved

The easiest way to get involved is to help out in the BuddyPress and bbPress support forums.

“Having someone’s experience of the forums be a rewarding, fun thing is the easiest way to be helpful. If you think you know anything, you probably know more than somebody else, and sharing that knowledge goes a long way for someone who’s looking for help.”

Help is also needed on both of the codices. As JJJ points out, this often feels like a thankless job because writing and formatting take so much time. But it’s a really useful place to get involved, especially because so few people are doing it.

If you’re interested in getting involved with development, join #buddypress-dev on Wednesdays at 19:00 UTC, or #bbpress on Wednesdays at 21:00 UTC. Contributors are always hanging around outside those hours.

What’s In It For You?

I asked all of my interviewees about what contributors get out of being involved in WordPress. There were commonalities across all of their responses: the joy of being part of a community, the thrill of creating something used by millions of people across the world, the rate at which you learn, and the pleasure of being involved in democratizing publishing. While the responses were varied, Mark Jaquith’s response sums them all up:

“I consider it part of my continuing education. I mean, tech is such a fast-moving industry that if you stand back and, say, just focus on the planning board and aren’t involved in the process and the technologies and the new skills, you’ll be left behind in a few months. It’s just part of the upkeep for me — that’s number one.”

Number two is because I enjoy it. I enjoy making things. I enjoy working on software that’s used by tens of millions of people. It’s a fairly powerful and rewarding feeling. And the other thing is that it raises your status inside the community, which is helpful, because it’s a very tight-knit community, and a lot of your business links are going to come from the community. A lot of your potential partners on ventures and projects are going to come from within the community. And by contributing and staying close to that tight knit group, you keep those connections alive.

Tips For Getting Involved

Now that you’re excited about contributing to WordPress, and you’ve found a contributor group that fits, here are some tips:

• Before diving in, do a bit or research and see how the group operates and what’s currently on the agenda. This will help you figure out where you fit in and whether your ideas have been discussed before. Reading though the P2s will usually suffice.
• Stop by the P2 for the group you’re interested in and say “Hi.”
• If you’re not sure what to get involved with, stop by the #wordpress-contribute IRC chatroom on freenode. Some people should be around to help you get started.
• Read through the P2, mailing lists or trac. Check that your ideas haven’t been proposed before, and if they have, see what the reasons were for refusing them.
• Go to WordCamps and Meetups! My involvement in WordPress has increased massively since I started meeting people in person.
• Reach out to people on Twitter or, if they publicize their address, via email.

Some Final Advice

A few pieces of advice didn’t fit neatly anywhere else in this article but are too valuable to be discarded. First of all, Matt has some words on starting out with contributing to WordPress:

“Remember that everyone who’s involved at WordPress started where the people who are reading this article are today, including myself. It looks big and scary. The first time someone said to me “You should patch that and put a diff on SourceForge,” I was like, “I don’t know what half the words in that sentence mean.” I had to figure out patches, I had to figure out what a diff is, I has to figure out what SourceForge is. We all started there. You’ve just got to dive in.”

And Mika has some words on the value of every WordPress contributor.

“Don’t ever feel that just because you don’t know how to code like Nacin and Otto that you’re not just as valuable as they are. Because without us, too, WordPress would fall apart. A healthy community is healthy on all levels, and everybody does know that.”

Contributor Information

Make WordPress Blogs

Here are the discussion blogs where the different groups carry on discussion and post updates:

• Master List
• Updates
  regular updates from the reps of every team
• Core
• Support
• Plugins
• Themes
  including Theme Review
• UI
• Mobile
• Polyglots
• Documentation
• Community
• Changes to WordPress.org

Chat Schedule

WordPress has a number of rooms on the freenode IRC channel. This is where the weekly chats take place. Remember that the chats are for getting things done, not just for saying hi, but they are a great time to find out how things work. People also usually hang out in the chat rooms throughout the day, which tends to be a better time to introduce yourself. Don’t be upset if people don’t respond — there are time-zone differences to take into account, and many WordPress people leave IRC on throughout the day, even if they’re not at their computer.

If you’re confused, the Codex has some information on IRC

• Tuesday: UI
  19:00 UTC in #wordpress-ui
• Wednesday: Mobile
  16:00 UTC in #wordpress-mobile
• Wednesday: BuddyPress
  19:00 UTC in #buddypress-dev
• Wednesday: bbPress
  20:00 UTC in #bbpress
• Wednesday: Core
  21:00 UTC in #wordpress-dev
• Thursday: Support and docs
  21:00 UTC in #wordpress-sfd

If you want help getting started, don’t forget that you can stop by #wordpress-contribute, where people are on hand to help.

(al) (il)

---

© Siobhan McKeown for Smashing Magazine, 2013.

Posted in Design | Add Comments »

Psst! Smashing Magazine Is Hiring! We’re Looking For A Senior Editor

Posted by Smashing Magazine Feed at 05-08-2013

Editorial work at Smashing Magazine is a difficult, challenging process. It requires patience, focus and thoroughness. Our readers have high expectations, and our authors expect sophisticated editorial guidance. That’s what we are known for, and that’s where we could use your help. We’re looking for a hard-working editor with technical experience to support and complement our team.

Such an editor can’t be found on any of the innumerable job boards out there. Because the position is one of the most important to our publication, we are looking for the best editor from our community — someone who truly understands Smashing Magazine and what it stands for. We would never otherwise publish a job opening on our front page — in this case, we made an exception.

Where? Freiburg, Germany.

We’d love to welcome you onto our team in Freiburg, Germany (Google map). In addition to enjoying the beauty of this student city, with its medieval city center, lovely vineyards and proximity to the Black Forest, you’ll also have France and the Swiss Alps just around the corner. Of course, you’ll also enjoy the playful spirit and open-mindedness of Smashing Magazine’s international team members, who like to work as hard as they party.

(Image: Björn Freiberg)

Your Responsibilities

We prefer that our team members focus on a few important tasks and do them well. Here are some of the tasks and responsibilities you will have:

• Continually acquire and communicate with authors, in accordance with our editorial process and publishing policy.
• Plan, edit, perform quality control on and publish articles on Smashing Magazine.
• Shape and contribute to the editorial direction of the magazine.
• Refine the content strategies for existing and future content.

What We’re Looking For

We are looking for professionals who know exactly what they’re doing. Here’s what we expect from you:

• A strong sense of craftsmanship in your work — whether in writing, editing, communication or simple HTML.
• Be curious to experiment and get creative with new forms of content and with design- and coding-related topics.
• Know and understand what it takes to make high-quality content for the Web.
• Be familiar with the Web design community and the industry in general.
• Be willing to challenge authors to leave their comfort zone, and make every article stand out from the crowd by being interesting, engaging, appealing — perhaps even extraordinary.
• Have excellent written and verbal communication skills in English. We’d love for you to have solid experience in copywriting as well, but that’s not necessary.
• Knowledge of Web design is necessary, both technical and non-technical, but we don’t expect you to be a ninja in all of it — a jack of all trades is just fine!

How to Apply

Interested? Fantastic! Please send your cover letter, résumé, work samples and URLs of relevant websites to me, Vitaly Friedman, at the following email address:

vitaly [at] smashingmagazine.com

We have a lot of exciting ideas for the magazine — we just need people who we would love to work with and who we can trust to make these ideas a reality. With your help, we can make this magazine even better and richer than it has ever been.

We look forward to your application.

(al)

---

© Vitaly Friedman for Smashing Magazine, 2013.

Posted in Design | Add Comments »

Free Texture Tuesday: Soapy Water

Posted by BittBox at 05-07-2013

Advertise here with BSA

Posted in Design | Add Comments »

The Smashing Editor’s Choice: A Free eBook

Posted by Smashing Magazine Feed at 05-07-2013

Nearly half a year ago, we introduced our eBook subscription model, also known as the Smashing Library. We knew we were onto something good, realizing that the Smashing Library was the next step in offering quality content — at a price you’ll still be able to afford all of the coffee you need to stay up long enough to read the entire library and, of course, the free eBooks.

A subscription to the Smashing Library is only $99 a year.

A subscription to the Smashing Library grants you unlimited access to all of the previously published Smashing eBooks, as well as a guaranteed 24 new eBooks throughout the year. This includes all digital versions of the Smashing Book series, including the The Mobile Book and the upcoming Smashing Book #4.

And our library is getting even more smashing. We didn’t want to limit the library to just our own content, so we are now including a growing number of industry-related eBooks. These books are by authors who aren’t necessarily affiliated with Smashing Magazine but who produce great content. In addition to saving more than half off the regular bundle prices, as a subscriber to the Smashing Library, you will get the opportunity to vote on what we publish next and what new eBook downloads will be automatically available in your Smashing Shop dashboard.

Download the “Smashing Library Catalog” (PDF, 2.8 MB) and get started today!

The Smashing Editor’s Choice

To give you a taste of what to expect from the eBooks in the Smashing Library, we are happy to present you with The Smashing Editor’s Choice: A Smashing Library Treat — a free eBook that contains a wide range of topics, including new coding techniques, user experience strategies, responsive design and mobile solutions by some incredibly prolific and knowledgeable authors. Well-known names such as Lea Verou, Christian Heilmann and Dmitry Fadeyev have contributed fascinating chapters on various subjects.

Sign up below to receive your free copy of The Smashing Editor’s Choice.

The Smashing Editor’s Choice eBook is only a sample of the kind of quality Smashing eBooks that are available in the library. We select only the best articles, wrap them in a user-friendly layout, and make them available in the three most common formats, PDF, EPUB and Kindle. And because we don’t want to impede your use of the eBooks, they’re all DRM-free.

If you like this eBook, then you’ll love the Smashing Library. Just fill in your email address below, and you will receive access to a download link to your free eBook copy of The Smashing Editor’s Choice, as well as our bi-weekly Smashing Newsletter, which is full of useful tricks, techniques and tweaks.

What Subscribers Think of the Smashing Library

Coming up with the subscription library model took meticulous planning and careful editorial work. Adding eBooks on a monthly basis and keeping up with industry trends take passion. Luckily, we have a lot of that. From the beginning, we had a feeling that the library would be popular, and with the surprisingly positive launch, you proved us right:

“A perfect resource for a full-service Web-dev company. I own and operate a Web development company. This provides a vast store of wisdom for daily operations across the board.”
– Taylor Black

“Unbelievable bargain! This is indeed a great offer if you’re thinking about purchasing several books and if you want to keep up with current developments. Very curious about what’s yet to come this year!”
– Joachim

“The best magazine is up with the best books. I recently received “The Mobile Book.” That was awesome, and I hope this will be 38X awesome. Worth reading!”
– Erik Royall

“Great books, nice offer! I already own Smashing Book #3 and was thinking about buying the mobile/coding bundle when I stumbled upon this offer. Been reading (almost) nonstop ever since, loving it so far! Thanks, Smashing!”
– Bernd

We try to make the Smashing Library worthwhile by adding new content regularly and by giving you, the subscriber, the choice of what we publish next. All downloads, eBook polls and news are accessible through your personal Smashing Shop dashboard. Have a look at what the library looks like when you’re logged in:

A preview of the Smashing Shop dashboard.

Thank you all for your support over the years, everyone! You’ve been truly smashing!

(al) (il)

---

© The Smashing Team for Smashing Magazine, 2013.

Posted in Design | Add Comments »

Whiteboards, Visions And Banned Words: How To Help A Real-Life Knight Achieve His Goals

Posted by Smashing Magazine Feed at 05-07-2013

This article is about design consultancy. It’s about wrangling that client who uses empty sentences like, “We want a snappy, simple experience,” or, “It should be on brand and should really pop.” It’s about commanding the room and setting a vision before moving on to wireframes and pixels.

While I’ll talk in terms of consultation, these ideas can be applied to the design phase of any new project.

Banned Words

I start every consultation with this list on the whiteboard:

• Clean
• Simple
• Fast
• Snappy
• Some
• Most
• Nice

These words are banned. If anyone in the room says any of these words, it means we’ve lost our focus or forgotten that we’re in the room to solve problems. We stop, reframe the conversation, then move on.

Any whiteboard is a weapon if you hold it right.

Here are three steps I take to ensure that the words above are never uttered in the first place.

1. Set A Vision

The design process can get derailed right at the start by focusing on questions like, “What’s the best thing about our product?” or, “What differentiates our service from the competition?”

Why This Is a Bad Idea

• Real users have families, jobs and tax bills and are quite possibly drunk when they first experience your brand. Put bluntly, people don’t care about your product — yet.
• Real people experience your idea on their terms, not yours.
• Dumb mass marketing doesn’t work anymore; we’ve raised a generation of marketing-proofed humans. (Thanks, Coke.)

Instead, let your audience define the project by explaining their needs to a friend, remembering that your brand is not what you say it is. Your brand is what people tell their friends it is.

“As a ____, I need to ____, so that I can ____.”

Let’s assume we’re selling ACME Dragon-Slayer Swords. Our audience might say:

“As a white knight, I need to slay the dragon, so that I can save the princess.”

Your brand is not what you say it is, but what your audience says it is.

This is useful because it describes our audience’s impetus and why it’s important to them. However, our user is not yet textured, nor specific enough. We can do better.

2. Narrow It Down

Let’s start with some experiential texture:

“As an inexperienced knight, I need to slay my first dragon so that I can prove my worth to the father of the princess.”

Better. We’ve textured our knight, with corresponding depth to his reasoning. Experiment with different textures — such as technical nouns, age, income and geography.

It’s easy to get lost in our idea and forget how it applies to the larger stage, so let’s delve further in time, before and after our idea:

“As an inexperienced knight on my first quest, I need to impress the king, so that I might marry his daughter and live happily ever after.”

In doing this, we’re taking our user from his real-world impetus, through our brand and back into real life again. We’ve realized that the dragon-slaying itself wouldn’t actually help a real knight achieve their goals. Might we consider selling ACME Dragon-Slayer Swords by how impressive they are to kings?

Describe the brand from multiple viewpoints. For example, our princess may find dragon-slaying presumptuous. If we discover that she’s a more interesting audience, then put her center stage instead.

Dragon-slaying princesses are DIY champions.

3. Stick To Your Vision

Once a scope is defined, remaining within its constraints is important. Thinking back to our banned words, let’s look at the scope-destroyers:

• Some
• Most
• Nice

The sentence, “It would be nice if some users could X” is almost as dangerous as, “Most of the time our users will Y.” This kind of thinking frays the edges of a good idea until it’s unrecognizable.

That way madness lies. Remove all but undebatable assumptions:

• Narrow down “some users” until you can say “every user.”
• If the client says “most times,” remove fuzzy options until they can say “all of the time.”
• Don’t waste time on “it would be nice” issues if you can fix a “we absolutely must” problem.

For example, earlier we defined our knight as inexperienced.

If anyone starts talking about experienced knights, we’d ask them to rephrase in terms of our defined audience. If we get sidetracked by knights who don’t want to impress kings, we’d jot that down on a “nice to have” list and forget about it entirely.

In The Real World

Here are some practical examples from real-world projects that I’ve led:

• Clarity.io
  “As a young adult, I want to donate to charity with my Facebook account so that I can share my charitable identity with friends.”
• The Fitzroy Academy of Getting Shit Done
  “I’ve lost faith in university education. I want an intense, condensed way to skill up and be industry-ready so that I can get out into the workforce soon.”
• OurSay
  “Australian citizens need direct access to people in power so that they can have an impact on their political system.”
• The Promo Bay
  “The Pirate Bay needs a way to centralize and sift through artists so that it can decide who to promote on the home page of The Pirate Bay.”

While we’re thinking “real world,” let’s look at the consultation session itself.

Sleight of Hand

When performing, stage magicians use props and well-practiced patter to better engage the audience. As a consultant, the magic lies in your command of design, while some nuanced expression can transform a banal experience into an engaging one.

One tablet makes you bigger, one tablet makes you smaller.

Practically Speaking

• Keep the vision written at the top of the whiteboard at all times. If anyone gets sidetracked, point at it meaningfully until they quiet down.
• If you feel you personally don’t have the authority to command the room, explain the consultative process up front. People sometimes prefer to trust a well-explained process, especially if they’re older or smarter than you.
• If a client uses terms like “drop-down” or “radio button,” ask them to rephrase without using those words. It’s also a good excuse to assert that the consultation is not about pixels and wireframes.
• Build a personal library of real-world metaphors that explain UX situations. For example, a website that logs you back in without asking is a lot like an automatic door. An HTML prototype is like a car without the engine. Physical examples ground people in reality.
• Your whiteboard marker is a conductor’s baton. This lizard-brain reaction harkens back to teachers in grade school. Note on the board something that a person says that you agree with, and people will suddenly speak on your terms just so you write down what they say.
• Once a vision is established, ask every person in the room whether they agree with it. Put a big tick next to it for each person, in turn. It’s now set in stone, and you can use it as the “bad guy” to settle disputes later.
• Pacing is one of the most important parts of consultation. Set time limits, and don’t be afraid to say, “OK, back to the process.” Consider having a clock in the room.
• Use a banned word, then catch yourself and apologize profusely. It proves you are beholden to the same rules as the client.

Always remember to keep your audience’s impetus in mind.

Further Reading And Experience

I’ve straddled the shoulders of two giants in writing this.

Reading

• The “As a ____, I need to ____, so that I can ____” technique is a simplification of a behaviour-driven development tool. See Bryan Helmkamp’s practical example over on SlideShare.
• I highly recommend watching the “Feedback Without Frustration” video and accompanying article, “How to Run a Design Critique,” by Scott Berkun.
• It may be old school, but a solid understanding of “Cognitive Walkthroughs” in Task-Centered User Interface Design is a good reference point for sticking to a vision.
• The “your brand is what your users tell their friends” idea comes from brand tribalism, another ’90s idea recently popularized by Seth Godin. See his TED talk on the subject.

Experience

You needn’t score a top-dollar client to learn how to deliver solid consultation services. We use these same techniques at work for all of our internal projects.

Try starting your next design sans-Photoshop. Instead, run a two-hour consultation with a coworker. Try again later with a really annoying person who hates your designs. Mixed experiences will help you find your own method in the madness.

Charm is a learned skill.

In Conclusion, re. Applicability

This style of consultation isn’t so great for fixing large broken systems. It’s better for new projects, with a small audience. It also works for small, distinct portions of a larger problem.

Extending the vision should happen after launch and testing, once you’ve won everyone’s heart.

Or:

“As the design lead of a new project, I need some consultative tricks to keep my clients in line and to craft a concise vision.”

(al) (ea)

---

© Will Dayble for Smashing Magazine, 2013.

Posted in Design | Add Comments »

M2: Free May 2013 Calendar Wallpaper

Posted by Fudgegraphics | for lovers at 05-06-2013

This post is part of the free calendar wallpaper series. Each month I create a new wallpaper featuring the current calendar. Looking at the same image over and over again is not very stimulating. Hence having a new desktop background each month should help getting your creative juices flowing.

The May 2013 Calendar Wallpaper, entitled M2, is minimal geometric design using fresh, summery colours. As the name suggests, this is a stylised form of the letter M (for May). The typography infused with vibrant colours, subtle textures and block shapes should get you in the mood for the upcoming hot summer days. Let’s hope that there will be plenty of days like that in May.

Download the May 2013 Desktop Wallpaper

The following resolutions are available. Simply right-click on the link and choose ‘save target as’.

• 2880×1800 (Retina Display) (non-calendar)
• 2560×1440 (non-calendar)
• 1920×1200 (suitable for 1440 x 900) (non-calendar)
• 1600×1200 (non-calendar)
• 1280×1024 (non-calendar)

iPhone Wallpaper

iPad Wallpaper

Posted in Design | Add Comments »

New Defaults In Web Design: How Much Has The Web Really Changed?

Posted by Smashing Magazine Feed at 05-06-2013

Responsive design is about more than just layout; it’s about designing for the Web, which means, mostly, for people with browsers. And that’s just about everything we know about the people who visit our websites: they are probably using a browser. All the rest we just don’t know.

Up until not so long ago, we used to base our designs on some rather general assumptions about screen size and input type. With the rise of devices with various screen sizes and alternative ways to interact, these assumptions have turned out to be unreliable. We need to upgrade the defaults that we use when we start designing our websites.

A Closer Look

People keep saying that the Web has changed. But has it really? Let’s take a look at all of the things that have actually changed.

Screen Sizes

In the 1990s, the Web was 640 pixels wide. In the early 2000s, it grew to 800 pixels. A few years later, we decided it should be 1024 pixels. But five years ago, all of a sudden, something strange happened. A device with a very small screen entered the market. Suddenly, our ideas about the size of the Web did not work anymore. Later on, tablets entered the market. People hold these things however they want. Today, the height of the viewport could be bigger than the width! But is that new? Not really.

Screen sizes, shown in a non-flexible medium. (Photo and work: Aram Bartholl)

We never really knew what size the window of our visitors would be. We just assumed it was at least the random pixel width that we felt comfortable with. These numbers were always arbitrary, and there were always people who could not see the entire website. We simply ignored them.

“Everyone Has a Mouse”

We’ve always assumed that everyone uses a mouse. Even though we knew that this was not always true, most designs completely ignored alternative ways of interacting. People who had to use a keyboard, for whatever reason, had a very hard time interacting with our websites.

But because most people did use a mouse, and because back then many designers thought that designing only for the majority was OK, we created websites that were unusable for a lot of people. And this turned out to be a growing number. Many mouseover interactions are completely dysfunctional on a touch device. Because people love these devices, and even managers and designers use them, they are harder to ignore.

“Everyone Has Broadband Internet”

Another thing we always assumed was that everyone had a super-fast Internet connection, at least as fast as our own. And if they didn’t already have it, they’d have it soon. This was again mostly true; speeds were increasing. But today, more and more people use crappy, unreliable 3G connections all the time. If you’ve ever travelled on a train in The Netherlands, you know what I mean. And if you’ve ever had to rely on the mythical “free hotel Wi-Fi,” then you know for sure that the assumption about the ever-increasing speed of our Internet connections is just not true. This is a big change in our thinking; we really should consider these users. This will have a major impact on what our designs look like.

“Everyone’s Computer Gets Faster Every Year”

It used to be true that computers would get faster and faster. If you waited half a year before buying a computer, you would get one that was twice as fast, for the same price. This was true of new desktop computers, but mobile devices have priorities other than processor speed. The most important thing for a phone, for instance, is battery life: you really don’t want to have to charge it after every phone call.

And there’s another trend: instead of creating ever-faster devices, many manufacturers are starting to sell ever-cheaper devices. Many people care about price and battery life more than about processor speed. This is also not new: what happened to your old computers? You probably sold them or gave them away. People keep using old stuff. Not everyone has the same hardware as we designers do.

“All Monitors Are Calibrated”

Well, we always knew this to be untrue, right? Only the monitors of visual professionals are calibrated. Most other monitors don’t display colors accurately, and many monitors are downright crappy. Most mobile phones that I’ve tested have pretty decent screens, until you start using them outside, in the sunshine. If you’re lucky, you can read the content, but you definitely cannot see the subtle gradients in low-contrast designs.

I haven’t even mentioned “modern” black and white screens. These, too, are not new. People have always used crappy monitors, and people with bad eyesight have always visited your websites. It’s just that more and more people are seeing a subpar color palette. Instead of buying a state of the art monitor, buying a cheap monitor and several low-end devices to test your work on might be a better investment.

All of these things are not new. In 2002, John Allsopp wrote the monumental article “A Dao of Web Design.” People such as Jeremy Keith and Roger Johansson have written about all of these facts for years and years. And yet, somehow, we’ve always managed to actively ignore them. But we really can’t anymore. The Web actually did change in the last five years, with new devices, new browsers and many, many cool new features. We need new defaults. The old ways of creating websites just don’t work anymore.

This Is Responsive, the excellent resource about responsive design by Brad Frost.

In the past few years, we’ve been actively researching new ways to deal with all of these different screen sizes. But apart from responsive design, there are many more challenges in today’s ever-growing pile of devices. We have to find new patterns of interaction: we need interfaces that work on any device. Maybe we have to reconsider that enormous photo carousel on the home page, now that we know that not everyone has a cheap and fast connection. New defaults are emerging, and I’ve collected a few for you here.

The things in this article are not new. Many clever people have written about them in many articles and many books. But these ideas, like all good stories, have to be repeated many times so that people understand and remember them.

New Default: Activate

I initially titled this section “New Default: Touch.” But I came to realize that “touch” has a different meaning for everyone. Some people, like me, think of a single tap when we hear the word. Others think about swiping and complex gestures. That’s why I settled on the heading “New Defaults: Activate.” All devices, no matter what kind of input they offer, let the user activate something in some way.

With a mouse, it’s a click; with a touch device, it’s a tap; on a keyboard, it’s the “Enter” key. There are ways to activate things by voice, and by waving your arms in the air. And many devices offer more than one way to interact. The only thing that all of these devices have in common is the action of activating. Most of them are capable of doing many other things, too, but all of them can activate stuff.

Only recently have we really started thinking about alternative methods of user input. We used to assume that everyone uses a mouse. Hiding content and showing it on mouseover was considered to be a decent design pattern. And it used to work for most people — until all of these wonderful touch devices entered the market. What should a device without a mouse do when content can be revealed only with a mouse? Different devices have different solutions. Let’s look at a simple drop-down menu.

See a live example of this navigation pattern.

When you hover over a menu item, a submenu appears. But apart from hovering over an item, you can also simply click on it to follow the link. Now, what should happen when you tap on the item with a touch device? Should the submenus appear, or should the link activate? Or both? Or should something else happen? On iOS, something else happens. The first time you tap a link like that, the submenu appears; in other words, the hover event fires. You have to tap a second time to actually follow the link. This is confusing, and not many people will tap a second time. On Android, the submenu appears and the link is followed simultaneously. I don’t have to explain to you that this is confusing.

It’s very well possible to think of complex solutions whereby you define different interactions for different input devices. But the better solution, I think, is to make sure that the default interaction, the activate event, just works for everybody. If you really need to, you could choose to enhance this default experience for certain users.

For instance, if you are certain that someone is using a mouse, you could enable some mouseover interactions. Or if you’re sure that someone has fat fingers, you could make small buttons a bit bigger. But only do so in addition to the default activate interaction, and only if there’s no doubt about it, and only if the enhancement would really make things better. Those are quite a few ifs, and some of them, such as the mouse usage, are very hard to detect — especially on devices that offer more than one way to interact, such as a laptop with an optional mouse, touch pad, camera, microphone, keyboard and touchscreen. Give it some serious thought. Do you really need to optimize for a mouse?

New Default: Small Screens

Growing is easy. Most things grow. Babies grow, trees grow, curious minds grow. They don’t grow by themselves, but you don’t need much energy to make things bigger. This is just what things do when they live. While shrinking things is definitely possible, it’s also much harder. You could, for instance, compress a car to a fraction of its original size. A compressed car does have a certain aesthetic appeal to it, but it is definitely not as useful as it was before. The same goes for websites. Shrinking a desktop website does not always result in a pleasant experience on a small screen.

Cedro di Versailles by Italian artist Giuseppe Penone clearly shows that things grow. On the other hand, the work Papalote Goliad by American artist John Chamberlain shows that shrinking can be aesthetically appealing but may result in less useful results.

To build a responsive website that works on all kinds of screens, designing for a small screen first is easiest. It forces you to focus on what’s really important: if it doesn’t fit in this small square, it is probably not terribly important. It forces you to think better about hierarchy, about the right order of components on the page.

The same principle that we follow for interactions — whereby we design the activate event first and enhance it later — applies to graphic design. We should start designing the things that we know everyone will see. That’s the content. No matter how big or small a screen is and no matter how minimal the feature set of a browser, it will be able to show letters. Because this is about the only thing we know for certain — since color is absent on most Kindles, most of the latest CSS doesn’t work on old browsers, and layout is of minor importance on small screens — starting with the text is logical.

I wrote an in-depth article about defining breakpoints on the basis of typography, so I won’t repeat every detail here. But the basic idea is that you start by designing the relationship between the different font sizes. Almost everyone, no matter what device they have, will be able to see this. When the typography is done, you would start designing the layout for bigger screens; you can think of this as an enhancement for people with bigger screens. And after that, when the different layouts are done, you could add the paint. And by paint, I mean color, gradients, borders, etc.

I’ve presented this as a very strict way of working; in real life, of course, things are not as rigid. I’m not talking about “activate only” or “small screen only.” When I say to start with typography, I don’t mean that you aren’t allowed to think about paint at the same time. Rather, I’m trying to find the things that all of these different devices, with all of their different screen sizes and all of their different features, have in common. It just seems logical to first design this shared core thoroughly. The strange thing is that this core is often overlooked: Web professionals tend to view their own creations with top-of-the-line devices with up-to-date browsers. They see only the enhancements. The shared core with the basic experience is often invisible.

New Default: Content

The way we designed our websites until recently was by putting a header with the logo and navigation at the top, putting the subnavigation on the left, putting some widgets on the right, and putting the footer at the bottom. When all of that was done, we’d cram the content into the little space that was left in the middle. All of the things we created first — the navigation, the widgets, the footer — they all helped the visitor to leave the page. But the visitor probably wanted to be there! That was weird. It was as if we were not so confident in our own content and tried our best to come up with something else that our guests might like.

But rather than pollute the page with all kinds of links to get people out of there, we should really focus on that thing in the middle. Make sure it works. Make sure it looks good. Make sure it’s readable. Make sure people will understand it and find it useful. Perhaps even delight them with it!

Once you’re done with the content, you can start to ask yourself whether this content needs a header. Or a logo. Or subnavigation. Does it need navigation at all? And does it really need all of those widgets? The answer to that last question is “No.” I’ve never understood what those widgets are for. I have never seen a useful widget. I have never seen a widget that’s better than white space.

Compare a typical news website’s attention to widgets with Medium’s complete focus on content.

By starting with the content first, you can come up with some very interesting solutions. For instance, does the logo really need to be at the top of every page? It could very well go in the footer on many websites; such as in digital style guides or on pages for registered users. Many links that we used to put in the subnavigation might work better in relevant spots in the main content.

For instance, the option to add extra luggage to a flight booking might be most effective right there in the overview of the flight, instead of in the middle of a list of links somewhere on the left of the page. And when looking at the hierarchy of a page, does the main navigation look more important than the main content? Most of the time it shouldn’t be, and I usually consider the navigation to be footer content. A simple “skip” link at the top of the page could either take the visitor to the navigation or fetch the navigation and show it at the top of the page.

In this era of responsive Web design, we need many new clever solutions. As we’ve seen here, our old defaults don’t work anymore. We need to reconsider how we work with interaction, how we approach design and how we shape our content. But we need to think about one other very important thing, and that is where our content comes from.

New Default: The API

Luke Wroblewski wrote a fantastic article about designing an application for the command line first, and then enhancing it for different needs. This is not just a nerdy idea, but a very practical idea, too. If you are able to design and develop your own application, you could test the functionality relatively easily before even starting to think about what it will look like on different devices. This requires designers to work with developers to design a feature that at first works only from the command line. If the feature does not work as expected, then you merely have to change the API, rather than also a bunch of visual designs. Once the API works as you want it to, enhancing it for all of the devices and screen sizes that you want to support becomes easier.

Most of the time, you wouldn’t design the entire API of the application that you’re building. Most companies would choose a content management system (CMS) of sorts or a specialized tool to help them achieve what they want to do. I’ve always been amazed that CMSes are so often chosen only by technical people and business people. This causes many problems during the design process.

Developers and business people have different goals than designers. Developers want stuff that is easy to develop on. Business people want stuff that’s cheap. But designers want to make the best and most beautiful things possible. These goals can easily conflict.

I’m not saying that designers alone should choose the system, but they should definitely be a part of the decision-making process. I’m convinced that the selection of CMSes will improve. And I’m convinced that CMS makers will start to improve their products once designers get involved. Right now, all CMSes I know of deliver hostile cruft unless you tweak them extensively.

But it works the other way around, too. If designers are involved in the selection process, they will have a say in the choice of tool and will understand how it works, what’s possible, what’s easy and what’s hard. This will result in designs that are based in part on the tool, not just on imagination. This is an important part of the design process that has not yet been optimized. Right now, the command line and the systems that deliver the content we design for are the domain of the developers, and designers have nothing to do with them. That is a pity. Just as you would want to take advantage of the knowledge of developers in the design process, you would want to take advantage of the knowledge of designers in the development process.

Progressive Enhancement

If you review the sections above, you’ll see that what I’ve described is nothing other than progressive enhancement. You start with the content, then design the content and optimize it for different screen sizes and devices, and after that you can further optimize for very specific features such as mouse usage and fat fingers. Many Web developers build websites according to this principle. They transform the beautiful Photoshop documents that they receive into all of the different layers described above.

This can work out fine if the developer has a good sense of design and a delicate attention to detail. But if they don’t — which is often the case — this can easily result in crappy usability and ugly details. I’m not saying that designers shouldn’t use Photoshop anymore. If that’s your tool, go ahead and use it. But do remember that you’re designing the layers of the Web, not the layers in Photoshop. There’s much more to the Web than a single beautiful image. People will see our creations in innumerable ways. We design for all of these people — remember that. We don’t just design for the CEO with a laptop. We also design for the people on the train and the people with “free hotel Wi-Fi.”

Tools

I’ve mentioned Photoshop a few times because it’s still widely misused for designing websites. One reason we have a hard time with progressive enhancement in the design process is due to a lack of good Web design tools. The tools we use are built to wow; they mostly help you to create the “paint,” not to design the core. Fortunately, more tools are popping up with very specific functions in the design process. These are micro-tools such as the International Measure Slider, which helps you to define breakpoints in your grid; tools such as Gridset, which helps you to create grids for different screen sizes; and excellent tools that help you to define typography. By incorporating these tools into our design workflow, we might start making better stuff.

Conclusion

The Web has always been a weird, borderless, flexible medium. In the last couple of years, we’ve started to realize that designing for this medium is fundamentally different from the design work we’ve done previously. The fixed dimensions and the singular ways of interacting that formed the basis of all types of media that we’ve worked with for centuries just don’t work on the Web. This truly is a unique medium.

We have to find new defaults, new starting points for our design process. I’ve explained some of these new defaults here, but of course there are many more. The way we work with forms, for instance, could probably use a whole series of articles by itself. Some new starting points are well established by now, but I’m sure many more will be invented in the near future. I am curious to hear about new patterns and new defaults that you have discovered and have used successfully in your projects.

(al)

---

© Vasilis van Gemert for Smashing Magazine, 2013.

Posted in Design | Add Comments »

Freebie Friday: 5 Fractal Shard Brushes

Posted by BittBox at 05-03-2013

Advertise here with BSA

Download. ZIP

Posted in Design | Add Comments »