WordPress.org

Make WordPress Design

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Hugo Baeta 7:02 pm on March 30, 2016 Permalink
    Tags: cross-posting, meta, research   

    If you’re curious about design for WordPress.org, I just posted extensive UX research survey results about WordPress.org network of sites on the meta p2 😉

     
  • Mark Uraine 10:30 pm on March 15, 2016 Permalink |  

    Various Web Store Flow Explorations 

    Along the lines of this post from @helen, and in relation to the Plugin Directory IA, I’m sharing some flows from other popular web store experiences. This is exploratory research for the Plugin Directory.

     

    FLOWS

    Code Canyon (https://cloudup.com/cbQSIYi5jUf)

    Sketch App Resources (https://cloudup.com/cEq1yIwY5NM)

    Steam (https://cloudup.com/cHiTsgm1U9R) via @markjaquith

    XBOX Store (https://cloudup.com/cUcVXIynaPa)

    Playstation Store (https://cloudup.com/cyK7tf-YlcC)

    Amazon App Store (https://cloudup.com/cng1vG1MzhT)

    Mac App Store (https://cloudup.com/c-annTJSdGh)

    Windows App Store (https://cloudup.com/cBLTp69gtv4) via @michael-arestad

    Google Play Store (https://cloudup.com/cpwbEDBa94v) via @ryan

    NPM Packages (https://cloudup.com/cX2qE9HThDs)

    Atom Package Manager (https://cloudup.com/cA073Aae_FU) via @michael-arestad

    Chrome Extensions (https://cloudup.com/ck-GUY0sjoO)

    Firefox Plugins (https://cloudup.com/cbHEKKMxY36)

    Safari Plugins (https://cloudup.com/ch_bI5-Cajd)

     

    FEATURE COMPARISON

    Web Store Feature Comparisons

    Web Store Feature Comparisons

     

    TOP COMMONALITIES

    1. Description (Often times this ONE section contained the description/FAQs/Other Notes, etc.)
    2. Author
    3. Download/Install Button
    4. Screenshots
    5. Reviews
    6. Ratings

     

    FEEDBACK

    What are your likes and dislikes between these? Are there popular design patterns that would be useful for our Plugin Directory? Please leave feedback below.

    If you have other flows that you think would be helpful, please link to those as well.

     
    • Hugo Baeta 11:29 pm on March 15, 2016 Permalink | Log in to Reply

      This is super useful! Thanks for putting this refreshed list together. I was looking through the “Feature Comparison” spreadsheet, and one note is we should probably separate “Download” and “Install”, since some stores allow you to install directly from their pages (like Google Play, which is awesome because you can select from the web what device you want the app installed in, it works like magic, I love it). 🙂

      • Erlend Sogge Heggen 9:46 am on March 16, 2016 Permalink | Log in to Reply

        An “Install” button could be possible with Jetpack.

        Prerequisite: Support Jetpack logins on WordPress Plugin Directory

        Example use case

        1. Click “Install this plugin”
        2. Background process checks with your Jetpack account to see what WP sites you’ve connected it to.
        3. Show user a list of sites they may choose to install this plugin on (just like Google Play)
        4. User selects a site
        5. Directory site goes “Installing…” while also providing you a link to your site’s backend.

        • Mark Uraine 3:00 pm on March 16, 2016 Permalink | Log in to Reply

          We’d probably have to do the check prior to page load, yes? I wouldn’t want to show an ‘Install’ button if the user doesn’t have Jetpack installed or is not logged in… unless the button prompts the user to log in if they’re not and then performs a check. And if they ARE logged in, it can check but error out if the user doesn’t have Jetpack? I don’t think that’s a solid experience. Right now, on the .ORG side, I’m not sold that an “Install” button will work smoothly.

        • Anton Timmermans 7:20 pm on March 17, 2016 Permalink | Log in to Reply

          I would prefer a plugin agnostic solution.

          On possible solution would be something like Shopify has on their store. When a user clicks on install they are given a form to fill in their site URL. We could do something like that asking a user for their site URL. See https://cloudup.com/csHVLs-ceGg.

    • Mel Choyce 3:22 pm on March 16, 2016 Permalink | Log in to Reply

      Really great research and comparison! 🙌

      Some general thoughts:

      • I think Code Canyon has the right idea emphasizing search
      • Featured plugins probably won’t change often enough to justify giving them larger banners or emphasizing them more than we do currently
      • Popular plugins, though, would be good to emphasize more, maybe by using their banners instead of their icons
      • (On that note, we should consider hiding things like the Importer plugins and Hello Dolly from popular)
      • Grids consisting of just icons get overwhelming pretty fast and my eyes tend to gloss over them
      • NPM’s “Getting Started” instructions at the bottom of the page are nice
      • Atom’s “Available Updates” section would be a nice addition to core
    • Mark Uraine 10:27 pm on March 18, 2016 Permalink | Log in to Reply

      Features we offer that were rarely used by anyone else:

      • “FAQ”
      • “Other Notes”
      • “Changelog”
      • “Stats”

      Features common with others but not with us:

      • File size
      • Related downloads/plugins
      • Category identification
      • Social sharing buttons

      I also like how CodeCanyon emphasizes Search. Even their search results page offers more ways to refine the search in the sidebar.

      Grids do get overwhelming when it’s just some little icon. When I see crap like that, I go immediately to the search field. I like how we treat them more as cards with additional info mixed in with the icon.

      I also like the little stats at the top of NPM to give a high level view of what’s going on with their directory.

  • Tammie 2:04 pm on February 5, 2016 Permalink |  

    Revisions UI focus kick off post 

    As @michael-arestad announced, I’m going to be leading a focus on the Revisions UI. This post is the first step on the path to starting to think about how we approach the Revisions UI.

    Background

    This project stems from some interesting discussions at the community summit between @melchoyce, @michael-arestad and @adamsilverstein. It will probably include some way to move between revisions quickly and a revised interface for viewing. This is an opportunity to rethink what we have right now.

    Here is what Revisions currently looks like:

    2016-02-05 at 10.06

    2016-02-05 at 10.08

    Process

    One thing we need to do is ensure we tackle this with a proper process. The structure would be something like:

    • Research: comparative, survey, discussions and trac ticket analysis.
    • Mockups for entire process. This will be influences by the earlier research.
    • Plan. It’s important that the plan is broken down into sensible timeframes to push the project on and get delivering.

    As each section happens the development process should be:

    • Mockups and lo-fi ideas
    • Testing
    • Iteration
    • Testing
    • Development
    • Testing
    • Release

    We also shouldn’t be afraid to go back at any point to revise and iterate. Testing is really important even if it may be peer at times. This way we can easily and swiftly test even the crazy ones – the ones that may just turn out to be the right direction.

    Timeframe

    This focus isn’t something that will result in a deliverable tomorrow. The first process of research I would like to kick off this week and expect research to take a few weeks as we work out the direction for the project. There will be regular posting on this blog for updates.

    Everyone is welcome

    If you are interested in joining us for this ride, let us know in the comments. As things process, we’ll be doing specific calls for tasks. Initially the plan will be to use the design open hours for anything that comes up. As we move into actually developing, we can look at going the route of other feature plugins, if that is needed in Slack.

     
  • Mel Choyce 6:27 pm on January 26, 2016 Permalink |  

    Design Office Hours 

    Have questions or need feedback on core or community design projects? @michael-arestad and I are establishing biweekly design office hours in #design on Slack. We’ll be around from 20:00 UTC to 21:00 UTC each Tuesday and Thursday.

     
  • Mark Uraine 8:53 pm on January 21, 2016 Permalink |  

    New Login Design 

    Hey community! – My name is Mark and I’m a recent addition at Automattic as a Designer on the Apollo Team focusing on Core and WordPress.org. This is my first WordPress.org design project. 🙂

    We recently launched the new login redesign for login.wordpress.org. I really enjoyed learning the processes for undergoing this sort of project and have learned even more now that it’s live – thus my post here on the /design blog.

    There were a few things that brought this redesign into fruition. The first being the incorporation of OAuth – sort of like a single sign in for some of our sites (coming soon). The other was a desire to differentiate it from the WordPress installations.

    wordpress.org-login

    For the sake of comparison, here’s what the WordPress.com login page looks like.

    With that said, I designed variations that would distinguish this login page from self-hosted sites and still hold true to .ORG’s branding, colors, and tone. As I’m still learning processes here with the community, I reached out to others and got some great feedback during it all.

    Another consideration in designing WordPress.org sites is the perceived “dated” appearance. Last summer, @hugobaeta did extensive UX research. As improvements are made to WordPress.org sites, we want to improve the design incrementally as well.

    Here’s the design we launched earlier this week.

    new-wporg-login

    What’s changed?

    1. A darker background
      1. I wanted to stick to the WordPress.org brand colors and thought this dark background (same as the current .ORG header) would provide the contrast and deviation to set it apart.
      2. The dark background here is only meant for the login/OAuth process and not for the entirety of WordPress.org.
      3. There’s also been some concern that the dark background is too different from the rest of design of WordPress.org. We’ve been exploring iterations and concepts, some of which can be viewed here.
    2. The WordPress logotype
      1. I opted to use the full logotype of WordPress to help provide the visual difference as well.
    3. I removed the box from the form
      1. This allowed for more flexibility when inserting some of the partner site information for OAuth onto the page.
      2. There are less constraints as to how the form balances with this information.
      3. The form fields stand out against the background bringing focus immediately to the action required.
    4. The footer
      1. Added smaller text at the bottom stating ‘WordPress.org’ for additional clarity.
      2. Retained the tagline from the inner pages ‘Code is poetry’ here as well.
    5. Tightened up the links below the form to keep things as high on the page as possible, especially on mobile devices.

    There’s been great feedback since launching, including a few suggestions for improvement:

    1. The contrast of labels against the background needs improvement.
    2. Revise the button to align better with the styling from wp-admin buttons.
    3. Add some letter-spacing to the footer text.
    4. Revert back to the ‘W’ mark instead of the whole logo. (I’m still at odds with this one for clarity purposes) 🙂 Maybe the logotype should include the “.org” as it does in the site header?
    5. Work in some intro text to explain exactly what this login is for.

    Do you have other ideas for the login page? What do you like? What do you hate? What improvements can be made?

     
    • Konstantin Obenland 8:59 pm on January 21, 2016 Permalink | Log in to Reply

      Good job Mark!

      Revert back to the ‘W’ mark instead of the whole logo.

      I, for one, like it with the whole logo. I’d even go as far as using the regular WordPress.org logo.

    • Ben Hansen (ubernaut) 9:06 pm on January 21, 2016 Permalink | Log in to Reply

      very nice! i think adding the .org is good idea.

    • Josh Pollock 9:20 pm on January 21, 2016 Permalink | Log in to Reply

      I like this new design. One thing that is really good about the current login design for WordPress.com is it says “WordPress.com”. Why can’t this login say WordPress.org on it?

      I know the browser bar says that, but we all know that the confusion between WordPress.org, WordPress.com and every other WordPress-powered site. Any work to make it as explicit as possible that they are signing into their WordPress.org account is good in my book.

    • Hugo Baeta 9:26 pm on January 21, 2016 Permalink | Log in to Reply

      FYI, the discussion is still going on the ticket as well: https://meta.trac.wordpress.org/ticket/1524

    • Zack Katz 9:34 pm on January 21, 2016 Permalink | Log in to Reply

      I think the placement of the form feels strange, considering that there are now no borders. Check out Squarespace’s login form: https://store.squarespace.com/config/

      There are a few things Squarespace does that I like:

      • Centering the form vertically
      • Use a subtle radial gradient adds dimension
      • Use placeholder text instead of labels (I know there are backward compatibility issues here)
      • The logo size feels more in scale with the login form
      • Better wording (“Stay logged in” instead of “Remember me” – backward compat, I know)
      • Inline “Forgot” links allow users to not look around from where their focus already was
    • Jon Brown 10:46 pm on January 21, 2016 Permalink | Log in to Reply

      Looks really good!

      +1 on vertical centering.
      +1 on liking the SS form a lot, particularly the input fields just being lines (instead of boxes) when frameless.
      +1 placeholder text instead of labels

      One of things that many years ago caused me _great_ confusion for many months of frequent password resetting was that this login is actually shared by wordpress.org, buddypress.org and bbpress.org.

      Nevermind that I think they should NOT be shared logins… it should however be clear to users that this is a shared login for all the sites one is logging into (I think that’s happening soon-ish?).

      In that regard what about representing that to users with something like this: https://cloudup.com/cOrYv4l4r-7

      Note: m not sure I like this exact idea aesthetically just the idea of showing logos some how of all that is being logged into to reduce confusion.

    • Tom J Nowell 10:47 pm on January 21, 2016 Permalink | Log in to Reply

      I have to squint to see the text in between the fields, there needs to be more contrast. Right now it looks nice, but disregarding aesthetics it’s much harder to read with the huge contrast between the boxes and the background next to the low contrast of the labels etc

    • Mark Uraine 4:54 pm on January 22, 2016 Permalink | Log in to Reply

      Excellent feedback! I’d like to address some of it.

      1. Talks about needing the ‘.org’ in the logo have been brewing so there’s obviously some justification here.
      2. Accessibility issues should be resolved now.
      3. I do like Squarespace’s login page, but I think the input field design would veer too far from the rest of the form fields across our site. I guess another question is how far are we willing to break away from our standards on a login page?
      4. Using placeholder text instead of label – I’ve always liked this better too, but it does have usability downsides, especially if we consider focusing cursor on first input when page loads.
      5. Centering form vertically is cool. Logo sizing adjustment is cool. Alternate wording is possible too.

    • Tehran Site Design 4:25 am on January 28, 2016 Permalink | Log in to Reply

      Very Nice Mark, i will use it in my website:
      http://tehran-site-design.com

    • Mark Uraine 1:38 am on February 11, 2016 Permalink | Log in to Reply

      Just pushed a revised login page based on feedback here: https://meta.trac.wordpress.org/ticket/1524

    • remediosgraphic 7:19 am on February 15, 2016 Permalink | Log in to Reply

      it looks very nice, very clean and high contrast.

  • Michael Arestad 4:03 pm on January 11, 2016 Permalink |
    Tags: , post-new, pulishing   

    Improving Post New 

    Before I get into it, I’m going to need help to get some of these projects going. If you see something you’re interested in working on, let me know in the comments. The following project proposals are not intended to be a single feature plugin because they are separate projects with separate goals.

    I could use your help with:

    • running usability tests
    • putting out a survey
    • design
    • managing some of these projects
    • development
    • testing (including accessibility testing)

    The process

    Before we get into designing, we need to do discovery (research) and a clear idea of which specific problems we’re going to solve. All of these will require research, some usability tests, maybe a survey or two,

    Potential projects

    I did a bit of searching on Trac (and am still doing so) specifically looking for anything related to posting or content creation. I have started some initial researching on anything related to creating content. I looked as past usability tests. I looked at some feedback around WordPress.com’s editors as well. We can learn from some of the ideas tried there.

    The following are a list of project ideas. If some get interest and traction, we will do a kickoff post for it (depending on scale) and I’ll add any resources/related information I’m aware of. Ideally, I’d like one of you to step up and lead a few of these if you have the time and are interested. If you have something you’d like to add as a potential project idea, please let me know in a comment.

    Publishing UX

    @helen brought this up as a project idea and it’s a good one. Here’s the proposal:

    When running user tests for post formats during the 3.6 release cycle, one of the most striking observations was that a majority of users had a hard time locating the Publish button at all. Because it’s typically in the top right, it’s possible it’s not on the screen, and is very disconnected from the general content workflow of writing and then publishing. The most common idea is to put the buttons in the bottom bar of the editor, since it pins and makes sense within a writing flow. There are, as always, other considerations to make, such as post types without an editor or various post statuses (another problem in the current box – you can’t actually have a private draft, because it’s the same field in the database). This project would likely involve multiple approaches, storyboards, mock ups, and lots of user testing through all stages.

    Related ticket: #17028

    Shiny saving

    Currently, when saving or updating a post the whole page reloads. The page reload makes it easy to lose your place when saving or updating. Because of the page reload, saving feels slow.

    My proposal is to introduce Ajax saving to prevent the page reload. This will introduce new problems to solve. We’ll need a way to provide feedback to the user about the status of a save. It will need to be accessible. I believe those are both doable.

    Related tickets:

    Toolbar remix

    I’d like to see what we can do to improve the editor’s toolbar. This will likely include a bit of button shuffling and some style changes. For example, I think the drop down to select the type of text (heading 1, paragraph, preformatted) should be in the primary toolbar rather than in the kitchen sink.

    Related ticket: #27159

    Post New UX

    I’d like us to take a look at the Post New UX as a whole. This might result in some mini projects/experiments rather than being a single feature plugin. I suspect the space could be utilized more efficiently. We can probably also make Post New feel a bit less overwhelming for newer users (I don’t want to remove functionality at all).

    Metabox physics

    Metaboxes are helpful. That’s why we have so many of them, right? Let’s see what we can do to make them part of the posting flow rather than a bunch boxes of settings that we have to battle before publishing anything. This project will need a good amount of love and research and will need to consider how plugins/themes use or hijack them. This might be a good place to provide some patterns or suggested design practices as a resource for plugin authors.

    Autosave

    I think if we implement Shiny Saving, we can definitely have autosave functionality. When digging through WordPress.com editor feedback, autosave was almost universally loved. It does have some awkward issues with revisions, but I’ll talk about revisions in a second.

    Revisions UI

    This is a bigger less-urgent project (unless we get Autosave in), but I think the revisions interface could use a bit of a rethink. It is currently a bit difficult to use and understand. I know @melchoyce had come up with some promising ideas during the community summit when we were discussing it with @adamsilverstein. This project will likely include some way to move between revisions quickly as well as potentially showing a different interface for viewing changes.

    Don’t break my divs

    It’s really easy to break just about any theme by forgetting to close a `div` or a `span` (and some other elements). I’m wondering if we can do something to warn users about unclosed html elements to give them some idea why their preview is looking funky. I wouldn’t try to autoclose tags.

    Live preview

    Wouldn’t something like a live preview (even if it’s tiny or off screen) be pretty handy? I think so.

    Proofreading mode

    I’ve had quite a few people request some sort of proofreading mode that allows them to comment/highlight/interact with post content. This is in the realm of projects I’m not sure are right for WordPress core, but might just be. Even if it isn’t, it could be a pretty dang rad plugin (if there isn’t one already).

    Content blocks?

    I was hesitant to add this as it’s been attempt a few times in the last few years (RIP CEUX). The idea of content blocks has come up again in conversation a few times over the last few weeks so I think we should revisit it with vigor. I know the Shortcake group is looking at an interface that might go hand in hand with a content block interface. The initial Shortcake implementation could be great first steps toward the block editor some of us dream about (or have nightmares about).

    Thoughts?

    If you are interested in tackling any of these, have a proposal in addition to these, or are have concerns/thoughts about a project, let me know in a comment.

     

     
    • Tammie 4:18 pm on January 11, 2016 Permalink | Log in to Reply

      This is awesome! Thanks so much for taking the time and leading the charge on this @michael-arestad. I’m really excited about what a focus on improving new posting will bring.

      I’d love to be involved in usability tests, surveys and design. I am also happy to manage one and would be interested in Publishing UX and/or Post New UX (happy to take on more than one).

      I’d also be happy to be involved Revisions UI as I already have worked in that area and absolutely feel that work needs still to be done. That would be more a secondary role as know there is already some great ideas to work from.

    • mapk 4:44 pm on January 11, 2016 Permalink | Log in to Reply

      Count me in. I’m up for usability testing, design, and managing a project as well.

    • jaragozzine 4:56 pm on January 11, 2016 Permalink | Log in to Reply

      I’m up for any of the bulleted items above. Very exciting!

    • Zack Katz 6:13 pm on January 11, 2016 Permalink | Log in to Reply

      I’m in.

    • Hugo Baeta 1:39 am on January 12, 2016 Permalink | Log in to Reply

      Count me in as well, you know where my strengths lie, so feel free to ping me and assign me to whatever you think I’d be of help. I’m particularly interested in the “Toolbar remix” stuff 😉

    • askoxyz 2:19 pm on January 13, 2016 Permalink | Log in to Reply

      @michael-arestad, I’d like a better custom field editing/creating/deleting experience as well. Like, maybe instead of having them below the post editor, use a modal like Squarespace 6 did modals (https://d1w5usc88actyi.cloudfront.net/wp-content/uploads/2013/07/1-Make-a-products-page-710×407.png). I think there’s a lot to learn from Squarespace UX as a whole with no need to copy them.

    • chatmandesign 3:55 pm on January 13, 2016 Permalink | Log in to Reply

      In regards to meta-boxes, I’ve created a simple plugin I’m calling Metaccordion that I’m currently beta testing on one site in development. It adds CSS/JS to convert the never ending list of meta-boxes that allows Publish to scroll off the screen into a fixed position accordion sidebar, with Publish always expanded. This keeps Publish where we’re all used to it being (and avoids any issues with post types without editors), but also ensures it’s almost always visible (the sidebar can be scrolled if there’s too many items to fit, but because the boxes are collapsed, Publish is never far away).

      I’ve found that when editing post types with a significant number of meta-boxes, this condensed UI makes finding the ones I want much, much easier.

      One further step I’d like to take to streamline the meta-box UI would be to group together related meta-boxes into a single expandable item. I’m currently using it on a WooCommerce site, and under any product I have expandable meta-boxes for Product Categories, Product Tags, and Brands. Instead, I’d like to have one item that says something like “Categories & Taxonomies” and expands to show all three of those options. So far I haven’t had time to do this, in part because it requires re-jiggering the DOM and I’m a little concerned that it could break some meta-boxes for some plugins, if they weren’t implemented flexibly enough.

      I believe WordPress.com launched a new post editor UI with elements similar to this not too long ago and received generally positive response to the changes.

      I don’t know if that’s the sort of thing you had in mind, but I’d be happy to contribute what little I have so far, or to further discuss ideas on streamlining, if any of this seems helpful.

      • Michael Arestad 4:57 pm on January 13, 2016 Permalink | Log in to Reply

        That is indeed one of the things I wanted to try. Awesome. Could be a good start for usability tests.

        • chatmandesign 6:53 pm on January 13, 2016 Permalink | Log in to Reply

          Ok, I threw my code up on GitHub:

          https://github.com/cdCorey/metaccordion

          It’s an early development build (written originally as a quick monkey patch for my own use), but it’s been working great for me so far. It should definitely work for usability tests at the very least.

          If anyone cares to contribute, I’m happy to accept pull requests, or of course you can fork it if you’d rather manage things that way.

    • chatmandesign 4:10 pm on January 13, 2016 Permalink | Log in to Reply

      Here are a couple quick screenshots of my plugin, if anyone’s interested:

      Closed: http://glui.me/?i=7wiix0f8v0vmjed/2016-01-13_at_10.02_AM.png/
      Open: http://glui.me/?i=w2onxkp30lxbndg/2016-01-13_at_10.06_AM.png/

      It’s a simple change, but it lets me see all the sidebar meta-boxes at a glance, and I’ve found that to make working with them a lot easier.

    • askoxyz 4:53 pm on January 13, 2016 Permalink | Log in to Reply

      @chatmandesign that’s neat! I could definitely use that. I think that would be a great solution for custom fields as well that are under the post editor. With some sort of + and – icons next to them to add and/or delete.

    • susanasalgado 5:38 pm on January 13, 2016 Permalink | Log in to Reply

      Hi! Count me in! Research, Surveys, Usability testing and/or managing a project.

      • susanasalgado 2:54 pm on January 14, 2016 Permalink | Log in to Reply

        @michael-arestad maybe it’s important for you to know what projects interest me the most:

        • Publishing UX
        • Post New UX
        • Live preview

        Nowadays we work with several big companies that use WordPress in a daily basis so we have access to a lot of potencial users for tests.

        Really want to work on a project like this and improve the user’s experience.

    • Chris Smith 8:37 pm on January 13, 2016 Permalink | Log in to Reply

      @michael-arestad count me in as well: Dev, research, testing, managing pieces

      As far as the projects go, I think the ones that sound the most interesting to me are:

      • Publishing UX, though I am initially leaning more towards a fixed scrolling box/button rather than tying it to the editor for the reasons @helen mentioned about CPT’s without.
      • Shiny Saving, I think this could be tied into the publishing UX as a related project
      • Metabox physics
      • Don’t break my divs
      • Live preview
    • Ahmad Awais 6:42 pm on January 15, 2016 Permalink | Log in to Reply

      Shiny Save would be great!

    • Mel Choyce 11:10 pm on January 15, 2016 Permalink | Log in to Reply

      @karmatosed @mapk @jaragozzine-1 @katzwebdesign @hugobaeta @chatmandesign @susanasalgado @chris_d2d @mrahmadawais and anyone else interested in working on Post New, would you mind filling out this survey?

      http://13233232.polldaddy.com/s/wordpress-org-improving-post-new

      @michael-arestad and I are going to start organizing projects in the next week or two.

    • susanasalgado 11:52 pm on January 15, 2016 Permalink | Log in to Reply

    • Ahmad Awais 6:31 am on January 16, 2016 Permalink | Log in to Reply

    • Ryan Boren 3:25 pm on January 17, 2016 Permalink | Log in to Reply

      Right on. I’ll help with testing and support, especially on touch devices.

      This ticket has some related post new ux discussion. https://core.trac.wordpress.org/ticket/29989

    • David Yarde 7:25 pm on January 19, 2016 Permalink | Log in to Reply

      Definitely interested in helping in any of the areas mentioned. Filled out the survey as well!

    • Stagger Lee 8:14 am on January 21, 2016 Permalink | Log in to Reply

      From my personal experience working with Post edit screen I dont find it much problematic working with many metaboxes as long as most of them are collapsed.

      One thought often crossed my mind. “I would like to have one JS button now to open/close, toggle on/off all metaboxes”. Besides ability to toggle them on/off one by one. Just one JS button for toggle would be enough for me, minus toggling metabox holding “Save” button perhaps.

    • Giuseppe Mamone 8:49 pm on January 21, 2016 Permalink | Log in to Reply

      Filled out the survey 🙂 I’m interested in helping in my spare time and getting to know you all.

    • FolioVision 11:36 pm on January 21, 2016 Permalink | Log in to Reply

      Hi Michael,

      Some great ideas here.

      Shiny saving would be a big improvement, along with a more solid revisions manager. One click to make all the extras disappear and reappear would be great. Mini-plug: our own FV Clone Screen Options is a big help in rolling out identical workflow editing experience among a less technical team. When trying to improve workflow, adding something similar to core (managing screen options for a team might make sense).

      Where we might be able to contribute code:

      • Revisions. Revisions more than three old could be retained on amount of difference (i.e. near identical revisions would be deleted first)
      • Previews. For our own editor Foliopress WYSIWYG (currently in maintenance mode as it’s FCKeditor based while CKeditor is current), we simple made FCKeditor parse and show the CSS styles for the #content box. Makes a world of difference. This should be built into WordPress. Martin and I would be happy to give this a try if there’s interest in real WYSIWYG preview for core.
      • Broken Divs. Great idea. I’d suggest some kind of pop-in or pop-up syntax editor which is not dependent on TinyMCE. Too many javascript dependencies will kill you here (js WYSIWYG editors are hard as we know from long experience). To smooth the experience, one could make Syntax another tab next to Visual and Text (although it would really be running its own miniature environment). There could be a general option in Settings/Writing to enable or disable the Syntax tab.

      We could help right away with Revisions and Previews. We don’t have enough experience with syntax repair libraries to provide prompt help.

      You can find us as FolioVision here or @foliovision

      Thanks, Alec

    • Matthew Haines-Young 2:01 pm on January 22, 2016 Permalink | Log in to Reply

      Great idea. Would love to see Shortcake as part of a broader push towards a better publishing experience!

    • Mark Root-Wiley 1:51 am on February 9, 2016 Permalink | Log in to Reply

      Hopefully better late than never, I’d be interested in helping, specifically with Toolbar remix. I’ve written (https://mrwweb.com/wordpress-formatting-manifesto/) about a lot of the issues mentioned on #27159 and have a plugin that implements what I think a lot of us what to see from the project (https://wordpress.org/plugins/mrw-web-design-simple-tinymce/).

  • Jen 5:49 pm on January 4, 2016 Permalink |
    Tags: annual survey, contributors   

    2015 Contributor Survey 

    Hi design folks! Thanks for all your hard work and contributions in 2015. Could you contribute few more minutes to fill in the 2015 contributor survey? It will help us establish some baselines around the contributor experience so that we can see how things change over time.

    **This is being posted to all the Make teams, so if you subscribe to a bunch of p2s and keep seeing this post, know that you only need to fill the survey in once, not once per team.**

    The survey is anonymous (so you can be extra honest), all questions are optional (so you can skip any that you don’t want to answer), and we’ll post some aggregate results by the end of January. It took testers 5-10 minutes to complete on average (depends how much you have to say), so I bet you could knock it out right after you read this post! 🙂

    There are two sections of the survey. The first has questions about team involvement, recognition, and event involvement, and is pretty much what you’d expect from an annual survey (which teams did you contribute to, how happy are you as a contributor, etc).

    The second section is about demographics so we can take a stab at assessing how diverse our contributor base is. All questions are optional, but the more information we have the better we can figure out what we need to improve. If there’s some information you’d rather not identify, that’s okay, but please do not provide false information or use the form to make jokes — just skip those questions.

    The survey will be open until January 15, 2016. Whether you have 5 minutes now, or 10 over lunch (or whenever), please take the 2015 contributor survey. Thanks!

     
  • Helen Hou-Sandi 4:58 pm on September 17, 2015 Permalink  

    Potential UI/UX projects in core 

    It’s not uncommon for both existing and potential contributors to feel like they don’t know what to work on. Let’s try listing a few UI/UX items that have come up on wishlists in this post, both as a temporal call for interested parties and to reference later. If you’re interested or have another frequently-requested item in mind, sound off in the comments or join us in the #design channel in the Make WordPress Slack.

    When changing UX, it’s important to be running user tests and surveys. These can be done lo-fi, such as with index cards or a questionnaire, or as high fidelity as using a functioning plugin and a user testing service. It’s also important to assume that it will take multiple iterations to get there and to avoid becoming too attached to a single approach.

    Publishing UX

    When running user tests for post formats during the 3.6 release cycle, one of the most striking observations was that a majority of users had a hard time locating the Publish button at all. Because it’s typically in the top right, it’s possible it’s not on the screen, and is very disconnected from the general content workflow of writing and then publishing. The most common idea is to put the buttons in the bottom bar of the editor, since it pins and makes sense within a writing flow. There are, as always, other considerations to make, such as post types without an editor or various post statuses (another problem in the current box – you can’t actually have a private draft, because it’s the same field in the database). This project would likely involve multiple approaches, storyboards, mock ups, and lots of user testing through all stages.

    Comment Management Overhaul

    A lot of strides have been and are being made in the Comment API behind the scenes, but we still have a generally dated comment moderation experience, from the list to the edit screen to the moderation screen shown when following a link from notification emails. This is a good project for a team to brainstorm on before attacking: What does a good comment management experience need? How do we accomplish that within WordPress?

    There are also some smaller tasks that could be tackled, such as UI improvements. For instance, right now comments are presented with an interface that is very similar to post editing and without much context. What if comments looked and felt like comments while editing (showing an avatar, a better general layout, etc.)? What kind of contextual information would be helpful to show?

    Small screen flow

    The admin adapts fairly well to small screens. There are some places where what’s critical or important on a given screen is overwhelmed by other items. Some particular offenders are the theme/plugin/media filters, filtering and navigation on content lists, and the additional buttons that often appear next to the “Add Media” button above the editor. The content in those areas stacks up and pushes down the primary content below, sometimes completely off the initial screen. We want UI to direct user focus to what they want or need to be doing, and these particular visual components are major offenders against that.

    Tickets: #32558 for the filter bar, #29989 for the media and related buttons.

     
    • Tom Ryan 6:13 pm on September 17, 2015 Permalink | Log in to Reply

      Much of WordPress’ future potential growth will come from new users and the current interface is unnecessarily arcane in many areas (It’s not anyone’s fault, it’s just evolved that way). Here are a few UX areas that could use some help in WP:

      1. Menu Hierarchy – Need a top to bottom review of menu consistency throughout WordPress. The original menu structure was developed when WordPress was mainly a blogging platform. It’s very cumbersome when you are trying to develop a full blown site in WP, rather than just publishing a blog post.

      2. Nested Menuing System – The current menu system breaks down after you get more than one level deep. Then yous have the Customizer, which has a completely different menuing system. This has lead developers to create their own menu systems, which makes the WP UX inconsistent from theme to theme. WordPress needs to provide theme and plug in developers a way to do all of their interface within the WP menu system, rather than having to create their own.

      3. Menu Consistency – This is a related to #2 above. WP has the top menu bar, the admin menus and the Customizer menus, which all feel like they are completely different products. Many of the settings overlap and make no sense to end users.

      4. Integrate “Page Preview” Into the Interface — Currently the Customizer is essentially the “page preview” feature of WP.. Rather than being integral to the main interface, it jolts you into a completely different interface, which overlaps in functionality with other areas of WP. There are ways to integrate the Customizer functionality into the main interface so that it WP becomes a more cohesive product.

      5. Settings Organization — Ensure better consistency of how to adjust settings. Sometimes plugin developers will put their settings under Settings, sometimes it will be in a new top level menu. Sometimes you can get to settings from the plug ins page, sometimes you can’t. Many of the WP core settings have the same issues. There should be a more clear delineation between standard settings and setting added by plug ins. It often hard to find the settings you wan to change because the Settings menu is so large and not organized into core and plug in settings.

      Currently, using WP to create and manage web sites is a “less than delightful experience” The changes above would really go a long way to clear up some of the cruft and make the WP interface easier to work with.

      I’m not a developer, but I would be happy to help with the process in any way I can.

      • allstar 4:10 pm on September 18, 2015 Permalink | Log in to Reply

        Just as you have inactive widgets it would be nice to have inactive menu items as well. There is some overlap when you start to look at Menus and Widgets, both have locations, active, inactive and order. Differences being static-sih individual menu items versus a widget’s instance
        functionality and linear widgets versus multidimensional menus.

        I’m stating something I see in an effort to be constructive. I know a merge would be difficult and an overlap of functionality complicated but it offers a possibility of having similar interfaces and for new people less learning can only be good.

      • dlouwe 12:25 am on September 19, 2015 Permalink | Log in to Reply

        A personal pain point somewhat related to #2 is the method for removing menu items. One or two items are simple to remove, but trying to remove 5+ is a tedious nightmare. A way to bulk delete menu items would save so many headaches.

        Also in regards to #5, this is likely something that would need to be put into the plugin submission guidelines and enforced by the plugin review team, rather than something implemented in core. I can’t imagine a good way to prevent plugins from modifying the admin menu however they please, so this kind of organization would need to happen at the community level.

    • raulalgo 6:36 pm on September 17, 2015 Permalink | Log in to Reply

      Hi,

      I’m fairly new here but I’ve been willing to collaborate for a while. I’m UX designer with big experience on mobile and long time user of WordPress.

      I’ll be happy to give a go at some elements on that list.

      Is there any priority among them?

      • sanit.tmg 9:58 am on September 19, 2015 Permalink | Log in to Reply

        hello sir… i am an IT student.. and i wanna learn about this word press but iv’e tried all videos, tutorials and much more but haven’t got my answers… sir will you plzz answer my questions sirr?

    • Cătălin Dogaru 7:12 pm on September 17, 2015 Permalink | Log in to Reply

      Hey,

      I would be interested in working on #22058 (alternative UI for the Background Image section in the Customizer) and #23120 (provide visual feedback on saving widgets). Some progress has already been made, it would be interesting to take things further.

    • Stephen Rider 1:42 pm on September 18, 2015 Permalink | Log in to Reply

      In response to Tom Ryan:
      You have a lot of good ideas, but I would have to strongly disagree with separating plugin settings from Core settings. I got involved with WP back around v2 or so, and at that time there was a widely accepted idea that plugin settings should all go under the Plugins menu. It was a huge mess. A few people (myself included) began championing the idea that plugins should me integrated cleanly. The best interface for a plugin is to be made in a way that you might not realize it isn’t Core.

      I totally agree with you that plugins should consistently link to their own Settings screens (if they exist) from their entry in the Plugins page. I believe I wrote the first tutorial about how to do that back in 2008: http://striderweb.com/nerdaphernalia/2008/06/wp-use-action-links/

      It would be nice to have some consistency, but at the same time I would hate to bind developers’ hands. It’s more a question of education.

      • Tom Ryan 5:37 pm on September 18, 2015 Permalink | Log in to Reply

        Thanks for your feed back Stephen!

        With respect to separating out plugin-added options, here is the issue I’m trying to address: The WP interface can look VERY different from site to site, depending on which plugins are installed. This makes the WP interface non-standardized and hard to find the things you use on a regular basis. I can understand your point about making the plugin integration seamless, but often settings are all over the place for no good reason. I have one theme that requires 5 other plugins and my top level menu is a mess of options I never use.

        Here is an example of a very a simple interface tweak that could help quite a bit: List all the core Settings items first, then a line, then list all the additional plugin settings below that line. That way, it’s still on the same menu, but you can always find the core WP items in the same place.

        By the way, many of the plugins I use should not be top level item; once they are set up, I only need to access them occasionally. It would be better if they were more like the themes page where you could see icons, for the installed plugins and click on them to configure them.. Maybe to have the best of both worlds, you could include a checkbox to enable the user to add a plug in to the top level menus. That would keep the top level WP menu clean by default, but allow users to include it in the top WP menu if they need to access it frequently.

    • Morten Rand-Hendriksen 4:11 pm on September 18, 2015 Permalink | Log in to Reply

      There’s also the ImageFlow project which looks to change the experience of adding and editing images.

    • FolioVision 4:53 pm on September 18, 2015 Permalink | Log in to Reply

      Hi Helen,

      Thanks for the suggestions. We’ve written a plugin for front end comment moderation (and now caching) called Thoughtful Comments. It works with all themes. We’d be happy to help add front end moderation to WordPress. I’ll take a look at backend moderation and see what might might be improved there.

      Hi Tom/Stephen,

      Plugin settings really must be put back into the Settings Menu and the Tools Menu. Each plugin demanding a top level menu item for itself is totally out of control and make most client sites look almost unusable now. 90% of plugins can get by with a Settings entry and (where necessary) a Tools entry.

      Forcing plugins to link to their own setting pages would be very helpful. I’d love to bind developers hands as consistency is the hallmark of great UI (think Mac OS 7 to 9 and Apple OS X vs Linux/Windows). Adding a requirement to consistently link to setting pages would make me very happy.

      Alec Kinnear

      • Tom Ryan 5:44 pm on September 18, 2015 Permalink | Log in to Reply

        > Each plugin demanding a top level menu item for itself is totally out of control and make most
        > client sites look almost unusable now. 90% of plugins can get by with a Settings entry and (where
        > necessary) a Tools entry.

        Thanks Alec, I agree with you 100%!

        If you think it looks bad as WP developer, can you imagine what it’s like for someone trying to come up to speed on WP for the first time? The WP learning curve is way to steep and long at this point.

        I’m hoping that the UX group will be able to address many of these issues to make WP a more accessible and easy/fun to use product.

    • fredhead 9:56 pm on September 21, 2015 Permalink | Log in to Reply

      I’d be interested to participate in the Publishing UX exercise. From my experience, in most cases simply floating the Publish button at the top as I scroll down the add/edit screen would work wonders for me. I hate having to always scroll up and up just to save my edits.

      FWIW, as a user and someone who sets up WP sites for other people, I totally agree with the discussion about adding flexibility to the WP core navigation as well as the need to provide more guidance about using Settings and Tools as the default location for plugin settings and functionality. The number of top level menus for lightly used plugins is way out of control in my experience and view.

    • th23 8:18 am on September 22, 2015 Permalink | Log in to Reply

      Really great to see, that the team is always looking how to (further) improve the user experience and interface 🙂

      I just yesterday submitted an idea on how to optimize the flow creating / editing a gallery – based on some feedback/ observation of a few friends using and struggeling a bit with finding their way around:
      https://core.trac.wordpress.org/ticket/33950

      In case somebody can point me to what to do next, I am happy to contribute!

    • thomask 7:49 pm on September 30, 2015 Permalink | Log in to Reply

      I would like to point the WP design/UX community to my ticket https://core.trac.wordpress.org/ticket/33931 where i have prepared very detailed wireframes for possible redesign, unification and simplification of many WP pages. I have also described there many problems with unnecessary differencies that might baffle the users and that harden the translation and modification.

    • rodosnews 10:58 pm on January 7, 2016 Permalink | Log in to Reply

      I FIND IT A LITTLE BIT DIFFICULT TO UNDERSTAND IT..

  • lessbloat 2:24 pm on July 31, 2015 Permalink  

    Calling all designers 

    With a location and date officially announced for WordCamp US (Philadelphia, December 4th–6th), it’s time to start thinking about design for the event.

    We’d like to include the entire WP community in this call for designers. If you’re interested, please continue reading:

    Concept proposals

    For those designers interested, we’d like to see a rough design proposal:

    Deliverables
    We’d like to see:

    1. Branding concept (logo, colors, typography for the event)
    2. Attendee badge design concept (dimensions: 4in x 3in)

    NOTE: Please free to submit designs in whatever fidelity you have time for (from sketches to pixel perfect mockups).

    Deadline for proposals
    Aug 10, Noon (PDT)

    Submissions
    To submit a proposal, please ping me privately on Slack (lessbloat is my username) including a link to your proposed design concepts.

    Questions

    When will I hear back?
    We’d like to get started relatively quickly. Please give us a week or so to sort through proposals after the the 10th. Note: I will reply to everyone who submits a proposal (whether you’re selected or not).

    What specific things would I be responsible for designing?
    If you’re selected, you’d design the following:

    • Branding
    • Badges
    • Signage (to be used on location)
    • Website design
    • T-shirts/Swag

    Will I be compensated for my work?
    Unlike most other conferences that charge hundreds or even thousands of dollars to attend, WordCamps tries very hard to keep attendance fees at a bare minimum. We do this by relying heavily on our amazing volunteers. That said, while you won’t receive financial compensation, this is a high profile event, and your work will be seen by everyone in attendance.

    Anything else I should consider?
    It might be helpful to check out the WordPress.org design handbook, specifically the sections on identity, colors, and typography.

    Additional questions?
    Please feel free to ask additional questions in the comments below, in the #design Slack channel, or via a private ping to me in Slack (lessbloat). Thanks!

     
    • lessbloat 9:01 pm on July 31, 2015 Permalink | Log in to Reply

      Two follow up answers from pings I received:

      1) Someone asked about the following sentence:

      That said, while you won’t receive financial compensation, this is a high profile event, and your work will be seen by everyone in attendance.

      Please know that I did not mean this in a “you won’t get paid, but you can add it to your portfolio” sort of way. Though now that I re-read it, I can see how it would come across that way, especially in my use of the words “high profile”. I feel bad. That sort of sentiment is gross.

      To clarify, what I meant to say was, this is volunteer work. The design work done for most WordCamps is done by volunteers. Since it’s volunteer work, naturally you won’t get paid. That said, if you have the time, and inclination to work on this, it should be a pretty great event, and plenty of people in attendance will benefit from your work.

      2) Someone asked if the could apply by submitting a portfolio site, instead of spending time to create proposal/concept designs (rather than spend time on a design with the chance that they might not be selected).

      Yep, that works too. If you’re interested in applying, and you’ve got a strong design portfolio that you feel represents your work well, please feel free to just shoot me a link to it.

      I hope that clears these things up. 🙂 Let me know if you have any additional questions or concerns. Thanks!

  • Stephane Daury (stephdau) 6:13 pm on June 25, 2015 Permalink  

    Core UI Chat, June 25th 2015, WC EU edition 

    Today’s chat did not really happen, for the best of reasons, since most of the regular contributors are currently making their way to the massive WordCamp Europe 2015. The good news is that many Core UI related chats are expected to take place there, as many gather in person.

    Since I ran the meeting for similar reasons last week, I figured I’d post a quick summary of what happened since then in Core UI Land instead.

    Tickets with notable UI-related commits

    #28820, #32213, #32015, #32325, #21845, #30157, #31336, and #31216

    Some active tickets

    • #32346 is being discussed
    • #29906 is alive and well, nearing commit state (needs testing)
    • #32395 got a brand new patch, needs testing
    • #16434 is seeing some patches and chatter
    • #30902 is on fire!
    • #19257 was set to fixed; #30729 got punted to a future release, and #31240 looks like it might as well

    Looking stalled, could use some help, with beta 1 approaching

    #31654, #32398, #26550, #29958, #32152, #32493, #29158, #30154, and #31655

    Main recommendations for commits this week

    I’ve chatted with the accessibility group about a series of List Table and accessibility ticket they have, and I’ve recommended they tag them as commit ASAP. They are all, IMHO, in good shape to be considered. They’ve also clearly been abundantly discussed, iterated upon, etc. Some commit-time tweaks might be required, but nothing I’d consider related to the actual functionality.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar