WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Tagged: front-end editor Toggle Comment Threads | Keyboard Shortcuts

  • Janneke Van Dorpe 3:57 am on September 1, 2014 Permalink | Log in to leave a Comment
    Tags: front-end editor   

    The next Front-end Editor meeting will be September 2, 2014 17:00 UTC! Take a look at the project on GitHub to get a good idea of what current state is. There are quite a few big changes. It only works with WordPress 4.0 and the plugin in the .org repo is not up-to-date. If you’d like to get involved, make sure to attend. I’m not going to continue the Skype group, we’ll just use IRC, GitHub and these P2 posts. As soon as WordPress 4.0 is released, I’ll release a 1.0 beta and publish a post about all the changes.

     
  • Janneke Van Dorpe 11:47 pm on June 17, 2014 Permalink
    Tags: front-end editor   

    Hi everyone!

    There haven’t been any meetings for the front-end editor in a while, and since I’m working on the GSoC project right now I won’t actively hold any meetings until that’s finished. If anyone would like discuss something or work on the project though, feel free to continue them. Most of the time I’ll be in #wordpress-ui too. (My username is avryl.)

    A lot of things that I’m working on can also be used for the front-end editor, so I might merge in some things along the way.

     
  • Janneke Van Dorpe 8:08 pm on April 23, 2014 Permalink
    Tags: front-end editor   

    Front-end Editor Meeting 22 April 

    Yesterday we had a quiet meeting, so there’s not much to report.

    I’ve removed compatibility with WordPress 3.8 so it’s easier to develop, and the plugin now loads the TinyMCE scripts from core, which should make the editor load faster. I also restyled the admin bar used in the editor so that it looks like the back-end editor. That way the buttons have styles for every state, and it’s hopefully easier to distinguish read and writing mode.

    More updates next week! :)

    fee-2014-04-23

     

     

     
    • radiomint 2:38 pm on May 15, 2014 Permalink | Log in to Reply

      Hi, I’m new to the Forum. and i need to suggest a feature request / a small implementation to the back end editor. It is small but would benefit a lot of people. :) So how or where can i go and do that?

  • Janneke Van Dorpe 7:20 am on April 19, 2014 Permalink
    Tags: front-end editor   

    I’ve been away without internet for the last two weeks, but now I’m back, so the next front-end editor meeting will be Tuesday, 22 April 2014, 17:00 UTC. In the meantime I’ll update the plugin a bit for 3.9 and remove 3.8 compatibility so it’s easier to work with.

     
  • Janneke Van Dorpe 8:08 pm on March 10, 2014 Permalink
    Tags: front-end editor   

    Front-end Editor Meeting 4 March 

    With @avryl (me), @azaozz, @hugobaeta, @kraftbj, @melchoyce, @mrroundhill, @rhurling, @samuelsidler, @ubernaut. Log.

    Links: Front-end Editor plugin, GitHub.

    • You probably noticed, but @designsimply did two usability tests with the front-end editor. One. Two. Main problems:
      • The “save” button seems to be hard to find.
      • The featured image area needs to be more descriptive.
    • Gallery previews have recently been added to trunk by @gcorne. I’ve been trying to implement the same plugin with the front-end editor, but since templates are used instead of the actual shortcode output, it will need to be adjusted. After all, we’re trying to make an accurate WYSIWYG editor. #52
    • Currently edit links on the front-end link to the front-end editor, and edit links on the back-end to the back-end editor. It’d be better if there was a drop down in the admin bar to choose which editor you’d like to use (?), but how should both editors be described? ‘Edit in admin’ and ‘Edit not on the front-end’ might make sense to us, but probably not to the average user. #53
    • The ‘meta modal‘ needs to improve. It’s a bit too clunky. It might be better to have a (collapsable) side bar with collapsed meta boxes (a bit like the customiser). Needs mock ups.
    • We should experiment with an inline toolbar (one that pops up after selecting text). I think this would only be useful in addition to the main toolbar, since it cannot have all the tools the main toolbar has. Needs mock ups.
    • Mobile: the editor works on small screens, but doesn’t have a TinyMCE toolbar. It should have one, or at least one with a few tools. Needs mock ups. #14

    The next meeting is tomorrow, 11 March 2014, 17:00 UTC in #wordpress-ui.

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

      Thinking about it, giving the user the option to choose the editor for edit links would require the same for new post links… While drop downs could be added for those admin bar items as well, doing so would add a lot. Too much in my opinion. There must be a better way.

  • designsimply 11:09 pm on March 5, 2014 Permalink
    Tags: front-end editor,   

    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.

  • designsimply 8:40 pm on February 27, 2014 Permalink
    Tags: front-end editor,   

    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   

    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.

     
  • Janneke Van Dorpe 9:49 pm on February 18, 2014 Permalink
    Tags: front-end editor   

    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

     
  • Janneke Van Dorpe 11:56 pm on February 11, 2014 Permalink
    Tags: front-end editor   

    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?

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