Make WordPress Design

Updates from August, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Mel Choyce 7:40 pm on August 16, 2013 Permalink
    Tags: ,   

    Content Editing User Experience (CEUX) 

    Howdy folks!

    This group will be focused around streamlining and improving the overall content editing experience in WordPress. We’ll be exploring better methods for curating and formatting content within the post and page editors. We have a preliminary set of mockups that we’ll be expanding and iterating on as we start. Here’s the plugin we’ll be building.

    Our first CEUX meeting will be taking place on Tuesday 17:00 UTC in #wordpress-ui. Providing this works for most people, we’ll continue meeting at this time each week.

    During our meeting, we’ll elect a team lead and discuss our process moving forward.

    Current team
    Our initial team is: @melchoyce (me!), @wonderboymusic, @saracannon, @DavidHickox, @georgestephanis, @helen, and to a lesser extent, @joen will be contributing feedback and ideas. We’ll also be communicating closely with the Page + Menu team as content blocks move into pages. @jenmylo has graciously agreed to advise this group. If you’re interested in getting involved, come by on Tuesday!

    • bradparbs 8:55 pm on August 16, 2013 Permalink | Log in to Reply

      Such an awesome project!

      Shout out from #wcpvd where we’re doing some work on this now!

    • jayarjo 7:45 am on August 18, 2013 Permalink | Log in to Reply

      Providing a way to extend “insert block” module with user-defined blocks would be great. Also ability to edit the content directly on the site without moving to backend can be a lot user-friendlier, since simpler or not backend view of the content still differs from what user actually gets in the end. Have heard multiple complaints from users in this direction, even though I had a editor-style.css in place with all the site-wide stylings activated (including fonts and other subtle things).

      In case you lack someone to actually code this, I’m ready to participate (@jayarjo).

      • paaljoachim 12:36 pm on August 19, 2013 Permalink | Log in to Reply

        I have noticed that http://www.wix.com is becoming more and more popular. Just check out the quick tour video. Many templates that are easy to customize on the frontend. Perfect it seems for the non designer/developer. It would be good to learn from them and incorporate similar aspects of easy to edit frontend into WordPress. Taking certain aspects from the backend and also adding them to the frontend.

        • Easy to cumstomize templates (backend&frontend). Save a page/post as a template to be reused.
        • Drag & drop elements (main elements and widgets) into a grid that can be adjusted in a simple way.
        • Mel Choyce 1:07 pm on August 19, 2013 Permalink | Log in to Reply

          Wix was actually a service I explored (alongside Squarespace and Weebly) when I first looked into improving content editing, and I actually found it to be the least intuitive and most frustrating experience out of those web building services.

          Sounds like @ubernaut‘s going to be working on a front-end editing project: https://make.wordpress.org/core/2013/08/14/present-your-3-8-feature-idea-at-tomorrows-meeting/#comment-9950 You should touch base with them about that, since it’s out of scope for this particular project.

          • paaljoachim 3:00 pm on August 19, 2013 Permalink | Log in to Reply

            Wix is great for beginners when a person has gone one step further then WordPress is great. I helped a friend edit a few things using the frontend editing in Wix. It was not that bad. Certain things were not intuitive though but I helped him figure it out.

            There needs to be close interaction between the groups though (backend content editing and the frontend editing group). As it would be great to have block elements added to a page on the backend as well as the frontend.

            Of course a more advanced approach on the frontend is this: https://webflow.com/

            • Mel Choyce 3:17 pm on August 19, 2013 Permalink

              I agree that there needs to be a lot of communication between groups. Widgets is also interested in exploring the idea of content blocks, so we’ll be in close communication with them as well. I think with these beginning stages it’s okay to play around and try out lots of ideas, but as we refine our concepts more we’ll need to come together to make sure everything is cohesive.

          • @ubernaut 3:42 pm on August 19, 2013 Permalink | Log in to Reply

            we don’t have a p2 yet but i have a few (3) rough mockups i put together yesterday so will try to get some helping posting a p2 asap. i think the ultimate goal here should be what video games strive for a UI/X that requires no explanation or instruction maybe thats a pipe dream but hey i like to shoot for the stars what can i say? Even if we can’t get all the way there any closer we can get to that ideal will be i think greatly beneficial to new users.

            • @ubernaut 3:43 pm on August 19, 2013 Permalink

              oh yeah i also dig your mockups for the new post edit ui mind if i borrow a piece or two for my mockups?

            • Avryl 3:50 pm on August 19, 2013 Permalink

              By front-end editing, do you mean editing posts and pages or the whole site (title, header, footer, design etc.)? I’m making a few mockups as well, but they’re focussed on editing posts. I’ll share them today or tomorrow.

            • Mel Choyce 3:53 pm on August 19, 2013 Permalink

              Feel free to snag anything, just know that it’s probably going to change pretty dramatically in the next couple weeks. Here’s my psd: http://cl.ly/2h1n2W2D2y3r

            • @ubernaut 4:22 pm on August 19, 2013 Permalink

              well posting is the primary thing which effects almost every user role and as such i think deserves the most attention but in terms of new users i’d say a good chunk of those people are admins setting up their first blog/site. i think the logic can be applied to many aspects of editing (content and structure)

              i think the main aspects of admin that do not translate well to a front end experience are the various list screens and general/plugin settings pages. i think even those cases making it seems as if your not in some entirely different world will make the experience more friendly for new users.

              i need to try to get someone to give me a p2 so we we can stop going on a complete tangent from this conv though and thanks Mel i really like your dark version of the editing tools for what I’m doing and my shortcut version would have bee just invert the existing things 😛

            • @ubernaut 10:22 pm on August 19, 2013 Permalink

              For anyone who wants to continue this conversation regarding the other idea conversation it’s here:


    • ryanrampersad 5:52 pm on August 18, 2013 Permalink | Log in to Reply

      The mockups look fantastic. I really like the look of “fieldless” fields.

    • JakePT 3:14 am on August 19, 2013 Permalink | Log in to Reply

      I love the look of the mockups!

      My only issues is that I wish there were a way to do blocks in columns, and I’m unclear on how image alignment works when in a block.

    • shaunandrews 4:50 pm on August 19, 2013 Permalink | Log in to Reply

      I’ve mentioned this to you a few times on Skype, but I want to make sure I mention in on a Make blog, too: I keep coming back to the idea of widgets-as-content-blocks. Imaging if all widgets are really just content blocks. You should be able to drop a widget into a post, page, or sidebar, just as easily as a content block into your post.

    • Azizur Rahman 11:30 pm on August 19, 2013 Permalink | Log in to Reply

      This is really great UX. What does concerns me is how this blurs the separation of presentation from data architecture.

      I am interesting in seeing how the actual data will be architect-ed. Would we have all the block some how composed into a single field (ie: post_content) or would the block themselves be stored such a way that it can be re-used and re-purposed for a different presentation?

      I am interested in this project so if you are looking for another team member to help let me know.

    • hearvox 9:29 pm on August 21, 2013 Permalink | Log in to Reply

      The mockups look great, MP6-like and very inviting: will encourage people to write. Assume these are of the Visual editor (don’t see the button for the Text editor).

      The Content Blocks idea make lotsa sense. I work w/ several national journalism sites, and we end up creating the equivalent, usually thru a homemade plugin that generates HTML w/ classes for things like Audio, Layout. (Will site-owners be able to define custom Blocks, as is possible w/ Post Types, Post Status, etc.?)

      The biggest problem all these sites have is the way TinyMCE wreaks having on HTML entered in the Text editor. For some sites we end up avoiding the WYSIWIG, and for others we extend the HTML that TinyMCE allows, and try to turn off most of its HTML reformatting: but this always seems like a battle.

      Most of the better articles in these journalism sites require HTML — some quite a bit of it. But any writers, and even coders, find a lot of editing/re-writing easier in Viz. So we’re constantly correcting the HTML mess TinyMCE leaves in its wake — aka, not optimum workflow.

      Anyroad: off to install the plugin on a dev site. Thanks for everyone’s work.

    • Michael Arestad 5:28 am on August 24, 2013 Permalink | Log in to Reply

      I love the idea of content blocks! I’m a little late to the party, but I’d love to help out with any design/CSS or icons if needed.

  • Mel Choyce 8:16 pm on August 8, 2013 Permalink
    Tags: , content editing   

    Proposal: Improving the content editing experience 

    As a follow-up to Matt’s recent post on make/core, I’d like to propose improving the content editing experience.

    I see this working in two parts:

    1. Content blocks
    2. Content formatting

    Some questions to consider moving forward:

    • How can we make formatting easier and faster to use?
    • How can we make it easier for users to include different types of media, such as audio, video, images and galleries?
    • How can we make it easier for users to embed external content, like tweets or maps?
    • How can we make it easier for plugin authors to include new types of content in a way that is more clear and intuitive for our users?
    • What would updating the content editing flow mean for theme authors? How can we make it as easy as possible for this workflow to work with current themes?

    Let’s start brainstorming some initial ideas and figure out how to move forward with a proposal for next week’s 3.8 meeting.

    • Mel Choyce 8:17 pm on August 8, 2013 Permalink | Log in to Reply

      Some initial concepts I’ve explored: https://choycedesign.com/wpadmin-ui/content-editing.html

      • Mel Choyce 8:33 pm on August 8, 2013 Permalink | Log in to Reply

        Some issues with these concepts: They are heavily based on a document model, which is probably not the best solution for our users.

        • ntl0820 8:39 pm on August 8, 2013 Permalink | Log in to Reply

          I’d disagree. I feel like this kind of format could easily be applied for different models. To me it just gives it a standard format. Their will always be exceptions, but I feel like this is a great direction to go for consistency.

        • Avryl 8:47 pm on August 8, 2013 Permalink | Log in to Reply

          What would be an alternative to a document model? What would the current model be, if not a document model?

          • Mel Choyce 10:00 pm on August 8, 2013 Permalink | Log in to Reply

            Document model works okay for posts, which are essentially documents, but as we branch out into pages and custom post types, we need to think a little broader. For example, services likes Squarespace and Weebly do a really great job at page building. We want to build, not just write.

            • sara cannon 1:02 am on August 9, 2013 Permalink

              If you want to reference a great builder, check out the new mailchimp drag and drop email customizer. great UX and very intuitive.

            • Mel Choyce 2:01 am on August 9, 2013 Permalink

              @saracannon That was awesome. 🙂

              If anyone wants to check it out, here’s a gallery I threw together of their post-signup, new user flow: http://imgur.com/a/L67xU

            • krogsgard 3:08 pm on August 9, 2013 Permalink

              I’d imagine it as a post type “supports” feature. Added to posts and perhaps pages by default, with the ability to register support for whatever this is named in the registration of the post type. Otherwise leaving it to a standard content area.

      • Avryl 8:35 pm on August 8, 2013 Permalink | Log in to Reply

        I’d really like to help out with this, but I’m new to contributing to WordPress and don’t really know where to start.
        Your concepts are great! They’re simple and intuitive. Will there still be a way to edit in html (and even maybe in markdown)?
        Also, with content blocks, is it the intention to have more than one post format for a post? Or is that something separate/obsolete?

        • Mel Choyce 8:40 pm on August 8, 2013 Permalink | Log in to Reply

          I’d really like to help out with this, but I’m new to contributing to WordPress and don’t really know where to start.

          Discussing ideas on the p2s is a great place to start!

          Your concepts are great! They’re simple and intuitive. Will there still be a way to edit in html (and even maybe in markdown)?

          I’d love to find a solution that allows us to eliminate the need for an html view entirely. 🙂

          Also, with content blocks, is it the intention to have more than one post format for a post? Or is that something separate/obsolete?

          I think the concept of post formats is something we’ll need to think about and explore moving forward, because I don’t think there’s a clear answer currently.

          • ntl0820 8:48 pm on August 8, 2013 Permalink | Log in to Reply

            I’d love to find a solution that allows us to eliminate the need for an html view entirely. 🙂

            I love the idea of that, but I feel like the work done to achieve that is overwhelming to think about. I can’t count how many times I’ve had to go to that tab for one reason or another.

            • Avryl 8:55 pm on August 8, 2013 Permalink

              Exactly. I think it should still be there, maybe tucked away.

            • Travis Northcutt 2:40 am on August 9, 2013 Permalink

              Yeah, even if you somewhat hide the html tab, I think retaining it for “power users” could be pretty important.

            • portfola 4:25 pm on August 9, 2013 Permalink

              Agree this needs to be available

            • Evan Herman 2:07 pm on August 13, 2013 Permalink

              I agree. The ‘html’ tab should remain, but hide it if possible. I know many of the clients I work with regularly click that tab when they certainly do not need to.

          • Kim Parsell 10:26 pm on August 8, 2013 Permalink | Log in to Reply

            Please do not remove the html view. There are a lot of users (including me) who prefer using that when writing. One of the first things I do when setting up a new WordPress install is to turn off the visual editor.

            • Justin Tadlock 11:55 pm on August 8, 2013 Permalink

              Same here.

            • Ipstenu (Mika Epstein) 1:45 am on August 9, 2013 Permalink

              For writing code in posts (tutorials) the text editor is a must. Now I can see defaulting to visual and maybe hiding text, since I suspect we’re more rare than the people who live in the visual, but it really needs to stay 🙂

            • krogsgard 5:14 pm on August 9, 2013 Permalink

              Is there any reason the html view could not be ported to a plugin? Decisions vs options imo. If the visual editor was *really* good, we should not give equal weight to the html view. If nothing else, it should be less obvious an option. Perhaps off by default in screen options, maybe, if not a plugin.

            • @mercime 8:25 pm on August 9, 2013 Permalink

              I second the plea to retain the HTML view.

            • Brendyn Montgomery 9:39 pm on August 11, 2013 Permalink

              Ditto – Really useful for cleaning up clients work who paste from word without using the “paste as plain text” option :).

              I’d be OK with it in the screen options and off by default

            • lettergrade 1:57 pm on August 12, 2013 Permalink

              Agreed. It also leaves options open that allow me to customize special client pages in a way they can be trained to edit, when custom templates are too far out of their comfort/safety range to touch!

            • TCBarrett 8:55 am on August 13, 2013 Permalink

              How many support posts in the WordPress forums make use of the text view to help fix visual issues?

            • Taylor Dewey 9:17 pm on August 13, 2013 Permalink

              For the majority of writers, the HTML view is a crutch for a visual editor that isn’t *quite* perfect. Right?

              Consider how often you have to flip into the text view to clean-up your markup, or delete something that isn’t easy to delete in the visual editor. Or write code.

              Sure, some folks prefer the HTML editor for whatever reason, but it’s existence — as a crutch— is not helping us make publishing easier.

              There are a few problems that should be solved before we can hide this crutch:

              • Janky markup. The visual editor needs to produce markup of the gods.
              • Code editing. There are lots of code bloggers—at least as many as photo, video, or audio bloggers. Let’s introduce a good way to write code examples into the visual editor
              • Formatting weirdness. Part of this is due to the visual editor not always accurately showing what the front-end will look like (which I realize is editor-styles.css), part of it is due to it’s relatively small size.

              For those that really just want to write in HTML (or markdown?) — perhaps we can repurpose some of that awesome code editor mentioned above for writing actual post content. There already exists an option in user preferences for the default editing environment. That can be repurposed as a toggle.

          • Joen Asmussen 7:25 am on August 9, 2013 Permalink | Log in to Reply

            Mel and I mocked up two directions on improving the post editor experience. In my mockups, I worked on the assumption that post formats wasn’t a thing at all — that there were only content blocks that contained semantic structure for its type of content. For theme compatibility, you’d be able to assign a post format class based on what content blocks were there: if there was only one video block, it would be a video post format.

            • Ivan D. 9:10 am on August 9, 2013 Permalink

              It’s a very good job. I like this “write flow”. The way that

              can be moved and styled one by one is very interesting (even if i think that the button for style is not very visible).

            • Erlend Sogge Heggen 9:53 am on August 9, 2013 Permalink

              I love the idea of non-strict post formats. If a video is the only media element, it’s a video post. If there’s a video and a chatlog, it’s a mix.

            • krogsgard 5:16 pm on August 9, 2013 Permalink


              I think this is a great start.

              Two things I think would be really helpful: easy to establish “section” and “column” options. This would allow for pretty simple content section establishment. Could be plugin territory, but I think if we’re going to content blocks, core could much better handle such features than a plugin.

            • krogsgard 5:19 pm on August 9, 2013 Permalink

              Sorry, I should’ve also noted: I basically envision these as classes that WordPress expects. Much like alignright and alignleft. Options like “content-section, content-column-group, content-column,” etc.

              For columns, I think a semantic structure similar to Kovshenin’s plugin works well: http://kovshenin.com/2013/columns-for-wordpress/

            • DavidHickox 5:40 pm on August 9, 2013 Permalink

              I like this a whole lot. I was going to sketch up some ideas of my own, but you’ve included many of the things i wanted to illustrate in your mockups. I especially like the sidebar content blocks and that the publish and category options are at the bottom, where they would most logically be used.

            • Joen Asmussen 7:15 pm on August 9, 2013 Permalink


              It definitely makes a lot of sense for block behavior to adopt such classes. Perhaps they even behave differently based on what the theme is capable of. If a theme doesn’t have an alignleft class, for example, such an alignment isn’t possible.

            • jeffr0 4:37 pm on August 12, 2013 Permalink

              When clicking the link to see your mockups, all I see is a page that says Mocco says hi. Where did the mockup images go?

            • shaunandrews 8:28 pm on August 12, 2013 Permalink

              Beautiful! I love every bit of it!

            • Joen Asmussen 7:20 am on August 13, 2013 Permalink

              Jeffr0: Sorry, was messing with the .htaccess, it’s up again.

            • ckluis 9:00 pm on August 14, 2013 Permalink

              I’d love for WordPress and thus theme designers by extension would use this block concept, but add many of the bootstrap style blocks: tabs, tables, alerts, etc.

              By choosing 10-15 base content blocks – most layouts could become much more WordPress dependent while the themes just apply the styling (the opposite of how it is today).

            • paaljoachim 11:02 pm on August 17, 2013 Permalink

              Your mockups are really good! To take it one step further I would suggest to add a semi transparent grid (improved table) to the layout area. Drag and drop an element into the grid. Click the element to add background color, curved corners, border, padding, margins etc. Select multiple cells and add a background color etc to the cells then drag an element into it, or just add some text to create a background color box. Here are my mockups: http://easywebdesigntutorials.com/wordpress/wordpress-mockups/
              The grid will make it possible to push/pull the cells to make them bigger or smaller. Adding just a design to a cell(s) and/or the element. I also suggest to add templates into this mix. Design a page and save it as a template. Make a new page and select the custom template and see how the design of the page changes to reflect which template is selected. Also widgets should be dragged&dropped anywhere on the page.

          • Matt McLaughlin 3:35 pm on August 9, 2013 Permalink | Log in to Reply

            To me post formats are really about applying differential layout in the blog-roll (and sometimes on the post itself) based on the content type. Making the edit surface easier to navigate – trimming down the options to avoid choice overload – seems like a secondary goal.

            If you can make all the editing easier then that secondary goal is less important and you’re left with, “How do I tell WP to layout “Quote Format” posts in the blogroll differently from “Picture Format” posts?Why not make the layout automagical. If you have a post where 75% of the text is an inserted block quote, then that becomes a “Quote Format” for the purpose of layout. If you have a post that is 80% a gallery, then clearly that’s a “Gallery Format”.

            Essentially I’m saying why bother asking the user to explicitly define posts as a being a particular format? They’ve already done that in their choice of what they put in the edit surface.

            There will definitely be edge cases so you might want some ‘Advanced User Explicit Defining Format’ option, but my sense is that it won’t be that common.

            • jeffr0 4:46 pm on August 12, 2013 Permalink

              As someone who currently does not use Post Formats on a regular basis, I would find it frustratingly annoying to have WordPress automatically applying post formats to posts. I structure posts in the way in which I want them to be displayed and if WordPress is going to get in my way to try and help me without me requesting it, it’s going to be a bad day. I am the edge case that explicitly wants to choose a post format based on when I want the content to take on the looks of that format.

          • binarymoon 1:30 pm on August 12, 2013 Permalink | Log in to Reply

            Personally I ONLY use the html tab so I really want that kept – however I really like the look of this style of interface. What I would suggest is disabling html and having it enabled through the user profile (like the colour schemes) so that power users can toggle it on and regular users can ignore it.

      • Ivan D. 8:36 pm on August 8, 2013 Permalink | Log in to Reply

        I like a lot the first screen. Very intuitive. Just the tags and categories at the bottom seems too far from to be seen fast.

      • Grant Palin 10:08 pm on August 8, 2013 Permalink | Log in to Reply

        Really like the idea. I’ve thought before that allowing the user to define ‘blocks’ of content within one page/post/etc would allow flexibility in defining what goes where. Start with text block, followed by an image, followed by more text… Advanced Custom Fields has given me some inspiration and capability on that front.

      • binarymoon 1:30 pm on August 12, 2013 Permalink | Log in to Reply

        Not sure if this is of interest but I put together my own thoughts on the wordpress post editor earlier this year.


        This was for 3.6 – and not so relevant with what you’re proposing but maybe it will have something helpful in there.

    • Helen Hou-Sandi 8:21 pm on August 8, 2013 Permalink | Log in to Reply

      So, in sort of the same way unit tests should be written in parallel to a PHP (or soon, JS) patch, I think user testing scripts should be written in parallel to initial ideas. What exactly makes this hard now, both from an editing perspective and from a theme-making perspective?

    • George Stephanis 8:27 pm on August 8, 2013 Permalink | Log in to Reply

      In the same vein of giving the editor screen some love, here’s something:

      Mockup: http://cloud.stephanis.info/image/1d463B2l3k3p
      Implementation thus far (much work to do yet, but a start): https://github.com/georgestephanis/publish-ux

      If anyone wants to be added to the github repo, just ping me.

      It should work well in concert with your alternate mockup on the above link, I think?

      • Mel Choyce 8:30 pm on August 8, 2013 Permalink | Log in to Reply

        From a high-level point of view, what problem is your publish UX looking to solve?

        • George Stephanis 8:32 pm on August 8, 2013 Permalink | Log in to Reply

          During my happiness rotation and a lot of work with clients, I’ve seen a lot of folks that hunt and hunt, trying to find the publish button. Sometimes they don’t see it when its right in front of their face, other times they’ve inadvertently hidden it by moving the Publish meta box around the page.

          My assertion is that, just like the editor, the publish button should be big, friendly, and consistently in one place.

          • ntl0820 8:36 pm on August 8, 2013 Permalink | Log in to Reply

            I definitely like the idea of the publish button being more emphasized somehow

          • Mel Choyce 8:37 pm on August 8, 2013 Permalink | Log in to Reply

            I’ve seen a lot of folks that hunt and hunt, trying to find the publish button. Sometimes they don’t see it when its right in front of their face

            I’ve seen this problem crop up pretty frequently in user tests, and absolutely agree it’s something we need to fix.

          • Amy Hendrix (sabreuse) 9:33 pm on August 8, 2013 Permalink | Log in to Reply

            I’ve also seen a ton of users struggle with finding the publish button – and even with finding it again after multiple exposures. OTOH, I’m not convinced that split buttons are usable or understandable for that same group of users.

            • George Stephanis 11:22 pm on August 8, 2013 Permalink

              At the very least, we could make one big publish button up above, even if it’s not a split button.

          • Kailey (trepmal) 12:04 am on August 9, 2013 Permalink | Log in to Reply

            I’m all for the Publish button getting a permanent location (or two). Too important to be so easily lost by accidentally moving or collapsing the box.

          • portfola 4:28 pm on August 9, 2013 Permalink | Log in to Reply


    • Ivan D. 8:28 pm on August 8, 2013 Permalink | Log in to Reply

      I like the concept of content blocks. For some ideas you can look at this amazing group of plugins : http://www.advancedcustomfields.com
      I always replace the traditional “content” by a “flexible field” where the user can add simple column, double colums, maps, accordions, carousel… it’s simple to understand than shortcodes.

      • Dalton Rooney 8:49 pm on August 8, 2013 Permalink | Log in to Reply

        Advanced Custom Fields is brilliant, I can’t remember the last time I built a site without ACF installed. We’ve implemented our own Content Blocks feature based on ACF & flexible fields which we re-use quite often. Here’s a screenshot of how we do it: http://cl.ly/image/0d1a1Y1L2J3f

        I can imagine endless possibilities for this as part of WordPress core.

        • Helen Hou-Sandi 9:04 pm on August 8, 2013 Permalink | Log in to Reply

          Note that it’s not really an end-user feature as it is, though, as it still requires editing the theme to display anything.

          • Ivan D. 9:29 pm on August 8, 2013 Permalink | Log in to Reply

            Yes but they can be “usual” blocks. Like post and page type. They are built in but we can create our own post type.

          • Grant Palin 10:11 pm on August 8, 2013 Permalink | Log in to Reply

            Seems to me that it could be possible to make this ‘block’ capability built in, where WordPress understand what each block represents, then can just render them in sequence. Yes theming work would be needed, but some core capability would be a good start!

            • Mel Choyce 10:33 pm on August 8, 2013 Permalink

              I *think* this is the direction we were going with in Post Formats UI last cycle, before it got terminated.

      • Grant Palin 10:12 pm on August 8, 2013 Permalink | Log in to Reply

        This. I was thinking that ACF flexible fields could be used to define reusable block types within single pages or posts, instead of having everything in one textarea.

    • ntl0820 8:35 pm on August 8, 2013 Permalink | Log in to Reply

      I really like the concept of content blocks as well, especially in-line. I think this would also create a standard also for other things to be implemented either through core or plugins…for example Columns.

      • Mel Choyce 8:46 pm on August 8, 2013 Permalink | Log in to Reply

        +1 to columns! Would make it even easier for users to work with any theme they want, instead of having to rely on themes with lots of extra features baked in.

      • Erlend Sogge Heggen 11:29 pm on August 8, 2013 Permalink | Log in to Reply

        Definitely want to see columns becoming standardized. It’s an essential part of responsive design and should be handled in a unified, standardized manner.

    • erikdana 8:36 pm on August 8, 2013 Permalink | Log in to Reply

      How can we make formatting easier and faster to use? – Maybe use “Markdown” with visual result by the side, like http://pad.haroopress.com/
      How can we make it easier for users to include different types of media, such as audio, video, images and galleries? – I thought about the drag and drop working without clicking on any button.
      How can we make it easier for users to embed external content, like tweets or maps? – Accepting pasting the embed code directly in the editor without having to switch to code/text

      @Mel Choyce, your layout ideas are looking good! I would definitely stick to the first option though (http://melchoyce.com/wpadmin-ui/img/add-new.png), separating text from the inserting options cleared up a lot, plus the publish button and options solve a lot of issues.

      • Helen Hou-Sandi 8:47 pm on August 8, 2013 Permalink | Log in to Reply

        Markdown is technical-friendly, not end-user friendly. That’s not to say that a Markdown mode shouldn’t be available, e.g. by plugin, but I would shy away from it being the default.

        When it comes to embed code, we actually support oEmbed for many services. The work on #15490 was a really cool start.

        • idealien 2:06 am on August 9, 2013 Permalink | Log in to Reply

          Page Builder – http://siteorigin.com/page-builder/ – uses widgets in its drag/drop interface to very good result…Not sure if that is larger in scope than what most think of as content block, but if bringing that type of interaction / content design into core is a part of this feature…I’m quite on board for beta testing as a part of this team.

      • Avryl 8:51 pm on August 8, 2013 Permalink | Log in to Reply

        I agree, markdown shouldn’t be default, but it’d be great to have a markdown mode.
        Btw, that’s exactly what Ghost is doing.

      • Dalton Rooney 8:58 pm on August 8, 2013 Permalink | Log in to Reply

        I agree, the first option makes a lot more sense to me.

      • Mel Choyce 10:05 pm on August 8, 2013 Permalink | Log in to Reply

        Markdown feels more appropriate as a plugin, IMO

    • Weston Ruter 8:36 pm on August 8, 2013 Permalink | Log in to Reply

      I suggested on Twitter after Matt’s SOTW that I think WP needs an open registry to collaborate on data structures and identifiers for post formats, such as maps. As I understand it, the reason post formats were closed was in order to ensure that the themes would have a fixed set of formats that they would have to account for, and that data structure for the media in the post format would (supposedly) follow a convention so that themes would know how to parse it.

      However, the closed set of post formats was something that we always hit up against, and would often find ourselves wanting to register new post formats (like polls or maps). We would then resort to creating a new Media Type taxonomy which would automatically assign the corresponding post format if there was one, but this allowed us to create as many media types as we needed, and it also allowed us to associate a post with *multiple* media types (like a post that features an image, music video, and a separate audio track). This now makes much more sense, however, when paired with the newly-proposed content blocks, and that a post can have multiple content blocks each of which as a media type.

      In order to allow new media types (post formats) to be registered, it seems there needs to be an open registry in which the community can collaborate on the identifiers for these media types (e.g. “map” or “vcard”) and also the data structure which this media type must follow (e.g. [map]45.523452, -122.676207[/map]); it seems shortcodes would be useful to specify in the data format, as themes could then easily override any default handlers for the formats. The WordPress media type registry could also refer to plugins which implement support for the media type in themes, and also themes that support the media type natively. Likewise, there should be a way for themes (e.g. via readme.txt) to declare which media types they support, so that they can be filtered when searching.

    • Terry Sutton 8:54 pm on August 8, 2013 Permalink | Log in to Reply

      Love this direction Mel. I’ve been playing with Squarespace in the last while and these content blocks are fantastic. Having columns, spaces and horizontal rules (as SP calls them) makes for very quick and intuitive development. It feels like a massive task though!

      @Dalton‘s implementation using ACF looks interesting too.

      • Dalton 9:05 pm on August 8, 2013 Permalink | Log in to Reply

        I think the important thing for content blocks is that it needs to be easy to plug in to and create new ones, and also easy to retrieve that data in the front end templates. That’s what makes Advanced Custom Fields so brilliant from a developer perspective.

    • tomdryan 9:27 pm on August 8, 2013 Permalink | Log in to Reply

      Here are some thoughts on the Posts user interface as you re-envision the posts page:

      1. All of the file operations (publish, save, preview trash) should be in roughly the same place on the screen and in a similar style (for example, they should all be buttons, but Publish could still be colored for emphasis).

      2. The file buttons could “light up” once the user starts to edit a post.

      3. When a post title is edited, there should be an easy way to update the Permalink without manually editing it. It should probably happen automatically if the post is still in draft mode.

      4. There should be a button to revert the current edits, which deletes the current draft (the way it is now is REALLY confusing to casual users).

      5. It seems that the post Status and Visibility controls could be combined.

      6. Since Posts is where the least technical users will interact with WP, I would put some more interactive help access (hover for help).

      7. For consistency, I would rename the first admin menu choice to “Manage Posts” instead of “All Posts”.

      8. One thought on editing would be to have a text mode with or without tags. This is how WordPerfect used to do it back in the day. They had a visual mode and a draft mode where you could show or hide formatting tags. It made for a very clean, “heads down” content creation mode where you didn’t need to worry about formatting or tags.. Might be worth consideration.

      • Avryl 9:49 pm on August 8, 2013 Permalink | Log in to Reply

        2. What do you mean by file buttons?

        3. That already happens after saving or publishing a post (but it would be nice to see it change before that).

        • Mel Choyce 10:04 pm on August 8, 2013 Permalink | Log in to Reply

          Hah! I totally did not know it updates itself when you save or publish! I’ve always just changed it manually.

          The more you know~

          So yeah, seeing that change live would be great.

    • s3w47m88 9:45 pm on August 8, 2013 Permalink | Log in to Reply

      I started this conversation two years ago and had nearly 300 votes to implement it and notable suggestions: https://wordpress.org/ideas/topic/improved-visual-editor

    • DavidHickox 10:24 pm on August 8, 2013 Permalink | Log in to Reply

      I like the content blocks concept a lot, though I think some sort of drag and drop action would be more intuitive than the “add block” appearing when your cursor rests. That kind of continual suggestion is likely to get annoying very quickly. Give the users the tools they need in a logical, but out of the way place and let them decide when to use them rather than have the UI constantly ask them to.

      I think your concept as a whole is several steps in the right direction. I’d like to see a more streamlined, page-first experience with all the menu and toolbar distractions isolated to one area. As it stands, having these tools at top, right, and below keeps the UI feeling more cluttered than it ought to.

      I’d love to pitch in on this project and am glad to help in whatever way I can.

      • Mel Choyce 10:45 pm on August 8, 2013 Permalink | Log in to Reply

        I think the big problem here is targeting the perpetual intermediate user. Beginners want things in their face so they don’t have to hunt for them. Experts want things out of the way so they only exist when they need them. We want to aim for the intermediate user — is comfortable enough to get what they need done, but still needs occasional reminders for where things are.

        I’d like to see a more streamlined, page-first experience with all the menu and toolbar distractions isolated to one area.

        +1. Content is king. 🙂

      • sara cannon 1:07 am on August 9, 2013 Permalink | Log in to Reply

        good to see you on here David – Please feel free to post sketches of your minimalistic ideas! love to see em 🙂

      • krogsgard 5:26 pm on August 9, 2013 Permalink | Log in to Reply

        Another consideration is small devices, that makes drag and drop problematic.

        I think a better implementation would be drag and drop or click to add block. The “action text” should be obvious whether the user is hovering or not. I can’t link the direct post bc I can’t find it, but it’s an accessibility concern.

        I don’t see why click or click+drag couldn’t both work. That way, on mobile, available content blocks could be available, perhaps toggled, at the top, and a touch/click could send it to the editor. On larger devices, drag and drop would be simpler.

        Also worth noting, making content blocks collabsable once in the editor could be very nice. Similar to the way gravity forms fields work once in the form editor. In fact, we may be able to learn a bit from the GF UI in general for a project like this. The goals are similar (not that I think GF is a perfect UI at all).

    • Debra S 10:35 pm on August 8, 2013 Permalink | Log in to Reply

      Not sure what content blocks means here, so maybe this is already something you’re talking about?

      I tend to write long posts with a lot of media – it would be really sweet to have the mark-up and media tools float along the side for easy use OR stay fixed and let the content scroll underneath (the way freeze frame works on Excel).

      Glad to see this process is going on!

    • JakePT 12:47 am on August 9, 2013 Permalink | Log in to Reply

      Where I work, in the last year we’ve built over 500 sites for clients on WordPress. The vast majority of these are for non-technical users running small businesses using WordPress as a CMS.

      One of the biggest issues by far is TinyMCE, for these reasons:

      • It’s not WYSIWYG, at least not in any way that clients understand.
      • Doing anything other than a vertical block of text with some images is incredibly difficult. Tables, through a plugin, are very difficult to use and very very buggy (#20943 has driven more than a few clients mad).
      • Alternatives like Column Shortcode plugins are too abstract and confusing for most of our users.
      • Adding anything other than a standard gallery/image is difficult. It involves either using a shortcode or going to the HTML editor and adding code, which often breaks things when switching back.

      I would like to see something where it’s easy to add rows and columns and then just drag a piece of content into it, like and image, gallery etc. as in the mockups, as well as just a simple HTML block when a user needs to embed something that isn’t available.

      It should also be easy for plugin developers to make their own content blocks as a replacement for/representation of shortcodes.

      I’m sure it would be incredibly difficult, but even with changes like this, a lot of our users will still struggle with anything short of front-end WYSIWYG editing, and I think that should be a goal for a future version.

      • sara cannon 1:11 am on August 9, 2013 Permalink | Log in to Reply

        I agree with the issues that users are having. wysiwyg is really not wysiwyg.. which is why I think a front end editing experience will be neat. but I think on first iteration, it might not be as robust in in content block creation as what is being discussed here.

      • DavidHickox 2:07 am on August 9, 2013 Permalink | Log in to Reply

        I too have seen years of awful content created with WYSIWYG editors on a variety of platforms. The WYSIWYG editor creates a level of comfort and familiarity because most people are familiar with basic desktop publishing and word processing. But that type of content formatting is not suitable or desirable on the web. Especially with RWD, web content should be fluid, hierarchical, and relatively uniform.

        In my experience dealing with clients, they feel intimidated by TinyMCE–It looks like a lot of work and makes “blogging” seem difficult. They feel that they are supposed to make every page “look pretty.” But those same people have no problem updating Facebook with relevant and even long-form content, and do it with ease. The struggle with the WordPress editor is to maintain a robustness of function while still feeling effortless and simple like Facebook, Tumblr, and the type of content editors people actually use quite regularly.

        In this effort toward approachability, I’d love to see the WYSIWYG concept go away.

    • mtourtellott 1:44 am on August 9, 2013 Permalink | Log in to Reply

      May I please suggest we turn this question around. Most of what I’m seeing here, and my apologies I have not read every word. We are back debating which keyboard makes you a better writer. Which always ends in disappointment.

      How do people create content? If you look to writers, there are droves of people running away from MS Word and moving to tools like Scrivner. Which means they are more interested in crafting their words in a comfortable space and less about rows of buttons. I personally want an interface that lets me write in HTML, or Markdown or text and then lets me format it. With most WordPress sites using a dedicated theme with CSS that already defines the actual look of the formatted type, having lots of ways to ruin the design is not really a great solution. Media needs to be easy. Take a look at Koken http://koken.me/ to see a way of handling media. Not necessarily the right way, but a great model to think about.

      If the interface is effective then there won’t be a front or back end it should just be content creation. Get out of modal thinking.

    • Erlend Sogge Heggen 9:33 am on August 9, 2013 Permalink | Log in to Reply

      I love the mockups!

      While we’re at it, why don’t we simply treat text as a content blocks as well? It’s text, so it would work a little bit differently, but it’s a content block just the same. I propose these simple rules:

      • One line-break creates two separate paragraphs but maintains the content block.
      • Double line-break separates the two paragraphs into two separate content blocks.

      I think this would be an efficient way to deal with columns. If text is considered a content block, drag&drop columns would be easy. Imagine I’ve written two paragraphs of text, and then I drag an image block in to the right of it. By default the editor would recognize this as me wanting to create a 2 column layout, like so:


      The two paragraphs and the image have now been joined into a 2 column layout. The 3/5 and 2/5 ratio was determined by some global default, but I can quickly change it by dragging the middle separator.

      (I’m not sure what I had planned for the horizontal separator. Probably slipped into the table mindset there).

      Re. Tables, I think this is a niche functionality that is better covered by some already outrageously popular plugins:

    • Ipstenu (Mika Epstein) 1:02 pm on August 9, 2013 Permalink | Log in to Reply

      In both Mel and Joen’s mock ups, would we still have a place for the custom crafted excerpt? The more tag is good, but there’s a use case for both 🙂

    • Matt McLaughlin 2:41 pm on August 9, 2013 Permalink | Log in to Reply

      While I think a lot of these ideas are nice, it strikes me that the simplest thing to do would be to unify all the editing into a single tool bar/ribbon. For people coming from just about any commonly used word processor, they’re used to all the functions being in one place above the edit surface. Insert a picture? That’s in the tool bar right next to bold, insert link, etc. etc.

      As it stands with WP, the toolbar does most of the work, then there are a few “privileged” functions like Add Media that sit above the tool bar. Things like Comments and social media (depending on plugin) tend to be check-boxes that sit in another box below the edit surface. Plugins that do things like forms are all over the map in terms of UI.

      The way I’d like to see it is:
      1) A single edit surface with everything that will appear on the post or page (Including comments, social media and other things that are set as the default in the theme).
      2) Ability to delete/modify any of those things inline. So turning off comments would be clicking the red circle with the line through it just like deleting media).
      3) All functions for inserting something into the edit surface together in one tool bar at the top.

    • Matt McLaughlin 3:45 pm on August 9, 2013 Permalink | Log in to Reply

      One more suggestion. One source of confusion that a lot of my users have is that they don’t fundamentally understand that the layout of what they’re typing in changes based on the viewers screen/device. Any way that you can make that more obvious would be hugely useful.

      One way you could do that is instead of one preview, have previews that are keyed to specific breakpoints in the responsive theme. So: View on 27″ monitor, View on 13″ laptop, View on iPad, View on iPhone.

      Alternatively, give the Preview page a horizontal scroll bar at the top that lets the user scrub back and forth through various sizes and devices to see what it does to the layout. I’m thinking that the left side of the layout is big monitors and as you move right if becomes smaller laptop screens. Get even further and there are detentes for various common mobile devices.

    • wycks 6:30 pm on August 9, 2013 Permalink | Log in to Reply

      +1 for Mel Choyces mock-ups, they look amazing. The biggest client frustration (for me) is when they wrestle with the editor, asking people to use shortcodes is not a good solution for formatting.

    • binarymoon 1:36 pm on August 12, 2013 Permalink | Log in to Reply

      Has anyone considered doing something like the theme customiser screen – where the WordPress nav is on the left – and the theme (website) is on the right, and then the post editor looks exactly like the website – so that you edit the theme in place, with styles and whatnot intact?

      • Avryl 1:46 pm on August 12, 2013 Permalink | Log in to Reply

        I’ve done it with a few websites, but font-end editing and post creation would be a lot more challenging to be compatible with all the themes. It could be opt-in for themes to add support, but there will still be a need to keep to back-end editor.

    • Matthew Muro 7:26 pm on August 12, 2013 Permalink | Log in to Reply

      The mockups look great, but I had to comment on the formatting toolbar. Highlighting to reveal a set of essential buttons is not obvious. I’m all fine for that when on mobile where space is precious, but if my monitor can support the space I say keep that out in the open. It just sounds like a usability nightmare.

      • Nick Halsey 8:22 pm on August 13, 2013 Permalink | Log in to Reply

        What if we did something like MS Word does, where there are persistent controls (maybe that can be hidden via screen options), but selecting text also brings up a more convenient contextual toolbar?

        Or, such a toolbar could always be shown when the cursor is active in the content area, although that could get annoying.

    • Dave Clements 1:26 pm on August 13, 2013 Permalink | Log in to Reply

      I like the ambitiousness of the new layouts and they’re certainly a lot less cluttered than the current editor, which is as a result of years of things being tacked on. An overhaul is needed, but what would be really nice would be if an API could allow for adding boxes and functionality to the post editor in a structured and uniform way (such as tapping into the “add content, layout and social” boxes that appear in your first mockup). The biggest benefit to this in my opinion, aside from a more structured and predictable post editor is the ability to transpose those same editor boxes and fields into the mobile apps. The mobile apps are good, but I can’t add SEO metadata using WordPress SEO for example, without visiting the site admin. But if plugins tapped into this API, the mobile apps could include these fields in the post editor to make the mobile apps more usable, which given Matt’s emphasis on mobile moving forward should be an important consideration.

      • Mel Choyce 2:43 pm on August 13, 2013 Permalink | Log in to Reply

        As a non-technical person I can’t speak to how we would accomplish this, but something like that would be a goal with this project. It should be easy for plugin and theme authors to tap into the content block system to add their own blocks.

        • doughamlin 8:03 pm on August 15, 2013 Permalink | Log in to Reply

          Agreed. Something along the lines of register_content_block() is absolutely essential.

          As an example, let’s say there is an FAQ page and I want my non-technical client to easily be able to add questions in a consistently formatted way. I could simply register and Question/Answer content block and my client would be able to add a new block, drag to reorder, etc.

          I run into needs like this constantly with sites. My go-to solution is often to use Custom Field Suite https://wordpress.org/plugins/custom-field-suite/ but this is messy and leads to an inconsistent editing experience.

          • Matt Mullenweg 10:48 pm on August 15, 2013 Permalink | Log in to Reply

            Exactly — if we do this right custom post type usage will probably go down 90%.

            There is of course nothing that says blocks need to be full-width, either.

            • JakePT 2:11 am on August 16, 2013 Permalink

              I think the ability to line up blocks in columns would be huge. At the moment we have clients using Tables or Column Shortcodes, and both are a nightmare.

            • doughamlin 6:25 pm on August 16, 2013 Permalink

              And Matt, I love that you mentioned Storify’s interface in the State of the Word. I think that is a fantastic model, and a few months back I sketched out something for a plug-in based on their interface. I never started coding though because I realized what a big undertaking it would be. So happy it will (hopefully) make it into core before year’s end.

    • rubai 11:12 am on August 15, 2013 Permalink | Log in to Reply

      I think this (http://moc.co/sandbox/post-formats/) mockup is the best of all. The text formatting thing should be present all the time because new users might not find it. Keeping it on top of the text will do. Also keeping the blocks in the sidebar is just awesome. I would suggest keeping a embed box in there because I have seen users struggling to embed youtube/vimeo videos. But again if video and audio stuff(rdio and spotify) things were available in the video and audio boxes respectively than there was no need to add another box. Some themes add new items to the editor like columns and such, so I think keeping it all in the sidebar is the best decision.

      • diegoliv 3:41 pm on August 19, 2013 Permalink | Log in to Reply

        I really like this concept (and Mel’s too)! Content blocks is a great idea, and this kind of concept reminds me a little of Behance’s project editing workflow, which I like very much.

        I saw too one concept here, by Erlend Sogge Heggen, that kind of answer to me two questions that I have:

        1) Sometimes whe want to insert custom fields in a post type that are not directly related to the layout or the content displayed (for example, via the_content() function), so where we would put these fields? The Erlend’ concept uses tabs to separate some sor of “content types”. I think that it is a good idea to use this to make a “custom fields tab”.

        2) This kind of editing workflow (and so Behance’s) is really good when we work with linear content (without columns), but what we do when we need them? Again, Erlend’s concept brings a suggestion to insert a “column” content block to deal with it, and I think it’s a good idea. My only concern here how we could deal with the formatting options in this kind of situation. Also, I link the workflow of SiteOrigin’s Page Builder plugin to deal with columns (https://wordpress.org/plugins/siteorigin-panels/).

        Anyway, this discussion is awesome and I hope to see content blocks really soon in the next releases of WordPress! 🙂

  • Mark Jaquith 3:52 pm on April 11, 2013 Permalink
    Tags: post format ui   

    @saracannon has posted her take on a new direction for post format UI, addressing some of the concerns that surfaced after @lessbloat‘s tests. Re-thinking WordPress Post Format UI.

    The one that is closest to what I was thinking, and the best balance between showing the new UI (to people who are already using post formats or who have a theme with special support), and getting it out of the way once you’ve chosen, is the “In Page decision with post editor greyed out” one.


    I’m curious to know what the UI team thinks. I’d like action taken on this ASAP, so that we can get the UI settled for beta 2.

    • Terry Sutton 3:59 pm on April 11, 2013 Permalink | Log in to Reply

      The modal doesn’t feel quite right to me. A) So many sites are adding those ultra-annoying modals, and It would feel a little like that to me, and B) with the exception of the Media modal, i feel like it doesn’t fit with the current UI direction. It’s very well done, so I don’t want to sound too critical, but it doesn’t feel quite right to me.

    • Mel Choyce 4:01 pm on April 11, 2013 Permalink | Log in to Reply

      Was just about to post this below, but I guess it belongs here now:

      I love these explorations! I know we don’t want increase the barrier between thought and post, but I do think that by choosing to write a post, you’re already making a decision. I like that we’re prompting users into action by making them decide on a post format. I wish we could test this with a selection of .org users, who might have different goals and behaviors than .com and tumblr users.

      Going on to the individual exploration, I’m not a huge fan of modals — especially since they never seem to act correctly on a small screen — but I can see them being a handy solution here. What would happen if someone automatically closes the modal, though?

      Overall, I agree with Mark — I definitely think #2 is the right direction. It makes a lot of sense to me, especially since it’s bringing you to the right screen and prompting you for action without the distraction a modal window might have. It helps directly reinforces how your decision effects what you’re posting. With a modal, there’s a little bit of a disconnect between what you choose and how that changes what you see.

      Building on this, I can also envision a setting that allows you to set your default post format, which would highlight your default when you land on the new post page and have the others greyed out. Alternately, we could do the selected/default icon in color and leave the others b+w. Power users, people who just post one type of content, or even professionals creating sites for clients could set defaults or disable formats entirely, and I think #2s method would make any of those changes easier.

      • Mark Jaquith 4:08 pm on April 11, 2013 Permalink | Log in to Reply

        So I was thinking that if you clicked into the post editor or title, it’d select Standard and let you go on your way. Just like before. And we could give focus to the post title, and select standard if you just started typing a title. Again, just like before. So this way you can’t miss the new UI, but you can also just skip past it when you just want to start composing.

    • esmi 4:09 pm on April 11, 2013 Permalink | Log in to Reply

      The perennial issue with modal windows is ensuring that they are fully accessible to those using screen reading software or those who don’t use a mouse. Ensuring this level of accessibility can put a lot of additional strain on the UI devs. Is that really something you want to impose at this stage of the game?

      • Mark Jaquith 4:13 pm on April 11, 2013 Permalink | Log in to Reply

        I’m not advocating that we use a modal. I agree with your concerns (and have more of my own). See above comments. Updated post with screenshot to be clear about the approach I was talking about.

    • sara cannon 4:13 pm on April 11, 2013 Permalink | Log in to Reply

      The greyed out area can also surface and choose “standard” as a format when clicked / tapped

    • Ipstenu (Mika Epstein) 4:17 pm on April 11, 2013 Permalink | Log in to Reply

      Would it still be possible to switch between? Sometimes I change my mind, and one thing I HATE about how Tumblr does it is that I have to totally start over :/ I Even if there was a warning that any standard specific content would be lost, the main part of the post below I’d like to keep.

      • Chip Bennett 4:19 pm on April 11, 2013 Permalink | Log in to Reply

        Looks like the sidebar meta box is retained – or, is rolled into the Publish meta box, as a dropdown or radio select.

      • sara cannon 4:20 pm on April 11, 2013 Permalink | Log in to Reply

        Yes, in the publish meta box there will be a switcher. I also think this is essential

        • Terry Sutton 4:53 pm on April 11, 2013 Permalink | Log in to Reply

          So I’m clear — the switcher won’t stay above the post title as it is now in Beta1? IE: the icon bar will go away after you’ve made your choice?

          • Mark Jaquith 4:59 pm on April 11, 2013 Permalink | Log in to Reply

            That’s the idea. Big and up top on first load. Tucked away once you’ve chosen (either explicitly or implicitly). Addresses the two big issues we’re having in beta 1: not obvious enough before choosing, in the way after choosing.

            • sara cannon 5:00 pm on April 11, 2013 Permalink

              and resolves any potential confusion for users that might think they can use all the buttons/formats on one post

            • Terry Sutton 5:06 pm on April 11, 2013 Permalink

              Ok. In that case, I’m split on the idea of it going away to a metabox, or staying above the post title as it does in Beta1. So after you’ve chosen which post type, here’s what you see: http://cl.ly/image/2g1f3o2D3m1U

            • Brian Richards 5:36 pm on April 11, 2013 Permalink

              I can’t decide whether or not I’d like for the UI to disappear completely after choosing my post format. I do like the notion of “putting it out of the way”, but what happens if I’ve accidentally clicked/tapped the wrong format and wanted to quickly click/tap on a different one — is the UI only removed after I begin entering content?

              I know from the explanation that the UI just gets moved into the Publish metabox, but it’s unlikely I would know or expect this behavior otherwise.

              The alternative of keeping it in place (and dimming the unselected choices) doesn’t sound like a great solution either because, as already discussed, it stays in the way and could lead to later confusion about the purpose of the buttons (e.g. “is this how I add a link to my post?”).

              Tough call…

    • Chip Bennett 4:17 pm on April 11, 2013 Permalink | Log in to Reply

      +1 to “In Page decision with post editor greyed out. Icons will go away and the “switching” will be in the sidebar like above.” It looks great, and appears to be a huge improvement to what we have now (3.5.1 and 3.6 beta 1).

      -(Eleventy Frillion) to a modal.

    • Robert Dall 5:06 pm on April 11, 2013 Permalink | Log in to Reply

      OMG you are awesome @saracannon I loved how you covered all the bases here… A couple comments.

      The Modal system as @AndyPeatling put it on twitter. “Not sure forcing the UX would be well received for dot org though. Most don’t care or use them.”

      The Post format switching as a radio button would to far to long leading pushing the category, tags, feature image to push them lower in the window.

      Icons with Text +10,000 looks awesome!
      One comment regarding the icons getting greyed out on the hover is it is opposite of the hover state in the admin menu on the left. We should keep the standard hover over icons the same through out the admin section of the site.

      Can we choose icons only or text only or both like Apple offers in there mail application? It seems that would suite the best of both worlds.

    • Tom Auger 5:08 pm on April 11, 2013 Permalink | Log in to Reply

      Really love this new direction. The in-your-face visual icons really bring this often-underused part of the post to the front.

      My only comment is – does the editor really need to be greyed out? Should we not just default to “Standard” and then let the user switch it up from there. I can just see a ton of bloggers who don’t currently use post formats get really annoyed when we add another click to the process.

      • Robert Dall 5:15 pm on April 11, 2013 Permalink | Log in to Reply

        I see your point most bloggers will choose the standard post… It beta1 it already chooses standard by default and I think we should keep it that 🙂

      • sara cannon 5:19 pm on April 11, 2013 Permalink | Log in to Reply

        Mark pointed out above that we will still have the title field focused like normal – so start typing like normal and there is no extra “click” and standard is chosen for you

    • Ryan Cowles 5:38 pm on April 11, 2013 Permalink | Log in to Reply

      Awesome work, Sara! These concepts look rad.

      While I don’t have much to say in regards to the UI itself, I think this part is important: “you can turn all post formats off from within core settings to override what your theme set. ”

      If a new step in the post creation flow is introduced that forces the user to select a post format, I think the user should be allowed to disable it. Therefore users that only use one post format aren’t forced to go through an unnecessary step each time a new post is created. Just my $0.02.

    • Helen Hou-Sandi 6:04 pm on April 11, 2013 Permalink | Log in to Reply

      I think this is a good compromise between representing the “choose once” part and not blocking users from just writing a new post as they currently can. What’s currently in trunk definitely does not reflect that it’s (generally) a one-time format selection before you get started. I think with smart wording in the feature pointer letting the user know that they can turn this off in screen options in addition to the filter that’s already been committed, it will work out okay.

      Question about the “just start typing to make a standard post” interaction, though – what happens to the switcher? Does it disappear and cause everything to shift up while the user is typing? That seems less than ideal to me.

    • Chip Bennett 6:09 pm on April 11, 2013 Permalink | Log in to Reply

      Crazy thought: what if the big ol’ post format icons were stacked vertically, to the left of the post editor (i.e. a third column on the post-edit screen)?

      Still have the everything-grayed-out-before-selection UI, but then let the icons remain where they are after selection.

      That would allow for easy switching, and would not cause the UI to jump around with appearing-then-disappearing icons above the post editor.

    • thirzah 6:13 pm on April 11, 2013 Permalink | Log in to Reply

      (random person chips in) Love it – but minor thought – if they are at the top, and (what looks likely to be) more meta boxes pushing post/data entry ever downwards, would it be possible to make the ‘publish’ box pinnable, or copied at the bottom, or something? – Yours, Lazy Scroller 🙂

    • sara cannon 6:19 pm on April 11, 2013 Permalink | Log in to Reply

      For responsive screens, we can wrap the icons. because they will be eliminated after choice – we don’t have to worry about real estate

      980: ​​http://s.sar.ac/image/3B2H2v0P1841
      768 ​Option 1: http://s.sar.ac/image/1D1e002x2i0X (5 across slightly spread out)
      768 Option 2: http://s.sar.ac/image/2a3u3v3E3p03 (5 across slightly spread out & centered)

    • nathanrice 6:30 pm on April 11, 2013 Permalink | Log in to Reply

      I have some deeper issues with the new Post Formats, but first let me say that I like the idea of a “decision first” approach with the ability to change in the publish box. Makes a lot of sense to me, and doesn’t clutter the post UI with buttons. It’s a little out of the way, which may have UX implications, but the initial decision path more than makes up for that.

      As for the Post Formats strategy itself, I’m troubled by the decision to turn this feature on by default. From reading through a few trac tickets, I can see the logic behind why this decision was made, but it still seems like it’s going to be a bit of a shock, especially to theme developers who may not see this coming, and certainly to users who will now have a UI that their theme isn’t at all prepared for.

      If this is the wrong place for this discussion, please tell me where I can go to bring this up with the powers that be. I’d like to understand the rationale if there was no other alternative, but otherwise, I’d like to see if there isn’t a better alternative than what we’ve got currently. And if my initial assumption is incorrect, I apologize.

    • Hal Gatewood 6:39 pm on April 11, 2013 Permalink | Log in to Reply

      Rough potential tabbed idea… http://goo.gl/143Zu

    • Drew Jaynes (DrewAPicture) 7:40 pm on April 11, 2013 Permalink | Log in to Reply

      I really like this concept a lot better. Plus, there’s parity with the hide/show overlays we used in the menus UI refresh.

      The thing I’ve consistently heard from talking to people about the new formats UI is that an intermediary choice step would solve a lot of the headaches and I think take this approach over what we have now will be a big step in the right direction.

    • Archetyped 4:18 am on April 12, 2013 Permalink | Log in to Reply

      “In Page decision with post editor greyed out” seems like the best option as others have noted.

      I agree with @markjaquith that clicking the title/description fields should automatically select the default post format and close the selection UI, however, I would suggest it be even a bit more flexible than that. I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format (e.g. standard post) and close the post format selection bar just as if someone had selected the format itself. This allows for a much larger hit target for the user to get to the editor and start creating content without much delay.

      I think it was also suggested that the post format selection UI go away immediately if the user starts typing in the title field (focused by default). I like this as well.

      In addition, how about an option in WP’s settings to allow the user/author to set the default post format. The editor fields for the selected post format’s would be displayed by default when creating new posts and the appropriate button would be highlighted in the post format selection UI.

      This would be a productivity boost for users who post mostly videos, or mostly links, or mostly status messages, etc.

      • sara cannon 4:53 am on April 12, 2013 Permalink | Log in to Reply

        “I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format ” — yes! I’m not sure if this was mentioned in the above threads but this is definitely something that should be included.

        @melchoyce also has mentioned the idea of setting a default post format in a comment above. I think that idea should definitely be explored further and is a logical next step. Part of why I think this is – we have ten formats with no hierarchy for preference.

    • Grant Palin 6:48 am on April 12, 2013 Permalink | Log in to Reply

      I generally dislike popups, modal or otherwise, when they are not really necessary. I could have made an exception in this case since the choice it would provide would determine the appropriate UI. It’s something that kinda needs to be done up-front.

      That said, it’s still a jarring change, and the better option may be the row of icons above the editor, which maybe shrinks or fades when a choice is made in order to stay out of the way. At least it’s top and center that way.

    • Avryl 11:24 am on April 12, 2013 Permalink | Log in to Reply

      I don’t really get the concept of selecting a post format. All post formats do more or less the same, you can add media, add a title, add a description/content. Why not just have one and detect what’s posted?

      Or maybe, have two buttons in the media uploader, one “insert in post” and one “make an image post”, same for a gallery, video and audio. When the user adds a link to the content, give the option to make a link post. Maybe this would be more obvious if there’s an “add link” button next the “add media” button or by somehow integrating them both in TinyMCE. A status post can be created if there’s no title.

      I’m just wondering, but what happens when a user inserts an image into the content of a standard post format and nothing else? Then that would be an image post right? Maybe it’s possible to detect if the user assigns the “wrong” post format, as in the UI test?

    • jrbeilke 2:45 pm on April 12, 2013 Permalink | Log in to Reply

      Nicely done Sara. I also prefer the in-page decision for post formats and think it stands out more than the current beta UI without being too obtrusive.

      I am concerned about all of the new decisions that a writer will be faced with when adding a new post. At a minimum the screen options/theme support should help to control the available post formats. Defaulting to a standard post when no selection is made would also streamline the process for those that want to stick with their current workflow.

      Another issue that I’ve run into while testing is the admin Posts screen, and posts without a title. It would be nice to tweak the Posts screen to show a snippet from the post if no title has been set. Maybe it’s just me, but with some of these new post formats (ie Aside and Status) a title isn’t necessary, but makes administration difficult without it.

      Posts without titles – https://i.imgur.com/M40SwIR.jpg
      Mockup Posts with snippets – https://i.imgur.com/WtwfSnt.jpg

      • Konstantin Kovshenin 2:46 pm on April 12, 2013 Permalink | Log in to Reply

        Related/possible solution: #24011

        • jrbeilke 3:09 pm on April 12, 2013 Permalink | Log in to Reply

          Thanks, didn’t see that ticket.

          Looks like it might work, but if it’s tied into save_post then what if there are already existing posts without titles? Will the user have to go through and re-save all of the posts that are missing a title?

    • Matt Mullenweg 8:10 pm on April 14, 2013 Permalink | Log in to Reply

      Also as food for thought: we’re supporting too many formats. Anything where you’re giving a user 10 choices before they get started is going to be rough from a usability and design perspective, especially given it’s not really obvious what that choice does not just to the form, but to the post when it’s published.

      There is some direct and indirect data about which formats are most used, perhaps we could apply our 80/20 principle to just supporting the 3-4 formats that would make the biggest difference to users.

      • Ipstenu (Mika Epstein) 3:49 am on April 15, 2013 Permalink | Log in to Reply

        What if you consolidate?

        Image and Gallery – Make it one, and if someone puts in an image, it shows just one. If it’s a gallery code, or they attach mulitple images, then use a gallery? To steal a page from Tumblr, that’s how they do it.

        You could do the same for audio/video maybe. Though that would be harder to theme in both cases.

        • sara cannon 10:51 pm on April 16, 2013 Permalink | Log in to Reply

          ^ I really like this solution – we just use the format “image” in the UI, but then when a user attaches more than one, it automatically makes it the “gallery” format in the background (no need to manually switch). It solves a UX problem where someone might decide to upload more than one after-the fact. (image->gallery is really one of the main use cases for decision-changing that I foresee)

      • Mark Jaquith 12:46 pm on April 15, 2013 Permalink | Log in to Reply

        The formats have been defined in code and in the codex for a while, so dropping some formats would result in data loss for some.

        One thing that has been considered is hiding less-used formats, so that instead of 10 options, you might have 5 options and a “more” button.

      • Ian Stewart 3:21 pm on April 15, 2013 Permalink | Log in to Reply

        +1 for hiding seldom used formats.

      • Andy Peatling 5:09 pm on April 18, 2013 Permalink | Log in to Reply

        I posted usage stats for frontend WordPress.com posting here: https://core.trac.wordpress.org/ticket/19570#comment:154

    • chabis 10:32 pm on April 17, 2013 Permalink | Log in to Reply

      There needs to be some careful rethinking about the post formats. two assumptions:

      A. many users want to create a post with a single content (gallery, audio, image, etc) and a post format is fine for that.
      B. many other user want to create a post that contains an image, a text, another image, then a video, etc.

      Now how do you make clear to the user that A. is not equal to B.? A. is a complete view change from a Post to a Gallery whereas B. is a Post with multiple content elements.

      In my point of view, and as mentioned before, the user gets confused by post-formats and the icons. Especially the icons can me users think that they need to click on the format to insert a media. And at the same time the decision hurdle is too high, maybe a user changes its mind during the editing process, what do you do then?

      Maybe we need to think about the editor in a slightly different way. It should be intelligent enough to make assumptions with the added and future content. The text-editor of koken.me is just a wonderful inspiration for that:


      • Anointed 6:37 pm on April 21, 2013 Permalink | Log in to Reply

        WOW, just WOW, that koken admin is SWEET! Especially the media manager. thnx for the link, not sure I would have ever found it on my own. Really gives the WordPress media manager something to aim for.

    • Anointed 6:34 pm on April 21, 2013 Permalink | Log in to Reply

      Not sure where to make this request, but this seems as good a place as any.

      I actually like the new post-formats setup, especially the video format where the actual player shows up on the page after clicking publish. This makes it so much easier to understand what is happening and to make sure the video oEmbed url works and you have the right video.

      My only request, is it would be nice to have the video player display PRIOR to clicking publish.

      Right now, we are able to make sure we have everything else right prior to publishing, but cool as this new player showing up is, we still don’t know that everything is perfect prior to publish as we can’t see the player.

      So, please make the player show up as soon as the oEmbed url/embed code/etc is inputted into the box.

  • Helen Hou-Sandi 12:21 am on November 16, 2012 Permalink  

    Coming soon: Weekly updates 

    Part of the duties of a team rep for each area of contributors is to be responsible for a weekly update on the group. At this moment, there is not an established UI team rep, but as a core development team representative, I’m happy to step in until new elections are done sometime in the near-ish future.

    Part of our UI group discussion at the Community Summit was about how we can make these weekly updates both informational and effective, especially when it comes to attracting and retaining contributors. Here’s what we’re thinking:

    • A breakdown of what we did this week, such as discussions held (with links to IRC as applicable), patches uploaded/worked on, and what’s changed in core in a more prose-y manner.
    • Links to ideas from the community at large, which would likely be blog posts on other sites, including your own. Discussion would be encouraged over on those posts rather than here – the creator should be able to really take ownership and pride in their idea and be centrally involved in the discussion. The idea is to both expose some of the great ideas that are happening and open up a platform for idea generation that isn’t “from the top” or carrying the official weight that gets associated with a post on the Make P2s, which are largely status-driven rather than hypothetical.
    • Weekly IRC chat summary with anything not covered above.
    • What needs to get done this week, including any assignments that have been made and ones that need volunteers. We’re thinking this will be a great step toward exposing more ways to get involved in case you’re still figuring things out.

    Thoughts? Love it, hate it?

    • karmatosed 10:11 am on November 16, 2012 Permalink | Log in to Reply

      I really like this idea be great to keep up with things. The last point will help greatly in finding ways in for me and others also so that’s really cool. Not everyone can every time get to the IRC meeting so it’s a great way to keep up to date and involved.

    • McGarityDotMe 11:59 am on November 16, 2012 Permalink | Log in to Reply

      All of this helps me out, as I’m trying to get my feet wet and understand more about sub-groups like this I’m interested in participating with. The IRC chats have been where I’ve started, but that’s often like jumping into the deep end of a pool after a swim lesson. 🙂 I especially like the last bullet point, as it’s not immediately clear to this n00b what’s in flight, what’s about to start, etc.

    • lessbloat 12:19 pm on November 16, 2012 Permalink | Log in to Reply

      Yep. +1 to all of it. 🙂

    • Jane Wells 1:56 pm on November 16, 2012 Permalink | Log in to Reply

      I was going to post this proposal to the team reps blog, and will, but since you posted this, I’ll pre-empt myself and post my thoughts here as well.

      I’ve been thinking more about this since our team reps discussion at the summit, and I’m still thinking we should re-jigger the UI group. When we talk about core UI, it really seems like that discussion should be happening as a part of the core project, rather than sidelined as a separate group. When I started the UI group, it was because we weren’t a project that really had design contributors yet, and I wanted to change that, but it would have been disruptive to try to get that started on wpdevel (as it was called then). Now that it’s make/core, and now that there are a number of designers (members of this group) participating actively in core, I think it’s time for a change to recognize that core UI is not a separate project, it is an integral part of core.

      At the same time, there are design needs across the WordPress project, like for events, documentation, site improvements, etc. Just as developing a system of team reps was intended to put other contributions on a level with core, I believe it’s time to rethink the UI group altogether.

      What I’d like to see is the stuff going on as “the UI group” currently to be treated as a regular core component (with component owner, if that’s still the plan post-summit) rather than an entirely separate group. I’m thinking the same thing about Accessibility. If something isn’t a separate, sovereign group that gets to make decisions (in this case, UI decisions still are ultimately made by the core team/release leads, not by a standalone UI group), then it should be an active part of the main group. In other words, I think it’s time for UI contributors to level up to the main core team. Updates about what is happening with core UI would be part of the regular core team updates.

      Then, we’d create a Design Corps of all the designers (graphic, interaction, web, print, you name it) that would be contributing to the project as a whole, rather than just core, and to all design needs, not just UI. Each of the contributor groups would have its own embedded contributing designers (like the core ui contributors), while the design corp *group* would be a place to share resources, discuss design problems across teams, and for team reps to post requests for design assistance when needed. This would solve several problems (other groups don’t have design resources, and they see the UI group as limited to CSS or usability).

      I will admit that this is basically a ripoff of how Automattic handles design (just as our new contributor group blogs and team reps are a ripoff of Automattic’s team updates system). The Automattic design group system has been in play for three and a half years now, and I think it works really well. It allows designers to be integral members of project teams, while also being part of a broader design group.

      Anyway, I’ll be proposing this to the team reps for consideration, but would like you guys to be thinking about it, too. @lessbloat and @chexee, as UI Group members who have experienced the Automattic model first-hand may be the best able to comment on whether it is a good model.

      • Helen Hou-Sandi 2:40 pm on November 16, 2012 Permalink | Log in to Reply

        +100000000000 to the overall direction of this group within the project as a whole. Siobhan’s post about handbooks earlier is in a similar vein – UI isn’t a separate handbook, but a component of each contributing area’s handbook. I also think it would be really helpful to promote areas beyond the core web application for folks to actively contribute to – it’s definitely different than ideas for, say, a website. I see plugin developers especially liking having a way to join forces with UI/UX-minded types 🙂

        P.S. Hey everybody, do get involved in the handbooks if you’re able and willing!

        • Siobhan 6:47 pm on November 17, 2012 Permalink | Log in to Reply

          Yes! Handbooks are cool and awesome and people should get involved!

          Also, I think a design corps group is an excellent idea. I have been thinking that we’ll need design people to help out with making the handbooks look beautiful and I had no idea where to look. This would solve the problem for me 😀

      • lessbloat 5:17 pm on November 16, 2012 Permalink | Log in to Reply

        Love it. I think that’s a great idea.

      • Mel Choyce 8:06 pm on November 16, 2012 Permalink | Log in to Reply

        This sounds like a great way to create more opportunities for designers to get involved. Awesome idea!

      • studionashvegas 11:13 pm on November 17, 2012 Permalink | Log in to Reply

        Multidisciplinary groups like what you’re suggesting are very common in the agency setting, and (from what I’ve experienced) seem to work very well, as all of the parts know what’s going on (which leads to a more cohesive experience).


      • karmatosed 11:53 pm on November 17, 2012 Permalink | Log in to Reply

        Sounds like a great idea and gives lots of scope for getting involved which is really cool.

      • Amy Hendrix (sabreuse) 2:26 pm on November 18, 2012 Permalink | Log in to Reply

        Yay! Destroy the silos!

      • Chelsea Otakan 10:12 pm on November 18, 2012 Permalink | Log in to Reply

        The Design Corps within Automattic work pretty well, IMO. We are a tight group and do our best to communicate well with each other.

        I really like the concept of spreading out the UI group to include design across the WP community. A lot of designers want to pitch in, but their skills might not be the best fit for core, but there’s currently no formal way to pitch in anywhere else.

        In short: Jane said all the things already 🙂 Sounds great to me! Weekly check in post for each group would be helpful.

      • Sheri Bigelow 4:39 pm on November 27, 2012 Permalink | Log in to Reply

        +1 I like the proposal. Seems to me developers would be more likely to reach out to a multifaceted design group vs. the current setup which is pretty intensely focused on Core UI.

    • acsearles 4:35 pm on November 16, 2012 Permalink | Log in to Reply

      I’ve sat on the sidelines for a long time, wanting to get more involved but not knowing where to get my feet wet. I’ve been following along, reading what I can and trying to stay up-to-date on the happenings of this group. So, I think this could help more people have an easier entry point into contributing. So I can continue to keep watching and when I see some low hanging fruit I’ll be able to pick a few things off. Eventually, as I get more of a grasp about what’s going on, I’ll be able to contribute in a more substantial way.

      Jane, I also really like the idea of designers becoming apart of other groups that are working on other projects. I know that in my line of work I do best when working on a team of people with different skill sets, then coming back to the group of designers to share ideas and critique.

      Sounds like so many good things came out of the summit. I’ll be excited to get started. And hopefully we can see everyone in Birmingham at our next WordCamp. Which reminds me, @saracannon, we need to get that started really really soon.


    • RDall 5:44 pm on November 16, 2012 Permalink | Log in to Reply

      I really like where this is going… I also agree with what Jane said as well… The UI group should be more then just the core dev… As I have struggled to find a place that I can contribute too that both use my strengths and fits WordPress needs as well…

  • Jen 5:30 pm on July 6, 2011 Permalink  

    Sometimes our admin ui is crap, depending on the screen size/resolution/browser width combination. Should we jump on the responsive design bandwagon with the admin for the next major release? Thinking maybe @saracannon could head it up if so, given her previous experiments with same?

    • Andrew Ozz 8:18 pm on July 6, 2011 Permalink | Log in to Reply

      I was planning to do some testing/fixes for iPad + friends, mostly to make our JS tap aware and the CSS rotation aware. Not sure we can achieve proper support for smaller screens.

      • saracannon 8:31 pm on July 6, 2011 Permalink | Log in to Reply

        I wonder what the percentage of users access their site via the browser on mobile / ipad rather than an app. I can see optimizing for mobile to be very helpful. Just took a look at 3.2 on my iphone … there is a lot of potential, especially for the collapsed-menu to work really nicely.

        • Andrew Ozz 8:50 pm on July 6, 2011 Permalink | Log in to Reply

          Looking at http://en.wikipedia.org/wiki/Usage_share_of_web_browsers the global percentage is quite low but growing. Surely something to think about, maybe not for 3.3 but soon. I think tmce will have support for iOS in the next major version too.

          • RyanWilliams 4:00 pm on July 19, 2011 Permalink | Log in to Reply

            There’s an official WordPress app which strives to provide an optimal small screen experience. Should this effort not be combined with any effort to make the admin UI itself work well on small screens?

            As users of the iPhone Facebook app probably know, it’s a bug-ridden mess that has less features and a more fiddly interface than the more recent mobile-optimised site — yet it’s still promoted as the optimal small screen interface.

            It’s only after months if not years of this horror that they’re finally conglomerating the two (the app’s news feed now literally just fetches the mobile site’s HTML and shows it in an an-app Safari window). Ideally this process will be avoided for WordPress.

    • saracannon 8:20 pm on July 6, 2011 Permalink | Log in to Reply

      This is very true. Especially when it comes to very large monitors. I find myself shrinking down my window for my post editor because I dont want to type across the screen. Simple limitations and modifications could potentially go a long way. I would love to start looking into this.

      • Jane Wells 8:50 pm on July 6, 2011 Permalink | Log in to Reply

        Yep. It’s officially your project. 🙂 Investigate/experiment at will, report to me + @azaozz as things come up so we can discuss anything contentious, and let’s start using UI meetings for it. I’ll put out a call for people to help. A lot of people would like it to look better on their high res screens.

      • Hugo Baeta 3:56 pm on July 7, 2011 Permalink | Log in to Reply

        And the other way around would be interesting too. What about optimizing the admin for smaller mobile screens?

        • saracannon 7:41 pm on July 7, 2011 Permalink | Log in to Reply

          I agree hugo 🙂

          and the iphone needs some love anyway. check out the WP logo in these screen shots: http://cl.ly/1Y2O14252d2l1W0b0B0G
          Zoomed: http://cl.ly/1n2X1M2t3z2n3K322T22
          I havent looked yet to see if there is a ticket…

          In thinking about this when it comes to the mobile bag of worms: if we start heading that direction for small optimization we’re getting closer to an app-like-influence. One idea would be to somehow encourage / force collapse the side admin menu and have the icons larger to make it more interface-like but still keep the style of the admin intact.

          I can see a use case for when moderating comments via email.. clicking on the link.. going to the wp-admin in your phone’s browser.. (at least the log in screen is already optimized! yay!) and having it be actually a decent experience where you dont have to zoom to read it or fumble to click the 8px button that is “spam”

          side note: I updated all my network to 3.2 from my iphone just the other day… I dont believe you can do that from the iOS app. If we decide to work on improving the mobile “wp-admin” experience, everyone could possibly feel comfortable updating their sites and posting/moderating on the go.

          • Terry Sutton 11:02 am on July 8, 2011 Permalink | Log in to Reply

            Great to see some movement on this.

            Quick and potentially obvious question: If we force-collapse the left hand admin menu, there seems to be pages we can’t access. Categories, for example.

            I might be missing something, but I can’t seem to get at the Categories page without being able to hover over the Posts thumbtack icon.

            Am I missing something?

            • Terry Sutton 11:06 am on July 8, 2011 Permalink

              Ack! Disregard!

              I tried this on my iPhone yesterday—when I clicked a button in the admin menu, it would lead me to the main landing page fo the button. It does work for me now though. When I click any of the buttons, I do get the dropdown.


          • Jorge Bernal 4:47 pm on July 27, 2011 Permalink | Log in to Reply

            Yep, we (mobile team) get lots of feature requests to add “advanced” features to the mobile apps (user/plugin management, specific plugin support, …).
            If wp-admin adapts well to small screens, the apps could just focus on the most useful features (posting, moderating, reading)

            And besides the apps, for many people (specially Asia and Africa) mobile internet is their only internet. Ideally you should be able to set up WordPress and use it from any mobile device (Opera and Nokia are stil big), without needing to go to a computer. That’s probably way beyond the scope for 3.3, but I think it should be a long term goal.

            For 3.3, I’d be really happy with an improved experience on iOS and Android

            If you need testing, coding, or anything for this, we’re here to help 🙂

    • Ran Yaniv Hartstein 3:50 pm on July 7, 2011 Permalink | Log in to Reply

      I like the idea of a more width-sensitive Dashboard – the Dashboard now can get quite weird on large monitors too, with very long lines for example in the settings pages.

    • Elio 7:01 pm on July 7, 2011 Permalink | Log in to Reply

      An outstanding move. Large monitors could use two sidebars instead of one in the post/page writing screen.
      How can I contribute to this?

    • Chelsea 6:14 pm on July 18, 2011 Permalink | Log in to Reply

      Helpful new discovery from @stephdau: http://www.getskeleton.com/

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