Acquia News Feed

Syndicate content
Updated: 1 hour 35 min ago

Why Open Source Is Driving Digital Transformation in Government

6 July 2015 - 9:00pm

“Change.” That’s the word that best describes today’s digital world. Since 1991, internet users have grown from a handful of researchers to nearly 3 billion globally. Along the way, how we access and use digital information has changed as well. Government organizations, like the rest of society, are under increasing pressure to adapt to this rapid pace of change.

Today’s sophisticated consumers demand dynamic, interactive experiences that help them work with–and participate in–government. To craft the digital experiences their constituents demand, governments have to adopt newer technologies. Constituents have a high benchmark for what digital experiences should be like—courtesy of their interactions with the brands and websites they love. Governments, therefore, don’t have the luxury of ignoring the digital trend.

This is where open source comes into play. Open source software is woven deeply into the fabric of the Internet. It certainly powers much of its infrastructure: Linux and related open source operating systems power more than 65 percent of all servers in the world.

Widespread adoption has helped open source technologies become more scalable, adaptable, and affordable. These also happen to be the core traits of the technologies necessary for the digital transformation in governments. As was the case with Australia’s govCMS platform, governments don't need one website or ten, but hundreds, and likely even more in the future. A technology platform that doesn't have the features necessary to facilitate such scalability won’t help any government affect its digital transformation.

Most importantly, governments must think not in terms of five years or even ten, but decades down the line. Within just two decades of consumer Internet, we’ve seen widespread changes in the way constituents access technologies and interact with the government. They’ve evolved from using bulky desktop computers to carrying powerful computers in their pockets.
Going forward, technology will grow at an ever-increasing pace. In this scenario, highly adaptable, scalable open source software can help governments keep pace with the digital transformation.

This is the first post in a series on Open Source Government. Stay tuned for upcoming posts, where we’ll discuss how open source digital platforms enable greater citizen engagement, which open source platform is used by more .gov sites and why, and what innovative agencies are doing with open source in the market today.

Tags:  open source government
Categories: Drupal News

Front End Performance Strategy: Styles

3 July 2015 - 2:38am

The quest for improved page-load speed and website performance is constant. And it should be. The speed and responsiveness of a website have a significant impact on conversion, search engine optimization, and the digital experience in general.

In part one of this series, we established the importance of front-end optimization on performance, and discussed how properly-handled images can provide a significant boost toward that goal. In this second installment, we’ll continue our enhancements, this time by tackling CSS optimization.

We’ll consider general best practices from both a front-end developer’s and a themer’s point of view. Remember, as architects and developers, it’s up to us to inform stakeholders of the impacts of their choices, offer compromises where we can, and implement in smart and responsible ways.

Styles

Before we dive into optimizing our CSS, we need to understand how Drupal’s performance settings for aggregation work. We see developers treating this feature like a black box, turning it on without fully grokking its voodoo. Doing so misses two important strategic opportunities: 1. Controlling where styles are added in the head of our document, and 2. Regulating how many different aggregates are created.

Styles can belong to one of three groups:

  • System - Drupal core
  • Default - Styles added by modules
  • Theme - Styles added in your theme

Drupal aggregates styles from each group into a single sheet for that group, meaning you’ll see at minimum three CSS files being used for your page. Style sheets added by inclusion in a theme’s ‘.info’ file or a module’s ‘.info’ file automatically receive a ‘true’ value for the every_page flag in the options array, which wraps them into our big three aggregates.

Styles added using drupal_add_css automatically have the every_page flag set to ‘false.’ These style sheets are then combined separately, by group, forming special one-off aggregate style sheets for each page.

When using drupal_add_css, you can use the optional ‘options’ array to explicitly set the every_page flag to ‘true.’ You can also set the group it belongs to and give it a weight to move it up or down within a group.

<?php
drupal_add_css(drupal_get_path('module', 'custom-module') . '/css/custom-module.css', array('group' => CSS_DEFAULT, 'every_page' => TRUE));
?>

Style sheets added using Drupal’s attached property aren’t aggregated unless they have the every_page flag set to ‘true.’

Favoring every_page: true

Styles added with the every_page flag set to ‘false’ (CSS added via drupal_add_css without the true option, or without the option set at all, or added using the attached property) will only load on the pages that use the function that attaches, or adds, that style sheet to the page, so you have a smaller payload to build the page. However, on pages that do use the function that adds or attaches the style sheet with every_page: ‘false’, an additional HTTP request is required to build that page. The additional requests are for the one-off aggregates per group, per page.

In more cases than not, I prefer loading an additional 3kb of styling in my main aggregates that will be downloaded once and then cached locally, rather than create a new aggregate that triggers a separate HTTP request to make up for what’s not in the main aggregates.

Additionally, turning on aggregation causes Drupal to compress our style sheets, serving them Gzipped to the browser. Gzipped assets are 70%–90% smaller than their uncompressed counterparts. That’s a 500kb CSS file being transferred in a 100kb package to the browser.

Preprocessing isn’t a license for inefficiency

I love preprocessing my CSS. I use SASS, written in SCSS syntax, and often utilize Compass for its set of mixins and for compiling. But widespread adoption of preprocessing has led to compiled CSS files that tip the 1Mb limit (which is way over the average), or break the IE selector limit of 4095. Some of this can be attributed to Drupal’s notorious nesting of divs (ugly mark-up often leads to ugly CSS), but a lot of it is just really poor coding habits.

The number one culprit I’ve come across is over nesting of selectors in SASS files. People traverse the over nested DOM created by Drupal with SASS and spit out compiled CSS rules using descendant selectors that go five (sometimes even more) levels deep.

I took the above example from the SASS inception page, linked above, and cleaned it up to what it should probably be:

The result? It went from 755 bytes to 297 bytes, a 60% reduction in size. That came from just getting rid of the extra characters added by the excess selectors. Multiply the savings by the 30 partials or so, and it’s a pretty substantial savings in compiled CSS size.

Besides the size savings, the number and type of selectors directly impact the amount of time a browser takes to process your style rules. Browsers read styles from right to left, matching the rightmost “key” selector first, then working left, disqualifying items as it goes. Mozilla wrote a great efficient CSS reference years ago that is still relevant.

Conclusion

Once again we’ve demonstrated how sloppy front-end implementations can seriously hamper Drupal’s back-end magic. By favoring style sheet aggregation and reining in exuberant preprocessing, we can save the browser a lot of work.

In our next, and final, installment in this series, we’ll expand our front-end optimization strategies even further, to include scripts.

Tags:  acquia drupal planet
Categories: Drupal News

Improve Your Site’s Security by Adding Two-Factor Authentication

2 July 2015 - 3:42am

Identity theft and site compromises are all-too-common occurrences -- it seems a day rarely goes by without a news story detailing the latest batch of user passwords which have been compromised and publicly posted.

Passwords were first used in the 1960s when computers were shared among multiple people via time-sharing methods. Allowing multiple users on a single system required a way for users to prove they were who they claimed to be. As computer systems have grown more complex over the last 50 years, the same password concept has been baked into them as the core authentication method. That includes today’s Web sites, including those built using Drupal.

Why Better Protection Is Needed

Today, great lengths are taken to both protect a user’s password, and to protect users from choosing poor passwords. Drupal 7, for example, provided a major security upgrade in how passwords are stored. It also provides a visual indicator as to how complex a password is, in an attempt to describe how secure it might be.

The password_policy module is also available to enforce a matrix of requirements when a user chooses a password.

Both of these methods have helped to increase password security, but there’s still a fundamental problem. A password is simply asking a user to provide a value they know. To make this easier, the vast majority of people reuse the same password across multiple sites.

That means that no matter how well a site protects a user’s password, any other site that does a poor job could provide an attacker all they need to comprise your users’ accounts.

How Multi-Factor Authentication Works

Multi-Factor authentication is one way of solving this problem. There are three ways for a person to prove he is who he claims to be. These are known as factors and are the following:

  • Something you know - typically a password or passphrase
  • Something you have - a physical device such as a phone, ID, or keyfob
  • Something you are - biometric characteristics of the individual

Multi-factor authentication requests two or more of these factors. It makes it much more difficult for someone to impersonate a valid user. With it, if a user’s username and password were to be compromised, the attacker still wouldn’t be able to provide the user’s second form of authentication.

Here, we’ll be focusing on the most common multi-factor solution, something you know (existing password) and something you have (a cell phone).

This is the easiest method of multi-factor authentication, and is also known as two-factor authentication (TFA) because it uses two out of three factors. It’s already used by a large number of financial institutions, as well as large social websites such as Google, Facebook, and Twitter. Acquia implemented TFA for it’s users in 2014 as discussed in this blog post: Secure Acquia accounts with two-step verification and strong passwords.

How To Do It

A suite of modules are available for Drupal for multi-factor authentication. The Two-Factor Authentication module provides integration into Drupal’s existing user- and password-based authentication system. The module is built to be the base framework of any TFA solution, and so does not provide a second factor method itself. Instead the TFA Basic plugins module provides three plugins which are Google Authenticator, Trusted Device, and SMS using Twilio. TFA Basic can also be used as a guide to follow when creating custom plugins. You can find the documentation here: TFA plugin development.

You’ll find that it’s easy to protect your site and its users with TFA, and given its benefits, it’s a good idea to start now.

But before you do, check out the TFA documentation. Acquia Cloud Site Factory users can find documentation for configuring two-factor authentication for their accounts here.

For more advice, check out TFA tips from Drupal.org.

Tags:  acquia drupal planet
Categories: Drupal News

Users and Permissions, and Creating an Organization in GitHub

2 July 2015 - 12:40am

This is the fourth post in a multi-part series on using GitHub for Government. In previous posts, we’ve discussed what the public can see and do with GitHub and what Drupal code should and shouldn’t be in a public repository. In this post we’ll discuss users and permissions on organizational accounts, and in the final post, we’ll look at developer workflows.

If your developers peer review each other’s code, if you have multi-person teams and want to control roles and permissions for code access, or if your organization’s code sticks around longer than your developers, a GitHub Organization is a powerful tool made with someone like you in mind. An organization:

  • simplifies management of group-owned repositories
  • centralizes your organization’s code
  • allows you to set up roles and permissions that can be applied to different groups of users across multiple repositories
  • Simplifies Git-based workflows for teams of any size

How do you create a GitHub Organization?
Only existing GitHub users can create an organization, so to start you’ll need at least one member of your organization to have a GitHub user account. Once a user is logged in, they can create a GitHub organization by following the steps outlined here. An organization is similar to a user profile, in that it can be named and have its own code repository. There are different paid account options, which correspond to different numbers of private repositories that your organization can own. There is also a free organization option, which contains your free open source code projects, but you have to pay to work on any private projects.

Once set-up, an organization works similarly to a user account - it is paid, it can add users to the organization, and it can add users to its private projects. An organization owns the projects that are created within them, so no single user controls the fate of a project. For reference, Acquia has a GitHub organization that you can review. There you’ll see different actions taken by members of the organization, and you can also see some of the Acquia GitHub organization members.

Who controls an organization?
Organization repositories have varying levels of permissions. Authorized members of an organization can manage issues, which means they can include issues or label them, can associate issues with milestones on the agency’s project roadmaps, and can delegate issues to members of the team who are going to work on them.

Does the public see all of an organization’s members and their activity?
The short answer is no. As mentioned above, when you look at the Acquia GitHub organization page, you can see the public members listed, but there may be organization members who are not public, and therefore won’t be listed. User visibility can be toggled on and off, depending on whether a project, and user association, needs to be kept private or is something that can be shared publically. This is a helpful feature if you’re working on projects that require discretion.

User activity on public projects, however, is always public, no matter the user. But users who are private members of an organization can comment on issues as themselves, without the public knowing that they have any association with that organization. Here’s an example:

User X is a private member of Organization Y, so when you visit the Organization Y page, you won’t see them listed as a member. User X replies to an issue in the Organization Y issue queue, but appears to be a member of the public, because they have chosen to make their association with Organization Y private. There are instances, however, when User X may want to show their association with Organization Y, especially in a situation where authority is needed, and they can prove their authority by sharing their association with the organization.

In the next post in this series on GitHub for Government, we’ll discuss developers and workflows.

Tags:  github government public sector
Categories: Drupal News

One year later: the Acquia Certification Program

1 July 2015 - 9:31pm

A little over a year ago we launched the Acquia Certification Program for Drupal. We ended up the first year with close to 1,000 exams taken, which exceeded our goal of 300-600. Today, I'm pleased to announce that the Acquia Certification Program passed another major milestone with over 1,000 exams passed (not just taken).

People have debated the pros and cons of software certifications for years (including myself) so I want to give an update on our certification program and some of the lessons learned.

Acquia's certification program has been a big success. A lot of Drupal users require Acquia Certification; from the Australian government to Johnson & Johnson. We also see many of our agency partners use the program as a tool in the hiring process. While a certification exam can not guarantee someone will be great at their job (e.g. we only test for technical expertise, not for attitude), it does give a frame of reference to work from. The feedback we have heard time and again is how the Acquia Certification Program is tough, but fair; validating skills and knowledge that are important to both customers and partners.

We also made the Certification Magazine Salary Survey as having one of the most desired credentials to obtain. To be a first year program identified among certification leaders like Cisco and Red Hat speaks volumes on the respect our program has established.

Creating a global certification program is resource intensive. We've learned that it requires the commitment of a team of Drupal experts to work on each and every exam. We now have four different exams: developer, front-end specialist, backend specialist and site builder. It roughly takes 40 work days for the initial development of one exam, and about 12 to 18 work days for each exam update. We update all four of our exams several times per year. In addition to creating and maintaining the certification programs, there is also the day-to-day operations for running the program, which includes providing support to participants and ensuring the exams are in place for testing around the globe, both on-line and at test centers. However, we believe that effort is worth it, given the overall positive effect on our community.

We also learned that benefits are an important part to participants and that we need to raise the profile of someone who achieves these credentials, especially those with the new Acquia Certified Grand Master credential (those who passed all three developer exams). We have a special Grand Master Registry and look to create a platform for these Grand Masters to help share their expertise and thoughts. We do believe that if you have a Grand Master working on a project, you have a tremendous asset working in your favor.

At DrupalCon LA, the Acquia Certification Program offered a test center at the event, and we ended up having 12 new Grand Masters by the end of the conference. We saw several companies stepping up to challenge their best people to achieve Grand Master status. We plan to offer the testing at DrupalCon Barcelona, so take advantage of the convenience of the on-site test center and the opportunity to meet and talk with Peter Manijak, who developed and leads our certification efforts, myself and an Acquia Certified Grand Master or two about Acquia Certification and how it can help you in your career!

Tags:  certification training developers
Categories: Drupal News

Caching to Improve Drupal Performance: The Three Levels You Should Know

1 July 2015 - 12:07am

In our continuing mission (well, not a mission; it’s actually a blog series) to help you improve your Drupal website, let’s look at the power of caching.

In our previous post, we debunked some too common Drupal performance advice. This time we're going positive, with a simple, rock-solid strategy to get you started: caching is the single best way to improve Drupal performance without having to fiddle with code.

At the basic level, it is easy enough for a non-technical user to implement. Advanced caching techniques might require some coding experience, but for most users, basic caching alone will bring about drastic performance improvements.

Caching in Drupal happens at three separate levels: application, component, and page. Let’s review each level in detail.

Application-level caching

This is the caching capability baked right into Drupal. You won't see it in action unless you dig deep into Drupal's internal code. It is enabled by default and won't ever show older, cached pages.

With application-level caching, Drupal essentially stores cached pages separately from the site content (which goes into the database). You can't really configure this, except for telling Drupal where to save cached pages explicitly. You might see improved performance if you use Memcached on cached pages, but the effect is not big enough to warrant the effort.

Drupal stores many of its internal data and structures in efficient ways to improve frequent access when application-level caching. This isn’t information that a site visitor will see per se, but it is critical for constructing any page. Basically, the only enhancements that can be made at this level are improving where this cached information is stored, like using Memcached instead of the database.

You just need to install Drupal and let the software take care of caching at the application-level.

Component-level caching

This works on user-facing components such as blocks, panels, and views. For example, you might have a website with constantly changing content but a single block remains the same. In fact, you may have the same block spread across dozens of pages. Caching it can result in big performance improvements.

Component-level caching is usually disabled by default, though you can turn it on with some simple configuration changes. For the best results, identify blocks, panels, and views that remain the same across your site, and then cache them aggressively. You will see strong speedups for authenticated users.

Page-level caching

This is exactly what it sounds like: The entire page is cached, stored and delivered to a user. This is the most efficient type of caching. Instead of generating pages dynamically with Drupal bootstrap, your server can show static HTML pages to users instead. Site performance will improve almost immeasurably.

Page-level caching gives you a lot of room to customize. You can use any number of caching servers, including Varnish, which we use at Acquia Cloud. You can also use CDNs like Akamai, Fastly, or CloudFlare to deliver cached pages from servers close to the user's location. With CDNs, you are literally bringing your site closer to your users.

Keep in mind that forced, page-level caching works only for anonymous users by default. Fortunately, this forms the bulk of traffic to any website.

It bears repeating: Caching should be your top priority for boosting Drupal performance. By identifying and caching commonly repeated components and using a CDN at page-level, you’ll see site speed improvements that you can write home about.

Next time: How to Evaluate Drupal Modules for Performance Optimization.

Tags:  acquia drupal planet
Categories: Drupal News

Seamless Migration to Drupal 8: Make it Yours

30 June 2015 - 11:26pm

Hi there. I’m Adam from Acquia. And I want YOU to adopt Drupal 8!

I’ve been working on this for months. Last year, as an Acquia intern, I wrote the Drupal Module Upgrader to help people upgrade their code from Drupal 7 (D7) to Drupal 8 (D8). And now, again as an Acquia intern, I’m working to provide Drupal core with a robust migration path for your content and configuration from D6 and D7 to Drupal 8. I’m a full-service intern!

The good news is that Drupal core already includes the migration path from D6 to D8. The bad news is that the (arguably more important) migration path from D7 to D8 is quite incomplete, and Drupal 8 inches closer with each passing day. That’s why I want -- nay, need -- your help.

We need to get this upgrade path done.

If you want core commits with your name on them (and why wouldn’t you?), this a great way to get some, regardless of your experience level. Noob, greybeard, or somewhere in between, there is a way for you to help. (Besides, the greybeards are busy fixing critical issues.)

What’s this about?

Have you ever tried to make major changes to a Drupal site using update.php and a few update_N hooks? If you haven’t, consider yourself lucky; it’s a rapid descent into hell. Update hooks are hard to test, and any number of things can go wrong while running them. They’re not adaptable or flexible. There’s no configurability -- you just run update.php and hope for the best. And if you’ve got an enormous site with hundreds of thousands of nodes or users, you’ll be staring anxiously at that progress bar all night. So if the idea of upgrading an entire Drupal site in a single function terrifies you, congratulations: you’re sane.

No, when it comes to upgrading a full Drupal site, hook_update_N() is the wrong tool for the job. It’s only meant for making relatively minor modifications to the database. Greater complexity demands something a lot more powerful.

The Migrate API is that something. This well-known contrib module has everything you need to perform complex migrations. It can migrate content from virtually anything (WordPress, XML, CSV, or even a Drupal site) into Drupal. It’s flexible. It’s extensible. And it’s in Drupal 8 core. Okay, not quite -- the API layer has been ported into core, but the UI and extras provided by the Drupal 7 Migrate module are in a (currently sandboxed) contrib module called Migrate Plus.

Also in core is a new module called Migrate Drupal, which uses the Migrate API to provide upgrade paths from Drupal 6 and 7. This is the module that new Drupal 8 users will use to move their old content and configuration into Drupal 8.

At the time of this writing, Migrate Drupal contains a migration path for Drupal 6 to Drupal 8, and it’s robust and solid thanks to the hard work of many contributors. It was built before the Drupal 7 migration path because Drupal 6 security support will be dropped not long after Drupal 8 is released. It covers just about all bases -- it migrates your content into Drupal 8, along with your CCK fields (and their values). It also migrates your site’s configuration into Drupal 8, right down to configuration variables, field widget and formatter settings, and many other useful tidbits that together comprise a complete Drupal 6 site.

Here’s a (rather old) demo video by @benjy, one of the main developers of the Drupal 6 migration path:

Awesome, yes? I think so. Which brings me to what Migrate Drupal doesn’t yet have -- a complete upgrade path from Drupal 7 to Drupal 8. We’re absolutely going to need one. It’s critical if we’re going to get people onto Drupal 8!

This is where you come in. The Drupal 7 migration path is one of the best places to contribute to Drupal core, even at this late stage of the game. The D7 upgrade path has been mapped out in a meta-issue on drupal.org, and a large chunk of it is appropriate for novice contributors!

Working on the Migrate API involves writing migrations, which are YAML files (if you’re not familiar with YAML, the smart money says that you will pick it up in, honestly, thirty seconds flat). You’ll also write automated tests, and maybe a plugin or two -- a crucial skill when it comes to programming Drupal 8! If you’re a developer, contributing migrations is a gentle, very useful way to prepare for D8.

A very, very quick overview of how this works

Migrations are a lot simpler than they look. A migration is a piece of configuration, like a View or a site slogan. It lives in a YAML file.

Migrations have three parts: the source plugin, the processing pipeline, and the destination plugin. The source plugin is responsible for reading rows from some source, like a Drupal 7 database or a CSV file. The processing pipeline defines how each field in each row will be massaged, tweaked, and transformed into a value that is appropriate for the destination. Then the destination plugin takes the processed row and saves it somewhere -- for example, as a node or a user.

There’s more to it, of course, but that’s the gist. All migrations follow this source-process-destination flow.

id: d6_url_alias label: Drupal 6 URL aliases migration_tags: - Drupal 6 # The source plugin is an object which will read the Drupal 6 # database directly and return an iterator over the rows of the # {url_alias} table. source: plugin: d6_url_alias # Define how each field in the source row is mapped into the destination. # Each field can go through a “pipeline”, which is just a chain of plugins # that transform the original value into the destination value, one step at # a time. Source values can go through any number of transformations # before being added to the destination row. In this case, there are no # transformations -- it's just direct mapping. process: source: src alias: dst langcode: language # The destination row will be saved by the url_alias destination plugin, which # knows how to create URL aliases. There are many other destination plugins, # including ones to create content entities (nodes, users, terms, etc.) and # configuration (fields, display settings, etc.) destination: plugin: url_alias # Migrations can depend on specific modules, configuration entities, or even # other migrations. dependencies: module: - migrate_drupal I <3 this, how can I help?

The first thing to look at is the Drupal 7 meta-issue. It divvies up the Drupal 7 upgrade path by module, and divides them further by priority. The low-priority ones are reasonably easy, so if you’re new, you should grab one of those and start hacking on it. (Hint: migrating variables to configuration is the easiest kind of migration to write, and there are plenty of examples.) The core Migrate API is well-documented too.

If you need help, we’ve got a dedicated IRC channel (#drupal-migrate). I’m phenaproxima, and I’m one of several nice people who will be happy to help you with any questions you’ve got.

If you’re not a developer, you can still contribute. Do you have a Drupal 6 site? Migrate it to Drupal 8, and see what happens! Then tell us how it went, and include any unexpected weirdness so we can bust bugs. As the Drupal 7 upgrade path shapes up, you can do the same thing on your Drupal 7 site.

If you want to learn about meatier, more complicated issues, the core Migrate team meets every week in a Google Hangout-on-air, to talk about larger problems and overarching goals. But if you’d rather focus on simpler things, don’t worry about it. :)

And with that, my fellow Drupalist(a)s, I invite you to step up to the plate. Drupal 8 is an amazing release, and everyone deserves it. Let’s make its adoption widespread. Upgrading has always been one of the major barriers to adopting a new version of Drupal, but the door is open for us to fix that for good. I know you can help.

Besides, core commits look really good with your name tattooed on ‘em. Join us!

Tags:  acquia drupal planet drupal 8
Categories: Drupal News

Higher Education’s Equation: Simplify Digital Complexity

27 June 2015 - 1:40am

Colleges and universities were some of the first organisations to create websites. They are natural content generators with access to great thinkers, cutting edge research and engaged students, not to mention they embody the word community. The web, as a result, was the perfect vehicle for them to communicate all they had to share and connect what they knew with those who were seeking the content that mattered to them.

But as we look at today’s landscape and the evolution of higher education digital strategies, is the compatibility of the web and higher education too much of a good thing? Too good of a match, if there is such a thing, leading to too many disparate websites floating around out there? What happens when a student moves on, a course changes, an organisation folds, a lecturer starts a new area of research, or a project outgrows its old site? Do they contact IT and ask them to take it down? Worse, did they build the sites according to the brand standards and style guides that are becoming increasingly important to those in higher education marketing?

Even though websites have come a long way since those early days, the challenges institutions face are still evident. At the beginning, there was the early adopter phase, then the “I need a web developer to build anything” days, and now we are in a new era- the era of web platforms. While universities have become highly dependent on digital platforms to drive all aspects of business, the effort required to build and manage web sites has become far more efficient. While this seems to be an effective progression that higher education institutions are making, they still face new challenges that come with the rate at which innovation is occurring all around them.

Take recruitment and retention, for example. Today’s higher education arena is increasingly complex when it comes to recruitment and retention. Elevating your web strategy revolves around the rate at which websites can be deployed and the ease with which they can be updated and maintained. Staying ahead of the resulting tangle of web sites and the associated costs is imperative in today’s ever-changing digital world. Universities find that by using a central platform to deploy sites quickly from templates, as opposed to building each site individually, they can maintain certain brand and end-user experience expectations while maintaining security and accessibility requirements. Also, they can utilise a centralised platform dashboard to keep track of websites and prevent the orphan site issue. All of this would allow them to focus on being forward thinking, focusing on things like site impact and user experience.

Lastly, a website is only as good as the content on the page. The ability to efficiently edit, upload and share content across sites is vital to effectively delivering a great digital campus experience. Passing content over the wall in applications like Word to a web developer in IT or leaving content owners on their own with little training or technical skill can be inefficient and leads to the type of frustration that hampers quality and frequent content refreshes. A solution that provides content creators with fool-proof templates and wizards that effectively distribute content authoring to the far reaches of campus, regardless of job function or skill can help content strategies immensely and get to the core of an institution's mission- to share and educate.

Today, we shop in the virtual world of storefronts, whether we’re pricing the options on a new car, comparing the attributes of a digital single lens reflex (dSlr) camera, or looking for a new home. Shopping for a university is no different and those doing the looking expect similar experiences. Long before a student ever walks through the front gate of a campus, they have spent many hours online, shopping specific campuses, cities versus rural locations and institution’s positions in the league tables. In fact, the great digital experience offered by an institution of higher education may be the best chance it has to attract a student who will be looking at many universities—maybe scores of universities. And that number is only rising.

Higher education, like other organisations, have progressed a long way in recent decades. The lesson learned? The top marks for a great digital experience in higher education will be earned by simple, yet powerful digital site solutions that no longer need to be built, but simply deployed.

Tags:  higher ed higher education education site factory acquia drupal
Categories: Drupal News

Acquia's 2015 Partner Site of The Year Finalists

27 June 2015 - 1:25am

Acquia partners with top digital agencies that are creating amazing digital experiences in order to help companies and brands thrive in today's complex digital world. The Partner Site of The Year competition serves as a unique opportunity to showcase the best examples of their work.

For this year’s competition, Acquia’s digital agency partners submitted client sites for consideration across 15 categories. After careful deliberation, Acquia’s executive team selected 48 finalists, assessing each site on visual
design, functionality, integration and overall customer experience. Next up? Finalists will face an evaluation by a panel of experts from the digital marketing and Drupal communities. Winners will be announced in Fall 2015.

Here at Acquia, we were all very impressed by the incredible work our partners have put forward. We think you will be impressed too. So without further ado, I am happy to announce the finalists for Acquia's 2015 Partner Site of the Year Awards...

Brand Experience Partner Site

EPAM Systems

Givaudan

Genuine Interactive

McLean Hospital

NorthPoint Digital

Johnson & Johnson

Commerce Partner Site

iKOS

Lush

Iksula

Starbazaar

Isovera

Bidsquare

Digital Experience Partner Site

Centerline Digital

GE Oil and Gas

Salsa Digital

Salsa Digital

Genuine Interactive

Intralinks

R2 Integrated

Bunn

Entertainment Partner Site

Caxy

The Field Museum

MasterChannel

Imagine Dragons

Brand42 Ltd

Lifetime TV

Technocrat

Presto (by Foxtel)

External / Customer Community Site Partner Site

Forum One

Johns Hopkins Bloomberg School of Public Health Center

Deeson

DePuy Synthes

Blue Coda

Shared Value Initiative

Financial Services Partner Site

Boston Web Design

Sigma Prime Ventures

Third & Grove

Mint.com (Intuit)

High Tech Partner Site

Fenix

Alcatel Lucent

Appnovation

Mulesoft

Boston Interactive

Physical Sciences, Inc.

Higher Education Partner Site

Carousel30

Howard University

FFW

Stanford University

Rauxa

Becker University

Internal Community Partner Site

Forum One

The World Bank Consultative Group to Assist the Poor

FFW

National Audubon Society (internal site)

Digital Bungalow

NCAA

Media

North America:

Partner Site

Mediacurrent

The Weather Channel

FFW

Emmis Digital

International:

Partner Site

iKOS

Forces TV

Just Digital

Abril

Ibuildings

RTL

NGO Partner Site

GSI

Earth Hour

Nurun

Montreal Airport

This Little Duck

Garage Sale

Pharma / Life Sciences Partner Site

CI&T

J&J Innovation

Digital Bungalow

MVLAD

Blue Coda

Clean Slate Centers

Public Sector: Federal Partner Site

OPIN

Canadian Transportation Agency

OPIN

Prime Minister of Canada

Forum One

US Global Change Research Program (USGCRP)

Public Sector: State and Local Partner Site

Code and Theory

New York State

Phase2

San Mateo County

Pixel Onion

San Francisco International Airport (China)

Sports Partner Site

Globant

Puma

Genuine Interactive

The Basketball Tournament (TBT)

Phase2

Bassmaster

Now it's time for you to dive in! Take some time to get familiar with each of the sites, paying special attention to design, engaging content experiences, multimedia, and of course, ease of navigation. These characteristics can make or break any site, and that is precisely what our juried panel will be looking for when evaluating finalist sites.

Congratulations to all finalists! Thank you to our partners for their submissions. We will unveil the award winners in Fall 2015. Stay tuned!

*/
Categories: Drupal News

BlissWorld.com: Achieving A Higher State of Happy

26 June 2015 - 9:55pm

It’s 2pm on a Friday and I am fried. I’m dying for the workweek to be over. This time last week I was rock climbing in the Austrian Alps with my fiancé trying my best not to scratch up my week-old engagement ring. We flew back to Boston the next day and were both at work on Monday, dying for a vacation from our vacation.

Now that I’m just about finished digging out from under a pile of email and to-dos, I’m in desperate need of more traditional relaxation. One project we’ve been working on is telling our newest success story – Blissworld.com. I’ve been looking at beautiful imagery of women relaxing on massage tables getting facials, mud wraps, pedicures… and staring at the tagline on Blissworld.com – “this is bliss… achieve a higher state of happy”. Yes please…

A tagline couldn’t ring more true. Not only do they have an amazing offering of spa products and services, but I’ve never before worked with a client team and an agency team that have such a happy relationship. To prep for the case study we got on a call with Bliss and BORN Group, the agency that drove the creative and technical strategy behind the redesign. It was an honest-to-god love fest. Bliss couldn’t be more thrilled with the site Keith Pires (Senior VP) and his team at BORN delivered. Keith praised Jacquelyn Ryal-Laufer (Senior Manager of Digital) and the rest of the Bliss team for a truly innovative vision that allowed his team to stretch their legs and really show their digital chops. Both were thrilled with their decision to power the whole site on the Acquia Platform and described it as the “centerfold,” allowing them to bring their vision to life. And I couldn’t be more pleased with the task of sharing their story with the world.

As I explore the new blissworld.com, I can understand the mutual excitement we heard on that first call. The imagery is beautiful, navigation clean, and the site is a joy to browse. I’ve gotten lost in product, imagining the bath I’ll draw for myself in my imaginary spa-tub in my ‘someday house’. I can almost smell the blood orange + white pepper sugar scrub and the grapefruit + aloe soapy suds that will line my bathtub.

Most importantly, as Jacquelyn pointed out on our first call, the user can now book spa treatments right on the site – not only a huge differentiator, but I believe a first in the spa industry. I explored that section of the site, and was impressed at the amount of spa services they provide and the detail provided on the pages within. Each spa detail page even includes links to products actually used in the treatment. Not only was I able to get a better idea of what the service entails, but if I wanted to I could even recreate the experience at home (provided I can talk my fiancé into giving me the 105 minute body rub down the spa offers).

The first draft of the case study is off for editing and I have about 5 minutes before my next meeting. So… do I go for their famous triple oxygen facial or the ginger rub massage?

Tags:  retail commerce ecommerce
Categories: Drupal News

Conquering the Drupal Learning Curve

25 June 2015 - 10:25pm

Common perception is that Drupal has a steep learning curve. Others, colleagues included, find the statement misleading and detrimental. I find myself somewhere in the middle. I think that Drupal development can be unintuitive to someone new to Drupal. However, I believe that any motivated, interested individual can 'conquer' Drupal development, regardless of prior experience.

I decided to test the theory by teaching a pre-school teacher, a used car dealership manager, a Java developer, and five others, Drupal 7 development.

Why the Reputation?

Drupal allows you to change almost anything at all, without editing any of Drupal’s core code. Let that sink in for a minute. Bear in mind, Drupal built its name on older versions of PHP with little Object Oriented support. This required pushing older versions of PHP’s limits using creative techniques, which led to coining the phrase doing things ‘the Drupal way’. It also led to the well-known idiom that Drupal is ‘on an island’ of its own. Unfamiliarity with ‘the Drupal way’ is where the steep learning curve comes from. Note: Drupal 8 goes a long way towards moving from unique solutions to solutions which are "Proudly found elsewhere."

Once I finally wrapped my head around all of the Drupal-isms, I knew the learning process could have been much simpler with an experienced Drupal developer to show me that I didn’t have to jump over the hurdles, there was a simpler path around them. 

Motivation

Before working at Acquia, I began Debug Academy, which previously operated as Debug Society. Through Debug Academy, I taught motivated individuals to be web developers one-on-one. They learned HTML, CSS, Drupal site building, and Drupal theming. They were then hired to build Drupal websites by Debug Society under my guidance, which often led to career changes.

After repeated successes, I decided to build a proper curriculum and expand the material taught. Git, Drush, Command line, HTML5, CSS, Advanced Drupal Site Building, managing updates in code, and more formed the newly assembled curriculum. It included all of the skills needed to be a successful member of an enterprise Drupal development team.  But, if the learning curve is really so ‘steep’, could even non-developers really learn Drupal development?

Eight Students. Three Months. One Goal.

After developing the curriculum, I decided to test it on a full, diverse classroom at no cost to students.

I ensured the individuals in the class spanned a wide array of experiences and education. The only criteria for enrolling were an interest in learning and a willingness to attend. Classes took place on Wednesday evenings and Saturday mornings, to ensure the working professionals could participate.

The students' backgrounds were:

  • Pre-school teacher (English degree)
  • Tutor (Neuroscience degree)
  • Non-technical Entrepreneur (N/A)
  • Engineering Ops (Two Information Technology masters degrees)
  • Civil Engineer (Civil Engineering degree)
  • Java Developer (Mechanical Engineering degree)
  • Dealership Manager (Associates degree)
  • Recent High School graduate (N/A)

The learning experience consisted of PowerPoint presentations, written lessons, online tutorials, at-home assignments, pair-programming tasks, debugging, patches and so much more. When a topic was deemed too hard to follow for a majority of students, graphics were created to help explain.

Class Projects

During the class, we worked on projects the students could be proud of.

  1. Re-built craigslist using Drupal
    • Updates were managed in code, using Git (all projects)
    • Each student built a category, (Jobs / Housing / Community, etc)
    • Using enterprise development workflows, students’ work was combined
    • Each student created a version of the theme
    • We were left with a functional copy of craigslist, built as a team
  2. Built http://debugacademy.com
    • Students researched and made cases for different distros
  3. Created a new responsive theme for http://debugacademy.com
  4. Created a new responsive theme for http://debugsociety.com
  5. Built a new homepage for a paying customer
    • Payment went to involved students
  6. Built a new responsive theme for a paying customer
    • Payment went to involved students

Every website was built to be responsive, as is expected of all modern websites. A distribution was used for Debug Academy, while the rest were built from vanilla Drupal installs.

No decision was made in private, and no steps were skipped. Students chose which modules we used, and which distribution to use. It was a great experience for all of us, and students can still see their work online today.

Reactions to the Drupal Development Class

The diverse group of students, most of which with no development experience at all, were each tasked with learning web development using Drupal 7. With Drupal’s supposedly ‘steep’ learning curve, let’s see what their reactions were:

  • Pre-school teacher (English degree)
    "I would definitely take it again. I learned so much and I feel that there is so much left to learn. I enjoy working with HTML and CSS and getting the hang of these languages as well as Drupal has been very rewarding."
  • Tutor (Neuroscience degree)
    "Web design is the future. My favorite project was DebugAcademy.com, seeing it go live is exciting. I learned the basics of Drupal and feel that I now have a good foundation to continue with."
  • Non-technical Entrepreneur (N/A)
    "It is empowering to know how to work the technical side of things, especially if you are thinking of starting (or have already started) a web based company. In such a company, the reality is that the non-technical founder (or co-founder) can be more of a liability than an asset to the team. The classes at Debug Academy gave me real experience and a real start to coding."
  • Engineering Ops (Two Information Technology masters degrees)
    "I'm going to use Drupal to build a website for my business. It's fascinating how much we can do with it already."
  • Civil Engineer (Civil Engineering degree)
    "This was an eye opening experience. I never programmed before but it makes sense. I'm impressed with Drupal and plan to do more freelance work before working with it full time."
  • Java Developer (Mechanical Engineering degree)
    "This class is more than your typical 3-hour lecture with a lengthy slide-deck. It covers real-world problems in web development and best practices that will have you ready to join a development team in a short period of time. After a few weeks you'll be working on real work that will NOT be thrown away. The best way to learn Drupal and web-development is by completing hands-on, useful work, and this course ensures that you are doing just that."
  • Dealership Manager (Associates degree)
    "This has opened so many doors for me."
  • Recent High School graduate
    "I am not yet responsible enough to be doing assignments, projects on my own yet. But it was really interesting to see the amount of effort it takes to build a website from scratch. The class is only good if you are willing to put in the time and effort. "
Where are they now?

The paths taken as a result of taking the class varied, but not for the reasons you may have expected. The primary indicators of success were showing up to class on time and successfully completing the required assignments.

Let's break it down by person:

  • Pre-school teacher (English degree)
    • Timely Attendance: 95%
    • Homework Completion: 80%
    • Now: Working as a front-end Drupal developer, received a 50% Salary increase.
  • Tutor (Neuroscience degree)
    • Timely Attendance: 90%
    • Homework Completion: 75%
    • Now: Working as a front-end Drupal developer, received a 50% Salary increase.
  • Non-technical Entrepreneur (N/A)
    • Timely Attendance: 60%
    • Homework Completion: 60%
    • Now: Migrating web-based business to Drupal for its flexibility.
  • Engineering Ops (Two Information Technology masters degrees)
    • Timely Attendance: 80%
    • Homework Completion: 30%
    • Now: Building Drupal-based small business website to pursue a personal business goal, and to learn Drupal better.
  • Civil Engineer (Civil Engineering degree)
    • Timely Attendance: 70%
    • Homework Completion: 60%
    • Now: Studying PHP and MySQL with the intention of changing careers.
  • Java Developer (Mechanical Engineering degree)
    • Timely Attendance: 95%
    • Homework Completion: 100%
    • Now: Working as a Senior Drupal Developer at Acquia. Received a 40% salary increase.
  • Dealership Manager (Associates degree)
    • Timely Attendance: 80% 
    • Homework Completion: 80%
    • Now: Became an IT Consultant, then Director of IT, after adding Drupal Development to the small business' services. Now employed as a Security Engineer for MicroStrategy.
  • Recent High School graduate
    • Timely Attendance: 65%
    • Homework Completion: 40%
    • Now: Pursuing a degree in finance, but having an easy time in his intro to web development course.
    Conclusion

    “Drupal has a steep learning curve” is the claim in question, and I readily refute it. It is not that the curve is steep, but that it can seem steep without guidance. The path to understanding is murky, and without a guide, it may seem more treacherous than it really is. After a three month, part time Drupal course provided through Debug Academy, ZERO students’ reactions were ‘Drupal is too hard’. Not even the students with no web development background at all!

    On the contrary, 7 out of 8 students plan to use Drupal professionally. The former Java developer is currently working at Acquia as a Senior Drupal Developer. The former used car dealership manager was able to completely change career paths, and is now a Security Engineer at a large software company. These students earned it with their perseverance, hard work, and decision to enroll.

    So if you are interested in learning Drupal, but are worried that the learning curve is too steep, take heed of the former pre-school teacher, the former car salesman, and the former Java developer. If you have the right attitude and have an experienced Drupalist to make you aware of the Drupal-isms as you get started, you can use Drupal to change your career as well.

    The students in this article learned at Debug Academy, which is accepting applications for upcoming classes in the Northern VA / Washington D.C. area on its student-built website, and is accessible to individuals of any experience level. An option in Boston, Acquia U, pays you to learn, and is accessible to individuals with at least 2-3 years of technology experience. Find the right solution for you, and embrace the career changing opportunities! 

Categories: Drupal News

What Drupal Code Should/Should Not Be Included in a Public Repository?

25 June 2015 - 2:28am

This is the third post in a multi-part series on using GitHub for Government. In previous posts, we've discussed the basics of GitHub, as well as what the public can see and do with GitHub. In this post we'll look at what Drupal code should and shouldn’t be in a public repository, and in future posts, we'll discuss users and permissions on organizational accounts and developer workflows.

What code can be safely made public and what code should be made public are not always the same thing. What custom code should or should not be made public depends on what your agency’s objectives are in releasing your source code. These objectives usually include one or more of the bullets below. (If you know you’re expected to open source your code, but you’re not sure which of these objectives is driving the decision, I recommend finding out. This can help you avoid a lot of headache and confusion down the road.)

Possible objectives for releasing source code to the public:

  • Comply with an organizational source code policy that mandates “open source by default” (e.g. Consumer Financial Protection Bureau policy here)
  • Release code as a matter of transparency, so the public knows what it paid for
  • Release code with author names in the commit history to give developers a sense of pride, ownership, and peer pressure to do their best work
  • Whether code is reusable or not, provide it as an example or starting point for other agencies solving similar problems
  • Cultivate a community of users and contributors so your agency is not paying the total cost of ownership alone
  • Encourage other agencies to reuse your code, so you’re not using taxpayer dollars to solve the same problems over and over again

The following lists of bullet points describe the different types of code that power Drupal-based web applications. These are things you can release. With your agency’s particular objectives above in mind, hopefully this will help clarify what you should release in your own particular situation.

These are the different types of projects that make up most of a Drupal application, and the different types of projects that people contribute on drupal.org. If your objective is reuse, these are the most important things to share:

  • Modules: Provide features and functionality that extend Drupal’s core feature set
  • Themes: Graphic designs are implemented as “themes”
  • Install profiles / Distributions (“distros”): Whole web applications can be made sharable and reusable as install profiles or distros (if developers build and maintain install profiles from the beginning, these are really easy to release later; trying to reverse engineer an install profile after the application is built can be laborious and costly)
  • Make files: A Drush make file is like a recipe for an application including a list of all included projects and version numbers. This can be used to assemble a whole application from all its constituent parts (these are usually included in install profiles on drupal.org to create a “distribution,” but you can release these on your own on GitHub too)

These are things developers do not release on drupal.org, but they may be valuable to others to serve as an example or starting point for similar projects.

  • Site-specific modules including features or functionality that is specific to your government agency.
  • Site-specific themes including branding assets, hard-coded privacy policies, or site names specific to your government agency.

Do NOT release:

  • Site-specific settings (e.g. settings.php)
  • Site-specific files (e.g. .htaccess)
  • Copies of other people’s work maintained elsewhere (e.g. drupal.org)
  • A full copy of the exact site code base

In the next post in this series on GitHub for Government, we’ll discuss users and permissions on organizational accounts.

Tags:  github government public sector
Categories: Drupal News

Open Data - The Global Health Data Imperative

22 June 2015 - 11:06pm

This year’s 3rd International Open Data Conference in Ottawa was a call to action and an amazing opportunity to witness the innovation that is enabling a global data revolution. According to the Office of Science and Technology Policy at the White House, “Freely available data from the U.S. Government is an important national resource, serving as fuel for entrepreneurship, innovation, scientific discovery, and other public benefits. According to a recent report, open data can generate more than $3 trillion a year in additional value in key sectors of the global economy, including education, health, transportation, and electricity.” Online resources like the Open Data Impact Map provide a searchable, centralized database of open data use cases not just from the United States, but from around the world. The Map is made possible by the open data community and was developed to demonstrate the value of open government data in a range of applications, identify key trends and best practices in open data use, and provide a basis for further analysis of the impact of open data globally.

While much has been written about the social impact of open data initiatives in the public sector, the potential global economic impact is equally compelling in emerging markets, enabling public health services, private sector innovation, and prosperity in developing countries. The open data community, through industry analysis, has put the annual potential economic value of open data as high as $3-5 trillion. Data is being leveraged in innovative ways, including creating new opportunities for sharing information and developing health policy.

Though the average person unknowingly engages with shared, open data every day, there is much hype around technology themes like “Big Data,” “Data Analytics,” and “Data Visualization.” There is also a lack of awareness beyond the open data community, and the average citizen doesn’t understand the reach and impact of open data on global health data initiatives– or on their everyday lives.

According to a recent article entitled “Sorry, open data: Americans just aren't that into you” in FCW, whether they know it or not, Americans are using government data. Many of us leverage location services and mapping data on our mobile devices, as well as weather data, power applications, and GIS based social data driven apps. The FCW article mentions a Pew survey conducted in late 2014 that found there is only a dim awareness of policies at the federal, state, and local levels to open and release troves of government data for use by entrepreneurs, researchers, and government watchdogs.

In this report, only 31 percent of respondents could identify any example of their local government's data policy. Although public awareness is limited, there are several great examples of open data initiatives afoot that have the potential to shape public policy and innovation well into the future, and it’s time to take notice.

Something that is important to all citizens is healthcare and better access to related services. Economic investments, both public and private, are made based on data. This month’s beta re-launch of Healthdata.gov by the US Department of Health and Human Services on an open source platform is a great use case of harnessing a wealth of health data and providing transparent access to be leveraged by both the public and private sector. This site is widely known as a reliable catalog of health, social services, and research data that is accessible by the public for reuse in a variety of different innovative projects aimed at improving the nation’s health and well-being. The Healthdata.gov project is an example to global government health agencies of what can be accomplished when open data policy, open source innovation, and government transparency come together to benefit public health initiatives.

The European Commission publishes its Health at a Glance report annually, leveraging European Core Health Indicators to provide insight into data from 35 European countries. The 88 core health indicators are used as quantitative or qualitative measures on progress towards achieving policy goals in the EU. Data sets are available on demography and socio-economic situations, health status, determinants of health, health services, and health promotions across 35 countries in Europe. From quality of health to urban health indicators, open data is driving policy development decisions that will have a material impact on public health service delivery, private sector healthcare innovation. and economic investment in Europe.

Open data initiatives are global and are affecting many aspects of our lives. Now we need to harness that data, make use of it, and learn from the stories it tells. Organizations like NuCivic have open source software-as-a-service (SaaS) offerings for public sector organizations around the world. Their Drupal-based, open source data platform, DKAN, has a full-service cloud offering called NuCivic Data. Initiatives like these, and others, are laying the groundwork for the future of open data in government, and within that movement, healthcare is a great place to start. Open source, open data solutions are having an impact on our everyday lives, and are likely to help benefit future generations to come.

Tags:  open data government health data public sector
Categories: Drupal News

How Weather.com Improved Their Page Load Times

19 June 2015 - 1:07am

In November, 2014 Weather.com launched on Drupal and became one of the highest trafficked websites in the world to launch on an open-source content management system (CMS). Mediacurrent and Acquia are excited to announce a new, 3-part blog post series that will share insight around how Weather.com was migrated to Drupal. Our team of experts will share best practices and what lessons we learned during the project.

There's an old saying, “Everyone talks about the weather, but nobody does anything about it.” While we are a long way from controlling the weather, Weather.com has done a spectacular job of delivering accurate weather news, as rapidly as possible, to all kinds of devices.

This is a small miracle, especially when you consider Weather.com served up a billion requests during its busiest week. Even slow weeks require delivering hundreds of dynamic maps and streaming video to at least 30 million unique users in over three million forecast locations. The site has to remain stable with instantaneous page loads and 100 percent uptime, despite traffic bumps of up to 300 percent during bad weather.

Page load times are the key to their business and their growth. When The Weather Channel's legacy CMS showed signs of strain, they came to Drupal.

On their legacy platform, Weather.com was tethered to a 50 percent cache efficiency. Their app servers were taking on far too much of the work. The legacy platform ran on 144 origin servers across three data centers. It takes all that muscle to keep up with the number of changes that are constantly happening across the site.

Traditionally, when you have a highly trafficked site, you put a content delivery network (CDN) in front of it and call it a day. The very first time a page is requested, the CDN fetches it from the origin server and then caches it to serve to all future requestors.

Unfortunately, it doesn't work that way for a site like Weather.com.

Consider this: If a user in Austin visits a forecast page, they see a certain version of that page. A visitor from Houston sees a slightly different version of that page. Not only are there two different versions of the page, one for each location, but much of the information on the page is only valid for about five minutes.

At the scale of three million locations, that's a lot of pages that have to rebuild on an ongoing basis only to be cached for 5 minutes each. Couple this with the fact that the number of served locations kept increasing as developers worked on the site, and you can see that things are rapidly getting out of control.

The first thing we did was break up the page into pieces that have longer or shorter life spans based on the time-sensitivity of the content. That allowed us to identify the parts of the pages that were able to live longest and that we could serve to the majority of users. The parts that varied, we no longer change on the origin servers, but instead delegate to systems closer to the user where they actually vary.

To accomplish that trick, we switched to a service-oriented architecture and client side rendering, using Angular.js, ESI (Edge Side Includes), and some Drupal magic. The combination of these three components boosted cache efficiency, page performance, and reduced the required number of servers to deliver it.

The result? After launch, we showed Weather.com a 90 percent cache efficiency. In other words, in going from 50 to 90% cache efficiency they reduced the number of hits to the origin servers, which means that you need fewer of them. Post launch, we were able to increase cache efficiency even further.

This cache efficiency was also measured only at the edge. Varnish (a caching proxy) further reduced the amount of traffic, meaning that Drupal itself and the Varnish stack were serving less than 4 percent of their requested traffic. The benefits of the service-oriented architecture also mean that scaling is simpler, architectural changes are less painful, and the end user can experience a richer user experience.

Doing something about the weather is still way out on the horizon, but Weather.com can certainly claim that it has improved the delivery of weather news.

Tags:  acquia drupal planet
Categories: Drupal News

Redefining Commerce: OluKai - Selling Shoes, Selling a Lifestyle

18 June 2015 - 10:31pm


I discovered the OluKai brand a couple of years ago when my brother bought a pair of OluKai sandals, and lived in them for an entire summer. Nearly daily proclamations of enthusiasm and excitement over that single pair of sandals soon had me looking at the brand website and buying a pair for myself. Much like my Brother, I immediately fell in love, and have been a strong brand advocate ever since. But it’s not just the sandals I fell in love with, it’s the lifestyle that OluKai embodies. It made me want to emulate that in my own life.

OluKai sells a stylish, comfortable, and high-quality product, but their true appeal isn’t in the shoes they sell, it’s in the lifestyle. Anywhere Aloha. “Aloha was born in Hawaii, but it is a spirit not bound by geography,” says a tagline on their website, splattered across pages full of vivid imagery, video, and faces of real people with real names, sharing their real-life stories of Aloha. OluKai is a brand that not only tells an engaging story, but aims to truly enhance your life. Their website features the most seamless integration of gorgeous, engaging content I’ve seen. Scrolling through their Anywhere Aloha stories - The Explorers, The Surfers, The Artists - it feels much less like an ecommerce sales experience, and much more of a PSA for living a happy life. And I’d venture to bet that the idea of selling happiness is a pretty lucrative one.

They also have a community page, which further promotes engaging stories. These are not necessarily stories about OluKai customers, but of individuals who are impacting their own local communities in some positive way. “There are those who lead by simply doing. Those who do not stray from challenging paths-- who inspire others to follow despite the obstacles. For them, work is more important than mere words and kuleana (responsibility) to generations past and to those yet arrived is a guiding light.” They make a point to discuss real life, real issues, real situations, and real people without the mention of product or the intent to sell. At the end of the day, of course they want to move product -- they are a retail company after all -- but they’re also so much more than that.

Beyond their exceptional and robust content offerings, their ecommerce experience is simple and straight-forward. Product pages are crisp and clean, and this is where you will find product images, product specs, and customer reviews are front and center. There is no fluff or extra flair, just an expert, yet easy, shopping experience.

What’s Working:

  • Promote a lifestyle. If your product evokes some sort of idyllic lifestyle, encourage your customers to live it! Nothing sells a product better than a customer being able to visualize the product as a part of their everyday life.
  • Immersive Imagery. Product and lifestyle images are the new norm for an excellent ecommerce experience, so finding a way to cut through the clutter is key. OluKai uses their graphics to paint a picture of this idyllic world that makes customers want to jump in and live it… with a pair of OluKai sandals on their feet, of course.
  • Live in the moment. The timing of this post -- just before Father’s Day, gave us a great perspective on OluKai’s execution of a holiday marketing campaign, and they hit it out of the park. Their homepage is covered with Father’s Day features, promoting quotes, stories, and products all about Dads.
  • Customer stories. Product reviews are great, but what about real people sharing real stories about how they live with and interact with a product? Where reviews might feel structured and generic, stories feel real and engaging. I don’t need to tell you which of those is preferable.

Now please excuse me while I get ready for summer and buy my summer OluKais…

This blog series - Redefining Commerce - highlights retail brands that are elevating traditional online commerce experiences, pushing the boundaries of what it means to be an online retailer, and delivering unparalleled consumer experiences.

Tags:  commerce retail ecommerce
Categories: Drupal News

Achieving Agile in Government - It Can Be Done

18 June 2015 - 10:14pm


Implementing agile development methodologies in a government setting can be quite difficult. Government agencies often want to know upfront exactly what they’re getting, and exactly what it will cost. From an agile development perspective, this is a major challenge.

According to Agile In A Nutshell, “Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations.” Clearly, this sounds nothing like the fixed terms a government agency is often seeking. So how do you implement an agile framework within a fixed scope project? Here’s how we do it.

Our team works with a fixed number of cycles, which means we give the client a set amount of work we can do for them, but not precisely what that work will be. So instead of agreeing to finish building a new feature, for example, we’ll agree to give them X number of tickets that we can guarantee will be completed. This simultaneously allows our team to do agile work, and also ensures for the client that they will get those X number of tickets completed in a certain period of time. What each ticket will address specifically is not fixed, which allows us to work with our stakeholders to set priorities on an ongoing basis, and allows for changing priorities throughout the duration of the project.

These cycles are also sold at a specific service level agreement, so for example, we might say that all tickets will be completed within 20 days, which allows the team to staff the project however they need to in order to meet that requirement. From the government agency perspective, we aren’t selling “people” for a project, but “capacity” to do the work, so that our development teams can allocate resources appropriately.

The result is a win-win resolution: the client pays a firm fixed price contract for a pre-determined amount of work, and is comfortable knowing that they get a certain amount of work done every 20 days. Our dev team, meanwhile, has the leniency and flexibility to determine how their hours are allocated during that time to maximize efficiency and achieve results.

Tags:  agile agile methodologies developers drupal government
Categories: Drupal News

What Can The Public See and Do With Things I Put On GitHub?

18 June 2015 - 12:38am

This is the second post in a multi-part series on using GitHub for Government. We’ll discuss what the public can see and do with GitHub, what Drupal code should and shouldn’t be in a public repository, users and permissions on organizational accounts, and developer workflows.

Here’s a quick overview of things that become visible and interactions that become public when a person makes a code repository, or “repo”, public on GitHub.

1. Code becomes downloadable and publicly viewable online. Visitors can browse through folders, click files, and view code through their web browser. (browsing example, view files/code example)

2. The code’s change history (the git “log”) also becomes public. This is like a “track changes” history. For every saved change, Git keeps track of the changes made, user who made the change, the date the change was made, and a message logged by the user. These changes can be viewed online and in copies of the source code.

Examples:

  • A list of logged changes, authors, and messages viewable online on GitHub (here)
  • A single change, its author, and the author’s message on GitHub (here)
  • A list of changes in a visitor’s copy of the repository (here)
  • A single change in a visitor’s copy of the repository (here)
  • All past releases are visible and downloadable online (here) and in a visitor’s copy of the code base (here)

While there is no obligation for code maintainers to respond to public input, public repositories on GitHub do open a few new channels for the public to interact with a project:

  • GitHub users can submit comments about saved changes, also known as “commits” (example here)
  • GitHub users can submit proposed changes to code as “pull requests,” so that the project maintainers know they can consider “pulling” changes into the main codebase (example here)
  • GitHub users can copy (“fork”) and maintain their own versions of any project they have access to (forking a project: begin here, end here)

Recommendations:
Your government agency should use an organizational GitHub account to publicly host open source code. GitHub is the easiest and most user-friendly way to release code to the public.

If you are interested in “open sourcing” your code, but people in your organization are wary of creating new, unknown, or unsupervised channels of communication with the public, disable the Wikis and Issues features. To the public, releases on GitHub will feel like a normal but “bare bones” use of the software.

Regarding this “bare bones” use – it is perfectly respectable to make code public, but not use GitHub as a forum for discussion or community engagement. Just because a repository is public, the owner of the repository is not obligated to communicate with the GitHub community or manage development in public view. Linus Torvalds, the creator of Linux and Git, uses GitHub to host Linux (x), but he does not manage development publicly there. Similarly, there is a mirror of Drupal’s authoritative git repository on GitHub here, but the wiki and issue tracker are disabled. Discussion, collaboration, and issue tracking for these projects happens somewhere else. For your agency, you can decide on a project-by-project basis if your roadmap and issue tracker should be private or public, and take place on GitHub or elsewhere.

In the next post in this series on GitHub for Government, we’ll discuss what Drupal code should and should not be included in a public repository.

Tags:  github government public sector
Categories: Drupal News

Build Your Drupal 8 Team: The Forrester Digital Maturity Model

15 June 2015 - 10:46pm

In business, technology is a means to an end, and using it effectively to achieve that end requires planning and strategy.

The Capability Maturity Model, designed for assessing the formality of a software development process, was initially described back in 1989. The Forrester Digital Maturity Model is one of several models that update the CMM for modern software development in the age of e-commerce and mobile development, when digital capability isn't an add-on but rather is fundamental to business success. The model emphasizes communicating strategy while putting management and control processes into place.

Organizations that are further along within the maturity model are more likely to repeatedly achieve successful completion of their projects.

Let's take a look at the stages of this model, as the final post in our Build Your Drupal 8 Team series.

Here are the four stages:

Stage 1 is ad hoc development. When companies begin e-commerce development, there is no defined strategy, and the companies' products are not integrated with other systems. Most products are released in isolation and managed independently.

Stage 2 organizations follow a defined process model. The company is still reactive and managing projects individually, but the desired digital strategy has been identified.

Stage 3 is when the digital strategy and implementation is managed. An overall environment supportive for web and e-commerce development exists, and products are created within the context of that environment.

In Stage 4, the digital business needs are integrated. Products aren't defined in isolation, but rather are part of an overall strategic approach to online business. The company has a process for planning and developing the products and is focused on both deployment and ongoing support.

The final capability level, Stage 5, is when digital development is optimized. Cross-channel products are developed and do more than integrate: they are optimized for performance. The company is able to focus on optimizing the development team as well, with continuous improvement and agile development providing a competitive advantage.

Understanding where your company currently finds itself on the maturity scale can help you plan how you will integrate and adapt the new functionality of Drupal 8 into your development organization.

If you are an ad hoc development shop, adopting Drupal 8 and achieving its benefits may be very challenging for you. You may need to work with your team to move up at least one maturity level before you try to bring in the new technology.

In contrast, if your team is at stage 5, you can work on understanding how Drupal 8 will benefit not just your specific upcoming project, but also everything else that is going on within your organization.

Resources:

  • A comprehensive SlideShare presentation on Digital Maturity Models.
  • A blog post by Forrester's Martin Gill that mentions the Digital Maturity Model in the context of digital acceleration.
Tags:  acquia drupal planet
Categories: Drupal News

Going from .NET to Drupal? Here are the top 5 ways they are different

12 June 2015 - 11:54pm

Drupal is an incredibly flexible and expressive CMS and development framework. As a
developer, it allows you to express yourself quickly and easily. That being said, being able to do
anything​ can be a little overwhelming.

Switching from .NET to Drupal 7 isn’t easy for most people. They take fundamentally different
approaches to development that aren’t called out. There is also a surprising lack of articles and
documentation on the subject. Two years ago I made the change to Drupal. I didn’t have
anyone to help, so the transition was harsh. Developers not only struggle with the transition, but
more importantly with the ability to adopt best practices. The end result is often unstable, and
unmaintainable.

This is the first post in a series highlighting the differences between .NET and Drupal. The goal
is to help you as a developer map concepts from .NET to Drupal and give you the foundation
you need to be successful with Drupal. You’ll see that Drupal development is actually easy,
robust, and a lot of fun.

Here are the top 5 ways that Drupal and .NET are different: Framework Support

Drupal is a CMS but it’s also a development framework. Where .NET has an API for everything,
Drupal has a lean core API, and a large ecosystem of open-source modules to provide extra
functionality. This is where Drupal’s CMS background shines. Drupal has fully completed
modules designed to meet business needs. There is a module for everything: modules for
styling content on a page, displaying social content, and even translation. I cannot stress this
point enough. There is a rich open source community in your corner backing you up. Modules
keep you from reinventing the wheel and allow you to dramatically increase your development
velocity.

While you have a clear API to follow with .NET or Java, Drupal requires a certain amount of
tribal knowledge to build a real site. You need to be able to know which module meets your
needs. It’s overwhelming at first. Here you are struggling to figure out Drupal core and at the
same time, you have to figure out all these modules as well. It takes time, but eventually you
start to get a feel for some of the basic modules to start with. (I recommend checking out
Lightning​ for a curated list that we use here at Acquia. And posts ​on identifying​, ​searching,​ and evaluating​​ Drupal modules).

Different Approaches: OO vs. Procedural

In order to understand the chasm between .NET and Drupal it helps to understand the
background and differences between C# and PHP.

C# is a descendant of C, C++, and Java. As such, C# has been around for a while and has a
mature object model. PHP only added modern OO capabilities in PHP 5.0 (2005) and late static
binding in PHP 5.3 (2009). PHP is a relative newcomer to the OO world.

The difference strongly influences code structure and coding practices in Drupal 7. A lot of PHP
code in D7 is largely procedural. Some of the newer PHP code is OO but in D7 that’s the
exception rather than the rule. This means that functions are not grouped together in small or
medium understandable objects, or even namespaces. Most functions are defined in a global
scope. Procedural code lacks the structure and aesthetic of OO code.

In an object-oriented world, a clear hierarchy of objects guides your development. When you are
working in Java or ASP.NET, that object hierarchy can be reassuring. You can turn to it to tell
you what to do. It is also listed in the API documentation, and you can drill down through it to
understand what you need to do to effect change.

You can also always look at the object in a debugger to see all the methods and properties
supported. The lack of object inheritance in procedural code makes it difficult to follow code and
understand what is happening. In a procedural language you need to simply know the functions
that are available to you. Since most functions are defined in global scope, they can be
overwhelming!

Strong vs. Loose Typing

The other major difference is that C# is a strongly typed language and PHP is a loosely typed
language. In strongly typed languages, such as C#, variables are declared with a type. In
loosely typed languages, no type is required.

C#
string myVar = “This is a strongly typed declaration”;

PHP
$my_var = “This is a loosely typed declaration”;

One has a type and one doesn’t. So what’s the big deal? By looking at a variable declaration in
C# you immediately know that it is storing a string. On the other hand, in PHP, you can only
infer based on the right side of the declaration statement.

Here is a great example of the confusion this can lead to:

$my_var =  node_load(123456);

What is the type of ​my_var​? Without knowing what ​node_load​ returns you have no idea. ​ ​This
is represents a huge barrier to reading and understanding PHP code. I cannot stress this
enough. Loose typing along with the fact that functions are defined in global scope means
reading PHP code requires a much broader understanding than C#.

Why Is Everything an Array?

The combination of procedural code, lack of an object model, and loosely typing means that
Drupal/PHP has to get creative when passing around bundles of information. It does this by
creating infinitely nested ​dynamic arrays​. Theses are incredibly powerful, flexible, and are core
to Drupal’s ability to be customized to meet almost any need.

That being said, Drupal arrays can be hard to understand and follow. They are also largely
undocumented and undocumentable. For a more in depth explanation see John Alban’s post on
Drupal 7 and the Arrays of Doom​.

So how do you work with these arrays? Most developers will either print them using the ​Devel
module’s dpm
​ or by using a PHP debug tool, such as ​PHPStorm​. I’ll discuss both approaches
more in depth in a later post. By poking around inside these structures you start to understand
what’s going on and how to enact changes!

Code vs. Configuration

In Drupal, the distinction between code and config can be ambiguous. Since .NET is a
framework not a CMS, there a clear line of demarcation between what is code and what is
config stored in a database. In general items stored in the database represent content/user
settings/config.

Drupal, on the other hand, is a CMS, one that is extremely customizable via the user interface.
We call this​ site-building. ​In Drupal, you can build a new content type just as easily as you can
create a new article. This flexibility and configurability are one of Drupal’s strengths. However,
from a developer’s point of view, this makes things confusing. When do you need to write code?
When do you need to do things via the GUI? The line between code and config is extremely
blurry and often debated among Drupalistas. (We’ll cover this more in a later segment.)

Till Next time

No doubt, Drupal comes with its fair share of challenges, a few of which we just talked about.
But those challenges are not insurmountable. At the end of the day, the things that can make
Drupal tricky also contribute to its flexibility and power. These attributes have positioned Drupal
as a CMS leader. I hope that mapping concepts from .NET to Drupal in this blog series will help
make the transition smoother and easier for you.

In future blog posts, I’ll go into depth on some of the more granular elements of Drupal, such as
working with hooks, modules, and Drupal core. Stay tuned.

Categories: Drupal News

6 Steps to Delivering a Personalized Digital Brand Experience

12 June 2015 - 12:20am

Successful brands not only requires an elegant and intuitive shopping experience, but one that is contextualized for the customer’s specific goals and preferences. Delivering an experience that is capable of understanding whether a person is doing product research, shopping for themselves, or buying a gift for someone else is complex, but achievable with the proper plan and technologies in place.

Businesses are scrambling to figure out how to achieve personalization success. To do it right, there are a lot of moving parts. Identifying and addressing each of those can be a challenge. Here, we’ve broken down the personalization process into easy, actionable steps to get your business started off on the right foot.

Before You Get Started

Prior to starting work, there is some preparation needed to assure success:

Define Your Goals and Strategy - Before you invest in software and technology, you need to define why you’re embarking on this project. What do you hope to get out of a personalization strategy, not just this year but in three, five, or seven years? You need to define your business goals and personalization strategy before you can select the right tools.

Put Your Tools in Place - Let’s assume you already have a commerce platform that can give you all the functionality you’ll need on the backend, and that can grow with you as your business evolves and expands. On top of that, you’ll need to integrate a leading Content Management System (CMS) into your site to give you maximum flexibility and control over your customer experience, and the requisite personalization tools.

Invest in Resources to Manage the Process - Personalization is much more than just a technology project. If you decide to get into the personalization business, then you need to commit to truly being in the business. This means having dedicated resources, processes in place, and KPIs determined to be able to measure effectiveness.

Get Organizational Buy-In - Make sure the senior decision makers within your organization are on board with personalizing your user experience. If they’re hesitant, let them read this and this. You’ll need to be sure your personalization strategy is aligned with your overall business goals, or you’ll never get this initiative off the ground.

Do Some Customer Research - Before you dive in, you’ll need to collect some customer data. This should include:

  • demographic information (age, gender, location)
  • behavioral observations (browsing and buying habits, cross-channel tendencies)
  • psychographic details (interests, activities, opinions, attitudes, values)
  • demonstrated affinities and loyalties

Got all that in place? Great! Your foundation is complete, and you’re ready to start your personalization journey.

  1. Create Customer Profiles, Segments, and Personas - Before you can establish and then start testing your hypotheses, you need to create the profiles, personas, and segments you’d like to target. Sift through all of the information you’ve collected to date and find trends. This is how you begin to develop personas and segments, which are crucial to mastering personalization.
  2. Build a Testing Campaign and Test a Hypothesis - Now is the time to create a Learning and Testing Agenda to build a basis for your execution strategy. What are your hypotheses? What do you want to learn? What are your ultimate goals? Let’s build a testing campaign to answer those questions.
  3. Test, Test, Test - With a campaign in place, and hypotheses created, you’re ready to start testing. This can include A/B and multivariate testing, or it can include behavioral targeting, which is another great place to start. This will allow you to start crafting the experience, in real time, to each individual user. Just remember -- you should test and measure every step of the way. The more tuned in you are to each step of this process, and each step of the customer journey, the more sophisticated your customer profiles will become.
  4. Refine Your Targeting - At this point, you’ve done a good amount of testing. You’ve collected loads of data and created one unified profile for each consumer. You know not only who the primary personas are who interact with your brand, but the individual customers, too. You’re ready to start refining your process and getting really good at targeting your customers with relevant content and offers. Now you want to revisit your Learning and Testing Agenda to confirm or deny your initial hypotheses, and then figure out what you want to learn next. Using the results of your initial hypotheses, consider what additional learnings will help you to continue to refine and enhance your targeting and experience personalization.
  5. Nurture - To be honest, this step isn’t rocket science, but it is a crucial step. You’ve spent all this time and money getting to know your customers, and you want to keep them hanging around for the long haul, right? So, take care of them! Nurture them like you would nurture a real relationship -- that’s what you’re aiming for, after all. Take the time and care to make them feel like they each matter individually, from every single touchpoint, across all channels online and off. Target them with the right offers at the right time, based upon where they are in their individual customer lifecycle.
  6. Repeat and Expand - Think you’re ahead of the game? Think again! Just as soon as you make your way through this list, the market has changed. TIme to start all over again -- redefining personas and repeating testing and targeting practices -- but this time, you’ll be all the wiser. Now is also the time to start expanding your personalization practices -- uniting in-store and online personalization tactics, integrating social, incorporating marketing automation -- figure out what makes the most sense for your business, and expand your efforts into those areas. Remember, personalization isn’t only digital -- it’s omnichannel, it’s everywhere.
Tags:  commerce ecmmerce personalization retail CPG
Categories: Drupal News