The French Press

Espresso from The French Press

The French Press

Goleta – 250 Storke Rd, Goleta, CA 93117

Great local haunt with single origin espresso and drip.

The French Press came highly recommended for my trip to Santa Barbara. One thing I very much appreciated was the free sample of Ethiopian single origin they had on drip, which was a delightfully complex and fruity coffee. The espresso was nutty and chocolately with a little bit of sourness toward the backend of the shot, both roasted by Dune Coffee. Bonus points for the gorgeous plateware.

Caffe Calabria

Caffe Calabria’s espresso blend

Caffe Calabria

North Park – 3933 30th St
San Diego, CA 92104

As close to Italian as you’ll get.

Caffe Calabria wants to capture the cafe culture of Italy, one of my favorite parts of my visit there in 2017. I loved that people would order their espresso, slam it at the standing bar, and be on their way. Illy and Lavazza have a tight reign on coffee there, but Caffe Calabria roasts their own blends and single origins. It’s a solid homage to the classic Italian espresso.



North Park – 3019 Adams Ave, San Diego, CA 92116

Cat & Cloud’s “The Answer” with fancy toast. You can’t go wrong.

Cat & Cloud, a roaster and chain of cafes out of Santa Cruz, is one of my favorite coffee experiences. I was pleasantly surprised to learn that Hawthorn brewed Cat & Cloud. The foodfare, sporting a number of vegan toast and pastry offerings, puts it over the top. Plus, there are plenty of cute dogs to pet.

Holsem Coffee

Holsem Coffee's Holsem Blend

Holsem Coffee

North Park – 2911 University Ave, San Diego, CA 92104

The rich and syrupy Holsem Blend is expertly roasted and perfectly pulled.

Holsem is a gorgeous fixture on University Avenue in North Park. A fantastic neon sign adorns the storefront, and the interior sports a pourover bar and a gorgeous La Marzocco. It’s a great place to stop on your way to work to grab a quick espresso blend to get your day started right.

The WestBean

West Bean

The WestBean

Bankers Hill – 2550 Fifth Ave #75, San Diego, CA 92103

Solid blend and innovative drink ideas.

WestBean Coffee Roasters is a local chain of coffee shops featuring house roasts. The blend used for the espresso reminded me of Italy, and I appreciated the cold brew/lemonade drink on offer.

Coava Coffee

Coava Coffee

Downtown – 400 West Broadway, San Diego, CA 92101

Two of the best espressos I’ve ever had.

Coava is a West Coast staple for great coffee. They only serve single origin espresso “ristretto,” which is a slightly smaller but more intense shot. It’s a great way to experience single origin espresso, and I’d recommend it in a heartbeat to anyone looking to get started with straight-up espresso.

Better Buzz

Better Buzz Espresso - Kenya Thunguri, AA

Better Buzz

Hillcrest – 801 University Ave, San Diego, CA 92103

A gorgeous meeting place with solid single origin options.

Better Buzz is a San Diego-area staple. The cafe in Hillcrest features two beautiful La Marzocco machines, with one bar seemingly dedicated to their single origin offerings, which are roasted in-house. It’s a friendly vibe with a solid food and coffee offering.

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.