WordPress.org

Make WordPress UI

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Mel Choyce 8:16 pm on August 8, 2013 Permalink | Log in to leave a Comment
    Tags: 3.8, 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: http://melchoyce.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

              Joen,

              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

              Krogsgard,

              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.

          • 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.

        http://www.binarymoon.co.uk/2013/05/redesigning-the-wordpress-post-editor/

        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

            +1

    • 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: http://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:

      http://i.imgur.com/RA02ic4.png

      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:
      http://wordpress.org/plugins/tablepress/
      http://wordpress.org/plugins/easy-table/

    • 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.

  • Till Krüss 11:21 am on July 30, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Heya! It’s been over a month since the release of MP6 1.8 and we’ve been busy making MP6 better and better. We had 98 commits since version 1.8, containing so many changes, it’s too much to list each one of them, but here’s a summary:

    • 3.6 Compatibility
    • TinyMCE Advanced Compatibility
    • Added color schemes component, including a blue theme.
    • Improved font sizes, margins, paddings, hover states, animations and shadows across the entire admin UI.
    • Improved responsiveness, especially of the admin-bar and editor.
    • MP6-ified TinyMCE modals.
    • Overall RTL improvements.

    The experimental color schemes component is by default disabled. If you’d like to help us test the blue color scheme, define define( 'MP6_COLOR_SCHEME', 'blue' ); in your wp-config.php and enable the component by un-commenting line 24 in plugins/mp6/mp6.php… or make your own color scheme and post it below!

    MP6 1.9 includes contributions from Joen Asmussen, Ben Dunkle, Kelly Dwan and myself.

    Thanks to everyone who’s reported bugs and contributed ideas and suggestions, it helps us a lot! Keep them coming…

     

    • Ayman 11:46 am on July 30, 2013 Permalink | Log in to Reply

      It’s nice to see that the Idea of having another color schema is being applied (Even if it’s disabled by default)

    • tomdryan 12:09 pm on July 30, 2013 Permalink | Log in to Reply

      Thanks for all your work Till! Where is the best place to provide ideas and suggestions for MP6? I have a few small tweaks in mind that would improve WP usability immensely.

      • Mel Choyce 2:27 pm on July 30, 2013 Permalink | Log in to Reply

        Feel free to post them here. :)

        • tomdryan 3:50 pm on July 30, 2013 Permalink | Log in to Reply

          Okay, here you go:

          WordPress MP6 1.9 UI Proposal
          1. Add “pin” option to make the left dashboard menu persistent when browsing site content, just as it is with the admin bar. Clicking the “W” in the admin bar could toggle the dashboard menu on/off instead of loading the About page.

          2. Move the About page from the “W” to the Welcome menu section and add as much technical information as possible to the About section, like disk space used by site, available space, Perl version, memory usage, current site health, etc. (where possible)

          3. Make the dashboard menu “collapse/expand” sticky (no auto collapse) and/or add a manual “pin” option

          4. Single window use case: Currently, WP is a bit clunky to use for those without dual monitors or working on laptops. To fix this, add a button in the Admin bar to that toggles between the current WordPress admn page and the last site page viewed (with auto reload). This would really speed interactive editing! This would be similar to the way the View Page/Edit Page toggle works, but be more universal when working on other parts of a site.

          5. Populate dashboard menus such as Posts, Pages, User, Themes, etc. with submenus which include recently used items for quicker access

          6. Have an option to preview the destination page when you hover over a dashboard menu choice, a click makes it active. This eliminates the back and forth clicking that many new users must do to find the right option.

          7. Extra credit. Add an easy way to list all the sites the logged in user administers in the admin bar and enable them to switch between them with a click. Perhaps this could be in the “Visit Site” section.

          • Native Imaging 4:35 pm on July 30, 2013 Permalink | Log in to Reply

            what?

          • Ipstenu (Mika E.) 5:48 pm on July 30, 2013 Permalink | Log in to Reply

            Tom, MP6 is skinning the admin, not massively changing the fundamental functionality of the dashboard. #2 is out of scope, as that would require a total re-do of the page in core :) #4 and #7 also are beyond MP6.

            • tomdryan 7:44 pm on July 30, 2013 Permalink

              Fair enough on 2, 4, 7. (although I think #4 might be able to be hacked fairly easily from the existing edit/view page code). Where does that leave us on 1, 3, 5, and 6 then? :)

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

            1: We were actually talking about implementing something similar as a later iteration. Matt Thomas mocked up some great ideas a little while back, which we’ll hopefully get to explore during the 3.8 release cycle.

            2: Out of scope, but maybe worth making a feature request for it on trac.wordpress.org. Would also be a great plugin.

            3: Can you elaborate on this a bit? I’m not sure I totally understand.

            4 + 5: Out of scope — seems like that would take some pretty intense back-end dev work to implement, and we’re pretty much limited to css and js with mp6.

            6: Worth exploring during 3.8

            7: Also out of scope

            Thanks for your suggestions. :) If you think or more, keep posting them in this (or subsequent) mp6 threads.

            • tomdryan 8:50 pm on July 30, 2013 Permalink

              You’re welcome! As a relatively new user to WordPress, its usability quirks are fresh in my mind and several of these changes would make a huge difference in usability and interface consistency.

              What is the best way to get the “out of scope” and “worth exploring: suggestions into formal consideration and to review/provide input as those features are developed? Is that trac?

              Clarification on #3: Currently in MP6, if you expand the dashboard menu on the left hand side so that it shows both icons and text labels, once you make a menu selection, it automatically collapses back to display icons only. It would be nice if it did always not revert back to icons, but kept your setting, either icons or icons+labels. If a user decides they don’t want to see the text labels, they can collapse it manually.j

              Let me know if that makes more sense…

            • Mel Choyce 9:11 pm on July 30, 2013 Permalink

              Sorry @tomdryan, can’t indent another level so I have to reply to my own comment.

              I’m unsure if adding ideas to trac would be best, or if you should wait a few weeks for development of 3.7 and 3.8 to get more underway and bring it up after a #wordpress-dev meeting on IRC. Hopefully someone else will chime in with their thoughts regarding that.

              Re: #3, that actually sounds like a bug — what device/OS/browser are you using? The menu should behave as you’re describing by default (and does for me in Chome on Mac)

            • tomdryan 9:18 pm on July 30, 2013 Permalink

              I’m using Chrome (Version 28.0.1500.95 m) under Windows 7. I just tested in IE (v10.0.9200.16635) and it’s doing the same thing. Also, another issue is that when I expand the menu to show icons+text, it does a two step display of the text, first the text appears flush to the very edge of the page, then it jumps to proper location. It makes the menu expand function look jumpy. It’s doing this in both Chrome and IE.

    • JonMasterson 12:48 pm on July 30, 2013 Permalink | Log in to Reply

      This is so cool. Thanks for your work!

    • Native Imaging 4:12 pm on July 30, 2013 Permalink | Log in to Reply

      Checking it out now. There was a few small problems with the admin bar. Lately since “-webkit-overflow-scroll: touch;” is standard in mobile devices, i have to push for this being used in the admin bar, especially since there will never be a perfect way to allow other plugins to utilize the top level admin bar.

      Oh, the blue makes my eyes feel like they are going to bleed, please don’t make it the default color or i will probably modify the plugin. There was a joke recently floating around about how the WordPress admin should match the color of facebook so beginning users can mentally grasp the options. PLEASE DONT. In-fact, the colors should be customizable.

      There are some plugins that have issues with the new vector icons such as Woocommerce.

      Also, when viewing the Admin on Android Motion, the Menu icon floats above the admin bar in its own block with a transparent background.

      And the Scroll bars need to be styled for web browsers.. Right now, there are the hideous mac/windows scrollbars.

      Un-Checked check boxes are all collapsed to 0px width.

      Several Input Text & Text-Area Fields are overflowing out of their containers as well as many format breaks with other plugins. I know there is no 100% proof system, and will require some plugin developers to make their plugins play nicely with MP6, but it’s definitely worth taking a look at to see if the MP6 can handle small layout issues. ie FontPress is an example of layouts breaking.

      Lastly for now:
      I dont think the media uploader works at all among many other WP Core functions.

      Thank You for all of the hard work! I’m extremely excited this new system is being developed. I still think that a more touch-swipe horizontal-carousel menu system with large icons is the way to go. I wish that things would be much more fluid and user friendly, but i’m just a dreamer.

      • Native Imaging 5:16 pm on July 30, 2013 Permalink | Log in to Reply

        One thing I wish something could be done about is the hideous white screen for the inner page content. It really kills the eyes after starring at it day in and day out. I know it could be a headache for handling some plugins, but not nearly as bad of a headache that millions of WordPress users get everyday form looking at the bright-white page wrapper background.

        Also, i’ve found icomoon.io to be thee best font-glyph system out there. They allow you to upload your own SVG’s as well as saving the JSON file to backup and restore your font glyph sessions….

    • hakaner 4:21 pm on July 30, 2013 Permalink | Log in to Reply

      Wow, this is a great! I’ve created a gray version: http://bit.ly/18L2Oon

      • BandonRandon 7:52 pm on July 30, 2013 Permalink | Log in to Reply

        Just a quick look over the grey version. You may want to name `colors-blue.css` to `colors-gray.css` you also have `This is the CSS file that makes MP6 blue by
        overriding MP6′s default styles.` if this makes it gray that is not true :)

    • Samuel Wood (Otto) 8:14 pm on July 30, 2013 Permalink | Log in to Reply

      Note that the color scheme is experimental, and probably will be implemented somewhat differently later. The way MP6 is (ab)using the admin color schemes offends me slightly, but it’s my own fault since I wrote it that way to begin with. I’ll probably pull it apart and make it do-it-right a bit later. :)

    • hakaner 8:20 pm on July 30, 2013 Permalink | Log in to Reply

      Thanks BandonRandon. I forgot this line in the colors-blue.css but if I change the name of colors-blue.css, you need to specify the new name in the colors.php. So I left it as it is.

    • BandonRandon 8:26 pm on July 30, 2013 Permalink | Log in to Reply

      Like @Otto said above, the color scheme is expermental. However, there appears to be a major bug that requirers the color scheme to be colors-blue. Here is a gist of the problem and a simple fix. https://gist.github.com/BandonRandon/fa9d631e2e91995f0510 Note, this will only work if the color scheme is required to be defined in the wp-config.php

    • Native Imaging 9:22 pm on July 30, 2013 Permalink | Log in to Reply

      I have one odd request that might be useful and solve some concerns about new design techniques…

      I’ve noticed a lot of websites are now using sticky headers & Navs for slicker navigation through their sites, but the wordpress admin conflicts with fixed positioned elements since it too is fixed at the header. I’ve tested a few snippets to move the admin to the bottom of the html window and the sub menus popping up above instead of down below, but this probably isn’t really the best idea for the Admin area. Although it did work, a few small kinks with MP6, i though it might be a good idea to have a check box or select option to move the admin bar above or below on the front-end (since MP6 is a rework for the WP Admin UI).

      • Seven sparks has implemented this for their new Sticky Nav extension.

    • Avocadesign 3:28 am on July 31, 2013 Permalink | Log in to Reply

      I’m also seeing checkboxes on the post and page edit pages collapsed to 0 width

      I’m sure you’re also aware to but the #post-body-content is missing the margin-bottom: 20px; to replicate the margin of the other meta boxes and the top one is currently flush with the bottom of the content editor.

    • Ipstenu (Mika E.) 3:34 am on July 31, 2013 Permalink | Log in to Reply

      Weird alert ‘box’ showed up when I had an upgrade available.

      http://cl.ly/image/0V1P3N2B372B

      It went away as soon as I updated the plugin, but that was totally weird.

    • Nick Halsey 3:35 am on July 31, 2013 Permalink | Log in to Reply

      I missed some other stuff in the editor styles. The biggest issue now is that it’s inheriting mp6 styling instead of theme styling unless the theme styling is fairly specific.

      Since Twenty Thirteen’s header colors are the same as the body text colors, they aren’t explicitly defined. So tinymce-dialog.css:394 causes blue headers in Twenty Thirteen, which are obviously out of place. I like the design intent a lot; perhaps there’s a way to only load some of that stuff (including open sans) if there are no theme-defined editor styles. That’s probably more difficult to do from the plugin, though.

      The beautified code looks much nicer, by the way!

    • tomdryan 8:32 pm on July 31, 2013 Permalink | Log in to Reply

      Is it possible to make it so the left dashboard menu is fixed and doesn’t scroll along with the page (i.e. the same behavior as the admin bar)? This would make it easier to work with WP since the menus would always be in the same location. Thanks!

      • Till Krüss 1:54 am on August 1, 2013 Permalink | Log in to Reply

        This is already happening as long as your browser window is taller than the admin menu.

        • tomdryan 12:59 pm on August 1, 2013 Permalink | Log in to Reply

          Doh! I see that now. I was playing around with with a shorter window.

        • tomdryan 2:55 pm on August 1, 2013 Permalink | Log in to Reply

          Now I recall where I had found this issue previously…If you have JetPack loaded and click on the JetPack menu choice, for some reason, that left admin navigation menu is no longer fixed,. but it scrolls with the page. This happens even when the browser window is taller than the admin menu on both Chrome and IE (Windows 7). The JetPack menu option is the only one that I have found that does this. Strange.

        • tomdryan 3:25 pm on August 11, 2013 Permalink | Log in to Reply

          Till, here is an idea for a different way to handle the “browser window too short to display entire admin menu” issue:

          Currently, if the browser window is too short, we just throw out the sticky menus all together and scroll with the page, no matter how long that page is.

          The proposal for those cases is to scroll the admin menu with the right side page just until the the last menu item is displayed and then lock it again in that position unless the user starts scrolling up again and then allow it to scroll with the page until the top of the admin menu is reached,.

          This way, you can handle the case where the window is too small, but the user will never lose site of the admin menu. It is important to the UX that the user not ever lose site of that menu. Also this gives a very smooth feel to the admin interface.

          You can see an example of how this works in action in FaceBook. The ads on the right hand side of the page will scroll until you reach the last ad, then it will stay fixed on the page,even though you keep scrolling the page (although they make you go all the way back to the top of the page before you can see the top of the ad column).

    • tomdryan 12:29 am on August 1, 2013 Permalink | Log in to Reply

      I’m not sure if this is the best place to put this, but I wanted to get it out there for discussion (happy to post it somewhere else if that makes more sense). Here is a proposal to organize the admin menu in a way that better meets the needs and expectations of users (especially those new to WP!). Some of the changes are as simple as renaming existing options to be consistent across the entire menu and some of the changes will likely be a bit more involved….

      WordPress New Admin Menu Re-Structure Proposal.

      Dashboard

      Posts
      Manage Posts
      Add New
      Categories
      Tags
      Settings (was: Settings>Writing)

      Media
      Manage Media
      Add New
      Settings (was: Settings>Media)

      Comments
      Manage Comments
      Settings (was: Settings>Discussion)

      Pages
      Manage Pages
      Add New
      Settings (was: Settings>Reading)

      Layout (could be included under Pages instead)
      Menus
      Widgets

      Users
      Manage Users
      Add New
      Edit Current Profile

      Themes
      Manage Themes
      Add New
      Customize
      Header
      Editor

      Plugins
      Manage Plugins
      Add New
      Editor

      Tools
      Import
      Export
      Updates

      Site Settings
      General
      Permalinks

      Help (this should also go on the admin bar under a “?” icon)
      Welcome
      About WordPress
      wordpress.org
      Documentation
      Support Forums
      Feedback

      —————-
      JetPack
      other plugins, etc.

    • titanas 2:22 pm on August 2, 2013 Permalink | Log in to Reply

      Inspired by the new MP6 i created a quick mockup (13-inch screen laptop) for a possibly the new admin. Maybe MP6 v20. My three rules of thumb are 1) speed 2) reduced clutter 3) adaptability

      I’m sure that data from WordPress.com could reveal real usage patterns but judging from my daily habits as a power user i rarely need the full menu on the left, even collapsed.

      Since the top bar is pretty much default, i thought we can mimic the design of the WordPress iOS app for simplicity, functionality, ease of use and speed.

      There are a few ideas like universal search (posts, pages, attachments, comments etc) i couldn’t resist to include :)

      Mockup available here https://dl.dropboxusercontent.com/u/184353/wordpress-admin-mockup-v-01.png

      • tomdryan 3:29 pm on August 2, 2013 Permalink | Log in to Reply

        Thanks for the mockup @Titanas! I can’t wait to get a chance to play with it to see how it works in action.:) In any case, we should unify the functionality (eliminate duplication) of the left and top admin bars, whether or not they remain separate items.

  • Lance Willett 12:07 am on July 29, 2013 Permalink | Log in to leave a Comment
    Tags: dashicons, genericons,   

    Discussing Genericons and Dashicons with Ipstenu and George Stephanis at WCSF Contributor Day, and wanted to bring this up for more discussion.

    See also #24864.

    Proposal: could we merge the two icon sets and have it be included in core?

    A few things to consider:

    • We’d have only one icon source to update.
    • There’s already enough overlap. (But, would Genericons users want the extra icons?)
    • Bundling in core will mean fewer themes and plugins needing to maintaining their own version.
    • Would this bottleneck maintaining the icon source over time? If it’s tied to core development cycle it’d be slower to iterate.
     

    • Ipstenu (Mika E.) 12:46 am on July 29, 2013 Permalink | Log in to Reply

      I’m not worried about the bottleneck since we don’t update all THAT often, rught @joen?

    • George Stephanis 12:51 am on July 29, 2013 Permalink | Log in to Reply

      • Graceful degradation where the icons don’t show on IE7 is acceptable to pretty much everyone I’ve run it past.
      • An updated consistent core version would prevent situations where a theme and a plugin both try to enqueue genericons, and the older one ‘wins’ out, leaving the new one with a broken icon that isn’t in the new set.
      • There could be a plugin that is ‘bleeding edge’ genericons, that does a version_compare() and swaps out the source if its version is higher.
      • I don’t really care whether they merge or not.
      • There is currently 17 themes on .org and 4 plugins that bundle genericons.

    • Joen Asmussen 5:39 am on July 29, 2013 Permalink | Log in to Reply

      I’m afraid the two fonts can’t be merged at all. Aside from the stylistic differences which I feel should be enough to let them stand alone, technically the two fonts have different pixel grids and font metrics. Genericons uses a 16×16 pixel-grid, and Dashicons uses a 20×20 pixel-grid. It would be unfeasible to redesign one font to fit in the other grid. I would also put out there that Dashicons is mainly a WordPress admin font. Not that it mustn’t ever be used elsewhere, but doing so would be like using the old admin icon sprite for your theme.

      I’m not entirely clear on what the benefits are of mixing up how Genericons are produced at the moment. I consider it more like an image sprite, than an icon-font, not something that deserves much mental overhead. While I do occasionally add icons to Genericons, it’s very rare that I make changes to existing icons (only happens when Facebook or Instagram redesigns, that sort of thing), so there’s no reason a theme couldn’t live a perfectly good life with an “older” version of Genericons.

      If the reason is an expected swath of new contributions to Genericons for Twenty Fourteen or other themes, I think it’s important to clarify that making icon fonts isn’t quite as mysterious a process as it might seem to an outsider, and I would love nothing more than teach a man to fish — create educational videos, instructions, howtos, step by steps for creating new icon fonts and even mixing existing ones up. There’s no reason we can’t have several different icon fonts living on their own. I think there’s a very valid argument to be made that Genericons contains, and probably more so will in the future, a whole bunch of icons that are less useful for bundling. Creating a completely new icon font, using the Genericons source files and perhaps a couple of the icons as a base, is no more than an afternoons worth of work.

      • George Stephanis 6:42 am on July 29, 2013 Permalink | Log in to Reply

        The comment about it being fine that themes use an older version is absolutely true. It’s also true that it’s ‘fine’ if themes bundle their own versions of jQuery — in a vaccuum, it will work fine.

        The issue crops up when a plugin also wants to use jQuery, or — in this case — Genericons. The plugin may need a newer version, and if the theme has already registered/enqueued its own version of Genericons, the result is one of two things:

        • Only one version of Genericons is echoed out. If it happens to be the older version that `wins`, the other source is stuck using a version that may not have an icon it’s expecting.
        • Two versions of Genericons get output on the page (if they’re enqueued with different slugs). One overrides the other, as @font-face kinda tends to do. If it happens to be the older version that `wins`, the other source is stuck using a version that may not have an icon it’s expecting.

        By providing an up to date canonical version in core, plugins and themes can know what is available and tell what to expect.

        I see the arguments for having a single version of Genericons provided in core as being pretty much identical to those for bundling jQuery in core.

        • Joen Asmussen 4:48 pm on July 29, 2013 Permalink | Log in to Reply

          To be clear, I have no ideological opposition to Genericons being bundled with core, not at all. I just don’t see the benefits.

          I don’t think the comparison to the jQuery bundling makes sense in this case. Being an icon font, like I briefly mentioned, a more apt comparison would be to a graphics sprite like this one. For me it would make the most sense for an icon font to be bundled with the theme that uses it.

          I ackowledge that a conflict would arise if you used a theme that relied upon Genericons, *and* a plugin that also bundled Genericons but enqueued it in an improper way. I suppose bundling Genericons with core would provide one canonical location for Genericons, but if you wanted to use a newer version of Genericons you’d still have to bundle the font — a use-case I would consider more likely than you wanting to use a newer version of jQuery.

          The downside would be more stuff in WordPress to maintain (effectively just shuffling the convenience issue), to solve an edgecase that I’m not sure is anything but an intellectual problem at this point.

          Icon fonts, when you have the process down, are pretty easy to create, and will only get easier as time goes by what with all the “convert your SVGs to an icon font in one click” services that are popping up these days. As much as I’m flattered by a side-project of mine being core canonized, I’m worried that we’re solving a non-issue and adding bloat in the process. I predict one year from now, creating a unique icon font for your theme or plugin is as commonplace as creating image sprites.

          • George Stephanis 4:54 pm on July 29, 2013 Permalink | Log in to Reply

            Asset sprites are normally ad-hoc made unique to the themes needs.

            Distributed icon font packages like Genericons are third-party libraries that get included in themes without trimming, modification, or creating of a customized version.

            That’s why it’s more akin to jQuery. Especially as each provider may have their own dependency on specific icons, that may not appear if an older version `wins`.

            Creating a unique icon font is, yes, not terribly hard. Tools like IcoMoon make it pretty simple — but many folks choose not to, and I think we should support that.

            I’ve already seen issues through my work with Jetpack where problems are cropping up with multiple versions of Genericons being used, and a bad one wins out.

      • Nick Halsey 10:07 am on July 29, 2013 Permalink | Log in to Reply

        I agree with Joen, the fonts serve different purposes. I was actually trying something with both of them recently because I needed a pretty broad set of icons (creating a multi-level menu with icons by each item). But it turned out that only 3 of the 20 I actually used were from Dashicons, and none of them were used for the visual meaning they’re used for in core. Dashicons are really admin-centric and I don’t see much benefit to the combined set over just Genericons, especially as new icons are added.

        So I’d say keep them separate but bundle them both with core; people can load both if needed. That also gives more of a reason to address a possible improvement to how we enqueue fonts (both icon fonts and others). The majority of the time, I think Genericons will be used on the front-end, and then it’s something bigger, basically “the WordPress (front-end) icon font.” More people will use Genericons in themes and especially plugins as a result. It could become too much if Genericons and Dashicons were both in the font (merging the duplicates), even if it were technically feasible, the WordPress icon font would feel too much like the WP admin, and thus carry a different connotation.

        The updates thing is less of an issue if release cycles are getting shorter, and at least everyone would be using the same version (by WordPress release).

        I’ll just point out that the sooner they’re bundled with core, the less time plugins need to continue to bundle them. For example, I would be able to cut my plugin’s package size in half, and would be fine with removing the Genericons option (it’s that or old-fashioned icons) for users of older versions. So sooner is better.

      • Mel Choyce 4:23 pm on July 29, 2013 Permalink | Log in to Reply

        +1. Dashicons was definitely designed with admin use in mind, and as joen mentioned, the pixel grid difference makes them totally incompatible.

        What are the drawbacks to bundling them both into core?

        • George Stephanis 4:37 pm on July 29, 2013 Permalink | Log in to Reply

          I think Lance was just thinking more convenience. Honestly, I’m fine with bundling them both seperately, and prefer that — less things to change on updates if we can just pull them directly.

          I think Dashicons in 3.8 with MP6, and Genericons in 3.7 is a good plan — I’m just not 100% sure on the file/folder structure we want for them. Or if we really need to base64encode the one font, as is currently done in the implementation.

        • Ipstenu (Mika E.) 8:24 pm on July 29, 2013 Permalink | Log in to Reply

          My thought for bundling was that some icons (twitter, shopping cart, etc) are in both.

          Though that begs the question… why ARE they in Dashicons?

          • Mel Choyce 10:32 pm on July 29, 2013 Permalink | Log in to Reply

            We’ve been gradually adding in new icons to Dashicons for plugin and theme authors to use.

            • Ipstenu (Mika E.) 2:57 am on July 30, 2013 Permalink

              So if we were to include Genericons, then you wouldn’t need to and you’d have less work? Or are you including them to be sidebar icons (which would make sense for shopping carts, I guess… Less twitter, but I may be missing something obvious!)

            • Mel Choyce 2:42 pm on July 30, 2013 Permalink

              To be used as sidebar icons, or used generally within wp-admin.

    • George Stephanis 4:47 pm on July 29, 2013 Permalink | Log in to Reply

      In addition to the 17 themes on .org and the plugins that bundle it, there are 23 free themes on wpcom, and 9 paid themes, that each bundle genericons.

      • Joen Asmussen 4:51 pm on July 29, 2013 Permalink | Log in to Reply

        But each theme will only use the icons that are embedded in the bundled genericons font. So any “missing icons” issue will only occur if a frontend-facing plugin bundles genericons in an improper way.

        • George Stephanis 4:56 pm on July 29, 2013 Permalink | Log in to Reply

          No. Even in a proper way.

          When two things want genericons, one version will always win out over the other. Regardless of whether they’re both trying to enqueue them with the same name or not.

          At that point, it’s a fifty-fifty chance if the version that wins is a newer version.

          • Joen Asmussen 4:58 pm on July 29, 2013 Permalink | Log in to Reply

            Wouldn’t the larger version win when using wp_enqueue_style? That’s what I was referring to by “proper way”.

            • George Stephanis 5:02 pm on July 29, 2013 Permalink

              Nope, just the one that was registered or enqueued first. See http://core.trac.wordpress.org/browser/trunk/wp-includes/class.wp-dependencies.php#L177

            • Joen Asmussen 5:06 pm on July 29, 2013 Permalink

              Gosh, well that sucks.

              I still don’t think the solution to such conflicts is bundling Genericons with core, though, I’d much rather we find a different solution such as a CDN or something (perhaps We Love Icon Fonts). I’m concerned about submitting to Google Fonts, but would frankly prefer that solution as well.

            • Joen Asmussen 5:18 pm on July 29, 2013 Permalink

              Wouldn’t the conflict just be reversed, though, if we did bundle it and a new Genericons came out in between WP releases, used by a theme? While my pace of adding icons to Genericons has certainly slowed, I don’t think it’s slowed more than at least a release every month or so.

            • Ipstenu (Mika E.) 5:34 pm on July 29, 2013 Permalink

              Not a CDN, please. Core shouldn’t RELY on a CDN, especially since it makes it unusable for anyone behind firewalls or on a private network. Bad UX.

            • George Stephanis 5:36 pm on July 29, 2013 Permalink

              CDNs as a dependency for core are untenable, as they may be places where the CDN is unavailable (Google in China, or if a site is being run on a sequestered intranet).

              If Genericons does get an update before core does, it’s the same situation as if jQuery gets an update before core releases. We’re still providing a known baseline version, and if someone really needs to bump to a newer version, they can do something like …

              {{{
              add_action( ‘init’, ‘fresher_genericons’ );
              function fresher_genericons() {
              global $wp_styles;

              $my_ver = ’2.11.2′;
              if ( version_compare( $wp_styles->registered['genericons']->ver, $my_ver, ‘registered['genericons']->src = theme_url( ‘fonts/genericons.css’ );
              $wp_styles->registered['genericons']->ver = $my_ver;
              }

              }
              }}}

              Which is what I meant above when I mentioned that there could be a plugin that ensures the freshest version is available, above and beyond what is bundled in the latest wp release.

            • George Stephanis 5:42 pm on July 29, 2013 Permalink

              Okay, easier to just link the code:

              https://gist.github.com/georgestephanis/6106105

      • Chip Bennett 11:33 pm on July 29, 2013 Permalink | Log in to Reply

        I expect that more Themes will be bundling Genericons soon. I know of at least one (mine), that has Genericons in the development version.

        So, while I have no opinion regarding merging of the iconsets, I huge +1 from me for including Genericons in core. Having them in core would facilitate their usage, and facilitating their usage would help with standardization of an increasingly important front-end UI element.

    • George Stephanis 4:49 pm on July 29, 2013 Permalink | Log in to Reply

      And for anyone that’s not caught it yet, currently in trunk, we have Genericons in two places, as it’s bundled both with twentythirteen and twentyfourteen.

    • Empireoflight 8:48 pm on July 29, 2013 Permalink | Log in to Reply

      Thanks for opening up this discussion, it’s giving me a reason for really thinking about why Dashicons exist. Re: Dashicons, they were made primarily for the admin menu. Any use outside of that context is secondary; we do use them for the visual editor, post formats, and a few other places., but first and foremost they are proportioned and styled to fit perfectly over there.
      It would be great if the core dashicons was loaded from a font server, and plugin authors could upload their icons as addons that would be loaded on top of the core set. Unfortunately, I’m not knowledgeable in the tech needed to deliver something like this (if it’s even possible), not sure if icomoon or something could do it, but would be interested in testing it out if anyone has suggestions.

    • Chris Reynolds 4:39 am on August 4, 2013 Permalink | Log in to Reply

      +1 for bundling Genericons in core. I don’t see any real reason not to — there’s plenty of other javascript libraries being bundled in core now that not everyone needs — and, as you’ve pointed out — there’s an immediate use for it in the bundled theme(s).

      Re: Dashicons vs. Genericons and merging the two — To me, as a plugin and theme developer, more options is better. I understand the style differences and the size/grid differences being an issue but…uh…in theory at least, that could be solved by just picking one stylistic choice and going with it; I don’t see that as being a huge insurmountable hurdle.

  • Matt Mullenweg 2:03 pm on July 4, 2013 Permalink
    Tags:   

    MP6 feedback: just to start a new thread people can leave comments on, drop one here if you have any MP6 bugs or feedback you’d like to share.

     

  • Matt Thomas 9:34 pm on June 7, 2013 Permalink
    Tags: , , ,   

    Hello all! We’re here with the final regularly scheduled weekly installment of MP6, version 1.5. As we’re beginning to wrap up our visual redesign, we’ll continue to release updates to MP6 when necessary, but will no longer be announcing them every Friday. We’ll miss you guys. :)

    New this week:

    • We’ve begun merging colors-mp6.css and wp-admin.css. This is just about done, but we need to do a bit more testing before we flip the switch and use the new CSS files for everyone. When we’re done, this will allow for much cleaner future potential patches/merges into Core.
    • Load Open Sans on the login screen.
    • RTL: Fix comment bubble tail and positions, view switch margins.

    This week includes contributions from Michael Erlewine (mitcho), Till Krüss, and myself.

    You can continue leaving comments here with feedback for us. And we’ll issue new posts when there’s something big new for you guys to take a look at (we’re already noodling on some larger core design issues we’re looking forward to sharing with you). As always, thanks for all your helpful feedback in advance.

     

    • Ulrich 10:13 pm on June 7, 2013 Permalink | Log in to Reply

      I am still having problems with the mobile menu. I am not sure what is causing it.
      Here is a screenshot
      http://pix.am/CfdX.png

      • codydh 1:05 pm on June 8, 2013 Permalink | Log in to Reply

        I am seeing this too, though I’m on WP 3.5.1, and I’m wondering if that’s the cause.

      • Matt Thomas 8:58 pm on June 12, 2013 Permalink | Log in to Reply

        I was able to reproduce this, but only on a 3.5 installation and not very consistently. Since it doesn’t affect 3.6 that I can tell, we probably won’t spend too much time debugging this, but let me know if you get any insight into what’s causing it, and we’ll take a look.

    • harribellthomas 11:16 pm on June 7, 2013 Permalink | Log in to Reply

      I am having a problem where the burger doesn’t appear on custom pages.
      Here is a screenshot:
      http://pix.am/E433.jpg
      Swiping still reveals the menu, as you can see, and the burger is visible on all generic WordPress pages, but not custom ones.
      Thanks for the plugin by the way, it has revolutionised the way I use WordPress!

      • harribt 11:37 am on June 16, 2013 Permalink | Log in to Reply

        I’ve solved this; I wasn’t using the div class ‘wrap’ for my settings page. I simply added this and all works as is supposed to.

    • codel1417 4:19 am on June 8, 2013 Permalink | Log in to Reply

      unlock horizontal scroll for non optimized that go off screen

    • Lea Cohen 7:21 am on June 9, 2013 Permalink | Log in to Reply

      Oh, mixed feelings: I’m very happy for you guys that the plugin has reached this maturity! But I’ll miss the Friday announcements :)

      This is a good opportunity to thank you for all the RTL care! I really appreciate it, and especially the fact that you listened to my feedback.

      However, it seems I can’t leave without adding some issues to your list :) , so here are this week’s additions:

      1) In the comment bubble tail and positions that you fixed this week, I forgot to mention that the hover doesn’t show the sorting arrow…

      2) The submit button on some screens is still left aligned. For example, the export.php acreen, all the options screens (options-general.php, options-media.php, etc.), the edit-tags.php screen, and maybe there are more – I’m not sure I went through all the screens.
      It’s funny, because in some screens, someone *did* remember to right-float it , for example: theme-editor.php, and plugin-editor.php (although it seems to me that text-align:right would have been enough. Why float it alt all?)

      Thanks again, and good luck !

      • Matt Thomas 9:06 pm on June 12, 2013 Permalink | Log in to Reply

        Thanks, Lea (and thanks for all the feedback on the RTL component over the last few weeks). I’ve added these issues to our to-do list, and should have a fix for them in trunk soon (when we do, I’ll bump the version number so you get an update notification).

    • webdevmattcrom 7:19 am on June 11, 2013 Permalink | Log in to Reply

      I seem to have quite a few issues with TinyMCE editory with MP6. A tiny issue I might have a fix for. The webfont icons don’t align well in the buttons. This is how I tweaked it to get them to align well:

      .wp_themeSkin span.mceIcon, .wp_themeSkin img.mceIcon {
      KEEP THIS–>display: block;
      REMOVE THIS –>width: 20px;
      KEEP THIS–>height: 20px;
      ADD THIS –>position: relative;
      ADD THIS–>bottom: 5px;
      }

      The problem then is buttons that still actually use images rather than the webfonts. One fix creates other problems, but I think this is a step closer to doing it well.

      Love this UI, such a HUGE improvement. Thank you!

    • jbrunet 1:15 pm on June 12, 2013 Permalink | Log in to Reply

      when you have a select multiple, just shows one line. In colors-mp6.css
      #wpbody select {
      line-height: 24px;
      height: 24px;
      border-color: #bbb;
      }
      The height property is not needed I think.

    • Linda Lee 9:12 pm on June 16, 2013 Permalink | Log in to Reply

      Matt I have been asking around but no one has given me a solid answer. Is the new dashboard going to be part of the new WP 3.6 release?

    • Ivan D. 5:17 pm on June 17, 2013 Permalink | Log in to Reply

      Hi,
      I’m new here and I like the MP6 ergonomy !
      But i think we can do more. I’ve made a little plugin to do little improvements.
      Look here the result : http://rcrea.fr/img-host/mp6-perso-17-06-13.jpg
      If you want the little plugin or more info just ask.
      I don’t know how i can help on this, if it’s not the right way tell me ;)

    • mrwweb 6:06 pm on June 17, 2013 Permalink | Log in to Reply

      I am still seeing this gross Firefox font-rendering issue that I raised way back in this comment. I went and checked and it does affect the dashboard on WordPress.com as of the release of the new interface there today.

      I’ve established that it doesn’t seem to be tied to any add-ons or hardware accelleration and can be fixed by either not using Open Sans or getting rid of fixed positioning. Beyond that, I haven’t figured out how to fix it.

      • Matt Thomas 9:52 pm on June 17, 2013 Permalink | Log in to Reply

        We’ve had a hard time reproducing it reliably; it seems to be some specific combinations of Firefox, OS, and hardware. We’ve still got this one on our to-do list, though.

        • mrwweb 8:22 pm on July 2, 2013 Permalink | Log in to Reply

          Glad to hear you’re still working on it. I came back at it today to see if I could find some other info that might help with a fix. In the past, I’ve noticed that removing fixed positioning resolves the issue, but now I’ve found another “solution:” on colors-mp6.css on line 1170, there’s the following:

          #adminmenuback, #adminmenuwrap {
          background-color: #222222;
          }

          If you remove #adminmenuwrap from the selector, the rendering issue ceases.

          You can similarly fix the admin-bar rendering by remove the background of #wpadminbar.

          So that seems to suggest the problem is a weird combination of fixed positioning and background color. That led to a new round of Googling that turned up empty like the last run, but this feels like a bit of a breakthrough.

          Hopefully this is useful.

    • Knut Sparhell 11:12 pm on June 20, 2013 Permalink | Log in to Reply

      I have TinyMCE Advanced on some sites. With MP6 some buttons become invisible.

    • FAT Media 10:08 pm on June 24, 2013 Permalink | Log in to Reply

      I’ve noticed that MP6 is loading admin styles on the front end needlessly. A quick check to see if the user is logged in should prevent this. I opened an issue on the plugin support forum over here: http://wordpress.org/support/topic/prevent-admin-menu-styles-from-loading-on-the-front-end?replies=1

      Here’s a direct link to the code that needs updated as well: https://gist.github.com/fatmedia/5853892

    • WebsiteDoctor 11:23 am on June 26, 2013 Permalink | Log in to Reply

      I think the new UI looks great. There are some problems with accessibility, in particular when using the Zoom feature on MacOSX and some other systems frequently used by those with visual impairment (partially sighted). This is a regression from the existing WP UI where the zoom works correctly.

      Where should I report this?

      • Matt Thomas 3:37 pm on June 26, 2013 Permalink | Log in to Reply

        Thanks — you can let us know right here, and we’ll add the issue to our to-do list. It’ll help if you can include screenshots of the problems you’re seeing. We’ve tested the core admin with browser zoom enabled quite a bit (see: http://cl.ly/image/113d231d0s1o), so a list of any plugins and other modifications you might have made would be helpful too.

    • Aaron D. Campbell 6:56 pm on July 1, 2013 Permalink | Log in to Reply

      I tried MP6 on my S3 and while I’ve not tested everything, here are some of the issues I’ve found. Let me know if there is a better place for bug reports.
      1) While I know the Settings option is at the bottom of the nav, I can’t actually get to it. This is scrolled all the way to the bottom: http://cl.ly/image/2v2H0F1V1S1d
      2) If there are added buttons with the Media button, it overlaps the editor buttons. This happens in both text and visual mode, and when it happens you can’t change between text and visual editors – http://cl.ly/image/2Y063X1X3b2P and http://cl.ly/image/0Y0k342c0r0f
      3) On the post list page, checkboxes are clipped – http://cl.ly/image/3D3P2M012L1f

    • gmcosta 8:33 pm on July 1, 2013 Permalink | Log in to Reply

      Hey guys, congratulations for the job you’re making with WP.
      I would like to suggest something. How about you include in WP Core, this feature:

      “When you search a plugin (under Plugins > Add New), wordpress auto check the version installed and display only compatible plugins with that version.”

      After searching for two hours for plugins that I could use on my project, 95% of them are not recommended and at least, half, doesn’t work at all.

      Please, let me know what you guys think about this.

      Kind Regards,
      Gmcosta

  • Matt Thomas 10:45 pm on May 31, 2013 Permalink
    Tags: , , ,   

    Happy Friday, everybody. Here’s what’s new in MP6 this week. It was a short week for most of us, so we’ll keep the post similarly short.

    • Mobile: You can swipe right and left to open and close the menubar now, in addition to tapping the “hamburger” button in the top left.
    • Mobile: Implemented a fix for dropdowns not displaying full width; props to deanjrobinson for his advice here.
    • Mobile: Better treatment for post revisions.
    • Mobile: Fixed multisite theme list.
    • Mobile: Align theme/plugin list checkboxes.
    • Mobile: Align theme/plugin list titles.
    • Mobile: Fixed frontend admin-bar.
    • Renamed toolbar.css to admin-bar.css for uniformity with core.
    • Added a changelog link to readme.txt.
    • Changed the minimum required WP version to 3.5, so 3.5 users will get update notifications for MP6.

    This week’s iteration includes work by Joen Asmussen, Till Krüss, and myself.

    If you missed it yesterday, be sure to check out our roundup of potential implementation recommendations for plugin authors who need to add a custom icon to the top-level menu. We appreciate any feedback you’ve got for us, so we can codify our recommendations for developers who’d like to add MP6-style icons to their plugins.

    We’ll be back next Monday with office hours in #wordpress-ui on IRC, for anyone who would like to discuss their feedback with us. You’ll find us there 1800 UTC on June 3.

     

    • Matt Van Andel 1:04 am on June 1, 2013 Permalink | Log in to Reply

      Since Post Formats UI has been removed from Core, it might be prudent to explore some alternatives in MP6. I know everybody has their own ideas about this, but I always felt that all WordPress’s post formats needed was a nice little UI refresh (as opposed to the comprehensive overhaul that Post Formats UI would have been).

      That said, this is what I propose… or at least something like it…
      http://www.mattvanandel.com/wp-content/uploads/2013/05/betterformats-screencap.jpg

      I’ve just submitted a pluginized version of this (called “Better Formats”) to WordPress.org so that it can be tested more broadly; the approach I’ve taken to achieve this might be a little out of scope for MP6 (there’s some JavaScript chicanery involved), but I think the direction this takes is worth considering. Lord knows it’s made my clients happier when we do trainings for new websites.

      Instead of making any dramatic changes, this simply replaces the ugly, unhelpful radio-button Format list with something prettier and javascript-based. The aesthetic similarity to MP6 is just a happy little accident! :-)

    • eburnett 3:30 am on June 1, 2013 Permalink | Log in to Reply

      What a bogus move. Thank you for putting something in, contemplating reloading last update. Plugin should have come first – at the least, I can’t find any reference to where to go to get it.

    • manyu.singhal 10:35 am on June 1, 2013 Permalink | Log in to Reply

      Any changes planned for the layout of the custom post types list? Like an optional grid layout?

      • Matt Thomas 2:02 pm on June 1, 2013 Permalink | Log in to Reply

        There are definitely still some things we can and should try with the styling of post formats, though we’ll probably not prioritize that for now since it won’t be part of core in 3.6.

    • Amy Hendrix (sabreuse) 11:34 am on June 1, 2013 Permalink | Log in to Reply

      Mobile: You can swipe right and left to open and close the menubar now, in addition to tapping the “hamburger” button in the top left.

      Sweet!

    • jlambe 9:38 am on June 3, 2013 Permalink | Log in to Reply

      Like the idea from Matt Van Andel. But then, the post format UI get stretch to the bottom. I don’t know if the core team intend to allow to build custom post format for developers. If it’s the case, then i think the concept from Matt Van Andel won’t work. Maybe build a drop down list () with the post formats. We can certainly add a short description of what is a post format above the drop down list. Plus with the use of javascript, we can still keep the idea of Matt Van Andel. Only the post format will appear on a click event or some sort.

      • Matt Van Andel 5:47 pm on June 3, 2013 Permalink | Log in to Reply

        Room could be freed up by shrinking the text and icons a pinch.

        The vertical space is definitely a consideration, but I erred on the side of usability in this case… at least at the beginning. Post Formats are ambiguous enough that most users “just don’t get it” – so this was attempt to add some in-line help in the form of mnemonics (icons) and a bit of help text.

        If you want to experiment with it a bit, it just went live on WordPress.org: http://wordpress.org/plugins/better-formats/

        I plan on adding some settings in the next version for hiding the verbose descriptions… which will further shrink that sidebar once a user has become more familiar with it.

    • Lea Cohen 12:38 pm on June 3, 2013 Permalink | Log in to Reply

      I didn’t get a chance to say this last week so I’ll say it now – thank you very much for the RTL fixes!

      And thanks for letting 3.5 users get update notifications for MP6. That’s a big help!

      And lastly, I found 2 more issues with RTL (sorry…):

      a) In the dashboard, in the Right Now box, the font-size grew, and now there isn’t enough space between the Discussion column and the Posts column in Hebrew:
      .
      This is what it looked like without MP6:

      b) In the posts screen, the title of the column between the Tag column and the Date column, has an icon. That icon isn’t positioned correctly in RTL, and neither is its hover position.
      Also, the image in the content of that column, the shoutout isn’t flipped for RTL
      This is what it looks like in RTL:

      And this is what it should look like:

      • Matt Thomas 7:20 pm on June 3, 2013 Permalink | Log in to Reply

        No need for apology Lea, we appreciate you helping us out by reporting them! I’ll add these to our RTL list.

        • Lea Cohen 5:21 am on June 4, 2013 Permalink | Log in to Reply

          Thanks Matt.

          And another small question – is the Press This window on the RTL list? Because I don’t see a fix to it yet…

          Thanks again!

    • Terry Sutton 2:39 pm on June 4, 2013 Permalink | Log in to Reply

      Hey all — the size and weight on the Posts/Pages lists feel a bit too much to me. The 14px bold feels a little too chunky. Here’s the current with a 13px 600 alternative: http://cl.ly/image/2i0Q1k0L2U3P http://cl.ly/image/0c2I470L2c2L

      Just that little bit less feels much more comfortable to me.

      • Matt Thomas 3:45 pm on June 4, 2013 Permalink | Log in to Reply

        Thanks Terry — it looks like you might have Open Sans installed locally, which will cause some text to display as bold instead of semi-bold (the bold/600 weight isn’t included in MP6, but older styles still use font-weight: bold instead of font-weight: 500). As we get all of those declarations switched over this should take care of itself (we like 14px for the titles in tables for the extra contrast, but will consider 13px as an alternative).

  • Matt Thomas 4:34 pm on May 30, 2013 Permalink
    Tags: , , ,   

    The MP6 team has been working on recommendations for plugin authors who add a top-level icon to the dashboard’s main menu. We’ve investigated a number of options, all of which have their own advantages and disadvantages. In this post, I’d like to share the options we’ve considered in the hopes of generating a larger discussion about what would be the best possible solution for WordPress and for plugin authors. An example of the two SVG methods is available at http://codepen.io/joen/pen/otdkK.

    Method A: CSS-colored SVG icon

    This method uses SVG (vector, infinitely scaleable) icons that are embedded inline in the HTML. Using this method, the icon is able to inherit the color of the admin and change depending on customizations chosen by the user (a high-contrast admin theme for vision-impaired users, for example).

    Pros
    • Clean, retina, and infinitely zoomable.
    • Only a single icon file needs to be created, no need for 2x versions or separate hover/active states.
    • With colors being controlled by the admin CSS, they will always match the core set of icons, as well as any further customizations made by the user.
    Cons
    • SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
    • For the CSS coloring to work, the SVG markup has to be cleaned up either manually or via an optimizer, adding some overhead to the creation.
    • The actual SVG markup has to be inline in the HTML. Hard to cache, requires core changes, potential security concerns.

    Method B: CSS background-image SVG icon

    This method also uses SVG icons for infinite scalability, but is applied via the CSS background-image property. Using this method, colors must be selected by the plugin author, and a separate file must be created for each color.

    Pros
    • Clean, retina, and infinitely zoomable.
    • No security concerns (that we are aware of) with SVGs when used as background images.
    • No WordPress core changes are necessary.
    • SVG files can be used directly from Illustrator, no editing of the SVG necessary.
    Cons
    • SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
    • Multiple files must be created for normal, hover, and active states.
    • With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).

    Method C: PNG icons (the “no-build option”)

    Alternatively, plugin authors could specify new MP6-style icons in the PNG format, using the same technique they use currently.

    Pros
    • Universal browser support.
    • No WordPress core changes are necessary.
    • No security concerns with PNG.
    Cons
    • Multiple files must be created for normal, hover, and active states.
    • Two sets of icons must be created in both 1x and 2x versions for retina displays (and more, when higher-than-2x displays appear).
    • With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).

    SVG Browser Support

    Internet Explorer 8 and below have no native support for SVG files. Icons in the SVG format will not display in IE8 and below as a result.

    • Modernizr’s .no-svg class could be used to specify PNG fallbacks.
    • A number of polyfills attempt to add SVG support to these browsers (we haven’t tried them).
    • We could adopt a Google Apps-style browser support policy for MP6, supporting the current and previous major release of each browser. This would drop IE8, but make room for the many new clients we’re supporting: mobile versions of Chrome, Safari, Firefox, and IE; and the Android and Blackberry browsers. We don’t know what IE8 usage is like among WP users, though.

    Conclusions

    Method A, inline SVG, is the best option from the designer’s viewpoint — plugin authors include a single icon and all styling is provided automatically. MP6 makes dashboard customizations like a high-contrast admin theme for visually impaired users much simpler than the current admin design — and method A makes styling plugin icons as easy as the core set of dashicons. However, the technical hurdles and possible security concerns could be significant and we need more input on whether this method is practical.

    Method B would be the next-best option — it would provide the primary benefit of using SVG icons (infinite scalability) without requiring changes to core. It would be significantly more difficult (though not impossible) for plugin icons to reflect user customizations, but would still require less manual work than creating separate sets of 1x and 2x PNG (method C).

    We’re interested in any thoughts that you may have, especially if you’ve worked with SVG before and can offer insight on how we could implement method A successfully. If you know of any reason why any of these absolutely won’t work, feel free to rain on our parade. :)

     

    • webdevmattcrom 5:21 pm on May 30, 2013 Permalink | Log in to Reply

      Do SVG and drop IE8 support. There’s no reason anyone wanting to create websites (meaning have access to the backend) should ever use IE8 or below. This is a valid concern for front-end development, but if ANYONE can push the envelope on modern browser adoption, the WordPress UI should be able to.

      • Matt Van Andel 6:10 pm on May 30, 2013 Permalink | Log in to Reply

        Have you considered a custom symbol/logo/icon font? You get all the benefits of SVG, plus CSS compatibility, but none of the drawbacks you mentioned. Converting an SVG to a symbol font is fast, easy, and very straightforward.

        Some preliminary reading:
        http://alistapart.com/article/the-era-of-symbol-fonts

        • Matt Thomas 6:27 pm on May 30, 2013 Permalink | Log in to Reply

          We’re actually using just this approach for the core icons in MP6 with an icon font called Dashicons. We’re including in Dashicons a number of generic icons that plugin authors can use if they don’t want or don’t have the resources to create a custom icon.

          The methods outlined above are for plugin authors who need their own, custom icons for plugins that add top-level menus to the dashboard. It would be possible for plugin authors to create their own fonts, but as multiple versions of the font are necessary, it would be a lot of overhead for each plugin to load its own fonts for a single icon each.

          • Native Imaging 2:45 am on July 20, 2013 Permalink | Log in to Reply

            Matt, thank your for this information. I was curious what your thoughts were on using Modernizr.js for old IE fallbacks. I’ve had awesome results for almost any kind of IE problem using Modernizr.js as a fall back.

            • Native Imaging 2:50 am on July 20, 2013 Permalink

              Also, I’ve been a bit frustrated with Font Glyphs. the idea is great & there are a lot of providers and font glyph libraries, but the usual case is when I choose one to use, and then the first icon i look for does not exist. Currently, I have 5 different font glyphs that have the icons i need and its seriously overkill. Why can’t we just use SVG and possibly an SVG sprite compiler that uses an internal grid system. Although that may sound complex, it would save a lot of http requests and have true ultimate flexibility. I’ve found the performance of SVG & CSS3 using Modernizr.js as a fall back has far exceeded performance of any other methods.

    • Ronnie Burt 8:23 pm on May 30, 2013 Permalink | Log in to Reply

      If it helps with your IE stats – for the month of May on Edublogs, 12% of our users use IE 8 in the dashboard – and there’s even a decent number on IE 7 and IE 6. That’s because they’re blogging from government or school computers, often old, and often without rights to update or add browsers on their own :( Safe to guess that the Edublogs community has higher use of IE than the WP community at large.

      That being said, there’s been a sharp decrease in IE 8 (and IE in general) over the past year for us too, so maybe leaving the rest behind is a decent option…

    • Shea Bunge 10:35 pm on May 30, 2013 Permalink | Log in to Reply

      I implemented an MP6 icon in my plugin quite a while back. It uses the same method as the Jetpack menu icon, with base 64 SVGs embedded in CSS background images. http://wordpress.org/plugins/code-snippets

    • JakePT 12:53 am on May 31, 2013 Permalink | Log in to Reply

      With my plugins I just used a Dashicon, lacking the resources as I do to create my own. I just added some CSS to set the content of the :before psuedo element to the character I wanted and it works great. As long as this approach is still an option I’m happy. Even better if Dashicons continues expanding with more icons that plugins could use as their icons.

      • FAT Media 8:49 am on May 31, 2013 Permalink | Log in to Reply

        I think this is the best solution. Expand the development of the Dashicons font encourage plugin authors to use them rather than trying to roll their own iconography. The custom icons rarely match up with the rest of the WordPress UI and if Dashicons were extensive enough and easy to contribute to, I think it would satisfy the needs of most users and developers.

        Also, maybe it would be possible to regenerate Dashicons on the fly in a manor similar to how the http://icomoon.io/ app works. Just a thought…

      • Matt Thomas 7:54 pm on May 31, 2013 Permalink | Log in to Reply

        Thanks, Jake — this will definitely be a part of our solution. We’ll include instructions on how to use the dashicons that are intended for plugin authors, and I imagine most plugin developers who don’t use their own custom icon or logo will go that route.

        • JonMasterson 12:57 pm on June 6, 2013 Permalink | Log in to Reply

          I love this plugin, and 100% agree with its vision. My only point of concern is the Dashicons. Whereas I do like them, there are not enough options for plugin/theme developers. Choosing a more robust icon solution (such as the free FontAwesome icons set http://fortawesome.github.io/Font-Awesome/cheatsheet/) would allow developers to easily hook into a large set of icons that match in style, and create menu items with a couple lines of css.

          I am forking this plugin at the moment to utilize FontAwesome icons instead of Dashicons, and it is going rather well. I am easily able to locate icons to represent my custom post types. I can even add commonly used custom post types (such as events, jobs, directory, deals, etc), so that common CPTs could be supported out-of-the-box.

          I realize the amount of time and energy that goes into icon creation, and do not think the more WP-specific icons should be abandoned. Perhaps adding them to the FontAwesome stack might be a better solution? Submitting new icons is really easy, and the FontAwesome community is already in place. It would quickly give plugin/theme developers the icon options they’ve wanted for years…

          • Matt Thomas 1:39 pm on June 6, 2013 Permalink | Log in to Reply

            Hi Jon — that’s a good idea, and plugin authors can use this technique today if they’d like, it doesn’t have to be bundled with MP6. Our reasoning for not using FontAwesome in the first place was our desire for a WordPress-specific icon set that was created and owned by the WordPress community. Second, we didn’t want to load a huge collection of generic icons when most users would only need the handful specific to WordPress.

            But that doesn’t mean Plugin authors are limited in what they can use. You can queue up FontAwesome with your plugin (their site says it’s GPL compatible, but I’m not familiar with the license they’re using) if you’d like to make use of its icons, or even create a custom icon font with your plugin’s logo and unique icons.

            • JonMasterson 2:14 pm on June 6, 2013 Permalink

              Hi Matt — Yes, I could load up any icons, but it might be better to have one bundled set that matches in style. This single collection (FontAwesome or not) would be loaded as a font stack, so no great performance losses there — only the benefit of having multiple icons bundled in one place. If mp6 became a part of core, a robust icon solution would be a huge asset for developers…

              If you prefer to enhance the Dashicons font set or leverage the WP community to expand the development (a la FAT above), that would be great! However, it might take some time to pull that together. In terms of quickly giving this plugin a variety of icons, and making it easy for developers, FontAwesome might be a better choice (it’s here already, and it’s easy to submit new icons).

              I’ll fork mp6 with FontAwesome 3.2 (due in 6 days) just for poops and laughs, and will set it up on GitHub in a week for anyone who’s interested. Thanks for listening to my blathering!

          • Ipstenu (Mika Epstein) 3:10 pm on June 6, 2013 Permalink | Log in to Reply

            There’s a Font-Awesome plugin – http://wordpress.org/plugins/font-awesome/

            Though it doesn’t do replacements for menus. That’d be an interesting plugin!

            • JonMasterson 3:45 pm on June 6, 2013 Permalink

              Perhaps an “mp6 icons” plugin, bundled with FontAwesome (or any icon font stack for that matter), that could hook into mp6 — basically a bit of replacement css for the icon elements, and a big ol’ icon font stack.

              Still think it would make sense to bundle mp6 with a nice stack of icons, but like this idea, too… leaves potential for many different icon font plugin options… hmmm

            • JonMasterson 2:51 pm on June 23, 2013 Permalink

              Just got around to putting this together… Once again, thank you for your work on this plugin… it’s great! I created a couple resources to help folks quickly add Font Awesome to MP6 (without modifying MP6). I will build this into a plugin when I have a moment. For right now, this should help a few folks… https://github.com/JonMasterson/Font-Awesome-for-MP6.

              I believe you are right in that this should be an add-on rather than one bundled set. Thanks!

  • Matt Thomas 12:29 am on May 25, 2013 Permalink
    Tags:   

    Howdy, UI group. This Friday brings you version 1.3 of MP6, the WordPress birthday weekend edition. This iteration is largely focused on responsive and RTL improvements, as well as bug fixes. Here’s what’s new:

    • First pass at some basic CSS transitions on link hovers, etc.
    • First pass at MP6 styling on post format picker.
    • Mobile: Adjusted theme customizer margins.
    • Mobile: Changed tablet breakpoint from 768px to 782px to match core.
    • Mobile: Fixed word-wrap issue on custom post types .widefat table headers and footers.
    • Mobile: Menubar now scrolls independently of the main column, so menu links are always visible even if you’re at the bottom of a long page.
    • Mobile: Better performance when scrolling in the admin.
    • Mobile: It’s now easier to dismiss dropdowns on touch devices.*
    • RTL: Corrected positioning of post-format-options.
    • RTL: Fixed tagchecklist position.
    • RTL: First stab at mobile style conversion for RTL.
    • RTL: First stab at admin-bar positioning.

    *There’s a known issue with the positioning of the New and Account dropdowns on mobile webkit browsers. We’ll have a fix in trunk as soon as we can (free WordPress blogs to anyone who has insight on a solution!)

    This week includes contributions from Joen Asmussen, Michael Erlewine (mitcho), Till Krüss, Andy Peatling, and myself. As always our thanks go to everyone who’s contributed by reporting bugs, offering suggestions, and testing it on your sites. If you’ve reported an issue here that hasn’t been resolved yet, rest assured it’s on our list and we’ll get on it soon.

    I’ll be out part of next week, so no IRC chat on Monday. We’ll continue to work on refining the responsive experience and RTL issues and stomping out whatever bugs you guys find.

     

    • Dean Robinson 1:16 am on May 26, 2013 Permalink | Log in to Reply

      hopefully the formatting below works…

      *There’s a known issue with the positioning of the New and Account dropdowns on mobile webkit browsers. We’ll have a fix in trunk as soon as we can (free WordPress blogs to anyone who has insight on a solution!)

      I had a bit of a play around this morning and my initial impression was that “position:fixed” is behaving a little more like “position:absolute” on mobile safari and the “position:relative” on its parent elements is causing the odd positioning.

      So, I’ve added this around line 125 in admin-bar.css (rules likely need some clean-up and definitely some better testing) to reset the position on the parent elements

      .touch #wpcontent #wpadminbar .ab-top-menu,
.touch #wpcontent #wpadminbar .ab-top-secondary,
.touch #wpcontent #wpadminbar #wp-admin-bar-wp-logo,
.touch #wpcontent #wpadminbar #wp-admin-bar-updates,
.touch #wpcontent #wpadminbar #wp-admin-bar-comments,
.touch #wpcontent #wpadminbar #wp-admin-bar-new-content,
.touch #wpcontent #wpadminbar #wp-admin-bar-my-account {
	position:static;
}

      Before: http://cl.ly/PDqy
      After: http://cl.ly/PD1c and http://cl.ly/PD4Z

      However, this results in the update/comments/new icons aligning left instead of right.

      I was able to trick them back into place using this, it works, but the negative margins make me nervous.

      .touch #wpcontent #wpadminbar #wp-admin-bar-comments,
.touch #wpcontent #wpadminbar #wp-admin-bar-new-content,
.touch #wpcontent #wpadminbar #wp-admin-bar-my-account {
	float:right;
}
.touch #wpcontent #wpadminbar #wp-admin-bar-comments {
	margin-right:95px;
}
.touch #wpcontent #wpadminbar #wp-admin-bar-new-content {
	margin-right:-97px;
}
.touch #wpcontent #wpadminbar #wp-admin-bar-my-account {
	margin-right:-147px;
}

      Result of above hack: http://cl.ly/PDXK

      Disclaimer: No idea if this would break things outside of mobile webkit (it was still ok in desktop firefox and safari), but hopefully it helps point anybody smarter than me in the right direction toward a solid solution.

      • Matt Thomas 3:33 pm on May 29, 2013 Permalink | Log in to Reply

        Thanks for taking a look at this, Dean (sorry you were held in moderation; I’ve been out for a few days). We’d also figured out that setting the parents to position: static fixed the dropdown issue but I hadn’t yet figured out a workaround for positioning those icons. Negative margins do make me a bit nervous as well, though if we limit the number of items that are visible in the toolbar on mobile browsers (hiding links that plugins add to the toolbar) that might be a fine solution. Or, as you mentioned, it may at least point us in the direction of a better solution.

    • JakePT 3:52 am on May 27, 2013 Permalink | Log in to Reply

      It looks like the admin table issue I raised in the last post is partly fixed. The rows no longer get extremely tall, however apart from the ttile column they are still very narrow:

  • Matt Thomas 8:59 pm on May 17, 2013 Permalink
    Tags:   

    Hey, UI gang. Here to help you wind down the week is the latest update to MP6, version 1.2.

    We’ve been focusing primarily on solving some of the trickiest responsive questions this week. Some we’ve found solutions to, and some we’re still discussing. We’ve also got a wild idea for the front-end of the site that we’ve got some mockups of to discuss.

    Here’s what’s new this week:

    • A new position for the “hamburger” button that opens/closes the mobile menu. It’s now part of the adminbar, and stays put when scrolling the rest of the page. There’s a much more obvious active style, and we’ve greatly increased the reliability of the button (no more multiple taps to get it to open anymore!).
    • Increased the size of wpadminbar dropdown menus for mobile sizes so that links are easier to tap. (We still need to work on making these easier to close without activating a link).
    • Improvements to the media uploader for responsive. Still needs work, but is more functional now.
    • Fixed buglets appearing because of Jetpack’s 2x retinafying code interfering with MP6.
    • Better positioning of icons in the wpadminbar.
    • Improved responsive layout on the Akismet configuration page.
    • Added new icon glyphs to the Dashicons font.
    • Reworked the way Open Sans is declared in the plugin.
    • Fixes to checkboxes and radio buttons.

    Once we decided that the adminbar was the best possible place to put the hamburger button for mobile, I started thinking about whether that same interaction might make sense on the desktop version of the dashboard. After all, we’ve already got a button that hides and shows the dashboard, it’s just always been at the bottom of the menu. What if we put it at the top, in the adminbar? The benefit would be that even desktop users would grow to understanding the meaning of the button, since its purpose, hiding or showing the menu, is the same whether you’re on desktop or mobile. If we took it that far, it could even go to the front end of your site; allowing access to any part of your blog’s dashboard within two clicks of your live site. This would be a bigger change than what we can do with just CSS in MP6, so it’s a topic we’re interested in your thoughts on, to see if it’s a good candidate for a potential core patch suggestion.

    This week’s edition of MP6 includes contributions from Joen Asmussen, Mel Choyce, Ben Dunkle, Till Krüss, Andy Peatling, and myself. Many thanks, as always, to those of you who have shared your feedback and ideas with us so far. Keep them coming!

    We’ll be in #wordpress-ui on Freenode May 20, 2013 at 18:00 UTC to discuss this week’s work; please meet us there if you’d like to chat about what’s new.

     

    • Hassan 9:32 pm on May 17, 2013 Permalink | Log in to Reply

      The idea of bringing the admin menu on the frontend (along with the admin bar) is just brilliant, I think.
      I don’t know why this never occurred to me before :)

      We need to make it a reality… after heavily testing it, indeed.

    • Hassan 9:47 pm on May 17, 2013 Permalink | Log in to Reply

      By the way, the update notification bubble is sometimes orange and sometimes blue. Is this intentional or a bug? I prefer the orange; the blue looks a bit wonky when the it’s on a highlighted menu item which is also blue.

    • mindctrl 12:34 am on May 18, 2013 Permalink | Log in to Reply

      Looking good. Bringing the admin to the front end is nice. A couple questions though.

      1. How much weight is that going to bring to the front end?

      2. Will we be able to totally disable that feature via filter/option/something where the weight doesn’t come with it if necessary?

    • Just a guy 12:58 am on May 18, 2013 Permalink | Log in to Reply

      I love it!

    • Dean Robinson 12:39 pm on May 18, 2013 Permalink | Log in to Reply

      If we took it that far, it could even go to the front end of your site; allowing access to any part of your blog’s dashboard within two clicks of your live site.

      Hot.

      +100

    • Aaron Hockley 4:50 pm on May 19, 2013 Permalink | Log in to Reply

      Random question: why do the MP6 updates not show up as updates w/in WordPress (I don’t get an update notification; can’t update from within the admin screens, etc)? I’m seeing this on several sites (multiple web hosts) so I trust it’s not a “just me” problem.

    • Matt Van Andel 5:08 am on May 21, 2013 Permalink | Log in to Reply

      Making the dashboard menus available from the frontend is just brilliant. I love, love, love the idea.

      That aside, I like the idea of having the mobile and desktop hamburger button consistently in the top-left of the admin bar as well.

    • Lea Cohen 5:22 am on May 21, 2013 Permalink | Log in to Reply

      I love the idea of bringing the admin menu on the front end !

    • Lea Cohen 5:35 am on May 21, 2013 Permalink | Log in to Reply

      And 2 more RTL issues:

      1) The adminbar doesn’t change direction on RTL.
      This is what it’s supposed to look like (the screenshot is wide, so I’m just linking to it, not embedding it here), and this is what it actually looks like with MP6.

      2) It seems that press-this didn’t get any RTL care… :)

    • JakePT 6:37 am on May 21, 2013 Permalink | Log in to Reply

      I’m having an issue with plugins that add columns to a custom post type using the manage_edit-POSTTYPE_columns filter. All the columns apart from the Name column become extremely narrow on small screens, forcing each letter to a new line, meaning the rows become very tall.

      Note that I haven’t used any custom CSS to resize the columns in the normal view.

    • Nick Halsey 9:22 pm on May 21, 2013 Permalink | Log in to Reply

      I love the frontend menu idea, although I think we risk putting too much visual weight on the active/open menu indicator on the backend using those mockups; I can’t think of a good solution other than retaining the existing treatment in the admin and only changing mobile and the frontend. Since the menu will usually be expanded in the admin for most users, the active menu icon is distracting, and the expanded/collapsed states are used more by preference than as active/inactive states.

      Also, the TinyMCE icons are being misaligned vertically unless they have dropdowns…

    • Ipstenu (Mika Epstein) 9:35 pm on May 21, 2013 Permalink | Log in to Reply

      Post Format images don’t show up with MP6 active

      • Matt Thomas 11:18 pm on May 21, 2013 Permalink | Log in to Reply

        Hmm, I can’t reproduce this one. I’m on the latest version of trunk, and the icons seem fine. Try an svn up or delete/re-install and if you’re still seeing it, let me know what browser and that other good stuff.

        • Ipstenu (Mika Epstein) 12:02 am on May 22, 2013 Permalink | Log in to Reply

          Tested a fresh version. Fails on Chome (mac) every time. Also tested on Firefox and Safari, same thing. It works until I turn on MP6.

          • Matt Thomas 12:11 am on May 22, 2013 Permalink | Log in to Reply

            Aha! Reproduced it after updating WP to the latest nightly. Looks like something changed there; I’ll figure out what.

          • Matt Thomas 12:45 am on May 22, 2013 Permalink | Log in to Reply

            Since the icons moved to colors-fresh/colors-classic, I took the opportunity to go ahead and add them to colors-mp6 as dashicons. Should be all fixed up now in trunk, with a first pass at some MP6-ish styling.

    • JPry 9:18 pm on May 24, 2013 Permalink | Log in to Reply

      Here’s a suggestion for a bit of consistency:

      It would be good on the Plugins page to change the `border-left` property to the same orange-ish color that is visible behind the update count. This would make it much easier to distinguish plugins that have an update available.

  • Siobhan 5:26 pm on May 17, 2013 Permalink  

    Hello UIers! The kind folks at Balsamiq have provided us with a free license for MyBalsamiq for the WordPress project. If you don’t know what Balsamiq is, it’s a tool for creating mockups (and it’s pretty cool)

    If you are working on anything relating to the main WordPress project and sister projects (BuddyPress, bbPress, GlotPress) and you need to put together mockups let me know and I can add you to the account. Email: siobhan at wordpress dot org.

    Update: this is for people working on the core WordPress project and sister projects. It is not for people creating third-party plugins and themes.

     

    • Shane Pearlman 5:35 pm on May 17, 2013 Permalink | Log in to Reply

      if you need to do anything with the admin we have some balsamiq templates of the admin: http://tri.be/?s=balsamiq. some are way out of date, but are a good starting point. I probably have them all up to date in some internal projects if you need anything specific.

    • Siobhan 5:42 pm on May 17, 2013 Permalink | Log in to Reply

      Shane’s templates are awesome. I’ve used them many times :)

      That also reminds me: there’s a user-contributed collection of UI components and design for Balsamiq. If anyone wants to contribute any I think that would make them very happy.

    • Jose Castaneda 6:03 pm on May 17, 2013 Permalink | Log in to Reply

      Not going to lie: That is pretty awesomesauce!

    • Hugh 9:19 pm on May 17, 2013 Permalink | Log in to Reply

      I use Balsaiq for some other work I do. What is MyBalsamiq?

    • paaljoachim 10:59 pm on May 20, 2013 Permalink | Log in to Reply

      Very cool Siobhan! As I came across this UI project I also posted a few things further below which I thought might be added to the UI but it is not a part of this specific project. So I have been playing with the thought on how to improve the admin area menus and submenus of WP. Using Balsamiq would be very cool! It sure would be easier then using Photoshop (which I used to create some mockup of the menu area in WP), or Inspect Element in Chrome which I used to give UI tips to the guy who create Ultimate http://wordpress.org/plugins/ultimate-tinymce/

← Older posts

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