I’ve been working on some video tests with the iPhone and I needed to mount it on tripod for some steadier shots. Some folks in the office had good things to say about the Glif from Studio Neat, but the only one we had lying around didn’t fit my phone and sat kinda goofy on our tripod plate. So, I did something I wouldn’t have imagined possible a few years ago. I printed a new one.

We got a 3D printer in the office a few months ago. So far it’s been used to make little statues, paperclips, even some chain mail. So I went about designing a new baseplate for our tripod.

The phone cradle came from an existing design on the wonderful Thingiverse. The base plate itself was just measured from our tripod plate and the whole thing was created with Google SketchUp.

It took a bit of tweaking to get the sizes right and there were a few failed prints where the machine decided to spray plastic filament all over. The final plate, however, is a dream; The phone fits snuggly and the plate stays in the tripod at any angle. You can turn the tripod upside-down and the phone stays secure.

So, if you’re looking for an iPhone 5 mount for a Davis & Sanford FM18 head, go ahead and print one out! You can download the Creative Commons licensed model here.

close article | permalink

For iOS development, I don’t use Interface Builder. I haven’t willfully used a NIB (when I say NIB, I mean Interface Builder file, not the specific format) since iOS 2.0. In the past, I’ve worked with a few folks that really liked using Interface Builder. This is an argument I’ve had over and over.

Instead of mindlessly arguing on one side or the other of this, here’s my “go-to” points when I’m trying to win someone over.

Choosing Explicit over Implicit

Choosing to be explicit is my number one reason to do things in code instead. If someone new to the team opens up a view or view controller, they can see right away where everything is and not have to wonder if this file has a NIB.

I have spent countless hours searching for the source of a bug only to discover it’s some checkbox in one of the half dozen inspectors in Interface Builder. If it was in code, it’s simple to glance at the view code and see the source of the problem much quicker.

Tight Coupling

It is much harder to use Interface Builder for reusable views. I constantly create little views and reuse them all over the place. That’s kind of the point of working in an object-oriented environment. If you use Interface Builder and have outlets and forget to connect the outlet in the second place you use it, you crash at runtime. This is terrible. This introduces a whole new class of bugs.

Now we have this thing that crashes simply because we’re using Interface Builder instead of using code. If it was the exact same thing in code, it wouldn’t crash. Even worse, the compiler can check this for you.

Not to mention, if you use lots of custom views, your NIBs will just be a bunch of invisible boxes. So now you have this tight coupling that is even harder to work with if you were to just lay it out in code.

Have you ever sat staring at some code wondering why it’s not working, only to realize you didn’t connect the outlet or action? I hate that.

Working With Others

Have you ever had a merge conflict in a NIB. It’s the worst. (Granted the XIB format has helped, but it’s just awful instead of impossible now.) If you’re working in a large application with several developers, you will waste an enormous amount of time dealing with this issue.

The worst part is if it gets automatically merged wrong, you might not notice until runtime. With code, you can read the diff and understand what’s happening. NIBs (in either format) are not human readable. This also makes looking at the history of a file useless. If it was code, it’s just Objective-C. We’re good at that.

It’s Part of Xcode

This used to be more of an issue, but I think it’s still worth mentioning. To put it lightly, Xcode is not the most stable piece of software in the world. The text editing part works pretty well. Every time I get a crash while editing a NIB, I grumble to myself and wish it was code even more.

The less I have to use Xcode for more than anything except a text editor with completion and a compiler, the happier I am.

Location, Location, Location

Layout code is not hard. Auto-layout is a bit more code than traditional layout, but it’s still not bad. Trying to work with auto-layout in Interface Builder is maddening. Setting outlets to control built-in constraints is just silliness.

It’s so simple to just override layoutSubviews and do your thing. Personally, I find this much easier to work with than auto-layout for most things.

I think this is a lot of people’s biggest fear is working with layouts in code. Once you get the hang of it, it’s so simple. Making your app universal becomes much more trivial than making separate NIBs for iPhone and iPad. You can simply reuse your code instead of create this tight coupling.

Bottom Line

Interface Builder itself is not bad. It does encourage bad practices, prevents reusability (making working with others more difficult), and slows your workflow. Personally, I avoid using Interface Builder (including storyboards) as much as possible. All of the projects I’ve worked on since 2009 haven’t had NIBs unless it was out of my control.

I think you should save yourself some time, learn a few things, and start moving to code. We are programmers after all.

The post Why I Don’t Use Interface Builder appeared first on Treehouse Blog.

close article | permalink

close article | permalink

Typekit is the easiest way to use real fonts on the web. Add a line of code to your pages and choose from hundreds of web fonts. Simple, bulletproof, standards compliant, accessible, and totally legal. Learn more at http://typekit.com

close article | permalink

I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? Right?

Nope, none! They’re great in theory but turns out they fail in practice, so we’re joining Mozilla and the W3C CSS WG and moving away them. There’s a few parts to this.

Firstly, we won’t be migrating the existing -webkit- prefixed properties to a -chrome- or -blink- prefix, that’d just make extra work for everyone. Secondly, we inherited some existing properties that are prefixed. Some, like -webkit-transform, are standards track and we work with the CSS WG to move ahead those standards while we fix any remaining issues in our implementation and we’ll unprefix them when they’re ready. Others, like -webkit-box-reflect are not standards track and we’ll bring them to standards bodies or responsibly deprecate these on a case-by-case basis. Lastly, we’re not introducing any new CSS properties behind a prefix.

Pinky swear?

Totes. New stuff will be available to experiment with behind a flag you can turn on in about:flags called “Experimental Web Platform Features”. When the feature is ready, it’ll graduate to Canary, and then follow its ~12 week path down through Dev Channel, Beta to all users at Stable.

The Blink prefix policy is documented and, in fact, WebKit just nailed down their prefix policy going forward. If you’re really into prefix drama (and who isn’t!) Chris Wilson and I discussed this a lot more on the Web Ahead podcast [37:20].

How long before we can try Blink out in Chrome?

Blink’s been in Chrome Canary as of the day we announced it. The codebase was 99.9% the same when Blink launched, so no need to rush out and check everything. All your sites should be pretty much the same.

Chrome 27 has the Blink engine, and that’s available on the beta channel for Win, Mac, Linux, ChromeOS and Android. (See the full beta/stable/dev/canary view).

While the internals are apt to be fairly different, will there be any radical changes to the rendering side of things in the near future?

Nothing too alarming, layout and CSS stuff is all staying the same. Grid layout is still in development, though, and our Windows text rendering has been getting a new backend that we can hook up soon, greatly boosting the quality of webfont rendering there.

We’re also interested in better taking advantage of multiple cores on machines, so the more we can move painting, layout (aka reflow), and style recalculation to a separate thread, but the faster everyone’s sites will render. We’re already doing multi-threaded painting on ChromeOS and Android, and looking into doing it on Mac & Windows. If you’re interested in these experimental efforts or watching new feature proposals, take a look at the blink-dev mailing list. A recent proposed experiment is called Oilpan, where we’ll look into the advantages of moving the implementation of Chrome’s DOM into JavaScript.

Will features added to Blink be contributed back to the WebKit project? Short term; long term?

Since Blink launched there’s been a few patches that have been landed in both Blink and WebKit, though this is expected to decline in the long-term, as the code bases will diverge.

When are we likely to start seeing Blink-powered versions of Chrome on Android? Is it even possible on iOS, or is iOS Chrome still stuck with a Safari webview due to Apple’s policies?

Blink is now in the Chrome Beta for Android. Chrome for iOS, due to platform limitations, is based on the WebKit-based WebView that’s provided by iOS.

Part of this move seems to be giving Google the freedom to remove old or disused features that have been collecting dust in WebKit for ages. There must be a few things high on that list—what are some of those things, and how can we be certain their removal won’t lead to the occasional broken website?

A few old ’n crusty things that we’re looking at removing: the isindex attribute, RangeException, and XMLHttpRequestException. Old things that have little use in the wild and just haven’t gotten a spring cleaning from the web platform for ages.

Now, we don’t want to break the web, and that’s something that web browser engineers have always been kept very aware of. We carefully gauge real-world usage of things like CSS and DOM features before deprecating anything. At Google we have a copy of the web that we run queries against, so we have a pretty OK idea of what CSS and JavaScript out there is using.

Blink also has over 32,000 tests in its test suite, and manual confirmation that over 100 sites work great before every release ships. And we’re working closely with the W3C and Adobe to share tests and testing infrastructure across browsers, with the goals of reducing maintenance burden, improving interoperability, and increasing test coverage. Eventually we’d like all new features to ship with shared conformance tests, ensuring interoperability even as we add cutting-edge stuff.

Still, any deprecation has to be done responsibly. There’s now a draft Blink process for deprecating features which includes:

• Anonymous metrics to understand how much any specific feature is used “in the wildâ€�
• â€�Intent to deprecateâ€� emails that hit blink-dev months before anything is removed
• Warnings that you’ll find in your DevTools console if you’re using anything deprecated
• Mentions on the Chromium blog like this Chrome 27 wrap-up.

Did part of the decision to branch away from WebKit involve resistance to adding a Dart VM? WebKit’s goals explicitly mention JavaScript, and Apple representatives have been fairly vocal about not seeing a need.

Nope, not at all. The decision was made by the core web platform engineers. Introducing a new VM to a browser introduces considerable maintenance cost (we saw this with V8 and JavaScriptCore both in WebKit) and right now Dart isn’t yet ready to be considered for an integration with Blink. (more on that in a sec). Blink’s got strong principles around compatibility risk and this guides a lot of the decisions around our commitments to potential features as they are proposed. You can hear a more complete answer here from Darin Fisher, one of the Chrome web platform leads.

Have any non-WebKit browsers recently expressed an interest in Dart? A scripting language that only stands to work in one browser sounds a little VBScript-y.

Not yet, but since Dart compiles to JavaScript and runs across the modern web, it’s not gated by other browsers integrating the VM. But it’s still early days, Dart has not yet reached a stable 1.0 milestone and that there are still technical challenges with the Dart VM around performance and memory management. Still, It’s important to point out that Dart is an open source project, with a bunch of external contributors and committers.

Let me take a moment to provide my own perspective on Dart. :) Now, as you know, I’m a JavaScript guy, so early on, I took a side and and considered Dart an enemy. JavaScript should win; Dart is bad! But then I came to realize the Dart guys aren’t just setting out to improve the authoring and scalability of web application development. They also really want the web to win.  Now I’ve recently spoke about how The Mobile Web Is In Trouble, and clarified that my priorities are seeing it provide a fantastic user experience to everyone. For me, seeing the mobile web be successful trumps language wars and certainly quibbling over syntax. So I’m happy to see developers embrace the authoring advantages of Coffeescript, the smart subset of JavaScript strict mode, the legendary Emscripten & asm.js combo, the compiler feedback of TypeScript and the performance ambitions of Dart. It’s worth trying out technologies that can leapfrog the current expectations of the user experience that we can deliver. Our web is worth it.

Will Opera be using the Chromium version of Blink wholesale, as far as you know? Are we likely to see some divergence between Opera and Chrome?

As I understand it, Opera Mobile, Opera Desktop, and Opera Mini will all be based on Chromium. This means that they’ll not only share the exact version of Blink that Chrome uses, but also the same graphics stack, JavaScript engine, and networking stack. Already, Opera has contributed some great things to Blink and we’re excited about what’s next.

Why the name “Blink,� anyway?

Haha. Well… it’s a two parter. First, Blink evokes a certain feeling of speed and simplicity—two core principles of Chrome. Then, Chrome has a little tradition of slightly ironic names. Chrome itself is all about minimizing the browser chrome, and the Chromebook Pixel is all about not seeing any pixels at all. So naturally, it fits that Blink will never support the infamous <blink> tag. ;)

<3z

close article | permalink

Email deliverability is a lot like SEO. Actually measuring results it is even worse. Some people still believe stats like opens and clicks are an indicator… thats a shame.

In Email you are totally guessing unless you use something like our Spamguard system. We are the only company to quantify our email deliverability but its not like we are doing anything revolutionary. Any email platform could do it… but they know the results would not be pretty. Those guys believe its much better to leave you in the dark thinking your clicks and opens is what matters. Not actually getting into the inbox.

But I digress…

One thing everyone can agree on that has a major factor is getting someone to add your contact information to their address book.

Lemme explain quick what this is for those who don’t know. Everyone has a list of contacts or “address book” in your email program. Whenever you email someone they are automatically added to that address book. People who are in your address book will override any sort of spam filter and from our experience if you have someone added to your address book then you will receive 100% of their emails.

In the Mass Email Deployment Industry this has always been the holy grail. Spammers have been coming up with unique ways hack in or manipulate systems to get their spam domains and accounts added to users address books so they can drastically increase revenue.

But lets take this to a legit company. Like one of our clients. How do we get customers to add their email address without doing anything shady?

We simply get them to reply to an email. Thats it… And you want to get them to do it right away.  Because when I write all the email copy for you I start to build a relationship.  But when the copy gets more salesy and could trip spam filters that is when we are already added to the contact list and bypass those.

Here are 2 simple tricks you can do:

1. Double Opt In – instead of making them click on a link just have them reply to the email.
2. Offer a discount – After you welcome them to your list offer them a discount if they just reply to the email and keep the subject intact.

There are a lot of other ways but those are 2 ways everyone here should be able to implement right away 100% automated programatically. I am sure your email provider will be able to do this for you at no charge. If not maybe its time you get on board with a enterprise level platform that works intimately with your company and really helps you grow in more ways then just email marketing.

Trying to increase your Google rank that is like no other?

close article | permalink

The open source WordPress CMS is typically installed to fill the void as a blogging platform. Many webmasters also choose WordPress for handling static pages with a backend interface. But the additional library of free WP plugins can only add to the major publishing platforms which come right out of the box.

In this article I would like to share a few popular choices for adding user voting to your posts and pages. WordPress will allow you to edit the settings in your plugin backend admin. This means you can adjust how the buttons will display on the page and how they behave from user interaction.

I Recommend This

The plugin called I Recommend This is a bit newer yet also has incredible reviews. It has been updated to work with the most current release of WP which is 3.5.2(as of writing this article). According to the original project page we may not see a whole lot of updates in the future.

But this plugin must be one of my favorites. Very easy to install and it looks great on almost any platform. The user interface is modeled similar to Tumblr’s like feature. Bloggers on the social network will know about how this works. You also have access to an internal settings page for customizing the look and styles on the page.

WP Likes

For a more complicated example of user voting check out WP Likes and what it can offer. This plugin allows new visitors to vote on articles which they like the best. All anonymous votes are counted and ranked by IP address to eliminate duplicate voting. There are a series of shortcodes which you should add into the page. They look something like this:

[wp_likes] [wp_likes show="monthly"] [wp_likes show="weekly" count="10"]

Also the plugin can be used as a small widget in your sidebar areas. This will display your top liked posts of all time. It can be organized by a certain date/time and there is lots of potential. But in my opinion this will require a more detailed knowledge of WordPress to install and get running properly. It’s not impossible for a beginner, but just keep trying if you run into a wall.

WTI Like Posts

This plugin comes to us from Web Tech Ideas and it seems to be one of the more popular options on the table. The average rating is a whopping 4.9 out of 5! The reason for this is because WTI has released two separate versions of their script. A simpler open source plugin which you can download from WordPress for free, along with a pro version which costs $25.00 USD.

The list of extra stuff in the pro version is quite daunting. You have the ability to create new post widgets ranking the most popular/unpopular articles. Also the choice of 6 different CSS styles for the voting buttons. I think anybody who is interested should try out the free version first, just to get a sense of the plugin and if you could be using it on your website. WTI Like Posts is definitely one of the more advanced user voting plugins with an exceptional array of possibilities.

WP Postratings

If you have been looking for a star rating option then I might suggest WP Postratings. This has an extraordinary backend design which makes handling the plugin very easy on beginners. The user will have a choice of voting on your post from 1 star to 5 stars. Then when users reload the page a new average will be calculated based on the total number of votes.

You will have the ability to change different template tags within the PHP to output various lines of text. The customizations are a lot easier than you might think. I also really like how the plugin will directly show how many votes are on each page, along with the average star rating. This plugin is better suited for general use as it is easy to install, easy to customize, and not much work is required for upkeep.

WP Custom Voting

The brand new open source project named WP Custom Voting is a newcomer into the field. I think the interface is a bit generic and will probably require a few CSS edits. However the functionality is golden and it supports the most currently up-to-date version of WordPress.

The Ajax code is written to check a user’s IP and keep a list of user votes stored in the database. There is not much security required to keep everything running properly. I have not extensively tested this plugin on any of my websites, but after looking over the features it seems to be very straightforward. This is a bare-bones voting plugin for somebody who just needs an easy interface with a quick installation.

KK I Like It

In my own personal opinion the KK I Like It plugins seeks to push the boundaries on WordPress. The admin panel is very well designed, easy to manage, and provides a litany of options such as custom button styles and anonymous vote tracking. You can display Gravatar photos and usernames(if available) for each of the people who votes on your articles.

Webmasters who are running BuddyPress may find a lot more use out of this plugin because it ties directly into the core of WordPress. All the users in your system can share their opinions and it will be displayed right into the post template. Although I haven’t customized much of this plugin, it is not unreasonable to think you could edit the PHP to link back to a user’s profile page. It’s a plugin which is worth testing – but since it is in beta you may not want to use this for a live production environment.

I Blank This

I Blank This is clean, concise, and very straightforward. The backend itself has not been updated for a while and the official plugin website has since gone offline. It is unclear if the developer will return for future updates. However the features are so basic and easy to use that I would not believe it will be difficult to setup your own functionality.

The best way to test out this plugin is by quickly installing and seeing how it looks. The admin panel does not offer a whole slew of options, but you can also go into the plugin editor and directly change PHP codes to display in various styles. The biggest problem is that this plugin was only released as version 1.0 and has not been touched ever since. If you are looking for a solution which will be updated over time, check out some of the other alternatives in this article.

Kudos

The original JavaScript for Kudos voting was put on Github as an open source project. The Kudos WordPress plugin was created by ahoereth and also managed in a Github repository. I think this plugin brings a lot of different ideas to the table which you do not find in any other solutions. The animation is very outlandish and the user vote function triggers by hovering over the button for just a few seconds.

Check out the live demo from the original JS Github entry. The WordPress plugin will work exactly the same, but it also has a custom backend admin panel for rearranging the voting button. Kudos may be worth a try but it is certainly peculiar – in a good way! Test it out and see if it works for your website. But keep in mind there are tons of these voting plugins and you should not stop looking until you find the right one for your project.

Final Thoughts

Any number of these plugins will help to improve the user experience on your WordPress website. There are situations where it does not make sense to include voting features on your pages, or any posts at all. But accompanied by the right features you may be surprised how much influence can be gained through user voting. If we have missed any great plugins feel free to share in the discussion area below.

The post WordPress Plugins for Custom User Voting Functionality appeared first on Treehouse Blog.

close article | permalink

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.

close article | permalink

There has been a growing tidal wave of flat designs on the web, and recent trend reports have confirmed that they're only increasing in popularity.

Of course it's easy to dismiss flat design as yet another fleeting aesthetic trend.

But further investigation into this new philosophy reveals that flat design is a lot more than "just for looks."

What is Flat Design?

Flat design can be seen as the more sophisticated and versatile cousin of minimalism. While flat designs look great when made within the restraints of minimalism, they...read more
By Luke Clum

close article | permalink

Here is a list of the newest internet marketing tools. All items listed are certified with volume sold and refund rate. Refund rate is a great indication of customers satisfied with the product. If one of these products interest you click the find out more information to go to their sales page which will be a much more detailed page about the product. All products come with at least a 30 day refund rate.

Viral Money Machines - case study that reveals how one person made $18,000 in four months by creating a Facebook Fanpage, driving traffic to it, and then monetizing it.  Cost: $7.00 – Products Sold to date: 2500+ Refund Rate: 0.00% Click here for more information

Lead Trackerjack-  the ultimate lead gen system and call tracking software. Cost: $49.00 Products Sold to date: 1000+ Refund Rate: 5.26% Click here for more information

Canis Inner Circle  – Get advice on how to grow your niche site to a #1 rank on search engines. Price: $4.95 Products Sold to date: 500+ Refund Rate: 2.820 Click here for more information

If you would like to be alerted on our weekly hot new internet marketing products of the week just enter your name and email below.   I also have a very big surprise for you when you get on the list

Looking for an SEO service that won’t get you banned?

close article | permalink

close article | permalink

close article | permalink

The <picture> element is a new addition to HTML5 that’s being championed by the W3C’s Responsive Images Community Group (RICG). It is intended to provide a declarative, markup-based solution to enable responsive images without the need of JavaScript libraries or complicated server-side detection.

The <picture> element supports a number of different types of fallback content, but the current implementation of these fallbacks is problematic. In this article, we’ll explore how the fallbacks work, how they fail and what can be done about it.

The <picture> Element And Fallback Content

Like <video> and <audio>, <picture> uses <source> elements to provide a set of images that the browser can choose from. The <source> elements may optionally contain type and media attributes to let the browser know the file type and media type of the source, respectively. Given the information in the attributes, the browser should render the first <source> with a supported file type and matching media query. For example:

<picture>
    <source src="landscape.webp" type="image/webp" media="screen and (min-width: 20em) and (orientation: landscape)" />
    <source src="landscape.jpg" type="image/jpg" media="screen and (min-width: 20em) and (orientation: landscape)" />
    <source src="portrait.webp" type="image/webp" media="screen and (max-width: 20em) and (orientation: portrait)" />
    <source src="portrait.jpg" type="image/jpg" media="screen and (max-width: 20em) and (orientation: portrait)" />
</picture>

For situations in which a browser doesn’t know how to deal with <picture> (or <video> or <audio>) or cannot render any of the <source> elements, a developer can include fallback content. This fallback content is often either an image or descriptive text; if the fallback content is an <img>, then a further fallback is provided in the alt attribute (or longdesc), as normal.

<picture>
    <source type="image/webp" src="image.webp" />
    <source type="image/vnd.ms-photo" src="image.jxr" />
    <img src="fallback.jpg" alt="fancy pants">
</picture>

The <picture> element differs from <video> and <audio> in that it also allows srcset. The srcset attribute enables a developer to specify different images based on a device’s pixel density. When creating a responsive image using both <picture> and srcset, we might expect something like the following:

<picture>
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg 3x" type="image/jpeg" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" type="image/jpeg" />
    <img src="fallback.jpg" alt="fancy pants" />
</picture>

The idea behind a <picture> example like this is that exactly one image should be downloaded, according to the user’s context:

• Users with <picture> support and a viewport at least 40 ems wide should get the big image.
• Users with <picture> support and a viewport narrower than 40 ems should get the med image.
• Users without <picture> support should get the fallback image.

If the browser chooses to display the big or med source, it can choose an image at an appropriate resolution based on the srcset attribute:

• A browser on a low-resolution device (such as an iMac) should show the 1x image.
• A browser on a higher-resolution device (such as an iPhone with a Retina display) should show the 2x image.
• A browser on a next-generation device with even higher resolution should show the 3x image.

The benefit to the user is that only one image file is downloaded, regardless of feature support, viewport dimensions or screen density.

The <picture> element also has the ability to use non-image fallbacks, which should be great for accessibility: if no image can be displayed or if a user needs a description of an image, then a <p> or <span> or <table> or any other element may be included as a fallback. This allows for more robust and content-appropriate fallbacks than a simple alt attribute.

The Fallback Problem

Right now, the <picture> element is not supported in any shipped browsers. Developers who want to use <picture> can use Scott Jehl’s Picturefill polyfill. Also, Yoav Weiss has created a Chromium-based prototype reference implementation that has partial support for <picture>. This Chromium build not only shows that browser support for <picture> is technically possible, but also enables us to check functionality and behavior against our expectations.

When testing examples like the above in his Chromium build, Yoav spotted a problem: even though <picture> is supported, and even though one of the first two <source> elements was being loaded, the fallback <img> was also loaded. Two images were being downloaded, even though only one was being used.

This happens because browsers “look ahead� as HTML is being downloaded and immediately start downloading images. As Yoav explains:

“When the parser encounters an img tag it creates an HTMLImageElement node and adds its attributes to it. When the attributes are added, the node is not aware of its parents, and when an ‘src’ attribute is added, an image download is immediately triggered.”

This kind of “look aheadâ€� parsing works great most of the time because the browser can start downloading images even before it has finished downloading all of the HTML. But in cases where an img element is a child of <picture> (or <video> or <audio>), the browser wouldn’t (currently) care about the parent element: it would just see an img and start downloading. The problem also occurs if we forget about the parent element and just consider an <img> that has both the src and srcset attributes: the parser would download the src image before choosing and downloading a resource from srcset.

<picture>
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg 3x" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" />
    <img src="fallback.jpg" alt="fancy pants" />
    <!-- fallback.jpg is *always* downloaded -->
</picture>

<img src="fallback.jpg" srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" alt="fancy pants" />
<!-- fallback.jpg is *always* downloaded -->

<video>
    <source src="video.mp4" type="video/mp4" />
    <source src="video.webm" type="video/webm" />
    <source src="video.ogv" type="video/ogg" />
    <img src="fallback.jpg" alt="fancy pants" />
    <!-- fallback.jpg is *always* downloaded -->
</video>

In all of these cases, we would have multiple images being downloaded instead of just the one being displayed. But who cares? Well, your users who are downloading extra content and wasting time and money would care, especially the ones with bandwidth caps and slow connections. And maybe you, too, if you’re paying for the bandwidth you serve.

A Potential Solution

This problem needs both short- and long-term solutions.

In the long term, we need to make sure that browser implementations of <picture> (and <video> and <audio>) can overcome this bug. For example, Robin Berjon has suggested that it might be possible to treat the contents of <picture> as inert, like the contents of <template>, and to use the Shadow DOM (see, for example, “HTML5’s New Template Tag: Standardizing Client-Side Templatingâ€�). Yoav has suggested using an attribute on <img> to indicate that the browser should wait to download the src.

While changing the way the parser works is technically possible, it would make the implementation more complicated. Changing the parser could also affect JavaScript code and libraries that assume a download has been triggered as soon as a src attribute is added to an <img>. These long-term changes would require cooperation from browser vendors, JavaScript library creators and developers.

In the short term, we need a working solution that avoids wasted bandwidth when experimenting with <picture> and srcset, and when using <video> and <audio> with <img> fallbacks. Because of the difficulty and time involved in updating specifications and browsers, a short-term solution would need to rely on existing tools and browser behaviors.

So, what is currently available to us that solves this in the short term? Our old friends <object> and <embed>, both of which can be used to display images. If you load an image using these tags, it will display properly in the appropriate fallback conditions, but it won’t otherwise be downloaded.

Different browsers behave differently according to whether we use <object>, <embed> or both. To find the best solution, I tested (using a slightly modified version of this gist) in:

• Android browser 528.5+/4.0/525.20.1 on Android 1.6 (using a virtualized Sony Xperia X10 on BrowserStack)
• Android browser 533.1/4.0/533.1 on Android 2.3.3 (using a virtualized Samsung Galaxy S II on BrowserStack)
• Android browser 534.30/4.0/534.30 on Android 4.2 (using a virtualized LG Nexus 4 on BrowserStack)
• Chrome 25.0.1364.160 on OS X 10.8.2
• Chromium 25.0.1336.0 (169465) (RICG Build) on OS X 10.8.2
• Firefox 19.0.2 on OS X 10.8.2
• Internet Explorer 6.0.3790.1830 on Windows XP (using BrowserStack)
• Internet Explorer 7.0.5730.13 on Windows XP (using BrowserStack)
• Internet Explorer 8.0.6001.19222 on Windows 7 (using BrowserStack)
• Internet Explorer 9.0.8112.16421 on Windows 7 (using BrowserStack)
• Internet Explorer 10.0.9200.16384 (desktop) on Windows 8 (using BrowserStack)
• Opera 12.14 build 1738 on OS X 10.8.2
• Opera Mobile 9.80/2.11.355/12.10 on Android 2.3.7 (using a virtualized Samsung Galaxy Tab 10.1 on Opera Mobile Emulator for Mac)
• Safari 6.0.2 (8536.26.17) on OS X 10.8.2
• Safari (Mobile) 536.26/6.0/10B144/8536.25 on iOS 6.1 (10B144) (using an iPhone 4)
• Safari (Mobile) 536.26/6.0/10B144/8536.25 on iOS 6.1 (10B141) (using an iPad 2)

I ran five tests:

1. <picture> falls back to <object>
2. <picture> falls back to <embed>
3. <picture> falls back to <object>, which falls back to <embed>
4. <picture> falls back to <object>, which falls back to <img>
5. <picture> falls back to <img>

I found the following support:

Making Sure The Content Is Accessible

Although the specifics of how to provide fallback content for <picture> are still being debated (see also this thread), I wanted to test how Apple’s VoiceOver performed with different elements. For these experiments, I checked whether VoiceOver read alt attributes in various places, as well as fallback <span> elements. Unfortunately, I wasn’t able to test using other screen readers or assistive technology, although I’d love to hear about your experiences.

Bulletproof Syntax

Based on these data, I’ve come up with the following “bulletproof� solution:

<picture alt="fancy pants">
    <!-- loaded by browsers that support picture and that support one of the sources -->
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg" type="image/jpeg" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, big-3x.jpg" type="image/jpeg" />

    <!-- loaded by IE 8+, non-IE browsers that don’t support picture, and browsers that support picture but cannot find an appropriate source -->
    <![if gte IE 8]>
    <object data="fallback.jpg" type="image/jpeg"></object>
    <span class="fake-alt">fancy pants</span>
    <![endif]>

    <!-- loaded by IE 6 and 7 -->
    <!--[if lt IE 8]>
    <img src="fallback.jpg" alt="fancy pants" />
    <![endif]-->
</picture>

.fake-alt {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}

Here we have a <picture> element, two sources to choose from for browsers that support <picture>, a fallback for most other browsers using <object> and a <span> (see note just below), and a separate <img> fallback for IE 7 and below. The empty alt prevents the actual image from being announced to screen readers, and the <span> is hidden using CSS (which is equivalent to HTML5 Boilerplate’s .visuallyhidden class) but still available to screen readers. The <embed> element is not needed.

(Note: The use of the <span> as a fake alt is necessary so that VoiceOver reads the text in Opera. Even though Opera has a relatively small footprint, and even though it’s in the process of being switched to WebKit, I still think it’s worth our consideration. However, if you don’t care about supporting that particular browser, you could get rid of the <span> and use an alt on the <object> instead (even though that isn’t strictly allowed by the specification). This is assuming that the <span> and alt have the same content. If you have a richer fallback element, such as a <table>, using both it and a non-empty alt attribute might be desirable.)

A similar solution should also work with <audio>, although <img> fallbacks for that element are, admittedly, rare. When dealing with <video>, the problem goes away if our fallback image is the same as our poster image. If these may be the same, then the “bulletproofâ€� syntax for <video> would be this:

<video poster="fallback.jpg">
    <!-- loaded by browsers that support video and that support one of the sources -->
    <source src="video.mp4" type="video/mp4" />
    <source src="video.webm" type="video/webm" />
    <source src="video.ogv" type="video/ogg" />

    <!-- loaded by browsers that don't support video, and browsers that support video but cannot find an appropriate source -->
    <img src="fallback.jpg" alt="fancy pants" />
</video>

However, if your <video> needs a separate fallback and poster image, then you might want to consider using the same structure as the <picture> solution above.

Note that <video> and <audio> don’t have alt attributes, and even if you add them, they will be ignored by VoiceOver. For accessible video, you might want to look into the work being done with Web Video Text Tracks (WebVTT).

Unfortunately, extensive testing with <video> and <audio> elements is beyond the scope of this article, so let us know in the comments if you find anything interesting with these.

How Good (Or Bad) Is This Solution?

Let’s get the bad out of the way first, shall we? This solution is hacky. It’s obviously not workable as a real, long-term solution. It is crazy verbose; no one in their right mind wants to code all of this just to put an image on a page.

Also, semantically, we really should use an <img> element to display an image, not an <object>. That’s what <img> is for.

And there are some practical issues:

• Chrome and Safari won’t show proper context menus for the images, meaning that users won’t be able to open or save them easily.
• IE 9 and 10 send an extra HEAD request along with the GET request.
• Using a <span> as a fake alt is pretty sketchy, and although it worked for my tests in VoiceOver, it could potentially cause other accessibility problems.

All that being said, as a short-term solution, it’s not too bad. We get these benefits:

• A visible image in every browser is tested (<picture> and <source> when supported, and the fallback otherwise).
• Only one HTTP GET request in every browser is tested (and the extra HEAD request and response in IE are tiny).
• VoiceOver is supported (and is hopefully supported with other screen readers).

<!-- show screenshot of network pane here -->

The semantics of the solution, while not ideal, are not horrible either: the HTML5 specification states that an <object> “element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a pluginâ€� (emphasis mine).

And although the <span> is not as nice as a real alt attribute, using a visually hidden element for accessibility is not uncommon. Consider, for example, “Skip to contentâ€� links that are visibly hidden but available to screen readers.

Next Steps

The best part about this solution, though, is that it highlights how bad the current situation is. This is a real problem, and it deserves a better solution than the monstrosity I’ve proposed.

We need discussion and participation from both developers and browser vendors on this. Getting support from browser makers is crucial; a specification can be written for any old thing, but it doesn’t become real until it is implemented in browsers. Support from developers is needed to make sure that the solution is good enough to get used in the real world. This consensus-based approach is what was used to add the <main> element to the specification recently; Steve Faulkner discusses this process a bit in his excellent interview with HTML5 Doctor.

If you’re interested in helping to solve this problem, please consider joining the discussion:

• Join the RICG, and participate in the #respimg IRC channel and the public-respimg mailing list.
• Check out the RICG on GitHub, and consider adding your voice to the discussion on this issue.
• Join the W3C public-html mailing list and the WHATWG mailing list to follow and contribute to discussions about the specifications.
• Help fix problems with current implementations by reviewing, patching, commenting on and filing bugs for WebKit, Mozilla and Internet Explorer.

The next step towards a long-term solution is to achieve consensus among developers and browser vendors on how this should work. Don’t get left out of the conversation.

Thanks to fellow RICG members Yoav Weiss, Marcos Cáceres and Mat Marquis for providing feedback on this article.

(al)

© David Newton for Smashing Magazine, 2013.

close article | permalink

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.

close article | permalink

In any given day I can find myself reading up on a new W3C proposal, fixing an issue with our tax return, coding an add-on for our product, writing a conference presentation, building a server, creating a video tutorial, and doing front end development for one of our sites. Without clients dictating my workload I’m in the enviable position of being able to choose where to focus my efforts. However, I can’t physically do everything.

I’m one half of a two-person web development business—the team behind the little CMS, Perch. I’m also an author and speaker on subjects that range from CSS to technical support, and I enjoy all of it.

When we were a service business, what I was actually working on was largely dictated by the requirements of our clients. Whether they wanted to pay me to build servers, manage projects, or write code didn’t really matter. I was exchanging my time for money, doing a range of things I enjoyed. Now that we’re a product company, my greatest challenge is working out where I am best spending my time, while avoiding falling down a rabbit hole of interesting things I have discovered while performing some other task.

The quote that I opened this column with reflects the dilemma I seem to face daily. I can choose to place my attention anywhere. But if I dart around between tasks, none of them get my full attention. At the very least, progress on everything becomes painfuly slow as I spend an hour on one thing and two on another, inching them all forward. I can’t claim to have the perfect solution to managing this problem, but I have started to develop a process for deciding what needs to be done, and whether I am the best person to be doing it.

First and foremost you need to identify what needs doing. I am a great fan of Getting Things Done and regularly review our business and my personal goals, and the tasks that will go into meeting them. Once I have a list of tasks, I can assess them against the following criteria:

• Am I the only person who can do this?
• Does the business or product benefit from me in particular doing this?
• Is this a task I really enjoy doing?
• Will I learn anything new by doing this?
• What am I not doing if I choose to do this?

Am I the only person who can do this?

Things that fall into group one, the things that only I can do, need investigating. It isn’t ideal for any business to have things that only one person can do. It might be that I need to deal with that task today, but how can I make it so that in the future someone else could? Until the middle of last year, our accounts were a case in point. Although we had an accountant do our end of year tax returns, I was the only person who fully understood the complex processes developed to deal with the many incoming small payments for Perch licenses. Taking on a bookkeeper meant I had to formalize and document all of those processes. As a result I don’t have to do the day-to-day books, but perhaps more importantly the business isn’t reliant on knowledge that is only in my head.

Does the business or product benefit from me in particular doing this?

It can make sense to keep some tasks internal. I wouldn’t completely outsource our technical support, or our social media activity, or even our marketing. The public face of our product is very much about us being a small, friendly business. Our customers get to talk to us, the product developers; we share their frustrations and they help us decide on where to put time into new features. There may well be real reasons to keep certain tasks as a role of the core person or team, even if they would seem straightforward to outsource.

Is this a task I really enjoy doing?

Running a business can involve hard work and long hours. If you feel you have to outsource bits of your job that you love doing because it makes most sense as a business, you may end up pretty miserable. For those of us running small software companies, it’s likely we have ended up here because we like to code. So it’s important to me that I spend some of my time actually writing code—even if it might be more sensible from a business perspective for me to just manage other people who are writing code.

I believe that our products and businesses are better when we love being involved with them. To have a successful business, it’s likely that you will always have important things to do that you find less enjoyable than designing or writing code, however I don’t think we should be beating ourselves over the head. Doing what we love is really what has been behind the success of our product. It is completely ok to hang onto some tasks because you simply enjoy doing them.

Will I learn anything new by doing this?

I might really enjoy a particular project, but I find a helpful way to decide if I should do something or contract it out is to see whether I will learn anything new by doing it myself. For example, I have just sent out a sizeable chunk of front-end development. It is a rebuild of an existing site, and I think there are lots of practical and performance gains to be had by rebuilding it. It would have been nice to have done that work myself, but I wouldn’t have learned anything by doing it. Therefore I made the decision that this would be a good piece of work to outsource to a contractor. I can manage that project and make sure that I’m happy with the end result, but I don’t need to actually write the code.

Our business benefits by us having knowledge and understanding. I’m currently spending quite a lot of time learning about automation (using Puppet) and modern ways of managing systems while rebuilding our infrastructure. I could have brought someone in to do this work for me, and may well do so in future. Yet by updating my systems administration skills, I’m ensuring that within the business we maintain a good level of knowledge about our infrastructure.

What am I not doing if I choose to do this?

As part of a tiny team of two, I’ll always have a number of tasks on the go. Ultimately, choosing to take on one task means not doing something else. It might be another task in the business that gets pushed back. It might be personal things like exercise, or spending time with family and friends. To be able to understand the implications of selecting one thing to work on over another, you need to have a really good overview of all the things that are trying to get your attention.

Having clear business goals and objectives in the first place can make this decision-making so much easier. When you find yourself in the position of being able to do anything, it is so easy to run around picking up tasks and trying to do everything. The trick is to take that step back; to see where you can be more strategic with which tasks you tackle and which you delegate. This approach can help you be far more productive and give you space to enjoy the work you are doing while meeting your business goals.

close article | permalink

In a world where people of all ages and backgrounds are spending increasingly more and more of their time navigating through software and web and mobile apps, providing an experience that engages and guides users is crucial for the success of the application.

While development teams spend countless hours designing the user experience, planning and coding features, and testing the application, they often overlook the importance of the information appearing within the application.

While this information is referred to, in its simplest form, as the user interface text, the integration between the user experience, the features and workflows comprising the application, and the...read more
By Linda Newman Lior

close article | permalink

Android is huge: 480 million people currently use Android devices, and 1 million new devices are activated daily. This means that every three weeks, the number of people who activate new Android devices is equal to the entire population of Australia. (Recent studies by Nielsen show that more Android devices are on the market than iOS devices.)

Popular apps that become available on Android experience huge growth. For example, Instagram grew by 10 million users with the launch of its Android app — in just 10 days.

Despite this unprecedented expansion of the platform, the majority of Android apps are… well, not great. Fewer quality apps are in Google Play than in the iTunes Store. Part of the reason for this is that Android has been going through puberty in the past few years. It was disorganized and erratic, and many designers avoided it — even hated it — and naturally gravitated towards iOS.

Some of Android’s problems no longer exist, and others have been blown out of proportion. For the ones that do exist, we’ll provide guidance on how to deal with them and how to start designing your first great Android app.

Symptoms Of Puberty

Many Android apps underperformed because the platform wasn’t mature enough to allow great apps to emerge. Though a powerful laboratory — it offered manufacturers and developers the freedom and openness to create whatever they wanted — not many wanted to work in a sandbox environment every day. But that sandbox has since coalesced into a foundation for great design.

The points below are what you might remember about Android — and possibly what curbed your desire to give it a try — but these issues have also been eliminated or improved. If your concerns appear in this list, then the next section will demonstrate how they’ve been resolved with Android’s maturation and how you can design a better app as a result.

Lack of Consistency in Google’s Own Apps

Not long ago, almost all of Google’s own Android apps looked different from each other.

Google took more than a year to start following its own advice. The action bar design pattern was presented in 2010 but wasn’t implemented until October 2011, with Android OS 4.0.

Lack of a User-Centric Design Culture in the Android Community

Google’s failure to set an example for other developers (because of its own inconsistencies) and the lack of consistent design guidelines and patterns contributed to another bigger problem: poor user experience. Good design starts with people; it leverages technology to help users accomplish their goals. Google wasn’t communicating this to developers clearly enough (unlike Apple).

Dramatically Inconsistent Experience Between Devices and OS Versions

Manufacturers often customize the system’s UI and hardware buttons. This contributed to fragmentation, made testing and quality control much harder and made consistency in app design nearly impossible.

Manufacturers used to put hardware buttons in different orders. Switching between devices was a pain.

Properly testing apps in the changing and fast-growing market was difficult for developers. Thus, a majority of apps didn’t function as they should have or were poorly designed.

Those apps are still there, but yours doesn’t have to be one of them. Android has since improved, enabling you to create a better and more consistent experience for your users.

Android Has Matured

The Android user experience today is more robust than ever before, making it easier for app designers and developers to deliver great apps. While some of the earlier problems still exist, most have become more manageable — and many more have been solved altogether.

One fundamental problem remains, however: there aren’t enough great apps. But with an improved and mature Android platform, designers and developers can solve this problem. All we have to do is give Android another chance.

The areas below are what the mature Android has to offer.

Better App Discovery

Previously, the discovery process was limited to searching by keyword and then trying out all of the results. The new Google Play store offers better discovery through featured apps and staff picks.

The new Google Play store offers more ways to discover cool new apps than its predecessor, Android Market.

Proper Android Design Guidelines

Until recently, no direction was provided for the basic elements that every app requires. Google has since created design guidelines, which remove the burden of small design decisions from app designers and developers. We can finally focus on the core value of the apps we’re creating and ensure a consistent experience across devices.

Example of a grid and a 48 density-independent pixel (DP) rhythm, taken from the “Metrics and Grids� section of the guidelines.

Menu and Search Hardware Buttons Are Gone

Google has started removing hardware buttons from its devices, uniting the hardware and software and making Android devices more elegant and easier to use.

The Nexus 4 is an instance of Google’s new approach to hardware buttons. They are always there, always in the same order. And gone are the search and menu buttons.

A variety of Android device types still exist (for example, LG still produces devices with Android 4.0 and hard menu buttons), yet this diversity is one of the main reasons why Android apps are able to excel.

Fragmentation Isn’t All Bad

Fragmentation may be the biggest remaining challenge facing designers and developers, and it’s built into Android’s DNA — a permanent part of the Android experience. This diversity offers designers an opportunity to reach an unprecedented number of people globally.

Learning to work within this fragmentation will make you a better designer or developer overall, with broader knowledge and an improved skill set. Given the rewards, the challenge is worthwhile to pursue. And to succeed in this pursuit, here are a few things to keep in mind when creating your Android app.

Tips For Creating A Successful Android App

Get to Know Android

To understand Android, you should learn how to use it and get to know its users. The best way to do this is by buying several devices from different manufacturers, with different screen sizes and maybe even OS versions. This will help you not only to understand user diversity but also to test your app.

To choose the best devices for your app, check the latest statistics from Google and select a device with your desired specifications. Independent studies, such as OpenSignal’s August 2012 report, can also help you select devices.

Something to keep in mind is that Android updates are controlled by service providers and, as a result, usually arrive earlier on devices that are created in collaboration with Google, such as the Nexus series. Picking up the latest Nexus devices will keep you on the cutting edge of platform releases. You can save money by buying a used device, but make sure it runs the version of Android that you need before purchasing it (many old devices are no longer updated).

Talk to your Android-using friends about how they use their devices and what they are happy and unhappy about. That will help you get to know the environment and bring you into the culture.

Follow the Guidelines

Following the guidelines will help you create an app that feels native to any device. But that’s just one of many reasons why following them is worthwhile. They can also help you achieve the following:

• Create an app fit for virtually any device,
• Make the app feel true to Android,
• Provide a UI that is familiar to users,
• Make the app easier to develop and support,
• Increase the app’s chances of being featured in Google Play.

Keeping Android navigation patterns in mind and using elements that are native to the platform will also help you create a consistent experience across devices.

When bringing an iPhone design (left) to Android (right), use elements that are native to the platform: this table view is styled for Android; the buttons for searching and adding contacts are moved to the split action bar at the bottom; and switching between data views is done through the view control.

Custom apps are more difficult not only to support, but also to design when ensuring operability across devices. New Android apps look great thanks to the new design guidelines; they are also very different from apps created before Android 4.0.

Understand Android’s Look and Feel

Google has invested a lot of effort in bringing a consistent visual experience to all of its products, including Android. Android 4.0 introduced its own style: simple, plain, clean — more about function than form.

Although this provides great freedom in styling, you still have to consider the subtlety of Android’s visual style: saying more with less. Simply copying the styles and elements from an iOS app might not work. And releasing a new app with old styles or with elements that look like they belong on another platform could make users react negatively — which happened to Microsoft.

Browsing Android Niceties is a great way to grasp Android’s style and to find inspiration.

Google’s Search app is a great instance of Android’s look and feel.

A good way to distinguish your app is through its icon. App icons for Android can take any shape or form. Users love great-looking icons and will gladly put your app on their home screen even if they don’t use it often. For tips on designing your icon, read the “Iconography� section in the guidelines.

App icons for Android can take any shape and form you want.

Build for Different Hardware Types

When designing your app, ensure that it will run properly on most devices. Keep in mind not only different screen sizes and aspect ratios, but also screens with low brightness or poor contrast and color, as well as slow, weak hardware.

For example, less-expensive devices might have smaller displays with lower contrast, so text that appears big enough on new devices with large screens might appear illegible there. Low contrast of text and visual elements might compromise the user experience as well.

Designs created according to the guidelines will easily scale to fit virtually any screen.

A few more things to keep in mind:

• Use contrasting colors for text and elements. For example, don’t use white on gray for important elements; they’ll just blend together on bad displays.
• Check your design on several devices with different brightness settings (low, high, auto) and in different lighting conditions.
• Even when using standard sizes, make sure your text and UI elements appear big enough on small screens (i.e. screens with a DPI lower than 240). You might want to adjust these elements specifically for small devices.

For a great example of designing for diversity, read Sebastiaan de With describe the process of creating the Alarm app.

Use Density-Independent Pixels to Define Layout

Part of providing a consistent experience is ensuring that UI elements stay roughly the same size across Android devices with varying pixels per inch (PPI). This doesn’t have to be a laborious task of calculating the number of pixels a button or font should contain in order to look great on a particular screen size. You can make the device do the work for you.

The recommended size for buttons in the action bar is 48 DP, which will result in different pixel sizes on different screens, but you don’t have to worry about that.

By defining sizes with density-independent pixels (DPs), you ensure that elements will appear at about the same physical size on any screen. Text will remain readable, and buttons will be comfortable to tap on any Android device, regardless of screen size or DPI. (See the section “Use Density-Independent Pixels� in the guidelines for more.)

In our practice, giving developers guidelines on sizes of elements and fonts has proven useful.

6. Create Assets for All Densities

Four sets of assets are required to accommodate all Android devices and to make the interface crisp: low density (LDPI), medium density (MDPI), high density (HDPI) and extra-high density (XHDPI). Start with a 640 × 960 screen for XHDPI assets, and then scale them down for other densities.

Start with XHDPI, and then scale down to other densities. Compare the actual sizes of these assets.

MDPI and XHDPI resolutions are exactly the same as the iPhone’s regular and Retina screens. So, if you have an iPhone design, you can use it to style the Android counterparts, or you could even test your designs on iPhone or iPod screens. But don’t forget about Android’s unique look and feel.

An XXHDPI bucket has been added to support the next generation of mobile devices, those with approximately 480 DPI screens. Although no such devices exist yet, the XXHDPI bucket is used today for launcher icons on XHDPI 10-inch tablets, such as the Nexus 10. (Because these devices are so large, the launcher icons are scaled up using the XHDPI assets.) To accommodate the next generation of screens, all you’ll need to do is scale your HDPI assets up by 200%.

Consider Different Versions Of The OS

Many Android devices will never be updated to the latest OS; it takes a couple of years for new versions to dominate the market. But users with newer devices won’t be pleased with apps whose looks or controls are outdated (as demonstrated by Microsoft’s Outlook app, mentioned earlier). So, deliver the most up to date experience possible. If you intend for the app to run on older platforms, create a separate version of the app for those devices.

Expand Your App With Widgets and Live Wallpapers

Take advantage of Android’s engaging features, such as widgets, live wallpapers and notifications. Widgets enable users to receive updates without running the app, and notifications are improving with each version of Android. Google is providing great support for designers and developers on how to notify users.

Widgets are a convenient way to peek into an app without opening it. This enables you to focus a user’s attention on a small portion of information, which would then expand within the app.

Widgets may have buttons and scrollable areas. Think of them as advanced app icons.

Gmail’s widget offers a sneak peek into the mailbox and enables users to compose mail right from the home screen. Chrome’s grid-view widget displays favorites or history.

Android users love to customize their devices and make them personal, and these items give them greater flexibility to do so.

Properly Test on Devices You Support

One of the most common reasons for negative reviews in the Play store is an app not functioning as promised. Target your design to the most popular devices, and release only for the ones you have tested; otherwise, you’ll end up with bad reviews from people frustrated by your app not working properly.

The highly successful Dead Space game receives most of its one-star reviews because the game doesn’t run on certain devices.

Design for Tablets, Too

Although several great Android tablets are on the market, they are not as popular as competitors such as the iPad. But if your goal is to build a truly universal Android app, then you need to consider tablets as well. The guidelines advise designers to use multi-pane layouts for tablet UIs and to build their interface using fragments.

Tablets use the same graphical assets as phones, but consider the context in which tablets are used. For instance, people usually hold tablets further away from their eyes than phones and, thus, are less precise in their tapping. So, the UI will require larger fonts, bigger buttons and more white space around elements.

Don’t forget to run your app through the “Tablet App Quality Checklist� as well.

Give Android A Chance

Designing for Android might be challenging in the beginning — it’s not as simple as it looks — but by following these 10 steps, you’ll have a head start on delivering a fantastic user experience and building a truly great app.

Give Android a chance. Designing for this newly matured platform is an interesting and educational process, and you’ll deliver a great-looking app while obtaining a new set of skills. You might find the experience to be very rewarding.

Update: While we were writing this article, case study has been published by The Verge about the Facebook Home application — next big thing for Facebook. But this isn’t about Facebook anymore. Thought this particular application is quite controversial, with limited device support and experience far from perfect, Fb designers have proven that with enough effort 100% of your ideas can be implemented and delivered on Android with no compromise. They have revealed a great opportunity and may even have marked the beginning of a new trend of creating greater presence on Android.

Examples of Great Android Apps for Inspiration

• The Verge
• doubleTwist Alarm
• Skype
• Evernote
• Foursquare
• Tumblr
• New York Times
• Path
• Endomondo
• Expedia

(al) (ea)

© A. Komarov, N. Yermolayev for Smashing Magazine, 2013.

close article | permalink

Ilya Grigorik discusses in detail how to construct a mobile website that loads as quickly as possible. A site that not only renders in 1 second, but one that is also visible in 1 second. With hard statistics as evidence to show why this matters, Ilya discusses techniques to deliver a 1000 millisecond experience.

close article | permalink

When it comes to e-commerce sites and shopping cart flows, usability testing is more than good practice. It’s a precious tool that helps uncover missed opportunities and dollars left on the table.

I’d like to present a handful of case studies and A/B tests that indicate a streamlined, “no BS� e-commerce flow with elegant user experience—where the site is honest and clear with visitors about how checkout works and what happens next—usually takes the cake for best conversion rate. The caveat is, keep on testing. As the last case study will suggest, there are always surprises.

Lesson 1: Do what you say you’re going to do

In business and in life, integrity is key and we often prefer people who do what they say they’re going to do. Why should buttons be any...read more
By Toby Biddle

close article | permalink

We’ve long believed in the value of transparency at 37signals. It’s why we write about how we work and why we provide real-time information about our customer happiness and uptime. We like being held to a high standard, and we think there’s no one better to do so than our customers.
Today we’re taking another step towards greater transparency with the launch of the 37signals Report Card.
This report card, which we’ll update monthly (April 2013 is available now; subscribe to be emailed the report each month), provides a high level overview of our performance in each month on the dimensions that our customers most directly experience: how available our applications are, how fast and successful their interactions with our support team were, and how fast the applications themselves were.

close article | permalink