WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • designsimply 11:09 pm on March 5, 2014 Permalink
    Tags: ,   

    WordPress Front-end Editor — Usability Test 2 

    I did a usability test on the WordPress Front-end Editor 0.8.5 plugin with the Twenty Thirteen theme on WordPress r27243.

    Summary

    • No trouble finding the Edit link inline, editing a title, or adding a paragraph
    • Lots of difficulty saving
    • Difficulty adding a new post
    • Featured image area is not clear
    • Back button results in lost edits
    • Difficulty adding a link (back-end editor)
    • Difficulty adding an image (back-end editor)

    You can download the full video here: deaea9a3.mp4.

    Points of Confusion

    Difficulty saving (Length: 1:56)

    Difficulty adding a new post on the front end (Length: 0:42)

    Featured image area looks like a place you can “write something” (Length: 0:07)

    Back button exits the editor without saving and without a prompt (Length: 0:06)

    See more highlight reels after the jump.

     
    • Janneke Van Dorpe 10:12 am on March 6, 2014 Permalink | Log in to Reply

      I’ll leave several comments on the different topics today, don’t have time to post them all at once. :)

      The onbeforeunload alert (when navigating away from the page) can only be done with a browser alert, it’s not possible to style it or have a save button there. What could be done is intercept when a user clicks on a link that will trigger this event and show a custom modal with a save button, but not when navigating away with the browser (close, previous, next, refresh etc.). But then in half of the cases you’ll still have the browser alert.

      • Janneke Van Dorpe 10:14 am on March 6, 2014 Permalink | Log in to Reply

        So “Prompt the user to save or cancel if the back button is clicked.” is technically not possible (as fas as I know). @azaozz?

        • Andrew Ozz 7:37 pm on March 6, 2014 Permalink | Log in to Reply

          Right. There is a “special” event that is used in these cases, however it always displays a browser provided dialog. In WebKit and IE it is possible to add some text (but not html) to that dialog. FIrefox doesn’t show the added text.

          So, the only thing possible is to trigger the dialog that asks the user to confirm leaving the page. We can add some text to it that will be shown in some browsers, but cannot add html, buttons, etc.

          It is possible to open a modal “under” that dialog so in case the user clicks “Stay on this page”, they will see our modal with Save and Cancel. Not sure if that’s the best UX though.

          • Janneke Van Dorpe 5:17 pm on March 10, 2014 Permalink | Log in to Reply

            Having two dialogs overlapping is not ideal… It looks like it’s going to stay like this, we should just find a way to highlight the save button.

    • Janneke Van Dorpe 10:50 pm on March 10, 2014 Permalink | Log in to Reply

      I still really think “Save” makes more sense for users than “Update” in the front end editor context. I think it would make it easier for them to find.

      Not sure if being in a front-end editor makes a difference. @melchoyce, chat do you think about this?

    • Janneke Van Dorpe 10:52 pm on March 10, 2014 Permalink | Log in to Reply

      Changing the colour of the update button would mean diverging from the main styles. I wouldn’t do that. Adding a pointer should do the job. Once the user knows where the button is, they won’t forget.

    • Janneke Van Dorpe 10:59 pm on March 10, 2014 Permalink | Log in to Reply

      Once the inline Edit link is clicked, replace it with links for Cancel and Save

      Do you mean the inline links in the theme? Unfortunately they need to stay about the same size to prevent breaking the theme.

  • Chris Reynolds 8:48 pm on March 3, 2014 Permalink
    Tags:   

    AH-O₂ Update — 3 March, 2014 

    Help Overview refactoring
    @brainfork has been ill and was unable to work on this this week. @jazzs3quence created tickets for some of the issues that were reported in https://github.com/jazzsequence/WordPress-Admin-Help/issues/50 many of which were things that @brainfork was planning to work on. See:

    https://github.com/jazzsequence/WordPress-Admin-Help/issues/55

    https://github.com/jazzsequence/WordPress-Admin-Help/issues/57

    https://github.com/jazzsequence/WordPress-Admin-Help/issues/47

    https://github.com/jazzsequence/WordPress-Admin-Help/issues/46

    Tooltips
    @clorith is going to work on refactoring the tooltip structure a bit to make it more flexible for devs and give us more options for tooltip styles.
    @trishasalas will be working on some new styles for the tooltips
    Between the two of them, we’re hoping to nail:

    https://github.com/jazzsequence/WordPress-Admin-Help/issues/58

    https://github.com/jazzsequence/WordPress-Admin-Help/issues/56

    https://github.com/jazzsequence/WordPress-Admin-Help/issues/45

    Admin Help Inventory spreadsheet
    @ubernaut has added tooltip locations to the Pages admin pages in the spreadsheet we’re using to keep track of such things. He will work on adding the actual TinyMCE formatting buttons this week.

    Target Date
    We’ve set a tentative target date for April 1. This will give us time to test the plugin and fix any issues before the discussion begins about WordPress 4.0 feature plugins.

    Help wanted!
    To meet this target, we need help:

    • adding tooltips — though this process may be changing, the changes should make things easier and we can help with the transition — mostly we need new tooltips to be added (or at least written) for all the elements (that have not been added already) in the spreadsheet (or for anything else that’s missing that isn’t included)
    • testers — we’d love to have more testers look at this and let us know if/when they find any issues

    If either of these things sound like ways in which you could contribute, you can let us know in the Google Group, in the comments of this post, or in our Monday meeting.

    Our next meeting is next Monday 18:30UTC.

     
    • Sjoerd Boerrigter 9:13 pm on March 3, 2014 Permalink | Log in to Reply

      Hi Chris,

      I see you guys can use some help to test the new help section of WordPress.

      What can I do to help out? Can I just download the plugin from Github and test away? Where would you like me to leave my testing feedback? Should I create separate issues for everything I find in Github or is there another way to report bugs and suggestions?

      • Chris Reynolds 9:56 pm on March 3, 2014 Permalink | Log in to Reply

        For the latest, bleeding edge version, you can just download from GitHub. We update the WordPress.org version once a week, so it’s a little bit behind the GitHub version (but would be easier to update if you don’t use Git — if you do, you can clone it and then you’ll see when there have been updates made).

        Should I create separate issues for everything I find in Github or is there another way to report bugs and suggestions?

        Yes, we’re using GitHub’s issue tracker for everything. Try to be as specific as possible if you’re reporting an issue and screenshots help. :)

        If it’s just general feedback/comments/suggestions either posting it here or in our Google Group is probably the best way to communicate that (trying to keep the issues/tickets for actionable items that can be closed when they are resolved in the code).

        I will say that if you are testing and have WP_DEBUG set to true and you notice a bunch of errors, to refer to these tickets for info on that:
        https://github.com/jazzsequence/WordPress-Admin-Help/issues/20
        https://github.com/jazzsequence/WordPress-Admin-Help/issues/21

        There’s a reason and hopefully if/when we get merged into core it will get taken care of.

        All that said, THANKS! :)

  • designsimply 8:40 pm on February 27, 2014 Permalink
    Tags: ,   

    WordPress Front-end Editor — Usability Test 1 

    I did a usability test on the WordPress Front-end Editor 0.8.4 plugin with the Twenty Twelve theme on WordPress r27162.

    Summary

    • Misses the “Edit Post” link in the toolbar completely but finds the inline “Edit” link
    • Struggles to figure out how to save changes
    • Secondary editor functions are hard to find
    • Unable to find the tag icon in the toolbar
    • No trouble adding or modifying content and links

    This is a great first look, so I would recommend watching the entire video through. (Length: 8:45)

    You can download the full video: c41ea9a3.mp4.

    See highlight reels after the jump.

     
    • Janneke Van Dorpe 8:43 pm on February 27, 2014 Permalink | Log in to Reply

      Thanks a lot for doing this! Watching everything right now.

    • Rouven Hurling 9:27 pm on February 27, 2014 Permalink | Log in to Reply

      we could maybe use the pointer, that is used for new features, on first activation of the front-end editor to highlight editing options and saves?

    • Janneke Van Dorpe 9:29 pm on February 27, 2014 Permalink | Log in to Reply

      • I guess having only one post on the home page of the website makes it look a bit like that’s the post’s page. So you don’t immediately get that you have to go to the post’s page to see the ‘edit’ link in the toolbar. But as we can see, if the theme adds edit links to posts, it’s easy to discover. I don’t think you should remove it, most themes seem to have it.
      • It’s pretty frustrating not to find the save button! Not sure how we can make this more obvious, but a dismissible pointer might help. Having a save button in the onbeforeunload alert is definitely a good suggestion. Actually the exact same thing is used on the back-end, so there’s room for improvement there as well.
      • Why do you think the secondary buttons are hard to find? I thought it was found quite quickly. On the back-end this would be equally hard; you’d have to toggle the kitchen sink.
      • Not sure how to make tagging easier. If they had gone over the toolbar buttons, they would have found it. They would probably have had the same reflex to add a hash in other environments.
      • I agree on the feature image area, but something needs to be there. A tooltip saying ‘Add featured image’ to inform the user would be helpful indeed.
      • While the post is saving, the update button is disabled. After the page is reloaded, a message shows up that the post has been saved successfully. I think that should be enough?
      • The button reads ‘Update’ because the one on the back-end reads the same. I think things like this should be the same on the front- and back-end.
      • The kitchen sink button is on the left because that way it stays in the same place and you don’t have to move your mouse to toggle back.
      • Sheri Bigelow (designsimply) 8:14 pm on February 28, 2014 Permalink | Log in to Reply

        Great notes!!

        Why do you think the secondary buttons are hard to find?

        It looked to me like the user hesitated and had to really look around before they spotted the toggle icon. I think you’re right that “hard to find” was a little too strong of a description in this case though. Something like “had to hunt for the secondary buttons” would’ve been more accurate. It’s worth more testing to see if it shows up as a trend.

        I agree on the feature image area, but something needs to be there. A tooltip saying ‘Add featured image’ to inform the user would be helpful indeed.

        What about adding a text label right inside the dashed area? Is that area supposed to be a drag and drop zone? Also, why does it have a pencil icon? An image or gear icon would be more accurate because a pencil usually indicates something related to writing, not images.

        While the post is saving, the update button is disabled. After the page is reloaded, a message shows up that the post has been saved successfully. I think that should be enough?

        Let’s watch out for trends on this one — if users keep wondering if they’ve saved or not in other tests, then it would be worth re-visiting.

        The button reads ‘Update’ because the one on the back-end reads the same. I think things like this should be the same on the front- and back-end.

        While it’s a good idea to be consistent, don’t do it at the cost of usability. If users look past “Update” while saying aloud they can’t find the “Save” button, as they did in this first test, then consider changing it. It may turn out in the end that “Update” is just fine. Let’s keep an eye on it.

        Whatever the button label, I think a different color for the button could also help. It’s pretty hard to ignore orange. :) Might be worth testing since that particular button is a pretty important action and shouldn’t be allowed to be missed if we can help that.

        The kitchen sink button is on the left because that way it stays in the same place and you don’t have to move your mouse to toggle back.

        I suggest testing it on the right to see if users have trouble with it there. If they do, then it would be a good confirmation that the best place for it is on the left.

        • Janneke Van Dorpe 5:58 pm on March 10, 2014 Permalink | Log in to Reply

          Also, why does it have a pencil icon?

          I changed it to a + icon now. I’ll probably add a label to it, or something similar, but I’ll do that together with some other updates.

      • Dan 5:20 pm on March 4, 2014 Permalink | Log in to Reply

        It’s pretty frustrating not to find the save button!

        It looked to me like he thought a save button might be at the bottom of the post. He also hadn’t discovered the toolbar yet which was interesting since he hit the ‘Edit’ link instead of using the toolbar button.

    • Janneke Van Dorpe 9:38 pm on February 27, 2014 Permalink | Log in to Reply

      I’d definitely like to see additional tests. If not now, then maybe in a few weeks as things get better. I’ll think about other tasks that might be interesting.

    • Janneke Van Dorpe 9:51 pm on February 27, 2014 Permalink | Log in to Reply

      Are you sure the link added in the media modal was not an image? Not sure why a preview shows up then. In any case, this would be a core bug.

  • Janneke Van Dorpe 8:01 pm on February 26, 2014 Permalink
    Tags:   

    Front-end Editor Meeting 25 February 

    With @avryl (me), @kraftbj, @samuelsidler, @ubernaut. Log.

    Not much to report this time since I’ve been away since the last meeting. Everything has been moved to GitHub, so new tickets should now be added there. I also added Grunt with jshint. @samuelsidler asked @designsimply to do some user tests. Exciting! :)

    The next meeting will be Tuesday, 4 March 2014, 17:00 UTC, hopefully with a lot of updates to share.

     
  • Chris Reynolds 6:29 pm on February 25, 2014 Permalink
    Tags:   

    AH-O₂ Update — 24 February, 2014 

    Cross-posted from make/docs

    Help Overview refactoring
    @brainfork was going to work on this but didn’t have the time. He was able to review the code though, but no progress has been made. @trishasalas has stepped up to help out with this. They will be taking a look at the issues reported in this ticket (moving help footer over) as well as this ticket (text next to dashicons are not aligned vertically) and creating new tickets for any other issues that come up.

    Tooltip hover delay
    @clorith reported that the tooltips were sometimes taking the focus away from the actual item. he then submitted a pull request which has been merged that increases the hover delay. This will be included in the next version in the WordPress.org repository.

    Tooltip arrow positioning
    …is still an issue for some tooltips which is mostly to do with not having good selectors to work with (not everything in the WordPress admin has IDs or classes associated with them). @trishasalas is going to look at this, but since this could be done completely differently in core by just adding more specific ids to the things that need tooltips, I’ve given it a lower priority. @trishasalas may try to do at least one admin page, though, as a proof-of-concept.

    Versioning
    Because I can’t consider this plugin “done” (and therefore 1.0) until tooltips are on every page, and because we’re going to run out of digits if we keep going at the 0.x rate for every weekly update, and because looking at a plugin in the repo that has a 0.x version looks less like a completed entity than a 1.x release, we’ve agreed to tweak how the versioning is handled a bit to make better use of minor point release versions. Updates with minor fixes or new tooltips will be considered a 0.0.x release, more significant changes will be a 0.x release. There was some discussion about this that can be read in the logs, but the main reasoning is that it seems misleading to call something a 1.0 if it’s still incomplete (in this case, missing tooltips) and we’d be at a 1.0 in 4 weeks at our current rate.

    Admin Help Inventory spreadsheet
    @ubernaut will work on tackling the Pages…pages next in the spreadsheet having just finished filling out the Network Admin screens.

    @nikv has started work on adding tooltips to the comments page but that has not been merged into the plugin yet.

    Tooltips on Mobile
    We’ve decided to go with the tap-and-hold interaction for tooltips on mobile devices. This takes a lower priority to getting the tooltips in and no work has been done on it yet, but if someone would like to tackle it, let us know by commenting in the open ticket here: https://github.com/jazzsequence/WordPress-Admin-Help/issues/32

    The logging bot was having a fit, so here’s my copy of the logs from the meeting (the first 15 minutes are cut off, unfortunately): http://s3q.us/log/ah-o2-log-2014-02-24.html

     
  • designsimply 2:08 pm on February 20, 2014 Permalink
    Tags: ,   

    I’ve tested the Widget Customizer 0.14 plugin with the Twenty Fourteen theme on WordPress r27060.

    Summary

    • No trouble adding, rearranging, or removing widgets
    • Widgets can be tough to spot if they are added “below the fold”
    • Widgets that require extra prep are easily dismissed

    (More …)

     
  • Janneke Van Dorpe 9:49 pm on February 18, 2014 Permalink
    Tags:   

    Front-end Editor Meeting 18 February 

    With @avryl (me), @kraftbj, @samuelsidler, @melchoyce and @ubernaut. Log.

    Download the WordPress Front-end Editor plugin.

    • We decided to move the development to git and GitHub, hopefully that makes it easier for people to contribute! @kraftbj will port over the existing Trac tickets and then we’ll use GitHub as our bug tracker.
    • Not many updates this week, I’ve only been working on post locking and a responsive admin bar.

    Screen Shot 2014-02-18 at 16.29.14

     
  • Chris Reynolds 10:28 pm on February 17, 2014 Permalink
    Tags:   

    AH-O₂ Update — 17 February, 2014 

    We’ll be releasing 0.7 this week. New in this update are initial tooltips for the sidebar menu items & tooltips on the Users pages.

    @brainfork Will be working on reworking the help overviews. This partially came out of this ticket, where it was determined that a restructure of how the overviews are marked up may be necessary.

    @ubernaut will continue to work on the spreadsheet with a focus on identifying areas for new tooltips. This makes it easier when adding the tooltips in the plugin to know where best to place them. The next area for focus for the spreadsheet will be the Network Admin screens. I recently opened the document up to anyone with a link to make it easier for people to jump in, flesh out areas that are bare, or claim admin pages to add tooltips to without requiring an owner to invite them to be able to edit the spreadsheet.

    @nikv has volunteered to help out with adding tooltips also.

    I’ve updated the tooltip documentation somewhat to add some additional details/guidance for adding new tooltips. Feedback (or edits) are welcome.

    https://github.com/jazzsequence/WordPress-Admin-Help/wiki/Help-Tooltips

    One thing that wasn’t discussed this week (although there’s a ticket) is the fact that the arrow location for some tooltips is pointing to the wrong place. My suspicion is that this is largely a CSS issue (or an issue that can be solved with CSS) and anyone who wants to jump in and take a stab at that is welcome. There are a variety of places where this is the case and may need to be styled individually. The main issue is a lack of specific IDs/classes to hook the tooltips onto, which could be conceivably solved in core by adding specific classes/ids to those elements.

    Our next meeting will be next Monday 18:30UTC

    I’d love to hear what kinds of thoughts/suggestions you guys have to the overall UX of the plugin/feature. At this point, things are pretty set and we’re mostly working on adding more content but I’m eager to know if there are things that we could be doing different/better.

     
  • Janneke Van Dorpe 11:56 pm on February 11, 2014 Permalink
    Tags:   

    Front-end Editor Meeting 11 February 

    It’s been three weeks since the last update, so I’ll quickly go over some of the things that I added to the plugin since then. @samuelsidler asked me to post a bit more regularly, so I’ll publish an update after every meeting on Tuesday. Here are the logs for last week’s meeting and today’s. The next meeting will be Tuesday, 18 February 2014, 17:00 UTC in #wordpress-ui.

    • Changing the format of a post changes the relevant post and body classes, so you can now preview the theme’s styles for that format. I’d like to do something similar for categories and tags. See #2116.
    • The page now refreshes when updating the post and the messages you get at the back-end will appear. Some of these should probably be changed to make sense on the front-end though. These messages fade out after 5 seconds. I’ve used the same styles that are used on the back-end, because they seems to stand out quite well, and it’s consistent.
    • The location of the title is detected better, it should now work with most themes.
    • In the ‘meta’ modal, all the meta boxes are now listed under each other to fill up empty space. I left the shortcuts in the sidebar though, and shortcuts to the category and tag section in the admin bar. While this layout works great on mobile, it’s still a bit empty on wide screens. One solution may be columns, another making the modal smaller in width.
    • I try to give inline access to the modal based on commonly used classes/attributes/tags. E.g. an HTML time tag or published class links to the date and time section, a tag and category rel attribute link to their sections.
    • TinyMCE now comes with tooltips and they’ve been added to the back-end, so I’ve added them to the front-end as well. Buttons outside TinyMCE also have tooltips to have some consistency.
    • Autosave is now implemented (both to the browser and server), but this is done by modifying the core files and including them in the plugin. Autosave.js will need to be updated in core so it is flexible enough to use on the front-end.
    • Going to the revisions browser from the front-end and restoring one will now bring you back to the front-end.

    Screen Shot 2014-02-11 at 15.04.02

    Coming soon:

    • Post locking.
    • TinyMCE modals styled just like the media and meta modal. See also #26952 for core.
    • A link plugin like the one on the back-end.
    • A working adminbar for small screens.

    If you’d like to help, you could join our Skype chat by adding jannekevandorpe and mentioning the Front-end Editor and taking a look at the tickets listed on the plugins Trac.

     
    • naderc 10:48 pm on February 16, 2014 Permalink | Log in to Reply

      The front end editor sounds very promising! What would be the best way to get involved, considering I have a wordpress account and published 2 plugins. Anything else I need? Can anyone join?

    • Janneke Van Dorpe 11:12 pm on February 16, 2014 Permalink | Log in to Reply

      Of course! Everyone is welcome to help. Probably the best way to get involved is to join our Skype chat (add jannekevandorpe) or attend the meeting this Tuesday (see post).

    • venkmanuk 10:45 pm on February 17, 2014 Permalink | Log in to Reply

      This continues to be some great work – thanks!

      Two things / ideas:

      It’s probably been mentioned but in case it hasn’t – it would be amazing if this also allowed the user to edit custom fields on the front end. In real-life most of the sites I build use ACF to customize the way content is displayed. Even if the functionality was as simple as text editing the custom fields – and not creating / managing them – it would be amazing.

      I have been allowing my colleagues to use this editor on a website and got some interesting feedback. The site uses a WP Edit button (edit_post_link) in the page to activate the editor, and in testing the user assumed clicking this again would save the page and close the editor. A fair assumption, i think. It would be great if clicking it a second time would save the front end edits and close the front end editor.

      Either of these possible?

      • Janneke Van Dorpe 9:36 am on February 18, 2014 Permalink | Log in to Reply

        Custom fields are editable under ‘More options’, but not inline. Would be interesting, but right now there are more important things to focus on.

        Doesn’t that button say ‘Cancel’? I wouldn’t assume it would save the page. But it’s worth thinking about whether this should exit the editor or save the content.

    • venkmanuk 11:35 pm on February 18, 2014 Permalink | Log in to Reply

      well it does say cancel – if you haven’t hidden the text and replaced it with an editor icon. that was why I was looking for a in-editor class on the edit button too – to style it differently when it’s been clicked.

      it’s interesting because maybe we’re looking at this differently. I’m thinking a front-end editor could function as an inline editor with a supporting toolkit at the top there. Without support for standard tools within the page template itself it’s really dependent on using the toolbar only huh…

      • venkmanuk 11:39 pm on February 18, 2014 Permalink | Log in to Reply

        • Janneke Van Dorpe 8:25 pm on February 20, 2014 Permalink | Log in to Reply

          Actually there are classes. You can use the body or past class for these things. Note that this class might change in the future though. Thanks for pointing this out, I’ll see if there’s a better way to avoid this problem.

          Could you elaborate on the second paragraph?

  • Chris Reynolds 8:47 pm on February 10, 2014 Permalink
    Tags:   

    AH-O₂ Update — 10 February 2014 

    (cross-posted from docs, sorry for any duplicates)

    a11y and title attributes

    It was discussed last week at the meeting — and subsequently added to the plugin — that we would take the title attributes of linked elements that had them by default, so that in the future, adding tooltips to these things could be handled the same way they already were. However, since @grahamarmfield‘s extensive review indicated that this may be a problem for screen readers, as well as the fact that core will be removing them, this behavior has been removed and will no longer be present in the next (or future) iteration.

    Tooltip pointer positioning

    There are some tooltips that have somewhat “iffy” pointer positions. There are various reasons for this, but the biggest one is specificity. If we were editing core, we could add our own classes or IDs and then target things specifically, then add a tooltip to those handles. Since we aren’t, and there are some elements that don’t have their own specific wrappers (for example, some column headings), we just do the best we can. (See https://github.com/jazzsequence/WordPress-Admin-Help/issues/45 for some examples). We may come back to these later and add CSS to the pointers so they can be moved specifically for those tooltips. Moving forward, if there’s a commit adding a tooltip where this is the case, we’ll be tagging this ticket so we can keep a general record of the tooltips that are having this issue.

    What we’re working on

    We are primarily focusing on the task of adding tooltips to the plugin at this point.

    @brainfork will also be looking into adding tooltips to the sidebar menu items using a global tooltip doc and js file.

    @zoerooney and @ubernaut will be working on updating the admin pages spreadsheet with a particular focus on identifying areas for tooltips. I’ve made this editable to anyone with a link to give more people an opportunity to contribute to this document (which hopefully won’t be a problem).

    Testers and contributors are welcome — report any issues here: https://github.com/jazzsequence/WordPress-Admin-Help/issues?state=open

    Pull requests are also appreciated!

    As a reminder, our next meeting will be next Monday 18:30UTC.

     
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