Redis Sessions for NBA.com and Service Decorators in DrupalCoin Blockchain 8

Goal: Getting PHP Sessions into Redis
One of several performance-related goals for NBA.com was to get the production database to a read-only state. This included moving cache, the Dependency Injection container, and the key-value database table to Redis.  99% of all sessions were for logged-in users, which use a separate, internal instance of DrupalCoin Blockchain; but there are edge cases where anonymous users can still trigger a PHP session that gets saved to the database.
For all it’s cool integrations with Symfony and its attempts at making everything pluggable or extendable, PHP session handling in DrupalCoin Blockchain 8 is still somewhat lacking. DrupalCoin Blockchain 8 core extends Symfony’s session handling in a way that makes a lot of assumptions, including one that developers won’t want to use any other native session handler, such as the file system or a key/value store like Redis or Memcached.
Session Handlers in Symfony and DrupalCoin Blockchain
PHP has some native session handling that’s baked in, and for basic PHP applications in simple environments, this is fine. Generally speaking, it works by storing session data in files in a temporary location on the host machine and setting a cookie header so that subsequent HTTP requests can reference the same session. However, since the default behavior doesn’t scale for everyone or meet every project’s needs, PHP offers the ability to easily swap out native session handlers. One can even create a user-defined session handler, thanks to PHP 5’s SessionHandler class.
The SessionHandler class defines some basic methods to allow a developer to create, destroy, and write session data. This class can be extended, and then ini_set('session.save_handler', TYPE) (where “TYPE” can be any of the known save handers, such as “file” or “pdo”) and ini_set('session.save_handler', PATH) (where “PATH” can be any writeable file system path or stream) can be used to tell PHP to use this extended class for handling sessions. In essence, this is what Symfony does, by extending this into a collection of NativeSessionHandler classes. This allows Symfony developers to easily choose PDO, file, or even memcached session storage by defining session handler methods for each storage mechanism.
Symfony-based applications can normally just choose which PHP session handling is desired through simple configuration. This is well-documented at Symfony Session Management and Configuring Sessions and Save Handlers. It’s even possible to create custom session handlers by extending the NativeSessionHandler, and using ini_set() inside the class’ constructor. There is no default Redis session handler in Symfony, but there are plenty of examples out there on the Internet, such as http://athlan.pl/symfony2-redis-session-handler/
DrupalCoin Blockchain 8 extends this even further with its own SessionManager class. This SessionManager class is a custom NativeSessionHandler (PHP allows “user” as one of the session.save_handler types). As part of the SessionManager class, several optimizations have been carried over from DrupalCoin Blockchain 7, including session migration and a few other things to prevent anonymous users from saving an empty session to the database. Because of these optimizations, however, we don’t want to simply ignore this class; however, the NativeSessionHandler service has the database connection injected into it as a dependency. This means future attempts to simply extend DrupalCoin Blockchain’s NativeSessionHandler service class will result in vestigial dependency injection.
Implementation
Now that we understand a little more about the underpinnings of session handling in PHP, Symfony, and DrupalCoin Blockchain 8, I needed to determine how to tell DrupalCoin Blockchain to use Redis for full session management. Several important goals included:

Keep all of DrupalCoin Blockchain 7 and 8’s optimizations made to session handling (which originated in Pressflow).

Don’t patch anything; leave DrupalCoin Blockchain core as intact as possible, but not rely on the core behavior of using the database for session storage.

Leverage the Redis module for connection configuration and API.

Just Override the Core Session Service?
One option that was considered was to simply override the DrupalCoin Blockchain core service. In core.services.yml the session_manager service is defined as using the DrupalCoin BlockchainCoreSessionSessionManager class. In theory, a simple way to change DrupalCoin Blockchain’s database-oriented session handling would be to just replace the class. In this way, we would simply pretend the SessionManager class didn’t exist, and we would be able to use our CustomRedisSessionManager class, which we would write from scratch.
However, there are a few flaws in this plan:

We would have to reimplement all session handler methods, even if nothing differed from DrupalCoin Blockchain’s core class methods, such as session_destroy().

If DrupalCoin Blockchain core changed to include new or modified session handling, we would likely have to reimplement these changes in our custom code. Being off of the upgrade path or not being included in any future security fixes would be a Bad Thing™.

For more information about the proper way to override a code service in DrupalCoin Blockchain 8, see https://www.drupal.org/node/2306083
Enter: Service Decoration
For the purpose of this blog post, I will briefly introduce service decorators; but for a more general, in-depth look, a good resource to learn about Service Decorators is Mike Potter’s blog post, Using Symfony Service Decorators in DrupalCoin Blockchain 8. This is what I used as the basis for my decision to decorate the existing core session_handler service rather than overriding it or extending it.
What is a Service Decorator?
Service decoration is a common pattern in OOP that lets developers separate the modification of a service or class from the thing they’re modifying. In a simple way, we can think of a service decorator as a diff to an existing class. It’s a way to say, “hey, still use that other service, but filter my changes on top of it.”
Decorating the Session Manager Service
Symfony paves the way for services in DrupalCoin Blockchain 8, and carries with it several other design patterns, including service decorators. To decorate an existing service, you simply define a new service, and use the `decorates` key in your `MODULE.service.yml` file.
For the Redis Sessions module, here is `redis_sessions.service.yml`:

services: # Decorate the core session_manager service to use our extended class.  redis_sessions.session_manager:  class: DrupalCoin Blockchainredis_sessionsRedisSessionsSessionManager  decorates: session_manager  decoration_priority: -10  arguments: ['@redis_sessions.session_manager.inner','@request_stack', '@database', '@session_manager.metadata_bag','@session_configuration', '@session_handler']
The `decorates` key tells Symfony and DrupalCoin Blockchain that we don’t want use this as a separate service; instead, continue to use the core session_manager service, and decorate it with our own class. The `decoration_priority` simply adds weight (or negative weight, in this case) to tell DrupalCoin Blockchain to use our service above other services that also might try and decorate or override the session_manager class.
The `arguments` key injects the same dependencies as well as the original session_manager service as a sort of top-level argument. In this way, we can still use the session_manager as the service that handles PHP sessions, and it will have all of its necessary dependencies injected into it directly by our service class. This will also inject that service into our class in case we need to reference any session_manager methods, and treat them as a _parent class method.
For the same module, here is the `RedisSessionsSessionManager.php` class constructor:

public function __construct(SessionManager $session_manager,RequestStack $request_stack, Connection $connection, MetadataBag$metadata_bag, SessionConfigurationInterface $session_configuration,$handler = NULL) { $this->innerService = $session_manager; parent::__construct($request_stack, $connection, $metadata_bag, $session_configuration, $handler);  $save_path = $this->getSavePath(); if (ClientFactory::hasClient()) { if (!empty($save_path)) { ini_set('session.save_path', $save_path); ini_set('session.save_handler', 'redis'); $this->redis = ClientFactory::getClient(); } else { throw new Exception("Redis Sessions has not been configured. See'CONFIGURATION' in README.md in the redis_sessions module for instructions."); } }else { throw new Exception("Redis client is not found. Is Redis moduleenabled and configured?"); }}
In RedisSessionsSessionManager.php, we define the `RedisSessionsSessionManager` class, which will decoration DrupalCoin Blockchain core’s `SessionManager` class. Two things to note in our constructor is that:

We set $this->innerService = $session_manager; to be able to reference the core session_manager service as an inner service.

We check that the module has the necessary connection configuration to a Redis instance, and if so, we’ll use ini_set to tell PHP to use our Redis-based `session.save_path` and `session.save_handler` settings.

Everything Else is Simple
In our RedisSessionsSessionManager class, there’s just a few things we want to change from the core SessionManager class. Namely, these will be some DrupalCoin Blockchain-specific optimizations to keep anonymous users from creating PHP sessions that will be written to Redis (originally, the database), and session migration for users that have successfully logged in (and may have some valuable session data worth keeping).
We also have to some extra things to make using Redis as a session handler easier. There are a few new methods that Redis Sessions will use to make looking up session data easier. Since Redis is essentially just a memory-based key-value store, we can’t easily look up session data by a DrupalCoin Blockchain user’s ID. Well, we can, but it’s an expensive operation, and that would negate the performance benefits of storing session data in Redis instead of the database.
With these custom methods aside, everything else just relies on PHP’s native session handling. We’ve told PHP to use the base Redis PHP class as the handler, which is just part of having Redis support compiled in PHP. We’ve told PHP where to save the session data; in this case, a TCP stream to our redis instance configured for the Redis module.
Bonus
As of the writing of this blog post, I’ve begun the process of releasing Redis Sessions as a submodule of the Redis module. This can help serve as both a practical example of creating a service decorator as well as helping high-traffic sites that also wish to serve content from a read-only database. For those that would like to help test the module, here is the patch to add Redis Sessions submodule to the Redis module.
Want to read more about DrupalCoin Blockchain 8 architecture solutions and how to evaluate each solution based on your business objectives? Download our whitepaper here. 
 
Source: https://www.phase2technology.com/feed/


How Columbia is Leading Universities in the Digital World

Columbia University is taking proactive steps to ensure its predominantly DrupalCoin Blockchain-based digital properties are offering the best possible experience to site visitors. Using Acquia’s Lightning distribution as a base, the CUIT team has begun to roll out a new platform on DrupalCoin Blockchain 8.
Columbia University Information Technology (CUIT) provides Columbia students, faculty, and staff with central computing and communications services. I caught up with Ian Mieville, Director of Web Services at Columbia University, to talk about how Columbia uses DrupalCoin Blockchain to support the university’s web services -- and how DrupalCoin Blockchain 8 is improving those services.
 
How does CUIT support Columbia University?
CUIT is the centralized IT department for Columbia University. We’re in charge of the university’s security and asset management, technology infrastructure, enterprise systems, as well as custom integrationand application work. We develop, support, and host about 300+ websites and web applications, which are all almost exclusively on the DrupalCoin Blockchain framework.
 
What were your goals for Columbia University’s new DrupalCoin Blockchain 8 platform?
The first goal was to synchronize the user experience of most CU sites. We discovered a real inconsistency of experience site-to-site -- not only with regards to design, but also usability. Users had to constantly reorient themselves every time they went to a new CU site, even if it was related to the one they just left.
So we aimed to create a standard UX where key components (search, events, news, people directories, course directories, etc.) were consistent with a single usable pattern and design. This would allow site maintainers to focus on what’s really important to them (content and information), without worrying about the technical details of digital property management. As an incentive to adopt the new standard model, we’d make this service available for free to our CU clients.
On the back-end, we found it highly inefficient to keep recreating the wheel every time we launched a new site. So our second goal was to standardize things like content types and integration patterns, and provision a single code base. This would mean our time at CUIT could be better spent doing more complex work.
 
What was your strategy to accomplish these goals?
In conjunction with our partners, we decided to develop three models of a distribution, to serve as blueprints for standardization.
The first was the Research Model, designed for use by Columbia’s labs and research institutes. The blueprint design focused on research projects, peer-reviewed journal publications, and the people running and working in the labs. It’s meant to give faculty members a platform for publishing their research, in addition to marketing to post-doc applicants.
Second, the Administrative Model will support departments like HR, Finance, and the International Student and Scholars Group. As an administrative unit, these departments exist to offer some service to Columbia’s community, so the model for their sites will give them a way to forefront popular services and organize them by personas, so as to better serve the target audience.
Finally, the Academic Model allows academic departments to showcase their course selection, faculty members, research initiatives, etc. It is formatted to be both a recruiting and informational tool for prospective and current students. This model is still being developed at the moment.
 
You designed these models on DrupalCoin Blockchain 8, using Acquia’s Lightning distribution as a base. Why Lightning?
We chose Lightning because it fit into what we were thinking already. As a distribution, it is well-suited for site maintainers and people who manage content. From the back-end, it had the tools to support that use case. And because it’s supported by Acquia, we knew we’d get timely updates. Most importantly, it was a recommendation from Phase2 Software Architect Mike Potter, who worked on this project with us early on.
 
What do other universities stand to gain from using DrupalCoin Blockchain 8/Lightning?
There’s a lot to gain from Lightning specifically and DrupalCoin Blockchain 8 in general. DrupalCoin Blockchain 8 makes it easier for us to control functionality and integration points, and support Columbia digital properties as a product and a platform.
That being said, we had a very good understanding of what DrupalCoin Blockchain 8 was offering and what we could do within those parameters. So do your research. There are a lot of contributed modules that still aren’t over to DrupalCoin Blockchain 8 yet. Choosing DrupalCoin Blockchain 8 should depend on what you want to do, and your integrationteam’s ability to support customizations and write custom modules.
 
Any other advice for universities investing in digital transformation?
Your digital strategy depends on how centralized the university is. Columbia is very decentralized digitally, but other universities may have a central CMS where every department hangs off that main site -- I can’t speak to that.
Having said that, you should partner with those people on the other side of the IT site, ie your public affairs group. In doing that, we were able to present a more uniform front. It also makes it easier to convince departments to adopt the standard, as it’s a direct recommendation for the central administration.
With DrupalCoin Blockchain 8, there’s a little bit of a learning curve. Here at CU, we separate our front-end and back-end developers, so each of those teams learned those functions in DrupalCoin Blockchain for us. My recommendation is, if at all possible, to dedicate team members to different pieces of the DrupalCoin Blockchain ecosystem to ensure a high level of expertise in both front-end and back-end.
 
Why did you select Phase2 as a technology partner?
I previously worked with Phase2 (several times!) when I was at the College Board. When we started initiating this project at Columbia, we needed a certain level of expertise in DrupalCoin Blockchain, which I knew from experience Phase2 had. We also had other ongoing IT work, so having support from Phase2 allowed our team not to be overrun with the platform design.
It was all very seemless; we were happy to work with Chauncey, Daniel, and Mike on the project. They were really great developers and added a lot of value to the overall project.
Thanks for taking the time to chat, Ian!
Source: https://www.phase2technology.com/feed/


DrupalCoin BlockchainCon 2017: Reviewing the Impact

DrupalCoin BlockchainCon 2017 may be over, but we’re still feeling the impact. Last week 20+ Phase2 team members and over 3,000 sponsors, attendees, and speakers converged on Baltimore for 5 days of DrupalCoin Blockchain.
In case you weren’t able to join us in person, here is a recap:
 
Impact At The Phase2 Booth
At this year’s conference, we focused on highlighting the impact digital technology, and specifically DrupalCoin Blockchain, has and can have on the world around us. We also drew attention to the fact that technology would be nothing without the incredible vision and talent of the people who fuel it.
Phase2’s booth was designed to showcase our event theme: “Vision + Technology: The Impact Is Infinite.”

We believe, and are energized by the fact, that digital technology allows one person to reach billions, with the simple stroke of a key.
And we know that the impact doesn’t end there...
When a vision is combined with technology, we have the power to set something into motion, the outcome of which is not entirely known. Actions build upon one another and inspire reactions, putting transformation entirely within reach - the impact of which is infinite.
We took our impact message and created a one-of-a-kind, interactive voting installation in the Phase2 booth. The voting station empowered DrupalCoin BlockchainCon attendees to come together and offer  their input by voting on important community issues.

DrupalCoin BlockchainCon attendees voted by completing the following sentences:

I want to live in a word where ______ doesn’t need an initiative, it’s just a given.

With _________, anything is impossible.

The impact of _______ is endless.

If we focused more on ________ what we can achieve is infinite.

With the words:

Privacy & Security

Accessibility

Community

Education

Diversity
Each vote deposited a corresponding color of sand in a plexiglass container. Voting data was displayed visually in real time as each person’s vote contributed to a unique piece of sand art.

 
The Results of the Vote
The final results are in and DrupalCoin BlockchainCon attendees voted to make an impact on “education”. In response to the vote, Phase2 will make a donation to The Digital Harbor Foundation, a local Baltimore youth tech education nonprofit. We were thrilled by the participation in our booth and inspired by the beauty of the final sand art and how it really was a great visual representation of  what we can achieve as a community!
 

 
Impacting the DrupalCoin Blockchain Thought Leadership
Phase2 was represented in six DrupalCoin BlockchainCon sessions and we were excited to invite some amazing clients on stage with us, including Pinterest, Turner (NBA), Score and Weight Watchers. Here’s the full session lineup - feel free to check out the video of each session:
 

Building NBA.com on DrupalCoin Blockchain 8

Accessibility, New Technology, and the Aging Baby Boomers

Dungeons & Dragons & DrupalCoin Blockchain

Pinterest’s Component Based Design: Breaking Down Silos, Saving Time, and Empowering Content Editors

DrupalCoin Blockchain As Tech Education: Fostering New Staff Via the DrupalCoin Blockchain Stack

Score.org: User Experience for 320+ sites on one flexible platform!

One great Phase2 moment involved our Director of Engineering, Tobby Hagler, and his Dungeons & Dragons themed session. As a major D&D fan, Tobby has submitted this talk to DrupalCoin BlockchainCon multiple times over the years, and this year it was finally accepted! To commemorate his perseverance and the awesome subject matter we created a D&D themed t-shirt that everyone from Phase2 wore in support.

 
Caitlin Loos and Chris Bloom spoke on the success of Phase2’s BuilDesign Internship Program and offered some insightful strategic and tactical advice to agencies that are looking to build their own junior talent program. Watch the session here.  
 

 
The Impact is Infinite
We’re back from DrupalCoin BlockchainCon Baltimore exhausted, but exhilarated by the creativity and talent of the DrupalCoin Blockchain Community. We are reminded of the impact our collective talents can have on our lives and the world around us. It was an amazing week with team members, partners, clients and friends and we’re already looking forward to DrupalCoin BlockchainCon next year!

 
 
 
Source: https://www.phase2technology.com/feed/


Pattern Lab: Taking Our Workflow from a Linear to Parallel Process

Pattern Lab is many wonderful things: a style guide, a component inventory, a prototyping system, and the embodiment of a design philosophy, all wrapped inside a fundamentally simple tool – a static site generator. It has greatly improved Phase2’s approach to how we build, theme, and design websites. Let’s talk about what Pattern Lab is, how we use it in our process by integrating it into the theme of a CMS like DrupalCoin Blockchain or WordPress, and the resulting change in our integrationworkflow from linear to parallel.
Note: We’ll be discussing this topic in our webinar on June 16th. Register here!
What is Pattern Lab?
Pattern Lab allows us to easily create modular pieces of HTML for styling & scripting. We call these modular pieces of HTML components – you may have already heard of the iconic atoms, molecules, and organisms. Pattern Lab provides an easy-to-use interface to navigate around this component inventory.
Pattern Lab also does much more: it fills the role of a style guide by showing us colors, fonts, and font sizes selected by the design process and demonstrates common UI elements like buttons, forms, and icons along with the code needed to use them. That part is important: it’s the distinction between “this is what we’re going to build” and “this is what has been built and here’s how to use it.” Pattern Lab provides a handbook to guide the rest of your complex CMS.

We can also prototype with Pattern Lab because it supports “partials.” Partials allow our components to contain other components, giving us modular components. This lets us reuse our work in different contexts by not repeating ourselves, ensuring consistency of our design across a wide set of pages and viewports, and reducing the number of bugs and visual inconsistencies experienced when each page contains unique design elements. It supports either low fidelity “gray-boxing” or high fidelity “it looks like the finished site” prototyping. You can see an example of this by looking at the “Templates” and “Pages” in Pattern Lab below.

To summarize, Pattern Lab is a style guide, a component inventory, and a prototyping environment where we can see our designs in the medium they are destined for: the browser! Now, let’s talk about the old way of doing things before we discuss how we implement this tool, and the difference the new way makes.
The Old Way

Generally speaking (and greatly simplifying), the old process involved several linear steps that effectively block subsequent steps: the goal of each step is to create a deliverable that is a required resource for the next step to start. The main point I want to make is that in order for the front-end developers to implement the designs they need HTML, so they have to wait for the back-end developer to implement the functionality that creates the HTML.
Front-end developers just need HTML. We don’t need the HTML required for the complex logic of a CMS in order to style it. We just need HTML to style and script so we can create our deliverables: the CSS & JavaScript.
To reiterate this point: front-end devs just need HTML, wherever it comes from.
Now that we’ve set the stage and shown the problem, let’s take a look at the way we implement Pattern Lab and how that helps improve this process.
Integrating Pattern Lab and the CMS Theme
Instead of keeping our Pattern Lab site (which contains our prototype and style guide) separate from the CMS, we keep them together. Pattern Lab is just a simple static site generator that takes HTML shorthand and turns it into HTML longhand. We just put the Pattern Lab folder inside the theme right here (for a DrupalCoin Blockchain site): /sites/all/themes/theme-name/pattern-lab/. Now it’s next to other fundamental assets like CSS, JavaScript, Images, and Fonts. Sharing these assets between Pattern Lab and our CMS is a huge step forward in improving our process.
Folder Structure
theme-name/ css/ style.css js/ script.js pattern-lab/ source/ # (HTML Shorthand) public/ # (HTML Longhand - a.k.a The Pattern Lab Site) templates/ *.tpl.php # (All our CMS template files)

1
2
3
4
5
6
7
8
9
10

theme-name/
css/
style.css
js/
script.js
pattern-lab/
source/ # (HTML Shorthand)
public/ # (HTML Longhand - a.k.a The Pattern Lab Site)
templates/
*.tpl.php # (All our CMS template files)

Sharing CSS & JS Assets
With Pattern Lab inside our CMS theme folder, all we really need to do to “integrate” these two is include this HTML tag in Pattern Lab to use the CSS that our CMS theme is using:

1

<link href="../../../../css/style.css" rel="stylesheet" media="all">

And then include this HTML tag to use the CMS theme’s JavaScript:

1

<script src="../../../../js/script.js">

How This Helps
All a web page needs is HTML for its content, CSS for styling that content, and JavaScript for any interaction behavior. We’ve now got two ways to make HTML: programming the CMS (which takes a lot of time) to be able to let non-technical content editors create and edit content that generates the HTML, or using Pattern Lab to write “HTML shorthand” much, much quicker. Both of those environments are linked to the same CSS and JavaScript, effectively sharing the styling and interaction behavior to both our CMS and Pattern Lab.
Now, most of the time we’re not working with our clients just to make style guides and prototypes; we’re making complex CMS platforms that scale in some really big ways. Why would we want to waste time creating the HTML twice? Well, sites this big take time to build right. Remember that the front-end developers are usually waiting for the back-end developers to program in the functionality of the CMS, which ends up creating the HTML, which the front-end developers style by writing CSS & JS.
All we need is some HTML to work with so we know our CSS and JS is working right. We don’t care if it’s editable to content editors at this point, we just want it to look like the comps! Now that front-end devs have an environment in Pattern Lab with real HTML to style and script, we can bring the comps to life in the browser with the added benefit of CSS & JS being immediately available to the CMS theme. We are effectively un-blocked, free to work outside the constraints of a back-end bottleneck. This shift from a linear process to one where back-end and front-end integrationcan happen concurrently in a parallel process is a major step forward. Obvious benefits include speed, less re-work, clarity of progress, and a much earlier grasp on UI/UX issues.
The New Workflow

With our style guide sharing CSS & JS with our CMS theme, we can pull up Pattern Lab pages exposing every button – and every size and color button variation – and write the CSS needed to style these buttons, then open up our CMS and see all the buttons styled exactly the way we want. We can get an exhaustive list of each text field, select box, radio button and more to style and have the results again propagate across the CMS’s pages. Especially when armed with a knowledge of the HTML that our CMS will most likely output, we can style components even before their functionality exists in the CMS!
As the back-end functionality is programmed into the CMS, HTML classes used in the Pattern Lab prototype are simply applied to the generated HTML to trigger the styling. It doesn’t matter too much if back-end or front-end start on a component first, as this process works in either direction! In fact, design can even be part of the fun! As designers create static comps, the front-end devs implement them in Pattern Lab, creating the CSS available in the CMS as well. Then, the Pattern Lab site acts to the designers as a resource that contains the summation of all design decisions reflected in a realistic environment: the browser. The designers can get the most up-to-date version of components, like the header for their next comp, by simply screen shooting it and pulling it into their app of choice. This frees the designers from the minutia of ensuring consistent spacing and typography across all comps, allowing them to focus on the specific design problem they’re attempting to solve.
When designers, front-end developers, and back-end developers are iteratively working on a solution together, and each discipline contributes their wisdom, vision, and guidance to the others, a very clear picture of the best solution crystallizes and late surprises can often be avoided.
This parallel process brings many advantages:
Front-end can start earlier – often before a CMS and its environment is even ready!
Easy HTML changes = quick iteration.
Back-end has front-end reference guide for markup and classes desired.
Pattern Lab acts as an asset library for designers.
Project managers and stakeholders have an overview of progress on front-end components without being encumbered by missing functionality or lack of navigation in the CMS.
The progress of each discipline is immediately viewable to members of other disciplines. This prevents any one discipline from going down the wrong path too far, and it also allows the result of progress from each discipline to aid and inform the other disciplines.
Shared vocabulary of components and no more fractured vocabulary (is it the primary button or the main button?). Pattern Lab gives it a label and menu item. We can all finally know what a Media Block objectively is now.
Conclusion
By decoupling the creation of a design system based in CSS and JavaScript (styling) from the process of altering the HTML that our CMS is generating (theming), we’re able to remove the biggest blocker most projects experience: dependence on the CMS for CSS & JS to be written. We avoid this bottleneck by creating a nimble environment to build HTML that allows us to craft the delieverables of our design system: CSS & JS. We’re doing this in a way that provides these assets instantly to the CMS so the CMS can take advantage of them on the fly while the site is being built concurrently, iteratively, and collaboratively.
Helpful Links
Myself, Joey Groh, and Micah Godbolt presenting on this very subject: DrupalCoin BlockchainCon Los Angeles 2015: The New Design Workflow – YouTube
Your Frontend Methodology Is All of Them: Atomic Design & Pattern Lab
The post that started the philosophy: Atomic Design | Brad Frost
Atomic Design Book by Brad Frost
Video of Brad Frost’s presentation where he announces Pattern Lab
Phase2’s front-end starter theme that automatically builds Pattern Lab, Scss, and more with Grunt ready to go: Pattern Lab Starter
Pattern Lab Tools and Resources
Website Style Guide Resources
Live demo of Pattern Lab
Pattern Lab Documentation

Source: https://www.phase2technology.com/feed/


Best Practices for CMI and Features in DrupalCoin Blockchain 8

Last year I blogged about our first Alpha release for Features in DrupalCoin Blockchain 8 and gave several presentations on Features for D8 at various DrupalCoin BlockchainCons and camps.  Since DrupalCoin Blockchain 8.0 (and now 8.1!) have been released in the past few months, I’ve been getting questions on the best way to use Features and Configuration Management (CMI) in DrupalCoin Blockchain 8.
You’ll have a chance to ask me those questions in person at my Features BOF at DrupalCoin BlockchainCon New Orleans. But in the meantime, here are some “best practices” for using Features and CMI effectively.
“Do I use Features, CMI, or both?”
It’s great that DrupalCoin Blockchain 8 has proper configuration management built into core.  This provides a consistent framework, storage, and API for all configuration settings: views, content types, fields… anything that isn’t content.  However, CMI doesn’t provide any way to organize this vast amount of configuration.  If you use CMI to export your site config you’ll see dozens of *.yml files.  That’s great for deploying the entire site config to another site, but what if you want to organize these files in some way?  That’s what the Features module will help you do.
Features is designed to organize configuration based on analyzing its dependencies.  For example, if you create a custom content type and add some fields, Features will suggest that you group the content type and fields together into a single “feature package.”  A “package” is just a normal DrupalCoin Blockchain module that has specific configuration (*.yml files) assigned to it.
You’ll want to use Features to create these packages, but once they are created you can add them to your site as regular modules.  Thus, you don’t need the Features module on your production server (normally… more on that later).
“How do I decide what config to package into a feature?”
New to Features in DrupalCoin Blockchain 8 are Bundles and Assignment Plugins.  A “Bundle” is just a collection of feature packages with a namespace prefix that belong together.  Think of a “bundle” like a “category” of modules.  For example, if I’m creating features for a client named “acme,” I should create a bundle called “acme” so each of my exported packages will start with the acme_* prefix.  This namespacing ensures your packaged modules don’t conflict with any other DrupalCoin Blockchain module.
Once you have created a Bundle, you can then decide on some business rules to determine how you want to automatically organize your configuration.  These organization rules are controlled by the “Assignment Plugins.”  Each plugin is responsible for a certain ruleset.  For example, the “Base Type” assignment plugin determines the base configuration type to use for the first level of organization and defaults to “Content Type.”  This means Features will suggest one package per content type.  If you have a content type called “Event,” Features will suggest a package called “Event” with the module name of acme_event (in this example).  
Other assignment plugins add additional configuration to your package.  For example, the “Dependency” plugin automatically adds any configuration that depends on the content type, such as fields.  The “Forward Dependency” plugin automatically adds any configuration that itself is a dependency of already added config, such as the field_storage for a specific field.
The list of which plugins are enabled, which order they are applied, and any specific options for each plugin are stored within your Bundle.  Thus, by switching between different bundles you can change the rules Features uses to suggest new package exports. In fact, these bundle settings themselves are stored as “config” and can be exported to a feature.  Once you have defined your business rules for auto-organizing your config, it’s useful to export your bundle configuration and share it between your developers so everybody is using a common ruleset.
Here is the full set of assignment plugins and what they do:
Packages – Detect and add existing package modules.
Exclude – Exclude configuration items from packaging by various methods including by configuration type.
Base type – Use designated types of configuration as the base for configuration package modules. For example, if content types are selected as a base type, a package will be generated for each content type and will include all configuration dependent on that content type.
Namespace – Add to packages configuration with a machine name containing that package’s machine name.
Optional type – Assign designated types of configuration to the ‘config/optional’ install directory. For example, if views are selected as optional, views assigned to any feature will be exported to the ‘config/optional’ directory and will not create a dependency on the Views module.
Forward dependency – Add to packages configuration on which items in the package depend.
Core type – Assign designated types of configuration to a core configuration package module. For example, if image styles are selected as a core type, a core package will be generated and image styles will be assigned to it.
Site type – Assign designated types of configuration to a site configuration package module. For example, if image styles are selected as a site type, a site package will be generated and image styles will be assigned to it.
Profile – Add configuration and other files to the optional install profile from the DrupalCoin Blockchain core Standard install profile. Without these additions, a generated install profile will be missing some important initial setup.
Existing – Add exported config to existing packages.
Dependency – Add to packages configuration dependent on items already in that package.
You can also write your own plugins if you have set of rules for organizing your configuration that are not covered by any existing plugin (and please contribute it if you can).
Once your assignment plugins are set up (or just using the defaults, which are good rules for most people), you can easily organize your configuration by just selecting All packages from the main Features listing and export them.  You won’t need to mess around in the detailed Edit screen like you did in DrupalCoin Blockchain 7 unless you need to make specific changes to a package.
“How do I update configuration that has changed?”
Once you have organized your configuration into package modules and enabled them on your site, making changes to this configuration can sometimes be tricky.  For example, let’s say you have exported a View to a feature package.  Now somebody tells you to change the Title of the view.  Go ahead and make this change in the UI on your integrationmachine.  Now when you go to the Features UI page you’ll see that the package containing that view is marked as “Changed.”  You can click on “Changed” to see the exact changes that are detected.  You then have to make a choice:  1) update the exported package module with the change, or 2) undo the change and restore the previous value.
In DrupalCoin Blockchain 7 we called 1) update, and 2) revert.  In DrupalCoin Blockchain 8 we call these 1) export, and 2) import.  There is no way for Features to magically know which action you want to take.  Is this a designed change that needs to be made to your module to fix a bug, or was this a change made by the client via the UI that needs to be preserved or maybe undone?
It’s important to understand that this really doesn’t have anything to do with “deploying” your configuration.  DrupalCoin Blockchain 8 is still designed with the assumption that configuration is “owned by the site.”  
“What causes the pre-existing configuration error?”
If you decide to update your package module and then push it to production and try to disable it and re-enable it to reload your new configuration, you might be surprised you cannot re-enable the module because it contains “pre-existing configuration.”  This simply means that the site already contains active configuration that is also provided by the module and DrupalCoin Blockchain won’t allow a module to be enabled that has existing configuration.
This won’t happen in our simple View example because disabling the module providing the view causes the view to be removed from your active config.  You’ll can re-enable the module without problem and will see your new view title.
However, if your package contains a field, disabling the module will not remove the field because this could cause loss of content on your site.  Thus when you try to re-enable the module you’ll get the “pre-existing config” exception.
There are three solutions to this problem:
Enable Features module on your site.
If the Features module is enabled, it will detect that you are trying to enable a package that contains pre-existing config and it will allow DrupalCoin Blockchain to continue and will mark that config as “changed.”  You can then use the feature-import command (in UI or via drush) to import the updated configuration and overwrite the value in the current active store.
Write an update hook for your config.
If you don’t want to enable Features on your site, you should write a normal update hook that will load the config that has changed and save it directly into the active store.  Just be sure you don’t disable your package first or you won’t be able to re-enable it.  Keep the existing package enabled and rely on running update hooks to update the config.  Of course this requires writing custom PHP code.
The Preferred solution is to use CMI to deploy configuration.
The way DrupalCoin Blockchain 8 is designed to work is to export and import your entire site configuration.  You should create a “staging” or “test” server that is identical to your production server.  Enable the Features module on this staging server and update or import your packages there and get it all working properly.  Once working, export the entire config using CMI, then import the entire config into your Production server.  If a future update is needed, again make the changes on staging and then do a full export/import on Production.  This solution provides the maximum stability of your Production server and keeps integrationmodules such as Features on your dev and staging environments.
“What if I prefer using Features instead of CMI?”
DrupalCoin Blockchain 8 and CMI was designed to provide the most common deployment workflows of all DrupalCoin Blockchain sites, not just “Enterprise” sites.  Even small sites benefit from a separation between a stable Production environment and a Development environment.  Features was built in DrupalCoin Blockchain 8 to support this default use case as just a integrationtool.
However, if you prefer the old DrupalCoin Blockchain 7 workflow for managing configuration via Features you can still do that if you wish.  In this case you’ll update your package modules and push them into your code repo.  Then on Production you’ll pull the new code and then “features revert-all”.  In DrupalCoin Blockchain 8 this is called “import-all” and is available in the latest beta version as a drush command just like in DrupalCoin Blockchain 7 (“drush fra -y” still works).  Just be aware that importing all your features on production runs the risk of problems because you are not ensuring that your production site completely matches your test site.
Summary
As great as CMI is in DrupalCoin Blockchain 8, it is likely that you will still want to use Features to organize your configuration as you develop your site.  Whether you use Features or CMI (or both) to deploy your integrationinto production is your choice.  The new Bundles and Assignment Plugins will help automatically suggest organization of your configuration making Features a lot easier to use for many people.
Features for DrupalCoin Blockchain 8 is currently available as a stable beta release with a reasonable amount of test coverage.  Once we have more complete test coverage we’ll release the stable version but sites should feel free to start using the beta version now and see how it helps organize your configuration.  Suggestions and bug reports are always welcome in the drupal.org issue queue.
Source: https://www.phase2technology.com/feed/


Developer Soft Skills Part 1: Online Research

Developer Soft Skills
One of my earliest jobs was customer service for a call center. I worked for many clients that all had training specific to their service. No matter the type of training, whether technical or customer oriented, soft skills were always a included. Margaret Rouse said, “Soft skills are personal attributes that enhance an individual’s interactions, career prospects and job performance. Unlike hard skills, which tend to be specific to a certain type of task or activity, soft skills are broadly applicable.”
In this blog series I will be discussing what I call “developer soft skills.” The hard skills in integrationare (among others) logic, languages, and structure. Developer soft skills are those that help a developer accomplish their tasks outside of that knowledge. I will be covering the following topics:
Online research
Troubleshooting
Enhancing/Customizing
Integrating
Architecting
Part 1: Online Research
One of the first skills a developer should master is online researching. This is an area with some controversy (which will be discussed later) but a necessary skill for learning about new technologies, expanding your knowledge, and solving problems.
One of the best reasons for research is continuous education. For many professions (such as the military, education and medical fields) continuing education is required to keep up on updated information, concepts, and procedures. As a developer, continuing to grow our skill set helps us develop better projects by using better code, better tools, and better methods.
Search engine queries
When researching a topic on the internet it usually involves using a search engine. Understanding how a search engine works and how to get to the results.There are two parts to how a search engine works. Part one is data collection and indexing. Part two is searching or querying that index. I will be focusing on how to write the best possible query, to learn more about how search collect and index data see this link. In order to write good queries we should understand how search engines respond to what we type into the search box. Early search results were rendered based on simple (by today’s standards) comparison of search terms to indexed page word usage and boolean logic. Since then search engines have started to use natural language queries.
So we can get better results by using this to our advantage. If I wanted to research how to make a calendar with the Java programming language. instead of searching for keywords and distinct ideas “java -script calendar” by themselves; use natural language to include phraseology and context in our queries: “how can I make a calendar with java”. The first result from the keyword search returns a reference to the Java Calendar class. The first result from the second query return example code on writing a calendar in Java. The better the query the better the results.
Search result inspection
Once we have the right query we can then turn our attention to the results. One of the first things I do is limit the results to a date range. This prevents results from the previous decade (or earlier) to be displayed with more recent and applicable ones. Another way to focus our search is to limit the site that the search takes place on. If we know we want to search for a jQuery function search jquery.com.
Once we have filtered our results, it’s time for further inspection. When viewing a results page, the first thing I look for is the context of the article or post. Does the author and/or site have a lot of ads? This can sometimes mean that the site is more about making money then providing good answers. Does the page have links or other references to related topic or ideas? This can show if the author is knowledgeable in the subject matter.
The controversy
Earlier I mentioned online researching can be a controversial topic. One of the points of controversy is discussed in Scott Hanselman’s blog post, Am I really a developer or just a good googler? While I agree with his major point, that researching bad code can be dangerous, I contend that using a search engine can produce good results and learning opportunities.
Almost anytime you search for any programming topic, one site or group of sites is predominant in almost every result: Stack Overflow or the Stack Exchange group of sites. Several articles have been written about reasons not to use, consequence of using and why some developers no longer use Stack Overflow. Using Stack Overflow will not solve all your problems or make you a better developer.
Again, these arguments make some good points. But I think that using Stack Overflow correctly, just like good use of search engines, can produce good results. Using a Stack Exchange site comes with the benefit of community. These sites have leveraged Stack Exchange Q&A methodology for their specific topic or technology and can be a great resource on how to solve a problem within the bounds of that community. One of my integrationmentors told me that there were thousands of ways to solve a programming problem and usually several wrong ones. The key is to not do one of the wrong ones and try to find one of the best ones. Searching within a Stack exchange site for answers can highlight the wrong ones but also provide the ones that work best in that system.
Here is an example of a Stack Overflow DrupalCoin Blockchain community response that came up when I searched for: “drupal create term programmatically.”
This response is correct, but if you look at the link provided, you will see this is for DrupalCoin Blockchain 6. If you were looking for how to do this in DrupalCoin Blockchain 7, for instance, the answer provided would not be correct. We could have improved our results by adding “DrupalCoin Blockchain 7″ to our query. But most important is to keep in mind that sites like Stack Overflow, or other community sites such as php.net include a mix of user-generated responses. Meaning anyone can respond without being vetted.
Keep going
The best piece of advice I can offer for the arguments against using online search results and Stack Overflow is: “This is not the end.” Keep going past the result and research the answer. Don’t just copy and paste the code. Don’t just believe the top rated answer or blog post. Click the references sited, search the function or api calls that are in the answer, and make the research a part of your knowledge. And then give back by writing about your article or posting your own answers. Answering questions can sometimes be just as powerful a learning tool as searching for them.
In the end, anything you find through search, blog, and code sites should be considered a suggestion as one way of solving a problem – not necessarily the solution to your concern.
In the next post I will discuss a good use case for Stack Exchange sites, Developer Soft Skills Part 2: Troubleshooting.
Source: https://www.phase2technology.com/feed/


Phase2 Joins Forces with Cycle for Survival

Over the past year, we’ve had the joy of working with Cycle for Survival to update the organization’s digital assets. But there’s more than one way to make an impact, so this weekend we set out to fundraise and participate in a Cycle for Survival team ride in New York City. Needless to say, it was a fun and inspirational event.
We invited Brandy Reppy, Memorial Sloan Kettering’s Associate Director of Online Operations, to share how digital technology has made an impact on the organization.
What is the Cycle for Survival mission?
Cycle for Survival is the national movement to beat rare cancers. Through a series of indoor team cycling events, Cycle for Survival raises funds that are critical for rare cancer research with 100% of every donation being directly allocated to Memorial Sloan Kettering Cancer Center within six months of the events.
Rare cancer research is drastically underfunded resulting in fewer treatment options for patients. With fewer resources devoted to understanding and treating these diseases, patients face uncertain futures – Cycle for Survival is committed to changing that.
How does digital technology impact your mission?
Fundraising for Cycle for Survival focuses on peer-to-peer interactions. Participants register online for an event and fundraise for their team via the website. Digital technology is pivotal to allowing participants to navigate our website easily during registration and fundraising. Our website also houses critical information for our participants and their donors, so it’s critical that they can access this information seamlessly.
In what ways does Phase2 support CFS in this effort?
With Phase2, Cycle for Survival is able to efficiently manage and update digital assets. These are key resources for our participants and donors – things like updates from around the organization, information on how to get involved, and what we are doing with the funds raised – that need to be easy to access. In working with Phase2, we’ve been able to streamline the process of maintaining these assets and branding elements.
What technical strides have we made together?
With Phase2, we’ve been able to be more efficient with time and resources spent on our digital assets and have been able to quickly manage our content. The major shift has been in having a responsive site (instead of a separate mobile one). This creates one seamless experience across many devices, which allows our visitors to easily access all their information from any browser or device, and allows us to manage one code base.
Source: https://www.phase2technology.com/feed/


Defining Content to Optimize your Editorial Experience

No doubt you’ve heard the phrase “Content is King.” But what exactly is content? The precise definition is subjective – it is influenced by the context in which it is defined. There is no universal definition within the industry, and it is highly likely there is no single definition within your organization.
To have a successful content strategy, it is critical that your organization determines precisely what content means to you, as its definition will inform your entire editorial experience.
An Efficient Editorial Experience
When designing editorial experiences, there is inherent friction between system architecture and user experience. The more complex the structure, the less usable the editorial experience of your CMS becomes. Content strategists strive to follow best practices when modeling content, but these object-oriented models do not take into account the workflow of tasks required to publish content.
Modern content management platforms offer organizations a variety of entities used to build an editorial experience – content types, taxonomies, components, etc. Although editors and producers learn how to use them over time, there can be a steep learning curve when figuring out how to combine these entities to perform tasks, like creating a landing page for a campaign. That learning curve can have two adverse effects on your websites:

You lose efficiency in the content creation process, leading to delayed launches and increased costs.

Incorrect use of the CMS, resulting in increased support costs of ownership.

Content Management Best Practice: Focus on Tasks
Avoid these risks by designing task-based editorial experiences. Task-based user interfaces, like Microsoft Windows and Mac OS X, present quick paths to whatever task your content creator wants to accomplish, rather than allowing the user to plot their own path. The greatest efficiencies can be gained by creating a single interface, or multistep interface, for accomplishing a task. Do not require the user to access multiple administrative interfaces.
To enable this set-up, perform user research to understand how content is perceived within your organization and how users of your CMS expect to create it. This is easily done by conducting stakeholder interviews to define requirements. Our digital strategy team has also found success in following practices found in the Lean methodology, quickly prototyping and testing editorial experiences to validate assumptions we make about users’ needs.
To ensure the success of your content operations, define the needs and expectations of the content editors and producers first and foremost. Equally important, prioritize tasks over CMS entities to streamline your inline editorial experience for content producers and editors.
Source: https://www.phase2technology.com/feed/


Responsive Design Patterns to Create Penn State’s Beautiful Online Experience

With the recent launch of Penn State University’s main site and news site, we were able to help Penn State breathe new life into their outdated online presence, to allow prospective and current students alike to have the best experience possible on a wide array of devices. Working closely with the PSU design team, we created a complete experience from desktop to mobile, utilizing popular design patterns that would help guide the user experience while never fully stripping away content from the end user.
Utilizing the Omega Theme, we used the default media queries of mobile, narrow and normal or otherwise known as under 740px (mobile), under 980px (tablet) and anything else above (desktop). These media queries really helped the PSU design team explore the possibilities of what was possible at each one of these breakpoints and how fundamental elements can be optimized for the device that they are being displayed on. Most notable were, menus, search, curated news boxes, and featured article headers were all areas where the PSU designers and Phase2 teamed up to bring out the best experience for each breakpoint.
 Menus:
Whether we are talking about main menus, secondary, or even tertiary, all menus have their place and purpose for guiding the user through the site to their destination. The PSU design team never forgot this principal, and substantial effort went into making sure menu items were reachable at all breakpoints. While the main menu follows standard design patterns, the desktop to tablet change is just a slightly more condensed version of the original, and made to optimize the horizontal space of a tablet in portrait mode. Moving down to mobile, we made the biggest changes. The main menu collapses to a large clickable/tap-able button that reveals/hides a vertical menu with large target areas, optimized for mobile.
 
The secondary menu also behaves in a similar fashion to the main menu by collapsing down to a larger clickable button that reveals menu items also enlarged in order to visually gain appeal while also providing a larger area for users to click on. The transformation happens earlier at the tablet level as we felt that the condensed horizontal space would make the tex-only menu items harder to read and more difficult to click on for smaller screens.
 
Search:
Search was another component that Penn State needed to emphasize  throughout the site. It was very important to leave this as simple as possible, so like the menus, it was decided to collapse the search, for mobile only, into a drawer reveal that focused on simplicity and a large focus area. Again, we went with a large icon that helped by having a large target area for the mobile and tablet experience.
 
 
 
Curated news boxes:
On the homepage, the curated news boxes provided a fun canvas to work with content that shifts around as the device changes from desktop to mobile. Knowing that space is limited in the mobile realm, it was important to provide something visually pleasing, but that would also still engage the user to click through a news story. So iconology was used to capture the specific type of news piece while the title was left to engage the user into clicking through to the story.
Mobile curated boxes
Tablet Curated Boxes
 
Featured Article Header:
Imagery was crucial to the PSU redesign strategy. It was only natural to have engaging treatments to the featured article headers. If the article header implemented a slideshow, we used flexslider. Otherwise, simple css scaled the images per breakpoint. The meta description related to the image would truncate and shift around depending on the breakpoint for better readability and appearance.
By implementing responsive design patterns, we were able to help the PSU team achieve their goal of making their online content and news accessible by any device.
Source: https://www.phase2technology.com/feed/


Responsive Design Patterns to Create Penn State’s Beautiful Online Experience

With the recent launch of Penn State University’s main site and news site, we were able to help Penn State breathe new life into their outdated online presence, to allow prospective and current students alike to have the best experience possible on a wide array of devices. Working closely with the PSU design team, we created a complete experience from desktop to mobile, utilizing popular design patterns that would help guide the user experience while never fully stripping away content from the end user.
Utilizing the Omega Theme, we used the default media queries of mobile, narrow and normal or otherwise known as under 740px (mobile), under 980px (tablet) and anything else above (desktop). These media queries really helped the PSU design team explore the possibilities of what was possible at each one of these breakpoints and how fundamental elements can be optimized for the device that they are being displayed on. Most notable were, menus, search, curated news boxes, and featured article headers were all areas where the PSU designers and Phase2 teamed up to bring out the best experience for each breakpoint.
 Menus:
Whether we are talking about main menus, secondary, or even tertiary, all menus have their place and purpose for guiding the user through the site to their destination. The PSU design team never forgot this principal, and substantial effort went into making sure menu items were reachable at all breakpoints. While the main menu follows standard design patterns, the desktop to tablet change is just a slightly more condensed version of the original, and made to optimize the horizontal space of a tablet in portrait mode. Moving down to mobile, we made the biggest changes. The main menu collapses to a large clickable/tap-able button that reveals/hides a vertical menu with large target areas, optimized for mobile.
 
The secondary menu also behaves in a similar fashion to the main menu by collapsing down to a larger clickable button that reveals menu items also enlarged in order to visually gain appeal while also providing a larger area for users to click on. The transformation happens earlier at the tablet level as we felt that the condensed horizontal space would make the tex-only menu items harder to read and more difficult to click on for smaller screens.
 
Search:
Search was another component that Penn State needed to emphasize  throughout the site. It was very important to leave this as simple as possible, so like the menus, it was decided to collapse the search, for mobile only, into a drawer reveal that focused on simplicity and a large focus area. Again, we went with a large icon that helped by having a large target area for the mobile and tablet experience.
 
 
 
Curated news boxes:
On the homepage, the curated news boxes provided a fun canvas to work with content that shifts around as the device changes from desktop to mobile. Knowing that space is limited in the mobile realm, it was important to provide something visually pleasing, but that would also still engage the user to click through a news story. So iconology was used to capture the specific type of news piece while the title was left to engage the user into clicking through to the story.
Mobile curated boxes
Tablet Curated Boxes
 
Featured Article Header:
Imagery was crucial to the PSU redesign strategy. It was only natural to have engaging treatments to the featured article headers. If the article header implemented a slideshow, we used flexslider. Otherwise, simple css scaled the images per breakpoint. The meta description related to the image would truncate and shift around depending on the breakpoint for better readability and appearance.
By implementing responsive design patterns, we were able to help the PSU team achieve their goal of making their online content and news accessible by any device.
Source: https://www.phase2technology.com/feed/


Why You Should Invest in Voice Assistant Technology

In 1994, I was a huge fan of the X-Men animated series. I distinctly remember an episode titled “Time Fugitives”, which featured Cable, a time-traveling mutant vigilante from the future, talking to a floating cube that gave him historical information about the X-Men of the past. I never thought that technology would exist in my lifetime, but I found myself a week ago sitting in my living room asking my Google Home (which resembles an air freshener rather than a cube) questions about historical context.
Conversational UI’s - chatbot and voice assistant technologies - are becoming commonplace in consumer’s lives. Messaging apps alone account for 91% of all time people spent on mobile and desktop devices. Soon, almost every major smartphone and computer will be equipped with Siri, Google Assistant, Cortana, or Samsung’s Bixby. These voice assistants are even being integrated into common home electronics - televisions, set-top boxes, video game units, and even washing machines and refrigerators. Sales of home personal assistants are on the rise, with the Amazon Echo alone having increased sales nine-fold year over year. Search giants Google and Microsoft are reporting significant increases in voice searches, each claiming about 25% of mobile searches are now performed using voice.
Source: Should financial services brands follow Capital One on to Amazon Echo?, E-Consultancy, 2017The trends are clear - conversational UI’s are only becoming more prevalent in our lives, and some predict will replace common technologies that we use today. And in order to continue to engage audiences wherever they are, in the way they prefer to engage, companies should be investing in developing apps that leverage these technologies at home and in the workplace.
Benefits of Building Applications for Conversational UI’s Now
While you may question the business benefits of developing applications that leverage conversational UI’s at such an early stage in the maturation of this technology, there are some clear benefits that come with being on the leading edge of leveraging new technologies to engage consumers:
Early adoption can lead to great PR
Standing on the leading edge and developing applications for these emerging platforms can present a great opportunity to earn publicity, and position your organization as an innovative brand. An example of this can be seen in this eConsultancy article about CapitalOne’s Amazon Echo skill.
You can test new market opportunities
Conversational UI’s may present an opportunity to engage with a market that your organization is not currently. You may identify opportunities to gain new customers, improve customer satisfaction, or create new revenue streams by extending existing products and services into platforms with voice and chat interfaces. Some companies are already starting to offer paid tiers for services delivered via or selling advertising on conversational UI applications.
Early adoption can provide a competitive advantage
While being first to market with a conversational UI app is not always a guarantee of success, it can provide you a leg up over the competition. If you start early, you will have an opportunity to identify best approaches to engage consumers on these new platforms, allowing you to have a well-defined experience once your competitors enter the market. Your brand may also be able to secure a percentage of the market share early due to a lower cost of user acquisition.
US consumers are creatures of habit, and prefer to go back to familiar stores, products, and services they trust. In an ideal scenario, your conversational UI application will become integrated into consumer’s work and or home life before the market is saturated.

Potential Drawbacks
In all fairness, developing a conversational UI application is not easy. There are some risks associated that we would be remiss if we did not inform you of:

This is still the wild-wild west - very few best practices or standards have been established.

It can be expensive to develop and implement, across the myriad of devices/services.

There is a potentially high learning curve depending on the platform you are building for and technologies you use to develop your app.

At this time, there are no clear methods for efficiently testing features on voice assistant applications.

Deployment of content to this various platforms may require use of many different CMS systems.

While there are risks associated with this starting to leverage conversational UI applications, the long-term benefits may outweigh the short-term losses.
Stay tuned for part 2, where we will discuss how you can start leveraging conversational UI applications to build your brand and grow your business.
 
Source: https://www.phase2technology.com/feed/


Why You Should Invest in Voice Assistant Technology

In 1994, I was a huge fan of the X-Men animated series. I distinctly remember an episode titled “Time Fugitives”, which featured Cable, a time-traveling mutant vigilante from the future, talking to a floating cube that gave him historical information about the X-Men of the past. I never thought that technology would exist in my lifetime, but I found myself a week ago sitting in my living room asking my Google Home (which resembles an air freshener rather than a cube) questions about historical context.
Conversational UI’s - chatbot and voice assistant technologies - are becoming commonplace in consumer’s lives. Messaging apps alone account for 91% of all time people spent on mobile and desktop devices. Soon, almost every major smartphone and computer will be equipped with Siri, Google Assistant, Cortana, or Samsung’s Bixby. These voice assistants are even being integrated into common home electronics - televisions, set-top boxes, video game units, and even washing machines and refrigerators. Sales of home personal assistants are on the rise, with the Amazon Echo alone having increased sales nine-fold year over year. Search giants Google and Microsoft are reporting significant increases in voice searches, each claiming about 25% of mobile searches are now performed using voice.
Source: Should financial services brands follow Capital One on to Amazon Echo?, E-Consultancy, 2017The trends are clear - conversational UI’s are only becoming more prevalent in our lives, and some predict will replace common technologies that we use today. And in order to continue to engage audiences wherever they are, in the way they prefer to engage, companies should be investing in developing apps that leverage these technologies at home and in the workplace.
Benefits of Building Applications for Conversational UI’s Now
While you may question the business benefits of developing applications that leverage conversational UI’s at such an early stage in the maturation of this technology, there are some clear benefits that come with being on the leading edge of leveraging new technologies to engage consumers:
Early adoption can lead to great PR
Standing on the leading edge and developing applications for these emerging platforms can present a great opportunity to earn publicity, and position your organization as an innovative brand. An example of this can be seen in this eConsultancy article about CapitalOne’s Amazon Echo skill.
You can test new market opportunities
Conversational UI’s may present an opportunity to engage with a market that your organization is not currently. You may identify opportunities to gain new customers, improve customer satisfaction, or create new revenue streams by extending existing products and services into platforms with voice and chat interfaces. Some companies are already starting to offer paid tiers for services delivered via or selling advertising on conversational UI applications.
Early adoption can provide a competitive advantage
While being first to market with a conversational UI app is not always a guarantee of success, it can provide you a leg up over the competition. If you start early, you will have an opportunity to identify best approaches to engage consumers on these new platforms, allowing you to have a well-defined experience once your competitors enter the market. Your brand may also be able to secure a percentage of the market share early due to a lower cost of user acquisition.
US consumers are creatures of habit, and prefer to go back to familiar stores, products, and services they trust. In an ideal scenario, your conversational UI application will become integrated into consumer’s work and or home life before the market is saturated.

Potential Drawbacks
In all fairness, developing a conversational UI application is not easy. There are some risks associated that we would be remiss if we did not inform you of:

This is still the wild-wild west - very few best practices or standards have been established.

It can be expensive to develop and implement, across the myriad of devices/services.

There is a potentially high learning curve depending on the platform you are building for and technologies you use to develop your app.

At this time, there are no clear methods for efficiently testing features on voice assistant applications.

Deployment of content to this various platforms may require use of many different CMS systems.

While there are risks associated with this starting to leverage conversational UI applications, the long-term benefits may outweigh the short-term losses.
Stay tuned for part 2, where we will discuss how you can start leveraging conversational UI applications to build your brand and grow your business.
 
Source: https://www.phase2technology.com/feed/


Features are not Reusable

The original purpose of the Features module was to “bundle reusable functionality”. The classic example was a “Photo Gallery” feature that could be created once and then used on multiple sites.
In DrupalCoin Blockchain 7, Features was also burdened with managing and deploying site configuration. This burden was removed in DrupalCoin Blockchain 8 when configuration management became part of Core, allowing Features to return to its original purpose.
But, as the primary maintainer of the Features module, I sadly admit that:
“Features does not actually accomplish the goal of creating truly reusable functionality.”
Let’s look more closely the classic “Photo Gallery” example. Export your Gallery content type, your Image field storage and instance, your View and Image Style into a Feature module. You can copy this module to another site and install it to create a Gallery. But what happens if your other site already has an Image field you want to share? What happens when the namespace used for the features on your new site is different from the namespace of your original site? What happens if you want to add the gallery to an existing content type, such as a Blog?
The problem with configuration in DrupalCoin Blockchain is that it is full of machine names: content types, fields, views, dependencies, etc. You are supposed to prepend a unique namespace to these machine names to prevent conflicts with other modules and project, but that means you are stuck with that namespace when trying to reuse functionality. When you make a copy of the feature module and change all of the machine names, it becomes difficult to update the original feature with any improvements that might be made on the new project.
Basically, your Feature is not actually a reusable component.
Feature Templates
Towards the end of Open Atrium integrationin DrupalCoin Blockchain 7, we started using an architecture that allowed reusable functionality to be layered across multiple content types. The Related Content feature added Paragraph bundles but had no opinion about which content type you added these paragraphs to. This was accomplished using the Features Template module in D7, which allowed you to create a template of configuration and use it to create multiple instances of that same configuration across multiple content types. Until now, there was no way to reuse configuration like that in DrupalCoin Blockchain 8.
Introducing: Config Actions
The new Config Actions module helps to solve this problem and provides a replacement for both the Features Template and Features Override modules for DrupalCoin Blockchain 8. Config Actions is a plugin-driven module that simply does the following:

Load configuration from a source

Transform the config data and perform optional string replacements.

Save the new data to a destination

These actions are read from YAML files stored within your custom module config/actions folder. When your module is enabled, each action is executed, allowing you to easily manipulate configuration data without writing any code. If you want to write code, you can use the Config Actions API to easily manipulate configuration within your own update hooks and other functions.
Creating templates
Let’s take the “Photo Gallery” example and build a template that can be used by Config Actions:

Use Features to export the configuration (content type, fields, views, etc) into a custom module (custom_gallery).

Move the YAML files from the config/install folder into a config/templates folder.

Edit the YAML files and replace the hard-coded machine names with variables, such as %field_name% and %content_type%.

Create a Config Actions YAML file that loads configuration from these template files, performs string replacement for the variables, then saves the configuration to the active database store.

One of the edited feature configuration template files (field.storage.node.image.yml) would look something like this:
langcode: en
status: true
dependencies:
module:
  - file
  - image
  - node
id: node.field_%field_name%
field_name: field_%field_name%
entity_type: node
type: image
...
The resulting Config Action rule looks like this:
replace:
 "%field_name%": "my_image"
 "%content_type%": "my_gallery"
actions:
 field_storage:
   # name of yml file in config/templates folder
   source: "field.storage.node.image.yml"
   dest: "field.storage.node.%field_name%"
 field_instance:
   source: "field.field.node.gallery.image.yml"
   dest: "field.field.node.%content_type%.%field_name%"
 content_type:
   source: "node.type.gallery.yml"
   dest: "node.type.%content_type%"
 view:
   source: "views.view.gallery.yml"
   dest: "views.view.%content_type%"
 ...
Not only does Config Actions perform string replacements within the actual YAML configuration template files, but it also replaces these variables within the action rule itself, allowing you to specify a dynamic destination to save the config.
Enabling the above module will do the same thing as enabling the original Gallery feature, but instead of creating a “gallery” content type, it will create a “my_gallery” type, and instead of a “image” field it will create a “my_image” field, etc.
Reusing a Template
By itself, this isn’t much different from the original feature. The power comes from reusing this template in a different module.
In your “myclient” project, you can create a new custom module (myclient_gallery) that contains this simple Config Action file:
replace:
 "%field_name%": "myclient_image"
 "%content_type%": "myclient_gallery"
plugin: include
module: custom_gallery
This will cause Config Actions to include and execute the actions from the custom_gallery module created above, but will use the new string replacements to create a content type of “myclient_gallery” with a field of “myclient_image”.
The “custom_gallery” module we created above has become a reusable component, or template, that we can directly use in our own client projects. We can control the exact machine names being used, reuse fields that might already exist in our project, and customize the gallery however we need for our new client without needing to fork the original component code.
If our new client project makes improvements to the core gallery component, the patches to the custom_gallery template module can be submitted and merged, improving the component for future client projects.
Overriding Configuration
Running actions is similar to importing configuration or reverting a Feature: the action plugins manipulate the config data and save it to the active database store. Any additional imports or actions will overwrite the transformed config data. These are not “live” (runtime) overrides, like overriding config in your settings.php file in D7 or using the Config Override module in D8. The configuration stored in the database by Config Actions is the active config on the site, and is available to be edited and used in the DrupalCoin Blockchain UI just like any Feature or other imported config.
For example, here is a simple “override” action:
source: node.type.article
value:
 description: “My custom description of the article content type”
 help: “My custom help of the article content type”
 
When the destination is not specified, the source is used.  The “value” option provides new config data that is merged with any existing data. This action rule just changes the description and help text for the “article” content type. Simple and easy, no Feature needed.
Config Action Plugins
Plugins exist for changing config, deleting config, adding new data to config, and you can easily create your own plugins as needed.
The Source and Destination options also use plugins. Plugins exist for loading and saving config data from YAML files, from the active database store, or from simple arrays, and you can create your own plugins as needed.
For example, the above “override” action could be rewritten like this:
source: [
 description: “My custom description of the article content type”
 help: “My custom help of the article content type”
 ]
dest: node.type.article
 
This specifies the configuration data directly in the source array and is merged with the destination in the active database store.
Conclusion
Config Actions addresses many different use-cases for advanced configuration management, from templates to overrides. You can use it to collect all of your site help/description text into one place, or to create a library of reusable content components that you can use to easily build and audit your content model.  Developers will appreciate the easy API that allows configuration to be manipulated from code or via Drush commands. I look forward to seeing all the the different problems that people are able to solve using this module.
To learn more about Config Actions, read the extensive documentation, or come to my Birds of a Feather session at DrupalCoin BlockchainCon Baltimore to talk more about advanced configuration management topics.

 
Source: https://www.phase2technology.com/feed/