Contributing to Gutenberg

I realized how important WordPress’ Gutenberg project would be as soon as I saw it. Internet publishing has been in a weird place from an authoring and design standpoint for some time; the penetration of mobile devices fundamentally broke the WYSIWYG document model, and WordPress needed to modernize to meet the publishing experiences of modern platforms like Medium and Squarespace.

As a part of WordPress’ Accessibility Team, I contributed my expertise in user experience, user interface design, and accessibility.

Document Flow

Gutenberg breaks individual pieces of content into blocks. This decision had some advantages and disadvantages, but ultimately, it makes the editor feel heavy and clunky. Asserting content as blocks was a reflection of the system, not the content people are building. As early as version 2.6, I proposed reducing the amount of block interface overhead by keeping text-like content as one cohesive piece of content, as demonstrated:

A wireframe showing how Gutenberg treats every piece of content as blocks, with a proposal to treat consecutive text items as one cohesive block.

There are two distinct advantages to this approach. First, it maps to the majority of document editing experiences that many users have. It’s familiar, and you don’t need to know that two separate paragraphs are actually blocks. Second, by grouping similar content together, the amount of UI overhead is reduced.

By reducing the amount of overhead and staying predictable with text editing, the design also supports established accessibility norms for screenreaders and relays less meta information to those that are using assistive technologies.

One side effect is that this model also forces content creators to work within the Gutenberg model of document publishing. Speaking from my own workflow, I tend to outline posts using levels of bulleted lists before expanding those thoughts into full paragraphs. It’s how I prototype content quickly. It works in Word, Apple Notes, WordPress’ Classic Editor, and almost every other document editor that I’ve encountered. To replicate that here, I’d have to create a bulleted list type, copy each bullet, paste it into a paragraph block type, and then format from there. I have adequate fine motor skills (and patience), but this would be a tremendous challenge for users of assistive devices.


My goal for contributing to Gutenberg’s interface design was to focus on creating and publishing content in a way that was simple, direct, and pleasant to use. In content editing, I think it’s important to keep the publisher close to the content that they’re creating, i.e., manipulating words and media directly and not diving into submenus and other non-direct editing contexts. Where this went wrong, in my opinion, is the interface surrounding (literally) blocks and the focus on blocks instead of content.

As previously mentioned, everything is a block and each block has a significant amount of interface that is associated with it:

There are icons on the perimeter, icons on hover, icons that are shown but grayed out. The massive amount of UI is taxing on sighted users, and all of this interface needs to be made available to assistive technologies as well. My primary concern was that the amount of interface takes away from the focus on content and its creation; again, we’re making content, not blocks. In the screenshot above, the content doesn’t even exist yet:

Here, the entire boundary of this block has interface elements to manipulate an object that doesn’t even exist yet. The UI should be more intentional when adding an image to do just that – add an image. Once the image is added and selected, I think there’s a better opportunity to expose more options such as linking, positioning, deleting, replacing, and so on. There just needs to be some consideration for context.

My comment on an issue in GitHub discussing UI in Gutenberg

Another interesting case of too much UI came up with embedding external content. There are any amount of external sources that you may add to a post (Twitter, Instagram, RSS, etc). My recommendation was to have a single Embed block type that took some information and made the embed for you:

A wireframe showing a possible alternative embed content block type in Gutenberg.

Alternatively, pasting in a link anywhere within the document editor should try to convert it to its embedded content type. Other services do this, and it requires much less to execute.

Another example of the focus on blocks instead of content:

Two highlighted paragraph boxes in the Gutenberg editor.

When selecting text between two paragraphs, you don’t select from text boundary to text boundary. Instead, you select the two blocks in their entirety. This is a unique and unprecedented behavior.

Here’s a Twitter thread with some of my compiled thoughts about NUX, the interface, and overall user experience within Gutenberg.


A lot has been written about the shortcomings of Gutenberg as an accessible product, ranging from the technical aspects of its design to product management in open source to WordPress’ community governance.

I can offer this summation. Technically, Gutenberg will most likely check the boxes of WCAG 2.1/AA. Automattic and community developers spent a lot of time ensuring their submissions had ARIA labels, semantic HTML, and other technical a11y considerations. But, the challenges with Gutenberg’s accessibility were deep in the product design, and no amount of ARIA or WCAG alerts could relay why Gutenberg isn’t pleasant to work with outside of a mouse/keyboard experience. For that, you would need to turn to usability tests and benchmarks against other editing experiences.

The accessibility challenges are, in my view, the same issues that impact the sighted experience but much less difficult to ignore. For example, tabbing through the block interface means you have to enter/exit each block of content; with a post such as the one you are reading, that’s a large number of elements to navigate. Then, you have to enter the block to begin editing, at which point the large amount of UI controls are announced to you.

One of the goals of the project was to make content publishing easier. That’s a big problem to solve, but in this case, research needed to be done to understand how content publishing is conducted across different technologies and contexts. Valuing and understanding that information from the outset would have resulted in a vastly different (and much more accessible) product.

Making content creation better with Gutenberg

I think it’s safe to say that Gutenberg has been a fairly controversial product. There has been plenty of friction and anxiety surrounding one of the biggest fundamental changes to WordPress, and as the release nears, those worries are starting to surface. Regardless of the technology, I think everyone understands the core need for something like Gutenberg, which is a more intuitive and modern content creation experience.

There have been plenty of disruptions in this space. I remember first using Medium and being thoroughly impressed by how it easy it was to compose and publish beautiful content. I know there have long been desires to create layout tools similar to Wix or Squarespace that achieved the same goal. Medium was able to break the WYSIWYG paradigm that so many content management systems and blogging platforms subscribe to, which mostly revolved around their broken or hacky implementation of TinyMCE.

We’ve been happy with replicating the Microsoft Word experience for a very long time. It’s a well-established creation model that is virtually ubiquitous in document creation. The challenge has always been with the translation from creation to publication; it was always tightly controlled with Word (or Notepad, or Acrobat). With the web, we were now working with CSS, and with responsive design, fluid layouts that didn’t quite map to the Word model. There was a disconnect between what was being shown in an editor versus what was being shown on an actual webpage.

To bring some predictability to content creation, the new school of thinking revolved around the concept of blocks, or segregated pieces of content that have more predictability when rescaled or moved. Gutenberg follows in the path of its competitors by breaking out of the traditional experience and introducing an editor that allows for block layouts. But somewhere in that transition, the desire to meet the technical goal missed the overall outcome, which was to make it easier to create gorgeous content.

What does intuitive actually mean?

I truly believe that everyone wants to create a product that is easy to use. It’s much more difficult, though, to articulate what that actually means. In this context, an intuitive editor should allow a content creator to produce content with as little friction as possible. To do this (and measure it), we need to consider the following:

  • What they know: a person’s previous experience using similar tools to reach this outcome impacts how they will interact with a new editor. If there are established norms and expectations of a product, those can be leveraged to reduce the time-to-outcome and control the perception of the experience.
  • The context(s) in which it will be used: how and where the content will be created throughout the entire production process, which will vary tremendously. There’s a lot of complexity to this, including the phases and milestones of content creation. For example, someone may start a draft of their content on Apple Notes before transferring it to the editor. The process for creating and publishing a static page would vary even more. While it would be impossible to map and meet every context and use case, flexibility for a number of different needs, milestones, processes, and technology would be preferred to creating a specific method or pattern to meet the outcome.

In short, upon first interaction, I would want a product to feel familiar. As a product manager, I can draw on tons of user research and testing to establish how to make a familiar experience, beyond the interface alone and into the entire experience. There are reasons that Medium, Squarespace, and Wix work, but simply copying them won’t ever put a product in a position to adapt to changing user needs. Let me be clear: I don’t think Gutenberg plagiarizes these designs, but there is definitely an influence from these products. And why not? Users love them because the product solves their problems.

I’d like to note that codifying this process will always be a challenge in open source, especially with distributed volunteers. I’m not sure what product management was done internally at Automattic, but having a lead that is armed with this information aligning development and priorities would have gone a long way in ensuring that the product focused on those outcomes. Not just the position, but having transparency and optics into design materials, research, and roadmapping would have gone a long way to ensuring that everyone who contributed was keeping user outcomes and UX in mind.

Why Gutenberg falls short in UX

Gutenberg falls short in UX because it doesn’t leverage what users know. I think it is safe to assume that there is a baseline expectation for users with regards to how we edit text across devices. When we work in something like Word, it’s a freeform document that allows us to create workflows and edit or manipulate content fairly freely. This is something that is the norm on other devices with similar content, such as the aforementioned Apple Notes. You can create a perfectly formatted and semantic document with headings, lists, and paragraph text (which, for accessibility, you totally should–that’s another blog post). Or you can draft an outline and expand from there. The lack of rigidity around the workflow allows someone to make it work for them. It doesn’t force you to create content in any particular way.

With Gutenberg, you’re creating blocks with content within them. This is your workflow. Even this simple paragraph is a block. When I try to select the text within this paragraph and the previous one, I actually select the blocks themselves, not the content within. So, because this content is forced into that pattern, what I know about simply selecting text is broken and changed. It is no longer intuitive.

Unfortunately, this pattern also has some dire unintended consequences, especially for those using assistive technologies. There are standards and norms that apply to those technologies that users expect; when the choice is made to adhere to a fairly rigid content creation process, the product risks being unintuitive or unusable if it doesn’t consider those cases. There are also edge cases such as NUI, where the interface maybe doesn’t target something like voice dictation specifically, but it should behave like other similar products. If you haven’t already, you should watch Eric Wright’s user test with Gutenberg while using Dragon.

Aside: I ran into a perfect example of this when drafting this post. I tried to create a sublist in the bulleted list above, but when I hit tab, it actually switched block focus. That’s definitely not leveraging my previous experience with lists in content editors.

Why Gutenberg falls short on interface

The decision to think blocks first and content second has led to a needlessly complex interface. Each block has a massive amount of controls that are fairly overwhelming; there are controls to position the block, change the block to another block, adjust the formatting of text within, and entire sidebar section dedicated to even more block-level options. The UI controls themselves are mostly good: they work as expected, they are responsive, and they’re mostly inline with most controls that we use on other platforms or products.

But… it’s a lot of UI noise, and in my experience, having so many controls available at once leads to them being ignored in cognition. We’re looking for simple and familiar controls, and superfluous or extraneous ones will be ignored completely. 

That’s also assuming that we are sighted users perceiving the interface visually. Going back to assistive technologies, all of these interface elements along with their various phases need to be relayed to users as well, which made for a frustrating experience when testing with VoiceOver.

How to fix it

This is a core product design issue that can be boiled down to this: you’re creating content, not blocks. The focus of Gutenberg should always support content creation, and blocks should be a tool to assist in that goal. When I add a cover to my post, I’m adding a gorgeous visual element as part of my story–not a block that contains that content.

The biggest change to improve the UI and UX would be to restore the freeform text behavior. Keyword: behavior. Paragraphs can be blocks, lists can be blocks as well, but that shouldn’t be something that a content creator needs to think about. The interface certainly shouldn’t make visually representing the block meta information a priority, which would cut through some of the excess controls. This would also make the mobile experience slightly less intimidating.

Does it create user outcomes?

If someone wants to use Gutenberg to publish, they’re going to find a way to make it work (albeit, with varying degrees of frustration). There are plenty of examples of misaligned design not getting in the way of determined users, but as an open source community, we should strive to collectively create a great product. WordPress is an incredibly important tool for social change, one that is relied upon by many groups that may not have the resources to create content on paid platforms. It’s imperative that we lower the barrier to entry for the maximum amount of users as possible, and I’m hoping that it can be improved with that goal in mind.

The Nuance of a Preflight Accessibility Audit for Gutenberg

I’ve explained my concerns and ideas for this a few times over Slack and Twitter, and now I’m taking to my blog to jot down some of my release plan concerns for Gutenberg as we approach the mid-November 2018 launch of WordPress 5.0.

First, I’m pleased that there is an intent by the elected accessibility launch lead to conduct an independent Gutenberg accessibility audit. I have two primary concerns about the process of this audit: the scope of the audit and how issues will be addressed or an action plan created for addressing them. Let’s start with the audit scope.

Accessibility Audit Scope

There are two general approaches to auditing Gutenberg. First, a block-by-block audit at the component level to ensure that individual controls are accessible. For example, the Cover Image has color controls that need to be tested and verified, both programmatically and for their experience. Second, there is an overall user experience audit that needs to be conducted that documents issues relating to the entire content creation and publishing process end to end.

The block-by-block approach is a chase-down audit to fix regressions or other accessibility issues, and I have no doubt that there will be some bugs of varying severity. My larger concern is with a more user experience-driven test, which will need relative data or context in order to be meaningful. Conducting the test from the lens of is this new experience accessible is significantly different than is this new experience creating better outcomes for everyone using it. How these tests are carried out will go a long way to the legitimacy of these tests as user research.

Personally, I think any UX accessibility test should proceed using three suites: Gutenberg, classic editor, and a third-party competitor or other content creation platform. This would give a wide range of information and data that would tell a better story of how Gutenberg performs–not just at the accessibility level, but on the overall experience for all users as well.

Action Plan for Discovered Issues

Finding issues won’t be a challenge, and it would be naive to think that Gutenberg (or any software) is going to be perfect from launch. For the sake of transparency, it’s important to detail how issues will be documented and resolved. There should be established criteria that explicitly states:

  • What the issue is
  • The severity/impact of the issue
  • Development priority of this issue
  • When it will be resolved
  • Who will be responsible for ensuring that it is resolved
  • What an accessible alternative is in the meantime

This is incredibly important for our technical leaders that have accessibility obligations under federal law (or similar) who cannot deploy software that violates accessibility standards. There should also be an amount of predictability to how these issues are handled so decision making isn’t made on an ad-hoc basis.

This process will be one deliverable adjacent to an action plan following the results of the audit. If this isn’t done, it is my fear that stakeholders (and the community) will continue to lose trust and faith in the project leadership to anticipate and mitigate these issues, particularly those that are vested in ensuring an accessible WordPress experience.

Consider the Consequences: Warning Users of Potential Hazards

WordPress offers users the ability to directly edit plugin and CSS code from the backend of their website. This is a potentially dangerous operation for new users; the slightest mistake in syntax could, potentially, cause a fatal error and make the website irrecoverable. I was brought to a four year old ticket that discussed how an interface could educate a user about the severity of the action.

The right way to do it: Themes and plugins should be edited in an offline environment that uses version control such as Git. This would allow a safety net for people. Experimentation is about failure, and in a local environment, you can fail fast and learn quickly.

UI Challenges: There are a few approaches to warning a user that are discussed in the ticket. They essentially come down to three approaches:

  1. A modal popup
  2. An interstitial page with warning information and a call-to-action to confirm
  3. A hint in the editor interface encouraging caution in these modes

The key issue with many of these is that they can be easily dismissed. The interface should also relay severity without feeling like it’s a nag. We have way too many naggy interfaces.

What kind of control can we put in place that would encourage a user to stop and consider the consequences?

The modal with input confirmation. By requiring a phrase (in this case, “I understand”), the user will need to consider some part of the warning before proceeding, avoiding the easily dismissible nature of “Ok” calls-to-action on modals.

Screenshot of mockups of a UI component requiring user input in order to proceed.
Interstitial page showing “I understand” prompt. Created in Balsamiq.

This design provides plenty of opportunity to expose the “right way” resources as well, without being too intrusive. After the user confirms the risk, they shouldn’t see this again.

Look for this design in 4.9, hopefully!

Thanks for calling, can we be best friends?

I ran across a series of tweets today.

I’d like to introduce you to user experience theater. Much like security theater and, well, security, user experience theater is when a company desperately wants to appear as if it cares at all about you. Instead of trying its best to make sure your relationship with them is great, they cook up ways to try to trick you into thinking that you are a valuable customer. Relationships are complicated, though — and there are definitely ways in which both sides can get what they need out of it.

I don’t know what issue @FilmDrunk was having, but we can make some assumptions:

  1. He had an issue with a product.
  2. It’s so bad that he’s actually had to call into the company’s phone support.
  3. That phone support has had some training on what to say to very frustrated customers who would rather do a million other things than troubleshoot an issue over the phone.

Here’s the thing: when someone contacts your company for support, your whole org chart goes out the window. Your user has a problem. They have contacted you, the provider of the product, to help them resolve their immediate issue. Your agents now have the power to change how a user feels about your company. Should both sides be respectful, understanding, and cordial? Absolutely. That should be assumed. Should that take precedence over fixing the damn problem? No. If you’re super nice but can’t help your user do what they need to do, then your user is not going to trust your company. It just isn’t enough. Trust is the foundation of a lasting relationship, and this relationship is between your user and the company.

When a company inherently cares about its customers, it is manifested in a few different ways. Training agents in forced empathy certainly isn’t one of them. Instead, work with support teams to consider context. When a user is interacting with your support team, it’s most likely because something has failed or gone wrong along the way. How your support team responds needs to factor in the user’s context; if the user is showing signs of frustration either audibly or inaudibly, then work with them quickly to try to resolve their issue. Throw your stupid “I’m so sorry to hear that you are experiencing [thing I just told you was wrong], Mr. Bertino” script out the window.

A few things that I feel are important during a support interaction of any kind:

  1. Your user should feel like the person that they are contacting is an expert that can help resolve their issue. If not, get them to someone who can (and fast).
  2. Your user should feel like you are going to do everything that you reasonably can to resolve their issue as quickly as you can.
  3. Your user should feel valued and respected.

It’s pretty simple, yet for some reason it still feels like the customer service agent wants me to be their new best friend. I don’t need your forced empathy, we aren’t going to be friends on Facebook, and I will (if you do this right) never talk to you ever again. So stop wasting my time and help me fix the problem so I can get back to doing whatever it is I need to do.

Of course, if being completely transactional goes against the fabric of your company, where you’ve determined that everyone has a personality (even your quirky front line), don’t be afraid — your agents can still have a personality. I’d even argue that they should. You should trust your agents to consider context and empathize inherently (i.e., without any type of script). But there’s a time and place for quirky and fun, and you have to trust that your agents will switch modes when working with someone who has an issue that needs to be solved immediately.

If you haven’t already, you absolutely must read MailChimp’s Voice and Tone Guide, specifically the section on failures. This guide is wonderful because it encourages a humanistic element to your communications without forcing it. It encourages communications to consider context and to change the message appropriately. Your agents should do the same thing.

I’d like to close with this: having a good customer support team is incredibly difficult. It’s imperative that you get it right, as the perception of your company can be destroyed by a bad interaction. You, the company, aren’t going to win every customer interaction, but your team should try its best and be expedient in the process. It’s far too important not to.

How to Pick a Theme You Will Love

You’re looking for a template for your site. You might not be a designer, but you know what you like. Using sites like ThemeForest, you start your research in an effort to find something amazing. Once you find the one you like, you purchase it.

Now you’re starting the process of implementation, and suddenly, you realize that your site looks nothing like the demo that you saw.

This is what I call template delusion. You were sold on the look/feel of the demo, but didn’t ask yourself the key question:

How will this template work for me?

Think about some of these scenarios.

Your site looks much more empty than the template demo.

Many theme demos rely heavily on stock photography and filler text. When those stylistic elements are gone, the template will seem empty.

When looking for a template, make sure you look at some examples that don’t rely heavily on imagery or large, stylistic typography. Blog posts for WordPress are a good example; this will allow you to see some of the color/typography in use. You will want to make sure that the default typography settings are legible and clear. Even if the template is based on a framework such as Bootstrap, template designers will modify fonts – they might not look great as body text.

Your images don’t look great in the template.

The demos sometimes use very specific media to show off the strengths of the template’s design. Your media might need to meet similar dimensions and focus points in order to work well with the template.

Look closely at the images in the demo. Is it wide? Where are the focus points? Is it out of focus? Is there text on top of the image that will make selecting an image difficult? Will it work with some of the images that you have? These are some of the questions to ask. When looking at a template, try to think about some of the media that you already have that could work – also consider restrictions you may have in the future. If the possibilities for images, particularly in large hero elements, are heavily restricted, you might find it challenging to find photos that work.

You’re struggling to fill the template with content.

After seeing the demo for something like a landing page, you’re struggling to “fill out” the various sections of the template.

This happens when you are trying to wire your content to the template. You won’t be able to do this, so before even looking at templates, start thinking about your user’s goals and your business goals. Write them down and evaluate how a template will help you meet those goals, not how you’ll fill out a template to try to meet those goals. Often, there will be templates for very specific products or apps that just won’t work for eCommerce or sites more focused on information.

Your website is not performing well, even after launching a new template.

You have not seen an improvement in metrics or conversions after re-launching on a new template.

There are a variety of reasons why a website won’t perform. Ultimately, the template needs to support your user needs and business goals, and sometimes the template can actually detract from the user experience. For example, templates that use parallax scrolling sometimes modify the mouse’s scrolling behavior or the template tries to preload all of the content using Javascript so it can have fancy stuff like animations. These “enhancements” are actually detracting from the user’s experience.

Start simple with a theme that doesn’t have any animations, preloading, or any other goofy stuff – focus on having a page that loads quickly and has clearly presented information and user paths. Don’t get in the user’s way with modal windows, carousel animations, or other gimmicky stuff. Take the time to learn about behavioral data such as Google Analytics to see where you’re losing people along the way.

You can’t create any of the content that the template promised.

The template requires technical knowledge beyond your skill level to create the content shown in the demo.

Many of the top-selling templates boast about the number of features they have, but sometimes this can be negative. The themes attempt to accomplish this by modifying the core system to make publishing in their design template easier, but this adds a layer of complexity that might hinder your ability to publish content. Before looking at a template, start simple by creating a simple sketch of what you would like your site to look like. This is called wireframing. Here are some examples. A User Experience professional uses a wireframe to create a very early paper prototype of what their pages will consist of. They take user goals (“As a customer, I’d like to contact technical support”) and business goals (building an opt-in mailing list) to create a visual of what the page might look like. You can do the same, and doing so will help you determine if a theme is right for you.

With a wireframe in tow, you can determine whether or not you need the extensive features that a theme might add. Keep in mind, though, that with more features added by the template, the more overhead and risk there is. A good test for this is to ask yourself “Could I create this wireframe on a plain page with no customization?” If so, all you will need from your template is look/feel customizations such as colors and typography.

Have you fallen out of love with a template you purchased? Tell me about it in the comments, and I’ll explain how to avoid template delusion in the future.

Hello, Timeboard!

Timeboard helps teams communicate with the magic of Meteor.

Timeboard, powered by Meteor

Each member gets a Status Card.
Status card being updated

Status Cards take a short message and one of three states: Available, Busy, or Out. Timeboard also has alerts, which show on everyone’s dashboard.

Alerts in Timeboard

Timeboard was built to be mobile friendly, but it’s more than a pretty face; Timeboard is designed for people on the move and makes updates (and administration) fast and simple.

Mobile View

Administrators can make edits directly to the dashboard by using Edit Mode. Alerts, profile changes, and other updates are pushed out immediately. No longer need that alert about the crazy cat lady? Just remove it in edit mode and it’s instantly gone.

Edit Mode activated

Deploying is easy. Just download and deploy. Timeboard will help you with your first user.

All-in-one Event Calendar 1.9 Update Woes

I’m a little whiny today.

We’re two weeks out from going into beta with our new WordPress-driven website, on which approximately 500 events will be created per year. After much consideration of the plugin market for events and calendaring solutions, I was able to settle in with’s All-in-one Event Calendar. After a painstaking migration, in which I learned more than I ever needed to know about the iCal format, I was able to successfully import over 6000 events into the calendar.

Everything seemed to be going well – we were working on a custom theme to help get it integrated, I was able to modify some of the code easily to change some presentation options (they’ve used MVC and have done a pretty great job with it), and it seemed like it was production ready. Then, I started receiving some very nasty yellow boxes across my entire admin interface – there’s a major update to the calendar plugin.

If you’re reading this because you updated and now everything is broken, let me just say that you can avoid this completely by instituting some sort of version control – whether it be Git, SVN, Mercurial, whatever – you NEED something like this in place for instances like this. Plugins or core updates always have the potential of going south (fast) and your first line of defense is version control. Don’t think that you can update blindly on your production server without testing first – it is a recipe for disaster, and I’m going to ding for making this update seem like it was absolutely necessary by plastering it all over the admin interface, causing people to hastily upgrade (or feel like they needed to).

Now, onto the issues:

1. It’s spitting out foreach errors and warnings. Apparently this is an issue with “legacy” themes – you’ll see tons of notices and errors about that, but they’re pretty informative.

2. AJAX loading of events/slow loading times. With the new update, when you visit an event “post,” the event information is loaded via AJAX instead of the database. I’m not sure where the culprit is, but this caused a delay of 2-6 seconds on my local dev machine – and anything over 2 seconds is simply unacceptable. The AJAX call isn’t necessary in this particular case – if the system is loading a single, static event, that information should be pulled directly from the database FIRST. Widgets have the same issue. The devs need to fix this.

3. CSS not loading/site crashing completely – we didn’t have this issue, but you’re probably going to need to revert. If you don’t know how, you might be in some trouble. First, look into disabling the plugin via the database. Second, revert if you have version control or find the legacy plugin to manually install.

We reverted the files back using version control and didn’t have any issues with databases, so with this particular plugin, you should be able to switch back without any issues. Hope this is helpful to someone, and I’ll update when a revision is posted.

Modern Version Control: Creating an Efficient Development Ecosystem

Version control is widely considered a litmus test for development environments, yet some companies and institutions continue to disregard it. Even worse, some have implemented old, archaic technology that is extremely inefficient in the modern developer’s workflow. Distributed version control systems provide all of the benefits of version control while enhancing the development ecosystem, making teams more flexible and efficient.

Considering a move from centralized version control like SVN? See the trials, tribulations, and metrics of Santa Clara Law’s transition from SVN to Git and the enhancement of the development ecosystem with the introduction of Gitolite and Redmine.

Modern Version Control

Updated 10/31/2012:

* Fixed gB/mB to GB/MB
* Added context to checkout slide
* Removed date from slides
* Higher quality slides

Notes from Modern Version Control at AgileDC

First and foremost, I want to say thank you to everyone that came to the presentation today, asked questions, and provided feedback about the presentation itself. I had a great time, and I feel like we were able to squeeze a lot into 30 minutes (maybe even too much). While you may be familiar with Git and DVCS concepts, I hope that I was able to inspire some thinking about how you use DVCS in your current organization and how that could be better.

That being said, these slides are great if you meet one of the following:

  • You’re considering moving from something like SVN, Perforce, etc to a distributed workflow like Git, Bazaar, or Mercurial
  • You’re looking to get started with the basics of Git and learn some of the “gotchas”
  • How to integrate Git with other services to change the development workflow
  • Integrate Gitolite and Redmine/ChiliProject with Git

While detailed step-by-step instructions would have been outside the scope of this presentation, these programs are all very well documented and there’s enough resources to get you into a test environment if you see fit. The Git community is awesome about posting their trials and tribulations, so use that to your advantage when rolling something like this out. As always, please feel free to contact me either here or on Twitter (@nicbertino) if you have any questions. I’d love to help.

Slides: Modern Version Control (8MB)