• Free Figma resource: “Farmers Market” site design

    Free Figma resource: “Farmers Market” site design

    Okay I’ll admit it: I got disproportionately excited when I saw Figma announce their new Sites product. I’m a web nerd. I love making websites, and I love working in Figma. Could this have the potential to be the best of both worlds for me?

    Well, it’s still in beta. It has known accessibility issues, and its CMS functionality is still in development. So for now, its wider usage is limited. BUT, that doesn’t mean I can’t geek out and have some fun :)

    My last team before leaving Automattic was focused on creating new themes and patterns for the WordPress site editor. I did dozens of little concept thumbnails that never made it beyond Figma. I tapped into that collection for inspiration, grabbing this thumbnail I’d liked but never had the opportunity to refine further.

    A small mockup of a potential website. The title reads "farmer" and then a big heading says "South Philly Fall Farmer's Market." Underneath that is "every Wednesday in October between 10am-5pm." Around the heading is a squiggly illustration, a photo from a farmers market cropped into a circle with an illustrated plant overlaying it. Another farmers market photo appears in the next section, along with a "vendors" heading and list of vendors. The image and text are cut off at the bottom.

    I wanted to keep it limited to just one page, only using static (instead of dynamically updated) content. So I included date/time, location, a list of vendors, and a blurb about the market.

    I aimed for the design to feel organic and crafty. I tried combining stock photography with this free shape library, but didn’t love how they felt together. Instead, I started working on some illustrations I could include. I drafted some ideas in Procreate, then struggled with vectorizing them. I wanted the kind of texture and character you can get from raster art that just doesn’t translate as well in vector art. Live tracing the drawings in Illustrator just wasn’t working out how I wanted. So, I tried redrawing in Adobe Fresco, which was…fine. It would be cool to do illustrations directly in Figma, but for now, my digital drawing capabilities are limited to my iPad.

    Once I felt like I had a decent draft, I copied it into Figma Sites and started figuring out how to actually build it.


    The interface for Sites is, unsurprisingly, just Figma in a different context. The page control in the left sidebar is for website pages, not document pages. The file information panel at the top of the sidebar contains a “publish” button. The righthand design/prototype toolbar is the same. Overall, it feels like a natural progression to the Figma interface. The only feature that feels new is the way you design responsively.

    A screenshot of Figma Sites' page UI showing four screen sizes of the mockup: large desktop, small desktop, tablet, and mobile.

    I’m unsure if it automatically maps which screen size to use for your imported mockup or if it just defaults to desktop, but it’s dropped as a size-specific artboard into a page canvas. (I have no idea if I’m using the official terminology, fyi.) From there, you can click the “+” in the corner of the canvas to add different screen sizes. It offers some preset sizes, or lets you create a custom breakpoint. And that’s what this is doing—each artboard is acting as a breakpoint for design changes.

    This is where intimately knowing how Autolayout works is key. Whether or not something is a fixed size or responsive depends on the autolayout setting for that element, and that element’s parent, etc. etc. So if like me you’d been playing around, you’ll have a lot of cleanup to do in order for your site to work as expected.

    This means using width: fill with max-widths, properly setting up columns and rows, and making sure the correct elements or containers have padding. And, it means ensuring any images or vectors you include are either ratio locked or unlocked to allow for your intended scaling.

    I found myself using the preview feature a lot and resizing the pane to check if my layout was responding as I intended. Unlike a design prototype, the preview opens in the same file. I kept forgetting and being like “wait where’d my site file go,” so I think that’ll take more getting used to 😂

    When you make a change to your design, it cascades down. For example, making a content or color change to your biggest desktop artboard will be reflected on smaller screens. If you want that to be overridden at a smaller size, you can do so, and that change won’t cascade back up. As I was fiddling I ended up having to redo a few things, but now that I have the hang of it I suspect my next project will go smoothly.

    One thing that tripped me up in another template I’m designing is that you can’t create new components inside of a page canvas. You have to drag it outside of that canvas in order to convert it into a component, so I ended up making a floating artboard to hold my components.

    Publishing the site was easy—it creates a new figma site URL on the fly you can access. If you’ve ever had a GitHub PR create an automatic preview, it’s similar to that. You can use that URL if, like me, you’re just creating something that doesn’t need to be branded. But, if you want to use it with a custom domain, that’s already supported. (I didn’t go through that setup flow because I didn’t need to.)

    And, when you’re publishing, it will also scan your site for potential issues.


    If you’d like to take my site for a spin or download it and poke around yourself, I’ve made both the live site and the Figma file available:

    Or, view directly in Figma

    This design is licensed under CC BY-SA 4.0. This means you’re free to share, reuse, and adapt it as you see fit for both personal and commercial uses, as long as you credit me somewhere.

    (You are free to use the template to build websites for clients, but the only thing I ask is that you don’t sell the template itself or the illustrations included without making your own improvements, because that’s kind of a jerk move.)

    Hope you enjoy! I plan on making a few more Figma Site templates for public use, and I’m hoping once it’s out of beta I’ll be able to upload it to the community. But in the meantime, you’ll find any new templates I release on my blog.

    Let me know what you think!

  • Ratings

    Ratings

    I was thinking about WordPress themes this morning, and how hard it is to find a good theme. There are tons of themes that look great, but once I install them, I either have no idea how to set up the theme to look like the demo, or I’m presented with so many customization options that I say “whelp, nevermind!” and go try to find another one.

    In theory, ratings are supposed to help you find better themes, but they’re so open to interpretation that you really only end up getting unfocused opinions. I like this, therefore, five stars. I hate Gutenberg, therefore, zero stars. It’s not really helpful.

    What if theme ratings were more granular? For example:


    Aesthetics
    ☆☆☆☆☆

    Setup
    ☆☆☆☆☆
    ◻ Someone set it up for me

    Works as intended
    ☆☆☆☆☆
    Did you encounter any bugs?:

    Has the features I need
    ☆☆☆☆☆
    Elaborate:

    Helpful support
    ☆☆☆☆☆
    ◻ I haven’t contact support

    Optional Comments:


    Every person using a theme is, of course, biased — so in some ways the ratings would still be arbitrary — but by providing some semblance of categorization, we might at least help people think about the theme experience.

    You might be saying (because I am also thinking) — “oh, but Mel, it’s already hard to get people to fill out ratings. By adding more questions, wouldn’t it make it even harder?”

    Partially, yes. Someone’s gonna look at that form and be like “nah, pass.” But for some, the additional structure might make them more likely to review. I hate being presented with a single star rating field and a comment field because it feels so unstructured, I never know what to say. Since my name is always included, I feel like I need to have a smart response or else someone’s going to come along and be like, “wow, Mel’s an idiot.” Having a guided form like the above helps me at least rationalize how I feel about something, and by breaking it down into specifics, I feel like I can provide a more accurate rating.

    Anyway, just random a Sunday morning afternoon thought.

  • Gutenberg Navigation Block Concepts Roundup

    One of the goals for Gutenberg Phase 2 is a new navigation menu block. There’s already been a lot of thought and discussion on this, which I wanted to gather into one location so it’s easier to review and compare all the options.

    Early concepts

    There are a number of early explorations on the GitHub thread:


    WordCamp US contributor day

    At the WordCamp US contributor day, a group got together and started thinking through a navigation block:


    Individual explorations

    Brent Jett has been writing a good series on the future of themes and customization in Gutenberg, and the second part of his series covers navigation:

    I have a couple more early ideas kickin’ around that I need to update:

    Did I miss any?

  • Designing a “Restaurant Menu” Block

    An animation showing the transition between a selected block, with toolbar and "add" icon, and a deselected block. The block contains a heading that says "Appetizers," and lists four menu items along with their price and description.

    Download Sketch file.

    View InVision prototype.


    I’ve wanted a better way of making restaurant menus since first working on WordPress.com’s restaurant menu custom post type a couple years ago. The process felt so slow, clunky, and divorced from the final product. CPTs never felt like the right method for providing this kind of content. Blocks provide a perfect opportunity to redesign how we add restaurant menus to our a site —  they’re UI-first, and both edited and previewed in-context.

    What the best way to approach this kind of block? If I were to convert the WordPress.com restaurant CPT 1:1, it would look like:

    • A parent block to act as a container.
    • Child blocks for menu sections, featuring names and descriptions.
    • Child blocks within menu sections for menu items, featuring a placeholder for featured image, name, price, and description.
    • Custom taxonomies (“menu labels”) for menu items.

    That seems like a whole lot of overhead for some content that, let’s be honest, doesn’t change very often. In many cases, the most a menu is changed is seasonally. I think we can ease the setup and maintenance of the block quite a bit.

    Zooming In

    Let’s look at simplifying restaurant menus down to their basic element: menu items. What if the only restaurant block that exists was a menu item?

    Menu item on the top left, price on the top right, and description below were the most common pattern I found when reviewing restaurant menus.

    Pros

    • Super simple — only need to enter three lines of text.
    • Minimal settings. Bold and italic options for some minimal text formatting control, but otherwise, no sidebar options.

    Cons

    • You have to add a new block for every menu item, which will get tedious fast.
    • Because menu items aren’t grouped into a shared container, styling options for your menu are limited.
    • Doesn’t make sense to be able to add menu items everywhere.

    These cons seem pretty big; let’s widen the scope.

    Zooming Out

    The next level above a menu item is a menu section. This is a parent container that features a section title, and individual menu items as children.

    Heading and Menu Item contained within the same container block.

    Pros

    • A wrapper means the entire section can be targeted with custom CSS, or support layout options.
    • The block could default to adding a new menu item next, so all you need to do to get another item is press “enter” at the end of the description field.
    • The block is still relatively simple, compared to the original.

    Cons

    • Doesn’t support the complex scenarios that the original CPT supports, including taxonomies and featured images.

    This feels like a happy middle-ground between the existing CPT, and a completely zoomed-in version of the block. The restaurant menu block acts as a wrapper with minimal default settings (columns, background color, text color) that could be extended to include fancy borders, background images, or other decorative elements. These could alternately be block styles.

    Additionally, the block could register some core blocks like additional headings, paragraphs, and images as child blocks:

    This negates the need for featured images, because you can insert images inline. And, most menus I’ve seen don’t show a thumbnail for every item on their menu — they mostly scatter highlights throughout the menu. This system supports that better, allowing for more flexible layout and display of menu items.

    Block settings

    Speaking of layout, this block could easily support some columns:

    Two column menu layout.

    I also included a toggle on the menu item itself for allergens. I don’t think this is necessarily the best label, but I couldn’t think of a better word. Toggling “allergens” on adds a new field underneath the item description, so you can add some extra details like “gluten-free” or “vegan.”

    Allergen setting activated in the block
    Allergen setting in the sidebar

    The supported core blocks (heading, paragraph, image, and gallery) would keep their default settings.

    Prototyping

    After mocking up most of the block states, I linked them together in Sketch with the InVision Craft plugin:

    I do this because I find actually clicking through the various block states is the best way to wrap my head around how the block actually works, and easily allows me to catch any errors I made while mocking up the block. In this case, I went through a couple rounds of minor revisions based on issues I saw in the prototype.

    For example, an earlier iteration of a menu item showed the block outline around the entire block, rather than just the menu item. Most recently, I updated some of the toolbars to use more up-to-date Gutenberg patterns.


    If you want to explore the design more closely, you can download the Sketch file or look through the InVision prototype.

    If you want to use this design to build your own restaurant block, that’s cool too — just credit me and link back to my site in your plugin readme.

    I’d prefer if this design wasn’t used for a premium plugin, but I’m okay with you using it as a starting point — just make sure to update it and introduce new features instead of building this exact design. Honor system!

    What should I design next? đŸ€”

  • Splash Pages for Campaigns on Squarespace

    You might have noticed in my recent post on election design that I made a bunch of splash pages for Alessandra Biaggi’s campaign.

    Website landing page that prominently features the text "ELECT MORE WOMEN / BIAGGI 2018." The headline on the page reads "elect more women," and the content describes why you should elect Alessandra Biaggi. There is a button to donate $25, and a link to continue to the website.

    Splash pages are common tactics for any site trying to raise money or spur action, like political campaigns and non-profits. They’re usually minimal, focused, and create a gate before you can reach the regular site.

    Biaggi’s site was built on Squarespace, so my first instinct (“download a WordPress plugin!”) was out. The idea of using a regular page and overwriting a bunch of CSS was… daunting, to say the least. That’s when I discovered the utility of Cover Pages. I’d seen them announced before and thought they were nifty, though at the time, I had no use for them. This changed when I started playing around with them as an option for splash pages.

    Cover Pages are great because they load a separate template into the page. You can control whether to show branding and navigation, or just go simple with a header, body text, and some action links. You have a similar style editor as the rest of the site, but it’s per-page, so you can tweak styles between different cover pages.

    There’s a number of available layouts, geared towards different use-cases. I found “landing,” “profile,” and “video” to be the most useful categories for my particular needs.

    Squarespace's "Change Layout" panel. The layout dropdown is open, showing the available layout categories. Behind the dropdown are preview thumbnails for a few layouts.

    In particular, I used VANGUARDMISSION, and PROJECTOR the most often. I also found FLASH a good option for making policy-specific splash pages, which we used on social media.

    One gripe — there’s no way to set per-page marketing settings, like social share images. This would have been immensely helpful for making our policy splash pages, so each had a unique social share image, instead of using the general site image.

    I had to write very little CSS to get these pages looking the way I wanted. I customized non-primary buttons so they appeared as links instead, and adjusted some background positioning on different screen sizes. That may have been the extent of it?

    Each splash page had its own corresponding ActBlue link, so we could track how each page performed. I wish we’d dived deeper into this — I think if I work on another campaign where we use these tools, I’d try more variations to see which pages perform better.

    We primarily used Cover Pages for donations and GOTV (“get out the vote”), but I could also see early-stage campaigns using them for email gathering or “stay tuned!” landing pages. I think there’s a lot of opportunities for campaigns using Squarespace to leverage this feature!

  • Design for Elections

    If you’ve chatted with me any time this year, you’ve probably heard that I’ve been spending a lot of my spare time volunteering for various campaigns across the US. I’ve been involved with Get Her Elected, Ragtag, and Tech for Campaigns, civic tech orgs focused on helping progressive candidates. I’m also the Website Director for Alessandra Biaggi’s campaign for New York State Senate.

    Civic tech kept me going this year. I spent much of last year in a useless haze. I felt powerless. This year, I was determined to take back my agency. Volunteering on campaigns allowed me to use my skills to make a difference. Whenever I felt despair sinking in, I’d work harder, or volunteer for another project. I had networks of other civic techies who kept me buoyed and provided support and encouragement.

    Now that the Midterms are (mostly) over, I wanted to share some of the work I’ve done. Pretty much all of these were collaborative efforts with other civic tech volunteers across different organizations.

    Site Design

    Site design is my specialty. I’m great at taking minimal amounts of content and stretching it into decent “brochure” style site.

    Most of the campaign sites I worked on this year were built on Squarespace or WordPress. WordPress is, obviously, my specialty, but I had a lot of fun learning the ins-and-outs of Squarespace, which is a pretty amazing platform for getting an attractive site up ASAP. 

    Here are some of the sites I worked on:

    And some landing pages I did for Alessandra Biaggi’s campaign:

    Ad Design

    This was my first foray into ad design, and I learned a lot in a short amount of time — best practices, sizing and formats, Facebook’s 20% text rule, etc. Here’s some of my favorite ads:

    With the Midterms wrapping up, I find myself wondering what’s next. Voter suppression and disenfranchisement, and Gerrymandering, continue to play a destructive role in our elections. I’d love to find a way to help fight both with my design skills. I want to work on tools to make campaigning easier, especially for candidates without a ton of resources. If you come across any orgs looking for design volunteers to tackle these issues, send them my way!

  • FireCast Presents: Paintsville Independent High School, Automattic, and AGI

    Last year, ï»żAutomattic paired up with Paintsville High School in Kentucky to do a remote graphic design fellowship. FireCast, a traveling video podcast in Eastern Kentucky, recently filmed the students talking about the experience:

    You can learn more about the podcast and about the design fellowship on The Hollerï»ż.

    I had a lot of fun working with both my artist, Min, and my student, Abby, and it was really great to hear how the program went from the Paintsville students’ perspectives. It sounds like we’ve opened up their minds to the idea of design as a career, and remote work.

    Too often, tech workers are pushed towards big cities in order to grow their careers and support their families. By opening up remote opportunities for work, folks in suburban and rural areas can live the lifestyles they love and still have opportunities to make great careers. This is especially important in areas where jobs are scarce and disappearing, like Appalachia.

    I really hope we get the opportunity to partner with more schools in the future, and to sustain our relationship with Paintsville!

  • 10 New Principles Of Good Design

    Dieter Rams’s design principles get a 21st-century update. Source: 10 New Principles Of Good Design

    Co.Design offers up 10 New Principles of Good Design, updating Dieter Rams’ principles for the modern digital age. Particularly relevant after the events of 2016–17. Give them a read!

  • Back to Childhood: Blocks are the Future

    Note: this post was originally published on our new Automattic design blog. Also check out my previous post about the future of site building & customization in WordPress for more context to this post.

    Photo by Tiffany Terry

    Last month, my colleague Joen wrote a great post about blocks and the Editor Focus for WordPress in 2017. Joen designed a fantastic blueprint for blocks in WordPress that the Customization Focus will continue to flesh out and build on over the next year.

    Recently, I’ve been starting to look at converting widgets in WordPress to Gutenberg blocks. Widgets are the bits of content you can currently drop into your sidebar or footer in WordPress — like the recently updated image widget, some text, or a search bar.

    Current Widget Panel in the WordPress Customizer

    Updating some of these widgets to use Gutenberg’s block patterns has been quite easy — they are simple blocks of content without a lot of settings. However, some widgets are quite complex. Turning them into blocks has been a challenge.

    Take, for example, the Categories widget. It creates a list of all your post categories, and links to the archive pages for those categories. It’s very useful for the large number of bloggers who organize the blog posts on their site using categories. The Categories widget comes with a couple options:

    • Display categories in a dropdown, instead of a list.
    • Display the number of posts in each category.
    • Display category hierarchy, if you have parent and child categories on your blog.

    These options are easy to present in a block:

    Proposed Gutenberg Category Block — Check it out on GitHub

    The widget settings work well in the “Inspector” on the right, while the block itself is previewed inside of your post or page editor (and eventually your whole site).

    Not all widgets are this easy to turn into blocks. Let’s take a look at Recent Posts widget, which shows a list of your most recently published posts. At first, it seems just as simple as the Category widget, right? Well, what if we took this opportunity to improve the widget while we turn it into a block?

    Currently, you can control the numbers of posts listed in the Recent Posts widget, and you can choose to display post dates. That seems like a good start for a sidebar, but what if you wanted to show a list of posts on your homepage? You’ll probably want to show more details about the post.

    Looking at popular blogging websites and themes, many include the post’s featured image, and either an excerpt, or the content of the whole post. Let’s add that to our list.

    Many sites and themes also show posts as a grid, not a list. What if we gave folks the option of choosing between a list or a grid layout? If we support grids, we’ll likely also want to let people choose how the maximum number of columns in which to display their posts on larger screens.

    Now, our feature list looks like this:

    • List view or grid view
    • Number of posts to show
    • Columns (only if grid view)
    • Display date
    • Display featured image
      • Featured image size (taken from your site settings)
    • Display post content
      • Excerpt
      • Full post

    More powerful, but also much more complex!

    This slideshow requires JavaScript.

    Proposed Gutenberg Post Block — Check it out on GitHub

    However, the block is still mostly controlled through a list of options in the Inspector. What about a block that you need to build, like the Custom Menu widget?

    At its most basic, this could be a simple block. The widget is pretty simple: just choose an existing menu from a dropdown, and it displays that menu in your widget. This isn’t great, though, since you need to know to make the menu first. It’s a pain and it breaks your flow.

    In a future where all of the navigation menus on your site are blocks, it seems more important to let you actually build that menu where you’re adding a block. We don’t have any established patterns for a task like menu-building yet, so we need to establish some.

    Core contributor Joshua Wold kicked off the brainstorming with a great sketch:

    Proposed Gutenberg Menu Block by Joshua Wold — Check it out on GitHub

    Within the block, you can choose an existing menu, or create a new menu. If you choose to create a new menu, you can drag pages over from the Inspector (or click on them) into the block to build your menu. This is similar to how menus currently work in the Customizer.

    Another direction we can take is cutting out the confusion of duplicate menus, and building the block to make one-off menus instead. That could look something like this:

    This slideshow requires JavaScript.

    Another Proposed Gutenberg Menu Block — Check it out on GitHub

    This block is still being explored. If you have ideas, you can post them on the GitHub issue! We’d love to see more folks involved in shaping the future of WordPress.

    I hope, by tackling the hard widgets (and shortcodes!) now, we’ll establish all the key patterns and lead the way for other plugins and themes to convert their custom widgets into blocks. I’d like to help create an ecosystem where page builder builders and premium themes can continue to flourish, while remaining consistent and compatible with core WordPress design patterns. Hopefully we’re off to a good start! ?

    Thanks to Joen and Tammie for their ongoing support and feedback as I explore these new block designs!

  • Building a Site That’s Right for You

    Note: this post was originally published on our new Automattic design blog. Check it out!

    Hello everyone! ? I’m Mel Choyce, a product designer on the Apollo team here at Automattic. Apollo is comprised of the Automatticians who contribute full-time to the open source side of WordPress over at WordPress.org. I’m the design co-lead of WordPress’ customization focus for 2017. Prior to joining Apollo to work on this focus, I was on another team at Automattic that whose mission was making site building and customization easier on WordPress.com.

    Customization has been a pretty big pain point in WordPress for a number of years. With the emergence of easy to customize, drag-and-drop website builders like Squarespace, Wix, and Weebly, WordPress’ minimal customization tools have been falling further and further behind. To make sweeping changes to your WordPress website, you still mostly need to know PHP. This is totally unrealistic in 2017! In the case of WordPress.com, where we don’t let people edit their website templates, this means you can’t make any big changes to your site (like easily adding recent posts to your homepage or swapping the position of your logo or your navigation menu).

    This is painful. There are so many “why can’t I just
” situations that really trip people up when setting up their sites on WordPress, myself included! For someone like a business owner with no time, that kind of barrier means they’re going to give up and try somewhere else. The platform they move to will likely be closed and proprietary. If their business grows and they need to scale up their website, being on a closed platform like Squarespace will make that even more difficult.

    We want the web to remain open. To ensure it stays that way, WordPress needs to step up its game and make it easier for everyone to make websites, from bloggers, to business owners, to web designers and developers. As a platform, we need to embrace all of these use cases.

    Enter this year’s customization focus. For the first half of this year, I’ve been collaborating with my development co-lead, Weston Ruter, and a couple other key contributors to fix some low-hanging fruit. We’ve identified these small but impactful updates a couple ways:

    • Looking through existing Trac tickets that feel like they would be small projects, but would make a big impact.
    • Building lots of test sites in WordPress, using “real” scenarios so we’re not just aimlessly putting dummy content into a site.
    • Reviewing previous usability tests that touched on site building and customization.
    • Chatting with folks who help support bloggers and business users who are building their own websites to find out what problems people encounter most frequently.

    Using this, we’ve come up with a list of projects that we’ve been slowly working our way through the past couple months, like adding a new image widget, and adding formatting options to the text widget.

    The four widget updates coming to WordPress soon: Image, Video, Audio, and Rich Text.

    The second half of the year is about tackling some of the bigger issues. While we’ve been hard at work on smaller fixes, the editor focus has been building a new paradigm for content creation in WordPress. You can check out their progress on their GitHub project, Gutenberg.

    After the new editor launches, the customization focus will start looking at how we can expand on the patterns Gutenberg has established. We have a number of problems we’ll need to address: how do you tell if you’re editing content on one page, or on all of your pages? What if I want to show my latest news on my homepage, in addition to a welcome message and some information about the services my company offers? What if I want my phone number higher up on the page? How can I edit my website without knowing any code? What if I’m a developer building websites for others — how can I make it easier for my media clients to act on breaking news or updates and edit their sites on-the-fly as their situation dictates?

    All of these are problems people struggle with when building websites on WordPress today. We hope that with Gutenberg’s design patterns as a base, we can start tackling these thorny problems and help empower people to build websites to help promote themselves, their passions, and their work.

    Stay tuned for more updates.