Acquia acquires Mautic to create the Open Digital Experience Platform

I'm happy to announce today that Acquia acquired Mautic, an open source marketing automation and campaign management platform.

A couple of decades ago, I was convinced that every organization required a website — a thought that sounds rather obvious now. Today, I am convinced that every organization will need a Digital Experience Platform (DXP).

Having a website is no longer enough: customers expect to interact with brands through their websites, email, chat and more. They also expect these interactions to be relevant and personalized.

If you don't know Mautic, think of it as an alternative to Adobe's Marketo or Salesforce's Marketing Cloud. Just like these solutions, Mautic provides marketing automation and campaign management capabilities. It's differentiated in that it is easier to use, supports one-to-one customer experiences across many channels, integrates more easily with other tools, and is less expensive.

The flowchart style visual campaign builder you saw in the beginning of the Mautic demo video above is one of my favorite features. I love how it allows marketers to combine content, user profiles, events and a decision engine to deliver the best-next action to customers.

Mautic is a relatively young company, but has quickly grown into the largest open source player in the marketing automation space, with more than 200,000 installations. Its ease of use, flexibility and feature completeness has won over many marketers in a very short time: the company's top-line grew almost 400 percent year-over-year, its number of customers tripled, and Mautic won multiple awards for product innovation and customer service.

The acquisition of Mautic accelerates Acquia's product strategy to deliver the only Open Digital Experience Platform:

The pieces that make up a Digital Experience Platform, and how Mautic fits into Acquia's Open Digital Experience Platform. Acquia is strong in content management, personalization, user profile management and commerce (yellow blocks). Mautic adds or improves Acquia's multi-channel delivery, campaign management and journey orchestration capabilities (purple blocks).There are many reasons why we like Mautic, but here are my top 3:

Reason 1: Disrupting the market with "open"

Open Source will disrupt every component of the modern technology stack. It's not a matter of if, it's when.

Just as Drupal disrupted web content management with Open Source, we believe Mautic disrupts marketing automation.

With Mautic, Acquia is now the only open and open source alternative to the expensive, closed, and stagnant marketing clouds.

I'm both proud and excited that Acquia is doubling down on Open Source. Given our extensive open source experience, we believe we can help grow Mautic even faster.

Reason 2: Innovating through integrations

To build an optimal customer experience, marketers need to integrate with different data sources, customer technologies, and bespoke in-house platforms. Instead of buying a suite from a single vendor, most marketers want an open platform that allows for open innovation and unlimited integrations.

Only an open architecture can connect any technology in the marketing stack, and only an open source innovation model can evolve fast enough to offer integrations with thousands of marketing technologies (to date, there are 7,000 vendors in the martech landscape).

Because developers are largely responsible for creating and customizing marketing platforms, marketing technology should meet the needs of both business users and technology architects. Unlike other companies in the space, Mautic is loved by both marketers and developers. With Mautic, Acquia continues to focus on both personas.

Reason 3: The same technology stack and business model

Like Drupal, Mautic is built in PHP and Symfony, and like Drupal, Mautic uses the GNU GPL license. Having the same technology stack has many benefits.

Digital agencies or in-house teams need to deliver integrated marketing solutions. Because both Drupal and Mautic use the same technology stack, a single team of developers can work on both.

The similarities also make it possible for both open source communities to collaborate — while it is not something you can force to happen, it will be interesting to see how that dynamic naturally plays out over time.

Last but not least, our business models are also very aligned. Both Acquia and Mautic were "born in the cloud" and make money by offering subscription- and cloud-based delivery options. This means you pay for only what you need and that you can focus on using the products rather than running and maintaining them.

Mautic offers several commercial solutions:

Mautic Cloud, a fully managed SaaS version of Mautic with premium features not available in Open Source.
For larger organizations, Mautic has a proprietary product called Maestro. Large organizations operate in many regions or territories, and have teams dedicated to each territory. With Maestro, each territory can get its own Mautic instance, but they can still share campaign best-practices, and repeat successful campaigns across territories. It's a unique capability, which is very aligned with the Acquia Cloud Site Factory.
Try Mautic

If you want to try Mautic, you can either install the community version yourself or check out the demo or sandbox environment of Mautic Open Marketing Cloud.

Conclusion

We're very excited to join forces with Mautic. It is such a strategic step for Acquia. Together we'll provide our customers with more freedom, faster innovation, and more flexibility. Open digital experiences are the way of the future.

I've got a lot more to share about the Mautic acquisition, how we plan to integrate Mautic in Acquia's solutions, how we could build bridges between the Drupal and Mautic community, how it impacts the marketplace, and more.

In time, I'll write more about these topics on this blog. In the meantime, please feel free to join DB Hurley, Mautic's founder and CTO, and me in a live Q&A session on Thursday, May 9 at 10am ET. We'll try to answer your questions about Acquia and Mautic.
Source: Dries Buytaert www.buytaert.net


Headless CMS: REST vs JSON:API vs GraphQL

The web used to be server-centric in that web content management systems managed data and turned it into HTML responses. With the rise of headless architectures a portion of the web is becoming server-centric for data but client-centric for its presentation; increasingly, data is rendered into HTML in the browser.

This shift of responsibility has given rise to JavaScript frameworks, while on the server side, it has resulted in the development of JSON:API and GraphQL to better serve these JavaScript applications with content and data.

In this blog post, we will compare REST, JSON:API and GraphQL. First, we'll look at an architectural, CMS-agnostic comparison, followed by evaluating some Drupal-specific implementation details.

It's worth noting that there are of course lots of intricacies and "it depends" when comparing these three approaches. When we discuss REST, we mean the "typical REST API" as opposed to one that is extremely well-designed or following a specification (not REST as a concept). When we discuss JSON:API, we're referring to implementations of the JSON:API specification. Finally, when we discuss GraphQL, we're referring to GraphQL as it used in practice. Formally, it is only a query language, not a standard for building APIs.

The architectural comparison should be useful for anyone building decoupled applications regardless of the foundation they use because the qualities we will evaluate apply to most web projects.

To frame our comparisons, let's establish that most developers working with web services care about the following qualities:

Request efficiency: retrieving all necessary data in a single network round trip is essential for performance. The size of both requests and responses should make efficient use of the network.
API exploration and schema documentation: the API should be quickly understandable and easily discoverable.
Operational simplicity: the approach should be easy to install, configure, run, scale and secure.
Writing data: not every application needs to store data in the content repository, but when it does, it should not be significantly more complex than reading.
We summarized our conclusions in the table below, but we discuss each of these four categories (or rows in the table) in more depth below. If you aggregate the colors in the table, you see that we rank JSON:API above GraphQL and GraphQL above REST.

REST
JSON:API
GraphQL
Request efficiency
Poor; multiple requests are needed to satisfy common needs. Responses are bloated.
Excellent; a single request is usually sufficient for most needs. Responses can be tailored to return only what is required.
Excellent; a single request is usually sufficient for most needs. Responses only include exactly what was requested.
Documentation, API explorability and schema
Poor; no schema, not explorable.
Acceptable; generic schema only; links and error messages are self-documenting.
Excellent; precise schema; excellent tooling for exploration and documentation.
Operational simplicity
Acceptable; works out of the box with CDNs and reverse proxies; few to no client-side libraries required.
Excellent; works out of the box with CDNs and reverse proxies, no client-side libraries needed, but many are available and useful.
Poor; extra infrastructure is often necessary client side libraries are a practical necessity, specific patterns required to benefit from CDNs and browser caches.
Writing data
Acceptable; HTTP semantics give some guidance but how specifics left to each implementation, one write per request.
Excellent; how writes are handled is clearly defined by the spec, one write per request, but multiple writes is being added to the specification.
Poor; how writes are handled is left to each implementation and there are competing best practices, it's possible to execute multiple writes in a single request.

If you're not familiar with JSON:API or GraphQL, I recommend you watch the following two short videos. They will provide valuable context for the remainder of this blog post:

A 3-minute demo of Drupal's GraphQL implementation.
A 5-minute demo of Drupal's JSON:API implementation.
Request efficiency

Most REST APIs tend toward the simplest implementation possible: a resource can only be retrieved from one URI. If you want to retrieve article 42, you have to retrieve it from https://example.com/article/42. If you want to retrieve article 42 and article 72, you have to perform two requests; one to https://example.com/article/42 and one to https://example.com/article/72. If the article's author information is stored in a different content type, you have to do two additional requests, say to https://example.com/author/3 and https://example.com/author/7. Furthermore, you can't send these requests until you've requested, retrieved and parsed the article requests (you wouldn't know the author IDs otherwise).

Consequently, client-side applications built on top of basic REST APIs tend to need many successive requests to fetch their data. Often, these requests can't be sent until earlier requests have been fulfilled, resulting in a sluggish experience for the website visitor.

GraphQL and JSON:API were developed to address the typical inefficiency of REST APIs. Using JSON:API or GraphQL, you can use a single request to retrieve both article 42 and article 72, along with the author information for each. It simplifies the developer experience, but more importantly, it speeds up the application.

Finally, both JSON:API and GraphQL have a solution to limit response sizes. A common complaint against typical REST APIs is that their responses can be incredibly verbose; they often respond with far more data than the client needs. This is both annoying and inefficient.

GraphQL eliminates this by requiring the developer to explicitly add each desired resource field to every query. This makes it difficult to over-fetch data but easily leads to very large GraphQL queries, making (cacheable) GET requests impossible.

JSON:API solves this with the concept of sparse fieldsets or lists of desired resource fields. These behave in much the same fashion as GraphQL does, however, when they're omitted JSON:API will typically return all fields. An advantage, though, is that when a JSON:API query gets too large, sparse fieldsets can be omitted so that the request remains cacheable.

REST
JSON:API
GraphQL
Multiple data objects in a single response
Usually; but every implementation is different (for Drupal: custom "REST Export" view or custom REST plugin needed).
Yes
Yes
Embed related data (e.g. the author of each article)
No
Yes
Yes
Only needed fields of a data object
No
Yes; servers may choose sensible defaults, developers must be diligent to prevent over-fetching.
Yes; strict, but eliminates over-fetching, at the extreme, it can lead to poor cacheability.
Documentation, API explorability and schema

As a developer working with web services, you want to be able to discover and understand the API quickly and easily: what kinds of resources are available, what fields does each of them have, how are they related, etc. But also, if this field is a date or time, what machine-readable format is the date or time specified in? Good documentation and API exploration can make all the difference.

REST
JSON:API
GraphQL
Auto-generated documentation
Depends; if using the OpenAPI standard.
Depends; if using the OpenAPI standard (formerly, Swagger).
Yes; various tools available.
Interactivity
Poor; navigable links rarely available.
Acceptable; observing available fields and links in its responses enable exploration of the API.
Excellent; autocomplete feature, instant results or compilation errors, complete and contextual documentation.
Validatable and programmable schema.
Depends; if using the OpenAPI standard.
Depends; the JSON:API specification defines a generic schema, but a reliable field-level schema is not yet available.
Yes; a complete and reliable schema is provided (with very few exceptions).
GraphQL has superior API exploration thanks to GraphiQL (demonstrated in the video above), an in-browser IDE of sorts, which lets developers iteratively construct a query. As the developer types the query out, likely suggestions are offered and can be auto-completed. At any time, the query can be run and GraphiQL will display real results alongside the query. This provides immediate, actionable feedback to the query builder. Did they make a typo? Does the response look like what was desired? Additionally, documentation can be summoned into a flyout, when additional context is needed.

On the other hand, JSON:API is more self-explanatory: APIs can be explored with nothing more than a web browser. From within the browser, you can browse from one resource to another, discover its fields, and more. So, if you just want to debug or try something out, JSON:API is usable with nothing more than cURL or your browser. Or, you can use Postman (demonstrated in the video above) — a standalone environment for developing on top of an any HTTP-based API. Constructing complex queries requires some knowledge, however, and that is where GraphQL's GraphiQL shines compared to JSON:API.

Operational simplicity

We use the term operational simplicity to encompass how easy it is to install, configure, run, scale and secure each of the solutions.

The table should be self-explanatory, though it's important to make a remark about scalability. To scale a REST-based or JSON:API-based web service so that it can handle a large volume of traffic, you can use the same approach websites (and Drupal) already use, including reverse proxies like Varnish or a CDN. To scale GraphQL, you can't rely on HTTP caching as with REST or JSON:API without persisted queries. Persisted queries are not part of the official GraphQL specification but they are a widely-adopted convention amongst GraphQL users. They essentially store a query on the server, assign it an ID and permit the client to get the result of the query using a GET request with only the ID. Persisted queries add more operational complexity, and it also means the architecture is no longer fully decoupled — if a client wants to retrieve different data, server-side changes are required.

REST
JSON:API
GraphQL
Scalability: additional infrastructure requirements
Excellent; same as a regular website (Varnish, CDN, etc).
Excellent; same as a regular website (Varnish, CDN, etc).
Usually poor; only the simplest queries can use GET requests; to reap the full benefit of GraphQL, servers needs their own tooling.
Tooling ecosystem
Acceptable; lots of developer tools available, but for the best experience they need to be customized for the implementation.
Excellent; lots of developer tools available; tools don't need to be implementation-specific.
Excellent; lots of developer tools available; tools don't need to be implementation-specific.
Typical points of failure
Fewer; server, client.
Fewer; server, client.
Many; server, client, client-side caching, client and build tooling.
Writing data

For most REST APIs and JSON:API, writing data is as easy as fetching it: if you can read information, you also know how to write it. Instead of using the GET HTTP request type you use POST and PATCH requests. JSON:API improves on typical REST APIs by eliminating differences between implementations. There is just one way to do things and that enabled better, generic tooling and less time spent on server-side details.

The nature of GraphQL's write operations (called mutations) means that you must write custom code for each write operation; unlike JSON:API the specification, GraphQL doesn't prescribe a single way of handling write operations to resources, so there are many competing best practices. In essence, the GraphQL specification is optimized for reads, not writes.

On the other hand, the GraphQL specification supports bulk/batch operations automatically for the mutations you've already implemented, whereas the JSON:API specification does not. The ability to perform batch write operations can be important. For example, in our running example, adding a new tag to an article would require two requests; one to create the tag and one to update the article. That said, support for bulk/batch writes in JSON:API is on the specification's roadmap.

REST
JSON:API
GraphQL
Writing data
Acceptable; every implementation is different. No bulk support.
Excellent; JSON:API prescribes a complete solution for handling writes. Bulk operations are coming soon.
Poor; GraphQL supports bulk/batch operations, but writes can be tricky to design and implement. There are competing conventions.
Drupal-specific considerations

Up to this point we have provided an architectural and CMS-agnostic comparison; now we also want to highlight a few Drupal-specific implementation details. For this, we can look at the ease of installation, automatically generated documentation, integration with Drupal's entity and field-level access control systems and decoupled filtering.

Drupal 8's REST module is practically impossible to set up without the contributed REST UI module, and its configuration can be daunting. Drupal's JSON:API module is far superior to Drupal's REST module at this point. It is trivial to set up: install it and you're done; there's nothing to configure. The GraphQL module is also easy to install but does require some configuration.

Client-generated collection queries allow a consumer to filter an application's data down to just what they're interested in. This is a bit like a Drupal View except that the consumer can add, remove and control all the filters. This is almost always a requirement for public web services, but it can also make development more efficient because creating or changing a listing doesn't require server-side configuration changes.

Drupal's REST module does not support client-generated collection queries. It requires a "REST Views display" to be setup by a site administrator and since these need to be manually configured in Drupal; this means a client can't craft its own queries with the filters it needs.

JSON:API and GraphQL, clients are able to perform their own content queries without the need for server-side configuration. This means that they can be truly decoupled: changes to the front end don't always require a back-end configuration change.

These client-generated queries are a bit simpler to use with the JSON:API module than they are with the GraphQL module because of how each module handles Drupal's extensive access control mechanisms. By default JSON:API ensures that these are respected by altering the incoming query. GraphQL instead requires the consumer to have permission to simply bypass access restrictions.

Most projects using GraphQL that cannot grant this permission use persisted queries instead of client-generated queries. This means a return to a more traditional Views-like pattern because the consumer no longer has complete control of the query's filters. To regain some of the efficiencies of client-generated queries, the creation of these persisted queries can be automated using front-end build tooling.

REST
JSON:API
GraphQL
Ease of installation and configuration
Poor; requires contributed module REST UI, easy to break clients by changing configuration.
Excellent; zero configuration!
Poor; more complex to use, may require additional permissions, configuration or custom code.
Automatically generated documentation
Acceptable; requires contributed module OpenAPI.
Acceptable; requires contributed module OpenAPI.
Excellent; GraphQL Voyager included.
Security: content-level access control (entity and field access)
Excellent; content-level access control respected.
Excellent; content-level access control respected, even in queries.
Acceptable; some use cases require the consumer to have permission to bypass all entity and/or field access.
Decoupled filtering (client can craft queries without server-side intervention)
No
Yes
Depends; only in some setups and with additional tooling/infrastructure.
What does this mean for Drupal's roadmap?

Drupal grew up as a traditional web content management system but has since evolved for this API-first world and industry analysts are praising us for it. As Drupal's project lead, I've been talking about adding out-of-the-box support for both JSON:API and GraphQL for a while now. In fact, I've been very bullish about GraphQL since 2015. My optimism was warranted; GraphQL is undergoing a meteoric rise in interest across the web development industry.

Based on this analysis, we rank JSON:API above GraphQL and GraphQL above REST. As such, I want to change my recommendation for Drupal 8 core. Instead of adding both JSON:API and GraphQL to Drupal 8 core, I believe only JSON:API should be added. While Drupal's GraphQL implementation is fantastic, I no longer recommend that we add GraphQL to Drupal 8 core.

On the four qualities by which we evaluated the REST, JSON:API and GraphQL modules, JSON:API has outperformed its contemporaries. Its web standards-based approach, its ability to handle reads and writes out of the box, its security model and its ease of operation make it the best choice for Drupal core. Additionally, where JSON:API underperformed, I believe that we have a real opportunity to contribute back to the specification. In fact, one of the JSON:API module's maintainers and co-authors of this blog post, Gabe Sullice (Acquia), recently became a JSON:API specification editor himself.

This decision does not mean that you can't or shouldn't use GraphQL with Drupal. While I believe JSON:API covers the majority of use cases, there are valid use cases where GraphQL is a great fit. I'm happy that Drupal is endowed with such a vibrant contributed module ecosystem that provides so many options to Drupal's users.

I'm excited to see where both the JSON:API specification and Drupal's implementation of it goes in the coming months and years. As a first next step, we're preparing the JSON:API to be added to Drupal 8.7.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for co-authoring this blog post and to Preston So (Acquia) and Alex Bronstein (Acquia) for their feedback during the writing process.
Source: Dries Buytaert www.buytaert.net


Acquia retrospective 2018

Every year, I sit down to write my annual Acquia retrospective. It's a rewarding exercise, because it allows me to reflect on how much progress Acquia has made in the past 12 months.

Overall, Acquia had an excellent 2018. I believe we are a much stronger company than we were a year ago; not only because of our financial results, but because of our commitment to strengthen our product and engineering teams.

If you'd like to read my previous retrospectives, they can be found here: 2017,2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009. This year marks the publishing of my tenth retrospective. When read together, these posts provide a comprehensive overview of Acquia's growth and trajectory.

Updating our brand

Exiting 2017, Acquia doubled down on our transition from website management to digital experience management. In 2018, we updated our product positioning and brand narrative to reflect this change. This included a new Acquia Experience Platform diagram:

The Acquia Platform is divided into two key parts: the Experience Factory and the Marketing Hub. Drupal and Acquia Lightning power every side of the experience. The Acquia Platform supports our customers throughout the entire life cycle of a digital experience — from building to operating and optimizing digital experiences.

In 2018, the Acquia marketing team also worked hard to update Acquia's brand. The result is a refreshed look and updated brand positioning that better reflects our vision, culture, and the value we offer our customers. This included updating our tagline to read: Experience Digital Freedom.

I think Acquia's updated brand looks great, and it's been exciting to see it come to life. From highway billboards to Acquia Engage in Austin, our updated brand has been very well received.

When Acquia Engage attendees arrived at the Austin-Bergstrom International Airport for Acquia Engage 2018, they were greeted by an Acquia display.Business momentum

This year, Acquia surpassed $200 million in annualized revenue. Overall new subscription bookings grew 33 percent year over year, and we ended the year with nearly 900 employees.

Mike Sullivan completed his first year as Acquia's CEO, and demonstrated a strong focus on improving Acquia's business fundamentals across operational efficiency, gross margins, and cost optimization. The results have been tangible, as Acquia has realized unprecedented financial growth in 2018:

Channel-partner bookings grew 52 percent
EMEA-based bookings grew 103 percent
Gross profit grew 39 percent
Adjusted EBITDA grew 78 percent
Free cash flow grew 84 percent
2018 was a record year for Acquia. Year-over-year highlights include new subscription bookings, EMEA-based bookings, free cash flow, and more.International growth and expansion

In 2018, Acquia also witnessed unprecedented success in Europe and Asia, as new bookings in EMEA were up more than 100 percent. This included expanding our European headquarters to a new and larger space with a ribbon-cutting ceremony with the mayor of Reading in the U.K.

Acquia also expanded its presence in Asia Pacific, and opened Tokyo-based operations in 2018. Over the past few years I visited Japan twice, and I'm excited for the opportunities that doing business in Japan offers.

We selected Pune as the location for our new India office, and we are in the process of hiring our first Pune-based engineers.

Acquia now has four offices in the Asia Pacific region serving customers like Astellas Pharmaceuticals, Muji, Mediacorp, and Brisbane City Council.

Acquia product information, translated into Japanese.Acquia Engage

In 2018, we welcomed more than 650 attendees to Austin, Texas, for our annual customer conference, Acquia Engage. In June, we also held our first Acquia Engage Europe and welcomed 300 attendees.

Our Engage conferences included presentations from customers like Paychex, NBC Sports, Wendy's, West Corporation, General Electric, Charles Schwab, Pac-12 Networks, Blue Cross Blue Shield, Bayer, Virgin Sport, and more. We also featured keynote presentations from our partner network, including VMLY&R, Accenture Interactive, IBM iX and MRM//McCann.

Both customers and partners continue to be the most important driver of Acquia's product strategy, and it's always rewarding to hear about this success first hand. In fact, 2018 customer satisfaction levels remain extremely high at 94 percent.

Partner program

Finally, Acquia's partner network continues to become more sophisticated. In the second half of 2018, we right sized our partner community from 2,270 firms to 226. This was a bold move, but our goal was to place a renewed focus on the partners who were both committed to Acquia and highly capable. As a result, we saw almost 52 percent year-over-year growth in partner-sourced ACV bookings. This is meaningful because for every $1 Acquia books in collaboration with a partner, our partner makes about $5 in services revenue.

Analyst recognition

In 2018, the top industry analysts published very positive reviews about Acquia. I'm proud that Acquia was recognized by Forrester Research as the leader for strategy and vision in The Forrester Wave: Web Content Management Systems, Q4 2018. Acquia was also named a leader in the 2018 Gartner Magic Quadrant for Web Content Management, marking our placement as a leader for the fifth year in a row.

Product milestones

Acquia's product evolution between 2008 and 2018. When Acquia was founded, our mission was to provide commercial support for Drupal and to be the "Red Hat for Drupal"; 12 years later, the Acquia Platform helps organizations build, operate and optimize Drupal-based experiences.

2018 was one of the busiest years I have experienced; it was full of non-stop action every day. My biggest focus was working with Acquia's product and engineering team.
We focused on growing and improving our R&D organization, modernizing Acquia Cloud, becoming user-experience first, redesigning the Acquia Lift user experience, working on headless Drupal, making Drupal easier to use, and expanding our commerce strategy.

Hiring, hiring, hiring

In partnership with Mike, we decided to increase the capacity of our research and development team by 60 percent. At the close of 2018, we were able to increase the capacity of our research and development team by 45 percent percent. We will continue to invest in growing our our R&D team in 2019.

I spent a lot of our time restructuring, improving and scaling the product organization to make sure we could handle the increased capacity and build out a world-class R&D organization.

As the year progressed, R&D capacity increasingly came online and our ability to innovate not only improved but accelerated significantly. We entered 2019 in a much better position, as we now have a lot more capacity to innovate.

Acquia Cloud

Acquia Cloud and Acquia Cloud Site Factory support some of the largest and most mission-critical websites in the world. The scope and complexity that Acquia Cloud and Acquia Cloud Site Factory manages is enormous. We easily deliver more than 30 billion page views a month (excluding CDN).

Over the course of 10 years, the Acquia Cloud codebase had grown very large. Updating, testing and launching new releases took a long time because we had one large, monolithic codebase. This was something we needed to change in order to add new features faster.

Over the course of 2018, the engineering team broke the monolithic codebase down into discrete components that can be tested and released independently. We launched our component-based architecture in June. Since then, the engineering team has released changes to production 650 times, compared to our historic pace of doing one release per quarter.

This graph shows how we moved Acquia Cloud from a monolithic code base to a component-based code base. Each color on the graph represents a component. The graph shows how releases of Acquia Cloud (and the individual components in particular) have accelerated in the second half of the year.Planning and designing for all of these services took a lot of time and focus, and was a large priority for the entire engineering team (including me). The fruits of these efforts will start to become more publicly visible in 2019. I'm excited to share more with you in future blog posts.

Acquia Cloud also remains the most secure and compliant cloud for Drupal. As we were componentizing the Acquia Cloud platform, the requirements to maintain our FedRAMP compliance became much more stringent. In April, the GDPR deadline was also nearing. Executing on hundreds of FedRAMP- and GDPR-related tasks emerged as another critical priority for many of our product and engineering teams. I'm proud that the team succeeded in accomplishing this amid all the other changes we were making.
Customer experience first

Over the years, I've felt Acquia lacked a focus on user experience (UX) for both developers and marketers. As a result, increasing the capacity of our R&D team included doubling the size of the UX team.

We've stepped up our UX research to better understand the needs and challenges of those who use Acquia products. We've begun to employ design-first methodologies, such as design sprints and a lean-UX approach. We've also created roles for customer experience designers, so that we're looking at the full customer journey rather than just our product interfaces.

With the extra capacity and data-driven changes in place, we've been working hard on updating the user experience for the entire Acquia Experience Platform. For example, you can see a preview of our new Acquia Lift product in this video, which has an increased focus on UX:

Drupal

In 2018, Drupal 8 adoption kept growing and Drupal also saw an increase in the number of community contributions and contributors, both from individuals and from organizations.

Acquia remains very committed to Drupal, and was the largest contributor to the project in 2018. We now have more than 15 employees who contribute to Drupal full time, in addition to many others that contribute periodically. In 2018, the Drupal team's main areas of focus have been Layout Builder and the API-first initiative:

Layout Builder: Layout Builder offers content authors an easy-to-use page building experience. It's shaping up to be one of the most useful and pervasive features ever added to Drupal because it redefines the how editors control the appearance of their content without having to rely on a developer.
API First: This initiative has given Drupal a true best-in-class web services API for using Drupal as a headless content management system. Headless Drupal is one of the fastest growing segments of Drupal implementations.
Our R&D team gathered in Boston for our annual Build Week in June 2018.Content and Commerce

Adobe's acquisition of Magento has been very positive for us; we're now the largest commerce-agnostic content management company to partner with. As a result, we decided to extend our investments in headless commerce and set up partnerships with Elastic Path and BigCommerce. The momentum we've seen from these partnerships in a short amount of time is promising for 2019.

The market continues to move in Acquia's direction

In 2019, I believe Acquia will continue to be positioned for long-term growth. Here are a few reasons why:

The current markets for content and digital experience management continues to grow rapidly, at approximately 20 percent per year.
Digital transformation is top-of-mind for all organizations, and impacts all elements of their business and value chain.
Open source adoption continues to grow at a furious pace and has seen tremendous business success in 2018.
Cloud adoption continues to grow. Unlike most of our CMS competitors, Acquia was born in the cloud.
Drupal and Acquia are leaders in headless and decoupled content management, which is a fast growing segment of our market.
Conversational interfaces and augmented reality continues to grow, and we embraced these channels a few years ago. Acquia Labs, our research and innovation lab, explored how organizations can use conversational UIs to develop beyond-the-browser experiences, like cooking with Alexa, and voice-enabled search for customers like Purina.
Although we hold a leadership position in our market, our relative market share is small. These trends mean that we should have plenty of opportunity to grow in 2019 and beyond.

Thank you

While 2018 was an incredibly busy year, it was also very rewarding. I have a strong sense of gratitude, and admire every Acquian's relentless determination and commitment to improve. As always, none of these results and milestones would be possible without the hard work of the Acquia team, our customers, partners, the Drupal community, and our many friends.

I've always been pretty transparent about our trajectory (e.g. Acquia 2009 roadmap and Acquia 2017 strategy) and will continue to do so in 2019. We have some big plans for 2019, and I'm excited to share them with you. If you want to get notified about what we have in store, you can subscribe to my blog at https://dri.es/subscribe.

Thank you for your support in 2018!


Source: Dries Buytaert www.buytaert.net


How to decouple Drupal in 2019

The pace of innovation in content management has been accelerating — driven by both the number of channels that content management systems need to support (web, mobile, social, chat) as well as the need to support JavaScript frameworks in the traditional web channel. As a result, we've seen headless or decoupled architectures emerge.

Decoupled Drupal has seen adoption from all corners of the Drupal community. In response to the trend towards decoupled architectures, I wrote blog posts in 2016 and 2018 for architects and developers about how and when to decouple Drupal. In the time since my last post, the surrounding landscape has evolved, Drupal's web services have only gotten better, and new paradigms such as static site generators and the JAMstack are emerging.

Time to update my recommendations for 2019! As we did a year ago, let's start with the 2019 version of the flowchart in full. (At the end of this post, there is also an accessible version of this flowchart described in words.)

Different ways to decouple Drupal

I want to revisit some of the established ways to decouple Drupal as well as discuss new paradigms that are seeing growing adoption. As I've written previously, the three most common approaches to Drupal architecture from a decoupled standpoint are traditional (or coupled), progressively decoupled, and fully decoupled. The different flavors of decoupling Drupal exist due to varying preferences and requirements.

In traditional Drupal, all of Drupal's usual responsibilities stay intact, as Drupal is a monolithic system and therefore maintains complete control over the presentation and data layers. Traditional Drupal remains an excellent choice for editors who need full control over the visual elements on the page, with access to features such as in-place editing and layout management. This is Drupal as we have known it all along. Because the benefits are real, this is still how most new content management projects are built.

Sometimes, JavaScript is required to deliver a highly interactive end-user experience. In this case, a decoupled approach becomes required. In progressively decoupled Drupal, a JavaScript framework is layered on top of the existing Drupal front end. This JavaScript might be responsible for nothing more than rendering a single block or component on a page, or it may render everything within the page body. The progressive decoupling paradigm lies on a spectrum; the less of the page dedicated to JavaScript, the more editors can control the page through Drupal's administrative capabilities.

Up until this year, fully decoupled Drupal was a single category of decoupled Drupal architecture that reflects a full separation of concerns between the presentation layer and all other aspects of the CMS. In this scenario, the CMS becomes a data provider, and a JavaScript application with server-side rendering becomes responsible for all rendering and markup, communicating with Drupal via web service APIs. Though key functionality like in-place editing and layout management are unavailable, fully decoupled Drupal is appealing for developers who want greater control over the front end and who are already experienced with building applications in frameworks like Angular, React, Vue.js, etc.

Over the last year, fully decoupled Drupal has branched into two separate paradigms due to the increasing complexity of JavaScript development. The so-called JAMstack (JavaScript, APIs, Markup) introduces a new approach: fully decoupled static sites. The primary reason for static sites is improved performance, security, and reduced complexity for developers. A static site generator like Gatsby will retrieve content from Drupal, generate a static website, and deploy that static site to a CDN, usually through a specialized cloud provider such as Netlify.

What do you intend to build?

The essential question, as always, is what you're trying to build. Here is updated advice for architects exploring decoupled Drupal in 2019:

If your intention is to build a single standalone website or web application, choosing decoupled Drupal may or may not be the right choice, depending on the features your developers and editors see as must-haves.
If your intention is to build multiple web experiences (websites or web applications), you can use a decoupled Drupal instance either as a) a content repository without its own public-facing front end or b) a traditional website that acts simultaneously as a content repository. Depending on how dynamic your application needs to be, you can choose a JavaScript framework for highly interactive applications or a static site generator for mostly static websites.
If your intention is to build multiple non-web experiences (native mobile or IoT applications), you can leverage decoupled Drupal to expose web service APIs and consume that Drupal site as a content repository without its own public-facing front end.
What makes Drupal so powerful is that it supports all of these use cases. Drupal makes it simple to build decoupled Drupal thanks to widely recognized standards such as JSON:API, GraphQL, OpenAPI, and CouchDB. In the end, it is your technical requirements that will decide whether decoupled Drupal should be your next architecture.

In addition to technical requirements, organizational factors often come into play as well. For instance, if it is proving difficult to find talented front-end Drupal developers with Twig knowledge, it may make more sense to hire more affordable JavaScript developers instead and build a fully decoupled implementation.

Are there things you can't live without?

As I wrote last year, the most important aspect of any decision when it comes to decoupling Drupal is the list of features your project requires; the needs of editors and developers have to be carefully considered. It is a critical step in your evaluation process to weigh the different advantages and disadvantages. Every project should embark on a clear-eyed assessment of its organization-wide needs.

Many editorial and marketing teams select a particular CMS because of its layout capabilities and rich editing functionality. Drupal, for example, gives editors the ability to build layouts in the browser and drop-and-drag components into it, all without needing a developer to do it for them. Although it is possible to rebuild many of the features available in a CMS on a consumer application, this can be a time-consuming and expensive process.

In recent years, the developer experience has also become an important consideration, but not in the ways that we might expect. While the many changes in the JavaScript landscape are one of the motivations for developers to prefer decoupled Drupal, the fact that there are now multiple ways to write front ends for Drupal makes it easier to find people to work on decoupled Drupal projects. As an example, many organizations are finding it difficult to find affordable front-end Drupal developers experienced in Twig. Moving to a JavaScript-driven front end can resolve some of these resourcing challenges.

This balancing act between the requirements that developers prioritize and those that editors prioritize will guide you to the correct approach for your needs. If you are part of an organization that is mostly editorial, decoupled Drupal could be problematic, because it reduces the amount of control editors have over the presentation of their content. By the same token, if you are part of an organization with more developer resources, fully decoupled Drupal could potentially accelerate progress, with the warning that many mission-critical editorial features disappear.

Current and future trends to consider

Over the past year, JavaScript frameworks have become more complex, while static site generators have become less complex.

One of the common complaints I have heard about the JavaScript landscape is that it shows fragmentation and a lack of cohesion due to increasing complexity. This has been a driving force for static site generators. Whereas two years ago, most JavaScript developers would have chosen a fully functional framework like Angular or Ember to create even simple websites, today they might choose a static site generator instead. A static site generator still allows them to use JavaScript, but it is simpler because performance considerations and build processes are offloaded to hosted services rather than the responsibility of developers.

I predict that static site generators will gain momentum in the coming year due to the positive developer experience they provide. Static site generators are also attracting a middle ground of both more experienced and less experienced developers.

Conclusion

Drupal continues to be an ideal choice for decoupled CMS architectures, and it is only getting better. The API-first initiative is making good progress on preparing the JSON:API module for inclusion in Drupal core, and the Admin UI and JavaScript Modernization initiative is working to dogfood Drupal's web services with a reinvented administrative interface. Drupal's support for GraphQL continues to improve, and now there is even a book on the subject of decoupled Drupal. It's clear that developers today have a wide range of ways to work with the rich features Drupal has to offer for decoupled architectures.

With the introduction of fully decoupled static sites as an another architectural paradigm that developers can select, there is an even wider variety of architectural possibilities than before. It means that the spectrum of decoupled Drupal approaches I defined last year has become even more extensive. This flexibility continues to define Drupal as an excellent CMS for both traditional and decoupled approaches, with features that go well beyond Drupal's competitors, including WordPress, Sitecore and Adobe. Regardless of the makeup of your team or the needs of your organization, Drupal has a solution for you.

Special thanks to Preston So for co-authoring this blog post and to Angie Byron, Chris Hamper, Gabe Sullice, Lauri Eskola, Ted Bowman, and Wim Leers for their feedback during the writing process.

Accessible version of flowchart

This is an accessible and described version of the flowchart images earlier in this blog post. First, let us list the available architectural choices:

Coupled. Use Drupal as is without additional JavaScript (and as a content repository for other consumers).
Progressively decoupled. Use Drupal for initial rendering with JavaScript on top (and as a content repository for other consumers).
Fully decoupled static site. Use Drupal as a data source for a static site generator and, if needed, deploy to a JAMstack hosting platform.
Fully decoupled app. Use Drupal as a content repository accessed by other consumers (if JavaScript, use Node.js for server-side rendering).
Second, ask the question "What do you intend to build?" and choose among the answers "One experience" or "Multiple experiences".

If you are building one experience, ask the question "Is it a website or web application?" and choose among the answers "Yes, a single website or web application" or "No, Drupal as a repository for non-web applications only".

If you are building multiple experiences instead, ask the question "Is it a website or web application?" with the answers "Yes, Drupal as website and repository" or "No, Drupal as a repository for non-web applications only".

If your answer to the previous question was "No", then you should build a fully decoupled application, and your decision is complete. If your answer to the previous question was "Yes", then ask the question "Are there things the project cannot live without?"

Both editorial and developer needs are things that projects cannot live without, and here are the questions you need to ask about your project:

Editorial needs

Do editors need to manipulate page content and layout without a developer?
Do editors need in-context tools like in-place editing, contextual links, and toolbar?
Do editors need to preview unpublished content without custom development?
Do editors need content to be accessible by default like in Drupal's HTML?
Developer needs

Do developers need to have control over visual presentation instead of editors?
Do developers need server-side rendering or Node.js build features?
Do developers need JSON from APIs and to write JavaScript for the front end?
Do developers need data security driven by a publicly inaccessible CMS?
If, after asking all of these questions about things your project cannot live without, your answers show that your requirements reflect a mix of both editorial and developer needs, you should consider a progressively decoupled implementation, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely developer needs, then ask the question "Is it a static website or a dynamic web application?" and choose among the answers "Static" or "Dynamic." If your answer to the previous question was "Static", you should build a fully decoupled static site, and your decision is complete. If your answer to the previous question was "Dynamic", you should build a fully decoupled app, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely editorial needs, then ask two questions. Ask the first question, "Are there parts of the page that need JavaScript-driven interactions?" and choose among the answers "Yes" or "No." If your answer to the first question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the first question was "No", then you should build a coupled Drupal site, and your decision is complete.

Then, ask the second question, "Do you need to access multiple data sources via API?" and choose among the answers "Yes" or "No." If your answer to the second question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the second question was "No", then you should build a coupled Drupal site, and your decision is complete.
Source: Dries Buytaert www.buytaert.net


The rise of headless commerce

Today, Acquia announced a partnership with Elastic Path, a headless commerce platform. In this post, I want to explore the advantages of headless commerce and the opportunity it holds for both Drupal and Acquia.

The advantages of headless commerce

In a headless commerce approach, the front-end shopping experience is decoupled from the commerce business layer. Headless commerce platforms provide a clean separation between the front end and back end; the shopping experience is provided by Drupal and the commerce business logic is provided by the commerce platform. This decoupling provides advantages for the developer, merchant and shopping experience.

For developers, it means that you can decouple both the development and the architecture. This allows you to build an innovative shopping experience without having to worry about impacting a system as critical as your commerce backend. For instance, you can add ratings and reviews to your shopping experience without having to redeploy your commerce platform.
For merchants, it can provide a better experience for administering the shop. Traditional commerce solution usually ship with a lightweight content management system. This means that there can be competition over which system provides the experience layer (i.e. the "glass"). This can introduce overlap in functionality; both systems offer ways to manage URLs, create landing pages, manage user access rights, etc. Because headless commerce systems are designed from the ground up to integrate with other systems, there is less duplication of functionality. This provides a streamlined experience for merchants.
And last but not least, there is the shopping experience for end-users or consumers. Simply put, consumers are demanding better experiences when they shop online. They want editorials, lookbooks, tutorials, product demonstration videos, testimonials, and more. They want the content-rich experiences that a comprehensive content management system can provide.
All this is why Acquia is excited about our partnership with Elastic Path. I believe the partnership is a win-win-win. It's a win for Acquia because we are now better equipped than ever to offer personal, unique and delightful shopping experiences. It is a win for Elastic Path as they have the opportunity to provide contextual commerce solutions to any Acquia customer. Last but not least, it's a win for Drupal because it will introduce more organizations to the project.

Note that many of the above integration challenges don't apply to native solutions like Drupal Commerce for Drupal or WooCommerce for WordPress. It only applies when you have to integrate two entirely different systems. Integrating two different systems is a common use case, because customers either already have a commerce platforms in place that they don't want to replace, or because native solutions don't meet their needs.

Acquia's commitment to best of breed

Acquia remains committed to a best-of-breed strategy for commerce. There isn't a single commerce platform that meets the needs of all our customers. This belief comes from years of experience in the field. Acquia's customers want to integrate with a variety of commerce systems such as Elastic Path, SAP Hybris, Salesforce Commerce Cloud (Demandware), Magento, BigCommerce, Reaction Commerce, Oracle ATG, Moltin, and more. Our customers also want to use Drupal Commerce, Drupal's native commerce solution. We believe customers should be able to integrate Drupal with their commerce management solutions of choice.
Source: Dries Buytaert www.buytaert.net


5-Day Drupal 8 Training - Toronto

Start: 
2018-10-01 09:00 - 2018-10-05 16:30 America/Toronto

Organizers: 

Meyzi

Event type: 

Training (free or commercial)

https://evolvingweb.ca/training/5-day-drupal-8-training

Learn how to build a website with Drupal from top to bottom. This week-long Drupal class is divided into three parts: site building, theming, and module development. You can register for all five days, or just the days of interest to you.
Day 1: Drupal 8 Site Building & Architecture
This course will give participants a thorough understanding of the Drupal site building process. You'll get hands-on experience creating an information architecture for Drupal, and implementing advanced features with Drupal core and contributed modules.
Planning and implementing content types
Techniques for organizing content with Views
Building layouts with configuration
Structuring content with Paragraphs
Setting up landing pages
Selecting and installing contributed modules
Site maintenance best practices
Pre-launch checklist
Days 2-3: Drupal 8 Theming
You'll learn how to build a responsive Drupal theme to customize the look of your Drupal site. We’ll create a theme based on Drupal core, and another using a front-end framework. Learn how to create layouts, customize Twig templates, and best practices for organizing your theme.
Creating a custom Drupal theme
Using Drupal's core themes
Drupal's templating system
Adding CSS and Javascript to your Drupal theme
Twig syntax and Twig debug
Sub-theming with Bootstrap, Zurb Foundation, etc.
Using Twig to customize Views output
Preprocess functions
Using SASS with your Drupal theme
Extending Twig templates
Using libraries to manage internal and external assets
Best practices for Drupal theming
Days 4-5: Drupal 8 Module Development
You'll learn the process for developing a module with standard components like blocks, permissions, forms, and pages. The course will cover the concepts behind module development, how to use Object Oriented Programming for Drupal 8, and essential Drupal developer tools. It will give you an overall understanding of how modules work and you’ll get hands-on experience developing modules from scratch.
Creating a Drupal 8 module
Drupal coding standards
Using Drush, Drupal Console, and Composer
Creating pages programmatically
Creating custom field types and formatters
Using the Examples module
Creating custom forms
Database integration
Creating blocks programmatically
Creating administrative forms
Creating and applying patches
Configuration management
To register and for details: https://evolvingweb.ca/training/5-day-drupal-8-training
Source: https://groups.drupal.org/node/512931/feed


Why large organizations are choosing to contribute to Drupal

During my DrupalCon Nashville keynote, I shared a brief video of Mike Lamb, the Senior Director of Architecture, Engineering & Development at Pfizer. Today, I wanted to share an extended version of my interview with Mike, where he explains why the development team at Pfizer has ingrained Open Source contribution into the way they work.

Mike had some really interesting and important things to share, including:
Why Pfizer has chosen to standardize all of its sites on Drupal (from 0:00 to 03:19). Proprietary software isn't a match.
Why Pfizer only works with agencies and vendors that contribute back to Drupal (from 03:19 to 06:25). Yes, you read that correctly; Pfizer requires that its agency partners contribute to Open Source!
Why Pfizer doesn't fork Drupal modules (from 06:25 to 07:27). It's all about security.
Why Pfizer decided to contribute to the Drupal 8's Workflow Initiative, and what they have learned from working with the Drupal community (from 07:27 to 10:06).
How to convince a large organization (like Pfizer) to contribute back to Drupal (from 10:06 to 12:07).
Between Pfizer's direct contributions to Drupal (e.g. the Drupal 8 Workflow Initiative) and the mandate for its agency partners to contribute code back to Drupal, Pfizer's impact on the Drupal community is invaluable. It's measured in the millions of dollars per year. Just imagine what would happen to Drupal if ten other large organizations adopted Pfizer's contribution models?

Most organizations use Open Source, and don't think twice about it. However, we're starting to see more and more organizations not just use Open Source, but actively contribute to it. Open source offers organizations a completely different way of working, and fosters an innovation model that is not possible with proprietary solutions. Pfizer is a leading example of how organizations are starting to challenge the prevailing model and benefit from contributing to Open Source. Thanks for changing the status quo, Mike!
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


Mollom: The story of my first SaaS startup

Last month, Acquia discontinued service and support for Mollom, the spam service I started more than ten years ago. As a goodbye, I want to share the untold story of how I founded Mollom.

In 2007, I read Tim Ferriss' book The 4-Hour Work Week, and was hooked. The book provides a blueprint for how entrepreneurs can structure and build a business to fund the lifestyle of their dreams. It's based on Ferriss' own experience; he streamlined his business, automated systems and outsourced tasks until it was not only more profitable, but also took less of his time to operate. The process of automation and outsourcing was so efficient, Ferriss only spent four hours a week to run his business; this gave him time and freedom to take "mini-retirements", travel the world, and write a book. When I first read Ferriss' book, I was inspired by the idea of simultaneously having that much free time and being financially stable.

While I was reading Ferriss' book, I was also working on a website spam filter for my blog, called Mollom. I had started to build Mollom as a personal project for exclusive use on my own blog. Inspired by the 4-Hour Work Week, I was convinced I could turn Mollom into a small SaaS service with global customers, complete self-service, and full automation. This would allow me to operate Mollom from anywhere in the world, and would require just a few hours of my time each week. Because I was starting to use machine learning, I enlisted the help of one of my best friends, Benjamin Schrauwen, a professor in machine learning at the University of Ghent.

In the same year, Jay Batson and I met at DrupalCon Sunnyvale, and we had already started to explore the idea of founding Acquia. My oldest son Axl was also born in the summer of 2007, and I was working hard to finish my PhD. Throughout all of this, we were also working to get Drupal 6 released. Needless to say, it was a busy summer.

With my PhD nearly complete, I needed to decide what to do next. I knew that starting Acquia was going to have a big impact, not just on Drupal but also on my life. However, I was also convinced that Mollom, while much smaller in scope and ambition, could provide a path to the freedom and independence Ferriss describes.

Mollom's foundational years

Exciting 2007, I determined that both Acquia and Mollom were important opportunities to pursue. Jay and I raised $7 million in venture capital, and we publicly launched Acquia in November 2007. Meanwhile, Ben and I pooled together €18,000 of our own money, bootstrapped Mollom, and publicly launched Mollom in March 2008.

I always made a point to run both businesses separately. Even after I moved from Belgium to the US in the summer of 2010, I continued to run Mollom and Acquia independently. The Mollom team was based in Europe, and once or twice a week, I would get up at 4 AM to have a two-hour conference call with the team. After my conference call, I'd help my family get ready for the day, and then I was off to work at Acquia.

By 2011, Mollom had achieved the goals our team set out to accomplish; our revenues had grown to about €250,000 annually, our gross margins were over 85 percent, and we could pretty much run the business on autopilot. Our platform was completely self-serviced for our users, the anti-spam algorithms self-learning, the service was built to be highly-available, and the backend operations were almost entirely automated. I often joked about how I could run Mollom from the beach in Greece, with less than an hour of work a day.

However, our team at Mollom wasn't satisfied yet, so instead of sitting on the beach, we decided to invest Mollom's profits in feature development. We had a team of three engineers working on adding new capabilities, in addition to re-architecting and scaling Mollom to keep up with its growth. On average, Mollom handled more than 100 web service requests per second, and we regularly saw peaks of up to 3,000 web service request per second. In a way, Mollom's architecture was ahead of its time — it used a micro-services architecture with a REST API, a decoupled administration backend and relied heavily on machine learning. From day one, our terms of service respected people's privacy, and we never had a data breach.

A photo of the Mollom team at an offsite in 2011: it includes Daniel Kudwien, Benjamin Schrauwen, Cedric De Vleeschauwer, Thomas Meire, Johan Vos and Vicky Van Roeyen. Missing in the picture is Dries.In the meantime, Acquia had really taken off; Acquia's revenue had grown to over $22 million annually, and I was often working 60 hour work weeks to grow the company. Acquia's Board of Directors wanted my full attention, and had even offered to acquire Mollom a few times. I recognized that running Mollom, Acquia and Drupal simultaneously was not sustainable — you can only endure regular 4 AM meetings for so long. Plus, we had ambitious goals for Mollom; we wanted to add many-site content moderation, sentiment analysis and detection for certain code of conduct violations. Doing these things would require more capital, and unless you are Elon Musk, it's really hard to raise capital for multiple companies at the same time. Most importantly, I wanted to focus more on growing Drupal and driving Acquia's expansion.

Acquia acquires Mollom

By the end of 2012, Ben and I agreed to sell Mollom to Acquia. Acquia's business model was to provide SaaS services around Drupal, and Mollom was exactly that — a SaaS service used by tens of thousands of Drupal sites.

Selling Mollom was a life-changing moment for me. It proved that I was able to bootstrap and grow a company, steer it to profitability and exit successfully.

Selling Mollom to Acquia involved signing a lot of documents. A photo of me signing the acquisition paperwork with Mary Jefts, Acquia's CFO at the time. It took three hours to sign all the paperwork.Acquia retires Mollom

By 2017, five years after the acquisition, it became clear that Mollom was no longer a strategic priority for Acquia. As a result, Acquia decided it was best to shut down Mollom by April 2018. As the leader of the product organization at Acquia, I'm supportive of this decision. It allows us to sharpen our focus and to better deliver on our mission.

While it was a rational decision, it's bittersweet. I still believe that Mollom could have continued to have a big impact on the Open Web. Not only did that make the web better, it saved people millions of hours moderating their content. I also considered keeping Mollom running as part of Acquia's "Give back more" principle. However, Acquia gives back a lot, and I believe that giving back to Drupal should be our priority.

Mollom's end-of-life announcement that replaced the old https://mollom.com.Overall, Mollom was a success. While I never got my 4-hour work week, I enjoyed successfully creating a company from scratch, and seeing it evolve through every stage of its life. I learned how to build and run a SaaS service, I made some money in the process, and best of all, Mollom blocked over 15 billion spam comments across tens of thousands of websites. This translates to saving people around the world millions of hours, which would otherwise be devoted to content moderation. Mollom also helped to protect the websites of some of the world's most famous brands; from Harvard, to The Economist, Tesla, Twitter, Sony Music and more. Finally, we were able to offer Mollom for free to the vast majority of our users, which is something we took a lot of pride in.

If you were a user of Mollom the past 10+ years, I hope you enjoyed our service. I also want to extend a special thank you to everyone who contributed to Mollom over the past 11 years!

Rest in peace, Mollom! Thank you for blocking so much spam. I'll think about you next time I visit Greece.
Source: Dries Buytaert www.buytaert.net


How to decouple DrupalCoin in 2018


In this post, I'm providing some guidance on how and when to decouple DrupalCoin.

Almost two years ago, I had written a blog post called "How should you decouple DrupalCoin?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their DrupalCoin architectures. Since that point, DrupalCoin, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

DrupalCoin's API-first initiative has introduced new capabilities, and we've seen the advent of the Waterwheel ecosystem and API-first distributions like Reservoir, Headless Lightning, and Contenta. More developers both inside and outside the DrupalCoin community are experimenting with Node.js and adopting fully decoupled architectures. As a result, Acquia now offers Node.js hosting, which means it's never been easier to implement decoupled DrupalCoin on the Acquia platform.

Let's start with the new flowchart in full:

All the ways to decouple DrupalCoin

The traditional approach to DrupalCoin architecture, also referred to as coupled DrupalCoin, is a monolithic implementation where DrupalCoin maintains control over all front-end and back-end concerns. This is DrupalCoin as we've known it — ideal for traditional websites. If you're a content creator, keeping DrupalCoin in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional DrupalCoin 8 also remains a great approach for developers who love DrupalCoin 8 and want it to own the entire stack.

A second approach, progressively decoupled DrupalCoin, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the DrupalCoin front end. Progressive decoupling is in fact a spectrum, whether it is DrupalCoin only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled DrupalCoin hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled DrupalCoin has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

The most important question to ask is what you are trying to build.

If your plan is to create a single standalone website or web application, decoupling DrupalCoin may or may not be the right choice based on the must-have features your developers and editors are asking for.
If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use DrupalCoin to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.
Ultimately, your needs will determine the usefulness of decoupled DrupalCoin for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling DrupalCoin if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, DrupalCoin makes it much easier to build applications consuming decoupled DrupalCoin. Even if you're using DrupalCoin as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" DrupalCoin.

Are there things you can't live without?

Perhaps most critical to any decision to decouple DrupalCoin is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled DrupalCoin, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where DrupalCoin does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling DrupalCoin will remove all of the critical linkages within DrupalCoin that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled DrupalCoin can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled DrupalCoin, my hope is that DrupalCoin keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. DrupalCoin's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by DrupalCoin grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in DrupalCoin today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use DrupalCoin not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.

Conclusion

Thankfully, DrupalCoin is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in DrupalCoin 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of DrupalCoin the tools to interact with it in unprecedented ways. Moreover, for Acquia customers, Acquia's recent launch of Node.js hosting on Acquia Cloud means that developers can leverage the most modern approaches in JavaScript while benefiting from DrupalCoin's capabilities as a content repository.

Unlike many other content management systems, old and new, DrupalCoin provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling DrupalCoin, progressively decoupling it, and traditional DrupalCoin — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets DrupalCoin apart from new headless content management systems and most SaaS platforms, and it also shows DrupalCoin's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; DrupalCoin has the answer.

Special thanks to Preston So for contributions to this blog post and to Alex Bronstein, Angie Byron, Gabe Sullice, Samuel Mortenson, Ted Bowman and Wim Leers for their feedback during the writing process.
Source: Dries Buytaert www.buytaert.net


Acquia retrospective 2017


The entrance to Acquia's headquarters in Boston.For the past nine years, I've sat down every January to write an Acquia retrospective. It's always a rewarding blog post to write as it gives me an opportunity to reflect on what Acquia has accomplished over the past 12 months. If you'd like to read my previous annual retrospectives, they can be found here: 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009. When read together, they provide insight to what has shaped Acquia into the company it is today.

This year's retrospective is especially meaningful because 2017 marked Acquia's 10th year as a company. Over the course of Acquia's first decade, our long-term investment in open source and cloud has made us the leader in web content management. 2017 was one of our most transformative years to date; not only did we have to manage leadership changes, but we also broadened our horizons beyond website management to data-driven customer journeys.

The next phase of Acquia leadership

Tom Erickson joined Acquia as CEO in 2009 and worked side-by-side with me for the next eight years.In my first retrospective from 2009, I shared that Jay Batson and I had asked Tom Erickson to come aboard as Acquia's new CEO. For the next eight years, Tom and I worked side-by-side to build and grow Acquia. Tom's expertise in taking young companies to the next level was a natural complement to my technical strength. His leadership was an example that enabled me to develop my own business building skills. When Tom announced last spring that he would be stepping down as Acquia's CEO, I assumed more responsibility to help guide the company through the transition. My priorities for 2017 were centered around three objectives: (1) the search for a new CEO, (2) expanding our product strategy through a stronger focus on innovation, and (3) running our operations more efficiently.

The search for a new CEO consumed a great deal of my time in 2017. After screening over 140 candidates and interviewing ten of them in-depth, we asked Mike Sullivan to join Acquia as CEO. Mike has been on the job for three weeks and I couldn't be more excited.

Mike Sullivan joins Acquia as CEO with 25 years of senior leadership in SaaS, enterprise content management and content governance.Market trends

I see three major market trends that I believe are important to highlight and that help inform our strategy.

Trend #1: Customers are driven by time-to-value and low cost of maintenance

Time-to-value and low maintenance costs are emerging as two of the most important differentiators in the market. This is consistent with a post I wrote eleven years ago, in regards to The Ockham's Razor Principle of Content Management Systems. The principle states that given two functionally equivalent content management systems, the simplest one should be selected. Across both the low and the high ends of the market, time-to-value and total cost of ownership matter a great deal. Simplicity wins.

In the low end of the market simple sites, such as single blogs and brochure sites, are now best served by SaaS tools such as Squarespace and Wix. Over the past five years, SaaS solutions have been rising in prominence because their templated approach to simple site building makes them very easy to use. The total cost of ownership is also low as users don't have to update and maintain the software and infrastructure themselves. Today, I believe that DrupalCoin is no longer ideal for most simple sites and instead is best suited for more ambitious use cases. Not everyone likes that statement, but I believe it to be true.

In the mid-market, SaaS tools don't offer the flexibility and customizability required to support sites with more complexity. Often mid-market companies need more customizable solutions like DrupalCoin or WordPress. Time-to-value and total maintenance costs still matter; people don't want to spend a lot of time installing or upgrading their websites. Within the scope of Ockham's Razor Principle, WordPress does better than DrupalCoin in this regard. WordPress is growing faster than DrupalCoin for websites with medium complexity because ease of use and maintenance often precede functionality. However, when superior flexibility and architecture are critical to the success of building a site, DrupalCoin will be selected.

In the enterprise, a growing emphasis on time-to-value means that customers are less interested in boil-the-ocean projects that cost hundreds of thousands (or millions) of dollars. Customers still want to do large and ambitious projects, but they want to start small, see results quickly, and measure their ROI every step along the way. Open source and cloud provide this agility by reducing time-to-market, cost and risk. This establishes a competitive advantage for Acquia compared to traditional enterprise vendors like Adobe and Sitecore.

At Acquia, understanding how we can make our products easier to use by enhancing self-service and reducing complexity will be a major focus of 2018. For DrupalCoin, it means we have to stay focused on the initiatives that will improve usability and time to value. In addition to adopting a JavaScript framework in core to facilitate the building of a better administration experience, work needs to continue on Workspaces (content staging), Layout Builder (drag-and-drop blocks), and the Media, Outside-in and Out-of-the-box initiatives. Finally, I anticipate that a DrupalCoin initiative around automated upgrades will kick off in 2018. I'm proud to say that Acquia has been a prominent contributor to many of these initiatives, by either sponsoring developers, contributing code, or providing development support and coordination.

Trend #2: Frictionless user experiences require greater platform complexity

For the past ten years, I've observed one significant factor that continues to influence the trajectory of digital: the internet's continuous drive to mitigate friction in user experience and business models. The history of the web dictates that lower-friction solutions will surpass what came before them because they eliminate inefficiencies from the customer experience.

This not only applies to how technology is adopted, but how customer experiences are created. Mirroring Ockham's Razor Principle, end users and consumers also crave simplicity. End users are choosing to build relationships with brands that guarantee contextual, personalized and frictionless interactions. However, simplicity for end users does not translate into simplicity for CMS owners. Organizations need to be able to manage more data, channels and integrations to deliver the engaging experiences that end users now expect. This desire on the part of end users creates greater platform complexity for CMS owners.

For example, cross-channel experiences are starting to remove certain inefficiencies around traditional websites. In order to optimize the customer experience, enterprise vendors must now expand their digital capabilities beyond web content management and invest in both systems of engagement (various front-end solutions such as conversational interfaces, chatbots, and AR/VR) and systems of intelligence (marketing tools for personalization and predictive analytics).

This year, Acquia Labs built a demo to explore how augmented reality can improve shopping experiences.These trends give organizations the opportunity to reimagine their customer experience. By taking advantage of more channels and more data (e.g. being more intelligent, personalized, and contextualized), we can leapfrog existing customer experiences. However, these ambitious experiences require a platform that prioritizes customization and functionality.

Trend #3: The decoupled CMS market is taking the world by storm

In the web development world, few trends are spreading more rapidly than decoupled content management systems. The momentum is staggering as some decoupled CMS vendors are growing at a rate of 150% year over year. This trend has a significant influence on the technology landscape surrounding DrupalCoin, as a growing number of DrupalCoin agencies have also started using modern JavaScript technologies. For example, more than 50% of DrupalCoin agencies are also using Node.js to support the needs of their customers.

The DrupalCoin community's emphasis on making DrupalCoin API-first, in addition to supporting tools such as Waterwheel and DrupalCoin distributions such as Reservoir, Contenta and Lightning, means that DrupalCoin 8 is well-prepared to support decoupled CMS strategies. For years, including in 2017, Acquia has been a very prominent contributor to a variety of API-first initiatives.

Product milestones

In addition to my focus on finding a new CEO, driving innovation to expand our product offering was another primary focus in 2017.

Throughout Acquia's first decade, we've been focused primarily on providing our customers with the tools and services necessary to scale and succeed with DrupalCoin. We've been very successful with this mission. However, many of our customers need more than content management to be digital winners. The ability to orchestrate customer experiences across different channels is increasingly important to our customers' success. We need to be able to support these efforts on the Acquia platform.

We kicked off our new product strategy by adding new products to our portfolio, and by extending our existing products with new capabilities that align with our customers' evolving needs.

Acquia Cloud: A "continuous integration" and "continuous delivery" service for developers was our #1 requested feature, so we delivered Acquia Cloud CD early in 2017. Later in the year, we expanded Acquia Cloud to support Node.js, the popular open-source JavaScript runtime. This was the first time we expanded our cloud beyond DrupalCoin. Previously, if an organization wanted to build a decoupled DrupalCoin architecture with Node.js, it was not able to host the Node.js application on Acquia Cloud. Finally, in order to make Acquia Cloud easier to use, we started to focus more on self-service. We saw rapid customer adoption of our new Stack Metrics feature, which gives customers valuable insight into performance and utilization. We also introduced a new Cloud Service Management model, which empowers our customer to scale their Acquia Cloud infrastructure on the fly.
Acquia Lift: In order to best support our customers as they embed personalization into their digital strategies, we have continued to add product enhancements to the new version of Acquia Lift. This included improving Acquia Lift's content authoring capabilities, enhanced content recommendations, and advanced analytics and reporting. The Acquia Lift team grew, as we also founded a machine learning and artificial intelligence team, which will lead to new features and products in 2018. In 2017, Acquia Lift has added over 200 new features, tracks 200% more profiles than in 2016, and has grown 45% in revenue.
Next, we added two new products to support our evolution from content management to data-driven customer journeys: Acquia Journey and Acquia Digital Asset Manager (DAM).

Acquia Journey allows marketers to easily map, assemble, orchestrate and manage customer experiences across different channels. One of the strengths of Acquia Journey is that it allows technical teams to integrate many different technologies, from marketing and advertising technologies to CRM tools and commerce platforms. Acquia Journey unifies these various interaction points within a single user interface, making it possible to quickly assemble powerful and complex customer journeys. In turn, marketers can take advantage of a flowchart-style journey mapping tool with unified customer profiles and an automated decision engine to determine the best-next action for engaging customers.
Acquia DAM: Many organizations lack a single-source of truth when it comes to managing digital assets. This challenge has been amplified as the number of assets has rapidly increased in a world with more devices, more channels, more campaigns, and more personalized and contextualized experiences In addition to journey orchestration, it became clear that large organizations are seeking a digital asset management solution that centralizes control of creative assets for the entire company. With Acquia DAM, our customers can rely on one dedicated application to gather requirements, share drafts, consolidate feedback and collect approvals for high-value marketing assets.
Acquia's new product strategy is very ambitious. I'm proud of our stronger focus on innovation and the new features and products that we launched in 2017. Launching this many products and features is hard work and requires tactical coordination across every part of the company. The transition from a single-product company to a multi-product company is challenging, and I hope to share more lessons learned in future blog posts.

While each new product we announced was well-received, there is still a lot of work to be done: we need to continue to drive end-user demand for our new products and help our digital agency partners build practices around them.

Leading by example

At Acquia, our mission is to deliver "the universal platform for the greatest digital experiences", and we want to lead by example. In an effort to become a thought-leader in our field, the Office of the CTO launched Acquia Labs, our research and innovation lab. Acquia Labs aims to link together the new realities in our market, our customers' needs in coming years, and the goals of Acquia's products and open-source efforts in the long term.

Finally, we rounded out the year by redesigning Acquia.com on DrupalCoin 8. The new site places a greater emphasis on taking advantage of our own products. We wanted to show (not tell) the power of the Acquia platform. For example, Acquia Lift delivers visitors personalized content throughout the site. The new site represents a bolder and more innovative Acquia, aligned with the evolution of our product strategy.

Business momentum

We continued to grow at a steady pace in 2017 and hired a lot of new people. We focused on the growth of our recurring revenue, which includes new customers and the renewal and expansion of our work with existing customers. We also focused on our bottom line.

In 2017, the top industry analysts published very positive reviews based on their independent research. I'm proud that Acquia was recognized by Forrester Research as the leader for strategy and vision, ahead of every other vendor including Adobe and Sitecore, in The Forrester Wave: Web Content Management Systems, Q1 2017. Acquia was also named a leader in the 2017 Gartner Magic Quadrant for Web Content Management, marking our placement as a leader for the fourth year in a row. In addition to being the only leader that is open-source or has a cloud-first strategy, Acquia was hailed by analysts for our investments in open APIs across all our products.

Over the course of 2017 Acquia welcomed an impressive roster of new customers who included Astella Pharma, Glanbia, the Commonwealth of Massachusetts, Hewlett Packard Enterprise, and Bayer GmbH. As we enter 2018, Acquia can count 26 of the Fortune 100 among its customers, up from 16 at the beginning of 2017.

This year was also an incredible growth period for our Asia Pacific business, which is growing ARR at a rate of 80% year over year. We have secured new business in Japan, Hong Kong, Singapore, Indonesia, Malaysia, Philippines and India. When we started our business in Australia in 2012, 70% of the pipeline came from govCMS, the platform offered by the Australian government to all national, territorial and local agencies. Today, our business is much more diverse, with 50% of the region's pipeline coming from outside of Australia.

Jeannie Finks, Director of Global Support Systems & Programs, accepting a Gold Stevie for Customer Service Team of the Year. Go team Acquia!Customer success continues to be the most important driver of the evolution of Acquia's strategy. This commitment was reflected in 2017 customer satisfaction levels, which remains extremely high at 94 percent. Acquia's global support team also received top honors from the American Business Awards and won a Gold Stevie for Customer Service Team of the Year.

This year, we also saw our annual customer conference, Acquia Engage, grow. We welcomed over 650 people to Boston and saw presentations from over twenty customers, including Johnson & Johnson, NBC Sports, Whole Foods, AMD, the YMCA and many more. It was inspiring to hear our customers explain why Acquia and DrupalCoin are essential to their business.
Finally, our partner ecosystem continues to advance. In 2016, we achieved a significant milestone as numerous global systems integrators repeatedly recommended Acquia to their clients. One year later, these partners are building large centers of excellence to scale their Acquia and DrupalCoin practices. Digital agencies and DrupalCoin companies also continue to extend their investments in Acquia, and are excited about the opportunity presented in our expanded product portfolio. In some markets, over 50 percent of our new subscriptions originate from our partner ecosystem.

The growth and performance of the partner community is validation of our strategy. For example, in 2017 we saw multiple agencies and integrators that were entirely committed to Adobe or Sitecore, join our program and begin to do business with us.

Opportunities for Acquia in 2018

When thinking about how Acquia has evolved its product strategy, I like to consider it in terms of Greylocks' Jerry Chen's take on the stack of enterprise systems. I've modified his thesis to fit the context of Acquia and our long-term strategy to help organizations with their digital transformation.
Chen's thesis begins with "systems of record", which are sticky and defensible not only because of their data, but also based on the core business process they own. Jerry identifies three major systems of record today; your customers, your employees and your assets. CRM owns your customers (i.e. Salesforce), HCM owns your employees (i.e. Workday), and ERP/Financials owns your assets. Other applications can be built around a system of record but are usually not as valuable as the actual system of record. For example, marketing automation companies like Marketo and Responsys built big businesses around CRM, but never became as strategic or as valuable as Salesforce. We call these "secondary systems of record". We believe that a "content repository" (API-first DrupalCoin) and a "user profile repository" (Acquia Lift) are secondary systems of record. We will continue our efforts to improve DrupalCoin's content repository and Lift's user profile repository to become stronger systems of record.

"Systems of engagement" are the interface between users and the systems of record. They control the end-user interactions. DrupalCoin and Lift are great examples of systems of engagement as they allow for the rapid creation of end-user experiences.

Jerry Chen further suggests that "systems of intelligence" will be a third component. Systems of intelligence will be of critical importance for determining the optimal customer journey across various applications. Personalization (Acquia Lift), recommendations (Acquia Lift) and customer journey building (Acquia Journey) are systems of intelligence. They are very important initiatives for our future.

While Chen does not include "systems of delivery" in his thesis, I believe it is an important component. Systems of delivery not only dictate how content is delivered to users, but how organizations build projects faster and more efficiently for their stakeholders and users. This includes multi-site management (Acquia Cloud Site Factory) and continuous delivery services (Acquia Cloud CD), which extend the benefits of PaaS beyond scalability and reliability to include high-productivity and faster time-to-value for our customers. As organizations increase their investments in cross-channel experiences, they must manage more complexity and orchestrate the testing, integration and deployment of different technologies. Systems of delivery, such as Acquia Cloud and Acquia Site Factory, remove complexity from building and managing modern digital experiences.

This is all consistent with the diagram I've been using for a few years now where "user profile" and "content repository" represent two systems of record, getBestNextExperience() is the system of intelligence, and DrupalCoin is the system of engagement to build the customer experience:

We are confident in the market shift towards "intelligent connected experiences" or "data-driven customer journeys" and the opportunity it provides to Acquia. Every team at Acquia has demonstrated both commitment and focus as we have initiated a shift to make our vision relevant in the market for years to come. I believe we have strong investments across systems of record, intelligence, delivery and engagement that will continue to put us at the center of our customers' technology and digital strategies in 2027.

Thank you

Of course, none of these 2017 results and milestones would be possible without the hard work of the Acquia team, our customers, partners, the DrupalCoin community, and our many friends. Thank you for your support in 2017 and over the past ten years – I can't wait to see what the next decade will bring!
Source: Dries Buytaert www.buytaert.net


A Front End Developer’s Guide to GraphQL

No matter how large or small your application is, you’ll have to deal with fetching data from a remote server at some point. On the front end, this usually involves hitting a REST endpoint, transforming the response, caching it, and updating your UI. For years, REST has been the status quo for APIs, but over the past year, a new API technology called GraphQL has exploded in popularity due to its excellent developer experience and declarative approach to data fetching.
In this post, we’ll walk through a couple of hands-on examples to show you how integrating GraphQL into your application will solve many pain points working with remote data. If you’re new to GraphQL, don’t panic! I’ll also highlight some resources to help you learn GraphQL using the Apollo stack, so you can start off 2018 ahead of the curve.

GraphQL 101
Before we dive into how GraphQL makes your life as a front end developer easier, we should first clarify what it is. When we talk about GraphQL, we're either referring to the language itself or its rich ecosystem of tools. At its core, GraphQL is a typed query language developed by Facebook that allows you to describe your data requirements in a declarative way. The shape of your result matches the shape of your query: in the example below, we can expect to receive back an object with a currency property and a rates property containing an array of objects with both currency and rate keys.
{
rates(currency: "USD") {
currency
rates {
currency
rate
}
}
}
When we talk about GraphQL in a broader sense, we’re often referring to the ecosystem of tools that help you implement GraphQL in your application. On the backend, you’ll use Apollo Server to create a GraphQL server, which is a single endpoint that parses a GraphQL request and returns data. How does the server know which data to return? You’ll use GraphQL Tools to build a schema (like a blueprint for your data) and a resolver map (just a series of functions that retrieve your data from a REST endpoint, database, or wherever else you choose).
This all sounds more complicated than it actually is — with Apollo Launchpad, a GraphQL server playground, you can create a working GraphQL server in your browser in less than 60 lines of code! 😮 We’ll reference this Launchpad I created that wraps the Coinbase API throughout this post.
You’ll connect your GraphQL server to your application with Apollo Client, a fast and flexible client that fetches, caches, and updates your data for you. Since Apollo Client isn’t coupled to your view layer, you can use it with React, Angular, Vue, or plain JavaScript. Not only is Apollo cross-framework, it’s also cross-platform, with React Native & Ionic supported out of the box.
Let’s give it a try! 🚀
Now that you’re well-versed in what GraphQL is, let’s get our hands dirty with a couple of practical examples that illustrate what it’s like to develop your front end with Apollo. By the end, I think you’ll be convinced that a GraphQL-based architecture with Apollo can help you ship features faster than before.
1. Add new data requirements without adding a new endpoint
We’ve all been here before: You spend hours building a perfect UI component when suddenly, product requirements change. You quickly realize that the data you need to fulfill these new requirements would either require a complicated waterfall of API requests or worse, a new REST endpoint. Now blocked on your work, you ask the backend team to build you a new endpoint just to satisfy the data needs for one component.
This common frustration no longer exists with GraphQL because the data you consume on the client is no longer coupled to an endpoint’s resource. Instead, you always hit the same endpoint for your GraphQL server. Your server specifies all of the resources it has available via your schema and lets your query determine the shape of the result. Let’s illustrate these concepts using our Launchpad from before:
In our schema, look at lines 22–26 where we define our ExchangeRate type. These fields list out all the available resources we can query in our application.
type ExchangeRate {
currency: String
rate: String
name: String
}
With REST, you’re limited to the data your resource provides. If your /exchange-rates endpoint doesn’t include name, then you’ll need to either hit a different endpoint like /currency for the data or create it if it doesn’t exist.
With GraphQL, we know that name is already available to us by inspecting our schema, so we can query for it in our application. Try running this example in Launchpad by adding the name field on the right side panel!
{
rates(currency: "USD") {
currency
rates {
currency
rate
name
}
}
}
Now, remove the name field and run the same query. See how the shape of our result changes?

Your GraphQL server always gives you back exactly the data you ask for. Nothing more. This differs significantly from REST, where you often have to filter and transform the data you get back from the server into the shape your UI components need. Not only does this save you time, it also results in smaller network payloads and CPU savings from loading and parsing the response.
2. Reduce your state management boilerplate
Fetching data almost always involves updating your application’s state. Typically, you’ll write code to track at least three actions: one for when the data is loading, one if the data successfully arrives, and one if the data errors out. Once the data arrives, you have to transform it into the shape your UI components expect, normalize it, cache it, and update your UI. This process can be repetitive, requiring countless lines of boilerplate to execute one request.
Let’s see how Apollo Client eliminates this tiresome process altogether by looking at an example React app in CodeSandbox. Navigate to `list.js` and scroll to the bottom.
export default graphql(ExchangeRateQuery, {
props: ({ data }) => {
if (data.loading) {
return { loading: data.loading };
}
if (data.error) {
return { error: data.error };
}
return {
loading: false,
rates: data.rates.rates
};
}
})(ExchangeRateList);
In this example, React Apollo, Apollo Client’s React integration, is binding our exchange rate query to our ExchangeRateList component. Once Apollo Client executes that query, it tracks loading and error state automatically and adds it to the data prop. When Apollo Client receives the result, it will update the data prop with the result of the query, which will update your UI with the rates it needs to render.
Under the hood, Apollo Client normalizes and caches your data for you. Try clicking some of the currencies in the panel on the right to watch the data refresh. Now, select a currency a second time. Notice how the data appears instantaneously? That’s the Apollo cache at work! You get all of this for free just by setting up Apollo Client with no additional configuration. 😍 To see the code where we initialize Apollo Client, check out `index.js`.
3. Debug quickly & painlessly with Apollo DevTools & GraphiQL
It looks like Apollo Client does a lot for you! How do we peek inside to understand what’s going on? With features like store inspection and full visibility into your queries & mutations, Apollo DevTools not only answers that question, but also makes debugging painless and, dare I say it, fun! 🎉 It’s available as an extension for both Chrome and Firefox, with React Native coming soon.
If you want to follow along, install Apollo DevTools for your preferred browser and navigate to our CodeSandbox from the previous example. You’ll need to run the example locally by clicking Download in the top nav bar, unzipping the file, running npm install, and finally npm start. Once you open up your browser’s dev tools panel, you should see a tab that says Apollo.
First, let’s check out our store inspector. This tab mirrors what’s currently in your Apollo Client cache, making it easy to confirm your data is stored on the client properly.

Apollo DevTools also enables you to test your queries & mutations in GraphiQL, an interactive query editor and documentation explorer. In fact, you already used GraphiQL in the first example where we experimented with adding fields to our query. To recap, GraphiQL features auto-complete as you type your query into the editor and automatically generated documentation based on GraphQL’s type system. It’s extremely useful for exploring your schema, with zero maintenance burden for developers.

Try executing queries with GraphiQL in the right side panel of our Launchpad. To show the documentation explorer, you can hover over fields in the query editor and click on the tooltip. If your query runs successfully in GraphiQL, you can be 100% positive that the same query will run successfully in your application.
Level up your GraphQL skills
If you made it to this point, awesome job! 👏 I hope you enjoyed the exercises and got a taste of what it would be like to work with GraphQL on the front end.
Hungry for more? 🌮 Make it your 2018 New Year’s resolution to learn more about GraphQL, as I expect its popularity to grow even more in the upcoming year. Here’s an example app to get you started featuring the concepts we learned today:

React: https://codesandbox.io/s/jvlrl98xw3
Angular (Ionic): https://github.com/aaronksaunders/ionicLaunchpadApp
Vue: https://codesandbox.io/s/3vm8vq6kwq

Go forth and GraphQL (and be sure to tag us on Twitter @apollographql along the way)! 🚀

A Front End Developer’s Guide to GraphQL is a post from CSS-Tricks
Source: CssTricks


DrupalCoin Blockchain Web Developer - Chandra Technologies Inc - Madison, WI

DrupalCoin Blockchain Web Developer. Advance experience with DrupalCoin Blockchain architecture, best practices, and coding standards (3 Years).... $50 an hour
From Chandra Technologies Inc - Sat, 02 Dec 2017 12:48:45 GMT - View all Madison, WI jobs
Source: http://rss.indeed.com/rss?q=DrupalCoin Blockchain+Developer


Web Designer / Developer (senior level) - State Government - SunPlus Data Group, Inc. - Madison, WI

Advance experience with DrupalCoin Blockchain architecture, best practices, and coding standards. SunPlus Data Group is seeking a Web Designer / Developer for a State...
From Indeed - Fri, 01 Dec 2017 16:08:11 GMT - View all Madison, WI jobs
Source: http://rss.indeed.com/rss?q=DrupalCoin Blockchain+Developer


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


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


Accessible Web Apps with React, TypeScript, and AllyJS

Accessibility is an aspect of web integrationthat is often overlooked. I would argue that it is as vital as overall performance and code reusability. We justify our endless pursuit of better performance and responsive design by citing the users, but ultimately these pursuits are done with the user's device in mind, not the user themselves and their potential disabilities or restrictions.
A responsive app should be one that delivers its content based on the needs of the user, not only their device.
Luckily, there are tools to help alleviate the learning curve of accessibility-minded development. For example, GitHub recently released their accessibility error scanner, AccessibilityJS and Deque has aXe. This article will focus on a different one: Ally.js, a library simplifying certain accessibility features, functions, and behaviors.

One of the most common pain points regarding accessibility is dialog windows.
There're a lot of considerations to take in terms of communicating to the user about the dialog itself, ensuring ease of access to its content, and returning to the dialog's trigger upon close.
A demo on the Ally.js website addresses this challenge which helped me port its logic to my current project which uses React and TypeScript. This post will walk through building an accessible dialog component.
Demo of accessible dialog window using Ally.js within React and TypeScript
View the live demo
Project Setup with create-react-app
Before getting into the use of Ally.js, let's take a look at the initial setup of the project. The project can be cloned from GitHub or you can follow along manually. The project was initiated using create-react-app in the terminal with the following options:
create-react-app my-app --scripts-version=react-scripts-ts
This created a project using React and ReactDOM version 15.6.1 along with their corresponding @types.
With the project created, let's go ahead and take a look at the package file and project scaffolding I am using for this demo.
Project architecture and package.json file
As you can see in the image above, there are several additional packages installed but for this post we will ignore those related to testing and focus on the primary two, ally.js and babel-polyfill.
Let's install both of these packages via our terminal.
yarn add ally.js --dev && yarn add babel-polyfill --dev
For now, let's leave `/src/index.tsx` alone and hop straight into our App container.
App Container
The App container will handle our state that we use to toggle the dialog window. Now, this could also be handled by Redux but that will be excluded in lieu of brevity.
Let's first define the state and toggle method.
interface AppState {
showDialog: boolean;
}

class App extends React.Component<{}, AppState> {
state: AppState;

constructor(props: {}) {
super(props);

this.state = {
showDialog: false
};
}

toggleDialog() {
this.setState({ showDialog: !this.state.showDialog });
}
}
The above gets us started with our state and the method we will use to toggle the dialog. Next would be to create an outline for our render method.
class App extends React.Component<{}, AppState> {
...

render() {
return (
<div className="site-container">
<header>
<h1>Ally.js with React &amp; Typescript</h1>
</header>
<main className="content-container">
<div className="field-container">
<label htmlFor="name-field">Name:</label>
<input type="text" id="name-field" placeholder="Enter your name" />
</div>
<div className="field-container">
<label htmlFor="food-field">Favourite Food:</label>
<input type="text" id="food-field" placeholder="Enter your favourite food" />
</div>
<div className="field-container">
<button
className='btn primary'
tabIndex={0}
title='Open Dialog'
onClick={() => this.toggleDialog()}
>
Open Dialog
</button>
</div>
</main>
</div>
);
}
}
Don't worry much about the styles and class names at this point. These elements can be styled as you see fit. However, feel free to clone the GitHub repo for the full styles.
At this point we should have a basic form on our page with a button that when clicked toggles our showDialog state value. This can be confirmed by using React's Developer Tools.
So let's now have the dialog window toggle as well with the button. For this let's create a new Dialog component.
Dialog Component
Let's look at the structure of our Dialog component which will act as a wrapper of whatever content (children) we pass into it.
interface Props {
children: object;
title: string;
description: string;
close(): void;
}

class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;

render() {
return (
<div
role="dialog"
tabIndex={0}
className="popup-outer-container"
aria-hidden={false}
aria-labelledby="dialog-title"
aria-describedby="dialog-description"
ref={(popup) => {
this.dialog = popup;
}
}
>
<h5
id="dialog-title"
className="is-visually-hidden"
>
{this.props.title}
</h5>
<p
id="dialog-description"
className="is-visually-hidden"
>
{this.props.description}
</p>
<div className="popup-inner-container">
<button
className="close-icon"
title="Close Dialog"
onClick={() => {
this.props.close();
}}
>
×
</button>
{this.props.children}
</div>
</div>
);
}
}
We begin this component by creating the Props interface. This will allow us to pass in the dialog's title and description, two important pieces for accessibility. We will also pass in a close method, which will refer back to the toggleDialog method from the App container. Lastly, we create the functional ref to the newly created dialog window to be used later.
The following styles can be applied to create the dialog window appearance.
.popup-outer-container {
align-items: center;
background: rgba(0, 0, 0, 0.2);
display: flex;
height: 100vh;
justify-content: center;
padding: 10px;
position: absolute;
width: 100%;
z-index: 10;
}

.popup-inner-container {
background: #fff;
border-radius: 4px;
box-shadow: 0px 0px 10px 3px rgba(119, 119, 119, 0.35);
max-width: 750px;
padding: 10px;
position: relative;
width: 100%;
}

.popup-inner-container:focus-within {
outline: -webkit-focus-ring-color auto 2px;
}

.close-icon {
background: transparent;
color: #6e6e6e;
cursor: pointer;
font: 2rem/1 sans-serif;
position: absolute;
right: 20px;
top: 1rem;
}
Now, let's tie this together with the App container and then get into Ally.js to make this dialog window more accessible.
App Container
Back in the App container, let's add a check inside of the render method so any time the showDialog state updates, the Dialog component is toggled.
class App extends React.Component<{}, AppState> {
...

checkForDialog() {
if (this.state.showDialog) {
return this.getDialog();
} else {
return false;
}
}

getDialog() {
return (
<Dialog
title="Favourite Holiday Dialog"
description="Add your favourite holiday to the list"
close={() => { this.toggleDialog(); }}
>
<form className="dialog-content">
<header>
<h1 id="dialog-title">Holiday Entry</h1>
<p id="dialog-description">Please enter your favourite holiday.</p>
</header>
<section>
<div className="field-container">
<label htmlFor="within-dialog">Favourite Holiday</label>
<input id="within-dialog" />
</div>
</section>
<footer>
<div className="btns-container">
<Button
type="primary"
clickHandler={() => { this.toggleDialog(); }}
msg="Save"
/>
</div>
</footer>
</form>
</Dialog>
);
}

render() {
return (
<div className="site-container">
{this.checkForDialog()}
...
);
}
}
What we've done here is add the methods checkForDialog and getDialog.
Inside of the render method, which runs any time the state updates, there is a call to run checkForDialog. So upon clicking the button, the showDialog state will update, causing a re-render, calling checkForDialog again. Only now, showDialog is true, triggering getDialog. This method returns the Dialog component we just built to be rendered onto the screen.
The above sample includes a Button component that has not been shown.
Now, we should have the ability to open and close our dialog. So let's take a look at what problems exist in terms of accessibility and how we can address them using Ally.js.

Using only your keyboard, open the dialog window and try to enter text into the form. You'll notice that you must tab through the entire document to reach the elements within the dialog. This is a less-than-ideal experience. When the dialog opens, our focus should be the dialog  -  not the content behind it. So let's look at our first use of Ally.js to begin remedying this issue.
Ally.js
Ally.js is a library providing various modules to help simplify common accessibility challenges. We will be using four of these modules for the Dialog component.
The .popup-outer-container acts as a mask that lays over the page blocking interaction from the mouse. However, elements behind this mask are still accessible via keyboard, which should be disallowed. To do this the first Ally module we'll incorporate is maintain/disabled. This is used to disable any set of elements from being focussed via keyboard, essentially making them inert.
Unfortunately, implementing Ally.js into a project with TypeScript isn't as straightforward as other libraries. This is due to Ally.js not providing a dedicated set of TypeScript definitions. But no worries, as we can declare our own modules via TypeScript's types files.
In the original screenshot showing the scaffolding of the project, we see a directory called types. Let's create that and inside create a file called `global.d.ts`.
Inside of this file let's declare our first Ally.js module from the esm/ directory which provides ES6 modules but with the contents of each compiled to ES5. These are recommended when using build tools.
declare module 'ally.js/esm/maintain/disabled';
With this module now declared in our global types file, let's head back into the Dialog component to begin implementing the functionality.
Dialog Component
We will be adding all the accessibility functionality for the Dialog to its component to keep it self-contained. Let's first import our newly declared module at the top of the file.
import Disabled from 'ally.js/esm/maintain/disabled';
The goal of using this module will be once the Dialog component mounts, everything on the page will be disabled while filtering out the dialog itself.
So let's use the componentDidMount lifecycle hook for attaching any Ally.js functionality.
interface Handle {
disengage(): void;
}

class Dialog extends React.Component<Props, {}> {
dialog: HTMLElement | null;
disabledHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});
}

componentWillUnmount() {
this.disabledHandle.disengage();
}
...
}
When the component mounts, we store the Disabled functionality to the newly created component property disableHandle. Because there are no defined types yet for Ally.js we can create a generic Handle interface containing the disengage function property. We will be using this Handle again for other Ally modules, hence keeping it generic.
By using the filter property of the Disabled import, we're able to tell Ally.js to disable everything in the document except for our dialog reference.
Lastly, whenever the component unmounts we want to remove this behaviour. So inside of the componentWillUnmount hook, we disengage() the disableHandle.

We will now follow this same process for the final steps of improving the Dialog component. We will use the additional Ally modules:

maintain/tab-focus
query/first-tabbable
when/key

Let's update the `global.d.ts` file so it declares these additional modules.
declare module 'ally.js/esm/maintain/disabled';
declare module 'ally.js/esm/maintain/tab-focus';
declare module 'ally.js/esm/query/first-tabbable';
declare module 'ally.js/esm/when/key';
As well as import them all into the Dialog component.
import Disabled from 'ally.js/esm/maintain/disabled';
import TabFocus from 'ally.js/esm/maintain/tab-focus';
import FirstTab from 'ally.js/esm/query/first-tabbable';
import Key from 'ally.js/esm/when/key';
Tab Focus
After disabling the document with the exception of our dialog, we now need to restrict tabbing access further. Currently, upon tabbing to the last element in the dialog, pressing tab again will begin moving focus to the browser's UI (such as the address bar). Instead, we want to leverage tab-focus to ensure the tab key will reset to the beginning of the dialog, not jump to the window.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});
}

componentWillUnmount() {
this.disabledHandle.disengage();
this.focusHandle.disengage();
}
...
}
We follow the same process here as we did for the disabled module. Let's create a focusHandle property which will assume the value of the TabFocus module import. We define the context to be the active dialog reference on mount and then disengage() this behaviour, again, when the component unmounts.
At this point, with a dialog window open, hitting tab should cycle through the elements within the dialog itself.
Now, wouldn't it be nice if the first element of our dialog was already focused upon opening?
First Tab Focus
Leveraging the first-tabbable module, we are able to set focus to the first element of the dialog window whenever it mounts.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});

let element = FirstTab({
context: this.dialog,
defaultToContext: true,
});
element.focus();
}
...
}
Within the componentDidMount hook, we create the element variable and assign it to our FirstTab import. This will return the first tabbable element within the context that we provide. Once that element is returned, calling element.focus() will apply focus automatically.
Now, that we have the behavior within the dialog working pretty well, we want to improve keyboard accessibility. As a strict laptop user myself (no external mouse, monitor, or any peripherals) I tend to instinctively press esc whenever I want to close any dialog or popup. Normally, I would write my own event listener to handle this behavior but Ally.js provides the when/key module to simplify this process as well.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;
keyHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});

let element = FirstTab({
context: this.dialog,
defaultToContext: true,
});
element.focus();

this.keyHandle = Key({
escape: () => { this.props.close(); },
});
}

componentWillUnmount() {
this.disabledHandle.disengage();
this.focusHandle.disengage();
this.keyHandle.disengage();
}
...
}
Again, we provide a Handle property to our class which will allow us to easily bind the esc functionality on mount and then disengage() it on unmount. And like that, we're now able to easily close our dialog via the keyboard without necessarily having to tab to a specific close button.
Lastly (whew!), upon closing the dialog window, the user's focus should return to the element that triggered it. In this case, the Show Dialog button in the App container. This isn't built into Ally.js but a recommended best practice that, as you'll see, can be added in with little hassle.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;
keyHandle: Handle;
focusedElementBeforeDialogOpened: HTMLInputElement | HTMLButtonElement;

componentDidMount() {
if (document.activeElement instanceof HTMLInputElement ||
document.activeElement instanceof HTMLButtonElement) {
this.focusedElementBeforeDialogOpened = document.activeElement;
}

this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});

let element = FirstTab({
context: this.dialog,
defaultToContext: true,
});

this.keyHandle = Key({
escape: () => { this.props.close(); },
});
element.focus();
}

componentWillUnmount() {
this.disabledHandle.disengage();
this.focusHandle.disengage();
this.keyHandle.disengage();
this.focusedElementBeforeDialogOpened.focus();
}
...
}
What has been done here is a property, focusedElementBeforeDialogOpened, has been added to our class. Whenever the component mounts, we store the current activeElement within the document to this property.
It's important to do this before we disable the entire document or else document.activeElement will return null.
Then, like we had done with setting focus to the first element in the dialog, we will use the .focus() method of our stored element on componentWillUnmount to apply focus to the original button upon closing the dialog. This functionality has been wrapped in a type guard to ensure the element supports the focus() method.

Now, that our Dialog component is working, accessible, and self-contained we are ready to build our App. Except, running yarn test or yarn build will result in an error. Something to this effect:
[path]/node_modules/ally.js/esm/maintain/disabled.js:21
import nodeArray from '../util/node-array';
^^^^^^

SyntaxError: Unexpected token import
Despite Create React App and its test runner, Jest, supporting ES6 modules, an issue is still caused with the ESM declared modules. So this brings us to our final step of integrating Ally.js with React, and that is the babel-polyfill package.
All the way in the beginning of this post (literally, ages ago!), I showed additional packages to install, the second of which being babel-polyfill. With this installed, let's head to our app's entry point, in this case ./src/index.tsx.
Index.tsx
At the very top of this file, let's import babel-polyfill. This will emulate a full ES2015+ environment and is intended to be used in an application rather than a library/tool.
import 'babel-polyfill';
With that, we can return to our terminal to run the test and build scripts from create-react-app without any error.
Demo of accessible dialog window using Ally.js within React and TypeScript
View the live demo

Now that Ally.js is incorporated into your React and TypeScript project, more steps can be taken to ensure your content can be consumed by all users, not just all of their devices.
For more information on accessibility and other great resources please visit these resources:

Accessible Web Apps with React, TypeScript & Ally.js on Github
Start Building Accessible Web Applications Today
HTML Codesniffer
Web Accessibility Best Practices
Writing CSS with Accessibility in Mind
Accessibility Checklist

Accessible Web Apps with React, TypeScript, and AllyJS is a post from CSS-Tricks
Source: CssTricks


Adapting JavaScript Abstractions Over Time

Even if you haven't read my post The Importance Of JavaScript Abstractions When Working With Remote Data, chances are you're already convinced that maintainability and scalability are important for your project and the way toward that is introducing abstractions.
For the purposes of this post, let's assume that an abstraction, in JavaScript, is a module.

The initial implementation of a module is only the beginning of the long (and hopefully lasting) process of their life-being. I see 3 major events in the lifecycle of a module:

Introduction of the module. The initial implementation and the process of re-using it around the project.
Changing the module. Adapting the module over time.
Removing the module.

In my previous post the emphasis was just on that first one. In this article, think more about that second one.
Handling changes to a module is a pain point I see frequently. Compared to introducing the module, the way developers maintain or change it is equally or even more important for keeping the project maintainable and scalable. I've seen a well-written and abstracted module completely ruined over time by changes. I've sometimes been the one who has made those disastrous changes!
When I say disastrous, I mean disastrous from a maintainability and scalability perspective. I understand that from the perspective of approaching deadlines and releasing features which must work, slowing down to think about all the potential image of your change isn't always an option.
The reasons why a developer's changes might not be as optimal are countless. I'd like to stress one in particular:
The Skill of Making Changes in Maintainable Manner
Here's a way you can start making changes like a pro.
Let's start with a code example: an API module. I choose this because communicating with an external API is one of the first fundamental abstractions I define when I start a project. The idea is to store all the API related configuration and settings (like the base URL, error handling logic, etc) in this module.
Let's introduce only one setting, API.url, one private method, API._handleError(), and one public method, API.get():
class API {
constructor() {
this.url = 'http://whatever.api/v1/';
}

/**
* Fetch API's specific way to check
* whether an HTTP response's status code is in the successful range.
*/
_handleError(_res) {
return _res.ok ? _res : Promise.reject(_res.statusText);
}

/**
* Get data abstraction
* @return {Promise}
*/
get(_endpoint) {
return window.fetch(this.url + _endpoint, { method: 'GET' })
.then(this._handleError)
.then( res => res.json())
.catch( error => {
alert('So sad. There was an error.');
throw new Error(error);
});
}
};
In this module, our only public method, API.get() returns a Promise. In all places where we need to get remote data, instead of directly calling the Fetch API via window.fetch(), we use our API module abstraction. For example to get user's info API.get('user') or the current weather forecast API.get('weather'). The important thing about this implementation is that the Fetch API is not tightly coupled with our code.
Now, let's say that a change request comes! Our tech lead asks us to switch to a different method of getting remote data. We need to switch to Axios. How can we approach this challenge?
Before we start discussing approaches, let's first summarize what stays the same and what changes:

Change: In our public API.get() method:

We need to change the window.fetch() call with axios(). And we need to return a Promise again, to keep our implementation consistent. Axios is Promise based. Excellent!
Our server's response is JSON. With the Fetch API chain a .then( res => res.json()) statement to parse our response data. With Axios, the response that was provided by the server is under the data property and we don't need to parse it. Therefore, we need to change the .then statement to .then( res => res.data ).

Change: In our private API._handleError method:

The ok boolean flag is missing in the object response. However, there is statusText property. We can hook-up on it. If its value is 'OK', then it's all good.
Side note: yes, having ok equal to true in Fetch API is not the same as having 'OK' in Axios's statusText. But let's keep it simple and, for the sake of not being too broad, leave it as it is and not introduce any advanced error handling.

No change: The API.url stays the same, along with the funky way we catch errors and alert them.

All clear! Now let's drill down to the actual approaches to apply these changes.
Approach 1: Delete code. Write code.
class API {
constructor() {
this.url = 'http://whatever.api/v1/'; // says the same
}

_handleError(_res) {
// DELETE: return _res.ok ? _res : Promise.reject(_res.statusText);
return _res.statusText === 'OK' ? _res : Promise.reject(_res.statusText);
}

get(_endpoint) {
// DELETE: return window.fetch(this.url + _endpoint, { method: 'GET' })
return axios.get(this.url + _endpoint)
.then(this._handleError)
// DELETE: .then( res => res.json())
.then( res => res.data)
.catch( error => {
alert('So sad. There was an error.');
throw new Error(error);
});
}
};
Sounds reasonable enough. Commit. Push. Merge. Done.
However, there are certain cases why this might not be a good idea. Imagine the following happens: after switching to Axios, you find out that there is a feature which doesn't work with XMLHttpRequests (the Axios's interface for getting resource method), but was previously working just fine with Fetch's fancy new browser API. What do we do now?
Our tech lead says, let's use the old API implementation for this specific use-case, and keep using Axios everywhere else. What do you do? Find the old API module in your source control history. Revert. Add if statements here and there. Doesn't sound very good to me.
There must be an easier, more maintainable and scalable way to make changes! Well, there is.
Approach 2: Refactor code. Write Adapters!
There's an incoming change request! Let's start all over again and instead of deleting the code, let's move the Fetch's specific logic in another abstraction, which will serve as an adapter (or wrapper) of all the Fetch's specifics.
For those of you familiar with the Adapter Pattern (also referred to as the Wrapper Pattern), yes, that's exactly where we're headed! See an excellent nerdy introduction here, if you're interested in all the details.
Here's the plan:

Step 1
Take all Fetch specific lines from the API module and refactor them to a new abstraction, FetchAdapter.
class FetchAdapter {
_handleError(_res) {
return _res.ok ? _res : Promise.reject(_res.statusText);
}

get(_endpoint) {
return window.fetch(_endpoint, { method: 'GET' })
.then(this._handleError)
.then( res => res.json());
}
};
Step 2
Refactor the API module by removing the parts which are Fetch specific and keep everything else the same. Add FetchAdapter as a dependency (in some manner):
class API {
constructor(_adapter = new FetchAdapter()) {
this.adapter = _adapter;

this.url = 'http://whatever.api/v1/';
}

get(_endpoint) {
return this.adapter.get(_endpoint)
.catch( error => {
alert('So sad. There was an error.');
throw new Error(error);
});
}
};
That's a different story now! The architecture is changed in a way you are able to handle different mechanisms (adapters) for getting resources. Final step: You guessed it! Write an AxiosAdapter!
const AxiosAdapter = {
_handleError(_res) {
return _res.statusText === 'OK' ? _res : Promise.reject(_res.statusText);
},

get(_endpoint) {
return axios.get(_endpoint)
.then(this._handleError)
.then( res => res.data);
}
};
And in the API module, switch the default adapter to the Axios one:
class API {
constructor(_adapter = new /*FetchAdapter()*/ AxiosAdapter()) {
this.adapter = _adapter;

/* ... */
}
/* ... */
};
Awesome! What do we do if we need to use the old API implementation for this specific use-case, and keep using Axios everywhere else? No problem!
// Import your modules however you like, just an example.
import API from './API';
import FetchAdapter from './FetchAdapter';

// Uses the AxiosAdapter (the default one)
const API = new API();
API.get('user');

// Uses the FetchAdapter
const legacyAPI = new API(new FetchAdapter());
legacyAPI.get('user');

So next time you need to make changes to your project, evaluate which approach makes more sense:

Delete code. Write code
Refactor Code. Write Adapters.

Judge carefully based on your specific use-case. Over-adapter-ifying your codebase and introducing too many abstractions could lead to increasing complexity which isn't good either.
Happy adapter-ifying!

Adapting JavaScript Abstractions Over Time is a post from CSS-Tricks
Source: CssTricks


Learn to build a DrupalCoin Blockchain 8 website in our hands-on class (Dec 1, 2017)

Start: 
2017-12-01 13:00 - 16:30 America/Los_Angeles

Organizers: 

douglaschoffman

rich.yumul

Event type: 

Training (free or commercial)

https://www.eventbrite.com/publish?crumb=bc5ad05c34d076&eid=39665241806

INTRO TO DRUPAL 8
The DrupalCoin Blockchain open-source content management system (CMS) powers more than one million websites and more than twelve percent of the top 100,000 according to BuiltWith.
Join us for an introduction to DrupalCoin Blockchain 8 websites.
Hosted by Sagetree, a forward thinking digital agency, crafting compelling brands, using technology and creativity to help you grow.
DETAILS:
When: Friday December 1st, 2017 from 1:00pm - 4:00pmWhere: Regus @ Gateway Chula Vista, 333 H Street, Suite 5000, Chula Vista, California, 91910What to bring: Wi-Fi enabled laptop with a web browser to participate in the hands on labs
This workshop will examine DrupalCoin Blockchain website architecture, design, site building, theming, module integrationand data visualization.
DRUPAL CONCEPTS
Users, roles and permissionsMenu systemContent typesTaxonomiesViews
AGENDA
1:00pm - Introductions 1:15pm - Install DrupalCoin Blockchain 81:30pm - Build basic DrupalCoin Blockchain 8 site2:00pm - Define taxonomies2:30pm - Define content types3:00pm - Build views3:30pm - Q&A
This workshop includes hands-on labs. If you wish to participate in the hands-on labs please bring your own laptop with WiFi, otherwise you can follow along during the labs. Each student will build out a fully functional web site using DrupalCoin Blockchain sandboxes on the Pantheon hosting platform.
RSVP using the form above. We look forward to seeing you at our event!
Source: https://groups.drupal.org/node/512931/feed


The evolution of Acquia's product strategy

Four months ago, I shared that Acquia was on the verge of a shift equivalent to the decision to launch Acquia Fields and DrupalCoin Blockchain Gardens in 2008. As we entered Acquia's second decade, we outlined a goal to move from content management to data-driven customer journeys. Today, Acquia announced two new products that support this mission: Acquia Journey and Acquia Digital Asset Manager (DAM).

Last year on my blog, I shared a video that demonstrated what is possible with cross-channel user experiences and DrupalCoin Blockchain. We showed a sample supermarket chain called Gourmet Market. Gourmet Market wants its customers to not only shop online using its website, but to also use Amazon Echo or push notifications to do business with them. The Gourmet Market prototype showed an omnichannel customer experience that is both online and offline, in store and at home, and across multiple digital touchpoints. The Gourmet Market demo video was real, but required manual integrationand lacked easy customization. Today, the launch of Acquia Journey and Acquia DAM makes building these kind of customer experiences a lot easier. It marks an important milestone in Acquia's history, as it will accelerate our transition from content management to data-driven customer journeys.

Introducing Acquia Journey

I've written a great deal about the Big Reverse of the Web, which describes the transition from "pull-based" delivery of the web, meaning we visit websites, to a "push-based" delivery, meaning the web comes to us. The Big Reverse forces a major re-architecture of the web to bring the right information, to the right person, at the right time, in the right context.

The Big Reverse also ushers in the shift from B2C to B2One, where organizations develop a one-to-one relationship with their customers, and contextual and personalized interactions are the norm. In the future, every organization will have to rethink how it interacts with customers.

Successfully delivering a B2One experience requires an understanding of your user's journey and matching the right information or service to the user's context. This alone is no easy feat, and many marketers and other digital experience builders often get frustrated with the challenge of rebuilding customer experiences. For example, although organizations can create brilliant campaigns and high-value content, it's difficult to effectively disseminate marketing efforts across multiple channels. When channels, data and marketing software act in different silos, it's nearly impossible to build a seamless customer experience. The inability to connect customer profiles and journey maps with various marketing tools can result in unsatisfied customers, failed conversion rates, and unrealized growth.

Acquia Journey delivers on this challenge by enabling marketers to build data-driven customer journeys. It allows marketers to easily map, assemble, orchestrate and manage customer experiences like the one we showed in our Gourmet Market prototype.

It's somewhat difficult to explain Acquia Journey in words — probably similar to trying to explain what a content management system does to someone who has never used one before. Acquia Journey provides a single interface to define and evaluate customer journeys across multiple interaction points. It combines a flowchart-style journey mapping tool with unified customer profiles and an automated decision engine. Rules-based triggers and logic select and deliver the best-next action for engaging customers.

One of the strengths of Acquia Journey is that it integrates many different technologies, from marketing and advertising technologies to CRM tools and commerce platforms. This makes it possible to quickly assemble powerful and complex customer journeys.

Acquia Journey will simplify how organizations deliver the "best next experience" for the customer. Providing users with the experience they not only want, but expect will increase conversion rates, grow brand awareness, and accelerate revenue. The ability for organizations to build more relevant user experiences not only aligns with our customers' needs but will enable them to make the biggest impact possible for their customers.

Acquia's evolving product offering also puts control of user data and experience back in the hands of the organization, instead of walled gardens. This is a step toward uniting the Open Web.

Introducing Acquia Digital Asset Manager (DAM)

Digital asset management systems have been around for a long time, and were originally hosted through on-premise servers. Today, most organizations have abandoned on-premise or do-it-yourself DAM solutions. After listening to our customers, it became clear that large organizations are seeking a digital asset management solution that centralizes control of creative assets for the entire company.

Many organizations lack a single-source of truth when it comes to managing digital assets. This challenge has been amplified as the number of assets has rapidly increased in a world with more devices, more channels, more campaigns, and more personalized and contextualized experiences. Acquia DAM provides a centralized repository for managing all rich media assets, including photos, videos, PDFs, and other corporate documents. Creative and marketing teams can upload and manage files in Acquia DAM, which can then be shared across the organization. Graphic designers, marketers and web managers all have a hand in translating creative concepts into experiences for their customers. With Acquia DAM, every team can rely on one dedicated application to gather requirements, share drafts, consolidate feedback and collect approvals for high-value marketing assets.

On top of DrupalCoin Blockchain's asset and media management capabilities, Acquia DAM provides various specialized functionality, such as automatic transcoding of assets upon download, image and video mark-up during approval workflows, and automated tagging for images using machine learning and image recognition.

By using a drag-and-drop interface on Acquia DAM, employees can easily publish approved assets in addition to searching the repository for what they need.Acquia DAM seamlessly integrates with both DrupalCoin Blockchain 7 and DrupalCoin Blockchain 8 (using DrupalCoin Blockchain's "media entities"). In addition to DrupalCoin Blockchain, Acquia DAM is built to integrate with the entirety of the Acquia Platform. This includes Acquia Lift and Acquia Journey, which means that any asset managed in the Acquia DAM repository can be utilized to create personalized experiences across multiple DrupalCoin Blockchain sites. Additionally, through a REST API, Acquia DAM can also be integrated with other marketing technologies. For example, Acquia DAM supports designers with a plug in to Adobe Creative Cloud, which integrates with Photoshop, InDesign and Illustrator.

Acquia's roadmap to data-driven customer journeys

Throughout Acquia's first decade, we've been primarily focused on providing our customers with the tools and services necessary to scale and succeed with content management. We've been very successful with helping our customers scale and manage DrupalCoin Blockchain and cloud solutions. DrupalCoin Blockchain will remain a critical component to our customer's success, and we will continue to honor our history as committed supporters of open source, in addition to investing in DrupalCoin Blockchain's future.

However, many of our customers need more than content management to be digital winners. The ability to orchestrate customer experiences using content, user data, decisioning systems, analytics and more will be essential to an organization's success in the future. Acquia Journey and Acquia DAM will remove the complexity from how organizations build modern digital experiences and customer journeys. We believe that expanding our platform will be good not only for Acquia, but for our partners, the DrupalCoin Blockchain community, and our customers.


Source: Dries Buytaert www.buytaert.net