Feed aggregator

Before doing any changes to your web site, the first thing to figure out are your goals. As a web development shop, we focus on building web sites that create measurable value for our customers, aligned with their goals.

Some common goals:

• Help me close more sales from people who I send to my web site (brochure/information)
• Bring me new customers (online marketing, SEO)
• Help me manage sales leads (CRM)
• Increase sales (e-commerce)

How you should revamp your site completely depends upon which of those goals (or whatever other goals you may have) are most important for your business at the current time.

Drupal PlanetGoalsData Visualization

The new Twitter 1.1 API kicked in recently, which meant a new cycle of maintenance for anyone consuming their data programmatically. My own Feeds + Views demo site streams #drupal, using Feeds and complementary modules.

read more

This series outlines our project process through the lens of our development of the new 4SiteStudios.com. In this post, we will discuss our process for architecting a content management solution for a client.

In the technical plan, we take the content plan, wireframes, and our documentation from the discovery phase, and begin to make decisions about how we're going to actually implement the site in Drupal. What content types do we need? What contrib modules do we need to install? Do all of those modules play nicely together? What custom modules do we need to write? What views do we need to build? How do we know when a feature is done, and how do we test to make sure?

The first thing we do is break all the main functionality of the site down into user stories. These are simple statements that describe tasks that different types of users should be able to perform. For example, "A visitor to the site can see a list of upcoming events," or "An authenticated user can register for an event." These are intentionally kept simple, so that we keep the focus on the problem we're trying to solve, rather than the way we're planning to solve it.

Next, we write a description for each user story. Descriptions are still simple and user-focused, but they go into a bit more detail. If the story is that the user should be able to fill out a form, the description tells us what form fields the user should see on the screen, and what she should see after she submits the form. These descriptions help guide us as we're designing solutions, but they also tell our developers (and more importantly, our QA testers) what "done" means. Occasionally as we're writing descriptions we'll discover additional use cases that weren't captured in the original wireframes, and we'll update the wireframes to match.

Finally, we briefly describe the solution we're proposing for each user story. Do we need to create a new content type? Build a view? Install a module? The solutions usually start fairly simply in the technical plan, but once we import the stories into our project tracking system, Pivotal Tracker, we'll start adding much more detail, including acceptance criteria and QA testing instructions. For any particular story, we usually write these detailed specs during the sprint before we actually start development on that story.

For the new 4SiteStudios.com site, most of our stories are pretty straightforward. We probably could have even built the site in Wordpress, but why would we want to do that? :) And since we're building the new site on top of our install profile, 4Site Hub, a lot of user stories (particularly stories for content editors and administrators) were already addressed in the tech plan for that project. As we go through the development phase, we'll test the 4Site Hub stories too, to make sure we haven't introduced any regressions.

The second tab of the technical plan outlines all of the content types we'll need on the site. We already started this work in the content plan, but the tech plan goes into much more detail. We capture all of the fields we need, the field type for each, whether it's required, and how it will be displayed. If the content type is based on one in 4Site Hub, we describe how we'll capture the changes—will we create a feature override, or just build a new feature? The third tab captures similar information for our taxonomy vocabularies. The final tab captures all of the modules, features, and third-party libraries we'll need for the project. For Hub-based projects, we always look for features and modules that are part of the standard installation that can be disabled.

Now that we have a plan for how we're going to proceed, we're ready to spin up a development environment and start building!

If you want to get a look at the tech plan for our new website, look below.

Technology Plan for new 4SiteStudios.com from 4sitestudios

It's the DrupalCon Portland Floor Show! I went around the exhibitors' area and through the halls of the Oregon Convention Center asking two vital questions to our community: What is your favorite thing about Drupal? Why should other people come to DrupalCon?

drupalcon_portland_floorshow_final.mp3

Let me preface this blog by stating the following facts about myself. I come from advertising. This was my first Drupalcon. I was attending on a severely sprained ankle and had left my fiancé (now wife) at home just two weeks before our wedding. Needless to say on my shaky flight to a city that is stuck with a perpetual rain cloud over it, my mind was not focused on Drupal.

A month or so ago the Drupalize.Me team started a discussion on how to start helping others learn Drupal 8. We knew Drupal 8 wasn't ready for our typical curriculum and video production process, but thought you would be interested to learn along with us about Drupal 8 as it continues to evolve. This blog post is the kick off to that series. As we stated in a recent podcast where we announced this idea, we need everyone to understand that the things we discuss are still in development and could change, or even be removed from D8 altogether.

read more

This series outlines our project process through the lens of our development of the new 4SiteStudios.com. In this post, we will discuss our process for developing a creative direction for a client.

I’m coming up with a design for the new 4Site website following the same process and with the same deliverables as our clients’ sites. That means starting out with some conversations with the decision-makers (“the boss” - aka Heming - in this case) to figure out what kind of personality the company has and what kind of customers/clients/visitors the site will have. Because I’m so close to 4Site, I see so many design possibilities that it can become overwhelming to choose just one! This is where the reviews and multi-stage deliverables come into play. Where they help clients decide what design direction they’d like, the 4Site design deliverables help me and my team discuss internally what works and what can be improved.

I start out with style tiles to reflect a few different ideas based off of my discussions with the team, then create a component style guide to reflect all the changes we want to see and get an idea of what some individual pieces of the site  will look like. This part is a narrowing-down of the style tile directions, but often I need to combine elements from several tiles, which poses a challenge to create balance and proper visual hierarchy, and can often take longer than the style tile stage.

With the 4Site redesign, I spoke with Heming initially to figure out how we’d like to portray ourselves as a company. We had just released our new logo, which is a minimalist version of our old logo, to be more modern and versatile. That now needs to be paired with the friendly, eclectic, historic feel of Columbia Heights, our neighborhood. Getting the clean, minimalist technology direction to mesh well with the artsy, hip aesthetic was definitely challenging. The first round of design (the style tiles) covered the gamut of ‘just clean,’ ‘clean and eclectic,’ and ‘just eclectic.’ Then, going into the component style guide after getting everyones thoughts and feedback, I had to come up with the real combo.  I’m pretty sure I had a few dreams about it, and every time I walked up 14th to the office I’d see something new to include in the design. It took a long time to come up with which elements should reflect which parts of our company, as well as showcase our work, but in the end we all were very happy with the results.

The component style guide wound up being a reflection of who we are as a company, and the type of work we do. We work primarily with non-profits and like to think of ourselves as “do-gooders,” so we have a lot of inviting textures. Our roots are as a design and creative services company, so we have some playful fonts here and there. And finally, because we’re pretty tech-savvy (geeky!), and are on the cutting-edge of web design and development, we have a clean, open, airy feel. A few Victorian accents add the Columbia Heights feel (since the modern elements are already covered with the other aesthetics). And... voila! There’s our concept for the new 4Site website theme.

Our style tiles and component style guide are working documents that inform our design mockups. Below is the component style guide for the new website. Let us know what you think!

New 4SiteStudios.com Component Style Guide from 4sitestudios

Thanks to everyone who stopped by the Commerce Village at DrupalCon Portland to drink, see demos, and meet the folks who make Drupal Commerce thrive. We had some great sessions, too, both in our Village Square and in the main conference.

If you couldn't make it, don't worry: we recorded all the sessions and have posted them to our site. And although there were some only-at-DrupalCon opportunities, home-schooled Drupalistas won't remain empty-handed! Read on....

View all Sessions

It takes a (Commerce) Village

First we once again want to thank our attending Service Providers for making DrupalCon — and Drupal Commerce itself — such a success. The feedback throughout the village from attendees was amazing. Everyone told us they learned a lot from each of our providers and they, in turn, got to meet so many of their userbase face-to-face... and introduce potential users to their solutions.

...and did you get to see Commerce Platform?

The big Commerce Guys news from the show was Commerce Platform, our new cloud-based hosting solution for smarter development.

You can see what's coming by checking out Damien and Robert's Commerce Platform demo and then request to be part of the private beta. Platform's unique architecture gives site-builders unprecedented flexibility to create and control their sites. (Believe us, you'll want to watch the demo.)

… and did you talk to us about our *New* Delivery Partner Program?

There are lots of opportunities for creating and running Drupal Commerce sites, and we need your help!

Mike O'Connor talked about our Drupal Commerce Delivery Partner Program, and we had a chance to speak to many of you. But if you're an experienced Drupal development company and have an interest in growing your eCommerce practice... and you're not yet on our list, Get in Touch with us to start getting the leads, co-marketing, and support you need to expand into this fast-growing field.

There's always something exciting happening at Commerce Guys. As always, stay in touch with us through Twitter, Facebook, or join our mailing list. See you in Prague in September... and in Austin for DrupalCon 2014

Tags: drupalcon portlandcommerce villagePlanet Drupal

Topic: Drupal

Drupal Developer Days is a great tradition in Europe to provide space for developers and site builders to get together in the summer. After such prior locations as Barcelona and Brussels, the Drupal Developer Days is coming to Dublin this year!

The conference program includes great sessions on security, project management, automation, multilingual, mapping, REST, continuous integration and so on! Lots of opportunities to learn about Drupal and the entry ticket is only €25.

The event is also ideally timed to coincide with the last days before Drupal 8's API freeze. There is a whole weeklong sprint included for those who want to work on solving major and critical issues as well as any patches still viable before API freeze. If you are still to take your first steps to contribute, the Community Tools Workshop is for you to delve into giving back.

There will be a recruitment event there too, so when you register make sure to say that you're looking for a job. Acquia will be there so come talk with us about the work we do if you are interested in joining!

To revert all features ..

drush fra -y drush cc all

To revert a specific feature..

drush fr -y feature drush cc all

If a feature has been overridden, it can be reverted. This means that the version in the database is destroyed and the version defined in code, in your feature, is used.

If you're deploying a feature to one of you servers you would ..

git pull drush fra -y drush cc all

To update your feature ..

drush fu -y feature drush cc all

Updating an overridden feature will ensure that the version of the feature defined in code is made to match the version stored in the database.

A feature is overridden when a user uses the UI to make configuration changes. These changes are stored in the database, and override what is stored in code.

Tags: featuredrushdrupalplanet Tweet

Completed Drupal site or project URL:  http://Georgia.gov

One of the popular functionalities we build at Propeople Drupal Agency are slideshows. Thanks to views_slideshow module it’s a very easy task to implement. Sometimes slideshows contain embedded YouTube videos. And thanks to the great Media module, it is not a very hard task to do either.

The only problem we face is when the user clicks play – the slideshow still switches to the next slide. This article addresses this problem.

We have found a nice example of reacting on YouTube player play / pause.

In order to use this example we will need to override media-youtube-video template as we will need to change the output.

In order to accomplish this we can create our own template and add it to suggestions in case this field is displayed in a view with slideshow.

<?php
/**
* Implements hook_theme().
*/
function mymodule_theme() {
return array(
'mymodule_media_youtube_video' => array(
'variables' => array('uri' => NULL, 'options' => array()),
'template' => 'mymodule-media-youtube-video',
),
);
}

/**
* Preprocess function for template media-youtube-video.tpl.php
*/
function mymodule_preprocess_media_youtube_video(&$variables) {
if (!_mymodule_search_backtrace('template_preprocess_views_view_field')) {
return;
}

$views_id = drupal_static('mymodule_preprocess_views_view_field');
if (empty($views_id)) {
return;
}

drupal_add_js('http://www.youtube.com/player_api');
drupal_add_js(drupal_get_path('module', 'mymodule') . '/mymodule.js');

$variables['theme_hook_suggestions'] = array('mymodule_media_youtube_video');

$variables['iframe_id'] = 'media-youtube-' . $variables['id'];
$variables['views_id'] = $views_id;
}
?>

The mymodule_preprocess_media_youtube_video() function does some tricks:

1. It checks whether rendering of media file is done inside the view. For this we check the backtrace for template_preprocess_views_view_field function. This is pretty hacky but I haven't found a nicer way to check. It is needed so we do not modify output if for example media file displayed in the node.

2. It loads $views_id from static variable. This is another pretty ugly hack, but it is needed for passing a variable to javascript (so we know what slideshow to pause / start). Also when we prepare that variable we check if a view actually uses slideshow style.

I would love to hear if you know a better workaround for these two hacks. Write in the comment form below or on our social profiles: Twitter, Facebook.

The function where we prepare the view id:

<?php
/**
* Preprocess function for views-view-field.tpl.php.
*
* Statically cache view information to pass to mymodule.js so we know what slideshow to pause.
*/
function mymodule_preprocess_views_view_field(&$variables) {
$views_slideshow_id = &drupal_static(__FUNCTION__);
$views_slideshow_id = '';

$view = $variables['view'];
if ($view->style_plugin->plugin_name == 'slideshow') {
$views_slideshow_id = $view->name . '-' . $view->current_display;
}
}
?>

Now the template file:

<div class="<?php print $classes; ?> media-youtube-<?php print $id; ?>">
<iframe id="<?php print $iframe_id; ?>"
class="media-youtube-player media-youtube-mymodule" <?php print $api_id_attribute; ?>
width="<?php print $width; ?>"
height="<?php print $height; ?>"
title="<?php print $title; ?>"
src="<?php print $url; ?>"
frameborder="0"
allowfullscreen
data-iframe_id='<?php print $iframe_id; ?>'
data-video_id='<?php print $video_id; ?>'
data-views_id='<?php print $views_id; ?>'
>
<?php print $alternative_content; ?></iframe>
</div>

As you can see, we are passing iframe_id, video_id and views_id as attributes of the iframe so javascript can use them.

And the last piece is the javascript itself:

<javascript>
(function ($) {
Drupal.behaviors.mymodule = {
attach: function (context) {
$('.media-youtube-mymodule').once('mymodule').load(function() {
iframe_id = $(this).data('iframe_id');
video_id = $(this).data('video_id');
views_id = $(this).data('views_id');

// Example of interacting with YouTube API's
//@link http://jsfiddle.net/masiha/4mEDR/
var mymodule_player = new YT.Player(iframe_id, {
videoId: video_id,
events: {
'onStateChange': function (event) {
if (event.data == YT.PlayerState.PLAYING) {
Drupal.viewsSlideshow.action({
"action": 'pause',
"slideshowID": views_id,
"force": true
});
}
else if (event.data == YT.PlayerState.PAUSED) {
Drupal.viewsSlideshow.action({
"action": 'play',
"slideshowID": views_id,
"force": true
});
}
}
}
});
});
}
};
})(jQuery);
</javascript>

The full code of this drupal module can be downloaded here.

Now, after enabling this module, if you build a slideshow with media youtube files it should apply this functionality automatically.

Enjoy.

Language English Tags: DrupalDevelopmentTutorialsCheck this option to include this post in Planet Drupal aggregator: planet

I created a bare-bones content filter to add musical notation to Drupal content, using the VexFlow / VexTab music engraving library. Here's a little sample, also showing my fork of the original library to handle basic Arabic musical notation (quarter tones and special scales):

tabstave notation=true tablature=false clef=treble key=Rast notes C/4 D/4 E%@/4 F/4 | G/4 A/4 B%@/4 C/5

Feel free to fiddle with the music snippet above.

read more

In this lesson we're going to talk about taxonomy. In my experience it's another one of those things in Drupal that uses unfortunate terminology and ends up confusing new users. But the truth is, taxonomy is pretty simple to get your head around and will be a huge help in your site building efforts.

The Lowdown on this Tutorial

We're going to break this topic down by first explaining the concepts. Next we'll take a brief tour of where Drupal keeps all the knobs and switches for managing taxonomy and then we'll wrap it up by discussing some very useful modules that extend the built-in functionality of the Taxonomy module.

If you've been keeping up with this tutorial series, you'll know it uses my free installation profile, Foundation, for the examples. Using Foundation along with the lessons can save some time in getting up to speed on this topic. It includes several pre-configured modules and views related to the topic of taxonomy that serve as good examples of how it can help with your site building. 

Taxonomy Defined

Let's begin by defining taxonomy. You may remember it from your high school biology class as a systematic way of categorizing things. In biology, the classifications involve plants and animals, but in Drupal the categories are for your content.

 

If you're coming from WordPress, this system is very similar to the Categories you'll find in that CMS. In Drupal, however, it's a little more complex - big surprise, right? That's OK. Like I said, it's not that bad. 

To really understand Drupal's taxonomy or classification system, we have to get a handle on both vocabularies and terms. Vocabularies are really just categories. That's all they are. Terms are simply the items that go inside a vocabulary. Let's look a little deeper at terms and vocabularies using an example.

A Hypothetical Vocabulary

By default, Drupal comes with one vocabulary defined - Tags. It's a generic, default way to start classifying your content. But let's say we have a site that provides information about the nutritional content of various foods. We'll probably want to create a new vocabulary (aka category) that we'll call Foods.

Under that vocabulary we'll start adding some terms to break our content down into more specific classifications - terms like Dairy, Grains, Poultry, Vegetables and Fruits. As you might guess, these will end up being not only terms themselves, but also the headings for sub-categories as we continue drilling down to more specific terms. For example, under Fruits we might have Apples, Bananas, etc. You can see that it won't take long before we have a very extensive hierarchy with hundreds, or even thousands, of terms.

Of course the point of all this categorization is to make it easier to sort our content and expose how each node is related to the others. If you think back to the previous lessons on Views, you'll start seeing how these two modules - Taxonomy and Views - work hand-in-glove to provide a way of creating and displaying content relationships in a relatively simple way.

How to Use Taxonomy

Let's kick this section off by looking at where we create and manage our vocabularies and terms. In Drupal 7, under Structure > Taxonomy you'll find a screen like the one below.

You'll see that in this screenshot from Foundation, we have two vocabularies, the default Tags, which I've chosen to use as the blog categories, and a second titled, Utility tags. This second vocabulary/category is used to mark content as special in some way - for example, to be featured on the home page.

I won't go through the steps of creating vocabularies or terms because it's very simple and I'm certain you can handle that without much trouble. But what we are going to look at is how we can make our new vocabularies available for use when creating content. You see, when you create a new vocabulary, it isn't automatically available on your Add content form. We have to add it manually.

To do this, we'll need to add a field to the content types where we want to be able to use the vocabulary. If you're using Foundation, head to Structure > Content Types and then select Manage fields under the Article content type. You'll see something similar to the image below.

Note the big red arrow. What you see is that I've added a field to my content type. It's a term reference and it associates the vocabulary Utility tags with the content type. In this case it allows me to tag an article as one that should be added to the home page (via a view).

But if we return to the example of a Foods vocabulary, this is where we could add it as well. We would simply add a new field and under field type, select Term reference and then set the desired widget (select list, checkboxes, etc.). After we click save, we'll be prompted for the vocabulary name and some default settings for the field.

After we've done this, we'll be able to tag our content with the terms we've defined when we're creating or editing the page. It's pretty simple, but if you want your users to be able to see the vocabulary terms on the page (so they might click them to view related content), we're not quite finished.

Go back to Structure > Content Types and then select Manage display under the Article content type. You'll see something similar to the image below.

You'll notice that in this case we have our Utility tags hidden from our site's visitors. But in the case of our hypothetical Foods vocabulary, we'd want to make sure it was displaying so that our site's visitors could use it to find and perhaps sort related content.

If this was what we wanted to do, I would also recommend enabling the Taxonomy term view (included by default with Views) and customizing the display of the pages that site visitors will see when they click on a taxonomy term. It would be in this view where you might expose a dropdown to your users that would let them easily sort through the content associated with the various terms you've defined.

Related Modules

That wasn't so bad, was it? It won't be long before you'll want to do all sorts of things with taxonomy and below are a few modules that will help.

Taxonomy Menu

This module will allow you to turn your vocabularies into menus. In my experience, the module works great so long as you don't try to disable any menu items. I've always had disabled items get re-added after cron runs, but otherwise no problems.

Tagadelic

You know those tag clouds you've seen on some sites? This module is one way you can do that with Drupal.

Taxonomy Breadcrumb

In the example we used in this tutorial, we saw how quickly you can create a deep vocabulary structure. The Taxonomy Breadcrumb module is a useful way of helping your users keep track of where they are.

The Rest...

Finally I'll leave you with the full list of taxonomy related modules - only 372 of them for you to sort through! Gotta love Drupal, huh? 

That's it for this lesson. We're a bit more than a fifth of the way through this series. Stay up to date via the series RSS feed or by subscribing to email updates for the blog. If you'd like to comment on anything in this lesson, you can do so on this discussion thread.

Affectionately known as "Yoda" by his cohorts, author Rick Nashleanas is the global program lead, a.k.a. global team manager, a.k.a. chief cat herder for DrupalCon. Rick was the local content lead for DrupalCon Denver and was tapped to volunteer his time to give continuity to the content-side of DrupalCon. 

The way that a DrupalCon comes together is similar to how releases of Drupal are produced by the community. Passionate experts in their subject matter areas volunteer tirelessly to make each DrupalCon grow and exceed the expectations of the past.

These volunteers range from the Drupal Association board who gives strategic direction to individuals who step up to staff the registration tables. All are equally important because without everyone’s help, DrupalCon wouldn’t be what they are today.

There are many aspects to putting on an event as large as a DrupalCon: logistics, sprints, social, core conversations and much more. My experience has been to help shepherd the process of the selecting content of DrupalCon.

My role came about as we, as a community, found we were making the same mistakes with DrupalCon over and over again. There was no corporate memory; we were not learning from our mistakes. (Like all of us, we still make mistakes. We just make NEW mistakes.)

I recruit and “lead” a group of volunteer subject matter experts called Global Track Chairs, e.g. globals. I put lead in parentheses because this global talent pool often leads ME! With a couple changes in our cadre of globals, I wanted to take this opportunity to explain the organization of content selection in DrupalCon and give credit to these globals for their tireless work.

When a DrupalCon starts to come together, a local team is assembled to take the primary roles for a number of areas. There is often an overall project lead for the DrupalCon and there is a local content lead. There are five standing tracks that appear in all DrupalCona:

• Site Building
• Business & Strategy
• Coding & Development
• Frontend
• DevOps

We have had a DevOps track in Munich and Portland. Starting in Prague, DevOps is now one of our standing tracks.

You’ll notice that the Community track is missing from this list. Community is absolutely essential to the Drupal project, but the Community track has been chronically under attended. The folks who were active in the community were presenting or needed in other sessions. Folks who were not yet involved with the Drupal community shyed away from attending these sessions.

Instead, we will be organizing a Community Summit on the Monday before DrupalCon Prague. Addi Berry will be spearheading that effort.

Besides these standing tracks, the local community often comes up with additional track(s) that enhance the overall theme of the DrupalCon.

From the local community, a local track chair is selected for each track. The local track chair is the operational lead for definition of the track description and session selection.

Before we had globals, the locals were on their own to do what they thought was best for the conference, often with minimal information about the track history at DrupalCon. Enter the globals.

The globals are volunteers who are subject matter experts, had previously been a local track chair for a DrupalCon, and are passionate about their area of expertise and DrupalCons. When you read “passionate”, translate that into “willing to spend significant time writing, recruiting, selecting and consulting”.

Globals are responsible for all DrupalCons worldwide. We have a North American global and a European global for each standing track. The North American global takes the lead for the North American DrupalCon and the European global takes the lead for the European DrupalCon.

In each track, the local and both globals weigh in to evaluate and select the sessions for their track. When you have 3 folks voting, you cannot have a tie!

When I on-board new globals, I explain that it is a great deal of work, you get no pay and no glory, people don’t know what you do and it might cause some to not like you. But they do it anyway. I’d like to recognize the great women and men who are currently serving as global track chairs: Meet the DrupalCon Global Team.

The work for the locals and the globals doesn’t start and end with site selection. This team also develops the track theme, recruits featured speakers for their track, recruits sessions on target subject areas, identifies backups and basically deals with all types of issues surrounding their specific track.

Over the years, the quantity and quality of the sessions submitted have increased, making the job of session selection more and more difficult. The dark side of content selection is that everyone is your bestest friend before you select the sessions. Afterwards, you are a hero to those that were selected and something-less-than-a-hero to everyone else.

I never meant this piece to be so long and I could double the length to talk about the details of the session selection process. Weighing known speakers vs. soliciting speakers from outside the Drupal community... How do we prevent DrupalCon from being just another big tech conference? If there is interest, perhaps I’ll write more.

The process I’ve described is actively growing and responding to the needs of the Drupal community. For every DrupalCon, we try to build on our successes and seek to fulfill the needs and desires of the ever-changing Drupal community.

As you can imagine, this whole effort takes a great deal of time on my part. Why do I do it? For the same reason that folks selflessly contribute code to Drupal. Not only is the technology great, the the people in the Drupal community are a delight.

 

Personal blog tags: drupalconcommunity

The way that a DrupalCon comes together is similar to how releases of Drupal are produced by the community. Passionate experts in their subject matter areas volunteer tirelessly to make each DrupalCon grow and exceed the expectations of the past.

Personal blog tags: drupalconcommunity

This series outlines our project process  through the lens of our development of the new 4SiteStudios.com. In this post, we will discuss our process for developing an user experience for our new website.

As we have been planning the new 4SiteStudios.com over the past few weeks, we have followed our typical project process. After I developed the content plan for the new website, I dove right into developing wireframes, taking into consideration things like messaging hierarchy, information architecture, content models, modern design trends, and the lot.

In my mind, our new website is a framework. We are putting into place a foundation to build a great digital experience that can be a showcase to our clients of how we work and how awesome we are at what we do. The site will be a conversion machine. But, it will take time and learning from user behavior to get there. So, we need to start simple.

My goal is to present visitors, with as little content as possible, the following in order of priority:

1. The work we have done (As we say in the agency world: “The work sells itself.”)

2. The spectrum of services we offer

3. Who we are as a company

4. Our thought leadership around creative content and user engagement

If you take a look at the user personas in our content strategy, you will see that our target audiences are looking to make a quick decision about hiring us. They will visit our website to look at our portfolio, get a sense of the services we offer, and maybe read some blog posts or other resources. We need to give the user what they are looking for quickly, with minimal barrier to entry.

Wireframing our New Website

This was a collaborative process...as much as we could make it. I brainstormed approaches and ideas with John and Alexis almost daily. I would have informal powwows with them to get their thoughts on how to structure content regions and get feedback on the wireframes as I was designing them. We whiteboarded, drew out ideas on napkins,, and debated a lot. In the end, we made Jeff Gothelf proud - we were lean.

The direction I took with the homepage was a stacked pane approach, as seen with many modern websites. It made sense for what we wanted to accomplish - create very distinct regions, each communicating a key message.  

Since we don’t have, nor can we produce,  a lot of content for the new website, I made each top-level navigation item a distinct landing page, and each subpage under it a defined region within the landing page. I then used conversational headers and intro text to tie these regions together into a narrative. With our new brand, we want to be more conversational with our content, so this approach makes sense for us.

I am a big fan of repeating patterns within websites so users can intuitively know how to navigate through content. Aside from our main navigation, Sliders are used consistently throughout the website to allow users to scroll through pages where there is content they will want to consume in isolation, such as a service descriptions. Exposed dropdown filters are used to allow users to easily find content within large groupings, like our portfolio and “Insights” page. Galleries will be displayed using a masonry layout, and listings of content in a grid layout.

If you read my last post on the content strategy for the website, you know that one of our major goals is to increase leads generated through the website. You will see webforms consistently incorporated throughout subpages on the new website where we describe what we do and products we have developed. That black circle that appears in the upper right-hand corner of the website will follow people as they scroll down a page. We need to make it easy for you to contact us about your next project, right?

The user experience is not complex. We want to keep the new website simple and clean; prioritize visual communication over written content (with the exception of our thought leadership content); and build a conversion machine. We will be improving the website over time, testing out landing pages and improving the design and copy based on user need, so we did not want to over-engineer anything.

The Review Process

Now, I know I make the process of creating the user experience sound like it was easy, but it was kind of painful. Creating a content strategy isn’t hard - much of it is conceptual and you don’t know what you get until you start building it. People respond more to visual queues, so the amount of feedback on a project increases exponentially the more people get to see what a website is going to look like.

Although wireframes are meant to communicate content structure and page layout, people easily get hung up on the details.

“Can we change that word to {blank}?”

“Are we going to have a slideshow on the homepage?”

“It would be REALLY COOL if {blank} did {blank}?”

You have probably heard at least one of those questions before...

It took work to get our team’s consensus on the wireframes. The key was to make people feel as though their feedback was important,, but allow them to give “just enough” feedback to gather the requirements you need and build buy-in amongst your stakeholders. Perfection is the enemy of good.

Setting parameters around what I needed feedback on and how long people had to provide their feedback was extremely helpful. Changes and feedback at the end of the process were minimal because I spoke with people throughout the process, allowing them to give feedback along the way.

It is also important to stress to people that project planning is an ongoing process. Just because you reach a point where you stop collecting feedback on wireframes doesn’t mean changes cannot be made at a later time. Planning documents should be living documents that are updated throughout the development process as requirements change.

Things I would have done differently

Looking back on the process, I feel like I spent too much time on the wireframes. Part of the challenge with wireframes, as with design mockups, is that people cannot easily visualize how things will look and behave in the browser. Spending hours making really nice, static wireframes is counterproductive. It won’t allow people to interact with the concept and get a true sense of the functionality. The feedback you receive will be incomplete because the experience will be incomplete in the mind of the reviewer.

There is an argument to be made for high-fidelity wireframes. Interactive wireframes and prototypes communicate function well, but not form. There needs to be a balance. The compromise for me is “mid-fidelity wireframes” - wireframes that include just enough design aesthetic so the viewer gets a sense of the design page layout and form, but does not dictate the design direction.

We have already begun to refine our process to incorporate interactive wireframes and/or prototyping. There are a few ways to approach this, and we are planning to either create interactive wireframes within Mockflow, our preferred wireframing tool, or go right into prototyping using Drupal, depending on the project.

Take a look at the wireframes for our new website below and let us know what you think.

New 4SiteStudios.com Wireframes from 4sitestudios

This is little introduction into one of the simpler, and more user-friendly ways of controlling spam in Drupal (as opposed to other also-helpful methods, like Mollom, CAPTCHA, etc.).

The Honeypot Method
Honeypot is aptly named because, just like Pooh bear is drawn towards honey jars, spam bots are drawn towards form fields—especially form fields they think will give them the ability to link back to their own websites. So, the Honeypot method basically inserts a hidden form field to Drupal (or other) forms with a field name like 'homepage' (you can set it to whatever you want). End users don't see the field, so they don't fill it out. But spam bots (usually using prewritten scripts) do see the field (usually), and add something to it. The Honeypot module detects this and blocks the form submission if there's something in the field.

Additionally, the Honeypot module adds in a timestamp-based deterrent. Usually, forms take at least a few seconds to fill out when a human is entering data into them—especially surveys, user registration forms, etc. Spam bots try to fill out as many forms as they can in as little time as possible, so they will often fill out a form within a couple seconds at most. The Honeypot module requires at least 5 seconds to pass (by default - you can adjust this too!) before a form can be submitted.

The Honeypot + timestamp form protection method is a very good defense against spam bots, but not so good against actual humans who fill out forms for spammers although there are now some ways you can configure the module to deter 'real' spammers; see honeypot.api.php). If you start having serious spam problems, you might need to add in Mollom or another more intelligent spam prevention service to the mix. The greatest advantage of the Honeypot method is that the user is given no extra obstacles to completing a form. In my opinion, it's the most user-friendly way of preventing spam, even if it's not the most effective in every situation.

Other Niceties
You can also bypass the Honeypot protection for certain user roles—say, for instance, site administrators, who just might be able to fill out a form in less than 5 seconds—and you can set which forms on which Honeypot protection will be enabled. You can also tell Honeypot to protect all forms on the site. Finally, you can use honeypot protection in any of your own forms by simply including a little code snippet inside your modules hook_form_alter.

honeypot_add_form_protection($form, $form_state, array('honeypot', 'time_restriction')); Tags: spamdrupalplanet Tweet

By now everyone hopefully made it safely home from DrupalCon (if you're still there, it ended more than two weeks ago so you might want to head home), and while the dust settles we wanted to say thanks to all who helped make DrupalCon Portland a success, and also share some highlights from Lullabot.

The Lullabot Party

By now everyone hopefully made it safely home from DrupalCon (if you're still there, it ended more than two weeks ago so you might want to head home), and while the dust settles we wanted to say thanks to all who helped make DrupalCon Portland a success, and also share some highlights from Lullabot.

The Lullabot Party