WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

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

  • Janneke Van Dorpe 7:20 am on April 19, 2014 Permalink | Log in to leave a Comment
    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.

  • Sheri Bigelow (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.

  • Sheri Bigelow (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?

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

    Front-end Editor Meeting 20 January 

    Screen Shot 2014-01-20 at 23.18.25

    With @avryl (me), @melchoyce, @helen, @samuelsidler, @gcorne, @obenland, @azaozz and @ubernaut. (Log.)

    We changed the meeting time to Tuesdays 17:00 UTC since that’s going to be much easier for some of us. Next meeting is Tuesday, 28 January 2014, 17:00 UTC in #wordpress-ui.

    There’s been a lot of updates since the last post. You can now create posts and pages from the front-end. I’ve added some more TinyMCE tools and a meta modal that looks very similar to the media modal and holds meta boxes based on the ones on the back-end. Because they’re just a copy, the lay out still needs to be improved. It looks like this:

    Screen Shot 2014-01-20 at 23.00.50

    All bugs/tasks/ideas/suggestions are now centralised in the plugins Trac. At the moment it’s a fairly small list of the things that popped up in my mind, but hopefully you test the plugin, stumble upon a bug and report it and share all your thoughts. Make sure you’ve added the ticket to the wp-front-end-editor component. Sometimes it ends up as not-listed and I won’t notice it.

    If you’re interested in contributing, this is also the place where you can find things to do.

    If you’d like to join our Skype conversation, just add jannekevandorpe and mention the front-end editor.

     
    • Scott Kingsley Clark 12:26 am on January 21, 2014 Permalink | Log in to Reply

      Are the modal sections like ‘Custom Fields’ added via the normal metabox API? Any word on possible integration points for plugins? Or at the very least, anything plugins need to be prepared for in their UI modeling to be able to support this when it’s opened up?

      • Janneke Van Dorpe 9:21 am on January 21, 2014 Permalink | Log in to Reply

        No, only core boxes will show up. It’s impossible to support meta boxes added by plugins since they’re not designed for that and could add javascript anywhere in the back-end. But plugins will be able to hook in the modal of course.

    • Jamil Ahmed 2:29 pm on January 25, 2014 Permalink | Log in to Reply

      Front-end Editor is best update for upcoming wp version and as a designer and QA analyst i will be happy to help in anything you need either its testing or anything related to UI /design. Please let me know that is this a right place for me to help. Already installed plugin in development server. Thanks

    • Ahmad Awais 9:12 pm on January 25, 2014 Permalink | Log in to Reply

      I would like to be a contributor. In case of this new front end UI development. Adding you at Skype :)

  • Janneke Van Dorpe 10:15 pm on December 26, 2013 Permalink
    Tags: front-end editor   

    Front-end Editor: Quick Christmas Update 

    • The plugin had a few updates recently: it now automatically embeds links that are supported by oEmbed, it generates a preview of galleries and captions, you can add/edit/remove the featured image and the toolbar moved into the admin bar. If you quickly want to see what that looks like, take a look at this video:

    • We’ve had some good Skype conversations lately. If you’d like to join the group to help with the design and development, add jannekevandorpe (but do mention the front-end editor in your request).
    • Normally the next meeting is Monday, but since a lot of people are busy around this time of the year, I’m going to cancel it. I should be around though, so feel free to come anyway. So now the next meeting is Monday, 6 January 2014, 16:00 UTC on the #wordpress-ui IRC channel.
    • TinyMCE will most likely be updated to 4.0.x (the version on which the Front-end Editor depends) by 3.9. Here’s the ticket if anyone’s interested to test/help @azaozz: #24067.
    • There’s also a ticket regarding the new styles not being applied to the Media Modal on the front-end (as you can see in the video). Would be nice if there’s a patch by 3.8.1. #26677.
    • So, what’s next and what can you do?
      • TinyMCEThis toolbar should also move into the admin bar. I wonder whether we should keep the default API, or completely create a new one that fits the admin bar’s API. There was also talk about creating an inline toolbar with some basic tools, but it’s probably best to develop this next to the one in the admin bar and show/hide them to test which one scores best in terms of user experience.
      • Shortcode previews. Along with oEmbed previews, this is something that could be used for the back-end editor too. It might be good to split this from the main project, but it’s obvious that this is important to any project that tries to improve WYSIWYG. Creating previews of core shortcodes isn’t that difficult because we know exactly what they do. Adding support for all shortcodes could be a nightmare as they can do anything. It’s also quite difficult to detect if the shortcode is going to represent a block or inline element, currently the code just assumes it’s going to be block. One solution could be to make the shortcode define whether it’s compatible, but it’s nicer if things just work out of the box. Still, it’s better than nothing.
      • Add things such as date and time, visibility, permalink, status and format next to the categories and tags, and think about where these should go. It might be easier and interesting to put them in a modal (similar to the media modal). The main things to keep in mind are accessibility, space and extendibility.
      • Also note that switching between categories, tags, format and status actually requires the html to be updated. Not only could the theme have some CSS for the content based on these, it might also changes its lay out.
      • Creating/drafting posts through the front-end.
      • Add support for CPTs.
      • Responsiveness/mobile interface. Only keep the most basic TinyMCE tools.
      • It would be nice if some people could continuously check the security of the plugin.
      • Low priority, but autosave (and local storage), post locking and expired sessions.
     
    • @ubernaut 10:24 pm on December 26, 2013 Permalink | Log in to Reply

      this is looking great!

    • Paal Joachim Romdahl 10:52 pm on December 26, 2013 Permalink | Log in to Reply

      Very nice!

    • idealien 3:20 am on December 27, 2013 Permalink | Log in to Reply

      Absolutely gorgeous!

      Would meta field support be tied to the APIs of the metamorphosis work?

    • Trifon 5:46 pm on December 27, 2013 Permalink | Log in to Reply

      It’s really working well now. It has come a long way since the project started and, as it matures further, I would love to see the plugin being added to core someday. :)

    • Lachlan MacPherson 2:21 am on December 28, 2013 Permalink | Log in to Reply

      Great work! This is a fantastic addition and will make a big difference to WordPress. Here hoping it makes it to 3.9 :)

    • Weston Ruter 10:56 pm on December 28, 2013 Permalink | Log in to Reply

      Regarding shortcode previews, this is an analogous problem we’ve wrestled with for Widget Customizer. Specifically, themes and widgets need to opt-in for whether they support postMessage (non-refresh) updates to the Customizer preview. Widget Customizer has built-in support for core-bundled themes and widgets, but others must opt-in as we don’t know if a theme’s sidebar has dynamic positioning of widgets, or a widget has dynamic initialization via JavaScript. See full writeup: http://wordpress.org/plugins/widget-customizer/other_notes/#Live-Previews

      • Janneke Van Dorpe 9:59 am on December 30, 2013 Permalink | Log in to Reply

        Yeah, really annoying… It be awesome if there’s a way to make these things work out of the box. But at least you have a refresh fallback!

    • brashell 8:57 am on December 30, 2013 Permalink | Log in to Reply

      You know how the tag for when you insert an image with a caption you see then see the image and the caption beneath it inside the editor. What about using the same concept?

      • brashell 8:58 am on December 30, 2013 Permalink | Log in to Reply

        caption tag / shortcode

        • brashell 8:59 am on December 30, 2013 Permalink | Log in to Reply

          Also I would like to recommend that you add a drop down under the edit button to edit in the backend. Also maybe something in the settings to chooses if you edit in the front or back by default.

      • Janneke Van Dorpe 9:56 am on December 30, 2013 Permalink | Log in to Reply

        I’m not sure what you mean… Captions are converted?

        I’d not use a drop down, but a button in both editors to switch. And yeah, a setting like that would be nice!

        • brashell 5:00 am on January 7, 2014 Permalink | Log in to Reply

          I don’t know why I wasn’t notified of a reply… How can I send you some screenshots of what I mean? It filters out everything I write here so I can’t post it either.

    • venkmanuk 8:46 pm on January 2, 2014 Permalink | Log in to Reply

      This is looking great.. good workin! I have a small idea/request – I’ve implemented this using an icon for the ‘edit_post_link’ link – but need to change the icon to show we are in the edit mode ( don’t like the ‘cancel’ message but that’s another issue ) .. it would be great if when in front-end editor mode we could have an editor_open css class added to the body or the edit_post_link.

  • Janneke Van Dorpe 11:40 am on November 28, 2013 Permalink
    Tags: front-end editor   

    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.

      • Janneke Van Dorpe 11:59 am on December 27, 2013 Permalink | Log in to Reply

        • The more and next page tags are currently visible as an html comment, but they should be visualised and added to TinyMCE.
        • What would the benefit of a body class be?
        • I’m not sure how you would preview archive pages, and I don’t really see the point of that. How would it be useful?
        • CPTs will be supported at some point. Probably custom taxonomies too, but the toolbar or modal will be extendible in any case.
    • 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.

      • Janneke Van Dorpe 12:14 pm on December 27, 2013 Permalink | Log in to Reply

        Thanks for the feedback!

        1. I agree. The floating toolbar will go away. I my opinion it needs to be integrated in the admin bar, but it’d be useful to experiment with and inline toolbar.
        2. That makes sense. You probably noticed that everything moved to the admin bar, but I guess the media button has a better place inside the TinyMCE toolbar.
        3. Would the sudden change in structure of the admin bar help? It might be good to do something more visual there. I think the edit mode should look as real as possible though.
        4. Hm. Maybe. Changing background colour to e.g. blue might solve 3 and 4.
    • 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!

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