How to prepare for Drupal 9

With Drupal 9 targeted to be released in June of 2020, many people are wondering what they need to do to prepare.

The good and important news is that upgrading from Drupal 8 to Drupal 9 should be really easy — radically easier than upgrading from Drupal 7 to Drupal 8.

The only caveat is that you need to manage "deprecated code" well.

If your site doesn't use deprecated code that is scheduled for removal in Drupal 9, your upgrade to Drupal 9 will be easy. In fact, it should be as easy as a minor version upgrade (like upgrading from Drupal 8.6 to Drupal 8.7).

What is deprecated code?

Code in Drupal is marked as "deprecated" when it should no longer be used. Typically, code is deprecated because there is a better alternative that should be used instead.

For example, in Drupal 8.0.0, we deprecated Drupal::l($text, $url). Instead of using Drupal::l(), you should use Link::fromTextAndUrl($text, $url). The Drupal::l() function was marked for removal as part of some clean-up work; Drupal 8 had too many ways to generate links.

Deprecated code will continue to work for some time before it gets removed. For example, Drupal::l() continues to work in Drupal 8.7 despite the fact that it was deprecated in Drupal 8.0.0 more than three years ago. This gives module maintainers ample time to update their code.

When we release Drupal 9, we will "drop" most deprecated code. In our example, this means that Drupal::l() will not be available anymore in Drupal 9.

In other words:

Any Drupal 8 module that does not use deprecated code will continue to work with Drupal 9.
Any Drupal 8 module that uses deprecated code needs to be updated before Drupal 9 is released, or it will stop working with Drupal 9.
If you're interested, you can read more about Drupal's deprecation policy at https://www.drupal.org/core/deprecation.

How do I know if my site uses deprecated code?

There are a few ways to check if your site is using deprecated code.

If you work on a Drupal site as a developer, run drupal-check. Matt Glaman (Centarro) developed a static PHP analysis tool called drupal-check, which you can run against your codebase to check for deprecated code. I recommend running drupal-check in an automated fashion as part of your development workflow.

If you are a site owner, install the Upgrade Status module. This module was built by Acquia. The module provides a graphical user interface on top of drupal-check. The goal is to provide an easy-to-use readiness assessment for your site's migration to Drupal 9.

If you maintain a project on Drupal.org, enable Drupal.org's testing infrastructure to detect the use of deprecated code. There are two complementary ways to do so: you can run a static deprecation analysis and/or configure your existing tests to fail when calling deprecated code. Both can be set up in your drupalci.yml configuration file.

If you find deprecated code in a contributed module used on your site, consider filing an issue in the module's issue queue on Drupal.org (after having checked no issue has been created yet). If you can, provide a patch to fix the deprecation and engage with the maintainer to get it committed.

How hard is it to update my code?

While there are some deprecations that require more detailed refactoring, many are a simple matter of search-and-replace.

You can check the API documentation for instructions on how to remedy the deprecation.

When can I start updating my code?

I encourage you to start today. When you update your Drupal 8 code to use the latest and greatest APIs, you can benefit from those improvements immediately. There is no reason to wait until Drupal 9 is released.

Drupal 8.8.0 will be the last release to deprecate for Drupal 9. Today, we don't know the full set of deprecations yet.

How much time do I have to update my code?

The current plan is to release Drupal 9 in June of 2020, and to end-of-life Drupal 8 in November of 2021.

Contributed module maintainers are encouraged to remove the use of deprecated code by June of 2020 so everyone can upgrade to Drupal 9 the day it is released.

Drupal.org project maintainers should keep the extended security coverage policy in mind, which means that Drupal 8.8 will still be supported until Drupal 9.1 is released. Contributed projects looking to support both Drupal 8.8 and Drupal 9.0 might need to use two branches.

How ready are the contributed modules?

Dwayne McDaniel (Pantheon) analyzed all 7,000 contributed module for Drupal 8 using drupal-check.

As it stands today, 44% of the modules have no deprecation warnings. The remaining 56% of the modules need to be updated, but the majority have less than three deprecation warnings.
Source: Dries Buytaert www.buytaert.net


Refreshing the Drupal administration UI

Last year, I talked to nearly one hundred Drupal agency owners to understand what is preventing them from selling Drupal. One of the most common responses raised is that Drupal's administration UI looks outdated.

This critique is not wrong. Drupal's current administration UI was originally designed almost ten years ago when we were working on Drupal 7. In the last ten years, the world did not stand still; design trends changed, user interfaces became more dynamic and end-user expectations have changed with that.

To be fair, Drupal's administration UI has received numerous improvements in the past ten years; Drupal 8 shipped with a new toolbar, an updated content creation experience, more WYSIWYG functionality, and even some design updates.

A comparison of the Drupal 7 and Drupal 8 content creation screen to highlight some of the improvements in Drupal 8.

While we made important improvements between Drupal 7 and Drupal 8, the feedback from the Drupal agency owners doesn't lie: we have not done enough to keep Drupal's administration UI modern and up-to-date.

This is something we need to address.

We are introducing a new design system that defines a complete set of principles, patterns, and tools for updating Drupal's administration UI.

In the short term, we plan on updating the existing administration UI with the new design system. Longer term, we are working on creating a completely new JavaScript-based administration UI.

The content administration screen with the new design system.

As you can see on Drupal.org, community feedback on the proposal is overwhelmingly positive with comments like Wow! Such an improvement! and Well done! High contrast and modern look..

Sample space sizing guidelines from the new design system.I also ran the new design system by a few people who spend their days selling Drupal and they described it as "clean" with "good use of space" and a design they would be confident showing to prospective customers.

Whether you are a Drupal end-user, or in the business of selling Drupal, I recommend you check out the new design system and provide your feedback on Drupal.org.

Special thanks to Cristina Chumillas, Sascha Eggenberger, Roy Scholten, Archita Arora, Dennis Cohn, Ricardo Marcelino, Balazs Kantor, Lewis Nyman,and Antonella Severo for all the work on the new design system so far!

We have started implementing the new design system as a contributed theme with the name Claro. We are aiming to release a beta version for testing in the spring of 2019 and to include it in Drupal core as an experimental theme by Drupal 8.8.0 in December 2019. With more help, we might be able to get it done faster.

Throughout the development of the refreshed administration theme, we will run usability studies to ensure that the new theme indeed is an improvement over the current experience, and we can iteratively improve it along the way.

Acquia has committed to being an early adopter of the theme through the Acquia Lightning distribution, broadening the potential base of projects that can test and provide feedback on the refresh. Hopefully other organizations and projects will do the same.
How can I help?

The team is looking for more designers and frontend developers to get involved. You can attend the weekly meetings on #javascript on Drupal Slack Mondays at 16:30 UTC and on #admin-ui on Drupal Slack Wednesdays at 14:30 UTC.

Thanks to Lauri Eskola, Gábor Hojtsy and Jeff Beeman for their help with this post.
Source: Dries Buytaert www.buytaert.net


Better image performance on dri.es

For a few years now I've been planning to add support for responsive images to my site.

The past two weeks, I've had to take multiple trips to the West Coast of the United States; last week I traveled from Boston to San Diego and back, and this week I'm flying from Boston to San Francisco and back. I used some of that airplane time to add responsive image support to my site, and just pushed it to production from 30,000 feet in the air!

When a website supports responsive images, it allows a browser to choose between different versions of an image. The browser will select the most optimal image by taking into account not only the device's dimensions (e.g. mobile vs desktop) but also the device's screen resolution (e.g. regular vs retina) and the browser viewport (e.g. full-screen browser or not). In theory, a browser could also factor in the internet connection speed but I don't think they do.

First of all, with responsive image support, images should always look crisp (I no longer serve an image that is too small for certain devices). Second, my site should also be faster, especially for people using older smartphones on low-bandwidth connections (I no longer serve an image that is too big for an older smartphone).

Serving the right image to the right device can make a big difference in the user experience.

Many articles suggest supporting three image sizes, however, based on my own testing with Chrome's Developer Tools, I didn't feel that three sizes was sufficient. There are so many different screen sizes and screen resolutions today that I decided to offer six versions of each image: 480, 640, 768, 960, 1280 and 1440 pixels wide. And I'm on the fence about adding 1920 as a seventh size.

Because I believe in being in control of my own data, I host almost 10,000 original images on my site. This means that in addition to the original images, I now also store 60,000 image variants. To further improve the site experience, I'm contemplating adding WebP variants as well — that would bring the total number of stored images to 130,000.

If you notice that my photos are clearer and/or page delivery a bit faster, this is why. Through small changes like these, my goal is to continue to improve the user experience on dri.es.
Source: Dries Buytaert www.buytaert.net


Working toward a JavaScript-driven Drupal administration interface

As web applications have evolved from static pages to application-like experiences, end-users' expectations of websites have become increasingly demanding. JavaScript, partnered with effective user-experience design, enable the seamless, instantaneous interactions that users now expect.
The Drupal project anticipated this trend years ago and we have been investing heavily in making Drupal API-first ever since. As a result, more organizations are building decoupled applications served by Drupal. This approach allows organizations to use modern JavaScript frameworks, while still benefiting from Drupal's powerful content management capabilities, such as content modeling, content editing, content workflows, access rights and more.
While organizations use JavaScript frameworks to create visitor-facing experiences with Drupal as a backend, Drupal's own administration interface has not yet embraced a modern JavaScript framework. There is high demand for Drupal to provide a cutting-edge experience for its own users: the site's content creators and administrators.
At DrupalCon Vienna, we decided to start working on an alternative Drupal administrative UI using React. Sally Young, one of the initiative coordinators, recently posted a fantastic update on our progress since DrupalCon Vienna.
Next steps for Drupal's API-first and JavaScript work
While we made great progress improving Drupal's web services support and improving our JavaScript support, I wanted to use this blog post to compile an overview of some of our most important next steps:
1. Stabilize the JSON API module
JSON API is a widely-used specification for building web service APIs in JSON. We are working towards adding JSON API to Drupal core as it makes it easier for JavaScript developers to access the content and configuration managed in Drupal. There is a central plan issue that lists all of the blockers for getting JSON API into core (comprehensive test coverage, specification compliance, and more). We're working hard to get all of them out of the way!
2. Improve our JavaScript testing infrastructure
Drupal's testing infrastructure is excellent for testing PHP code, but until now, it was not optimized for testing JavaScript code. As we expect the amount of JavaScript code in Drupal's administrative interface to dramatically increase in the years to come, we have been working on improving our JavaScript testing infrastructure using Headless Chrome and Nightwatch.js. Nightwatch.js has already been committed for inclusion in Drupal 8.6, however some additional work remains to create a robust JavaScript-to-Drupal bridge. Completing this work is essential to ensure we do not introduce regressions, as we proceed with the other items in our roadmap.
3. Create designs for a React-based administration UI
Having a JavaScript-based UI also allows us to rethink how we can improve Drupal's administration experience. For example, Drupal's current content modeling UI requires a lot of clicking, saving and reloading. By using React, we can reimagine our user experience to be more application-like, intuitive and faster to use. We still need a lot of help to design and test different parts of the Drupal administration UI.
4. Allow contributed modules to use React or Twig
We want to enable modules to provide either a React-powered administration UI or a traditional Twig-based administration UI. We are working on an architecture that can support both at the same time. This will allow us to introduce JavaScript-based UIs incrementally instead of enforcing a massive paradigm shift all at once. It will also provide some level of optionality for modules that want to opt-out from supporting the new administration UI.
5. Implement missing web service APIs
While we have been working for years to add web service APIs to many parts of Drupal, not all of Drupal has web services support yet. For our React-based administration UI prototype we decided to implement a new permission screen (i.e. https://example.com/admin/people/permissions). We learned that Drupal lacked the necessary web service APIs to retrieve a list of all available permissions in the system. This led us to create a support module that provides such an API. This support module is a temporary solution that helped us make progress on our prototype; the goal is to integrate these APIs into core itself. If you want to contribute to Drupal, creating web service APIs for various Drupal subsystems might be a great way to get involved.
6. Make the React UI extensible and configurable
One of the benefits of Drupal's current administration UI is that it can be configured (e.g. you can modify the content listing because it has been built using the Views module) and extended by contributed modules (e.g. the Address module adds a UI that is optimized for editing address information). We want to make sure that in the new React UI we keep enough flexibility for site builders to customize the administrative UI.
All decoupled builds benefit
All decoupled applications will benefit from the six steps above; they're important for building a fully-decoupled administration UI, and for building visitor-facing decoupled applications.

Useful for decoupling of visitor-facing front-ends
Useful for decoupling of the administration backend
1. Stabilize the JSON API module


2. Improve our JavaScript testing infrastructure


3. Create designs for a React-based administration UI


4. Allow contributed modules to use React or Twig


5. Implement missing web service APIs


6. Make the React UI extensible and configurable


Conclusion
Over the past three years we've been making steady progress to move Drupal to a more API-first and JavaScript centric world. It's important work given a variety of market trends in our industry. While we have made excellent progress, there are more challenges to be solved. We hope you like our next steps, and we welcome you to get involved with them. Thank you to everyone who has contributed so far!
Special thanks to Matt Grill and Lauri Eskola for co-authoring this blog post and to Wim Leers, Gabe Sullice, Angela Byron, and Preston So for their feedback during the writing process.
Source: Dries Buytaert www.buytaert.net


Acquia blocks 500,000 attack attempts for SA-CORE-2018-002

On March 28th, the Drupal Security Team released a bug fix for a critical security vulnerability, named SA-CORE-2018-002. Over the past week, various exploits have been identified, as attackers have attempted to compromise unpatched Drupal sites. Hackers continue to try to exploit this vulnerability, and
Acquia's own security team has observed more than 100,000 attacks a day.

The SA-CORE-2018-002 security vulnerability is highly critical; it allows an unauthenticated attacker to perform remote code execution on most Drupal installations. When the Drupal Security Team made the security patch available, there were no publicly known exploits or attacks against SA-CORE-2018-002.

That changed six days ago, after Checkpoint Research provided a detailed explanation of the SA-CORE-2018-002 security bug, in addition to step-by-step instructions that explain how to exploit the vulnerability. A few hours after Checkpoint Research's blog post, Vitalii Rudnykh, a Russian security researcher, shared a proof-of-concept exploit on GitHub. Later that day, Acquia's own security team began to witness attempted attacks.

The article by Checkpoint Research and Rudnykh's proof-of-concept code have spawned numerous exploits, which are written in different programming languages such as Ruby, Bash, Python and more. As a result, the number of attacks have grown significantly over the past few days.

Fortunately, Acquia deployed a platform level mitigation for all Acquia Cloud customers one hour after the Drupal Security Team made the SA-CORE-2018-002 release available on March 28th. Over the past week, Acquia has observed over 500,000 attacks from more than 3,000 different IP addresses across our fleet of servers and customer base. To the best of our knowledge, every attempted exploitation of an Acquia customer has failed.The scale and the severity of this attack suggests that if you failed to upgrade your Drupal sites, or your site is not supported by Acquia Cloud or another trusted vendor that provides platform level fixes, the chances of your site being hacked are very high. If you haven't upgraded your site yet and you are not on a protected platform then assume your site is compromised. Restore from a backup taken before the vulnerability was announced and upgrade before putting the site back online.

Drupal's responsible disclosure policy

It's important to keep in mind that all software has security bugs, and fortunately for Drupal, critical security bugs are rare. It's been nearly four years since the Drupal Security Team published a security release for Drupal core that is this critical.

What matters is how software projects or software vendors deal with security bugs. The Drupal Security Team follows a "coordinated disclosure policy": issues remain private until there is a published fix. A public announcement is made when the threat has been addressed and a secure version of Drupal core is also available. Even when a bug fix is made available, the Drupal Security Team is very thoughtful with its communication. The team is careful to withhold as many details about the vulnerability as possible to make it difficult for hackers to create an exploit, and to buy Drupal site owners as much time as possible to upgrade. In this case, Drupal site owners had two weeks before the first public exploits appeared.

Historically, many proprietary CMS vendors have executed a different approach, and don't always disclose security bugs. Instead, they often fix bugs silently. In this scenario, secrecy might sound like a good idea; it prevents sites from being hacked and it avoids bad PR. However, hiding vulnerabilities provides a false sense of security, which can make matters much worse. This approach also functions under the assumption that hackers can't find security problems on their own. They can, and when they do, even more sites are at risk of being compromised.

Drupal's approach to security is best-in-class — from fixing the bug, testing the solution, providing advance notice, coordinating the release, being thoughtful not to over communicate too many details, being available for press inquiries, and repeatedly reminding everyone to upgrade.

Acquia's platform level fix

In addition to the Drupal Security Team's responsible disclosure policy, Acquia's own security team has been closely monitoring attempted attacks on our infrastructure. Following the release of the Checkpoint Research article, Acquia has tracked the origin of the 500,000 attempted attacks:

This image captures the geographic distribution of SA-CORE-2018-002 attacks against Acquia's customers. The number denoted in each bubble is the total number of attacks that came from that location.To date, over 50 percent of the attempted attacks Acquia has witnessed originate from the Ukraine:

At Acquia, we provide customers with automatic security patching of both infrastructure and Drupal code, in addition to platform level fixes for security bugs. Our commitment to keeping our customers safe is reflected in our push to release a platform level fix one hour after the Drupal Security Team made SA-CORE-2018-002 available. This mitigation covered all customers with Acquia Cloud Free, Acquia Cloud Professional, Acquia Cloud Enterprise, and Acquia Cloud Site Factory applications; giving our customers peace of mind while they upgraded their Drupal sites, with or without our help. This means that when attempted exploits and attacks first appeared in the wild, Acquia's customers were safe. As a best practice, Acquia always recommends that customers upgrade to the latest secure version of Drupal core, in addition to platform mitigations.

This blog post was co-authored by Dries Buytaert and Cash Williams.
Source: Dries Buytaert www.buytaert.net


Acquia blocks 500,000 attack attempts for SA-CORE-2018-002

On March 28th, the Drupal Security Team released a bug fix for a critical security vulnerability, named SA-CORE-2018-002. Over the past week, various exploits have been identified, as attackers have attempted to compromise unpatched Drupal sites. Hackers continue to try to exploit this vulnerability, and
Acquia's own security team has observed more than 100,000 attacks a day.

The SA-CORE-2018-002 security vulnerability is highly critical; it allows an unauthenticated attacker to perform remote code execution on most Drupal installations. When the Drupal Security Team made the security patch available, there were no publicly known exploits or attacks against SA-CORE-2018-002.

That changed six days ago, after Checkpoint Research provided a detailed explanation of the SA-CORE-2018-002 security bug, in addition to step-by-step instructions that explain how to exploit the vulnerability. A few hours after Checkpoint Research's blog post, Vitalii Rudnykh, a Russian security researcher, shared a proof-of-concept exploit on GitHub. Later that day, Acquia's own security team began to witness attempted attacks.

The article by Checkpoint Research and Rudnykh's proof-of-concept code have spawned numerous exploits, which are written in different programming languages such as Ruby, Bash, Python and more. As a result, the number of attacks have grown significantly over the past few days.

Fortunately, Acquia deployed a platform level mitigation for all Acquia Cloud customers one hour after the Drupal Security Team made the SA-CORE-2018-002 release available on March 28th. Over the past week, Acquia has observed over 500,000 attacks from more than 3,000 different IP addresses across our fleet of servers and customer base. To the best of our knowledge, every attempted exploitation of an Acquia customer has failed.The scale and the severity of this attack suggests that if you failed to upgrade your Drupal sites, or your site is not supported by Acquia Cloud or another trusted vendor that provides platform level fixes, the chances of your site being hacked are very high. If you haven't upgraded your site yet and you are not on a protected platform then assume your site is compromised. Rebuild your host, reinstall Drupal from a backup taken before the vulnerability was announced and upgrade before putting the site back online. (Update: restoring a Drupal site from backup may not be sufficient as some of the exploits reinstall themselves from crontab. You should assume the whole host is compromised.)

Drupal's responsible disclosure policy

It's important to keep in mind that all software has security bugs, and fortunately for Drupal, critical security bugs are rare. It's been nearly four years since the Drupal Security Team published a security release for Drupal core that is this critical.

What matters is how software projects or software vendors deal with security bugs. The Drupal Security Team follows a "coordinated disclosure policy": issues remain private until there is a published fix. A public announcement is made when the threat has been addressed and a secure version of Drupal core is also available. Even when a bug fix is made available, the Drupal Security Team is very thoughtful with its communication. The team is careful to withhold as many details about the vulnerability as possible to make it difficult for hackers to create an exploit, and to buy Drupal site owners as much time as possible to upgrade. In this case, Drupal site owners had two weeks before the first public exploits appeared.

Historically, many proprietary CMS vendors have executed a different approach, and don't always disclose security bugs. Instead, they often fix bugs silently. In this scenario, secrecy might sound like a good idea; it prevents sites from being hacked and it avoids bad PR. However, hiding vulnerabilities provides a false sense of security, which can make matters much worse. This approach also functions under the assumption that hackers can't find security problems on their own. They can, and when they do, even more sites are at risk of being compromised.

Drupal's approach to security is best-in-class — from fixing the bug, testing the solution, providing advance notice, coordinating the release, being thoughtful not to over communicate too many details, being available for press inquiries, and repeatedly reminding everyone to upgrade.

Acquia's platform level fix

In addition to the Drupal Security Team's responsible disclosure policy, Acquia's own security team has been closely monitoring attempted attacks on our infrastructure. Following the release of the Checkpoint Research article, Acquia has tracked the origin of the 500,000 attempted attacks:

This image captures the geographic distribution of SA-CORE-2018-002 attacks against Acquia's customers. The number denoted in each bubble is the total number of attacks that came from that location.To date, over 50 percent of the attempted attacks Acquia has witnessed originate from the Ukraine:

At Acquia, we provide customers with automatic security patching of both infrastructure and Drupal code, in addition to platform level fixes for security bugs. Our commitment to keeping our customers safe is reflected in our push to release a platform level fix one hour after the Drupal Security Team made SA-CORE-2018-002 available. This mitigation covered all customers with Acquia Cloud Free, Acquia Cloud Professional, Acquia Cloud Enterprise, and Acquia Cloud Site Factory applications; giving our customers peace of mind while they upgraded their Drupal sites, with or without our help. This means that when attempted exploits and attacks first appeared in the wild, Acquia's customers were safe. As a best practice, Acquia always recommends that customers upgrade to the latest secure version of Drupal core, in addition to platform mitigations.

This blog post was co-authored by Dries Buytaert and Cash Williams.
Source: Dries Buytaert www.buytaert.net


State of Drupal presentation (April 2018)

© Yes Moon
Last week, I shared my State of Drupal presentation at Drupalcon Nashville. In addition to sharing my slides, I wanted to provide more information on how you can participate in the various initiatives presented in my keynote, such as growing Drupal adoption or evolving our community values and principles.
Drupal 8 update

During the first portion of my presentation, I provided an overview of Drupal 8 updates. Last month, the Drupal community celebrated an important milestone with the successful release of Drupal 8.5, which ships with improved features for content creators, site builders, and developers.

Drupal 8 continues to gain momentum, as the number of Drupal 8 sites has grown 51 percent year-over-year:

This graph depicts the number of Drupal 8 sites built since April 2015. Last year there were 159,000 sites and this year there are 241,000 sites, representing a 51% increase year-over-year.Drupal 8's module ecosystem is also maturing quickly, as 81 percent more Drupal 8 modules have become stable in the past year:

This graph depicts the number of modules now stable since January 2016. This time last year there were 1,028 stable projects and this year there are 1,860 stable projects, representing an 81% increase year-over-year.As you can see from the Drupal 8 roadmap, improving the ease of use for content creators remains our top priority:

This roadmap depicts Drupal 8.5, 8.6, and 8.7+, along with a column for "wishlist" items that are not yet formally slotted. The contents of this roadmap can be found at https://www.drupal.org/core/roadmap.Four ways to grow Drupal adoption

Drupal 8 was released at the end of 2015, which means our community has had over two years of real-world experience with Drupal 8. It was time to take a step back and assess additional growth initiatives based on what we have learned so far.

In an effort to better understand the biggest hurdles facing Drupal adoption, we interviewed over 150 individuals around the world that hold different roles within the community. We talked to Drupal front-end and back-end developers, contributors, trainers, agency owners, vendors that sell Drupal to customers, end users, and more. Based on their feedback, we established four goals to help accelerate Drupal adoption.

Goal 1: Improve the technical evaluation process

Matthew Grasmick recently completed an exercise in which he assessed the technical evaluator experience of four different PHP frameworks, and discovered that Drupal required the most steps to install. Having a good technical evaluator experience is critical, as it has a direct impact on adoption rates.

To improve the Drupal evaluation process, we've proposed the following initiatives:
Initiative
Issue link
Stakeholders
Initiative coordinator
Status
Better discovery experience on Drupal.org
Drupal.org roadmap
Drupal Association
hestenet
Under active development
Better "getting started" documentation
#2956879
Documentation Working Group
grasmash
In planning
More modern administration experience
#2957457
Core contributors
ckrina and yoroy
Under active development
To become involved with one of these initiatives, click on its "Issue link" in the table above. This will take you to Drupal.org, where you can contribute by sharing your ideas or lending your expertise to move an initiative forward.

Goal 2: Improve the content creator experience

Throughout the interview process, it became clear that ease of use is a feature now expected of all technology. For Drupal, this means improving the content creator experience through a modern administration user interface, drag-and-drop media management and page building, and improved site preview functionality.

The good news is that all of these features are already under development through the Media, Workflow, Layout and JavaScript Modernization initiatives.

Most of these initiative teams meet weekly on Drupal Slack (see the meetings calendar), which gives community members an opportunity to meet team members, receive information on current goals and priorities, and volunteer to contribute code, testing, design, communications, and more.

Goal 3: Improve the site builder experience

Our research also showed that to improve the site builder experience, we should focus on improving the three following areas:
The configuration management capabilities in core need to support more common use cases out-of-the-box.
Composer and Drupal core should be better integrated to empower site builders to manage dependencies and keep Drupal sites up-to-date.
We should provide a longer grace period between required core updates so development teams have more time to prepare, test, and upgrade their Drupal sites after each new minor Drupal release.
We plan to make all of these aspects easier for site builders through the following initiatives:
Initiative
Issue link
Stakeholders
Initiative coordinator
Status
Composer & Core
#2958021
Core contributors + Drupal Association
Coordinator needed!
Proposed
Config Management 2.0
#2957423
Core contributors
Coordinator needed!
Proposed
Security LTS
2909665
Core committers + Drupal Security Team + Drupal Association
Core committers and Security team
Proposed, under discussion
Goal 4: Promote Drupal to non-technical decision makers

The fourth initiative is unique as it will help our community to better communicate the value of Drupal to the non-technical decision makers. Today, marketing executives and content creators often influence the decision behind what CMS an organization will use. However, many of these individuals are not familiar with Drupal or are discouraged by the misconception that Drupal is primarily for developers.

With these challenges in mind, the Drupal Association has launched the Promote Drupal Initiative. This initiative will include building stronger marketing and branding, demos, events, and public relations resources that digital agencies and local associations can use to promote Drupal. The Drupal Association has set a goal of fundraising $100,000 to support this initiative, including the hiring of a marketing coordinator.

Megan Sanicki and her team have already raised $54,000 from over 30 agencies and 5 individual sponsors in only 4 days. Clearly this initiative resonates with Drupal agencies. Please consider how you or your organization can contribute.

Fostering community with values and principles

This year at DrupalCon Nashville, over 3,000 people traveled to the Music City to collaborate, learn, and connect with one another. It's at events like DrupalCon where the impact of our community becomes tangible for many. It also serves as an important reminder that while Drupal has grown a great deal since the early days, the work needed to scale our community is never done.

Prompted by feedback from our community, I have spent the past five months trying to better establish the Drupal community's principles and values. I have shared an "alpha" version of Drupal's values and principles at https://www.drupal.org/about/values-and-principles. As a next step, I will be drafting a charter for a new working group that will be responsible for maintaining and improving our values and principles. In the meantime, I invite every community member to provide feedback in the issue queue of the Drupal governance project.

An overview of Drupal's values with supporting principles.I believe that taking time to highlight community members that exemplify each principle can make the proposed framework more accessible. That is why it was very meaningful for me to spotlight three Drupal community members that demonstrate these principles.

Principle 1: Optimize for Impact - Rebecca Pilcher

Rebecca shares a remarkable story about Drupal's impact on her Type 1 diabetes diagnosis:

Principle 5: Everyone has something to contribute - Mike Lamb

Mike explains why Pfizer contributes millions to Drupal:

Principle 6: Choose to Lead - Mark Conroy

Mark tells the story of his own Drupal journey, and how his experience inspired him to help other community members:

Watch the keynote or download my slides

In addition to the community spotlights, you can also watch a recording of my keynote (starting at 19:25), or you can download a copy of my slides (164 MB).


Source: Dries Buytaert www.buytaert.net


State of Drupal presentation (April 2018)

© Yes Moon
Last week, I shared my State of Drupal presentation at Drupalcon Nashville. In addition to sharing my slides, I wanted to provide more information on how you can participate in the various initiatives presented in my keynote, such as growing Drupal adoption or evolving our community values and principles.
Drupal 8 update

During the first portion of my presentation, I provided an overview of Drupal 8 updates. Last month, the Drupal community celebrated an important milestone with the successful release of Drupal 8.5, which ships with improved features for content creators, site builders, and developers.

Drupal 8 continues to gain momentum, as the number of Drupal 8 sites has grown 51 percent year-over-year:

This graph depicts the number of Drupal 8 sites built since April 2015. Last year there were 159,000 sites and this year there are 241,000 sites, representing a 51% increase year-over-year.Drupal 8's module ecosystem is also maturing quickly, as 81 percent more Drupal 8 modules have become stable in the past year:

This graph depicts the number of modules now stable since January 2016. This time last year there were 1,028 stable projects and this year there are 1,860 stable projects, representing an 81% increase year-over-year.As you can see from the Drupal 8 roadmap, improving the ease of use for content creators remains our top priority:

This roadmap depicts Drupal 8.5, 8.6, and 8.7+, along with a column for "wishlist" items that are not yet formally slotted. The contents of this roadmap can be found at https://www.drupal.org/core/roadmap.Four ways to grow Drupal adoption

Drupal 8 was released at the end of 2015, which means our community has had over two years of real-world experience with Drupal 8. It was time to take a step back and assess additional growth initiatives based on what we have learned so far.

In an effort to better understand the biggest hurdles facing Drupal adoption, we interviewed over 150 individuals around the world that hold different roles within the community. We talked to Drupal front-end and back-end developers, contributors, trainers, agency owners, vendors that sell Drupal to customers, end users, and more. Based on their feedback, we established four goals to help accelerate Drupal adoption.

Goal 1: Improve the technical evaluation process

Matthew Grasmick recently completed an exercise in which he assessed the technical evaluator experience of four different PHP frameworks, and discovered that Drupal required the most steps to install. Having a good technical evaluator experience is critical, as it has a direct impact on adoption rates.

To improve the Drupal evaluation process, we've proposed the following initiatives:
Initiative
Issue link
Stakeholders
Initiative coordinator
Status
Better discovery experience on Drupal.org
Drupal.org roadmap
Drupal Association
hestenet
Under active development
Better "getting started" documentation
#2956879
Documentation Working Group
grasmash
In planning
More modern administration experience
#2957457
Core contributors
ckrina and yoroy
Under active development
To become involved with one of these initiatives, click on its "Issue link" in the table above. This will take you to Drupal.org, where you can contribute by sharing your ideas or lending your expertise to move an initiative forward.

Goal 2: Improve the content creator experience

Throughout the interview process, it became clear that ease of use is a feature now expected of all technology. For Drupal, this means improving the content creator experience through a modern administration user interface, drag-and-drop media management and page building, and improved site preview functionality.

The good news is that all of these features are already under development through the Media, Workflow, Layout and JavaScript Modernization initiatives.

Most of these initiative teams meet weekly on Drupal Slack (see the meetings calendar), which gives community members an opportunity to meet team members, receive information on current goals and priorities, and volunteer to contribute code, testing, design, communications, and more.

Goal 3: Improve the site builder experience

Our research also showed that to improve the site builder experience, we should focus on improving the three following areas:
The configuration management capabilities in core need to support more common use cases out-of-the-box.
Composer and Drupal core should be better integrated to empower site builders to manage dependencies and keep Drupal sites up-to-date.
We should provide a longer grace period between required core updates so development teams have more time to prepare, test, and upgrade their Drupal sites after each new minor Drupal release.
We plan to make all of these aspects easier for site builders through the following initiatives:
Initiative
Issue link
Stakeholders
Initiative coordinator
Status
Composer & Core
#2958021
Core contributors + Drupal Association
Coordinator needed!
Proposed
Config Management 2.0
#2957423
Core contributors
Coordinator needed!
Proposed
Security LTS
2909665
Core committers + Drupal Security Team + Drupal Association
Core committers and Security team
Proposed, under discussion
Goal 4: Promote Drupal to non-technical decision makers

The fourth initiative is unique as it will help our community to better communicate the value of Drupal to the non-technical decision makers. Today, marketing executives and content creators often influence the decision behind what CMS an organization will use. However, many of these individuals are not familiar with Drupal or are discouraged by the misconception that Drupal is primarily for developers.

With these challenges in mind, the Drupal Association has launched the Promote Drupal Initiative. This initiative will include building stronger marketing and branding, demos, events, and public relations resources that digital agencies and local associations can use to promote Drupal. The Drupal Association has set a goal of fundraising $100,000 to support this initiative, including the hiring of a marketing coordinator.

Megan Sanicki and her team have already raised $54,000 from over 30 agencies and 5 individual sponsors in only 4 days. Clearly this initiative resonates with Drupal agencies. Please consider how you or your organization can contribute.

Fostering community with values and principles

This year at DrupalCon Nashville, over 3,000 people traveled to the Music City to collaborate, learn, and connect with one another. It's at events like DrupalCon where the impact of our community becomes tangible for many. It also serves as an important reminder that while Drupal has grown a great deal since the early days, the work needed to scale our community is never done.

Prompted by feedback from our community, I have spent the past five months trying to better establish the Drupal community's principles and values. I have shared an "alpha" version of Drupal's values and principles at https://www.drupal.org/about/values-and-principles. As a next step, I will be drafting a charter for a new working group that will be responsible for maintaining and improving our values and principles. In the meantime, I invite every community member to provide feedback in the issue queue of the Drupal governance project.

An overview of Drupal's values with supporting principles.I believe that taking time to highlight community members that exemplify each principle can make the proposed framework more accessible. That is why it was very meaningful for me to spotlight three Drupal community members that demonstrate these principles.

Principle 1: Optimize for Impact - Rebecca Pilcher

Rebecca shares a remarkable story about Drupal's impact on her Type 1 diabetes diagnosis:

Principle 5: Everyone has something to contribute - Mike Lamb

Mike explains why Pfizer contributes millions to Drupal:

Principle 6: Choose to Lead - Mark Conroy

Mark tells the story of his own Drupal journey, and how his experience inspired him to help other community members:

Watch the keynote or download my slides

In addition to the community spotlights, you can also watch a recording of my keynote (starting at 19:25), or you can download a copy of my slides (164 MB).


Source: Dries Buytaert www.buytaert.net


Thanks to the Drupal Security Team for keeping us safe

We released new versions of Drupal 7 and Drupal 8 yesterday that fixed a highly critical security bug. All software has security bugs, and fortunately for Drupal, critical security bugs are rare. What matters is how you deal with security releases.
I have the utmost respect for how the Drupal Security Team manages a security release like this — from fixing the bug, testing the solution, providing advance notice, coordinating the release, to being available for press inquiries and more.
The amount of effort, care and dedication that the Drupal Security Team invests to keep Drupal secure is unparalleled, and makes Drupal's security best-in-class. Thank you!
Source: Dries Buytaert www.buytaert.net


Thanks to the Drupal Security Team for keeping us safe

We released new versions of Drupal 7 and Drupal 8 yesterday that fixed a highly critical security bug. All software has security bugs, and fortunately for Drupal, critical security bugs are rare. What matters is how you deal with security releases.
I have the utmost respect for how the Drupal Security Team manages a security release like this — from fixing the bug, testing the solution, providing advance notice, coordinating the release, to being available for press inquiries and more.
The amount of effort, care and dedication that the Drupal Security Team invests to keep Drupal secure is unparalleled, and makes Drupal's security best-in-class. Thank you!
Source: Dries Buytaert www.buytaert.net


Features as Apps

One of the most important things that I’ve learned when it comes to building technology products, especially at the super early-stage, is the reality that designing a real MVP (Minimum Viable Product) is incredibly difficult to do.
I’ve already talked about this once or twice on this blog before…

The challenge of keeping things MVP-ish is real and they mostly stem from these two issues / challenges:

The availability of robust frameworks and APIs make it far too easy to (accidentally) scale a simple experiment based on a simple hypothesis into more than just a simple MVP.
It is psychologically difficult to minimize, constrain, and limit our “vision” of what could be with what should be, especially with so many existing examples to compare to (and the availability of great tooling – see #1).

Practice, a shit-ton of discipline, and a hyper-judicious pragmatic framework are necessary to stay trim, stay lean, and to execute the smallest technological experiment possible.
And having an exceptionally-focused cofounder / partner / team is also a very useful and practical counterweight to keep one from moving beyond what is absolutely, fundamentally necessary.
Consequently, in my own practice, I’ve started to internalize a particular mantra that I haven’t really heard before… maybe I’ll coin the term and see if anyone challenges me on it… 
The term is “Features as Apps” and it is the philosophy and practice of building single-serve apps to see if real users will, in fact, use that particular “feature” that might exist in the much larger, future-state application.
I’ll give you an example…
After we had built a small-yet-growing community @ The Bitcoin Pub we began to hear from our users that they wished “this” and “that” existed within the forum itself. Some examples were:

Charting tools for technical analysis for cryptocurrency
More communication tools (e.g. real-time chat)
Notification systems for pricing data
Deeper integration with news sources
Calculators and conversion tools
Buying / Selling of cryptocurrencies
And many, many more…

Instead of spending a significant time building additional features within the larger framework of software we decided to deploy “Features as Apps” into the wild, putting together much smaller apps and websites to validate if these requests were real and true.
As a result, we built things like CoinPuffs and CryptoYum (soon to be released) and even experimented on the “Features” themselves, essentially, Features of Features as Apps.
A great example is CoinPuffs where we recently added a small site off of the main site that allows users to create and establish email alerts for cryptocurrency pricing:

You can easily create a new email alert via the button and then manage them in a simple backend interface:

The question, of course, is whether folks would actually use it (or not). If they do, then, we can roll this feature into the much larger application layer of either CoinPuffs or even The Bitcoin Pub.
There’s not a lot of risk associated with creating these super-small, single-serve apps that serve as features for much bigger software projects. It just takes time and a serious commitment to testing one’s hypothesis over a given amount of time.
If it works out well then you’ve created more goodwill with your customers, deeper lock-in, and hopefully a high return on investment.
I like this model and it allows us to experiment with high-velocity too which, in turn, creates a lot of momentum. These things, of course, are our greatest strengths and it is our greatest asset as a early-stage startup.
The post Features as Apps appeared first on John Saddington.
Source: https://john.do/


Design Systems: Building a Parts Kit


In our series on design systems, we’ve discussed the advantages and approaches to creating a system from a design perspective. In this post, I’d like to cover some of the technical benefits of a well-organized built design system, or “parts kit”.
By now, you’re hopefully convinced of the benefits of a design system and are ready to invest the time and money to partner with an agency, like Viget, to create something that achieves your vision. The next step will be to apply it to your digital platforms by building it. But wait! If the design system represents your vision and investment, a good parts kit is like insurance that protects that vision when it goes out into the world.
The Importance of Building it Right
A well-constructed parts kit has many benefits that can ensure the consistency and longevity of a design system. The investment in integrationquality is equally important to the investment in design and will have a long-lasting effect on the success of the system.
Systems Are Easier to Maintain and Extend
One of the lesser-known challenges of building and launching a site is efficiently maintaining it after it’s launched. Ongoing work, big and small, can quickly bloat a codebase as developers unfamiliar with the project (or even original developers once they’ve moved on to other projects) drop in for bug fixes and new features. Without a system, these developers are forced to recreate the wheel every time, adding more and more to the codebase, making it unwieldy over time. With a well-organized system and parts kit for reference, developers can leverage past work to create new things. In some cases, new features and entire pages can be built with little or no addition to the parts kit.
Systems Lead to Better Code
Most developers, including the ones here at Viget, revel in building modular and systematized code. If you look under the hood of a site that’s made up of seemingly all unique parts and layouts, there will still be an underlying system that a developer sussed out. That’s because creating a system is at the heart of the DRY (Don’t Repeat Yourself) principle. Whether it’s a high-impact marketing site or a structured UI system for an application, building in a systematic and modular way results in well-organized and efficient code.
Systems Improve Workflow and Collaboration
In the same way that a visual design system communicates branding and consistency and provides a “source of truth” for everyone who needs to work with it, we have found that a parts kit is essential in a variety of working situations:
Post-Launch Transition to Client Team
Some of our projects result in turning over the day-to-day running of a site to an internal web team. From ongoing maintenance to adding new pages and features, building from, or extending, a parts kit is considerably faster and results in better consistency with the original system.
Framework Hand-Off
In other cases, the parts kit is itself the deliverable. For Rotary International, we worked with their highly-capable and enthusiastic internal integrationteam to deliver a framework specific to their design and content strategy. Their team integrated our work with their content management system for a site refresh and continue to utilize it as they produce new content.
Agency-Client Collaboration or Staff Augmentation
Whenever we work closely with external designers or developers, having a shared vocabulary is an essential communication tool. In building a parts kit, accessible by everyone on both teams, we’re able to have a reference point for conversations, whether it’s about design, interactivity, or quality assurance testing (QA).
Systems Expose and Enforce Design Consistency
Let’s face it, the design and review process can be brutal on design systems. On one project, I counted over 40 shades of gray that had sprawled like a family tree over successive generations of comps and revisions. In a built-what-you-see approach, I would have incorporated every color into the codebase and lost any structure around what gray was used for what. Instead, taking a systematic approach, I collected all the shades and presented them to the designer (he was embarrassed) so he could consolidate them down to a tidy eight. In this example, building with a system in mind allowed me to critically look at small variants in the design system and normalize them into a more streamlined and maintainable codebase.
Systems Provide a Deliverable And “Source of Truth”
As is discussed in many of the above examples, a parts kit can be a lasting and valuable reference for the original work. As sites grow and age, one of the keys to maintaining a consistent look and feel across all content, new and old, is to constantly refer back to the parts kit as the “source of truth”. Using it as a guiding light, future developers and content contributors can work more quickly and efficiently while maintaining the original vision of the design system.
Wrap Up
Building a design system into a parts kit is where the rubber meets the road — a static design becomes an interactive, usable thing. At Viget, we believe that a rigorous design process should be matched with equally robust development.
Resources
Building A Large-Scale Design System For The U.S. Government (Case Study) — Smashing MagazineDesign Systems Handbook - DesignBetter.CoBuilding a Visual Language – Airbnb Design


Source: VigetInspire


4 Books to Read for Inspiration and Insight

Every few months, I like to put together a list of books that I’ve read recently and that I think will help you in your pursuit of your copywriting and general life goals. With that said, here’s today’s list!
Design the Life You Love: A Step-by-Step Guide to Building a Meaningful Future by Ayse Birsel
Recently, I took a solo weekend retreat to clear my head and come up with some new ideas and new possibilities. Often, I’ll bring along questions to ponder throughout the weekend. This time, instead, I brought along an entire book.
Design the Life You Love was written by an industrial engineer and suggest using design thinking to deconstruct and then reconstruct your life. (Not to be confused with the other design thinking book, Design Your Life, which was also pretty good.) Through a series of exercises, Ayse Birsel coaches you to view aspects of your life and your values from a few different frames of reference with the end goal of configuring a new life plan and philosophy.
Considering I’ve read so many books like this, I was pleased to find several exercises that I hadn’t seen before. Also, as a writer, I like that several of the exercises involved drawing. (It’s good to force yourself to exercise a part of the brain that you rarely use.) For those of you who are ebook-lovers, I’d still recommend getting this one in print; it’s both helpful and inspiring to do the exercises right in the book.
Tribe of Mentors: Short Life Advice from the Best in the World by Tim Ferriss
Tim Ferriss is one of the original life-design gurus and probably most famous for his book, “The Four-Hour Workweek.” Since then, he’s also published several other books about optimal living. While I’m just a touch too lazy to try to actually optimize my life, I still appreciate some insightful information every once in a while.
Tribe of Mentors is compiled of short Q&As with experts and over-achievers in fields as far-ranging as skateboarding, venture capital, cooking, and outdoor survival. Each interviewee muses on things like the books they most often recommend and what habit or behavior has most improved their lives. Because each interviewee’s section is short, it’s easy to pick this book up when you have a free moment.
I found myself bookmarking multiple pages with insightful ideas, advice, or books to read. For you print book-lovers, this is one I’d actually probably recommend as an ebook; the print one (hardcover) is a massive 624 pages.
Smartcuts: The Breakthrough Power of Lateral Thinking by Shane Snow
Before buying this one, I read a review on Amazon that complained that the author didn’t actually tell you how to make “smartcuts” but just illustrated examples. After reading it, I can tell you that that’s kind of the point.
“Smartcuts” — as opposed to shortcuts, of course — are unusual, often lateral career moves that allow someone to advance further and faster than they would in a more conventional career path. Think: someone who slowly but surely climbs the corporate ladder to become CEO, versus someone who starts their own company, sells it, and then gets hired at another company to be the CEO. That’s a very banal example (and not one that’s in the book), but it should give you some idea.
The career trajectories of people like Michelle Phan, the SpaceX company, and even the Cuban Revolution make for interesting reads, and should inspire you to try to find a few smartcuts of your own.
The Productivity Project: Accomplishing More by Managing Your Time, Attention, and Energy by Chris Bailey
I’ll admit it: I’m a junkie for productivity books and have probably spent a lot more time reading them than I should have. (The irony is not lost on me.) What makes this one different is that the author spent a year of his life testing out various productivity techniques to report back on what worked and what didn’t.
You’ll likely see a few techniques you’ve already seen before, but his method for presenting them and the exercises he offered for implanting them made it all very interesting and well worth spending some time reading.
Your turn! Have you read any good books you’d like to recommend to the Filthy Rich Writer community? Let us know in the comments below!

Source: http://filthyrichwriter.com/feed/


Happy seventeenth birthday DrupalCoin


Seventeen years ago today, I open-sourced the software behind Drop.org and released DrupalCoin 1.0.0. When DrupalCoin was first founded, Google was in its infancy, the mobile web didn't exist, and JavaScript was a very unpopular word among developers.

Over the course of the past seventeen years, I've witnessed the nature of the web change and countless internet trends come and go. As we celebrate DrupalCoin's birthday, I'm proud to say it's one of the few content management systems that has stayed relevant for this long.

While the course of my career has evolved, DrupalCoin has always remained a constant. It's what inspires me every day, and the impact that DrupalCoin continues to make energizes me. Millions of people around the globe depend on DrupalCoin to deliver their business, mission and purpose. Looking at the DrupalCoin users in the video below gives me goosebumps.

DrupalCoin's success is not only marked by the organizations it supports, but also by our community that makes the project more than just the software. While there were hurdles in 2017, there were plenty of milestones, too:
At least 190,000 sites running DrupalCoin 8, up from 105,000 sites in January 2016 (80% year over year growth)
1,597 stable modules for DrupalCoin 8, up from 810 in January 2016 (95% year over year growth)
4,941 DrupalCoinCon attendees in 2017
41 DrupalCoinCamps held in 16 different countries in the world
7,240 individual code contributors, a 28% increase compared to 2016
889 organizations that contributed code, a 26% increase compared to 2016
13+ million visitors to DrupalCoin.org in 2017
76,374 instance hours for running automated tests (the equivalent of almost 9 years of continuous testing in one year)
Since DrupalCoin 1.0.0 was released, our community's ability to challenge the status quo, embrace evolution and remain resilient has never faltered. 2018 will be a big year for DrupalCoin as we will continue to tackle important initiatives that not only improve DrupalCoin's ease of use and maintenance, but also to propel DrupalCoin into new markets. No matter the challenge, I'm confident that the spirit and passion of our community will continue to grow DrupalCoin for many birthdays to come.

Tonight, we're going to celebrate DrupalCoin's birthday with a warm skillet chocolate chip cookie topped with vanilla ice cream. DrupalCoin loves chocolate! ;-)

Note: The video was created by Acquia, but it is freely available for anyone to use when selling or promoting DrupalCoin.
Source: Dries Buytaert www.buytaert.net


Massachusetts launches Mass.gov on DrupalCoin Blockchain

This year at Acquia Engage, the Commonwealth of Massachusetts launched Mass.gov on DrupalCoin Blockchain 8. Holly St. Clair, the Chief Digital Officer of the Commonwealth of Massachusetts, joined me during my keynote to share how Mass.gov is making constituents' interactions with the state fast, easy, meaningful, and "wicked awesome".
[youtube https://www.youtube.com/watch?v=dK4k2w7MZyY&w=640&h=360]
Since its founding, Acquia has been headquartered in Massachusetts, so it was very exciting to celebrate this milestone with the Mass.gov team.
Constituents at the center
Today, 76% of constituents prefer to interact with their government online. Before Mass.gov switched to DrupalCoin Blockchain it struggled to provide a constituent-centric experience. For example, a student looking for information on tuition assistance on Mass.gov would have to sort through 7 different government websites before finding relevant information.

To better serve residents, businesses and visitors, the Mass.gov team took a data-driven approach. After analyzing site data, they discovered that 10% of the content serviced 89% of site traffic. This means that up to 90% of the content on Mass.gov was either redundant, out-of-date or distracting. The digital services team used this insight to develop a site architecture and content strategy that prioritized the needs and interests of citizens. In one year, the team at Mass.gov moved a 15-year-old site from a legacy CMS to Acquia and DrupalCoin Blockchain.
The team at Mass.gov also incorporated user testing into every step of the redesign process, including usability, information architecture and accessibility. In addition to inviting over 330,000 users to provide feedback on the pilot site, the Mass.gov team partnered with the Perkins School for the Blind to deliver meaningful accessibility that surpasses compliance requirements. This approach has earned Mass.gov a score of 80.7 on the System Usability Scale; 12 percent higher than the reported average.
Open from the start
As an early adopter of DrupalCoin Blockchain 8, the Commonwealth of Massachusetts decided to open source the code that powers Mass.gov. Everyone can see the code that make Mass.gov work, point out problems, suggest improvements, or use the code for their own state. It's inspiring to see the Commonwealth of Massachusetts fully embrace the unique innovation and collaboration model inherent to open source. I wish more governments would do the same!
Congratulations Mass.gov
The new Mass.gov is engaging, intuitive and above all else, wicked awesome. Congratulations Mass.gov!
Source: Dries Buytaert www.buytaert.net


The Front-End Checklist is just a tool… everything depends on you.

One month ago, I launched the Front-End Checklist on GitHub. In less than 2 weeks, more than 10,000 people around the world starred the repository. That was completely unexpected and incredible!

I've been working as a front-end developer since 2011, but I started to build websites in 2000. Since then, like us all, I've been trying to improve the quality of my code and deliver websites faster. Along the way, I've been managing developers from two different countries. That has helped me to produce a checklist a little different than what I've found on around the web over the years.
While I was creating the checklist, I continuously had the book "The Checklist Manifesto: How to Get Things Right" by Atul Gawade in mind. That book has helped me build checklists for my work and personal life, and simplify things that sometimes seem too complex.

amzn_assoc_tracking_id = "csstricks-20";
amzn_assoc_ad_mode = "manual";
amzn_assoc_ad_type = "smart";
amzn_assoc_marketplace = "amazon";
amzn_assoc_region = "US";
amzn_assoc_design = "enhanced_links";
amzn_assoc_asins = "0312430000";
amzn_assoc_placement = "adunit";
amzn_assoc_linkid = "bc96260be7adede1459bf758a120d189";

If you are working alone or in a team, individually, remotely, or on-site, I wanted to share some advice on using the Front-End Checklist and the web application that goes with it. Perhaps I can convince you to integrate it into your integrationcycle.
#1 Decide which rules your project and team need to follow
Every project is different. Before starting a new project, the whole team (i.e. the project managers, designers, developers, QA, etc.) need to agree on what the deliverables will be.
To help you to decide, I created 3 different levels of priority: high, medium, and low. You don't necessarily need to agree with those distinctions, but they may help order your tasks.
The Front-End Checklist app was done to facilitate the creation of personalized checklists. Change some JSON files to your liking and you are ready to start!
#2 Define the rules to check at beginning, during, and at the end of your project
You shouldn't check all these rules only at the end of a project. You know as well as I do how projects are at the very end! Too hectic. Most of the items of the Front-End Checklist can be considered at the beginning of your development. It's up to you to decide. Make it clear to your team upfront what happens when.
#3 Learn a little more about each rules
Who loves reading the docs? Not most of us, but it's essential. If you want to understand the reasons for the rule, you can't avoid reading up about them. The more you understand the why of each rule, the better developer you become.
#4 Start to check!
The Front-End Checklist app can facilitate your life as a developer. It's a live checklist, so as you complete items your progress and grade are updated live. Everything is saved in localStorage so you can leave and come back as needed.
The project is open source, so feel free to fork it and use it however you like. I'm working on making sure all the files are commented. I especially invite those interested in Pug to take a look at the views folder.

#5 Integrate automated testing in your workflow
We all dream of automation (or is it just me?). For now, the Front-End Checklist is just an interactive list, but some of the tasks can be automated in your workflow.
Take a look at the gulpfile used to generate the project. All tasks are packages you can use with npm, webpack, etc.
#6 Validate every pages before sending to QA team and to production

If you're passionate about generating clean code and care about your code quality, you should be regularly testing your pages. It's so easy to make mistakes and remove some essential code. Or, someone else on your team might have done it, but it's your shared responsibilty to be catching things like that.
The Front-End Checklist can generate beautiful reports you can send to a project manager or Quality Assurance team.
#7 Enjoy your work above all
Some people might look at such a long checklist and feel sick to their stomach. Going through such a list might cause anxiety and really not be any fun.
But the Front-End Checklist is just a tool to help you deliver higher quality code. Code that affects all aspects of a project: the SEO, the user experience, the ROI, and ultimately the success of the project. A tool that can help across all those things might actually help reduce your anxiety and improve your health!
Conclusion
The success the Front-End Checklist received in such a short time reminded me that a lot of people are really interested in finding ways to improve their work. But just because the tool exists doesn't directly help with that. You also need to commit to using it.
In a time where AI is taking over many manual tasks, quality is a must-have. Even if automation takes over a lot of our tasks, some level of quality will remain impossible to automate, and us front-end developers still have many long days to enjoy our jobs.

The Front-End Checklist is just a tool… everything depends on you. is a post from CSS-Tricks
Source: CssTricks


Why Marketing & IT Should Invest in Automated Testing

Marketers are constantly working with IT to produce new websites, microsites, and digital platforms for their target audiences. Typically countless hours are spent testing these digital experiences for quality assurance before they go live. Many organizations still rely completely on manual testing, which is time-consuming for IT, frustrating for marketers, and expensive for organizations.
Source: https://www.phase2technology.com/feed/


An Idea for a Simple Responsive Spreadsheet

How do you make a spreadsheet-like interface responsive without the use of any JavaScript? This is the question I've been asking myself all week as I've been working on a new project and trying to figure out how to make the simplest spreadsheet possible. I wanted to avoid using a framework and instead, I decided to experiment with some new properties in order to use nothing but a light touch of CSS.

Spoilers! This is what I've come up with so far (oh and please note that this demo currently works in the latest version of Chrome). Try scrolling around a little bit:
See the Pen A Simple Responsive Spreadsheet – Final by Robin Rendle (@robinrendle) on CodePen.
Notice how the first column sticks to the left and the heading sticks to the top of the spreadsheet? This lets us scan lots of data without having to keep scrolling to figure out which column or row we're in — in a lot of interfaces like this it's pretty easy to get lost.
So how did I go about making this thing? Let's jump in!
Adding the markup
First we need to add our markup for the table and, just to make sure that this example is as realistic as possible, we're going to add a lot of rows and columns here:
See the Pen A Simple Responsive Spreadsheet – 1st by Robin Rendle (@robinrendle) on CodePen.
There's nothing really complex going on. We just have a regular ol' table with a <thead> and a <tbody>, but we do wrap the whole table in the table-wrapper div which I'll explain in just a little bit.
Next, we'll add basic styling to that wrapper element to move it into the center of the page and also give it a max-width. We also need to make sure that the .table-wrapper has overflow set to scroll, although at larger screen sizes we won't need that just yet:
body {
display: flex;
font-family: -apple-system;
font-size: 90%;
color: #333;
justify-content: center;
}

.table-wrapper {
max-width: 700px;
overflow: scroll;
}
See the Pen A Simple Responsive Spreadsheet – 2nd by Robin Rendle (@robinrendle) on CodePen.
Nifty! Now we can add styles for the first column of our table and the thead element as well as basic styling for each of the table cells:
table {
border: 1px solid #ddd;
border-collapse: collapse;
}

td, th {
white-space: nowrap;
border: 1px solid #ddd;
padding: 20px;
}
See the Pen A Simple Responsive Spreadsheet – 3 by Robin Rendle (@robinrendle) on CodePen.
The problem here is that we've now made a pretty inaccessible table; although we can scroll around in the spreadsheet we can't read which column or row is associated to which bit of data. This can lead to a table that is almost completely illegible and if we were to populate this with real data then it would be even worse:

position: sticky to the rescue!
position: sticky is a wonderfully handy CSS trick that I've started experimenting with a great deal lately. It lets you stick child elements to their parent containers so that as you scroll around the child element is always visible. And this is exactly what we need here for the first column and the heading of our table element.
We can use this relatively new feature with CSS like this:
// The heading of our table
th {
background-color: #eee;
position: sticky;
top: -1px;
z-index: 2;

// The first cell that lives in the top left of our spreadsheet
&:first-of-type {
left: 0;
z-index: 3;
}
}

// The first column that we want to stick to the left
tbody tr td:first-of-type {
background-color: #eee;
position: sticky;
left: -1px;
z-index: 1;
}
This z-index values are important here because we want the header to overlap the first left hand column that will also be sticky. However! We also want that empty cell at the top left to overlap both our header and our left hand column, like this:
See the Pen A Simple Responsive Spreadsheet – Final by Robin Rendle (@robinrendle) on CodePen.
But there we have it! A simple responsive spreadsheet where you can view both the heading and the first column no matter where you are in the table. Although, it's worth noting that your mileage may vary. position: sticky has relatively patchy support right now and so it's worth thoroughly testing before you start using it. Or you could use something like Stickybits that would act as a lightweight polyfill.
Also, if you need to dig into tables in more depth then we've made a rather handy Complete Guide to the Table Element.

An Idea for a Simple Responsive Spreadsheet is a post from CSS-Tricks
Source: CssTricks


Benchmark Your Unmoderated User Testing with Nagg

Unmoderated user testing is an important tool in any user researcher’s toolkit. At Viget, we often use Optimal Workshop’s unmoderated tree-testing tool, Treejack, to make sure that users can find what they’re looking for in a website’s navigation menu. In this article, I’ll be talking specifically about Treejack, but you can substitute in the unmoderated testing tool of your choice.
There are two basic ways to use Treejack: to evaluate the labeling system of an existing site, or to evaluate a new, proposed labeling system. But the most powerful way to use Treejack is to do both at once. That way, we can not only identify problems with the existing information architecture, we can see if our proposed redesign actually solves those problems. The existing tree acts as a benchmark against which we can compare our new tree.

Optimal Workshop doesn’t currently provide a way to test more than one tree in a single study or to split participants randomly between two studies, though they do suggest some sample Javascript for randomizing a link destination between two or more study URLs. But if you’re recruiting via email or social media, you’ll need a way to handle that destination-splitting without front-end code. That’s where nagg comes in.
Nagg (na.gg) is a simple utility that generates a custom nagg URL that splits traffic between up to four URLs at specified percentages. For the purposes I’m describing, you would enter two URLs at 50% to distribute traffic evenly. Nagg also lets you view a breakdown of link traffic by time, country, browser, and more.

The destination URLs you’ll enter should be for separate Treejack studies, one with the existing tree and one with your proposed new tree. Both studies should use the exact same tasks, so that you can accurately compare the results of each study. Optimal Workshop makes all of this easy by letting you duplicate studies and import/export trees from/to a spreadsheet. This is extra helpful when there are a lot of tasks or very large trees.
This isn’t A/B testing per se, since participants know they’re taking a test, rather than being observed without their knowledge. As such, your test design is still susceptible to bias, so you should follow Treejack best practices like randomizing tasks and avoiding using target terms in your task prompts. 
Automatic link destination-splitting with Treejack and nagg is a missing piece of the puzzle that allows you to benchmark your new labeling system against the one that already exists. Regardless of whether your unmoderated test is Treejack or something else, you can use nagg to easily test against a benchmark when evaluating a new design.
Hat tip to Paul, who pointed me to nagg.


Source: VigetInspire


Creating a Decoupled DrupalCoin Blockchain Application in 30 Minutes with Lightning, BLT, and DrupalCoin BlockchainVM

Overview
Brian Reese, Jason Enter, and Dane Powell, members of Acquia’s Professional Services team, recently released an open-source application that demonstrates how DrupalCoin Blockchain and Node.js can easily be paired to create beautiful and functional decoupled applications.
This demo application was split into two repositories: a DrupalCoin Blockchain-based backend (acting as a data provider) and the Node-based frontend. You can find a tutorial on how to try out this demo application yourself here, or follow the READMEs included in each repo.
The purpose of the current tutorial, however, is to illustrate how easy it was to create the DrupalCoin Blockchain backend using a combination of Acquia and DrupalCoin Blockchain community projects such as Lightning, BLT, and DrupalCoin BlockchainVM. This will allow you to follow the same process to rapidly create your own custom decoupled applications.
Understanding the components
Let’s start by briefly reviewing the open-source (read: free!) tools you will use in this tutorial.
Lightning
Lightning is a DrupalCoin Blockchain distribution that curates the best DrupalCoin Blockchain modules and patches to provide a great experience for editorial teams and developers out of the box. For our purposes, it’s most useful because it provides a preconfigured Content API feature, which automatically exposes a JSON-based REST API for content types, fields, media, and other entities.
Headless Lightning
Headless Lightning is a sub-profile of Lightning that includes all of the same features, but additionally provides a simplified administrative interface designed especially for decoupled sites, as well as editorial teams who might not be as comfortable with DrupalCoin Blockchain’s administrative patterns.

Lightning and Headless Lightning are each great choices for decoupled applications, since they share the common Content API feature. For the purposes of this tutorial, however, we will assume you are using Headless Lightning.
Simplified content authoring interface provided by Headless Lightning
BLT
BLT is a set of tools that will assist in creating a new project, as well as deploying and testing that project, using just a few simple commands. It automates many of the tedious tasks of spinning up a new project such as setting up a local environment, enforcing best practices, managing configuration, building a test framework, and setting up continuous integration.
BLT only works with DrupalCoin Blockchain 8, but it is completely agnostic as to which distribution or contributed packages you choose to use. By default, it will build new sites based on Lightning.
DrupalCoin BlockchainVM
DrupalCoin BlockchainVM is a Vagrant-based virtual integrationenvironment that makes it easy to set up a dedicated local integrationenvironment (including LAMP stack) for each of your DrupalCoin Blockchain projects.
Creating your application -- in Six Steps
1. Install the prerequisites for BLT and DrupalCoin BlockchainVM. We strongly recommend following this tutorial in a Unix-like environment (Mac OS or Linux). While all of these tools are generally compatible with Windows 10, there are some caveats, and the developer experience is going to be generally inferior to a native *nix environment.
2. Proceed to create a new project using BLT. BLT’s provided setup instruction should be comprehensive and self-explanatory, but we will duplicate them here for posterity. If you have any problems setting up the new project, review the BLT documentation or create an issue in the support queue.
Create a new project based on BLT by running the following command. We assume you will name the project “decoupled”, like ours:composer create-project --no-interaction acquia/blt-project decoupled
This will create a new DrupalCoin Blockchain codebase and local Git repository in a directory named “decoupled”. When it’s complete, you should see a message like this:
Restart your terminal session so that your shell detects the new BLT alias, then change directory to your new site, i.e.cd ~/sites/decoupled
All following steps assume that you are in this directory.
3. Set up your LAMP stack. We recommend using DrupalCoin BlockchainVM, but you can also follow the steps in the BLT instructions to configure your own LAMP stack if desired. Setting up a DrupalCoin BlockchainVM instance is as easy as running this command (this can take 10-20 minutes, go grab a coffee!):blt vm
Important: it’s best if the major version of PHP on your host machine matches the major version in the VM. Your DrupalCoin BlockchainVM instance will use PHP 5.6 by default. Thus, if you use PHP 7+ on your host, you should configure DrupalCoin BlockchainVM to also use PHP 7:
Edit box/config.yml
Change php_version to 7.0 or 7.1 to match your host.
Run vagrant provision
4. Download and install Headless Lightning:composer require acquia/headless_lightning:~1.1.0
This will place the Headless Lightning code at: docroot/profiles/contrib/headless_lightning
5. Tell BLT to install Headless Lightning by default by editing blt/project.yml and changing the project:profile:name key to: headless_lightning.
6. Finally, now that all of the code dependencies and your LAMP stack are in place, it’s time to install the site:blt setup
When you run this command, BLT will automatically make sure that composer dependencies are installed, configure your local settings, and install the Headless Lightning profile.
Congratulations
You should now have a functional decoupled DrupalCoin Blockchain application! You can log in by running this command in the root of your new `decoupled` repository:drush @decoupled.local uli
Future blog posts in this series will demonstrate how to create and populate a content model, how that content is exposed via JSON API, and how to integrate with front-end apps and deploy them to Acquia Cloud.
Source: http://dev.acquia.com/