Design systems are all the rage these days, but what exactly is a design system? How do you know when you need one? In this session we'll cover the following:
What is a design system?
How do you know when you need a design system?
How do you thoughtfully plan and model a design system for a CMS like Drupal?
How do you create and maintain a design system as a team (or teams)?
I'll share real-world examples from projects of varied scale and complexity that our team of Lullabot strategists, designers and developers have worked on.
Who is this session for?
Designers looking to learn more about what design systems are and how to model them for a CMS like Drupal.
Content editors and product owners looking for practices and approaches to creating great design systems that empower editors of a Drupal site.
Content strategists looking for ways to relate the content model to the patterns, components and presentation of the site.
Front-end and back-end developers wanting better process and strategies for planning out design systems collaboratively.
Project managers looking for practices to facilitate communication and collaboration by multiple disciplines creating a design system.
A smart programmer is not the one who fixes all the problems, but rather, the one who understands what the problems worth fixing are. When discussing quality software, everyone talks about unit tests and test-driven development, only a small piece of building good software. In this session, we'll explore validation and verification beyond software tests. In other words, are you building the right product (validation), and was the product built correctly (verification)? The only way to test for validation and verification is to understand what you and your company does best, what the client offers, and what their customers need.
We will cover:
Getting clients involved and invested (not just the role of your PM!)
Creating a build specification to document, refine and communicate project architecture
Prototyping and sandboxing
Timeboxing tasks to validate estimates quickly
How to handle QA and code reviews
Drush cr… drush cr… drush cr!!! We all know the scenario where you’ve made a change to the site, but when you load the page it just doesn’t seem to show. Oftentimes the solution is to clear your cache and move on, but why is that?
In this session we’ll explore how that cache is built and used. What determines when a page can be cached, and how does Drupal know when to rebuild it? How does Drupal know when to rebuild parts of a page without rebuilding everything?
Drupal 8 introduced a whole new methodology for caching: Cache tags and contexts. Using and maintaining these effectively will make your life easier and your clients love you. We will go over real life examples and show best practices to keep your caches up to date.
Level of Knowledge Needed
Attendees should be comfortable with back-end development and/or theme-level development using render arrays.
Topics to be Discussed
Throughout this session we’ll explore:
Caching layers in Drupal
Existing and custom cache contexts and tags
Maintaining cache data throughout rendering
Caching during development
Using cache tags with proxies (Varnish, CDN, etc.)
Attendees to this session will walk away with:
An understanding of how cache tags and contexts are used in Drupal 8
A view into Drupal’s rendering process and how caching data bubbles through the render caches
A framework of questions to determine when cache tags or contexts are needed
In a user-first world, content is the basis for ensuring great user experience. A content audit lays the groundwork for aligning organizational objectives with site visitor needs. It is the preparatory work for the site architecture, content model, and page layouts. It addresses content governance and the content creation process.
Additionally, a content audit can be a tool for building collaboration, credibility, and respect for the role of the content strategist on the web team. We can embrace and agree upon values, goals, and realities that set the stage early in the project for ongoing cooperation.
This session will provide content strategists both the understanding of how to conduct a content audit, as well as the insights for making the content audit a key tool for website collaboration.
You will learn how to:
Conduct the quantitative and qualitative aspects of the content audit.
Tie the audit to the needs of content creators for creating sustainable content.
Collaborate with all team members, with a fresh understanding of where content fits into a web project.
Build credibility within the organization for the practice of content strategy.
Email remains one of the most powerful and direct ways to reach your audience and this session will explain how you can track its performance on a detailed level without impacting your Drupal infrastructure. We will be using Amazon’s Web Services, through a combination of Simple Email Service, Simple Notification Service, and Simple Queue Service to integrate with Drupal to send and track deliveries, opens, clicks, bounces, unsubscriptions, and complaints, all at a really low cost and dramatically reducing the load on your own server.
Emotional labor is, in one sense, the invisible thread that ties all our work together. Emotional labor supports and enables the creation and maintenance of our products. It is a critical community resource, yet undervalued and often dismissed.
In this session we'll take a look at a few reasons why that may be the case and discuss some ways in which open source communities are starting to recognize the value of emotional labor.
Specifically, we will cover:
What do we mean when we discuss "emotional labor"?
How is emotional labor different from other kinds of work?
What expectations exist around emotional labor?
(How) is emotional labor valued in Drupal?
What can we do to increase the perceived value of emotional labor?
How can we distribute the responsibility to perform emotional labor?
This talk is targeted towards all levels of the community, to coders and non-coders, and especially to project leads and those who wish to become leads.
Drupal thrives on community contributions in the form of patches and documentation to both contributed modules and core. This helps the project move forward and stay relevant.
Not everyone who works on open source projects is a senior developer. Smaller tasks help people increase confidence and gain experience, which, in turn, leads to more contributions. Code is very important, but so are all the other parts. Contributing back to Drupal helps folks to become better developers. A more polished Drupal leads to a better overall experience.
But how does one become a contributor? Together we’ll discuss what we can do as a community to help foster new contributors and keep the ones we already have.
There will also be a lightning round demonstrating the process of creating an issue, writing a patch, uploading the fix to Drupal.org, and then reviewing the patch for RTBC (reviewed and tested by the community). We'll even take a look at the upcoming GitLab contribution process because specific tools and processes change over time.
High demands, high anxiety clients are a reality of agency life. Their stresses, deadlines, and sometimes lack of understanding of the technology can create tension and take a project (or the client relationship) off track. Together we’ll discuss common challenges and the strategies that satisfy the clients need while insulating your team; allowing them to be more effective. These strategies will include how to:
Herding Cats: wrangle in out of control expectations
Stop the Hissing: promote positive, team-focused communication styles
Playing Well Together: encouraging multi-player team involvement without sidetracking the dev team
Detaching the Claws from the Ceiling: being a calming voice while holding your ground and mitigating scope creep
Grooming: performing a retrospective at important milestones that produce actionable improvements moving forward
Walk away with people-focused tactics that will help you improve your relationships with both the client and inside of your team.
A growing number agencies and development teams today work remotely or at least co-located. In fact, the Drupal Project itself is almost entirely developed by individuals in different locations.
This type of remote work offers a lot of benefits in today’s fast-growing global economy and many have grown to favor remote work over the conventional, centrally located office environment. But even the most experienced members of a distributed will admit it doesn’t come without its challenges. Whether you work from home, a co-working space, coffee shop, or are in a centrally located small team in a larger org—you’re sure to get something out of this session.
In this session we’ll cover:
• Tools and workflows for effective collaboration
• Beating isolation while working remotely
• Staying productive when you reach a creative rut
• Processes for eliminating distractions
• Having fun and keeping the human connection
• Finding ways to take advantage of remote work
Are you looking to improve the handoff between your design and development teams? In this session, we’ll share our approach at Lullabot for how the design team works with the front-end team throughout the entire design process to help improve the design handoff. We’ll discuss:
When to push back
To get the most out of this session, we expect you to be familiar with the designer to dev procedure and hopefully have experienced some pain within the process.
Nearly every new project focuses heavily on the flashy design and fancy tools it'll make for its visitors. So much focus is driven into the site user's experience to make it intuitive and pleasant, but in many cases this ignores the users that will visit the site more than anybody else: the content editors.
The topic of improving the editorial experience in Drupal has gotten much more attention in recent years through core initiatives and distributions like Lightning and Thunder exploring how to improve the administrative interactions. Making a user-friendly site admin doesn't require dedication at the level of a core initiative or distribution; through the use of existing contrib modules, some best practices, and a bit of consideration all the sites you build or manage can be intuitive and helpful to anyone logging into it with minimal added effort or risk.
Level of Knowledge
Content editor: Attendees interested in learning how forms could be improved even if unsure how to do so personally are welcome.
Site-builder: Attendees should be comfortable with installing modules and site-building configuration throughout Drupal.
Topics to be Covered
Principles of a good administrative experience
Best practices in Drupal forms
Contrib modules to improve your admin UX
Attendees Will Leave With...
Guiding principles to apply to any forms or admin experiences they encounter
Resources to reference for common UX best practices
A toolbox of modules to improve new and existing sites alike
Website development tools have come a long way over the past decade and if you are just getting started you can feel lost pretty quickly. To do something simple like spinning up a CMS and installing a few plugins comes with a handful or pre-requisites that may be out of your skill set and more suited for someone in devops. What tools do I need to use? Do I need a server? OMG I need to install linux, apache, mysql, and php? ... Sound familiar?
So you’re thinking about decoupling your Drupal site because the Drupal’s API-First initiative is making it easier than ever to plug in your favorite front-end framework and get to work. But what are the gotchas that you might encounter? We are lucky to work with a full-featured platform like Drupal, but what features must you replace in order to build a completely independent front-end?
Our team has developed and released decoupled Drupal sites and this talk will cover our experiences developing these applications and tools we used to build features we needed. This talk is targeted at developers and those who are considering a decoupled project but are skeptical of the scope of the work compared to a “traditional” Drupal build-out. The talk will review the following topics and concepts:
Essential Drupal modules
Design & layout
Custom REST endpoints
Current and future challenges
The search world is all about social graphing today. Just look at Google's quick results sidebar when you search for a local business. You see a picture of the business, rating/reviews, hours, menu and more. Structured SEO data can help you define and shape what is shown about your site on search results.
This talks is intended to help people understand how to apply Structured data to a website and then implement this with a minimum of technical skill.
This talk covers:
Why you should be using structured data
An overview of what structured data is
A dive into the Schema.org standard and how Search Engines expect this to be embedded into a site.
A short example of how this was used in the DukeHealth.org site
A how to on using the Metatag and Schema.org Metatag modules to add structured data to your site.
A very quick look at how to go beyond what these can do using code.
Note I'm not an SEO wiz that can tell you 'how to make your site shine' but have learned a bit while implementing this on various sites. In other words, I may not be able to tell you what to do for this, but I can tell you how to do it.
If you've worked on large enterprise site themes, you're probably tired of writing Twig to map in your hand-built pattern libraries to Drupal templates. If you're building sites solo, it'd be nice to not have to use 20 different modules to get all the blocks you need to make your front-end look just right after theming, or have to resort to using the pre-build Bootstrap bundles.
Patternkit (https://www.drupal.org/project/patternkit) attempts to solve these problems by allowing you to import existing Pattern Libraries directly into Drupal as blocks, drop them into your layouts using the Layout Builder core module, then map in your existing content as needed. Keep your content types (and therefore schema) as simple and sensible as possible and let Patternkit do what it does best: display the patterns you choose with your content. It's like the ui_patterns module (https://www.drupal.org/project/ui_patterns) - but much more flexible.
We'll show you how to go from our Git repo with a Pattern Lab (https://patternlab.io/) library to a fully-built Drupal site with dynamic components and content using only Drupal Core, Patternkit, and a custom component library - and then a dash of how to expand on what we've built!
In this session we'll learn how to gather, clean, and visualize Drupals usage statistics using essential data science tools.
Participants will leave the session with a host of ideas on how they can use these tools to analyze their own data; both for client work and within their organization.
How to pull data into your environment using APIs and web scraping
How to clean the data using Pandas and Jupyter Notebook
How to turn the data into interactive visualizations
How to analyze this information to come to real world conclusions about your project or organization
I’m JD and I have mental illness. I’m also not alone. Every year, roughly 20% of the US adult population deals with some form of mental illness, however that number is MUCH higher in the tech community.
In this talk I tell my story of how I came to terms with the fact that I have mental illnesses, and how I came to realize that I’m not alone. Within my story, I tell how I came to realize I needed help, how I found help, what treatments worked for me, and how I came to be active in OSMI (Open Sourcing Mental Illness) with a mission of Erasing the Stigma that surrounds mental illness.
Attendees will walk away from this session with knowledge of resources that are available, statistics that have been collected, and hopefully a new view on mental illness that helps them Erase the Stigma from their own point of view.