Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 21 hours 29 min ago

Gábor Hojtsy: State of Drupal 9 - May 2019 session recording

7 June 2019 - 4:29am

I created and shared an open source set of editable slides with plenty speaker notes titled "State of Drupal 9" early in May, based on my webinar with Dries and then the Drupal 9 parts of the DrupalCon Seattle Driesnote. I hope that we can bring this know-how to a lot of conferences, meetups and to companies so people are more aware of what is coming, what happens to Drupal 8 and 7, what's so great about Drupal 9 and what are the key tools involved.

Before I even presented the slideshow first, I already got improvement suggestions from people presenting it elsewhere. So the first time I got to present this session in Minsk, Belarus at the kind invitation of DrupalCamp Belarus organizers, it was already improved from when I first published it. I will keep updating the slides and present where I can in the coming months. Please, do it yourself too! Translate, shorten, lengthen, etc. to match your audience and timing needs, as long as the key messages get through. Be an important contributor to Drupal 9 this way!

Here is the recording from DrupalCamp Belarus:

Categories: Drupal

Agiledrop.com Blog: Top Drupal blog posts from May 2019

6 June 2019 - 11:41pm

May marked another important month for the Drupal community, with a new minor version of Drupal being released on May 1st and Acquia acquiring the open source marketing platform Mautic. In case you missed any of these important pieces of news, here’s an overview of the top Drupal blog posts from May.

READ MORE
Categories: Drupal

Community posts: Creating Strategies for Effective & Inclusive Group Communication in the Drupal Community

6 June 2019 - 12:08pm

One of the chartered responsibilities of the Drupal Community Working Group (CWG) is to work to develop and support community initiatives that promote the health of the Drupal community and help to prevent conflict and burnout. One of the ways that we do this is by organizing workshops designed to provide community leaders with the knowledge, tools, and resources they need to help keep our community a friendly and welcoming place.

Following feedback from last year’s Teamwork and Leadership workshop at DrupalCon Nashville, we decided to narrow the focus and audience for our next workshop. One of the things we’ve observed over the last year in the Drupal community is that many of the issues we’ve seen have had to do with communication breakdowns between various individuals and groups. Following internal discussion in late 2018, we decided that one way to begin addressing this issue was by bringing together leaders in the community representing different groups and interests for a workshop focused on communication skills at DrupalCon Seattle.

In early 2019, we interviewed a number of potential facilitators suggested by Drupal Association board chair Adam Goodman and selected Megan Bernard, a professor of communication studies who specializes in promoting meaningful and inclusive learning and collaboration. Based on Prof. Bernard’s recommendation, we decided to spread this year’s workshop out over two days (April 10-11) in a dedicated meeting room provided by the Drupal Association, who generously covered all fees and expenses.

After finalizing the logistics, we then reached out to those who had attended last year’s workshop, as well as additional community members involved with community governance, camp organizing, core and contrib maintainers, the Drupal Security Team, Drupal Diversity & Inclusion, and the Drupal Association. The workshop facilitator suggested that we keep the size of the workshop to around 20 people, focusing on individuals who are well-connected in the community in hopes that they can help distribute the lessons learned in the workshop. 17 people attended some or all of the first day of the workshop, and 18 attended some or all of the second. In total, community members from 10 different countries spread across 4 different continents were represented.

Day one of the workshop included introductions, a discussion of needs, assets, and challenges faced by various groups within the Drupal community, and a discussion of shared context and perspective. We talked about different ways that other online communities help communicate context about their users, such as identifying the primary language, pronouns, and location in comment threads. During our discussion, Neil Drumm pointed out there was already an active issue led by justafish and others to allow users to display this kind of information, and one of the first action items we agreed on was helping it get implemented on Drupal.org as quickly as possible.

Another topic of discussion centered around creating pre-written template responses that maintainers and/or other privileged users could use in issue threads to “nudge” users in the right direction and realign communication when conversations start trending away from our community standards. We discussed badges and other ways to promote positive communication in our issues threads and other community spaces. In addition, we also talked about better ways to on-board new members into the project and foster an ongoing sense of community. One insight was that small cohorts of 6-8 people are far more effective than 1:1 mentoring at building community engagement.

In our second day, we dug more deeply into the concepts of emotional intelligence, de-escalation practices, and different forms of conflict. One of our exercises was a case study challenge, where different groups were tasked with finding different ways to resolve typical kinds of conflicts often seen in Drupal and other open source communities.

We also spent time talking about different ways to apply some of the things we had learned to our own community, and next steps. We agreed as a group to focus on three main areas:

  1. Setting context in issue queues. This work had already been mostly completed in https://www.drupal.org/node/2961229 so it was really just a matter of working with DA staff to get it implemented on Drupal.org.

  2. Nudges. A group of us decided to do more research into pre-written templates to use in issue queues, forums, and Slack to gently steer things back in the right direction when conversations were starting to go in a negative direction.

  3. Improving Drupal.org user on-boarding and cohorts. In addition to better identifying new users on the site, we agreed to look into various ways to help community members join small cohorts, organized by industry, technology, geography, or other criteria. We felt it was important that this be an opportunity that’s open to existing community members as well as new ones.

The folks assigned to each area agreed to find a time to meet in the coming weeks and to involve other interested community members as well. The CWG also identified several opportunities to improve and streamline its internal processes and communication practices.

By developing and communicating best practices that can be shared across the community, the hope is that we can help build structures for self-guided conflict resolution among community members and support more effective communication overall.

Categories: Drupal

Srijan Technologies: Going Global: Enabling Multilingual SEO with Drupal 8

6 June 2019 - 10:32am

Enterprises can find their websites attracting visitors and clients from different geographies, speaking different languages. The market is so huge (and international) that targeting only English speaker based users means deliberately missing out on an effective way to grow audience, ROI, customer trust, and rank on Google.

Categories: Drupal

Texas Creative: Drupal 8: How to Alter Forms Without Modules

6 June 2019 - 7:30am

Sometimes when working with Drupal’s exposed forms, you might get stuck with a field type that you don’t want. Often times you can find a module to help improve the style or functionality of these forms. However, in some cases using a module will not be available and you will have to make modifications directly to the code.

If you are just getting started with Drupal, and come from a JavaScript background, this will clearly be the easiest method for you. If you are familiar with PHP and want to better understand Drupal, I encourage you to try a preprocess function!

Read More
Categories: Drupal

OPTASY: Using Drupal for Project Management and Team Collaboration: 2 Drupal Distributions to Consider

6 June 2019 - 5:27am
Using Drupal for Project Management and Team Collaboration: 2 Drupal Distributions to Consider adriana.cacoveanu Thu, 06/06/2019 - 12:27

“Can I use Drupal for project management?” Definitely. 

Given all its content-oriented baked-in capabilities — file management, version control, easy content creation, and editing — Drupal makes the perfect software for:
 

  • managing your projects the easy and the... smart way
  • streamlining communication among your team members and with your contractors
     

In this respect, Drupal provides its own feature-rich distributions to help you put together your robust setup in no time. “Distributions” that come already packed with a set of useful sub-modules and themes, that all support the core functionality: project management (and smooth collaboration).

Categories: Drupal

wishdesk.com: Time to prepare for Drupal 9 with Upgrade Status module

6 June 2019 - 5:19am
Upgrades from Drupal 8 to Drupal 9 will be quick and easy, and this is one of Drupal 8 benefits. However, there is a condition all websites should meet — and there is a wonderful Upgrade Status module that will help them with that. 
Categories: Drupal

Third & Grove: An Intro to Decoupled Drupal Podcast with Acquia

6 June 2019 - 4:00am
An Intro to Decoupled Drupal Podcast with Acquia mdavis Thu, 06/06/2019 - 07:00
Categories: Drupal

Phase2: Hello Marketers! We’re writing this (Drupal 8) one for you.

5 June 2019 - 11:45am

The latest version of Drupal is version 8.7.2. You’re familiar of course. In fact, you’ve been on pins and needles ever since version 8.7.1(a). I’m sure you’ve been instasnaptweeting ever since it was issued.

OK, back to reality: You’re definitely more concerned with getting the data you need, driving great brand interactions, and maintaining costs (and keeping your InfoSec or IT teams happy)—than the latest CMS version.

Categories: Drupal

Mediacurrent: The Myth of Inaccessible React

5 June 2019 - 11:00am

On Twitter, in Slack, on Discord, in IRC, or wherever you hang out with other developers on the internet, you may have heard some formulation of the following statements:

  • React doesn't support accessibility
  • React makes websites inaccessible
  • People should write accessible HTML instead of React
  • React is ruining the internet

There's a somewhat common misperception that JavaScript frameworks and web accessibility don't mix. React, being one of the largest JavaScript libraries, is often the target. 

In my career, however, I have had the interesting experience of being introduced to accessibility and ReactJS at around the same time. I found tooling in React that helped me learn a lot about accessibility that I never would have encountered otherwise.

And while I don't disagree that there are plenty of libraries, websites, apps, etc. written in React that are inaccessible, I do disagree there is something inherent in ReactJS that makes developers build inaccessible sites. In fact, I love the accessibility tooling available in the React ecosystem, so this post is really about how React can help you make more accessible websites than you've ever made before.

I'll outline how you can combine React linting tools, DOM auditing, and Storybook (a component library tool) to provide a really supportive accessibility environment for developers -- whether they are accessibility pros or just getting started. By the end of this post, you'll have the following configured for your Gatsby project (or other React project):

  • in-editor reporting of accessibility errors
  • a pre-commit hook for preventing accessibility errors from getting into the repository
  • browser console reporting of accessibility errors during development, with links to info on how to resolve the errors
  • a component library with built-in accessibility testing so all project stakeholders can hold the team accountable for accessibility issues

Want to get started right away? I created a Gatsby starter with all these accessibility tools built in. Checkout the gatsby-starter-accessibility repo that has all these features available out of the box.

Tools and Setupeslint-plugin-jsx-a11y

If you've written JavaScript over the past few years, you've probably used or at least heard of ESLint. If not, now is a great time to get started with it!

ESLint is a linting utility for JavaScript that helps you catch formatting and syntax errors while you are writing code. Most editors have some sort of linting configuration built in, which lets you see errors in your editor while you code.

This is really helpful for keeping code consistent, especially when there's a lot of people working on a project.

ESLint also has a really healthy plugin ecosystem. You can include rules specific to the JavaScript framework you are working with (i.e., React, Angular, Vue, etc), among others. For React, I typically use the eslint-plugin-react and the really helpful eslint-plugin-jsx-a11y. This plugin lints your code for known accessibility violations, using these rules.

Having these automated tests run while you are writing code can prevent so many errors. Even though automated accessibility testing catches only about 20-30% of all accessibility errors, catching these errors before they make it into a codebase can save time, budget, and energy for doing more manual testing once the code is in the browser.

Usage

Here's how you can get started with accessibility linting in your React project.

First, we'll need to install the necessary eslint packages:

npm install eslint eslint-plugin-react eslint-plugin-jsx-a11y --save-dev

In your package.json, add the following configuration:

"eslintConfig": {
    "parserOptions": {
      "sourceType": "module"
    },
    "env": {
      "node": true,
      "browser": true,
      "es6": true
    },
    "plugins": [
      "react",
      "jsx-a11y"
    ],
    "extends": [
      "eslint:recommended",
      "plugin:react/recommended",
      "plugin:jsx-a11y/recommended"
    ]
}

With this added to your package.json, ESLint will use the rules recommended by ESLint, React, and the jsx-a11y plugin while you are working. 

You'll want to make sure your editor is set up to display linting errors in the editor for this to be really useful.

Add a pre-commit hook for preventing inaccessible code in the codebase using lint:staged

Now we've got some accessibility linting set up, and hopefully everyone working on the project has linting turned on in their editor so they can see any errors while they work.

But you can't be 100% sure that everyone will be paying attention to the linter. And even if they are, it's easy to make a quick change, switch files, and any errors will be out of sight, out of mind.

What we can do as an extra check to prevent inaccessible code from entering the codebase is to add a pre-commit hook that runs the linting we set up above every time a developer tries to commit code. If an accessibility error is found, an error message will display with the relevant linting error and location of the error, and the commit will be prevented until the developer resolves the issue.

lint-staged will run a pre-commit hook that will catch any accessibility errors raised by eslint-plugin-jsx-a11y

Usage

The easiest way to set up pre-commit linting hooks is using the lint-staged package. After you've got all your eslint configuration set up (from our first step), run the following command in your project directory:

npx mrm lint-staged

This command will install the husky package for managing the pre-commit hooks and look in your package.json to automatically setup a pre-commit hook based on your linting configuration.

A simple configuration that lints all JS files based on the existing eslint configuration in the repo will look like this (from package.json):

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
},
"lint-staged": {
    "*.js": [
      "eslint"
    ]
}

You can adjust this as you see fit. For example, sometimes you want to limit linting to certain directories. To run the pre-commit hook only on JS files in the src directory, you would update the lint-staged configuration like this:

"lint-staged": {
    "src/*.js": [
      "eslint"
    ]
}

The great thing about lint-staged is that it only lints the files that are part of the current commit. If for some reason there is some pre-existing errors in another part of the codebase, the commit won't be prevented--it only prevents new errors from being introduced.

react-axe

The great thing about the linting setup we have now is that it will prevent a lot of errors from being introduced into the codebase. It won't prevent all errors, however. Some errors only exist when several components are used together, or from certain content, and can only be caught in the browser.

Luckily, we have a solution for this, too. Axe is an open source engine for automated accessibility testing, supported by Deque. I first became familiar with axe by using their really useful browser extension for testing individual pages in the browser.

The problem with browser-extension accessibility testing is that they are typically only run after development is complete. Using the react-axe library, you can have automated accessibility testing run on every page during development, so developers can get real-time feedback on accessibility issues. This helps make sure that accessibility issues never make it to production, and it also educates developers who may not be accessibility experts on potential pitfalls.

The react-axe library is an easy to use implementation of the axe engine, specifically for React.

Usage

Here's how to get started using react-axe with Gatsby (someone made a Gatsby plugin for it!):

npm install --save gatsby-plugin-react-axe

Add gatsby-plugin-react-axe to your plugins array in gatsby-config.js

module.exports = {
 siteMetadata: {
        title: 'Gatsby Default Starter',
    description:
      'Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.',
    author: '@gatsbyjs',
  },
  plugins: [
    'gatsby-plugin-react-axe',
    // other plugins go here
  ],
};

Now, when the page renders, the plugin will print any accessibility errors to the browser console. Here's an example, where I've put an <h5> directly underneath an <h1>:

React aXe will show accessibility errors in the console while you are developing.

You can see that in the axe message in the console that it has identified my heading issue: "Heading issues should only increase by one" as a moderate issue. It also includes a link to learn more about why this is an issue and how to resolve it: https://dequeuniversity.com/rules/axe/3.2/heading-order. And lastly, it displays the specific element that is causing the issue for easy identification.

This kind of instant feedback is so important, whether you are an accessibility beginner or even a seasoned pro. Catching the automated issues instantaneously can give you more bandwidth to focus on other more involved tasks.

Storybook and Accessibility

The last piece of our accessibility workflow has to do with our component-driven workflow. For React projects, I have really enjoyed using Storybook to build and document our front end components. 

Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building stunning UIs organized and efficient.

storybook.js.org

Besides having a nice workflow and UI, Storybook has an awesome accessibility add-on that adds a panel to each component in your component library highlighting accessibility issues.

Our storybook configuration has built-in axe tests for each component and a color blindness simulator, provided by the storybook accessibility add-on.

Behind the scenes, the add-on actually also uses aXe for testing. This is really nice, because it means that the testing we are using in development is the same as what we are using in the component library. Having the errors highlighted in the component library also helps everyone on our project teams catch accessibility issues as they are browsing the library, either for QA purposes or design inspiration.

Setup

The setup for Storybook is a bit more involved, so if you haven't used Storybook before, you can checkout the Storybook for React documentation for a generic React setup.

If you want to get Storybook running with Gatsby, see Visual Testing with Storybook in the Gatsby docs.

Once you have Storybook setup, adding the accessibility add-on is pretty straightforward.

First, install the add-on:

npm install @storybook/addon-a11y --save-dev

Then add this line to your addons.js file in your storybook config directory:

import '@storybook/addon-a11y/register';

And lastly, add this line in your Storybook config.js file to automatically add the accessibility panel to all components:

addDecorator(withA11y);

When you run Storybook now, you should now see the accessibility panel (see a live version here):

Our storybook configuration has built-in axe tests for each component and a color blindness simulator, provided by the storybook accessibility add-on.

As a side note - you can control the order of the tabs in your add-ons panel based on the order that you import add-ons into your addons.js file, if you want to have the accessibility panel display by default, make sure it is the first line in your addons.js.

Wrap up

If you didn't follow along with the setup or just want to get a new project setup quickly with this workflow, checkout the gatsby-starter-accessibility Gatsby starter!

You can create a new Gatsby site with all the configuration I described above out-of-the box with this single line in your terminal:

npx gatsby new my-accessible-project https://github.com/benjamingrobertson/gatsby-starter-accessibility

Or you can checkout the specific configuration in the repo.

Whether you ran through all the steps above or use with the starter, you'll have the following features set up in your Gatsby / React project:

  • in-editor reporting of accessibility errors
  • a pre-commit hook for preventing accessibility errors from getting into the repository
  • browser console reporting of accessibility errors during development, with links to info on how to resolve the errors
  • a component library with built-in accessibility testing so all project stakeholders can hold the team accountable for accessibility issues
     

On a complex project with many team members and moving parts, automating accessibility testing will help save time to make sure you can pay more attention to the accessibility tasks that can't be caught by automated tests. 

Beyond that, tools like this can really help developers level up their accessibility knowledge.

I know it's helped me--I hope it helps your team too!

Categories: Drupal

Lullabot: Interpreting the Drupal Core Commit History

5 June 2019 - 10:40am

According to Drupal’s community documentation, “The Benevolent Dictator for Life (BDFL),” Dries Buytaert, is the “chief decision-maker for the [Drupal] project.” In practice, as Dries has pointed out, he wears “a lot of different hats: manager of people and projects, evangelist, fundraiser, sponsor, public speaker, and BDFL.” And he is chairman and chief technology officer of a company that has received

Categories: Drupal

Hook 42: All Aboard To Chattanooga

5 June 2019 - 8:00am
All Aboard To Chattanooga Lindsey Gemmill Wed, 06/05/2019 - 15:00
Categories: Drupal

Drudesk: Simple ways to rewrite the output of Drupal 8 Views fields

5 June 2019 - 6:34am

The unique Drupal Views module allows you to pull the data from the database and display it in any way you wish. As an example, we discussed creating photo galleries with Drupal 8 Views. Drupal’s flexibility is unlimited, so it offers additional ways to customize the content display and meet the customer’s precise requirements. One of them is to rewrite the output of Drupal Views fields. Let’s explore it a little bit in the simplest of cases.

Categories: Drupal

Morpht: Debugging Guzzle HTTP request errors in Drupal

5 June 2019 - 3:24am

Guzzle makes HTTP requests easy. When they work, it's like magic. However, as with all coding, getting something to work requires debugging, and this is where the Drupal implementation of Guzzle has a major usability problem - any returned messages are truncated, meaning that with the default settings, error messages that can help debug an issue are not accessible to the developer. This article will show developers how they can re-structure their Guzzle queries to log the full error to the Drupal log, instead of a truncated error that does not help fix the issue.

Standard Methodology

Generally, when making a Guzzle request, it is made using a try/catch paradigm, so that the site does not crash in the case of an error. When not using try/catch, a Guzzle error will result in a WSOD, which is as bad as it gets for usability. So let's take a look at an example of how Guzzle would request a page using a standard try/catch:

try {
  $client = \Drupal::httpClient();
  $result = $client->request('GET', 'https://www.google.com');
}
catch (\Exception $error) {
  $logger = \Drupal::logger('HTTP Client error');
  $logger->error($error->getMessage());
}

This code will request the results of www.google.com, and place them in the $result variable. In the case that the request failed for some reason, the system logs the result of $error->getMessage() to the Drupal log.

The problem, as mentioned in the intro, is that the value returned from $error->getMessage() contains a truncated version of the response returned from the remote website. If the developer is lucky, the text shown will contain enough information to debug the problem, but rarely is that the case. Often the error message will look something along the lines of:

Client error: `POST https://exaxmple.com/3.0/users` resulted in a `400 Bad Request` response: {"type":"http://developer.example.com/documentation/guides/error-glossary/","title":"Invalid Resource","stat (truncated...)

As can be seen, the full response is not shown. The actual details of the problem, and any suggestions as to a solution are not able to be seen. What we want to happen is that the full response details are logged, so we can get some accurate information as to what happened with the request.

Debugging Guzzle Errors

In the code shown above, we used the catch statement to catch \Exception. Generally developers will create a class that extends \Exception, allowing users to catch specific errors, finally catching \Exception as a generic default fallback.

When Guzzle hits an error, it throws the exception GuzzleHttp\Exception\GuzzleException. This allows us to catch this exception first to create our own log that contains the full response from the remote server.

We can do this, because GuzzleException provides the response object from the original request, which we can use to get the actual response body the remote server sent with the error. We then log that response body to the Drupal log.

use Drupal\Component\Render\FormattableMarkup;
use GuzzleHttp\Exception\GuzzleException;

try {
  $response = $client->request($method, $endpoint, $options);
}

// First try to catch the GuzzleException. This indicates a failed response from the remote API.
catch (GuzzleException $error) {

  // Get the original response
  $response = $error->getResponse();

  // Get the info returned from the remote server.
  $response_info = $response->getBody()->getContents();

  // Using FormattableMarkup allows for the use of tags, giving a more readable log item.
  $message = new FormattableMarkup('API connection error. Error details are as follows:@response', ['@response' => print_r(json_decode($response_info), TRUE)]);

  // Log the error
  watchdog_exception('Remote API Connection', $error, $message);
}

// A non-Guzzle error occurred. The type of exception is unknown, so a generic log item is created.
catch (\Exception $error) {
  // Log the error.
  watchdog_exception('Remote API Connection', $error, t('An unknown error occurred while trying to connect to the remote API. This is not a Guzzle error, nor an error in the remote API, rather a generic local error ocurred. The reported error was @error', ['@error' => $error->getMessage()));
}

With this code, we have caught the Guzzle exception, and logged the actual content of the response from the remote server to the Drupal log. If the exception thrown was any other kind of exception than GuzzleException, we are catching the generic \Exception class, and logging the given error message.

By logging the response details, our log entry will now look something like this:

Remote API connection error. Error details are as follows:

stdClass Object (
  [title] => Invalid Resource
  [status] => 400
  [detail] => The resource submitted could not be validated. For field-specific details, see the 'errors' array.
  [errors] => Array (
    [0] => stdClass Object (
      [field] => some_field
      [message] => Data presented is not one of the accepted values: 'Something', 'something else', or another thing'
    )
  )
)

* Note that this is just an example, and that each API will give its own response structure.

This is a much more valuable debug message than the original truncated message, which left us understanding that there had been an error, but without the information required to fix it.

Summary

Drupal 8 ships with Guzzle, an excellent HTTP client for making requests to other servers. However, the standard debugging method doesn't provide a helpful log message from Guzzle. This article shows how to catch Guzzle errors, so that the full response can be logged, making debugging of connection to remote servers and APIs much easier.

Happy Drupaling!

Image credit: Marco Verch https://www.flickr.com/photos/30478819@N08/35337269544
Categories: Drupal

Agiledrop.com Blog: Our blog posts from May 2019

5 June 2019 - 1:47am

We’ve prepared a short overview of the blog posts we wrote in May. Give it a read and check out what we had to say.

READ MORE
Categories: Drupal

BADCamp 2019: Amalgamate with us in the fall!!

4 June 2019 - 2:53pm
Amalgamate with us in the fall!! volkswagenchick Tue, 06/04/2019 - 21:53
Categories: Drupal

Phase2: The Last Great Migration: Why Drupal 8 is in a Class of Its Own

4 June 2019 - 8:45am

Historically, migrating your content management system (CMS) or content platform from one major version of Drupal to the next was nothing short of a Herculean task.

Every new version of Drupal meant rebuilding existing functionality, converting (or migrating) your content, and accepting significant changes along the way. Because of this, it’s become commonplace to see stakeholders want to leapfrog Drupal versions (e.g., 5 to 7, or 6 to 8), to extend the life of both their old and new platforms for as long as possible for the least amount of transitional pain.

Categories: Drupal

Hook 42: Switching Themes For Progressive Enhancements

4 June 2019 - 8:40am
Switching Themes For Progressive Enhancements Adam Bergstein Tue, 06/04/2019 - 15:40
Categories: Drupal

Palantir: Learning Design Thinking by Doing: How to Craft a Design Workshop

4 June 2019 - 8:39am
Learning Design Thinking by Doing: How to Craft a Design Workshop Monday, June 17, 2019 brandt Tue, 06/04/2019 - 10:39 WeWork, 111 W Illinois Street, Chicago, IL Chicago IA/UX Meetup (official site)

Facilitating design workshops with key stakeholders allows them to have insight into the process of "how the sausage is made" and provides the product team buy-in from the get-go.

Join Palantir's Director of UX Operations, Lesley Guthrie, for a session on design workshops. She'll go over:

  • How to choose the right exercises 
  • How to play to the team skill sets
  • Ways to adjust the workshop to fit the needs of the project 

You'll learn how to sell it the idea of the design workshop to stakeholders and collaborate with them on a solution that can be tested and validated with real users.

Tue, 06/04/2019 - 12:00
Categories: Drupal

Freelock : Is your host a single point of failure?

3 June 2019 - 3:45pm
Is your host a single point of failure? John Locke Mon, 06/03/2019 - 15:45

Just ran across a sad story where Digital Ocean is accused of killing a startup:

Disaster Recovery Drupal Planet Risk
Categories: Drupal

Pages