WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Janneke Van Dorpe 11:40 am on November 28, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Front-end Editor Update 

    I’ll briefly summarise some of the things we said in last week’s meeting, at WordCamp London and on Skype.

    • We’d like to experiment with the toolbar (or part of it) popping up on selecting some text, even though it’s not easy to discover without clearly pointing it out to the user, and there’s no way all the options could fit in. It’s probably best to keep a fixed and permanent toolbar on top and develop a smaller inline toolbar next to it. We can then hide one of both to do some user testing. Some inspiration here, here and here.
    • For now, it’s better to focus on the most basic TinyMCE functionality, keeping in mind that it should be extendible. Let’s also just focus on the most used WordPress options, things like Custom Fields, Discussion, Author and other custom meta boxes are low priority and maybe not even in scope.
    • In the next version of the plugin, the toolbar will move up, like this: Screen Shot 2013-11-18 at 17.06.14
    • It now also depends on WordPress 3.8-alpha or higher, so you’ll need to update your install to test it.
    • Another thing that needs to be done is, apart from experimenting with different editing interfaces and taming TinyMCE, designing and developing a way to preview oEmbeds and shortcodes/galleries and thinking about other ways to insert shortcodes other than manually inserting them. If we want a real WYSIWYG editor, having a preview for those is a must.
    • A Skype group has been set up, so if you’d like to join, add jannekevandorpe and let me know.
    • The next meeting will be Monday, 2 December, 16:00 UTC on the #wordpress-ui IRC channel.
     

    • Tom Greenwood 12:22 pm on November 28, 2013 Permalink | Log in to Reply

      Thanks for the update.

      I agree that having the main toolbar fixed at the top is simple and intuitive – the screenshot looks good.

      The inline toolbars shown on CodersGrid are a really nice idea. I don’t think they are essential, but probably a nice to have so worth testing. The Barley Editor is pretty similar to TextMorph in that you can just type over text on the front end and the simplicity is great. However, the big issue I have with it is that there is not visual indicator that you are in editing mode. I think it is essential that the user always knows when they are/are not able to edit the content on the front end.

      I think as discussed at WordCamp, most if not all meta boxes could be handled in some sort of overlay that can be accessed when you need it, but which doesn’t clutter up the page the rest of the time.

      Also as mentioned at the weekend, I 100% agree that things like shortcodes need to be visual in the editor so that you get a real WYSIWYG experience.

      I have added you on skype. I may have a client meeting at that time but if I can make the call then I will.

    • Janneke Van Dorpe 12:42 pm on November 28, 2013 Permalink | Log in to Reply

      Yes, that was the idea, to have all the meta boxes in a modal, but we can experiment with that later.
      The meeting will be on IRC, not on Skype. Sorry for the ambiguity. I’ve added it to the post.

      • venkmanuk 7:01 pm on December 10, 2013 Permalink | Log in to Reply

        i’m new so maybe i have the wrong end of the stick… let me know if so!

        i think that one of the reasons Medium is so good is the simplicity of the editor.

        I recognize that previews for embedded content would be good – but i feel like modals are a step backwards in terms of ux. The idea is to edit directly into the page – right? So why not just allow pasting embed code into the page. once the user moves on to the next thing the embed is previewed live in the browser. if the issue is identifying/differentiating embedded code from text then maybe have one of the controls ‘switch’ that section to HTML mode instead of editor..

    • Native Imaging 3:16 pm on November 28, 2013 Permalink | Log in to Reply

      If the front editor had responsive column templates with some drag & drop features, I think I would use the Front End Editor for everything. But at the moment, a lot of important WP features are not available when making pages or posts. I also prefer to use plugins for grid layouts such as the Page Builder and others. I’ve pretty much ruled out all possibilities of clients and users using shortcodes for columns. If any code at all is involved with page composition, it will fail every-time. lol.

      • Tom Greenwood 4:42 pm on November 29, 2013 Permalink | Log in to Reply

        I agree about drag and drop columns and keeping code out of the editor. I think that is pretty fundamental in a visual editor.

    • Weston Ruter 7:50 am on November 29, 2013 Permalink | Log in to Reply

      What about abandoning TinyMCE in favor HTML5′s ContentEditable? With it, you can turn any element in a page whatsoever into a rich text area (i.e. it is seamless), which seems exactly what is needed for the frontend editor.

    • Tom Greenwood 4:44 pm on November 29, 2013 Permalink | Log in to Reply

      Quick question. I may be missing something obvious, but do you know why the front end editor is not visible on the front end of this site where I am testing it when I am logged in? http://www.eatwholegrain.co.uk

      Running 3.8 beta and Front End editor plugin is installed.

    • Gabriel Gil 12:41 pm on December 2, 2013 Permalink | Log in to Reply

      hey guys!
      I would love to be part of the testers of this great plugin but let me introduce little bit before.
      I’m a web developer from Vigo, Spain. Currently working by myself using WordPress on the most of my projects. For example: odd-barcelona.com and newworldsgroup.com

      Thanks in advance.

      • Sam Sidler 11:16 pm on December 2, 2013 Permalink | Log in to Reply

        Welcome Gabriel! You can install the plugin right now and test, but keep in mind it’s still under active development and might be rough around the edges. Test away and let us know what you think! We’d love to have to at the weekly chats (were you there today?!). If you have Skype add me (samuelsidler) or Janneke (see above) and we’ll add you to the Skype channel. Cheers!

    • alpha1beta 8:48 pm on December 6, 2013 Permalink | Log in to Reply

      I would love to be part of this project. I have been testing it a bit myself and have felt the need for similar featured in the past. I have hacked together some things that may compliment the editor and would love to contribute ideas and maybe code.

      Specifically, I would like to:
      Mark the location of the More Tag
      Mark the Location or the Next Page tags
      Add a class of Preview to the Body when editing or previewing a post. (Written and working)
      Allow Preview as an article would show up on the homepage/category pages and others, not just the single-preview page. (I have a work in progress on this)
      Ensure the Front End Editor takes or can take all changes applied to the current edit post page (If you enable and add custom types they do not show up currently.
      Add Support for Custom Taxonomies in the edit bar (Just like the categories and tags have now) if they have the permissions to show in adminbar.

    • Rafael Angeline 8:11 am on December 11, 2013 Permalink | Log in to Reply

      Hello! Fantastic project, exactly what I was thinking to develop. Would be amazing see it integrated to WP core in the future. WP is missing a great front-end editor!

      Looks like the hardest part is the shortcode/embed integration and how can we handle it, it’s hard but we can develop something to solve this!

      Added you guys at Skype :)

      When will the next meeting happen?

    • Tom Greenwood 6:26 pm on December 13, 2013 Permalink | Log in to Reply

      I don’t know whether it is best to post feedback here or in the skype chat, but I tossed a coin and here it is.

      I know we touched on this in last weeks IRC, but having played around with the editor more now, it is clear that there are some usablity issues with the way we are locating things.

      1. The floating toolbar just doesn’t work in my mind. It isn’t located anywhere that you would logically look and so isn’t easy to see at a glance. As we discussed last week, an inline position would be much better.

      2. It is really confusing that we have tools and options spread in several locations. We have the toolbar on the page, the EDIT/Cancel button in the top bar and the other tools and buttons at the bottom of the browser. I think it is really important that we clarify the logic and workflow of this. I’d suggest that any tools used to actually edit text should be in the inline toolbar, even if they are in the kitchen sink. For example, it is frustrating as a user that I have to look elsewhere to insert an image or add a hyperlink. It would then also make a lot of sense to put the save button in the top bar next to the EDIT/Cancel button, because I think that is where you would expect it to be. As discussed last week, perhaps the other info in the top bar could be hidden when you are in edit mode to reduce clutter/confusion, allow more space for editing relating elements and also make it more obvious that you are in edit more because the top bar is distinctly different.

      3. Following on from above really, I think we do need to make a bigger visual statement that you are in editing mode. I’m trying to think about the general public using WordPress and figure that if I have to look around for a clue then less experienced users are going to feel really lost.

      4. I am testing on a site with a dark grey background and the toolbars just blend in. Either we could have it automatically switch between light/dark depending on your theme colour, or perhaps there could be an option in your site settings to change this manually.

      As discussed previously, the ability to create content on the front end and to edit other elements (e.g. widgets) and live preview shortcodes should be on the list of things to do long term, but I know we’re focussing on getting the basics right first.

      I’ll post more when I’ve tested in more detail.

    • alexpatin 7:16 pm on December 13, 2013 Permalink | Log in to Reply

      I’ve been meaning to take a look at this. I saw it the other day when I was exploring front end editors, so I’m definitely excited for this as a feature to come to core. I’ll start playing around and follow along with the updates, looking forward to contributing!

  • Sheri Bigelow (designsimply) 4:32 pm on November 20, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    User Testing the Better Widgets 0.1 Plugin 

    Let’s keep going with the work on widgets! I’ve tested the Better Widgets 0.1 plugin with the Twenty Eleven theme on WordPress 3.7.1 and there is some interesting stuff in the results.

    Summary

    • No problem at all rearranging or deleting widgets
    • Had trouble with the drag-and-drop target area at first
    • Suggests adding a way to add new widgets directly from the Widgets page
    • Uses the wrong widget area, completely misses the pre-expanded “Main Sidebar”
    • Customizer is slow

    Successes

    No problem rearranging widgets:

    No problem deleting widgets:

    Points of Confusion

    Unsure where to go when asked to add a bio to the sidebar:

    Drag-and-drop misfires:

    Completely misses the pre-expanded “main sidebar” widgets (longest clip at 4:11):

    Other Insights

    Wants to know how to add more widgets from the Widgets screen:

    Reasons for picking search and calendar widgets:

    Unrelated to Widgets

    Slow customizer is slow, takes ~24s for this user to load it up:

    If you’d like to see the full video, you can download it here: Better Widgets v0.1

    (For Reference) Tasks Used in the Test

    • Add a bio to the bottom of the sidebar.
    • Look through the widgets and pick two that you like. Add both of them to the sidebar and say why you picked them.
    • Rearrange the widgets so the bio appears at the top of the sidebar.
    • Remove all of the widgets except the bio and one other widget you think is the most important to keep.
    • The test website is using the Twenty Eleven theme. It has a widget area called “Showcase Sidebar.” What do you think that’s for, and how would you go about figuring out how to set it up?

    User’s Computer Info

    • Operating System: Windows NT (unknown) 6.2
    • Browser: Windows Chrome 30.0.1599.101
    • Display: 1366

    My Observations & Suggestions

    • The drag-and-drop misses in this video are interesting, makes me wonder if having widget areas side-by-side is good or not—or perhaps arranging them more masonry style instead of in a grid would be better
    • Interesting that she didn’t connect “sidebar” and “widgets” right away, but getting into that label is tricky business and I’d like to watch that area with more users in order to spot trends
    • Love the suggestion to have an “Add New” button on the widgets page
    • Different sidebar areas for themes is tough, I think it’s pretty hard to tell what in the world the “Showcase Sidebar” is for if you’re not familiar with Twenty Eleven
    • It’d be great to focus on customizer performance speed

    Next up: same test, except run it on WP 3.8 trunk. What specifics are you interested in finding out from tests like these?

     

    • Weston Ruter 5:55 pm on November 20, 2013 Permalink | Log in to Reply

      Perhaps the slow loading for the customizer was just a network problem? It seems like an external script was blocking the page loading. In my experience the customizer loads very fast.

      • designsimply 7:27 pm on November 20, 2013 Permalink | Log in to Reply

        Could be. I’ve seen the problem show up more than once in tests, so I’ll keep watching to see if it continues to be a trend.

  • Andrew Nacin 3:17 pm on November 19, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Targeting the new dashboard design in a post-MP6 world 

    There’s been a lot of chatter about how to handle the detection of the new dashboard design in a plugin in WordPress 3.8, now that the “mp6″ body class is gone. I have three suggestions, any of which can be used depending on the situation.

    The WordPress admin assigns a “branch-x-y” class to the body. So, branch-3-8, branch-3-9, etc. But rather than targeting 3.8 or newer this way (which will require you to add selectors for versions far into the future), target 3.7 or older. So if the latest version of your plugin supports 3.6 or later:

    .branch-3-6 .some-selector,
.branch-3-7 .some-selector {
     /* some rules go here for 3.6 and 3.7 */
}
.some-selector {
     /* 3.8+ rules go here */
}

    As your minimum requirements increase over time, the older rules can simply be removed. Pretty easy.

    The second method is for when you require greater UI robustness. (This is also good for instant compatibility with existing code written against MP6.) Simply add your own mp6 class to the admin. The admin_body_class filter is a little funky, so bear with me:

    add_filter( 'admin_body_class', 'nacin_please_prefix_this_add_mp6_class' );
function nacin_please_prefix_this_add_mp6_class( $classes ) {
    if ( version_compare( $GLOBALS['wp_version'], '3.8-alpha', '>' ) ) {
        $classes = explode( " ", $classes );
        if ( ! in_array( 'mp6', $classes ) ) {
            $classes[] = 'mp6';
        }
        $classes = implode( " ", $classes );
    }
    return $classes;
}

    An added benefit here is some nice standardization: If multiple plugins need this same class, it’ll simply be added once and be subject to shared usage.

    The final method is for if you need to know in PHP whether MP6 the plugin is enabled outside the body class. For that, simply use the version_compare() above.

    if ( version_compare( $GLOBALS['wp_version'], '3.8-alpha', '>' ) ) {
    // 3.8 dashboard theme
}

    To those asking why we shouldn’t just include the class in 3.8: WordPress evolves over time, and even 3.8 has significant changes when compared to MP6 the plugin. While we do strive to maintain backwards compatibility — including, to some extent, when we merge in popular plugins — a line needs to be drawn somewhere. Short of introducing a “version” string of the UI (which would be redundant, given WP versions), there’s just no great way to solve this, especially when trying to be forwards compatible with future design changes (to 3.8 and beyond). It’s worth noting that the branch-x-y classes were introduced a few versions ago specifically for the purposes of managing UI changes in plugins.

    A side note, and this is purely a personal preference, I’d really like to *stop* calling the dashboard design “MP6″. I don’t just mean in code, I also mean in general nomenclature and bug reports. Code names are cute in software development, and it helps to have a shorthand. (We already have a lot of them — too many, even.) But we’ve reached the point where we are about to ship this to tens of millions of users. It’s time to drop it. In bug reports, let’s simply set the “version” field to “trunk” and file it under the Administration component. In general, let’s celebrate it as the new design and aesthetic that WordPress 3.8 brings/brought us. It’s no longer MP6. It’s now just WordPress.

     

    • John Blackbourn 4:21 pm on November 19, 2013 Permalink | Log in to Reply

      I’m not sure this addresses the main concern that was brought up (#25906), which is themes that have a fixed header and need to fix it at a certain number of px from the top in order to clear the admin toolbar.

      The height of the toolbar has changed in 3.8, so themes that want to retain backwards compat with pre-3.8 need a simple way of targeting pre-3.8 in CSS.

      Sergey’s added a patch to #25906 which adds the branch number to the front end body class. Is this likely to go in? If so, themes will be able to use that.

      • Andrew Nacin 4:59 pm on November 19, 2013 Permalink | Log in to Reply

        Great question. I have been thinking about this for a while.

        For starters, themes could use one of the techniques listed here by adding their own classes for 3.7 or earlier. Twenty Fourteen is already filtering the body classes, so it would be a few short lines of code. This likely affects very few themes anyway.

        It would be great if we can come up with a solution for Twenty Fourteen that negates the need to account for the toolbar. I hate that the situation even exists where a theme must know 28px versus 32px, and we should pursue multiple avenues to avoid it. A new class is possible (for the branch or something like .admin-bar-32). But, it’s not like this is a CSS-only situation; the JS is already being used to fix the header and could be used to look at the height of the toolbar.

        It would be interesting to see if the toolbar can be designed without those extra 4 pixels, even if just on the frontend. It actually looks quite good at that height. The extra pixels are most needed in the admin so it doesn’t feel cramped when compared to the rest of the admin.

    • Hassan 4:43 pm on November 19, 2013 Permalink | Log in to Reply

      The demise of the “MP6″… sniff :P

    • George Stephanis 4:57 pm on November 19, 2013 Permalink | Log in to Reply

      If doing the `version_compare()` check against a src checkout, it’ll actually not work, as version_compare returns `-1` when doing `version_compare( $wp_version, ’3.8-alpha’ )` — as $wp_version is `3.8-alpha-src` — which is calculated to be less than `3.8-alpha`

      So do `version_compare( $GLOBALS['wp_version'], ’3.8-alpha-src’, ‘>=’ )` instead and you should be good.

      • Andrew Nacin 5:00 pm on November 19, 2013 Permalink | Log in to Reply

        $wp_version is currently 3.8-alpha-26127-src, which is greater than 3.8-alpha. The check in the post is fine.

        • George Stephanis 5:04 pm on November 19, 2013 Permalink | Log in to Reply

          Ah, just needed an `svn up` locally. I was at the interim revision before r26127 where it was merged in, but the version was still 3.8-alpha-src without the revision.

    • Jason (Theme Blvd) 7:47 pm on November 20, 2013 Permalink | Log in to Reply

      Within the various admin color schemes, there are a lot of useful CSS classes we can use that are all prefixed with “mp6-” — i.e. mp6-primary, mp6-text-primary, mp6-highlight, mp6-text-highlight, etc.

      Will these end up being changed to something else?

    • Shea Bunge 9:36 am on November 21, 2013 Permalink | Log in to Reply

      How are we now supposed to specifically target all versions running new interface or the old interface in CSS?

    • Bryce Corkins 9:46 pm on November 21, 2013 Permalink | Log in to Reply

      Didn’t see anywhere to post general questions, so thought I’d ask here:
      I’m writing a new plugin framework and I’d like to support the new WordPress admin style / MP6 from launch as much as possible. Is there a guideline for how to style jquery-ui tabs within a single plugin’s settings page? I’m thinking either white page body with the “active” tab also white, or grey page body with the inactive tabs dimmed somehow.

    • Juanfra Aldasoro 3:50 pm on December 4, 2013 Permalink | Log in to Reply

      Is there a simple way/function to get the current admin color scheme programmatically speaking and not css? I’ve seen that I can find that within the $GLOBALS, but is not so handy.

      I’m asking this because I now have to call different icons for the menu, depending on the color scheme (the default style requires light icons, light style requires dark icons ).

      Thanks!

    • olyma 7:04 pm on December 5, 2013 Permalink | Log in to Reply

      Okay, this entry above seems to sort of maybe answer my question, but I could use a little more clarity. It sounds like from what people are saying here and there is that the admin interface is now quite skinnable. If this is true, that the interface is much more skinnable:

      1) Where are the skin files located in my wordpress installation?
      2) Is there a skin to change it to appear the 3.7.1 way or in any other way than what comes box-standard?
      3) Should we use the method above and where should we plop that code in order to change the skin?

      Many Thanks!

  • Mel Choyce 6:45 pm on November 11, 2013 Permalink
    Tags:   

    Since there have been some questions about CEUX recently, as announced in our 10/22 meeting, CEUX has been put on hold until there are more available developers interested in working on the project.

    Thanks to @joen for collaborating on concepts with me, everyone who pitched ideas here and in our weekly chats, and @diegoliv and @briandichiara for their hard work on the CEUX plugin. Diego has expressed interest in working on the plugin some more in his spare time. If anyone else is interested, I’m happy to give commit access.

    ’til next time. See you, space cowboys.

     

    • julianprice 3:30 am on November 16, 2013 Permalink | Log in to Reply

      Hi @melchoyce looks awesome thanks you guys for all your hard work. First of all I am newbie here commenting but for some time I have been wanting to find away to contribute to the wordpress community even though I do not have has much web exp at all but have been learning … I guess :) who knows…

      Anyway I was unsure where to post so you the first I came to just for user experience and have followed you and Helen tuts from word camps on .tv.

      I will cut to the chase now in part to vent that word camps video sessions are constantly talking about engage in the community contribute make WordPress better. In my opinion though and certainly know this is all voluntarily contribution but you have engage perspective of others that are not remotely in your business.

      So my means of engaging contribution was as follow: http://wordpress.org/support/topic/suggesting-box?replies=1

      No replies no engagement nothing from someone that is a complete outsider trying to contribute. I know this probably should be in support or plugin ; bottom line I consider this u/x on the overhaul of wordpress.org usability especially with plugins in catgorories of functionality, requirements for plugin in developers to at least place in 1 cat no more than 3 & no more than 5-10 tags.

      I see the plugin repo as a pin board with catgories of functionally: sliders, galleries, content types, social media tools, admin tools, styling tools, short codes,…you probably know best how to categorize than I do.
      In addition ensuring tags on the submissions. On top of bringing to front by 6 months updated, 1 yr updated and removing all others.

      I certainly giving suggestion in addition I am happy to go in start catgorzing/ tagging them in right format or even better I am pretty sure there could be a user suggest script to place in cat and/or tag.

      That’s all I have at this to contribute to make.wordpress.org better.

      • Mel Choyce 5:27 pm on November 20, 2013 Permalink | Log in to Reply

        Hey! Glad to see you’re interested in getting involved in improving WordPress UX and usability. From your post, it sounds like you’re interested in improving WordPress.org itself. The best place to get involved on that front is http://make.wordpress.org/meta/, the Make subgroup that helps tackle the WordPress community websites and tools. They have their own track, where you can bring up usability and UX issues: http://meta.trac.wordpress.org/

    • Leah 12:52 pm on November 18, 2013 Permalink | Log in to Reply

      Perhaps something to check out: http://madebymany.github.io/sir-trevor-js/

    • roodlicht 4:35 pm on November 20, 2013 Permalink | Log in to Reply

      And here is the English version of the last URL regarding TYPO3 Neos: http://www.roodlicht.com/typo3-neos-or-typo3-cms/3364?lang=en

  • Janneke Van Dorpe 5:35 pm on November 11, 2013 Permalink
    Tags:   

    Front-end Editor Meeting Recap (November 11) 

    Attendees: @avryl, @helen, @melchoyce, @samuelsidler, @shaunandrews, @ubernaut

    We had a good chat today about the status of the front-end editor plugin and where it’s going. To recap, we talked about the following:

    • The overall list of tasks is on a spreadsheet now. It will probably grow considerably over time. If you’re interested, comment here to sign up!
    • The color scheme of the front-end editor was based on the MP6 customizer being black. The customizer (as has landed in core) has changed to white/grey, so we should update the plugin as well.
    • On the color scheme topic, it may be possible to use color schemes for the editor in the future, but it’s not worth looking at until much later in the process.
    • The plugin currently has an MP6 dependency, which is no longer needed given that MP6 has landed in core.
    • The fade of the edit bars is a bit too much and should be removed, though this won’t exist when the toolbar moves up to the admin bar.
    • In edit mode, things might look better if everything but the content fades out, but we need to determine how to do this right.
    • The project is still in its early stages. It might be worth working up some other concepts before we get too far along in one direction.

    Next steps:

    • @avryl to remove the MP6 dependency, add the wordpressdotorg author to the plugin, and fix the permalink issue. Done.
    • @shaunandrews will explore some other concepts.
    • Setup a Skype group for those interested in contributing.
    • The meeting time will change to Mondays at 16:00 UTC going forward.
     

    • Gizburdt 7:19 pm on November 11, 2013 Permalink | Log in to Reply

      Hi! Couldn’t make it to the chat tonight, but I really would like to contribute to this plugin and help to make it the most awesome plugin yet! ;)

      And is it possible for me to join the Skype group?

    • @ubernaut 7:49 pm on November 11, 2013 Permalink | Log in to Reply

      Awesome meeting today thanks for all your hard work on this Avryl!

    • mrwweb 3:06 am on November 12, 2013 Permalink | Log in to Reply

      Glad to see more progress! In the spirit of considering alternate concepts, I’d like to reshare the work I’ve done on “inline access” (as opposed to “inline editing.”). I wrote up my thoughts on it at http://mrwweb.com/wp-inline-access/ and Joomla is implementing something similar in 3.2.

      Since my initial write-up and proposal, I’ve built a functioning prototype that’s in the plugin repository (http://wordpress.org/plugins/wp-inline-access/) and on GitHub (https://github.com/mrwweb/wp-inline-access). I’d love to hear from people on whether this seems like an idea worth pursuing further and whether any of the observations that led to it may be worth incorporating into this project.

      • mrwweb 6:47 pm on November 14, 2013 Permalink | Log in to Reply

        And a quick followup, I just posted a write-up of my progress so far, lessons learned, and a brief summary asking for help determining the future of my work on WP Inline Access. http://mrwweb.com/wp-inline-access-future/

      • Janneke Van Dorpe 8:13 pm on November 14, 2013 Permalink | Log in to Reply

        I like your idea. But I think this feature is trying to do something different. You’re trying to link all the bits from the front-end to the relevant bits on the back-end, which is great! Letting users edit on the front-end with an immediate visual result is what this feature is trying to do. But if it’s decided not to continue with this, ‘inline access’ would be a good way to go, and even if we continue with front-end editing, it might be desirable to implement something similar for e.g. widgets. These are just my thoughts of course.

        • mrwweb 8:08 pm on November 15, 2013 Permalink | Log in to Reply

          I hear you @Janneke Van Dorpe. I agree that the plugins do different things but a lot of decisions I made were in response to some concerns with the ideas of front end editing. The original post (http://mrwweb.com/wp-inline-access/) talks about my concerns with front end editing more that the more recent post. I’m interested in hybrid approaches (like you say, widgets [and menus] seem to be the big inline access wins) but I think it may be very hard to merge them cohesively.

    • bfintal 1:02 pm on November 14, 2013 Permalink | Log in to Reply

      One thing I find hard to brainstorm on is how to implement shortcodes and custom fields in front-end editing. Plus isn’t it a downside to have 2 different code bases that handle page/post editing (one back-end, one front-end)? The current back-end method is stable and very familiar to users.

      How about trying the split screen approach from within the back-end? What if in the same edit screen we have now, get rid of the left navigation area and the right sidebar. Half the size of the content editor then stick it to the left. The title and custom fields and other stuff can still stay below the content editor. The right half of the page would be the preview of the page/post that gets updated via javascript.

      I dunno, from a development side, I think doing a split screen is easier to create and will use a lot of the code base we have right now. It’ll just need some clever javascript code to make the live preview render super fast.

      • Janneke Van Dorpe 8:30 pm on November 14, 2013 Permalink | Log in to Reply

        Think of the converted shortcode as some kind of uneditable object that’s inserted in the editor. By clicking on it you can edit the short code again. Complex short codes (such as galleries) could have their own modals.

        Do you mean something like this mockup by @rockethouse? It just feels like a waste of space, having the same content twice on the same screen, once live and once in a WYSIWYG editor. What’s the point of having a WYSIWYG editor? I totally understand this approach if you’re writing pure html or markdown. Otherwise, why not let users edit right on their website?

        • bfintal 11:38 pm on November 14, 2013 Permalink | Log in to Reply

          Yea that mockup does it.

          But yes you’re right, the first time I saw the image on the left and the right, my first thought was that there was wasted space. That really won’t work for the WYSIWYG TinyMCE content editor.

          I do however edit mostly using the html tab in the admin, so the split screen would do wonders there.

          The idea of shortcodes having a different method of editing, such as modal pop ups make me cringe. For one of my WP themes, I tried before adding a bunch of TinyMCE buttons to insert shortcodes. Clicking those buttons opened up modals with fields for the shortcode parameters. It worked, but it was a hassle to create pages since there was a lot of mouse clicking involved. It depends on the execution though.

          I would suggest something like a split screen again. The left shows the markdown editor, and the right is the front-end editor. But that would look pretty much like Ghost.. still thinking.

      • Janneke Van Dorpe 8:41 pm on November 14, 2013 Permalink | Log in to Reply

        In my opinion, a split screen approach is definitely not the way to go for WordPress. If the editor was html/markdown based, like Ghost, then it would make sense, moreover, it would be the only way to go.

      • mrwweb 10:06 pm on November 15, 2013 Permalink | Log in to Reply

        It’s also important not to forget about editor-style.css. A lot of themes don’t implement it or implement it poorly, but it does solve many (most?) of the problems about body content looking like the front end.

    • Janneke Van Dorpe 6:29 pm on November 15, 2013 Permalink | Log in to Reply

      The next meeting will be delayed by an hour, so it will be on Monday, 18 November, 17:00 UTC. Sorry about that!

    • Tom Greenwood 1:30 pm on November 16, 2013 Permalink | Log in to Reply

      Hi guys, Really interested in this project. Can you tell me how we can get involved?

      I’m testing split screen and front end editing options at the moment and I think at the present time, split screen is the simplest option and a big improvement on what we have by default, but my understanding is that this project is looking long term at what users will really want and I think genuine front end editing is going to be the way to go long term.

      When I talk to my clients about what they would want in an ideal world, they want to be able to write and format their pages the way that they are going to look when published. Basically, they want WYSIWYG, and that means front end. I think shortcodes and custom fields could be challenging, and as mentioned above there will always need to be an easy way to switch to HTML view, but these are challenges to be overcome rather than fundamental road blocks.

      I’m going to be discussing this at WordCamp London next week so happy to share any ideas and feedback that I get from there.

      Thanks for creating this project guys! I think it is much needed to keep WP at the forefront of online publishing.

      Tom

      • Sam Sidler 3:01 pm on November 18, 2013 Permalink | Log in to Reply

        The best way to get involved is to attend the weekly chats. The next one will be today (!) at 17:00 UTC. That’s about two hours away from this comment.

        Outside of that, there’s a spreadsheet with things that need to get done. If you want to sign up for anything, @avryl is the one to talk to.

        Both @avryl and myself will be at WC London as well. Would love to talk about your ideas and the ways you want to get involved.

    • @ubernaut 8:01 pm on November 21, 2013 Permalink | Log in to Reply

      we were mentioned in this recent interview with wp.com’s CTO:

      http://www.wptavern.com/cto-of-wordpress-com-interviewed-by-frantic

  • Janneke Van Dorpe 10:54 pm on November 9, 2013 Permalink
    Tags:   

    Front-end Editor #2 

    I apologise for disappearing like that, but here’s a small update for the front-end editor!
    Just as a reminder, the link to the previous post, the plugin and the GitHub repo.

    We need your help!

    Here’s a list of some of the things that need to be done. Currently it’s just a draft and it will probably expand over time. I’ll start tackling them one by one, but if you’d like to take one of them, or if you have suggestions, let me know. Also feel free to fork the plugin, transform it with your thoughts and share the results!

    There will be a meeting Monday, 11 November, 16:00 UTC on the WordPress UI IRC channel, and I’ll definitely be there. If you’re interested, please join! Or leave a comment if you can’t make it.

    I’ll try to publish a post every week with the progress we’ve made.

     

    • JarretC 12:20 am on November 10, 2013 Permalink | Log in to Reply

      I’d be interested in trying to setup the date/status/visibility stuff for the meta modal but wondering if I should hold off first until the hookable version gets designed.

      Also, not sure where to setup that stuff at. I was thinking in the bottom bar where there is the stuff to set tags/categories/etc but not sure if that would be the best place.

      • Janneke Van Dorpe 10:25 am on November 10, 2013 Permalink | Log in to Reply

        Maybe it’s better to find out how often the date/status/visibility/author options are used and then place them either in the toolbar or a “general” meta section in the meta modal? In any case, this has to wait until the toolbar has been moved up or the meta modal has been designed, but we can start thinking about where to place it.

    • Erlend Sogge Heggen 10:19 am on November 10, 2013 Permalink | Log in to Reply

      So how are you planning to harmonize this with the CEUX project?
      http://make.wordpress.org/ui/2013/09/23/ceux-sept-17-chat-notes/

      Is this meant to be the immediate improvement, while CEUX takes the long-term approach for a radical change down the line?

      I sincerely hope this improved front end editor makes it into 3.9. The lackluster writing experience is imo the #1 detractor for WordPress bloggers today.

      • Janneke Van Dorpe 10:36 am on November 10, 2013 Permalink | Log in to Reply

        I’m not sure how CEUX is evolving right now. Does anyone know how they’re doing?

        I think both features are trying to do something very different, and eventually they could work perfectly well together. Content blocks is something that can be applied to both the back-end and front-end editor. But ultimately we’re both trying to improve the editing experience, so we can learn form each other. Both are also experiments, there’s nothing that’s meant to be.

        I think it will need more time, but it depends on how much interest there is.

        • Sam Sidler 12:43 pm on November 10, 2013 Permalink | Log in to Reply

          CEUX has been put on indefinite hold due to lack of developer resources. For now, I wouldn’t worry about it, but I’ll let you know if that changes.

          I’d also say this project is so large it’ll need more time than the cycle to 3.9, but we’ll play it by ear. In general, I don’t assume any feature will make any specific release and just let them try for the “next release” after they’re ready.

    • Janneke Van Dorpe 12:21 pm on November 10, 2013 Permalink | Log in to Reply

      @hax Sorry for the late reply, can’t comment on the previous post anymore, but the next meeting will be Monday, 11 November, 16:00 UTC.

  • Matt Thomas 10:52 pm on November 8, 2013 Permalink
    Tags:   

    MP6 2.2 

    We’re back with another Friday update to MP6. We’ve had a flurry of improvements and bugfixes as we come down the home stretch.

    • Open Sans is now included in MP6 instead of linking to Google Fonts. (background and discussion)
    • Responsive fixes to the color scheme picker.
    • Hide 3rd-party adminbar elements at responsive sizes to prevent the adminbar from overflowing its container.
    • Improvements to sizing and spacing of responsive adminbar icons.
    • Updated Dashicons with new glyphs.
    • Fixes to Press This.
    • Icon fonts are no longer blurry in Firefox 25/Mac thanks to -moz-osx-font-smoothing.
    • New :focus style for Screen Options and Help tabs.
    • Added @-ms-viewport so IE10/11′s “snapped” mode takes advantage of responsive sizes.
    • Added a fix for the Windows Phone 8 viewport size bug.
    • Manymanymore bugfixes. (see full log)

    This edition of MP6 includes contributions from Shaun Andrews, Joen Asmussen, Mel Choyce, Kelly Dwan, Ben Dunkle, Helen Hou-Sandí, Till Krüss, and myself.

    Several of the team will be meeting up in-person and via Skype tomorrow to work on readying MP6 for its merge into core. Since this may be the last regular update to MP6 the plugin, now’s a good time to thank all of you who helped test and provide feedback on MP6 along the way, to everyone who’s contributed designs or code to MP6, and to @matt for jumpstarting the effort. We’ve come quite a way since March, and we couldn’t have done it without the mountain of help we received. So, thank you!

     

    • Matt Thomas 11:05 pm on November 8, 2013 Permalink | Log in to Reply

      We’ll hold our regular office hours Monday, November 11, 2013 18:00 UTC to discuss the state of the merge.

    • shaunandrews 11:34 pm on November 8, 2013 Permalink | Log in to Reply

      Thank you, MT! You’re the best!

    • OriginalEXE 12:04 am on November 9, 2013 Permalink | Log in to Reply

      There seems to be a small bug that is not happening when the plugin is deactivated.

      I am not sure if it was introduced with this latest update because I haven’t done this prior to updating just now.

      When I click on any select inside WordPress dashboard, top (About WordPress) menu pops out. I can see in elements inspector that #wp-admin-bar-wp-logo get’s class ‘hover’.

      Issue does not happen:
      -if I deactivate the plugin
      -if I disable javascript
      -if I change the browser (tested in ff)

      What I tried:
      -incognito mode with no extensions loaded
      -triggering any even that came to my mind on select (none of them caused this issue)

      My Chrome version is Version 30.0.1599.114 and I’m running latest Kubuntu. WordPress is updated to the latest stable release.

      Screenshot of an issue: http://pbrd.co/1c6OJlv (note that select works normally, for some reason Ksnapshot does not capture it, but imagine it’s opened :) )

      Let me know if there is anything else I can do to test this.

    • portfola 1:07 am on November 9, 2013 Permalink | Log in to Reply

      MP6 looks really, really great. Thanks for this.

    • Nick Halsey 5:58 am on November 9, 2013 Permalink | Log in to Reply

      Wow, @-ms-viewport makes a big difference (not sure why they don’t just go with the meta tag…). I’m making a ticket and patch to get that into the default themes.

      That should get into the customizer too (I suppose we can start ticketing & patching directly after the merge).

      • Matt Thomas 7:25 pm on November 9, 2013 Permalink | Log in to Reply

        One caveat to keep in mind with @-ms-viewport is that setting width: device-width will cause Windows Phone 8 devices to report that value in hardware pixels instead of CSS pixels. So a Lumia 920, for example, will respond with a device with of 768px, pretty much disabling responsive styles for that device.

        There are two workarounds: set a fixed width of 320px for @-ms-viewport, which will work around the bug in Windows Phone 8, but negatively affects IE 10/11 on Windows 8 because its “snapped” view is no longer responsive, but stuck at a fixed width of 320px.

        The second workaround is to set width: device-width in your CSS, then add a bit of JavaScript recommended by Microsoft. This solves the bug in Windows Phone 8 while still letting IE10 take full advantage of your responsive styles when in Snapped mode. This is the approach we took with MP6.

        Good news is that this bug’s been fixed in Windows Phone 8 Update 3. Since it’s going to take a while for that update to roll out to devices, though, I’d recommend implementing one of these workarounds for now.

        There are excellent write-ups of the issue and the solution at http://timkadlec.com/2013/01/windows-phone-8-and-device-width/ and http://mattstow.com/responsive-design-in-ie10-on-windows-phone-8.html.

        • Nick Halsey 11:27 pm on November 9, 2013 Permalink | Log in to Reply

          Thanks for the info!

          I think the WP8 Update 3 has actually gone out to most devices at this point. Mine did a few weeks ago, and it’s an HTC, not Nokia, and the Lumias tend to get the updates first. We’ll probably be fine by December, since I think most users probably apply the updates. I think we’ll probably avoid the js in the bundled themes (the css just got committed, I’m bring it up though).

          With Windows 8.1 & IE11, it’s pretty critical that the snapped view is fully responsive since it can now be anywhere between 320px and roughly 1600px wide, so `width: device-width` is the best solution.

          For reference, the bundled themes ticket is #25888.

          • Matt Thomas 11:33 pm on November 9, 2013 Permalink | Log in to Reply

            My AT&T Lumia 920 hasn’t been so lucky just yet :) but it may well be that it’s out by the time of 3.8′s release.

    • Matt Thomas 12:42 am on November 10, 2013 Permalink | Log in to Reply

      I’ve tagged an update, 2.2.1, reverting back to Google Webfonts as the default source for Open Sans, while we investigate the best way to serve appropriate subsets for extended character sets. 2.2 was causing some missing characters in Czech and other languages.

    • John Blackbourn (johnbillion) 3:09 am on November 12, 2013 Permalink | Log in to Reply

      I have a list of bugs relating to MP6, some of which are new and some of which have gotten forgotten along the long journey of MP6 :)

      Are we ready to open individual tickets for MP6 issues on core Trac yet, or should we hold off, or?…

    • Shea Bunge 8:25 am on November 12, 2013 Permalink | Log in to Reply

      When using the the visual editor with media buttons disabled, like this:

      wp_editor( $content, $editor_id, array( 'media-buttons' => false );

      The whole space on top of the editor where the tabs are and the media buttons would usually be is a blank white bar:

      This happens for both the TeenyMCE and TinyMCE editors when media buttons are disabled.

    • Anderton 1:00 am on November 18, 2013 Permalink | Log in to Reply

      Good thing inlcuding the fonts. One (other) issue with serving fonts via Google is that Google is blocked in some countries. So good call!

      • Anderton 1:04 am on November 18, 2013 Permalink | Log in to Reply

        Posted without saying that i know that issue have been discussed earlier (like in the thread mentioned above).

  • Sheri Bigelow (designsimply) 8:04 pm on October 24, 2013 Permalink
    Tags: ,   

    User Testing Widgets+MP6 v1 Layout 

    I’ve analyzed user testing for two videos shaunandrews kicked off for v1 of Widgets + MP6. The clips represent the main points of interest and user confusion from the tests and range from 12 to 49 seconds, so they should be quick and easy to watch.

    Expects clicking “Save” will close the widget:

    Troubles with drag and drop:

    • Windows 7 6.1
    • Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
    • 1920 x 1080

    Hover tip proves useful when figuring out the Meta widget:

    No trouble with drag and drop to add a widget:

    Expects widget to close after saving:

    • Windows Vista 6.0
    • Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
    • 1280 x 800

    If you’d like to see the full videos, you can download them here: Widgets+MP6 001, Widgets+MP6 002.

    Key Observations

    • One user spotted the hover tips and the other didn’t
    • Both users said they expected the widget to close after saving
    • May need to increase sensitivity of the widget drop area, check Chrome 30 on Win7 for issues

    Just because a couple users mention they’d like to see a widget area close after saving doesn’t necessarily mean you should do that. Additional testing in situations where someone is working for a longer time with one particular widget and may want to save periodically would be good. Adding some other visual indicator to show when saving is finished might be sufficient, as opposed to closing the widget on save.

     

    • Ulrich 8:24 pm on October 24, 2013 Permalink | Log in to Reply

      I think the problem with the saving of the widgets is that there is no confirmation anywhere that the widget is saved.

    • Archetyped 8:28 pm on October 24, 2013 Permalink | Log in to Reply

      Save on close

      Another way to pose this is: why shouldn’t the widget button close on save?

      Or perhaps the better question is: Are the actionable options provided to the user the right ones?

      If you break it down, the actions available to users are basically:

      • Edit widget settings
      • Close widget without making any further changes
      • Delete widget

      Therefore, perhaps more appropriate user actions would be:

      • Done — Save widget and close
      • Cancel — Close widget without saving changes
      • Delete — Completely remove widget

      In the current UI, you could make the argument that the widget should not close on save because the user may just want to save their progress as they continue to work on the widget’s settings.

      But why should the user have to do this? This is a burden that the machine should be offloading from the user.

      Post progress is saved automatically as you edit a post, why shouldn’t widgets have the same intelligence?

      With the machine saving your progress, the UI no longer needs a “save” button. You can focus on your work until you’re done. Then you just have to decide what your final action will be– save or cancel your changes (or remove widget entirely).

      • Jon Brown 12:02 am on October 25, 2013 Permalink | Log in to Reply

        WordPress saving changes is confusing enough as it is (metadata/featured image on posts. I wouldn’t want incremental changes to widgets saving prior to clicking save. Especially if the widget settings are versioned and undo-able.

        The buttons should read “close” and then upon making changes the button should change “save” then after saving change back to “close”. While there were changes to save a link for cancel changes and close would replace the current link for close next to delete.

        Personally I don’t want the widget closing on save, I just want a stronger confirmation that my changes were actually saved. I often want two widgets open at the same time so I can copy settings between the two.

      • designsimply 12:30 am on October 25, 2013 Permalink | Log in to Reply

        Take user suggestions like this one with a grain of salt. Sometimes people say one thing and then turn around and do another. So you have to look at a group of tests and find trends, and even then I think there’s a little magic that goes into interpreting the tests. :)

        Post progress is saved automatically as you edit a post, why shouldn’t widgets have the same intelligence?

        I imagine it’s because you don’t always want your widget changes live until they are finished—if you auto-saved, your widgets would be all skewampus on the front end during editing.

        I’m not advocating for one solution over another btw. I think it’d be cool to test the different scenarios more.

      • designsimply 12:32 am on October 25, 2013 Permalink | Log in to Reply

        Thanks for the feedback btw!

      • shaunandrews 2:34 am on October 25, 2013 Permalink | Log in to Reply

        Post progress is saved automatically as you edit a post, why shouldn’t widgets have the same intelligence?

        The key difference here is that the auto-save functionality that you see in the post editor is saving a revision. Widgets don’t have the concept of revisions. So, if widgets auto-saved, they’d be pushing out new versions of your widget to your live site. Not ideal.

        Now, one day we may have the ability to save revisions of widgets — then auto-save makes a lot of sense. However, you’d still want a “Save” button, or perhaps a “Publish” button, to push your changes to your site.

      • Archetyped 7:03 am on October 25, 2013 Permalink | Log in to Reply

        Yes, I understand the data infrastructure that allows posts to autosave progress as revisions, etc. My point is that users should not need to care about any of that.

        Obviously nothing should be live until the user commits those changes. Apologies if it seemed the opposite was implied. I’m also not saying autosave should be implemented without the necessary infrastructure changes, but that infrastructure should conform to user needs, not other way around.

        Take user suggestions like this one with a grain of salt.

        Indeed. My comments are not based on a single user’s comments but rather based on the usability issues observed working with clients over the years.

        • designsimply 2:13 pm on October 25, 2013 Permalink | Log in to Reply

          Apologies if it seemed the opposite was implied.

          No worries, I think it’s just a current technical limitation that widgets are confined to for this iteration. Frustrating :) so I think people like the ideas but are just explaining limitations.

          My comments are not based on a single user’s comments but rather based on the usability issues observed working with clients over the years.

          Awesome! i’m glad to read about your insights and that you’re participating.

    • shaunandrews 2:35 am on October 25, 2013 Permalink | Log in to Reply

      A huge thanks to @designsimply for going through these user tests and pulling out the highlights. Thanks, Sheri!

    • designsimply 9:06 pm on November 5, 2013 Permalink | Log in to Reply

      We reviewed all of the feedback from the comments on this post in our weekly THX chat today. RTL, back button, and escape to exit are going to be worked on. It’s too late in the project to change to an inline overlay layout for the details page, but anyone interested is encouraged to make a plugin showing how it could work if they would like to experiment with something like that. Feedback in yesterday’s core dev chat said that bulk edit wasn’t needed, and it’s not quite ready anyway so we took it out.The team talked about adding a trash icon to the main screen but decided against it because the delete in the modal is probably enough and users were able to find it pretty quickly in user testing.

      Thanks for all the feedback!

  • Sheri Bigelow (designsimply) 3:15 am on October 23, 2013 Permalink
    Tags: ,   

    THX38 0.7.1 User Testing 

    I put THX38 0.7.1 through some testing. Here are some clips showing the main points of interest. Most are around a minute or so in length, some are shorter.

    Accidentally clicks into the customizer and gets disoriented, first click on the “Customize” button doesn’t work (not sure why), thinks the magnifying glass hover icon indicates search:

    While the themes page is blazingly fast :) the customizer is slow:

    Suggests the “Delete Theme” button should be red all the time:

    Overlooks “Customize” button on the active theme:

    “Delete Theme” is a little hard to find for this user:

    Wishes clicking on the large screenshot in the modal would show a full view:

    Wants more screenshot detail:

    “Delete Theme” process not immediately visible, but found fairly easily:

    Theme description details are a little too technical, i.e. “post format-packed,” HTML, SEO:

    “Delete Theme” is easy:

    Keeps clicking the back button instead of the “x” in the modal and it disorients her a little:

    Tries right-clicking to delete:

    If you’d like to see the full videos, you can download them here: THX38 001, THX38 002, THX38 003, THX38 004, THX38 005.

    What would make finding really good themes easier? (survey question responses)

    • Tags or categories for subject matter, colors, or any number of style ideas and needs
    • Marketing maybe? Make it free?
    • If I were given an option of more than 20 themes to choose from, I would like to be able to choose by category, color theme, or complexity.
    • I can’t think of anything to really beat browsing. I mean, you could categorize them and even list them according to common uses (like Church) but I think I’d have to keep looking to find the perfect one. If you categorized based on HTML5 and all that, I think you’d lose a chunk of your user base (although having more technical categories for advanced users isn’t a bad idea at all).
    • The ability to search by genre. e.g. if I was a hairdresser key in the term hairdresser and get back a range of themes that could work for that business model. Complete with a choice of images would be fantastic.

    Key Observations

    • The magnifying glass/search icon was only mentioned by one user. The visibility icon could still be a good alternate because an eye symbol is often used for “view” online.
    • Themes load very fast! This makes it especially noticeable when the customizer loads slowly.
    • Viewing most themes on a brand new WordPress install is lackluster because there isn’t much data to customize per se.
    • Users had no trouble finding “Preview,” “Activate,” and “Delete Theme” in the modal when hover buttons were removed. Consider taking the hover buttons out. I know this adds one click to activating a theme (pushback if you feel strongly about it).
    • Noteworthy user suggestion:  make the “Delete Theme” button red all the time
    • Noteworthy user suggestion:  make it so you can click the screenshots in the modal to enlarge them (carousel style?) or make them zoomable

    All in all, the plugin is in really good shape. It’s fast! The “delete theme” link doesn’t get triggered accidentally but is still relatively easy to find. All of the bugs found via user testing were fixed in plugin version 0.8. If I could vote for two updates for v1, I would recommend: remove preview and activate hover buttons, change hover icon to a “view” symbol.

     

    • Lea Cohen 6:26 am on October 23, 2013 Permalink | Log in to Reply

      I have been following the posts and I love this plugin. If I could request one thing, I would appreciate RTL treatment :)
      I’ve never collaborated before in such things, so am not sure if and how I can help, but if there’s any way I can – I’ll be glad to.

      • Matías Ventura 4:50 pm on October 23, 2013 Permalink | Log in to Reply

        Good call — yes RTL will be added for sure. You are welcome to contribute anyway you can. We have chats on IRC on Tuesdays if you want to join. Otherwise you can keep participating on these threads.

        • Lea Cohen 12:32 pm on October 24, 2013 Permalink | Log in to Reply

          Could I help in implementing the RTL css in the plugin?

          • designsimply 8:15 pm on October 24, 2013 Permalink | Log in to Reply

            You could submit a patch. Do you know how to make one? I’d recommend starting with something very small and checking in with matveb to make sure you’re on the right track before doing more.

            • Lea Cohen 6:28 am on October 28, 2013 Permalink

              No, I’ve never submitted a patch. I agree with you that something very small would be a good start.

            • designsimply 9:04 pm on October 28, 2013 Permalink

              Do it! I found a basic tutorial that could help: http://www.doitwithwp.com/submit-patch-wordpress-core-beginners/ and you can ping me in #wordpress-core-plugins (or anyone in #wordpress) if you have questions.

            • Lea Cohen 6:21 am on November 4, 2013 Permalink

              Thank you so much, @designsimply. That’s a wonderful tutorial.

              I tried installing IRC on my computer, but we have a problem with open ports at my work. I’ll try contacting you from home, since I have a couple of questions. Thanks again for your support and encouragement!

    • biznis86 12:29 pm on October 23, 2013 Permalink | Log in to Reply

      I already suggested a concept without the popup modal, but haven’t received any response. Here is what I was thinking of:

      Also:

      • Move theme name above theme screenshot
      • Move all theme action buttons to the bottom of screenshot

      • designsimply 2:41 pm on October 23, 2013 Permalink | Log in to Reply

        The modal window is performing well in user testing. What problem are you trying to solve by trying to change it? I think one of the reasons for the theme name and action buttons being at the bottom of things is to put emphasis on the visuals, the screenshots specifically. Are your suggestions to move the theme name and action buttons a personal preference? Or how are you proposing that change will benefit users?

      • designsimply 3:30 pm on October 23, 2013 Permalink | Log in to Reply

        Btw, personal preferences are cool to bring up (you’re a user too!), but it would be awesome to include why you’d like to see things moved and how you think it will help along with the suggestions if you can.

        Aside: feedback on design (and reacting to it) is not as easy as it seems :) and my initial response sounded too defensive to me (maybe?) when I re-read it after posting. Anyway, I’m always looking for ways to get better at the feedback thing, both sides of it—just something that’s on my mind.

        • biznis86 3:56 pm on October 23, 2013 Permalink | Log in to Reply

          Sure, here are my arguments:

          Modals are not a good user experience, especially not on mobile devices. Inspiration behind my design comes from redesigned google image search, which was previously modal and is now similar to what I’ve posted. It works very well, at least for me. I really hate when links open in new window and I hate modals for the same reason. They add confusion and navigate user from their focus field.

          Theme name: there’s no reason to place it inside screenshot as it is not immediately visible to user. To make the name more obvious you need to add a background color to it and wrap everything with borders (which you did). But why? It would be simpler and nicer if you just added the name on top of screenshot, so the screenshot is cleaner and more obvious to user.

          Action buttons (activate, preview, delete, customize): It confuses users if they see buttons positioned differently on active theme and inactive themes and would be better to place them all at the bottom of screenshot. If you add theme name on top as previously suggested, you can also add “Active theme” text where theme name is currently positioned.

          I hope what I posted made any sense. As my company makes 90% of revenues from WP, it’s in my best interest to help as much as I can ;)

          • designsimply 4:13 pm on October 23, 2013 Permalink | Log in to Reply

            The modal isn’t used for mobile. The design is responsive. Try testing it out! Also, the modal isn’t done in a separate page load, so it’s super fast, which might help. Also, my role is more testing than design, so maybe one of the designers will chime in about modal vs. inline theme details.

            Ah, but I think the intention is to take away focus from the theme name and put it on the visual, the screenshot.

            It might be cool to experiment with user testing with the buttons in the detail view moved to the top. Are you interested in coding it up and running a test?

            • biznis86 4:26 pm on October 23, 2013 Permalink

              Do you need me to code our version of THX38 plugin or can we send over layered PSD file to save the dev work? Either way, no problem, first one will only take a bit more time.

              Otherwise, here is a fully sized screenshot of my previous image.

              I still believe, no matter how good modal is, it is never better than inline editing. Still, thank you for participating in this conversation – it just proves WP cares about users ;)

            • designsimply 4:31 pm on October 23, 2013 Permalink

              Do you need me to code our version of THX38 plugin or can we send over layered PSD file to save the dev work?

              For the button moving from the bottom to the top inside the modal? I’d suggest making a patch. I imagine you could do it with a bit of CSS. If you patch it, I’ll test it. Oh hey, I noticed the buttons are at the bottom of the description in your inline theme details mockup too! ;)

              it just proves WP cares about users

              True! so. true.

      • Matías Ventura 4:37 pm on October 23, 2013 Permalink | Log in to Reply

        One of the problems with the inline overlay is that we’ll run out of space quickly for the things we’d like to do, namely: more screenshots (gallery), showcase of real blogs using a theme, support forums, etc.

        Also, it doesn’t feel like the best use of space to duplicate the information (theme name + screenshots) on the same visual canvas.

        The overlay on mobile is a full screen page. Nothing indicates it’s a “modal” on that environment.

        Having said that, if anyone wants to code a version with the inline view and test it, I’d be happy to discuss it. I’m hesitant myself of modals, but in this case (with the url updating, arroy keys navigation, and being quite fast) think of it as a really quick “new page”. You can send people to themes.php#theme/twentyfourteen and it will open the theme for them, with all the details and actions at hand in a focused screen.

        Action buttons (activate, preview, delete, customize [...] you can also add “Active theme” text where theme name is currently positioned.

        We had this in one of the versions and eventually decided against it. The theme name is not that important and throws off the layout balance a bit when it is at the top.

        • designsimply 4:39 pm on October 23, 2013 Permalink | Log in to Reply

          themes.php#theme/twentyfourteen and it will open the theme for them

          I love that.

        • biznis86 5:09 pm on October 23, 2013 Permalink | Log in to Reply

          Not sure I agree that we’ll run out of space, since the modal is of the same size as inline overlay I suggested. More screenshots can be added the same way as to the modal. And user is never confused or disoriented. Although, some info is duplicated on the visual canvas, it follows user action, so there is no confusion about its purpose.

          One other benefit to inline overlay is also that you actually don’t need to “Add new” themes in a separate page. You could add new themes the same way with inline overlay at the end of themes list (with same Add New thumbnail you have now), so it would feel like you’re in control of your overall themes list and nothing would distract you from building it.

          You are spot on with URL updating and sending people to selected theme, but I’m not sure how many users will actually use this. This feature would only be usable if I could send my customers to their admin, where they could open/preview my custom theme (not yet installed) – if that is the case here, I’m really impressed and blown away really.

          I guess this is more my preference than a general opinion, so even if I feel really strongly about my case, I’ll stop here and won’t add more confusion to it.

      • Paal Joachim Romdahl 6:41 pm on October 23, 2013 Permalink | Log in to Reply

        Inline.

        • Keeps the connection with the other themes even when previewing.
        • It is easy to select another theme in the open preview area. One could also scroll through using the arrow keys having one theme after another open as a preview. Move the mouse inside the open preview and scroll to see additional screenshots and features. Or perhaps have small thumbnails below the main preview image. Clicking them opens into the main preview area. It seems like a good idea to code. To test out modal and inline methods.

    • Matías Ventura 4:25 pm on October 23, 2013 Permalink | Log in to Reply

      Thanks a lot for doing these.

      “Keeps clicking the back button instead of the “x” in the modal and it disorients her a little”.

      We can probably make it so the browsers back button takes you back to the grid view. I had it working with pushState but had to switch to normal hashes due to some troubles dealing with the .php extension of the themes page.

      • designsimply 4:33 pm on October 23, 2013 Permalink | Log in to Reply

        I thought you might appreciate the short video clip reporting format. :D

        Making the back button trigger the grid view would be awesome.

        Another idea: make the escape key exit the modal.

        • Matías Ventura 4:46 pm on October 23, 2013 Permalink | Log in to Reply

          Escape would be good, too.

        • Bryan Petty 6:56 pm on October 23, 2013 Permalink | Log in to Reply

          Both sound like good ideas, and escape is certainly standard.

          I think in general that all modal windows should probably be pushed onto the history stack honestly. Less of a specific theme issue here, and more of a general observation.

      • Andy Mercer 1:08 am on October 24, 2013 Permalink | Log in to Reply

        Having the back button return to the grid doesn’t necessarily make sense, but users (myself included) have been trained for decades that when you click something that makes the page change, the back button will undo it.

        Though it will probably add complexity to the code, I’d say it will be worth it just for the comfort factor, and for easing people in. It can always be removed down the line someday.

        • designsimply 9:16 pm on October 28, 2013 Permalink | Log in to Reply

          Clicking the back button could be perceived as broken if you’re in theme details view :) and it has to do with how the modal is setup. You can see it in the test above labeled “Keeps clicking the back button” where she clicks back and ends up on the main dashboard then has to navigate back to Appearance > Themes.

    • Archetyped 6:38 pm on October 23, 2013 Permalink | Log in to Reply

      Some thoughts/suggestions based on the videos

      Delete Theme

      • Delete option in grid view would be nice so that users can easily delete themes without having to go into a modal for every single theme. Using a simple trash can icon would be pretty much universally understood
      • Then, replace the “delete” button in the modal with the same trash can icon to standardize the UI in both views. This will make it less obtrusive while still easy to find when desired.

      View Icon

      The “eye” icon is scary and doesn’t really communicate “more detail” as well as it communicates “Eye of Ra”. The magnifying glass icon is a better direction and the functionality could be even better communicated by adding a “+” in the magnifying glass, which would give us the standard “zoom in” icon. It would communicate “zoom in for more detail” better than the eye.

      Modal

      The responsive modal works well. Normally a modal is a problem on mobile because they are generally not responsive so you have wasted space and positioning/scaling issues when the user interacts with the page. Here the modal is quite usable on mobile with large buttons and a simple layout.

      • designsimply 7:57 pm on October 23, 2013 Permalink | Log in to Reply

        Thanks for watching the videos!

        Two of the tests experimented with taking out all of the hover buttons all together. Even though a couple testers commented that the “delete theme” link is a little bit hard to find at first, most of them found it within a few seconds of looking around. Plus, it shouldn’t be too terribly easy to delete a theme, so I think the tests show it’s in line with the designers’ intention.

        It’s good to hear specific feedback about the icon. I never thought of the eye as scary! :)

        Cool feedback on the responsive design. I agree.

        • landwire 9:34 am on October 24, 2013 Permalink | Log in to Reply

          Delete:
          I also think there should be a “Delete” option in the grid view. Especially if there is another window popping up saying “Do you really want to delete XXXX theme”. So it cannot really happen accidental and that is the main concern I would think.

          • Matías Ventura 1:43 pm on October 24, 2013 Permalink | Log in to Reply

            I don’t think the frequency of deleting themes warrants the placement on the front — specially with the goal being to streamline the interface weight.

            We did play with a “bulk edit” mode in which you get an “x” to delete themes quickly. We couldn’t find an elegant way to invoke it, though. Still totally open to improving this in the future. Not sure it’s an area that warrants a lot of attention at this stage.

            https://cloudup.com/cdC2ME6Y1oK

            • Ipstenu (Mika Epstein) 2:04 pm on October 24, 2013 Permalink

              As someone who handles a lot of cases where people download a bajillion themes (seriously I deleted 30 off someone’s site this week) testing them out, and then never upgrade, a bulk delete option really is needed. Its VERY common for newer users to do that, and every time I give a session in how to use WP to the non-Tech people, I get asked ‘Why can’t I bulk delete?’

              I get why it’s not there now, but it needs to stay on the radar please :)

            • Matías Ventura 2:53 pm on October 24, 2013 Permalink

              Hah, thanks for the feedback from the front! It’s definitely on the radar, and we may very well get to it soon. Open to ideas about how to invoke the edit mode, if possible without another button next to “add new”. :)

        • Archetyped 8:09 pm on October 24, 2013 Permalink | Log in to Reply

          Why wouldn’t we want theme deletion to be easy? It’s an action that a user would feasibly want to do, so why discourage the it? There’s nothing inherently “bad” about deleting a theme.

          As theme deletion is destructive in nature, a confirmation of the action is important, which the popup handles. There’s no other reason to make it any more difficult than that.

          A trash can icon could be unobtrusive enough to not distract the user (like an always-on hot red button might), but would still be recognizable enough. In fact, after ages of UI conditioning, you could reason that a trash can icon is what users would actually be looking for when they want to delete a theme.

          Having to read the text of every button slows the user down from performing the desired action. While the a red-colored button may help to draw the eye to the button, it does nothing in terms of accessibility (e.g. color-blind users).

          • designsimply 8:17 pm on October 24, 2013 Permalink | Log in to Reply

            Looks like we’re going to try some bulk delete options, and I’m sure we’ll discuss a trash icon option in our next office hours. Thanks for the feedback!

  • shaunandrews 2:07 pm on October 22, 2013 Permalink
    Tags:   

    Widgets Update 

    Howdy!

    The widgets team has been working hard! We’ve spent some time working with (and joining) the MP6 team to get a redesigned widgets screen into the latest version of MP6. If you haven’t seen it yet, download (or update) MP6, and you’ll get this beauty:

    We’ve also created a new plugin named Widget Area Chooser, which lets you click to add a widget to any of your sidebars:

    We’ve also made some great progress on the Widget Customizer plugin, which lets you manage your widgets from within the customizer:

    How can you help?
    This week, we’ll be focusing on getting the Widget Customizer plugin updated to let you add new widgets. If you want to join in, you can head over to GitHub and submit some patches, do some testing and add an issue, or just drop your ideas/thoughts. Or, you can just post a comment below and we’ll add you to our group Skype chat.

    Also, we’d love some code review on the Widget Area Chooser plugin.

    We’ll be meeting next week in #wordpress-ui at our normal time, October 28 @ 20:00 UTC.

     

    • Michael Arestad 2:08 pm on October 22, 2013 Permalink | Log in to Reply

      Group Skype chat. michael.arestad

    • jeffr0 8:16 pm on October 22, 2013 Permalink | Log in to Reply

      I’ve been using the new widget screens via MP6 and they are an improvement over what existed there. Out of curiosity knowing that you’ve been working on this area of the back-end for awhile, can you fill me in on why the performance of this particular page is so bad? That is, there appears to be a delay in doing anything on the widget management page. Click on a sidebar arrow and there’s a delay, click it again, another delay, click a widget to drag it to another sidebar and the delay/responsiveness is terrible.

      What is it that causes such a delay between me clicking on something and the reaction?

    • Andy Mercer 1:10 am on October 23, 2013 Permalink | Log in to Reply

      Looking great! I think I may have found a slight bug in the sizing. I’m running Firefox 24 on Windows 7 (classic theme; I think that makes a difference for the position bars). When playing around with sizing, I found that in what looks like the smallest mobile version, a slider bar is a bit too far to the right. It goes off the screen. Link to screenshot with the area in question circled: http://i210.photobucket.com/albums/bb80/Kelderic/Screen02_zpsdb08cf0b.png

← 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