Make WordPress Design

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Ella 7:08 pm on September 5, 2016 Permalink |  

    Contextual inline formatting toolbar 

    I’m looking into streamlining tools for the editor by moving more buttons to a contextual toolbar.

    One flow that more and more people are getting used to, and seems like a pretty solid concept, is having a contextual inline formatting toolbar. This means that the bold, italic, link etc. buttons are (only) available when you select text.

    Contextual inline formatting toolbar

    What is your experience with this, positive and negative? Do you have any feedback on this from your users or clients using other software?

    In my own experience, some of the positive sides are that:

    • These tools are hidden by default, which makes the interface lighter. They are not used as long as you don’t select any text, so there’s also no reason to show them.
    • The tools appear close to your focus area, which makes it easier to find them and which saves you time moving the cursor, or hand, to them. For screen readers it could be announced (I think).

    Some of the negative sides are that:

    • The toolbar may easily become overcrowded when plugins extend it. (This may happen now as well…) For this reason, please think of it as just for inline formatting, no block formatting and no insertion. In other words, the action needs to affect the selection the user made, nothing more, nothing less. Headings, for example, do not belong here. More on that soon.
    • Some people do use these tools when no text is selected, meaning to format the word containing the caret. Similarly keyboard shortcuts also work in this case.

    I’m looking forward to read your comments.

    • Nick Halsey 7:23 pm on September 5, 2016 Permalink | Log in to Reply

      I like this idea, particularly if the inline tools are specifically intended for non-block-level formatting. More experienced users can leverage this in conjunction with keyboard shortcuts and formatting shortcuts to apply formatting without selecting text. All users would understand that the tools are available when selecting text after first experiencing how it works, although we should run some user tests to investigate the discoverability (ie, ask a user to make something bold, insert a link, etc. and see if they try selecting text to bring up the tools).

      My biggest concern is with mobile, where various platforms may not have great interfaces for selecting text. But the inline tools would probably work better than what we have now here anyway. Also of course, making sure that it’s accessible, although I imagine that the experience would be improved there as well.

      • Ella Iseulde Van Dorpe 7:40 pm on September 5, 2016 Permalink | Log in to Reply

        If you can’t easily select text, it would indeed be hard right now as well, unless you just want to format a word. Even then, you still have to scroll a lot.

        Regarding screen readers I can imagine we could make it even better than how it is now.

        My concern for mobile is that some systems also have a contextual toolbar, but there are some not so ideal ways to work around that. One way is to offset ours, another is to position it at the top (bottom wouldn’t work with virtual keyboards). Yet another is trying to do something with the selection or focus. Suggestions are welcome. 🙂

      • FolioVision 8:26 pm on September 5, 2016 Permalink | Log in to Reply

        Ella Iseulde, this a wonderful idea with one caveat: that it does not affect performance or compatibility. An additional formatting tool is probably not worth doing if it’s not lightweight. My suggestion would be to disable the code for platforms where it would either exert a significant performance penalty or would simply be awkward and out of place.

        Like Nick and yourself, I agree that this should only be for non-block level formatting.

        I especially like it if it means that the buttons which work inline do not appear in the toolbar. Redundancy would just be clutter.

    • Raul Illana 8:46 pm on September 5, 2016 Permalink | Log in to Reply

      My humble two cents. An inline editor toolbar feels like the right next choice, because you can always extend it with your favourite toolbar, or hooks.

      Medium uses something like this, and there’s also a vanilla JS clone. https://github.com/yabwe/medium-editor

    • Morten Rand-Hendriksen 9:11 pm on September 5, 2016 Permalink | Log in to Reply

      I like this idea, and it’s a big step toward front-end editing. That said, even with this tool inclusion I would keep the functionality in the main toolbar for a couple of reasons:

      1. The tools are effectively hidden by default, meaning people will assume they are not there and have to discover them by accident.
      2. There are use cases where the toolbar is a better place for the functionality.
      3. How will this work with regards to accessibility?

      Also, a question: The toolbar is often used to unstyle content (unbold text for example). This is typically done by placing the caret in a word, not highlighting the word. How will this work?

      • Ella Iseulde Van Dorpe 1:25 pm on September 6, 2016 Permalink | Log in to Reply

        Yeah, a good strategy would be to keep the main toolbar and maybe have it more out of the way in small steps. For example, we could hide it on scroll down and show it on scroll up, instead of leaving it at the top at all times. If there’s a system to get data, we can see how many people use which for bold etc. And sure I don’t expect the main toolbar to go away entirely.

        For screen readers I think you could announce the toolbar which would be even better than it currently is (I think). Moving the focus to the toolbar in an intuitive way is more difficult, but it would certainly not be harder. Maybe @afercia has some insights.

        Not sure about removing styles. If it’s used so much in that way it can be left in the main toolbar. Otherwise it can be added in the contextual one if the selection contains such styles.

      • FolioVision 4:16 pm on September 6, 2016 Permalink | Log in to Reply

        If we really need to duplicate the menu bar functionality, Morten and Iseulde, it seems to me we should not create triplicate functionality. Keyboard shortcuts are already duplicate (and the desirable additional interface as the keyboard shortcuts promote efficiency). If we move the bold italic, strikeout and link functionality into a contextual menu, wouldn’t it be better to free up that menu bar space for other block functionality?

    • Weston Ruter 4:57 am on September 6, 2016 Permalink | Log in to Reply

      Some people do use these tools when no text is selected, meaning to format the word containing the caret. Similarly keyboard shortcuts also work in this case.

      I think I often hit one of these formatting buttons to start/stop formatting. Well, actually, I use the keyboard shortcuts to do this. I think I select text to format less frequently.

      • Omaar Osmaan 6:08 am on September 6, 2016 Permalink | Log in to Reply

        Same here. Mostly keyboard shortcuts to start/stop formatting, rarely the buttons, when I’m writing. While editing/revision, I use the buttons instead of shortcuts.

      • Ahmad Awais 9:54 pm on September 9, 2016 Permalink | Log in to Reply

        Pretty much same here. Keyboard shortcuts FTW. But I like this idea.

    • Andrea Fercia 3:28 pm on September 6, 2016 Permalink | Log in to Reply

      Re: Moving the focus to the toolbar in an intuitive way
      I’ve seen other applications that just insert the toolbar in the tab order, not sure if it’s the best option but sounds like the more intuitive thing maybe. For sure it would require some research and user testing.

      • Ahmad Awais 9:55 pm on September 9, 2016 Permalink | Log in to Reply

        How do you think something like this can be made more accessible? Through keyboard shortcuts or with tab indexes to filter through the options available.

    • Mark Root-Wiley 7:55 pm on September 9, 2016 Permalink | Log in to Reply

      I thought long and hard before responding to try to get all my thoughts together. I spent quite a long time searching for existing user research but barely found any.

      My first question: Particularly given the mobile concerns that probably prevent removing the B / i / link buttons from the toolbar, what’s the goal of adding this feature? Is it primarily about the distance required to move the mouse? Without understanding the driving problem this solves, this first struck me as a solution looking for a problem.

      I also have a few concerns, none of which are all that original:

      • I wonder about how distracting the continual pop in / pop out will be. If the goal of the editing experience has generally been to remove distractions, does this support that goal? I was able to find one very brief source suggesting this didn’t happen when tested with users, but I remain skeptical. If user testing is done, I wonder if testers should perform the same tasks twice, one using the feature and once not in a random order to try to judge preference.
      • Relatedly, besides distraction, the pop up blocks text that’s near the words being formatted. Does this interrupt people’s thoughts more than previously? (I believe Jen Mylo raised this concern regarding the Front End Editor plugin but I can’t find her comment.)
      • In that same vein: Generally speaking, hidden controls don’t just reduce findability to new users, but they also increase cognitive load for all users (both thinking about the hidden controls that are there and remembering the words hidden behind it).
      • The potential for abuse seems very real. I’d honestly recommend not making this extensible if it’s added. Even one or two buttons in it that I didn’t want and never used would make editing a site much less pleasant.
      • This objectively has one downside which is that users can’t select certain words near their selection without clicking out of the current selection. (Example, bolding two words and then italicizing the entire containing sentence.)

      ## Other thoughts

      After the formatting shortcuts for bold and italic were dropped, is this seen as a new alternative to those? Will it be in addition? (i.e. we’ll have at least 4 ways to bold!)


      I AM NOT A SCREEN READER USER but the idea of these being announced every time I select text sounds super annoying. I imagine most screen reader users use CTRL / CMD + B, etc. and so I’m not sure reading buttons aloud will help. But that’s my uninformed gut reaction.


      re: @iseulde

      > we could hide it on scroll down and show it on scroll up

      See concerns about cognitive load above. See Also: “Maximize the Content-to-Chrome Ratio, Not the Amount of Content on Screen”

  • Tammie Lister 6:22 pm on September 1, 2016 Permalink |  

    This is the design chat summary on September 1. (Slack log).

    In attendance was: myself and @mapk

    • We talked about some Customizer tickets that could do with some attention should anyone be able to. #29158, #35210 and #22058.

    It was a great and active chat! Thanks everyone for participating. Next week we’ll be moving to the new(old) meeting time. See you on Thursday September 8th, 17:00 UTC!

  • Hugo Baeta 4:32 pm on August 25, 2016 Permalink |

    Design chat agenda for August 25 

    I’m sorry for the late post, this week’s chat is happening in a few minutes, at 17:00UTC

    Since I didn’t get to post an agenda yesterday, we’re gonna keep it simple today:

    • Design projects for 4.7
    • Plan of action for #27159
    • Open Floor

    If anyone has other tickets the needs attention or other matter for the meeting, feel free to leave a comment with it. See you in a few minutes!

  • Mel Choyce 2:15 pm on August 25, 2016 Permalink |
    Tags: dogfooding   

    Better Dogfooding Tips 

    This was originally written by @karmatosed. I’ve adapted it for WordPress.org.

    Dogfooding is a great way we can use WordPress and test our features. By testing WordPress ourselves, we get to unearth all manner of bugs, issues and fun things. Try setting up a new site from scratch, especially thinking about specific use-cases like a new photoblog, or a company website.

    I thought it would be great to come up with some tips for so new folks doing dogfooding can have a resource to start with. So, without further ado here’s just that!


    How you present the post really helps for people to read and also how we can use later on. A rough format for reporting your observations via video that works is:

    • Title: Make sure your title has the word “dogfooding” in it somewhere, so it’s easy to scan. Also include what feature you’re testing in title. ex: Dogfooding: Theme Setup
    • Use the more tag to shorten posts. It helps keep the p2 streamlined so it’s easier to scan.
    • Talk about your perspective as a user, and what you’re trying to accomplish.
    • Embed the video in your post.
    • Under the video, pull out any key points at minute marks. ex: 01:00: here’s where I spent a whole minute trying to search for directory themes from my installed screen. Keep this list short; don’t worry about pulling everything out, as if this is long, people will be less likely to read. Just make sure to list the biggest finds.
    • After that, it’s often useful to chop up the video (if it’s very long) and pull out significant clips. Making clips like this is useful for bug reporting and summaries. Clips can go after or next to minute marks, and also next to bugs for easier visual reference. Just consider that not everyone will want to watch your entire video. 🙂
    • Bugs: List out any bugs you found while testing. You can even do a fun thing by putting the bug emoji at end to make them stand out: 🐛
    • Summary: Summarize the main issues and conclusions you found from testing. ex: I stumbled a lot with the theme installation process because… If we did x or y it might improve this feature…
    • Tags: Tag it #dogfooding and anything else relevant.

    Here’s what the above would look like laid out:

    1. Dogfooding: Feature You’re Testing
    2. As a user, I’m trying to accomplish x
    3. Video embed
    4. 1:00: something amazing, 2:00: something else amazing
    5. Significant clips
    6. Bugs 🐛
    7. Summary
    8. #dogfooding


    If you see a bug, report a bug. It’s important we follow through on the bugs and don’t just leave them on this p2.

    The same goes for things you think are issues, or even enhancements. Sometimes you may think of something awesome nobody else has thought of before, and it could become something that changes the life of our users. Pretty cool right? That’s why it’s very important to report on trac.

    Enjoy and please dogfood 🐶

    The caveat here is that not everyone can post to p2s. It might be worth opening up make/flow, or liberally granting Authorship over there. I’ll be x-posting this post on that p2 as well.

    Maybe we should do a series of posts around a specific dogfooding topic, that people can comment on? This needs some additional discussion. 🙂

    • Tammie 3:01 pm on August 25, 2016 Permalink | Log in to Reply

      Yay awesome to see this 🙌❤

      I’d be happy to get involved in the starter posts and calls for dogfooding. I would love to see more people get involved. It’s incredible how it opens your eyes and gives you ideas. Also, I’ve yet to do dogfooding anywhere and not find a bug! This means we can fix bugs as we go!

    • Nick Halsey 1:11 am on August 26, 2016 Permalink | Log in to Reply

      I think this also underscores the importance of publishing with WordPress regularly. And going through processes like redesigning your site. There’s no better way to test flows than using them to publish real content.

  • Hugo Baeta 1:48 am on August 19, 2016 Permalink |

    Design chat summary for August 18 

    This is the design chat summary on August 18. (Slack log).

    In attendance was: myself, @michaelarestad, @foliovision, @mapk, @melchoyce, @jorbin, @helen, @westonruter, @remediosgraphic

    • I brought up the WordPress 4.7 Design Wishlist post, and @jorbin mentioned there are a lot of design-focused ideas on Helen’s post on make/core. Comment on one of the other, either is fine.
    • We decided to move the weekly chat time back to 17:00 UTC, starting next week.
    • @celloexpressions brought up a few tickets in the agenda comments that we discussed:
      • #34923 – Allow users to more seamlessly create page-based nav menus during customization – needs better wording for the link to edit a newly-published page. The discussion resulted in a consensus to actually remove the link.
      • #37661 – A New Experience for Discovering, Installing, and Previewing Themes in the Customizer – It needs a lot more UX thought, it wasn’t an easy ticket to talk during the chat as it’s quite intricate. If anyone wants to contribute some UX thinking there, that would be very welcomed!
      • #29158 – Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin – @celloexpressions believes it needs a strategy for back arrow hover/focus styles. in the conversation it became clear that the ticket is becoming too broad, and that some of the things in there needs a prototype for testing. Everyone agreed that the left-border blue indicator should be committed, and that the rest of the ticket should be broken up into smaller tickets.
      • #22058 – Improve custom background properties UI – he wanted us to focus on the last comment that mentions an idea of leaving these decisions up to the themes. The conversation went into a notion that these options are visualizing what the CSS is doing, not necessarily helping the user make a decision. Overall everyone feels that the solution in the ticket is a tad heavy and not really focused on the users. The conversation continued on the ticket itself.
    • @mapk asked for us to help out with some critique on the implementation of the screenshots portion of the plugin page on the new Plugins Repository (in beta). The generalized consensus was that the screenshots should be in order and include the description very clearly, as in current plugin directory they are used to guide users through the usage of the plugin mostly. Questions like “should this be a separate tab” were brought up as well. @melchoyce suggestion was for @mapk to step back and sketch other ideas and consider how both users and plugin developers are using and could use this.
    • We skipped @karmatosed Old Ticket Sweep (but, please, go through them in the chat agenda post!

    It was a great and active chat! Thanks everyone for participating. Next week we’ll be moving to the new(old) meeting time. See you on Thursday August 25, 17:00 UTC!

  • Hugo Baeta 3:19 am on August 18, 2016 Permalink |

    Design chat agenda for August 18 

    This week’s chat is on Thursday, August 18 at 20:00 UTC

    • WordPress 4.7 Design wishlist discussion
    • Design Weekly chat meeting time change
    • Tammie’s Old Ticket Sweep:
      • #29076 – The Minor Publishing Actions (Buttons) need some breathing room
      • #25419 – Add icon support for widgets on the admin page and customize screens
      • #22976 – Remove reference to category to tag converter from the tools page
      • #23477r21789 creates a breaking change in behavior for get_submit_button
      • #33141 – Search form clear button is clipped in Safari (OS X)
    • Open Floor

    If anyone has other tickets the needs attention or other matter for the meeting, feel free to leave a comment with it. See everyone tomorrow!

    • Nick Halsey 3:43 am on August 18, 2016 Permalink | Log in to Reply

      The following tickets need design feedback, and would particularly benefit from discussion during the meeting (see specific points needing discussion in parentheses):

      • Content authorship in nav menus – #34923 (needs better wording for the link to edit a newly-published page)
      • A new experience for discovering, installing, and previewing themes in the customizer – #37661
      • Improving contrast and UI consistency in the customizer – #29158 (needs a strategy for back arrow hover/focus styles)
      • Custom background properties – #22058 (see latest comment, what about leaving it up to themes and taking the burden off of users)

      Depending on the new time, I should be able to start attending the meetings next week.

    • Mark Uraine 5:20 pm on August 18, 2016 Permalink | Log in to Reply

      We’re exploring ways in which screenshots would be displayed in the new Plugin Directory and can use some more feedback.

      As many of you know we’re building a single page layout. So rather than having a full page where we can list several screenshots on top of each other, we have a limited space to show them.

      There are a few examples here where the discussion is continuing:

      Recently, there’s been an idea to use the Jetpack carousel, but how do these screenshots get displayed on the page? Mosaic tiles, square tiles, a slider?

    • FolioVision 4:17 pm on August 30, 2016 Permalink | Log in to Reply

      @karmatosed Thanks for this list Tammie. I’ve picked up #29076, #25419 and #33141 for immediate testing and fixes targeted to 4.7 release schedule (i.e. first revision this week).

      We’re also working on Nick’s Custom Background Properties: #22058.

  • Hugo Baeta 9:48 pm on August 17, 2016 Permalink |
    Tags: 4.7, , wishlist   

    WordPress 4.7 Design Wishlist 

    Hello designers!

    First off I’d like to congratulate everyone on a great 4.6 release yesterday! During this cycle we brought back regular weekly meetings around design – It’s been a learning experience for @karmatosed and I, so we appreciate everyone who’s been actively engaged and supportive.

    Now it’s time to start focusing on what we want to see in 4.7. Had a conversation with @helen (the 4.7 release lead) and she suggested we have a design-focused wishlist post here to expose what is important to focus on in terms of design and user experience. She posted today on make/core about this as well, so you can comment on either post with your ideas. I’ll make sure whatever gets posted here reaches her for consideration. She also wrote a great post with some ideas for the release.

    Let’s get a conversation started!

  • Hugo Baeta 9:13 pm on August 11, 2016 Permalink |

    Design chat summary for August 11 

    This is the design chat summary on August 11. (Slack log).

    In attendance was: myself, @karmatosed, @mapk, @foliovision, @melchoyce, @afercia

    • @celloexpressions had requested for us to bring up #34923 during the chat. It’s a complex ticket, but hopefully it will get some eyes on.
    • During open Floor, @karmatosed shared a list of tickets that need attention:
      • #37384: Text alignment in options-discussion.php – @foliovision is gonna spend some time on this
      • #30599: media views: improve keyboard accessibility avoiding confusing tab stops – We came to the conclusion it doesn’t need ui feedback, it’s a purely accessibility issue
      • #32194: Post Locked Notification Dialog is not Responsive – @mapk found a bug in there and is opening up another ticket for it. @foliovision is also looking into it
      • #26605: Appearance of recent/future posts in dashboard looks off on mobile.
      • #27253: Enhancement Request: direct link to Drafts under Posts and Pages on the sidebar – I added a quick inspector mockup screenshot to the ticket to help visualize it.

    We’ll be back next week on Thursday August 18th, 20:00 UTC!

  • Tammie Lister 9:57 pm on August 4, 2016 Permalink |

    Design chat summary for August 4 

    This is the design chat summary on August 4. (Slack log).

    In attendance was: myself, @hugobaeta, @foliovision, @ocean90, @petya, @melchoyce, @samuelsidler, @afercia, @presskopp

    • The about page was discussed #37246. It’s close to release and @hugobaeta led us through the latest iteration.

    We’ll be back next week on Thursday August 11th, 20:00 UTC!

  • Hugo Baeta 9:17 pm on July 21, 2016 Permalink |

    Design chat summary for July 21 

    This is the design chat summary on July 14. (Slack log).

    In attendance was: myself, @karmatosed, @FolioVision, @mapk, @voldemortsen.

    • I gave a short update on the status of the about page #37246. Things are moving along and I’ll begin working on the layout of the page this week (here is a collection of past About page designs). @mapk is continuing the work on the shiny updates interactive bit (fallback for when the users have no updates), and I’ll circle back to the Native Font one.
    • WordCamp Brighton is happening this weekend and there’s a contribution day. @karmatosed will be there and is asking for tickets to work on – se feel free to reach out to her!
    • @FolioVision brought up #36999 – he updated the ticket with the requested screenshots and it seems ready for commit. @karmatosed and @voldemortsen +1’d it.
    • A discussion about the overuse of `!important` spawned off of the previous ticket, and there’s a ticket for an `!important` audit: #26350

    We’ll be back next week on Thursday July 28th, 20:00 UTC!

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar