I'm working on a site that uses Conditional Fields and Taxonomy Term Reference Tree Widget. Conditional Fields allows you to show certain fields in your content type only if other fields contain a particular value, and Term Reference Tree cleans up the UI on the backend for neater nested checkbox lists.

Today I encountered two problems when using these two modules with each other. Both were odd enough that I'm writing them up to save someone else time trolling the issue queue.

This client has a very complex taxonomy structure, and has a need to show some vocabularies only when certain values are provided in other vocabularies.

Here's an example of what I'm trying to do, tags renamed to protect the innocent:

field_pet has three options: cat, rabbit, dog.

field_cat_breed has three options: Persian, tabby, Manx.

field_rabbit_breed has three options: lionhead, dwarf, lop.

field_dog_breed has three options: black lab, Australian shepherd, Chow.

I only want to show field_cat_breed if field_pet is set to cat, because only cats should have a cat breed. field_rabbit_breed should only be shown if the pet is a rabbit. field_dog_breed should only be shown if it's a dog.

Unlike the examples above, the vocabularies on my site have a deep nested taxonomy, so we implemented Term Reference Tree on all the vocabularies to give them nice nested checkboxes.

The first problem I ran into was that field_cat_breed, field_rabbit_breed, and field_dog_breed were always shown, no matter what value I picked for field_pet -- or even if field_pet was completely empty.

Problem: It appears that Conditional Fields can't process input from Term Reference Tree. I didn't find a bug report to this effect, but found that if I switched the dependee (field_pet) from Term Reference Tree to a core widget type, the problem went away.

Solution: Go to your content type > Manage Fields. Find field_pet and click edit. Click Widget Type. Change it to checkboxes/radio buttons.

Having solved Problem #1, I set field_pet to rabbit and then set field_rabbit_breed to lionhead. I saved the node. While other tags not related to this dependency did show up (e.g. field_color), "lionhead" was stubbornly missing. I reopened the node and checked. It hadn't saved. I tried this multiple times with a variety of different tweaks, and sometimes "rabbit" did save, sometimes it didn't.

This post in the Conditional Fields issue queue gave me the answer. I had been setting my dependency like this:

Dependent: field_rabbit_breed
Dependee: field_pet
Values input mode: Insert value from widget...
[Check the box for "rabbit".]

This is much more convenient but apparently has a bug. Instead, I needed to set it manually. I checked the ID of the "rabbit" tag -- let's say 12 -- and set my dependency like this:

Dependent: field_rabbit_breed
Dependee: field_pet
Values input mode: All of these values (AND)...
Set of values: 12

I saved that dependency, added similar dependencies for field_dog_breed and field_cat_breed, went back to my node, and selected "rabbit" and "lionhead" again. It saved with no problem.

The Drupal module Leaflet More Maps already offered a considerable set of over 20 attractive maps from a variety of providers, including high-res versions of Google Maps. All available at the click of a drop-down selector, when you have the Leaflet or IP Geolocation Views & Maps modules installed.

But until a couple of days ago, an important provider was missing: Bing. Adding the Bing road, satellite and hybrid maps was a little harder due to Bing's quad tree tile numbering system. For instance, a map tile in the more common xyz coordinate system, e.g. "x=5, y=11 at zoom level 5", which is the Portland OR area (pictured in Esri's World Topo Map), in Bing is identified by a single quad key: "02123".

Not that you have to know any of this. With a little help of the Bing software architect" we figured this out for you. And thanks to the extensibility of the Leaflet JS library it was easy to implement with only a few lines of Javascript.

Simply upgrade to Leaflet More Maps 7.x-1.4, select your favourite map from the drop-down and enjoy!

The Drupal community members are a numerous and varied breed of creatures, each with their own personality and quirks that make Drupal the awesome eco-system that it is. I’ve said this before: I love the community and the atmosphere it has. Below are some of the ways one can experience being part of this community.

As a followup on A pinch of Symfony for D8MI? why do we need to squash?

After some more squash and push -f attempts regarding pull request for Symfony I get the hang of it.

But chx said in squash is bad as we loose history on the development process.

So how should we do this on d.o when git phase 3 lands? Those discussion seems to got to a halt.

1. CVS to Git: Phase 3
2. Personal sandboxes/repos/branches for issues for git

I do see the ratio behind squash from the receiving part as the pull request contains just one commit. So the log is clean and simple. Working locally I try to commit as early as possible thus having 10 commits needed to fit into one PR.

How do I work now?
I have two local branches named work-x and x. Only x is supposed to get pushed to remote eventually.

Work on the patch to be.

Create the 1 commit for remote

So no need for squashing.

• drupal
• planet
• planet drupal
• git
• symfony

You’ve likely heard of Batman and Robin, Simon and Garfunkel, Henrik and Daniel. But today, I’d like to pay tribute to a dynamic duo that deserves to be recognized with the likes of the aforementioned: Drupal and HTML5.

Like most dynamic duos, Drupal and HTML5 are great standalones. But together? Potential for magic.

Drupal, for starters, is a powerful engine. Its very thin client architecture allows performance to be isolated to the server and contains everything within its structure. Almost everything lives server side, and therefore the server does most of the work. However, every time the page loads, the client must then make a request to the server for each new set of HTML, forcing the server to repeat the same process over and over.

Contrastingly, HTML5 builds and runs everything client side, going back to the server only when necessary. This significantly reduces the lag from the server. And in a world now dominated by smartphones and tablets and their varying development platforms and languages; the case for HTML5, supported by almost all of these devices, just grows stronger. However, HTML5 still requires an engine to drive all this power.

And so, as seen in demonstrations of physics but also with love, opposites attract, and perhaps that’s why Drupal and HTML5 appear to be made to collaborate with each other. Hybrid solutions marrying the two allow Drupal to manage typical server side content management requirements, while providing HTML5 the capabilities to distribute and push off a lot of the logic to the clients, running on mobile devices in a fashion akin to native apps. Using HTML5 JavaScript frameworks such as Sproutcore alongside Drupal offer many benefits, including the MVC design pattern, content bindings, and sparse arrays.

Perhaps recognizing dynamic duo Drupal and HTML5 and what they are capable of together is the first step in leading your team to victory.

We are going to launch a free 'this is Drupal' Ipad app with a set of introductory Walkthroughs for the most popular drupal distributions to thank our sponsors for supporting our project. Want to make sure your favorite distribution ends up on the app? Cast your vote at our website.

So far the fundraising campaign for Walkthrough.it has been a great success. We've already raised 20% more than our original target from a total of 38 backers.

If you were expecting me to have a real change of heart since my last review 4 years ago, you are probably going to be disappointed. This is the least favorite option of the 3 products I am reviewing in this roundup. I will do my best to explain why.

At Mediacurrent we often get requests to compare Drupal to other platforms used for intranet sites and social business platforms (like https://dev.twitter.com/ for example). This is often referred to as “Social Business Software”, which has grown in popularity in recent years. I decided to do a round-up of a couple of the more well known platforms and compare their products to Drupal.

In this roundup we will be comparing Jive, Sharepoint and Drupal Commons. Drupal Commons is a popular distribution created by Acquia to compete with some of these other proprietary platforms.

There are many other options out there, commercial and otherwise, to compare with Drupal but I want to focus on Jive and Sharepoint for a couple of reasons. I chose Jive because it is one of the leading competitors in this space in respect to market share. Next, I chose Sharepoint because I have some history with Sharepoint. This experience dates back to when I built www.adhe.edu with Sharepoint 2007 a few years ago. I subsequently wrote this blog entry about my experience shortly after joining Mediacurrent. This roundup will also act as a refresher for those who read my original “Drupal vs. Sharepoint” blog. Yammer, which was recently bought by Microsoft and is the tool we currently use for office communication will also get some mentions throughout this article.

Apache Solr is the search technology that powers many Drupal sites. It integrates easily with Drupal's search_api contrib module, through the search_api_solr module. It's easy enough to set up a single site installation of solr on your own, but if you're serious about building Drupal sites with solr you will be building more than one site. Solr includes a "multi-core" mode, which lets you serve multiple search cores to separate sites from a single installation. Each core looks, feels, and acts like a totally separate Solr install, so you can develop as many solr sites as you like. Each core has its own configuration, data directory... the works. One core can support extensive custom geo data, and another can be completely location blind. The best part: with Solr multicore, adding a new search core to your existing stack is a trivial 5 minute installation.

You may have thought on first glance at the title that this article is about building a mobile website.

It isn't.  This article explores a slightly different angle on the topic:  Building a website using a mobile phone as your tool.

This could be useful as a form of rapid prototyping. I tried this because I wanted to see what a website looked like, at a time when I happened to be thinking about it with no desktop/laptop internet connection.

Please note, the site I wanted to build was very simple, so didn’t require custom coding. I’m not talking about a WhiteHouse.gov in this article!

TL; DR: The results of my experience was that it is very possible to create an entire Drupal website on a mobile phone. However, the user experience was poor in a number of places.

I used an existing domain name for this website, but created a new subdomain to test on. This saved the need to purchase a domain on my phone, although I suspect that wouldn’t have been a problem.

However, I did need to add the DNS “A” record for this subdomain.

My host (DomainMonster.com) does not have a specific mobile oriented website, or an Android App, but the full website worked just fine. I did already know my way around the website very well, which probably helped.

My server is powered by Aegir, which makes creating a new website easy. I use the default Aegir theme, which again, is not mobile oriented, but the standard site works well for most tasks.

The only time I struggled here, was when a popup appeared – off the screen of my mobile. I couldn’t see or click it, so had to find a different route to perform the same task.

Like most of the Drupal community, I use Drush on my server to make tasks like downloading modules quick and simple.  I had also previously set up ConnectBot on my Android phone, which enabled me to get shell access to my server (aside: Worth doing so that you can reboot if an urgent issue occurs).

This made downloading modules trivial.

Lastly, I tried to set the website up as I wanted it. This was almost all possible (all except uploading some screenshots that I wanted to do on a desktop anyway). However, this was much more hassle than I realised.

Often, navigating around the admin area of the site would take several clicks, where I’m used to quickly finding the page I need with Administration Menu.

When creating blocks, it helped me when I remembered to click the “Show Row Weights” option. This gives the possibility to reorder using dropdown selection boxes rather than drag’n’drop.

Due to wanting to upload screenshots, and the general hassle of writing content on my mobile phone, I decided in the end to leave the final configuration until later when I could work on my laptop.

As you can tell from my experiences above, it is definitely possible to create an entire website using your mobile phone (and if necessary, I could have used my time and patience to finish the website completely on my phone). However, the experience is clunky, to say the least.

I believe that Drupal 8 and Spark both offer improvements against my experience (on default Drupal 7). I plan to try these too, and if so, will write my experiences up there as well.

Have you tried creating Drupal websites on your mobile too?

Any tips and tricks that I missed?

The Views module is the most powerful tool for a Drupal developer, and so much loved that from Drupal 8 the Views module has made it's way into Drupal core. As for Drupal 7, Views is still a contributed module and not all that famous for it's performance. This blog post will look at a few ways to improve the performance of your Views in Drupal 7 by using caching.

Read the full post on Millwood Online

On Saturday, March, 23rd 2013, DrupalCampChina 2013 (announcement) has successfully taken place in Shanghai, China. As one of the organizers, I proudly announce that the Camp has :

• 100 people pre-signed up on groups.drupal.org/china.
• Up to 300 people attended one or more sessions on the day.
• Many People traveled from different cities to Shanghai, for example: Beijing, Guangzhou, Chengdu and New York City.
• Between 150 people and 200 people has sit in the Keynote speech, delivered by Forest Mars.
• 7 sessions were held; 2 sessions were conducted in English, 3 conducted in Chinese, 2 conducted with mixed English and Chinese.
• 150 DrupalChimaChina 2013 T-shirt were distributed for free.

These numbers above are astonishing, considering this camp is the first Drupal Camp specifically targeting the whole China mainland Drupal developers and users; As 6 months ago in 2012, when I started advocating the idea of a Drupal camp in China, I was telling other organizers, Drupal Association and potential sponsors that we would expect 50 to 100 people to show up! Obviously, we have over-achieved, and Drupal has grown fast! On that note, I feel writing down three short stories on the brewing process of DrupalCampChina 2013 to share and to inspire:

Collaboration with Barcamp (Techyizu)
Since January, 2011, I moved to Shanghai, I teamed up with other local Drupalers to organize monthly Drupal meetups and Drupal Happy Hours. We usually have from 10 to 30 people to attend (I noticed a trend: expats in Shanghai they more likely attend Drupal Happy Hours while local Chinese Drupal developers more likely attend well-organized meetups). In the early of 2012, at one of our Drupal meetups we discussed that maybe it would be much more fun and meaningful to hold a Drupal Camp in Shanghai, and not long after the meeting, due to amazing responses we received, we upgraded that idea to hold a Drupal Camp for the whole potential audience in China! At that time, we were expecting from 50 to 100 people to show up; and that number was already beyond the resources we had at our disposal.

Just the right organization came to mind to help our needs: Techyizu, which is a Shanghai-based volunteer-driven organization and staunch supporters of the China startup and tech community. They organize two Barcamps a year, and a few other events as well. Techyizu usually attracts around 400 people to their camps, and the team handles all the logistics such as venue, food, water, WIFI and beer. I have given presentations at previous Barcamps and realized the style of the camp is very similar to Drupal camp. So, if Drupal Camp acts as a content provider while Barcamp functions as a conference framework, that would mutually help, right? Indeed, the idea was accepted by Mark Englehart Evans at first, who is one of the organizers at Techyizu, then later on the idea was approved by the whole Techyizu team. In the end, we focused our energy on the presentations of Drupal, and left most of the logistics to Techyizu, and we were very grateful for that!

Fast forward to the conclusion of DrupalCampChina and Barcamp, as a result:

• 600 people pre-signed up for Barcamp including Drupal camp people and 800 people attended (a historical high for Techyzu as well). This became a unique opportunity for our Drupal community to show other people what is Drupal about!
• 20 organizers had participated in the organization of the event for the past 6 months.
• 336 bottles of beer and 200 cups of coffee were consumed.
• 700+ Sandwiches were delivered for free and some people were still hungry :)

On the behalf of the Shanghai Drupal Community, I thank Techyizu for their great help! On the other hand, we are also honored to bring new heights to Techyizu :) (There is an interview I did with the local media CreativeHunt.com one week before the camp took place with more details on Drupal camp and Barcamp: DrupalCamp 2013: Jingsheng Wang, by Frances Arnold)

Our story: How Community Cultivation Grant Helped Us.
As many people would agree with me that content is one of the most important things for a camp, therefore the first thing we discussed at the organization meetings were the presentations. It didn't take long before we reached a conclusion that we needed the Drupal Association's help, and specifically we needed an experienced Drupal speaker from oversea to come to our camp to give us a keynote speech, and tell us what's happening with the latest Drupal development, the events in the rest of the world or the experience of promoting Drupal in enterprise and government. I applied for the Community Cultivation Grant in October, 2012, at that time I told the Community Cultivation Grant Committee that I was expecting 100 people to show up for DrupalCampChina, and thankfully they accepted my application and issued 1500 USD towards DrupalCampChina 2013 in January, 2013.

We started looking for our candidates, by firstly posting Open Invitation for a Keynote Speaker at DrupalCampChina 2013 / 征集2013年Drupal中国营主题演讲嘉宾. By the end of Feburary, 2013, we were excited that Forest Mars, a Hypermedia Architect from New York City, decided to fly to our camp and help with the keynote speech. When the time finally approaches, Forest successfully presented Drupal, Hypermedia and the Future of the Web . His overview of the web and Drupal, and his discussion on methodology are just what we needed to present the new, the abstract and the futuristic perspective to the Chinese audience.

Multilingual Content Deliver and Drupalize new adopters
As many of us know, the most valuable thing in Drupal is the Drupal community. But this part of Drupal has not been fully understood by most people in China yet, as we are facing two big challenges: first, while almost every Chinese developers communicate using Chinese (The percentage of English Speakers in China is 0.83, by Wiki), the rest of the international Drupal community speaks English primarily. But thanks to our volunteers from Shanghai Drupal community, we made every post related to DrupalCampChina 2013 available in both Chinese and English including this article (Chinese version) and we encouraged presenters to mix with Chinese and English, and make translations in slides as much as possible. By having a camp like this, we created the opportunity for the new comers to introduce themselves in more multilingual friendly environment and the opportunity for many expats to communicate with Chinese developers face-to-face.

However, the second challenge is even greater: most Chinese developers are not familiar with Barcamp style and we are not familiar with the DoMocracy in Drupal community yet. But, at the camp, we tried our best to learn established DrupalCon/DrupalCamp styles, we discussed about the role of IRC in Drupal community, we talked about groups.drupal.org, localize.drupal.org; we organized 150 people time to introduce ourselves; we talked more about meetups, Drupal Happy Hours, patches, modules, distributions, etc. In the end, most people had positive response to participating in BarCamp style, although there are many benefits still left unknown for us to discover. Therefore, we want and need to do Drupal camps again and again!

In summary, promoting Drupal Community or cultural is a long term task, and DrupalCampChina 2013 was just beginning. We are studying fast on Drupal as well as Drupal Community. As Dries Buytaert once used a quote in his keynote: "if you want to go quickly go alone if you want to go far go together", the Chinese Drupal community has a late start, but the community is eager to catch up and go far together with the international Drupal community.

* photo credits go to Ami Sanyal
For additional photos, please go to Sina Weibo or Google+.

• 简体中文

I led a workshop for Getting Involved with Drupal and was on the panel at the Flourish! Open Source Conference last weekend. Among the questions brought up there were:

• Who are new contributors?
• How can we encourage new contributors to participate in open source projects?

In Drupal, new contributor interactions are often online only at first with just a username. We do not know someones age, their experience, where they are from, etc. Are they 12 years old, a new programmer, and new to Drupal? Are they a project manager, experienced with Drupal, and contributing for the first time? Could there be special circumstances like being dyslectic, very shy, English not their first language, etc? There are many combinations possible.

How we treat them in their first interaction can make the difference between bringing in a person to our community, or pushing them away.

Drupal uses a patch based workflow. Changes to core and contrib projects are suggested in the form of patches attached to each project's issue queue. This is nothing new.

But this is not the norm for projects that use git for version control. Normally they use a traditional git branch/fork process - issues are worked on in branches or forks, when ready a pull request is sent, when approved the code is merged.

The git workflow has a number of advantages over the patch workflow, the most notable being there is no need to re-roll patches - you just merge HEAD instead.

So given Drupal uses the patch workflow, this article shares what I've found to be a successful recipe for maximizing the features of git in the patch workflow constraints.

This recipe has several advantages, including ease of creating interdiffs.

The main body of a Drupal.org issue is its editable issue summary. Clear issue summaries are recommended for most Drupal core issues, and core maintainers can require them before an issue is considered for a commit.

We need more up-to-date summaries for Drupal 8 issues. Read on for how you can help, or start right away by updating the summary of an issue tagged with Needs issue summary update.

The summary is a concise overview of an issue's purpose and current status. Summaries can be updated collaboratively as an issue progresses. There is also a standard template for issue summaries to make them easier to read. (To update an issue summary, click on the "Edit" tab for the issue.)

• Providing a clear explanation of how to reproduce a bug or what needs to be done next to resolve an issue is the most effective way to get someone to work on it.

• Up-to-date summaries save time spent reading all of an issue's comments, especially for issues with many comments. One concise, complete summary can save literally hours of the community's time.

• Summaries save time for reviewers, and Drupal has far more patch contributors than reviewers. About 20% of Drupal 8 issues are marked "Needs review," and over 900 of these have not received a new comment in over a month. The oldest have not had updates in more than a year and a half.

• Drupal 8 core maintainers in particular need to know how an issue fits into the "big picture" of Drupal 8, especially now that we are in feature freeze. Clear, current summaries will help maintainers make decisions about which patches to accept and when.

Any Drupal core issue benefits from a clear, concise, up-to-date summary, but they are especially important for:

• Major and critical issues.
• Issues with many comments or large patches.
• Issues that introduce important architectural changes.
• Issues that have changed direction since the initial post.

• When an issue is ready for community input.
• When the summary doesn't reflect the current status.
• When the summary is unclear or doesn't answer your questions about the issue.
• When someone posts feedback on the issue that needs to be addressed.
• When an issue is tagged with Needs issue summary update, especially when a reviewer or maintainer has recently requested the update.

• The target audience is a Drupal 8 developer or maintainer who is not familiar with the particular issue or the details of the particular API.
• A concise, scannable summary is far more valuable than an essay.
• Above all, a summary should identify what change is needed and why.
• For details, see the issue summary instructions.

• Review the issue summary instructions.

• When you look at a core issue, skim the summary and see if it could use an update. (Tip: Dreditor provides an inline issue summary editor that you can use while reading the issue.)

• If you find an issue unclear, add the Needs issue summary update tag.

• If an issue summary has good information but does not use the standard template, edit it and simply insert the template headers where appropriate.

• When you review a patch, double-check that the solution described in the "Proposed resolution" section accurately reflects the patch that you reviewed.

• When you do a code review on a patch, make note of any API changes you notice. (These can be added to the "API changes" section of the summary.)

• Look for an issue tagged with Needs issue summary update, and help update the summary.

• Review and update the summary for a major or critical issue.

• Come to Core contribution mentoring and tell your mentor that you'd like to contribute to an issue summary.

• Try to contribute one issue summary update every day, and tweet about it with the #PatchADay tag.

I recently sat down at Acquia HQ with my friend and colleague, Angela "webchick" Byron. She is a Drupal core co-maintainer, book author, Drupal Association board member, public speaker, equality advocate, and all-around powerhouse contributor. Angie works with Drupal Lead, Dries Buyteart, in the Acquia Office of the CTO (OCTO): "My job is to make Drupal awesome. We figure out together what's the biggest thing holding Drupal back right now, and whatever it is, we just tackle it."

We're thrilled to announce you can now register to attend DrupalCamp Austin as well as submit your session proposals.

We are still in the process of building the full site*, but the links below will help you in the meantime:

Register to attend DrupalCamp Austin

Submit your session proposal

When: June 21-23
Where: Austin Convention Center
Price: $65

Program:

• Friday: Full-day workshops (TBA)
• Saturday: Sessions, Half-day workshops, Keynote, BoFs, after party
• Sunday: Sessions, Keynote, BoFs

*More on this soon, we'll be doing some cool things with D8

This post by Cathy Theys was previously published on GDO, but she gave us permission to repost it here. So many things in this story to love, from the multi-generational meetups to the start of Global Sprint Weekend. If you have a Drupal community initiative you want to get off the ground, check out the info on Community Cultivation Grants to see if you might qualify for funding.

Thanks, Cathy!

From its inception in 2009, Four Kitchens has been heavily involved in the planning and organizing of DrupalCamp Austin, along with other Austin Drupal leaders like Astonish Design, Volacci, and Entermedia (to name a few).

It seemed like in 2011, we had hit our stride: Angela Byron was keynoting, we produced one of the first responsive DrupalCamp websites, introduced full-day training to the camp, and finally found a cool Druplicon mascot (we love you, hipster Druplicon).

Then in 2012, things came to a halt. Maybe the Mayans meant to predict the end of DrupalCamp Austin and not the end of the world. Okay, maybe not. But 2012 was definitely a turning point in the Austin event landscape with the inaugurating Formula 1 race at Circuit of the Americas. While CoA is great for the Austin economy, it was bad news for us and our camp.

Every hotel in Austin and the metro area was booked solid for the whole month of November, which is when we usually host our camp. We didn’t want to put on a camp that would be inaccessible to folks from out of town, especially our friends in Dallas and Houston; so we decided to cancel the camp as a result. (Although we did have an awesome one-day event aptly called Drupal Day Austin.)

We’re no Die Hard 3, but we are back with a vengeance in 2013! (Sam Jackson may even make an appearance at this year’s camp. Okay, no. Don’t get your hopes up.)

Here’s what’s new this year:

• 3 days instead of 2: The camp will start on Friday with full-day trainings and a one-day web leadership summit open to anyone who works in the web (and free to attend!).
• Full-day trainings take place on Friday so you can enjoy 2 days of camp, uninterrupted.
• Half-day trainings will still be available the Saturday of the camp for those who prefer half-day training, and don’t mind missing half a day of camp talks.
• Tech trivia Friday! Start off the camp with a fun trivia night and test your overall geeky knowledge.
• We’re downtown, baby! Our venue this year is the Austin Convention Center, conveniently located right by the metro rail and near watering holes like Easy Tiger and The Gingerman (the unofficial post-meetup spot in Austin).

And now for the fun part!

Volunteer: Email us at volunteer (at) drupalcampaustin.org and let us know what you’re interested in.
Sponsor: Email me personally at cecy (at) fourkitchens.com to talk about sponsorship opportunities.
Train: Get in touch with Diana Dupuis at Astonish Design if you have any ideas or questions about training.

The best way to stay up-to-date is to follow @DrupalATX on Twitter or Facebook.

We hope to see you there!

–
Photo credit: jenniferconley on Flickr.

Voting is now open for the 2013 Blue Drop Awards. Lullabot is honored to have helped design and build three sites nominated for Blue Drop Awards this year in three different categories. Tech Guy Labs has been nominated for Best Media Website, PAC-12 Videos for Best Sports Website and Tizen.org Best Associate Website.