Most of the time, WordPress Hooks give us everything we need to make these modifications, but sometimes the way a plugin chooses to hook into actions or filters makes it difficult to modify.

Consider, for example, a plugin that hooks into an action or filter using an instance method. In an attempt to avoid polluting the global scope, the plugin’s author might instantiate the object in a function. In this case, the object instance isn’t accessible to other code, and therefore, we can’t unhook it or otherwise work with that object instance.

To address this issue, we created a small library that we’re calling Captain Hook, which allows us to remove otherwise-inaccessible action/filter callbacks, and even hijack private object instances. Here’s an example of how it works:

class Plugin {
  public function __construct( public string $name ) {
    add_action( 'wp_footer', [ $this, 'wp_footer' ], PHP_INT_MAX );
  }

  public function wp_footer() {
    echo '<p>' . esc_html( "Powered by {$this->name}" ) . '</p>';
  }
}

add_action( 'after_setup_theme', function() {
  new Plugin( 'Super Plugin Pro' );
);

In this example, if we wanted to remove the wp_footer action callback, WordPress doesn’t have a built-in way to do that. Captain Hook makes it possible:

\Alley\WP\remove_action_by_force(
  'wp_footer',
  [ Plugin::class, 'wp_footer' ],
  PHP_INT_MAX
);

This works similarly to unhooking a static method, where you pass the class name and method. The remove_action_by_force function will find the callback where the object’s classname and method name match and remove that callback.

Instead of removing the callback, we can reprioritize it, if we want something else to be able to run before it. Here we move it from a very high priority down to 10:

\Alley\WP\reprioritize_action(
  'wp_footer',
  [ Plugin::class, 'wp_footer' ],
  PHP_INT_MAX,
  10
);

Lastly, we can also hijack the object instance and modify that instance:

$plugin = Alley\WP\get_hooked_object(
  'wp_footer',
  [ Plugin::class, 'wp_footer' ],
  PHP_INT_MAX
);
$plugin->name = 'WordPress';

We hope Captain Hook can make your WordPress development a little easier. If you give it a try, reach out to us on Twitter X or LinkedIn and let us know what you think!

The post Introducing Captain Hook for WordPress appeared first on Alley.

State of Enterprise WordPress 2023, set to be published later this year, will provide a current snapshot of the pros and cons of the platform according to the growing number of global brands that use it. As well as focusing on key areas such as budgets, publishing processes, and custom functionality, the report will also highlight why they chose it, how they’ve extended it, and what improvements they’d like to see over the longer term. 

It is anticipated that the report will not only give the broader WordPress community a stronger understanding of the needs and requirements of enterprise organisations, but could also shape future features and platform updates.

To gather insights for State of Enterprise WordPress 2023, we’re asking enterprise organizations that use WordPress – or those with an enterprise-level solution – to share their experience and opinions in a short survey. All collected data is completely confidential and will be aggregated and anonymized for the report, which will be freely available once published.

To have your say, head over to: soewp.com

The post Enterprise WordPress uncovered: share your experience appeared first on Alley.

We were happy to join this conversation and help people understand how WordPress has helped some of the biggest brands on the planet simplify their publishing workflow and lower their total cost of ownership for their websites.

The guide is now available to download. Thanks to our colleagues at Big Bite for organizing this effort.

If you would like to chat with us further about your enterprise publishing needs, we will be at both ONA 23 and WordCamp US this week or reach out to us directly.

The post WordPress for Enterprise: Insider insights for big brands and publishers appeared first on Alley.

When it comes to developing in WordPress, there’s an advantage: WordPress allows developers to customize core blocks, which could be anything from a minor change of the front-end design to a complete overhaul. Customizing core blocks can save hours— even days —of development time, especially if the desired feature is just a slight variation from core. At the outset, however, it can be hard to tell just how different your new feature will be.

Weighing your options

As a developer, building blocks from scratch can become a default pathway. But the truth is, there are benefits to customization too — and in the interest of efficiency, developers should weigh the benefits of each approach.

Recently, a client asked our team to implement a gallery feature with a lightbox and a carousel for their image displays. When initially scoping the project we knew we had two main choices: create a custom gallery block, which would duplicate all the effort of integrating with the media library, or limit the customizations to the rendering of the block and add a toggle to swap between the two views. In our case, we chose the latter.

It doesn’t always go according to plan

Originally, we chose the core block customization path for the lightbox gallery because it allowed us to complete the development in a fraction of the time compared to creating a custom block. We were able to demo a functionally complete version of this feature to the client within a week.

What we had yet to anticipate, however, was a follow-up request asking if we could change the way the block appeared in the editor. Specifically, they wanted it to appear the same way as it did on the front end, which meant we would need to incorporate the same structural changes in the editor as we did on the render function.

While implementing this additional request, it quickly became apparent that we were creating a brand new editorial view for the core block, which meant reimplementing many of the features from scratch. At this point, we needed to reassess our decision to customize the core gallery block.

Customize or create? Choosing your solution

In many software development projects, there comes a time when developers need to decide if they should start fresh or continue on the current path when new challenges surface. In this particular lightbox gallery case, we faced a choice: start over with a new block, or customize an existing core block. 

We find the following questions help create a map to navigate these situations:

1. What experience is your user looking for?

As with any product or feature build, figuring out whether to customize a core block or create a block from scratch comes down to the desired user experience.

In our case, the client wanted a low-effort experience for their editing team. Specifically, they wanted to be able to use the existing gallery feature and toggle a lightbox view on or off on the front end as needed. They also didn’t want to have to recreate galleries to swap between the gallery views, which was a concern given WordPress gallery images are only stored at the block level as InnerBlocks. Given these requirements, it made sense for us to lean on the existing core block and restrict our changes to modifying the front-end design.

2. Is there a core block that gets you 90% of the way there?

When deciding on a path to take for your feature, start by asking yourself what the primary goal is. There are a number of core blocks that go unused; do any of them get you most of the way to your desired feature?

In our case, the answer was clearly yes. Our client was requesting a lightbox gallery that performed exactly like the core gallery, but on the front end, it would present as a lightbox carousel. The existing gallery got us 90% of the way there. We were able to lean on the functionality of the existing gallery block, which restricted our customizations to front-end markup and style changes. Is there a block that can do the same for you? 

3. Would customizations to a core block be functional or visual? Is it primarily in the back-end or the front-end?

If you’re lucky, the changes you need to make to the core block might be limited to styling. In that case, your customization may be as small as adding a class to the block and updating a stylesheet. In our situation, we had to filter the rendering of the gallery block to generate our own markup. However, even that was much simpler than creating a custom block from scratch.

We had to add a SlotFill to the block to allow switching, which meant filtering the block in the editor, but we expected the gallery experience to functionally remain the same in the editor as it had always been.

Ultimately that wasn’t the case, given the decision to modify the editor’s view, but that leads me to my last point.

Core block customizations can (practically) become custom blocks

The lightbox gallery effectively acts as a custom block that uses a block variant and a custom edit component. A block variant, or block variation, is an alias for a defined block that allows us to pre-configure attributes. In our case, we were able to create a block variant with the alias of lightbox gallery that pre-configured the lightbox attribute to active.

In lightbox mode, it uses existing attributes from the core gallery block — but it doesn’t use all of them. When not in lightbox mode, it looks and acts exactly as it would without any modifications. When using the lightbox gallery block variant an additional, hidden, attribute is configured that, when set, disables the ability to toggle the lightbox mode off.

This approach allowed us to maintain the customization for the user experience, and effectively offer two blocks to toggle between, which protects our customizations in the event the core block changes. We also incorporated a block variant that forces the lightbox effect on and disables the ability to toggle it off. This way, we have the best of both worlds. Editors can convert existing galleries to lightbox galleries without having to rebuild them, and anywhere a lightbox gallery is specifically required, editors can disable the ability to toggle off the lightbox view by using the lightbox gallery block variation.

If we were to remove our code today, all the existing lightbox galleries would automatically revert to core galleries, essentially leaving the core code unaffected, just as a custom block would. 

The core issue

The decision to customize core blocks or create custom blocks in WordPress depends on various factors such as time, resources, user experience goals, and the extent of required modifications. While building from scratch allows developers to have more control and showcase their skills, customizing core blocks can save time and effort when the desired result is a slight variation of an existing core feature.

However, it’s essential to consider potential risks, challenges, and future compatibility issues associated with customizing core blocks. By carefully evaluating the user experience objectives and utilizing block variants and custom components, developers can strike a balance between leveraging existing solutions and implementing innovative features, ultimately leading to efficient development processes and satisfying user experiences.

Want to learn more about how Alley approaches custom solutions? Check out our work.

The post Customize or create? Core thoughts on core blocks appeared first on Alley.

When evaluating a plugin that you’ll potentially use on a site, there are a number of things you want to keep in mind. The most important are security, performance and scalability, customization, and maintainability.

Performance and Scalability

There is a widely believed myth in the WordPress ecosystem that the number of plugins installed on your site will hinder performance. This isn’t quite correct; 1,000 small, performant plugins won’t impact your site as much as one plugin that has issues. When dealing with large and high-traffic sites, any change in performance will be multiplied quite a few times over. A personal blog with a few hundred visitors taking an extra half second to load isn’t that big of a deal, but if you have a million visitors each month, you’re now looking at over five days of loading across those visits!

Front-end versus back-end loading

There are two things to consider when evaluating plugin performance — which assets get loaded on the front end and what happens on the back end. Quite a few plugins will bundle their own scripts and styles, sometimes loading them on every page. This process adds extra requests for each visitor. (And some plugins will do this whether or not the asset is even necessary!) Extra requests aren’t the worst thing (especially when they’re minified and cached), but it’s worth taking the time to see if you can disable that loading and move the needed styles into the existing stylesheets that you’re loading.

Pro tip: You can use tools like Pingdom, GTMetrix, and Google Lighthouse to evaluate the front-end speed or Query Monitor and New Relic for the back end. This way, you can assess page speed and performance on your site both with and without the plugin.

Database reads and database writes

Your website performance will also be affected by database reads (which retrieve stored information) and database writes (which update or add information). 

Database reads 

Ideally, you want a plugin that interacts efficiently with the database. While auditing the code, take note of any WP_Query calls. Anytime something gets read from the database, there should be limits on it. Grabbing all the posts on the site and looping through them will be fine on a brand-new site with little content, but as your site grows, that query’s performance will suffer dramatically.

There are some arguments that can be passed to WP_Query in WordPress to improve query performance. If you see any of them in use, the plugin developer is probably trying to query the database efficiently:

• fields: By specifying only the fields you need, you can reduce the amount of data retrieved from the database, leading to improved performance. For example, fields => ids retrieves only post IDs, fields => [id, post_title] retrieves post IDs and the post title, and fields => all retrieves all fields (default behavior).
• posts_per_page: This argument allows you to limit the number of posts retrieved. By specifying an appropriate value based on your requirements, you can reduce the database load and improve query performance.
• no_found_rows: By default, WordPress performs an additional query to calculate the total number of found posts. If you don’t need the total count, setting no_found_rows => true can avoid this extra query and improve performance.

Sometimes large or inefficient database reads are unavoidable. In those cases, the results should be cached so that the slow query doesn’t have to be run as often.

Database writes

Any plugin that writes to the database often (especially from the front end of the site) will quickly cause a strain. Database writes from the front end can cause the page to take longer to display. These delays will compound with more traffic. On high-traffic sites, database writes could also happen multiple times because another session thinks the update has not happened yet. Database writes should happen in the admin dashboard where there is less traffic, or via the WP-CLI command line utility. Database writes from the WP-Cron scheduling system may be okay if your hosting platform has implemented a server-side solution for running these scheduled tasks. If not, the previous issues with delays and multiple writes could apply.

Making sure your plugins can scale

Scalability goes hand-in-hand with performance. As your site grows in size and traffic, small issues will multiply, so building a highly performant and efficient site from the beginning is key. In addition to examining front-end assets, ask yourself the following:

• Will the plugin continue to work well as your site grows in size and traffic?
• What are the potential bottlenecks and limitations?
• Can the plugin be easily scaled across multiple sites or installations?

Another component of scalability is how many plugins you must keep updated and stay familiar with. If you use the same plugins on multiple sites, then you can gain more experience and expertise with those particular plugins — versus having to figure out a different set of plugins for every site you work with.

Customization

Similar to performance and scalability, assessing customization functionality is a key part of ensuring your plugin can continue to meet your needs as your site evolves. 

• Does the plugin offer enough options to customize its functionality to your specific needs?
• Can you easily style the plugin to match your site’s design and branding?
• Is the plugin developer-friendly? (Can you easily extend its functionality through custom code?)

Good plugins will provide WordPress hooks, which allow you to customize how certain data is processed or add custom code when certain actions occur in the plugin. A good example of this are the Action and Filter Hooks available on our Publish to Apple News plugin. These filters allow you to customize all aspects of the article before it’s sent to Apple News, to perform additional actions when certain conditions are met, or to display additional content in the admin interface.

Maintainability

Like any good software, plugins need to be maintained. Look for plugins that are updated and supported regularly with well-written, highly-transferable code. Making sure your site is equipped with well-maintained code will allow you to make modifications and improvements over time more seamlessly. 

When evaluating plugins to meet a specific need, prioritize smaller, focused plugins over ones that seem to do everything. A complex plugin with many features will have many potential attack surfaces. If 90% of a plugin contains features you don’t need, you’re better off extracting that 10% you do need and using it as a base to build a new one.

If you find an issue with a plugin, check the plugin documentation to see if the plugin authors are open to pull requests to fix issues or add enhancements. If they are, you can make your changes available to all users of the plugin. This is one of the great things about open-source software.

If the authors aren’t open to pull requests, but the software is open-source, don’t be afraid to fork the plugin! Using an existing plugin as a starting point for customizations and modifications gives you a great head start compared to writing one from scratch. If you do plan to write it from scratch, you can still use the codebase for reference and inspiration.

Security

When it comes to website security, ensuring that all installed plugins are secure should be a top priority. Given the popularity of WordPress and its widespread use, it’s important to recognize that the more high-profile the site, the greater the likelihood of being targeted. Therefore, utilizing tools such as PHPCS, WordPress VIP coding standards, PHPStan, and linting can be helpful in identifying any potential vulnerabilities in a plugin. Additionally, it’s crucial to evaluate how often the plugin is updated and how responsive the developers are to security concerns. Even if a plugin has had past security issues, timely and thorough patching can indicate a responsible approach to security. In general, it’s best to opt for plugins that are frequently updated and prioritize security concerns rather than those that don’t. 

Plug in to what works for you 

Creating a website is not a one-time task; it requires continuous updates and improvements. In assessing the specific needs of your site, you can compare and contrast a variety of plugins (or potentially fork plugins to suit your particular objectives) — all without causing waste or compromising site performance or security. Plugins play a crucial role in the long-term (and short-term!) efficacy of your site, so evaluating them carefully at the forefront will help ensure a successful implementation that will serve your site for years to come.

The post Evaluating WordPress plugins: Key considerations for strategic selection and implementation appeared first on Alley.

When you’re trained to architect solutions to problems, the off-switch doesn’t always come naturally. It’s only one small step from looking at a software challenge or existing product to concluding: “That’s not the approach I would’ve taken. I could do better. And here’s how.” This insight is not necessarily bad on its own. However, when it becomes less of a thought experiment and more of an actual experiment — you’re paying an opportunity cost. Seemingly, only direct experience (seeing custom approaches succeed or fail) over time will stay your hand from succumbing to your own college try. Often the “senior” developer has to start rattling off the graveyard of abandoned frameworks, deprecated libraries, or scrapped internal projects that nearly every company has in order to remind you of the pragmatism of using what works.

We at Alley have our fair share of internal tools that we’ve created or reinvented, but we exercise restraint and feel strongly that these were pragmatic decisions. To wit: we’ve narrowly avoided recreating our own version of Jira, but we often consider it. So what does Alley consider pragmatic to build for ourselves, and why?

Hermes: Our intranet and middleware between several SaaS products

Yo dawg, I heard you like SaaS, so I put some SaaS in your SaaS.

This fell into the category of too helpful not to make and too custom to use a pre-existing tool. We use many products that have their own sources of data — Hubspot, Jira, BambooHR, Google Workspace, GitHub, and our chatbot — Alleybot, to name a few.

Hermes performs a multitude of functions for us and serves as a home base for many different processes. It’s a single interface that rolls up performance against Agile OKRs (we use Scrum at Alley) and forecasting, customized just the way we like it. It provides a self-service option for clients to see progress on certain projects. And so much more.

Like many in-house projects, it started as an excuse to learn a framework while solving a business need. From there, it was a short leap to internal dogfooding other use cases. While it might serve partially as a pressure release valve for the “change we want to see” (usually data visualization and collaboration) from our SaaS vendors, somewhere along the road, Hermes became indispensable.

Broadway: Our local development environment

I don’t always fork VVV, but when I do…

Alley’s local development environment (nicknamed Broadway) is our secret sauce for making amazing client projects. It probably has enough customization (particularly in its client package management systems) to justify its existence, but if we’re honest: it’s custom because, like our editor configurations or favored terminal client… we’re artists, it’s our palette, and it’s kinda personal.

Alleybot: Our heavily customized Hubot (Slackbot) for flair

“Must have taken forever to build.”
“No, not too bad. About 70 hours. Which isn’t bad, considering I carved it all by hand from one piece of wood.” 

Kevin Rawley (Owen Wilson), Meet the Parents

Alleybot and its associated hijinks serve both our workflows and our culture. One piece of the functionality has been open-sourced for the good of humankind – an easy way to view and claim code review tasks in Slack — but most of Alleybot’s functionality (and snark) is geared toward our specific style of work, and we’d be ill-advised to share it without regard for other workflows. If you’re looking for a less opinionated version to share with the world, check out our Slack App Helperbot. For now, Alleybot only talks to us.

Open-Sourcing Internal Tools

All of the examples above are closed-source (private) repositories, but how do we decide what constitutes our secret recipe and what might be valuable to the greater community? What’s the difference between some of our “invented here” projects that are open-source (say Mantle or Fieldmanager) and the above? Well, for one thing, they managed to pass the following smell test, but for another: their application became so essential to various projects’ success that we knew others would find them useful.

Here are some questions that we ask ourselves to avoid succumbing to Not Invented Here Syndrome:

• Would the subjective benefits (fun, learning, community enrichment, marketing, etc.) outweigh the objective costs? What’s good for a hackathon may not be great for the bottom line. Don’t eliminate hackathons, but consider forcing projects to stand on their own for a bit. Time has a great way of proving viability.
• Is the approach not merely novel, but objectively better? Is it more efficient, more secure, provide core functionality, etc? Can you prove it? Work to document the “why” of your project.
• Can it fail? Who else has a solution to this problem? Can we use their tested model? What’s the backup plan? You’re currently living without your novel implementation, what happens if you are forced to continue doing so? Does the world need another react boilerplate?
• Are you thinking rationally about your supply chain, or merely looking for control or prestige? Draw a line in the sand for your supply chain or service inputs and outputs. Not every engineering shop needs their own container stack, custom CI/CD pipeline, hosting solution, cloud, lobbyists, etc. 
• How does this fit into your business model, or can it upend it? View your solution through different perspectives. Would a consumer buy it? Would a competitor fork it? Would your staff actually use it? Does it make fiscal sense: can you produce a better product for less money to a greater audience? What’s the opportunity cost to your current mission, and are you as passionate about this as your current core competency?

Alley has several internal tools and utilities that we believe make us better at delivering our core services; experience has also allowed us to humbly resist rebuilding several mission-critical applications in the name of “doing it the right way.” We make light of it, but Not Invented Here Syndrome can be a real drag on the opportunity cost of your business’s mission. Reinventing the wheel can divert resources from projects that could dramatically improve life for you, your clients, and your users. Take the time to make sure you’re working on the right things!

If you ever need some advice on figuring out what you should be working on (or need help working on them) — reach out! We’re always here to chat.

P.S.: If reading this didn’t stay your hand, perhaps your business’s Hedgehog Concept isn’t what you thought it was. Maybe it’s time to break out that breadboard, install that new framework, fork that repository…. And PIVOT!

“They want to be the agents, not the victims, of history. They identify with God’s power and believe they are godlike. That is their basic madness.”

Philip K. Dick, The Man in the High Castle

The post “Not Invented Here Syndrome” and how to prevent it appeared first on Alley.

A lot has changed since the new block editor (codenamed Gutenberg) was launched with WordPress 5.0 in December of 2018. Building custom blocks is now easier than ever, thanks to three key enhancements that were introduced over the last two years:

1. block.json

WordPress now lets you describe your custom block using a special JSON schema. By specifying the configuration of your block in a JSON file, you can register the block for both the editor (in JavaScript) and the server (in PHP) while only maintaining one configuration file for block settings and attributes. Furthermore, there is a new helper function that registers a block simply by passing in the path to a block.json file, allowing you to write code that scans a directory for blocks and automatically registers them, thereby cutting down on the amount of developer time needed to add a new block to a site.

2. wp-scripts

The WordPress Scripts package is “a collection of reusable scripts tailored for WordPress development.” What that means in practice is that developers can install the @wordpress/scripts package and get a build system and linter without needing to maintain their own configurations for Webpack, TypeScript, Babel, ESLint, Stylelint, and a host of other technologies. This means that developers can focus on building new blocks rather than maintaining toolchains, and any bugfixes or updates to the toolchain can be obtained simply by applying the new version to a project.

3. create-block

The WordPress Create Block package was recently updated so that it can be used to create a new block inside of an existing plugin, rather than expecting each block to have its own plugin with its own set of dependencies. On the sites that Alley builds, which routinely involve several dozen custom blocks to support our designs and editorial workflow, it’s not practical to have each block live within its own plugin. The @wordpress/create-block package can be used to create a new plugin that comes preconfigured with wp-scripts, and can then be subsequently used to create new blocks within that plugin.

The confluence of these technology changes means that it is possible to create new blocks in a matter of minutes rather than hours.

Using the create WordPress plugin 

Alley has put together a template repository on GitHub that leverages these technologies called Create WordPress Plugin. In addition to the technologies above, this freely available open-source template repository includes the following features:

• Continuous integration via GitHub Actions
• Unit tests powered by Mantle
• Autoloaded PHP files via Composer WordPress Autoloader
• A helper script for running create-block
• Extensions to wp-scripts to make it easier to add Slotfills and custom entries
• JavaScript linting provided by Alley’s extensions to the Airbnb standard
• JavaScript unit testing using Jest
• Full TypeScript support

Keeping technical debt at bay

Using these tools has made it easier to both create new blocks and keep our toolchains up to date. The new method of building blocks using block.json also results in being able to co-locate scripts and styles with block definitions and front-end output, which helps with code organization and ensures that we are only loading assets on the front-end when necessary. This new method of building features using the block editor has improved the developer experience while reducing the amount of time it takes for us to deliver enhancements to the editorial and user experience.

This post is a modified version of a talk that I gave at the WordPress Boston Meetup on April 24, 2023.

Looking for more ways to increase productivity? Check out the benefits of pair coding.

The post Three WordPress enhancements to streamline your custom block development appeared first on Alley.

However, using Slack as a synchronous communication tool has plenty of downsides. Slack can be a source of constant interruption and context switching. It can feel like an all-day meeting. It can build unnecessary stress, a sense of implied urgency, an ASAP culture, and an implied 24/7 availability. Worst of all, it can promote shallow work. With one eye always on Slack, tasks are completed half-distractedly. Work is organized around not just meetings, but also around the rabbit holes of Slack!

Managing expectations

At Alley, we aim to set expectations around using Slack as an asynchronous tool, where teammates exercise autonomy in when and how they address issues brought to them in Slack. That way, deep work becomes the default and team members can more easily achieve a flow state in which to work. Aside from deep work, communication itself can be improved when moving toward a more asynchronous culture. It can lead to higher quality, more thoughtful, and better-written responses in Slack (and, therefore, better documentation as well). And, of course, it fosters time zone equity which is especially important to Alley as a fully-remote company with team members all over the world.

Assessing your team’s needs

At Alley, we seek to take an evidence-based approach in everything we do. So when we set out to improve our Slack culture, we started by gathering information at the source: our team. We conducted a session focused on reaping the benefits of Slack while promoting a more asynchronous culture of communication.

Creating a Slack detox plan

After discussing the various pros and cons of Slack, we invited participants to come up with a “Slack Detox Plan.” At the beginning of the exercise, participants were given the following directions:

1. Write down what you like most about Slack.
2. Write down your biggest struggles with Slack.
3. Outline steps you can take to keep what you like in Slack, while shedding what you don’t. (Can you live without desktop notifications? Probably yes!)
4. Commit to these steps for a two-week detox! 

Retrospecting the results

At the end of the two weeks we held a Retrospective, where we discussed the different strategies our team used during their detox, the benefits and drawbacks, and how we could adopt these strategies in the long term.

The ensuing conversation was thoughtful — surfacing many suggestions, tips, and tricks around improving our culture around Slack. Many reactions and responses fell along the lines of “I didn’t know I could do that!” or “I didn’t know we were allowed to do that.” The exercise confirmed that creating space for this “Slack Detox” had true value. 

Strategies for Slack detoxing

• Set team norms: Establish that it’s okay to be unavailable for periods of time to promote focus and flow states on work in progress.  
• Overcommunicate: When you do ping, include all pertinent information and context to ensure your request is clear and detailed. Don’t forget screenshots and links (if applicable), and a deadline.
• Plan ahead: Give people time to respond to your message. Don’t always expect an immediate response.
• Triage: Limit “urgent” requests for true emergencies.
• Compartmentalize your tools: Use alternative tools (like project management systems) to engage in less immediate discussion around important topics.
• Create specialized channels: Establish a dedicated emergency channel for your team.
• Opt out: Leave channels where you’re no longer active. (Use your judgment and when in doubt, consult with your team first).
• Hit the snooze: Mute channels where you’re not active on a daily basis.
• Manage your notifications: Disable desktop notifications during focus time, at night, and perhaps even all the time – provided this does not become an impediment to you or your team.
• Make the most of your settings: Use the “Show Activity” feature to never miss a direct message or mention when “backscrolling” (catching up on the conversation from when you were away).
• Set reminders: Use Slackbot’s built-in reminders such as “Add to saved items,” “Remind me about this,” or “Mark as unread” so you can return to them when you’re ready. 
• Update your status: Inform others when you’re heads down, on a call, or otherwise in or out of commission.
• Mind your mentions: Use @here or @channel sparingly (if at all) and be mindful of your @mentions in general.

At Alley, we want our teams to feel empowered to make Slack work for them, not the other way around. Moving forward, we’re working on – individually and team-wide – further ways to use Slack as a tool and not as a place to live. We’re making sure we communicate asynchronously whenever possible, both being patient when awaiting responses, and being self-aware when replying.

Looking for more ways to manage expectations and increase team productivity? Check out these ideas for setting boundaries when working from home.

The post Promoting asynchronous communication in Slack appeared first on Alley.

Building a brand is a lot like building a reputation — it’s important to lay a strong foundation, but ultimately, you build it one interaction at a time. One thing that connects all these components is language. 

When I say language, I’m not referring to a native tongue or offering multiple translations (although this can be a crucial part of your practice). I’m talking about your choice of words. What you say, how you say it, and who you say it to. In the race to create content and increase engagement, we often forget to assess (and reassess) the language across our messaging to ensure it aligns with our brand and editorial strategy. 

Defining your messaging: Create a source of truth

No matter the size of your organization, maintaining cohesive language is full of hurdles: shifting priorities, multiple contributors, and topic overload, to name a few. Developing a style guide can go a long way in fostering consistency. 

What is a style guide?

A style guide is a source of truth for brand elements and content across your organization. From how and where your logo should be used to how you cover particular topics, a style guide empowers your team to represent your brand confidently and accurately. You can even outline your approach to various audiences, specific products, or channel-specific messaging (such as email versus social media). 

How do you make a style guide? 

There are many ways to create a style guide. You can opt for a simple Word document with general guidance or a robust manual with lots of detail. Depending on the amount of content you produce, how widely your logo is used, or how often you participate in public speaking engagements, your guidelines should address those needs accordingly. 

A style guide should evolve over time (just like your company does), so make sure the format you choose supports ongoing updates. For example, a PDF or a hard-coded landing page might dissuade edits, which will keep your document frozen in time.  

Why should you have one?

Aside from defining and unifying your message, establishing a source of truth allows you to set the tone for nuanced subjects. Engaging your leadership team proactively helps protect your brand from inaccurate interpretations across teams that might be dealing with competing priorities or varying degrees of expertise. 

We all know that language is a powerful tool. Our Director of Agile, John Ragozzine, elaborates on some of the ways outdated and problematic language pervade our industry and how simple changes in our word choices (such as swapping the term “master” for “main” in GitHub’s platform) communicate progress in how we regard marginalized communities. A style guide can capture these shifts and help forge new habits at a company-wide level.

Communication is key

Once your guidelines are set, you’ll need to roll it out to your team. Don’t be afraid to overcommunicate! Make sure your style guide is easily accessible — preferably in a live format where updates will be reflected in real time. Don’t forget to incorporate your style guide into onboarding and training materials for new team members.

Conducting a content audit

With your style guide in place, it’s time to cull your existing public-facing materials for out-of-date messaging. Auditing your organization’s content might sound like a daunting task — and it can be — but prioritization is key. You probably don’t need to revise every single piece your team has ever produced, but your audit should cover all the various groupings and categories your content encompasses. Approaching the content by group will allow you to assess the messaging at a macro level and the content architecture itself. 

Pick out your content essentials 

Foundational content (such as your website’s main navigation pages: home, about, team, etc.) and other high-traffic materials (such as product content or any pieces you promote regularly) should be revised to meet your brand guidelines and reviewed periodically to ensure they’re always relevant and accurate. Meanwhile, you can update regular blog content over time or as needed (for example, when you decide to recirculate or promote it). 

Get organized 

Have a tracking system in place. You can use a specialized tool, like a project management system, but personally, I love a good old-fashioned spreadsheet. Start by organizing your content according to its current architecture to determine if it supports an intuitive user experience. Your tracking system should account for where the content currently lives, where it needs to move, and any page-specific updates, such as revised calls to action (CTAs), messaging, or imagery. 

Delete or revise any content that no longer serves your strategy. This doesn’t mean that anything slightly out of date needs an overhaul, but aimless content without a clear purpose only serves to distract your audience from quality content. 

Keeping your strategy in place

When initiatives are new and shiny, we often nurture them into existence only to see them fall apart after a few months. A robust content governance process will insulate your program from deterioration as new priorities arise, team composition changes, and focus shifts.

Consider how often different materials will need to be reviewed and set recurring reminders for periodic audits. You’ll also want to define a process by which your internal documentation (like your style guide) gets updated in accordance with company-wide changes. Don’t forget to account for how these changes should trigger updates on your content essentials. 

The big picture

Organizations are so much more than the sum of their parts — and language is a critical component in shaping your brand. Taking the time and energy to refine the details and build them into a sustainable editorial strategy puts the power of language on your side to ensure you’re representing your brand thoughtfully and intentionally. 

Does your content management system (CMS) support your editorial strategy? Learn how Alley helps clients evaluate and improve their editorial workflow.

The post Beyond the logo: Tools to define your brand and editorial messaging appeared first on Alley.

What does education have to do with DEIA? 

The DEIA realm is not a static one. Not only is education one of five key areas where we focus our (DEIA) efforts, it’s weaved throughout all of them. Staying up-to-date on best practices, new language guidance, and the evolving needs across diverse communities are all foundational to building (and maintaining) an impactful DEIA program.   

Taking actionable steps

Setting goals and taking clear, actionable steps helps us uphold our values of quality, transparency, and accountability in everything we do — including our DEIA initiatives. To that end, we’ve outlined some specific goals around DEIA education and the steps we’ve taken to ensure a mindful and evolving approach to DEIA at Alley.

Our Goals

• Provide resources and opportunities for all Alley team members to engage in DEIA education.
• Ingrain ongoing DEIA research and education into Alley’s training, governance, language guides, and culture at large.

Steps we’ve taken

• Ensured all Alley team members complete anti-harassment and anti-discrimination training during onboarding and on a recurring annual basis. (Q2 2019) 
• Established periodic learning sessions in Alley’s DEIA Working Group where we distributed and discussed reading materials and protocols around DEIA-related issues including systemic racism, current events, bias in tech, and disabilities in the workplace. (Q2 2020)
• Completed unconscious bias training for all leadership, including those involved in hiring. (Q4 2020)
• Participated in How to Be(come) an Anti-Racist training for all team members. (Q4 2020)
• Organized a 21-Day Equity Challenge, the first Alley-wide learning opportunity led by the DEIA Working Group. (Q1 2021)

What the future holds

Diversity, equity, inclusion, and accessibility are dynamic and complex matters, and making meaningful progress requires ongoing attention and education. At Alley, we will continue to seek out resources and turn to leaders in the DEIA space to ensure that our approach is in line with the needs of historically marginalized groups such as women, BIPOC, 2SLGBTQIA+ people, and people with disabilities. We aim to expand the reach of our DEIA working group and continue to participate in regular learning sessions and company-wide equity challenges that keep our team aware of and engaged with our DEIA program.  

The post Education & DEIA: Maintaining an evidence-based DEIA program appeared first on Alley.