WordPress.org

Make WordPress UI

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • lessbloat 1:30 am on September 29, 2013 Permalink | Log in to leave a Comment  

    DASH Update 

    Accomplished this week

    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

    Up next

    • Coding, coding, coding. Continue bringing Joen’s designs to life.
    • Again, we’ll skip our regularly scheduled IRC chat next week. Our next IRC chat will be Tuesday, October 8th, 2:00pm UTC in #wordpress-ui.
     

  • Matías Ventura 6:27 pm on September 25, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    THX38 Update 

    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:

    Screen Shot 2013-09-24 at 4.30.13 PM

    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.

    Screen Shot 2013-09-24 at 4.29.43 PM

    We have two tasks going on: make theme switching work with the current prototype, and finish implementing theme fetching to the install-themes screen.

     

  • shaunandrews 5:14 pm on September 24, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Widgets Sept 23 Chat Notes 

    We had our weekly chat yesterday. If you weren’t there, you can always check out those cool log things.

    A few highlights:

    • We adopted the Widget Customizer plugin as our customizer prototype
    • I tossed out the idea of a “mission control” view for the tabbed prototype, which would let you see all your sidebars at once. The goal with this is to make it easier to move (and maybe copy) widgets between sidebars. Check out the video of this concept in action.
    • We pondered the question “Can the tabbed prototype and the customizer prototype coexist?” Turns out every one seems to agree that both interfaces can coexist. The tabbed prototype lends itself to more advanced functionality with lots of widgets, while the customizer plugin makes it super simple to edit (and perhaps add) widgets to the areas that are currently visible in the preview.
    • I brought up the idea of a way to preview widgets from the tabbed prototype. Turns out this is difficult (and maybe impossible) to accomplish since we won’t know what page the sidebar lives on, or if it even exists. I’d love to find a way to make this possible.
    • Weston got his temporary hooks included in 25580 — yay! This opens up a lot of possibilities for the customizer plugin.
    • We discussed a few ideas for how to add widgets from the customizer. I whipped up a quick sketch showing an extension to the customizer bar.
    • We discussed cleaning up the list of available widgets. The tabbed prototype has renamed a few widgets, and removed the descriptions.
    • Weston brought up the idea of preview thumbnails for widgets. The thumbnails would show a preview of how that widget would look in the current theme. This would require that all widgets have some “dummy” content. Perhaps we could extend this to existing widgets, as well. Having a preview of each widget in the tabbed prototype may help solidify the connection to their location on the front-end. Super cool idea.
    • We discussed the menu-like prototype briefly. I’ve chatted with jtsternburg about his progress. He and his his wife recently welcomed their third child (and future blogger) into the world — congrats! As his time is limited, he’s unable to continue work on the menu-like prototype. He’ll be sharing his code soon, so we can pick it up and get it to a testable stage.

    Our next steps:

    • Continued work on the customizer plugin, and lots more user testing.
    • Connect with the front-end team to see how we can collaborate with widget editing.
    • Pickup the menu-like prototype and get it to a testable stage.
    • Follow @lessbloat‘s lead and create a planning spreadsheet to help define tasks and roles.

    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.

     

    • Weston Ruter 5:49 pm on September 24, 2013 Permalink | Log in to Reply

      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?

    • ntl0820 6:13 pm on September 24, 2013 Permalink | Log in to Reply

      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.

    • Weston Ruter 9:00 am on September 26, 2013 Permalink | Log in to Reply

      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

  • Mel Choyce 9:25 pm on September 23, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    CEUX, Sept 17 Chat Notes 

    Couldn’t make it last week? Check out the chat log.

    Design updates

    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. :)

    Getting stuff done

    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.

    CEUX Poll

    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:

    Writing Posts in WordPress

    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.

     

    • mrwweb 11:34 pm on September 23, 2013 Permalink | Log in to Reply

      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?

      • Diego de Oliveira 12:57 am on September 24, 2013 Permalink | Log in to Reply

        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.

      • Joen Asmussen 6:44 am on September 24, 2013 Permalink | Log in to Reply

        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.

        • mrwweb 3:41 pm on September 24, 2013 Permalink | Log in to Reply

          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.)

          • Joen Asmussen 4:45 pm on September 24, 2013 Permalink | Log in to Reply

            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.

    • gregpabst 1:22 pm on September 24, 2013 Permalink | Log in to Reply

      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.

    • Edouard Duplessis 12:41 pm on September 26, 2013 Permalink | Log in to Reply

      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.

    • Diego de Oliveira 4:53 pm on September 26, 2013 Permalink | Log in to Reply

      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.

    • Manuel Schmalstieg 5:17 pm on September 27, 2013 Permalink | Log in to Reply

      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 :)

  • lessbloat 7:57 pm on September 20, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    DASH Update 

    Accomplished this week

    1) I updated our planning spreadsheet.

    2) We held our weekly IRC chat last Tuesday. @joen shared:

    Along with the following thoughts:

    • Far right column is for mini widgets. The added whitespace adds balance, centers the middle columns. Is reminiscent of the “Publish” box on the Write section.
    • We pulled back on the ambitions of the activity stream (for 3.8). We still have high hopes of filling out the activity stream with valuable information in a later release.
    • Hooks would be added to the top, middle, and bottom of the activity stream to make it immediately pluggable.

    This mockup solicited the following feedback:

    • Maybe play with a splash of color?
    • Maybe try light or regular font-weight for the big header at the top?
    • Let’s experiment with rotating through different languages/idioms for the header text: aloha, Bienvenido, etc…
    • How about “Site Content” instead of “Right Now”?
    • Can we remove the # of widgets in “Site Content” area?
    • Maybe try one header area with “Recent Activity”, and two sub areas with sub headers, “Publishing Soon”, and “Recent Comments”?

    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:

    Up next

     

    • mrwweb 10:00 pm on September 20, 2013 Permalink | Log in to Reply

      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.

    • Ali Shafiee 7:55 am on September 21, 2013 Permalink | Log in to Reply

      • Joen Asmussen 2:04 pm on September 22, 2013 Permalink | Log in to Reply

        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.

    • Paal Joachim Romdahl 10:08 pm on September 22, 2013 Permalink | Log in to Reply

      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.

    • Manuel Schmalstieg 9:02 am on September 26, 2013 Permalink | Log in to Reply

      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.

  • Helen Hou-Sandi 3:02 pm on September 20, 2013 Permalink | Log in to leave a Comment  

    Update: Media Library Grid View 

    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:

     

  • shaunandrews 2:00 pm on September 18, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Widgets, Sept 16 Chat Notes 

    We had our weekly widgets chat in #wordpress-ui on Monday, check the logs for the full transcript.

    • More work on the tabbed prototype, with some more user testing.
    • RichardTape is feeling better, and ready to get to work on his prototype.
    • jtsternberg has the foundation for the menu-like prototype ready, and plans to make more progress this week.
    • Discussed the Widget Customizer plugin, and pinged the developers to join us. (Hi Weston and John!)

    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.

     

    • shaunandrews 7:06 pm on September 18, 2013 Permalink | Log in to Reply

      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.

      • Weston Ruter 7:32 pm on September 18, 2013 Permalink | Log in to Reply

        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.

      • Weston Ruter 8:53 am on September 23, 2013 Permalink | Log in to Reply

        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.

    • John Regan 7:32 pm on September 18, 2013 Permalink | Log in to Reply

      That was great to see. I think that highlighting the widget area being edited is a great idea!

  • Mel Choyce 7:48 pm on September 16, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    CEUX, Sept 10 Chat Notes 

    We had a pretty exciting chat last week! Here’s what happened:

    • Briefly went over our initial wireframes and Jen’s feedback. @joen is planning on working on some wireframes based on her suggestions.
    • Next, we talked a lot about @diegoliv’s WIP prototype and agreed it’s a great start to move forward from.
    • @JustinDGivens and @wonderboymusic worked on moving Diego’s prototype into plugin form, then merged it into the content blocks plugin, which now generates a new “add post (prototype)” page for testing out content blocks. Diego will continue work on the prototype in this plugin.

    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.

     

    • Paul 10:17 pm on September 16, 2013 Permalink | Log in to Reply

      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.

      • Diego de Oliveira 11:43 pm on September 16, 2013 Permalink | Log in to Reply

        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′).

        • Paul 7:06 pm on September 17, 2013 Permalink | Log in to Reply

          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….

          • Mel Choyce 7:11 pm on September 17, 2013 Permalink | Log in to Reply

            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.

    • Grant Palin 11:24 pm on September 16, 2013 Permalink | Log in to Reply

      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.

    • Diego de Oliveira 11:38 pm on September 16, 2013 Permalink | Log in to Reply

      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.

  • Avryl 10:03 pm on September 14, 2013 Permalink | Log in to leave a Comment
    Tags: front-end editor   

    Front-end Editor 

    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:

    fee-1

    Editing mode

    fee-2

    TinyMCE 4.x

    fee-3

    Tagging

    fee-4

    Distraction free writing?

    fee-5

    Post updated

    fee-6

    Responsive

    Of course this is just one approach. Another could be @scribu’s Front-end Editor.

    Excited? Get involved!

    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.

     

    • rockethouse 10:22 pm on September 14, 2013 Permalink | Log in to Reply

      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

      • Avryl 10:47 pm on September 14, 2013 Permalink | Log in to Reply

        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! :)

        • Remkus de Vries 8:21 am on September 15, 2013 Permalink | Log in to Reply

          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?

          • Avryl 9:05 am on September 15, 2013 Permalink | Log in to Reply

            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.

            • rockethouse 9:35 am on September 15, 2013 Permalink

              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.

            • Avryl 9:45 am on September 15, 2013 Permalink

              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!

            • Diego de Oliveira 1:16 am on September 16, 2013 Permalink

              @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?

            • Avryl 8:33 am on September 16, 2013 Permalink

              @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?

            • Avryl 8:36 am on September 16, 2013 Permalink

              Or, can I help you with that? :)

            • @ubernaut 2:34 am on September 19, 2013 Permalink

              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.

            • landwire 8:23 pm on September 27, 2013 Permalink

              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…

      • landwire 8:25 pm on September 27, 2013 Permalink | Log in to Reply

        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.

    • notaternet 10:32 pm on September 14, 2013 Permalink | Log in to Reply

      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)

      • Avryl 9:18 am on September 15, 2013 Permalink | Log in to Reply

        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.

      • Sam Sidler 8:02 pm on September 17, 2013 Permalink | Log in to Reply

        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.

    • Hassan 8:21 am on September 15, 2013 Permalink | Log in to Reply

      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..

      • Avryl 9:11 am on September 15, 2013 Permalink | Log in to Reply

        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.

    • Isaac Keyet 12:09 pm on September 15, 2013 Permalink | Log in to Reply

      Looks darn cool! How’s this going to work on mobile and touch screen devices? Has any thought been put into that yet?

      • Avryl 1:18 pm on September 15, 2013 Permalink | Log in to Reply

        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.

    • Looimaster 6:00 pm on September 15, 2013 Permalink | Log in to Reply

      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?

      • mrwweb 6:16 pm on September 15, 2013 Permalink | Log in to Reply

        @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

      • Avryl 6:16 pm on September 15, 2013 Permalink | Log in to Reply

        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.

    • mrwweb 6:24 pm on September 15, 2013 Permalink | Log in to Reply

      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.

      • Avryl 7:35 pm on September 15, 2013 Permalink | Log in to Reply

        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.

    • Simon Wheatley 8:58 am on September 16, 2013 Permalink | Log in to Reply

      I like this a lot, thanks for sharing it. A couple of observations from having a play with the plugin:

      1. I had to hunt for the “save” button when I first used it
      2. The fading in and out is happening a bit quickly, perhaps increase the delays before fading out to “calm it down” a bit
      3. I tried it in Twenty Twelve, and it worked as expected, but in Twenty Thirteen the formatting bar doesn’t show (everything else works) – I suspect you know this, and I know it’s a prototype! :)
      4. I wonder if there is potential for confusion as to what is editable on the page. When the editor is loaded, there is no difference between the text and images that you can edit, and the text and images that you can’t edit. Is there a way you could “dim” the non-editable items, or place some kind of affordance around the editable items/areas?

      • Avryl 10:19 am on September 16, 2013 Permalink | Log in to Reply

        Thanks for the feedback!

        1. You’re not the only one it seems. Where were you looking for it first? I think you always have to hunt for buttons if you’re not used to the interface though.
        2. I’ll do that.
        3. No, that’s weird, it should work… I’ll try it again.
        4. Yes, I’d like to fade out the rest of the page a bit, but it should work with different backgrounds… Maybe a dotted boundary works better.

        • Diego de Oliveira 2:10 pm on September 16, 2013 Permalink | Log in to Reply

          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.

          • ntl0820 8:01 pm on September 17, 2013 Permalink | Log in to Reply

            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.

        • Sam Sidler 7:23 pm on September 17, 2013 Permalink | Log in to Reply

          (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.

    • binarymoon 3:30 pm on September 16, 2013 Permalink | Log in to Reply

      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?

      • Avryl 3:39 pm on September 16, 2013 Permalink | Log in to Reply

        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.

        • binarymoon 9:26 pm on September 16, 2013 Permalink | Log in to Reply

          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.

          • Paul 10:22 pm on September 16, 2013 Permalink | Log in to Reply

            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.

            • Avryl 6:27 pm on September 17, 2013 Permalink

              @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.

            • Sam Sidler 7:18 pm on September 17, 2013 Permalink

              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.

            • Avryl 9:19 pm on September 17, 2013 Permalink

              [Which doesn't mean they can't collaborate of course.]

    • ntl0820 8:30 pm on September 17, 2013 Permalink | Log in to Reply

      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.

      • Avryl 9:16 pm on September 17, 2013 Permalink | Log in to Reply

        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.

        • mrwweb 9:27 pm on September 17, 2013 Permalink | Log in to Reply

          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.

          • Avryl 9:43 pm on September 17, 2013 Permalink | Log in to Reply

            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.

          • ntl0820 2:36 pm on September 18, 2013 Permalink | Log in to Reply

            That’s actually a great idea! I think an animation effect would immediately give attention of where those tools are.

            • @ubernaut 2:31 am on September 19, 2013 Permalink

              that makes me think of z-targetting in zelda 64 for some reason.

    • Avryl 3:47 pm on September 19, 2013 Permalink | Log in to Reply

      @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.

      • Sam Sidler 10:38 pm on September 19, 2013 Permalink | Log in to Reply

        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.

    • Johannes Fosseus 7:15 pm on September 20, 2013 Permalink | Log in to Reply

      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)

      • Avryl 8:00 pm on September 23, 2013 Permalink | Log in to Reply

        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.

    • Ryan McCue 1:10 pm on September 21, 2013 Permalink | Log in to Reply

      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.

      • Avryl 8:09 pm on September 23, 2013 Permalink | Log in to Reply

        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.

    • carloroosen 12:18 pm on September 23, 2013 Permalink | Log in to Reply

      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.

    • Avryl 7:55 pm on September 23, 2013 Permalink | Log in to Reply

      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!

    • David 11:51 am on September 24, 2013 Permalink | Log in to Reply

      Is it planed to keep the dependency on mp6 in future? I like the front-end editing but not the mp6 backend style.

      • Avryl 11:55 am on September 24, 2013 Permalink | Log in to Reply

        mp6 will be the new back-end style, so yes it will depend on mp6 until it’s part of core.

    • mrwweb 3:37 pm on September 24, 2013 Permalink | Log in to Reply

      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.

      • Avryl 1:22 pm on September 25, 2013 Permalink | Log in to Reply

        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.

        • mrwweb 6:52 pm on September 25, 2013 Permalink | Log in to Reply

          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.

    • landwire 8:25 pm on September 27, 2013 Permalink | Log in to Reply

      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.

    • landwire 8:37 pm on September 27, 2013 Permalink | Log in to Reply

      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.

  • lessbloat 6:22 pm on September 13, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    DASH Update 

    Accomplished this week

    1) We held our weekly IRC chat last Tuesday, and @joen shared the following:

    He also shared a whittled down version of the current “Right Now” widget which looks like this:

    These mockups solicited the following feedback:

    • Can we merge the “3 new comments since your last visit” and “recent comments” sections?
    • Under QuickDraft, let’s just start by showing the title. On keyup, the other elements will slide down.
    • Unclear what the three dots mean in the vertical divider (they’re drag handles). We’ll keep working on it.
    • Can we add the plugins widget into the new combined “News” widget somehow?
    • Note that multisite hides the plugins widget. Something to keep in mind as we refactor these.

    2) Joen worked up 2 additional mockups:

    Option A:

    Option B:

    3) In our Skype chat we brought up 2 additional things to think about:

    • What doe the activity feed look like when a user first installs WP? When there isn’t any updates, scheduled posts, or comments?
    • Where does the welcome screen fit into all of this?

    We need your help

    • We need developers. We’re ready to start building some of this out. But we need some core developers to join our ranks. If you have any interest, please leave a note in the comments.
    • Feedback on anything above is much appreciated.

    Up next

    We’ll hold another IRC chat this coming Tuesday at Tuesday, September 17th, 2:00pm UTC in #wordpress-ui.

     

    • Valerio Souza 6:28 pm on September 13, 2013 Permalink | Log in to Reply

      I’m totally available.

      • lessbloat 6:32 pm on September 13, 2013 Permalink | Log in to Reply

        Awesome. Ping me on in #wordpress-dev (I’m lessbloat), and I’ll get you added to our Skype room.

    • Robert Dall 6:29 pm on September 13, 2013 Permalink | Log in to Reply

      I really like where this is going… Great job so far. One Question that stick out in my mind is. I’ll still have the ability to have the Right Now in the top left corner if I want it right?

      • lessbloat 6:31 pm on September 13, 2013 Permalink | Log in to Reply

        If you have the activity feed disabled, yes. :-)

        With the activity feed enabled, no. But you could have it in the top right corner. ;-)

        The activity feed, as proposed will always stay fixed on the left side.

    • TimothyBlynJacobs 7:16 pm on September 13, 2013 Permalink | Log in to Reply

      I like the version 1 mockup much better than the first, I’d be interested in seeing an actual test of whether or not someone would identify that they can drag it. I’m not a big fan of the horizontal line under the title in the second mockup.

      I think when a user first installs WordPress it’d be cool if the dashboard was integrated with the theme chooser as well, like maybe show some popular themes to install. But I think you are asking about what it would look like when there is no information in the feed to show, which could theoretically often be the case on static CMS type WordPress installations with no blog posts or comments. I think it would have to be empty with like a no activity message, otherwise it might be disorienting for a new user if we used the space in a vastly different way when there is no activity, and then suddenly it changes to this weird view.

      I think the welcome screen should be the same. Just above the rest of the elements on the dashboard, the same way it is now.

      Another question I have is, how would comments pending approval be denoted? And should those float to the top of the recent comments list, regardless of whether or not they came after an approved comment i.e.,

      should it be

      –approved comment from september 10
      –approved comment from september 9
      –not yet approved comment from september 9
      –approved comment from september 8
      –not yet approved comment from september 7

      or
      –not yet approved comment from september 7
      –not yet approved comment from september 9
      –approved comment from september 10
      –approved comment from september 9
      –approved comment from september 8

      • Joen Asmussen 1:16 pm on September 14, 2013 Permalink | Log in to Reply

        I like the version 1 mockup better as well, and for the same reasons. We’ve decided to not mock up the slider further and wait for a prototype. We might find that the slider in itself is unnecessary. We might find it doesn’t have to be visible all the time, but could in fact be visible only when you mouse over the gap between left and right columns.

        That’s an interesting conundrum with the sorting order. From a high level perspective, the activity stream makes the most sense to me if it’s strictly chronological. However, two avenues are perhaps worth exploring:

        1: a pending comment can be pinned, thus jumping out of the chronology
        2: perhaps pending comments are grouped in a section separately

        Imagining the latter, you’d have a section showing maybe 5 pending comments (with more buried). You’d mouse over the top one, click “approve”. Immediately when approved, the comment fades to white, then animates down below to the “recent comments” section. That way, if you need to moderate many comments in a row, you don’t need to move the mouse, because the next pending comment would jump up where the one you just moderated were.

        Perhaps that’s worth a GIF mockup.

        • TimothyBlynJacobs 5:01 pm on September 14, 2013 Permalink | Log in to Reply

          I love the idea of how you would be able to make “bulk” actions with option number 2. My only concern is that it would be adding another comments box to the stream area. I think there is a question that has to be asked before that decision is made, though. Where would plugins be able to hook into the stream. Currently, it seems that there are three separate and distinct streams: comments, updates, and publishing soon, all of which are awesome, and need to be there in some way. But currently, I don’t see where plugin authors would be able to hook into the stream. If the idea is that they would hook into what is now called the “Recent Comments” stream, then perhaps that needs a renaming, and option 1 certainly doesn’t make much sense, and a distinct comments approval area should be created. However, if comments are going to remain a separate stream altogether, then I don’t think it would be so disorienting.

          In one part of my mind I think the dashboard stream can be categorized into three separate areas. The past, the present and the future :) , i.e.

          The Past – recent comments, perhaps backups that just completed, or any other event that happened in the past.

          The Present – things that the user has to take action on currently, pending updates, pending comments, posts by “authors” that need approval, or in plugin territory, maybe contact form submissions that need a response.

          The future – things to notify the user about, future posts, for plugins, an event plugin could tap into it and have maybe 1 or 2 events happening in the near future.

          These sections are already there, but the titles aren’t correct, currently they are too narrow. Adding hooks for plugins might be out of the current scope of the project, but if they were ever added in a later version, it might be worth it to have those sections distinguished already.

          So I think you were spot on with one of your earlier mockups that had the icons. At that point in time it seemed that they weren’t necessary because it was essentially only the pin icons and the comment icons. But if plugins are able to use this area, it would make sense to pull from the icon that they are using on the main menu, so that users are able to see that continuity. I don’t think the icons need to be as pronounced as before, but I think they would be extremely helpful for distinguishing between the different notifications, especially if the comments section, for example, is changed to like things that happened recently, it would be necessary to distinguish comments, from backups, or anything else a plugin might add.

    • Nick Halsey 8:57 pm on September 13, 2013 Permalink | Log in to Reply

      I can help with development!

      I think we could do an iteration of the welcome screen to replace (or go above) the activity feed for new sites, also addressing the lack of activity for new installs. But that screen is definitely one of the only good parts of the dashboard currently.

      I think it would probably look better if the featured widget was after the WordPress Planet feed. And we should look into ways to hide release posts from the official blog if the site has already been updated.

      • lessbloat 9:06 pm on September 13, 2013 Permalink | Log in to Reply

        Nick, great. Ping me on in #wordpress-dev (I’m lessbloat), and I’ll get you added to our Skype room.

    • Paal Joachim Romdahl 10:29 pm on September 13, 2013 Permalink | Log in to Reply

      New users need guidance where to go and what to do after logging in the first time. How can we guide them?

    • Paal Joachim Romdahl 11:23 pm on September 13, 2013 Permalink | Log in to Reply

      I was looking at Unity 3D and the bottom part reminds me of a Dashboard area (even though it is not):
      http://unity3d.com/
      I share it to give additional inspiration. Perhaps we should look at web pages and share the ones that gives an association of a Dashboard.

    • rockethouse 12:43 am on September 14, 2013 Permalink | Log in to Reply

      Hi guys,

      I’m a front-end developer who could help out with theming the UI. I’ve actually started mocking and building up my own Admin template ( http://www.behance.net/wip/241237/455345 ) which I want to release one day. But keen to help work-on and build the default admin theme.

      Cheers

    • Erlend Sogge Heggen 7:59 am on September 15, 2013 Permalink | Log in to Reply

      I’d love a “Hide” (Tooltip: Hide this from the front page) option for the updates. As an example, bbPress 2.4 was recently released, but shortly after there were some pretty annoying bugs reported. So, I decided to stick with the latest stable version until 2.4.1 comes out. So in the new dash, I’d want to keep that hidden until a new version pops up.

← Older posts

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel