Hi there, WordPress community.
The MP6 team has been working on adding color schemes in the past couple weeks. Now, we’d like to get your input about which color schemes you want to see make it into the core plugin. Please check out the schemes and let us know which color schemes you would use:
Which of these MP6 color schemes would you use?
We’re also taking suggestions for color scheme names.
1) Fairly quiet week. Some progress on our planning spreadsheet.
2) No IRC chat this week. None next week either. Our next chat will be Tuesday, October 8th, 2:00pm UTC in #wordpress-ui.
3) @ryelle coded up the new “Right Now” widget.
4) I made a few adjustments to the structure of the plugin.
5) @kraftbj made a first stab at removing the columns screen option
We’ve been busy building and improving the plugin. We are approaching the point of a full feature prototype, which will allow us to start testing smaller incremental changes.
I committed the first pass at the browse themes screen based on the mockups we’ve discussed before:
By the way, we are running a bit short on development resources, so if you are proficient in PHP and/or JS and want to contribute to this project, please, either chime in to one of our weekly chats or ping me directly. We are using Backbone to build all the theme views. We started a short document with the current tasks.
We have two tasks going on: make theme switching work with the current prototype, and finish implementing theme fetching to the install-themes screen.
Is there any way that non-core developers can get a copy of the plugin to try out? The Make WordPress Accessible Team is interested in having a look.
Hey Graham. Here is the link to the core plugin: http://wordpress.org/plugins/thx38/
I notice the new buttons Widgets and Menus which are on the activated theme page. Interesting.
What are your thoughts on including those buttons Matias?
We had our weekly chat yesterday. If you weren’t there, you can always check out those cool log things.
A few highlights:
Our next steps:
I’ll be out of town next week. While I encourage everyone to meet in IRC, our next official meeting will be in two weeks on October 7th, 2013 @ 20:00 UTC.
Regarding widget thumbnail previews, the way I was thinking it could be done is when switching a theme or when a new widget is registered, WordPress could initiate a request to an ad hoc page containing just the widget, and take a screenshot (with some canvas tool) and then save the screenshot to the database. This request would have to be done in the background in some hidden iframe. It would be very cool, but it also seems like a horrible hack.
Something more feasible would be if we introduced icons to WP_Widget. When instantiating a WP_Widget:
function __construct() {
parent::__construct(
'my_text_widget', // Base ID
__('My Text Widget', 'text_domain'), // Name
array(
'description' => __( 'So much better than text!', 'text_domain' ),
'icon_url' => includes_url( 'images/widget-icons/text.png' ),
)
);
}This icon_url concept is used in add_menu_page(). The widget icons could then be displayed on the widgets page and anywhere else that widgets are managed, to allow them to be easily recognized quickly. The core patch to add support for icon_url would require adding a generic widget icon, and icons for all widgets bundled with WordPress.
In addition to icon_url there could also be a screenshot_url argument. This would be analogous to themes which allow you to include a screenshot.png. Sure the widget screenshot would not be reflective of how it would exactly appear in the current theme, but it would give a good visual overview of what you’re going to get when you add the widget. To see how the widget will look exactly in your theme, the user can just go ahead and add it in the customizer and then can preview how it will look, and decide then whether they want it.
Thoughts?
Submitted a feature-request ticket for this: http://core.trac.wordpress.org/ticket/25419
Great prototypes Shaun! I love the tabbed interface, much easier I think and makes good use of the space.
I think the idea of a preview is a great idea. Maybe you could have it automatically use the default template for a page, but then have a dropdown to select a specific page to see what it would look like on that specific page?
I’d love to see a way to have existing widgets available in a list to be used on multiple sidebars.
Regarding the use of the customizer to manage widgets that appear only on select pages (as the ), I think the customizer is not currently displayed prominently enough in WordPress. When you’re looking at a post on the frontend, there should be a Customize link right next to the Edit link in the Admin Bar. Furthermore, when editing a post in the backend, the Preview button should open the post inside of the Customizer, not in a standalone page; the Back (Close/Cancel) button in the Customizer then can just close the window and bring focus back to the window opener. This makes it much snappier to go back to the post edit screen. Also, right now the document title of the customizer does not change based on what is currently being previewed: it always remains just “Customize Twenty Twelve — WordPress”. This is not helpful, and it should dynamically update to include the currently-loaded document title in the preview.
I’ve put together a plugin which addresses the above wishlist items: https://github.com/x-team/wp-customizer-everywhere
Just released Widget Customizer 0.6: drag-and-drop widgets within customizer panel to preview changes to their ordering! http://wordpress.org/plugins/widget-customizer/
Woo Themes have made a very nice plugin: http://wordpress.org/plugins/woosidebars/
Couldn’t make it last week? Check out the chat log.
This past week, we’ve had some new designs pop up:
UX feedback is welcome, though keep in mind these are still ideas. We’re looking for big-picture issues. 
We’re going to continue to work on smoothing out these ideas, then will need some people to help us prototype them. To help that along, we’ve put together a spreadsheet of tasks. If you’re interested in claiming a task, let me know.
We’re pretty deep into various design concepts, but I think I want to also take a step back and evaluate what we’ve done so far. Are we on the right track? To help this, I’ve put together a survey:
Please take this when you have a moment and share it along. The results will be used to help us figure out if we’re solving the right problems, or if we need to step back and try out some different ideas. It will also help us determine if there are any “quick wins” we can implement prior to adding content blocks.
Chat is tomorrow, Tuesday the 24th at 17:00 UTC in #wordpress-ui. I’ll be on a plane, so I might not be able to make it, so @joen has agreed to lead in case of my absence.
A few thoughts/ideas (and sorry if this has been covered previously).
1) I can’t help but notice how similar this feels to the Post Formats UI (particularly in iconography). I’m super bummed that that project seems completely abandoned, but should it ever come back to life, thinking about putting these two things together is pretty mind-blowingly confusing.
2) The UIs where the buttons are in the editor seem clearer that you’re adding content to the body of the post. I think this might be even clearer if you outlined the options in a dotted line to denote the potential for additional content. Here’s a concept that merges some things from a couple of the posted ideas: http://mrwweb.com/wp-ceux/mrw-ceux-concept-092313.jpg To be clear, I make the assumption that the new feature is prominent enough that people will discover it whether or not they understand it at first.
3) Given the direction of WordPress (and the web), making sure the tool and content layouts themselves are responsive seems very important.
4) I’ve noticed some concepts have a “Text” block and others don’t. The inclusion of a text block feels a bit confusing to me. If I add an image, for instance, do I have to add a Text block afterwards to continue writing or is text the default state of the editor after a block is added and configured?
Hey, mrwweb, nice thoughts! First, I think that the Content Blocks plugin is definitely an evolution of the idea of Post Formats. In my opinion, that’s the initial reason that the mockups and prototypes use the same icons.
What I like about your concept is that it has an area that looks like a placeholder, and it made clear that it is a place to put something else (content, in this case). Maybe this could be a more intuitive approach.
About the “Text block”, It is there because we’re still trying to figure out how to deal with content. For example, if we think about blocks like pieces in a grid layout, then I think that every piece of content should be a block, including text. But, if we think about the use of blocks in an “editorial” post with a linear content, for example, then maybe a grid wouldn’t be much necessary, and maybe the use cases of Content Blocks would be more limited. I think that the point of Content Blocks is, in first place, help build any type of content, without depend on a selection of a post format (you can build any format of post, at any place), and, in second place, let the user free of the linear approach of build a page.
I really dig your mockup. I think the dotted line may be a tad weighty, but that’s definitely workable. It keeps things clean while still showing recently used blocks on hover. Good job.
About post formats — the inception of content blocks is to subsume the post format concept altogether. If you only add a single content-block, video for example, that defines your post format.
No problem on the line weight. It was a quick mockup and certainly worth evolving
If you only add a single content-block, video for example, that defines your post format.
Do you mean that in a literal technical sense or just in the abstract? Would post formats be deprecated if this feature gets into core? What if you mark a post as “Audio” and then put only a “Video” in it? (That wouldn’t make sense, but I don’t think an interface should even allow that type of confusion.)
There were many reasons for post formats being separated from core. The added UI was one of the reasons. And so part of the genesis of a block-based editor was indeed a yearning for a post formats alternative. So yes I mean that in a technical sense: there’s no reason WordPress can’t add “format-video” as a CSS class to a post that only has video-blocks. So the post format is automatically detected by WordPress based on what blocks you use. It’s not something you pick.
As always, we’re exploring here. Nothing is set in stone.
These concepts are coming along nicely. I lean more towards @joen‘s concepts as I think having the common content types easily accessible inline would make it easy to add content blocks as you are composing a post. I do appreciate the more robust options and search shown in your and @diegoliv’s wires. The main issue I see with those options is that the common content types aren’t as easy to get to. For example, the search is shown first. Maybe a hybrid could be done where the common content types are shown at the top of the modal or inline with the composed post like the first concepts then the robust modal with additional content types and a search are shown for the “More…” menu.
Did you look guy at what they do on Squarespace http://vimeo.com/45734056, I dont really like the implementation of adding stuff, but for the layout thing, I think it’s pretty nice. It’s like an automatic column layout.
Yeah, It’s pretty awesome! I tested it some weeks ago, and the way that the Squarespace’s editor handles layout is really good. Personally I think that if we could achieve something like that, we would have a powerfull new way to handle content and layout. We just need to figure out how to handle it, and think about the use cases and possible issues.
We’re still discussing at the CEUX Chat some initial concerns of the project, like the blocks menu UI and the implementation of TinyMCE, but content layout will be probably a discussion we’ll have after we solve this initial challenges.
I am extremely excited by all the CEUX prototyping so far. My main comment is pretty close tho what Jen Mylo has been saying (last paragraph).
In short: I think this is an amazing opportunity for improving the handling content blocks, not only *inside* the main text container, but also extending to several separate content blocks. I am thinking mostly about a picture gallery that sits *above* or *aside* editorial content, rather than being embedded in the body text. This is so far solved by custom meta boxes, or plugins like the (excellent) Advanced Custom Fields.
It’s a bit lengthy to explain in full, so I wrote a detailed and illustrated post. Waiting for your feedback
Nice post, I gonna try to make some sketch about it and the best simple way for the user to use this.
1) I updated our planning spreadsheet.
2) We held our weekly IRC chat last Tuesday. @joen shared:
Along with the following thoughts:
This mockup solicited the following feedback:
3) Joen shared the following mockup in our Skype chat:
4) I uploaded an updated combined news feed patch. Please test this patch out if you have time, or dive in for a code review.
5) I riffed off of Joen’s latest mockup, and came up with:
A few thoughts:
1) I have loved the move to “Quick Drafts” from Day 1. It feels like the main (only?) action-oriented item on the dashboard, and with good reason. When people log in, they should be encouraged to create! So from that standpoint, why not put it in the left column where people’s eyes pass first? This would necessitate moving the Activity Stream to the right, but when I think of other sites with a stream (ala Facebook), they’re frequently on the right. What’s more, the activity stream would seem to have a natural affinity with the “Right Now” widget which is on the right. (I even wonder if the two could merge with a global summary of the site that includes both a broad overview and recent changes)?
2) Does the WordPress News deserves a big widget or whether it’s more of a mini widget.
3) Has there been any discussion of adding an “Updates” widget? (Probably a mini-widget.) Many people are terrible at updating it would sure be great to nag them a bit more. A “What’s New” link that goes to each plugin’s/theme’s changelog could also potentially give people a reason to update and make the changelog sound a lot less scary.
It’s been great to watch this concept develop (for the better even!) and I hope to see the final product work it’s way into core.
@mrwweb they showed Updates mockups in the previous post:
http://make.wordpress.org/ui/2013/09/13/dash-update/
I’m still curious to know if there’s been any changes to the Updates widget from last time, as I suggested a Hide feature that has yet to be commented on.
I overlooked that in the activity log. Thanks.
Hey that’s pretty nice!
We’re currently trying to hammer out the scope of the activity stream, making sure we’re ready for 3.8, so the activity stream in the first release may just be a bulked up “Recent Comments” widget with added pending posts. But that’s a nice mockup, I like that style.
Awesome work Lessbloat! The various Core Plugins groups really should follow your example! Make spreadsheets showing progress and where work is needed. It will make it really clear for people wanting to contribute what is still needed to be done. It seems some kind of “template” for running a core plugin group needs to be worked out. Which is clear and to the point for various stages of the development. Regular updates are needed for all the groups so everyone can see what is going on. Backward, stand still or forward progression. Communication is vital for anyone taking part.
I like the work you’re doing here. But I was really hoping that *recently published* posts would make it into the activity stream. My subjective impression is that, as a blogger, you often want to go back to a recently published item to change a few details. Having a direct link from the dashboard would be top. And in a multi-user setup (team or company site), it’s important to see who did recently publish things.
I think that’s a great idea.
Slowly getting rolling with updates, but after @shaunandrew’s initial proposal, I’ve agreed to lead the plugin for a Media Library Grid View. Our weekly meetings are Fridays at 15:00 UTC in #wordpress-ui. Plugin development will proceed for the time being on GitHub.
@shaunandrews has also done a couple of screencasts of some experiments:
I love the scaling ability to make less columns and make the images bigger, great idea! I’m not a fan of the rotating when selecting items. I feel like on the front end of a site that’s a cool element for sure, but in the backend, I think simple is better.
Same here
Yea, I added the rotate-on-select cause I thought it was fun. Turns out no one else thinks so. To be fair, this is just a prototype, and the end result will likely look more like the media manager modal.
Some very cool news!
Automattic Acquires File-Sharing Service Cloudup To Build A Faster Media Library And Enable Co-Editing: http://techcrunch.com/2013/09/25/automattic-acquires-file-sharing-service-cloudup-to-build-faster-media-library-and-enable-co-editing/
The question that arises is how will the media library change?
We had our weekly widgets chat in #wordpress-ui on Monday, check the logs for the full transcript.
Short and sweet. Lets keep the conversation going on the comments here, in skype, and in IRC. See you next week. Same bat time; Same bat channel.
I ran a user test using the Widget Customizer plugin. Since the plugin doesn’t support adding widgets (yet) the test is focused on updating a few widgets, and seeing how comfortable the person is navigation around the site from within the customizer:
Things went very well. The biggest take away is that, even with the customizer, there’s still a disconnect between the “sidebars” presented in the customizer and the widget-ized areas in the page. We’ve discussed this a bit on Skype, and there are plans to highlight the widget area thats being edited.
Wow. This is really valuable. Thanks for doing this @shaunandrews! Lots to glean from this.
Notice he clicked on the text he wanted to update, but it did nothing. Then he had to hunt through the customizer sections and controls to finally find the right control that edited that area. When clicking on a widget, the corresponding section and control should automatically show. We have actually already captured this feature in issue #5.
But there is also a key improvement needed for the Theme Customizer in general. There should be an onunload event handler which throws you a confirmation when you try to navigate away from the page when you have unsaved changes. That, along with a more prominent “changes pending” indicator would be great, like the “Save & Publish” could have an animated glowing effect.
This was his first time ever using the customizer, so his impressions were especially important. It would be interesting to also see a user’s reaction if they had used the customizer a lot in the past.
I’ve just released a new version of the Widget Customizer plugin (0.5) which addresses the primary issue uncovered by the user test: difficulty to discover which sections and controls in the customizer panel correspond to widgets in the preview window. So now in the new version, hovering over widgets in preview highlights corresponding customizer sections and controls in panel. Clicking a widget in preview opens the widget form in the panel and focuses on first input. Interacting with widget form highlights widget in preview. See screenshots on issue #5.
The specific highlight style used (the red box-shadow) is really just a proof of concept. Any suggestions for improving the visual indicators would be much appreciated. Pull requests welcome.
That was great to see. I think that highlighting the widget area being edited is a great idea!
We had a pretty exciting chat last week! Here’s what happened:
This upcoming week sounds like it’ll be a work week, so I’m thinking the meeting will just be a check-in. Come with your questions, comments, and any progress you’ve made with sketching or developing. As always, chat is Tuesday at 17:00 UTC in #wordpress-ui.
Absolutely love the WIP prototype, definitely a win and a great way of handling a variety of post content, (re – pot format debacle) This is definitely what I want to see in the next iteration of the WordPress Admin. A great addition would be a preset responsive grid allowing you to set a column width for a content block.
I assume the idea would be for the the_content() to do all the heavy lifting in outputting the various types…. my themes are bloated with a lot of logic ands various views. The ability to control the content layout like this would be AMAZING!!!!!!!!!!!
Bring it on – as a professional WordPress developer this is what I, and my client,s have been gagging for.
Hi, Paul! The idea of handling columns and grids right at the post editor is definitely a feature that we need to discuss, I agree that it will be a great addition!
And I was thinking the same as you about the use of the_content() to handle all the content blocks. I think that we could print all the content using just the_content, and we could get a particular block using something like the_content(array(‘block_id01′, ‘block_id02′).
Awesome, yeah love the idea of extending the content, I don’t want to jump ahead too far, but the other ‘concern’ or point of interest for me would be how we eventually handle custom content blocks.
Currently, other than using the post formats fairly extensively with my own custom meta boxes (I like to use them for pages as well) which this would totally handle (woop!) I usually create fairly extensive meta-boxes for specific content areas on a template or site as well…. any thoughts – leave them as they are for now ? or would the goal be to integrate those as well….
It’s too early to worry about this yet, so I’d leave them as-is for now. We plan on making the blocks in such a way that it’s easy for developers to be able to add custom blocks, but how that’ll be implemented is still up in the air.
Really like the prototype. I’ve been using Advanced Custom Fields to add extra fields to certain content types, but it would be super to get some similar functionality into core, or at least a “core” plugin similar to the post formats one. It would be fabulous to be able to distinguish blocks of content within a single post or page, instead of having them all together in one text editor.
Yay, I’m happy that everyone’s enjoining the prototype!
@melchoyce just for the record, I’ve just pushed some commits that fixes the prototype markup and styling, now everything including Dashicons should work properly.
This is the first Front-end Editor post (see Inline Editing Front-end Editor on the Features as Plugins Tracking page).
If you haven’t heard about it before, you should definitely take a look at the overview, where you can read about the problems we’re trying to solve and where we’ll keep all the information.
A prototype is currently in development, it can be found in the plugin directory and on GitHub as a mirror.
Here are a few screenshots:
Editing mode
TinyMCE 4.x
Tagging
Distraction free writing?
Post updated
Responsive
Of course this is just one approach. Another could be @scribu’s Front-end Editor.
We’d really like to hear (and see) your thoughts! Whether it’s feedback to the current prototype, or ideas, examples of how other platforms implement front-end editing, wireframes or even working prototypes – everything is welcome.
We’re still looking for more people to join us: developers, designers, users… If you’re interested, please leave a comment.
Our weekly IRC chats are on Thursdays, 20:00 UTC. The next one will be on September 19 20:00 UTC.
This is nice. However I think another approach could be more usable and compatible with more sites.
A left “pull-out” style menu (like the theme editor) that has title, the content, featured image and any custom fields etc in a streamlined layout and it updates live via Ajax as you edit.
That way you’re not interfering with your site design by having front end editor panels overlayed and if you’re using custom fields for additional content that will be easier to edit.
Just my two cents. I may do a mockup to show what I mean.
Cheers
For the custom fields and additional post information, I was thinking about a modal in the style of the media uploader.
Using the customizer is another approach, though it would only make it more complicated to make. Why do you think it would more compatible?
A mockup would be great!
I agree, using the customizer is not the right way. For the custom fields; do you intend to use one modal per custom field or one modal for all the fields?
I was thinking about one modal, with different sections like there are different metaboxes and subtabs for each if necessary. It should be as extendible as possible.
The thing about front-end editing is that, if the site if less blogging oriented, and WordPress is more used as a CMS, the front-end editor looses its magic. If there’s almost no content, and lot of fields in the modal, it’s pointless.
But then again, the front-end editor could be turned off, and the back end could be used instead. Most of those bigger CMSs (or app platforms) have a customised back-end or front-end anyway.
This is what I had in mind… (rough sketch) http://cl.ly/image/2m1b0N0L0r2c
As you can see, if you change the title for example you would see it update live on the fly to the right, and the same for the content – giving the user a true real-time preview of the post / page.
I would prefer this method myself.
Nice mockup.
As you said, it’s more a real-time preview in a split screen than a front-end editor. But I’ll definitely reference to your mockup in the future and see what others think. Thanks!
@rockethouse nice concept! It reminds me a little of the concept of the Ghost project from what would be the post editor: on the left, the user edit the post, and on the right, the user sees in realtime how the post will look on frontend (http://tryghost.org/features.html – check it out here). In fact, I like too the use of markdown on Ghost concept, not just because of the language itself, but the fact that it is less cluttered. Maybe the idea of “clean up” the UI a little bit could improve this concept?
@rockethouse @diegoliv
There are some pros and cons for both approaches. While I think having just one field that’s both the editor and preview is cleaner than a split screen approach, there are some things, like shortcodes, that are difficult to implement. I’m trying to figure out how to do it, but shortcodes can do about anything, so they’re quite unpredictable.
The split screen approach would easily take care of that, but it takes up more space, it shrinks the preview, and I’m not sure how it would work on small screen devices.
What about building another prototype alongside the one above and see how that works out? @rockethouse would you like to help with that?
Or, can I help you with that?
i think there are some fundamental issues with the split screen approach personally. #1 it’s still a separation which is potentially confusing #2 i don’t see that would work well for small screens especially mobile.
On the upside, it is visually and functionally consistent with the existing customizer.
I like the look of the editor a lot!
I guess the left pull-out option would be very much like this plugin:
http://wordpress.org/plugins/live-edit/
I still prefer the not pull out version myself, but I guess both have pros and cons and maybe a pull out can be used to access more complex issues, that cannot be dealt with otherwise…
I like the idea of this editor a lot!
Slide out panel would be similar to this one I assume:
http://wordpress.org/plugins/live-edit/
But I personally prefer the not panel approach, maybe the the option to pull out a panel for more complex issues if necessary.
Looks like a really nice, innovating new way to edit posts/pages on the front-end.
I’m very interested in contributing to this project, I just don’t know how. (I’m a developer with skills in php, HTML 5/css3 and of course WordPress)
You can always share your ideas, give feedback to the current prototype, or even enhance it. It’s all on GitHub too.
But right now it’s more in the design phase than the development phase.
I’d recommend coming to the weekly chats and seeing where help is needed. While, as @avryl says, it’s still mostly in the design phase, you might be able to help with prototyping during the week.
Wow, looks interesting indeed. Is the current version actually working, or are these screenshots just some photoshops? I just installed it on a plain vanilla WordPress with MP6 and Twenty Thirteen but no front-end editing anywhere..
It should work more or less But you have to click “edit” on the front-end, not the back-end. I don’t want to completely block back-end editing.
Looks darn cool! How’s this going to work on mobile and touch screen devices? Has any thought been put into that yet?
I have no idea yet, so your thoughts are very welcome! Some input from people who actually use small screen devices to create/edit posts would be helpful.
Is the scope of this editor defined anywhere? I like its current implementation a lot but I’m wondering what features should be ideally a part of it and what features shouldn’t be a part of it (and why?). For instance: shortcodes, embeds, more HTML tags, columns, widgets – will it support this? I have a few pieces of code that may be useful but I just need to know what is the desired end result of this extension. Will it go to the core?
@looimaster, I had the same question. This partials addresses it: https://github.com/avryl/wp-front-end-editor#what-problems-are-you-trying-to-solve
On the overview:
[...] and still has all or most of the functionality of the current back-end editor. The scope of the project would be limited to editing and creating posts (meaning posts and pages, as well as CPTs that support it).
If you can add something to the content in the back-end editor, you should also be able to add it in the front-end editor. Whether or not custom fields etc. should be part of it is a different question.
Will it go to the core?
I don’t know. Maybe, maybe not. Depends on the end result and what the core team thinks about it. But it’s almost definitely not a 3.8 feature.
I have a lot of thoughts that I’ll try to get together in a longer post, possibly with some mockups, but I wanted to quickly respond to a few of the problems this project is trying to solve (Source: github):
Post formats aren’t supported by add_editor_style() at all.
It’s also impossible at the moment to apply any css rules based on classes outside the content. A small example: the colour of the links and headings inside my post are based on the category of that post. Additional css rules have been added based on the post class, but they don’t affect the colour in the back-end editor.
As detailed in this Tuts article from 2012, it’s not that hard to dynamically add classes to the editor based on the selected format. I’ve extended this technique to Page Templates and there’s no reason it couldn’t be extended further to categories, tags, and even Authors. Simply adding a set of standardized classes akin to `post_class()` would resolve this problem and let theme authors take this issue on.
You’re absolutely right.
And post formats already have a their class added to the editor’s body. Something Twenty Thirteen makes use of. (I noticed this before, and forgot to change it.) Categories, authors etc. could also be added that way. Thank you for pointing it out.
The point I wanted to make was that with front-end editing, the post would always appear exactly as it was styled in style.css, both the post you’re editing and the published post will look exactly the same.
I like this a lot, thanks for sharing it. A couple of observations from having a play with the plugin:
Thanks for the feedback!
I think that, for the first observation, about the “save” button, I had the same impression, I didn’t found the save button so quickly when I saw the screens of the prototype. I think that maybe this is happening because we, like any wordpress regular users, are used to find this button at the upper right corner of the screen, when we are editing the post at the back-end. So, when put our eyes for the first time at the screens, our mind expect that some things will be in a certain place.
Same here on the save button, but I agree completely. I think it makes sense in that location with this format…The only other way is to maybe have it at the top right by itself since I feel like that’s the instinctive place to look.
(Preface: I haven’t tested this plugin.)
If the editor is always visible, maybe it makes sense to add the save button there. If it *isn’t* always visible, there’s perhaps some other kind of highlighting that can be done. Generally things tacked onto the bottom of a page get ignored.
I thinks this looks awesome – but I am slightly confused as it seems to conflict with the equally awesome new post editor design – http://make.wordpress.org/ui/2013/09/04/ceux-sept-3-chat-notes-wireframes/ – how do you see the two working together?
Conflict in what way? Do you mean how content blocks would work in a front-end editor? If content blocks become reality, then yes, the front-end editor should support it. But for now, we don’t know how that’s going to work yet.
My concern is that there seems to be 2 projects doing the same thing (improving post editing) and I don’t understand how they will work together. Perhaps I’m worrying about nothing – but I found it strange that nobody else saw the issues I see so I wondered if anybody had thought about how the two would work together.
I agree, and I have to say I much prefer having the admin page – love the idea of content blocks over this.
I suppose front Personally I suppose front end editing could be cool for minor tasks like correcting a quick error or changing a heading / image / font size / color etc, but I would want to see the abilities of the front end editor throttled to the bare minimum.
@binarymoon @pushplaybang
I also think content blocks are really cool, and no-one said they can’t be part of front-end editing I’ll talk about it with @melchoyce in the next meeting to see in which ways she’s up for some collaboration.
And this is an experiment of course, they’re all experiments, and it will be exciting to see what they end up being.
As @avryl said above (and below!) there’s no reason for these two projects not to exist side-by-side. They’re both experiments. If/when CEUX gets slated for core, the front-end editor project will need to adjust their plugin for it. But as of right now, CEUX isn’t in core, so the front-end editor should be designed without them.
[Which doesn't mean they can't collaborate of course.]
I think this is a really great start, looks awesome! I like where everything is for the most part, I feel like everything is where I expect. The save button is at first hard to find, but I feel like it makes sense in this format…I just have to fight the urge to look at the top right.
The one thing I would like is maybe a border around the space your editing so that there is a clear definition of edit mode. I think this also would work well if content blocks were ever added. Maybe something like this. I think the icons would help too if content block were added, maybe not so big though.
For me it makes sense too, but the bottom bar probably has to move anyway. See also the problem in chrome. (And I don’t think a browser should overlap any content, but yeah…)
I really like it at the bottom though.
Yes, the edit area needs to be properly pronounced. See this comment.
I’m curious why you chose the bottom and not some type of visual extension of the admin bar which is already associated with editing. I could imagine some type of slidedown animation that catches the attention immediately.
It just seemed to fit there somehow.
The admin bar is the only other place to go really. I kind of see it merge with the TinyMCE bar then. The slidedown is a nice idea.
That’s actually a great idea! I think an animation effect would immediately give attention of where those tools are.
that makes me think of z-targetting in zelda 64 for some reason.
@samuelsidler I can’t make the meeting tonight – I have some problems that suddenly came up. What’s the best thing I can do? Really sorry about this.
I’m currently in the midst of traveling, but the best thing usually is to find someone else to run it. Barring that, announce that your meeting is canceled along with any updates you have for the week on a make/ui post.
I love this concept and as I understand, it’s about editing posts, correct?
Have you done any thinking around editing pages, layouts or adding content like it’s done in the episerver layout editor? (inspiration -> http://www.youtube.com/watch?v=QDMmpaQS_t4)
I’m sure a lot of people have thought about that, but this specific feature is just about editing and creating posts on the front-end, not customising the website’s layout or design.
Although I’d hate to delay this project and create a dependency there, what do you think about delaying this to wait for the JSON REST API in core? I think it’d be mutually beneficial to base the front-end editor off the API, as it would strengthen the API’s Javascript offerings while ensuring that we don’t duplicate work on the backend.
I don’t think we need to delay this project for that. We’re more in a design stage and it’s easier to have a more or less working prototype to experiment with. But eventually, yes, why not. I’ll look into your project.
Hi everybody. I already created a WP plugin and own inline editors some time ago.
Plugin demo videos http://directedit.co/videos
live demo on http://carloroosen.nl/lignostar
The javascript library is already on GitHub (https://github.com/carloroosen/directEditor), the rest of the plugin is planned to be published as GNU within a few months. Subscribe on directedit.co and you’ll get access to the code and some documentation.
However, I must say there is a difference in what I want to achieve with my plugin, it is primairy meant to build custom websites for customers.
Quick Front-end Editor update.
I’m sorry the last IRC meeting had been cancelled, it was quite short notice. Unfortunately, at the moment, it’s really difficult for me to meet on the current date. It could be moved to a different date of course, or maybe we can just have discussions on this P2 instead? At least that’d be easier for me.
I’ll soon publish another post with the next steps/problems/updates, where you can leave all your thoughts. I’m really happy with all the input form everyone on this post!
Is it planed to keep the dependency on mp6 in future? I like the front-end editing but not the mp6 backend style.
mp6 will be the new back-end style, so yes it will depend on mp6 until it’s part of core.
I have some pretty basic concerns about how this scales to more complex CMS-like sites with Post Type and Taxonomy Archives, Custom Post Types, Custom Fields, multiple menus, multiple sidebars, conditional widgets, etc. While front end editing can help with very basic sites (Medium seems to be an example of the best type of use case), I worry that for more complex sites, front end editing hides the structure of a site, focuses editors on the visual display of the site (which is already a problem as it is), and generally may cause more problems than it solves. It’s also a second editing interface for new users to learn and for WordPress devs to maintain.
So I’ve put together a separate concept for “inline access” where the editor uses the front end as the starting point for the editing process. I’ve made some mockups and written more about my specific concerns about front end editing and why I think this other idea may be better a solution: http://mrwweb.com/wp-inline-access/
I’d love for people to take a look and give some feedback. As this project moves forward, I hope some of the concerns raised in my post can inform decisions here.
The front-end editor needs to be turned on for CPTs. I don’t really see the problem with multiple menus, sidebars, widgets etc. Why would it be a problem? And really complex sites that use WordPress more as a CMS or application framework generally have their own editor and back-end, and they don’t have to use the front-end editor.
Could you be a bit more specific when you say “and generally may cause more problems than it solves”?
I’d be really cool if you could make a prototype with your ideas.
Happy to try to clarify. Between my explanation and the articles linked from it, I think the pieces all come together.
My big concern is what it means to let the users make changes on the front end. I think it’s best encapsulated from the “Leaky Abstractions” article I link to in my explanation of the mockups (linked above):
If the primary editing interface we present is also the visual design seen by site visitors, we are saying: “This page is what you manage! The things you see on it are the true form of your content.”
This problem becomes more pronounced on large CMSy sites but I think it’s a fundamental issue on anything more than a 1-page site (which is why front end editing works on something like Medium).
If we allow editors to edit the title and body, they’ll be frustrated if they can’t also edit the widgets. But if they do edit the widgets and that change is reflected across the site, that begins to break the expectation that you are only editing what you’re looking at on that page. That expectation is mistaken but I think front end editing encourages it.
I like the idea of this editor a lot!
Slide out panel would be similar to this one I assume:
http://wordpress.org/plugins/live-edit/
But I personally prefer the not panel approach, maybe the the option to pull out a panel for more complex issues if necessary.
Will you be looking to make images, media, gallery editable from the front end too? Similar to the back-end solution now, with drag and drop inserting, sorting and choosing the way a gallery is displayed.
I really like this idea. I am brand new to the WordPress community (though I have been using wordpress for years and developed a few private-use plugins). I would really like to get involved in the opensource community here at wordpress.org, and this seems like a great place to start. Can anyone let me know who I need to chat with? I’d like to learn the process.
I am fluent in PHP and have used WordPress extensively. I would consider myself a developer, not a designer and would be happy to pull some bug requests or whatever.
Thanks!
Sounds like you’re looking for the plugin on GitHub: https://github.com/avryl/wp-front-end-editor
This is my favorite new feature and it’s not even out yet lol
Terry Sutton 5:24 pm on October 1, 2013 Permalink | Log in to Reply
Ectoplasm for life!
Valerio Souza 5:37 pm on October 1, 2013 Permalink | Log in to Reply
I would love it if it had an option to force all users to have a pre-defined layout.
Ipstenu (Mika Epstein) 6:25 pm on October 1, 2013 Permalink | Log in to Reply
You can do this!
http://halfelf.org/2013/mp6uccess-tips-and-tricks/ (scroll to ‘force a choice’)
esmi 7:07 pm on October 1, 2013 Permalink | Log in to Reply
All of the suggested color schemes re very pretty but what would be really cool would be to have at least 1 user-selectable high contrast scheme for visually impaired users. Yellow on black would be one possible option. Ditto a very low contrast scheme for some dyslexics. I’d be more than happy to wok on this with someone.
Helen Hou-Sandi 7:19 pm on October 1, 2013 Permalink | Log in to Reply
Have you taken a look at the default and light themes? Note that this poll is regarding *extra* schemes.
Trifon 8:47 am on October 3, 2013 Permalink | Log in to Reply
The readability of the default is really good for me (being dyslexic myself). You should take a look at it, for I think that it works great for your purposes.
Mel Choyce 8:58 am on October 3, 2013 Permalink | Log in to Reply
Let me know if either of the default schemes (light or dark) works — if not, I’d love to chat some time in the next week about making a high and/or low contrast scheme. At the very least, we could create a plugin pack of accessibility-focused color schemes.
That reminds me — it would also be great to make a plugin that replaces Open Sans with OpenDyslexic (which would be super easy if we were using a pre-processor for more than just color schemes!).
Joe Dolson 11:17 pm on October 4, 2013 Permalink | Log in to Reply
I looked into the OpenDyslexic question, but unfortunately it’s not under a GPL compatible license (CCA 3.0 Unported). I couldn’t find any other Dyslexia-focused fonts that were under GPL licenses, so doesn’t seem to be an option.
Mel Choyce 11:19 pm on October 4, 2013 Permalink | Log in to Reply
Oh no! For some reason I thought it was MIT. Bummer.
Joe Dolson 12:12 am on October 5, 2013 Permalink
Yeah, I thought so too — I knew they’d been wanting to get it into Google Fonts, so I’d assumed it was something GPL compatible…but no.
Native Imaging 8:00 pm on October 1, 2013 Permalink | Log in to Reply
I thin Color schemes are a bit of waste of efforts. Why not just create a panel to define your own color schemes, and let users import and export them.
What I am hoping to see are the bug fixes and hard CSS resets for the Admin.
I know it must be hard or nearly impossible to hard reset all of the CSS HTML and scripts running inside of 3rd party plugin developers. but what I see, is a Union of Compliance that needs to be set and sponsored by the best-of-the-best plugin developers. There needs to be some form of speed-optimization and responsive-touch standards implemented into all plugins, or else, get chucked-from-the-movement. The utmost complaint I have from 90% of clients is that their windows OS’s are not working , and they can’t even get online due to Anti-Virus softwares. #2, they are completely flabbergasted when trying to understand the wordpress backend, even when all they see is Posts, Pages, and Profile as an Author. WordPress has an awesome core that can be configured in anyway, but I’m watching the innovative progress of the MP6 plugin slowing down.
Certain things that are unfixed problems i’ve personally noticed (yet I still use MP6 on every single website I maintain)
• unchecked boxes are horizontally collapsed.
• viewing admin bar horizontally on mobile devices is broken.
• Media Uploader does not work at all for mobile touch ready devices. Should load in a full screen container with BIG BUTTONS creating galleries and/or images.
• Drag and drop does not seem to utilize the predefined styles for Android & iOS.
• No one uses their computers anymore, and sadly said that the WordPress App does not work at all for 90% of the devices I’ve test it on.
• The MP6 is a good start, but it’s still labeled as a secret. WE NEED Responsive and Speed Optimized Compliance with all large plugin authors. I hope to see a network created soon to encourage this type of flexible development for all successful developers.
• Users are On-the-go and this should be taken into consideration for all developed plugins. (Hence some sort of compliance needs to be encouraged. )
Other than that, other bugs are small, and I hope that the MP6 does see its way into the WP, core and probably should’ve been a while back. Social Media continues to dominate the average/Non-Savvy computer user. Today, only 10% of clients use computers, and less than 2% of visitors come from desktop computers. The numbers are staggering and falling each day.
Sorry if i’m posting in the wrong thread, but just wanted to share my opinions about the MP6 development and where its getting of track and falling behind…
Hassan 9:02 am on October 3, 2013 Permalink | Log in to Reply
Good points here.
While I agree that desktop traffic is slowly declining, I believe your statements “No one uses their computers anymore” and “only 10% of clients use computers” are a bit incorrect. I maintain a couple of sites where the vast majority of users come from their desktop PCs. Mobile might be on the rise, but it is still site-specific. Some sites -by their nature- attract more mobile visitors, while others do the opposite. So, yeah, it’s subjective.
That said, I do not see desktops going anywhere anytime soon. They still have looong life left
Ipstenu (Mika Epstein) 3:36 pm on October 3, 2013 Permalink | Log in to Reply
Esp. since mobile browsers (on iOS) are still janky for editing.
hakaner 11:16 pm on October 2, 2013 Permalink | Log in to Reply
I prefer an option to create your own.
Hassan 10:06 am on October 3, 2013 Permalink | Log in to Reply
MP6 dark, light, and midnight schemes are the one’s I’d probably use. Not particularly fond with the other ones; they look kind of “out of sync” to me, though I’m not really sure what that means
The idea of users having the ability to create their own custom schemes sounds interesting indeed! Perhaps something like a color picker..