WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Updates from August, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Siobhan 9:22 pm on July 7, 2014 Permalink
    Tags: feature-plugins, ,   

    Feature Plugin: Improving Image Editing 

    Image editing in WordPress isn’t fun. It’s possible, but it isn’t fun. Bringing image editing into the media modal was pretty awesome. Now people can edit images from the modal (yay!) but they also realise how frustrating that image editing experience is (boo :( ).

    WordPress is not an image editing platform, but we do offer some minimal image editing tools and, since they’re there, they should be intuitive instead of anger inducing.

    Image editing is an area that’s ripe for improvement, so we are proposing an image editing feature plugin to see how we can improve things.

    At the WordCamp Seattle contributor day, myself, @sonjanyc, @mor10 and @DH-Shredder started some discussions about how we can improve the image editing experience in WordPress. Below is what we discussed:

    What we want to provide to users

    • a set of simple image editing tools that just work (crop, rotate, scale)
    • image editing tools that integrate better with image uploading workflows
    • image editing tools that are easy to access
    • an interface that is extensible so that plugin developers can create advanced image editing which can be easy integrated

    Process
    We discussed the process for the way forward with the project:
    1. Creating personas and workflows
    2. Conducting interviews with user types (photoblogger, food blogger, tutorial writer, multi-author blog editor, etc)
    3. Looking at how other platforms provide image editing functionality
    4. UI mockups
    5. Design
    6. Coding
    7. Testing

    Tickets related to image editing

    And here are some mockups that were done around 3.5 from @lessbloat

    If anyone would like to be involved in this project, please let us know. We have a Skype group and we can start kicking off weekly meetings, either in IRC or Google Hangouts. It’s in the very early stages and we’re planning to take things slowly since we all have other commitments, but we can get things moving more quickly if with more involvement.

    Here are some things you could help out with:

    • conducting user interviews and writing up the research
    • researching other platforms, writing it up, providing screenshots
    • mocking up workflows
    • mocking up the UI
    • designing the interface
    • coding like a boss
    • coding like a backbone boss
    • user testing
    • feedback, insight, rants, cheerleading

    You can email me to be added to the Skype group or let us know in the comments

     
    • Marko Heijnen 9:31 pm on July 7, 2014 Permalink | Log in to Reply

      First of all why Skype and not something public. Secondly please add me to it. This is also something I discussed multiple time with @DH-Shredder and lately also with @ericlewis. I was planning to bring this up during his weekly Media Component Office Hours on friday’s but due internet issues I didn’t had the change yet.

      • Siobhan 9:56 pm on July 7, 2014 Permalink | Log in to Reply

        Will add you to the group. Skype is great for asynchronous communication and IRC is not. We’re in a number of different timezones and IRC isn’t great for that. However, I agree that it’s better for things to be transparent- we’re investigating the best way to publish the Skype logs online. If you have any idea on the best way to do that, that’d be awesome :)

      • Mike Schroder 10:28 pm on July 7, 2014 Permalink | Log in to Reply

        This is early early stages of “let’s do something about this.”

        I’ll note that I’m actually trying to stay as disconnected with the early process as possible, since a lot of brainstorming with regards to user flow is helpful here.

        That said, anyone who is interested is super welcome, and agreed that it’d be good to bring it up in the Media office hours.

    • Mike Schinkel 10:37 pm on July 7, 2014 Permalink | Log in to Reply

      @Siobhan – I’d really love to get involved, but with #metadata I think I’d be overcommitted. So, here are some thoughts about what I think is really needed:

      1. Core needs to add a concept of “Image Type” that can be added using PHP code (i.e. maybe add_image_type( $type, array( 'label' => $label, $sizes = array( 'small' => '75x75', 'medium' => '200x150', 'large' => '500x300', 'xlarge' => '1024x768') which would allow core to generate only the sizes needed for those types, allow for easier filtering of images (by type) and empower plugin and core developers to enhance UX for functionality related to images. Examples of types might be “headshot”, “hero”, “featured” and so on.

      1b. Once we have image types and sizes, filenames could be augmented with that information, i.e. instead of jsmith-500x300.jpg files could be renamed to jsmith-large-headshot.jpg.

      1c. And if core does not do 1b., at least it could remove the sizes from the filenames when it resizes a file so that you don’t get this kind of name jsmith-500x300-75x75.jpg but instead just get jsmith-75x75.jpg

      1d. Note the sizes I included above are not the same aspect ratios so it would be nice of by setting those sizes for a type that WordPress core would present a UI to the user to crop those sizes separately.

      2. It would really be nice if core could add an option to generate image files on demand the first time an image is externally accessed rather than on upload so that you don’t end up for an order of magnitude more image files on disk then are actually ever used.

      Anyway, thanks for listening.

      • Mike Schroder 10:55 pm on July 7, 2014 Permalink | Log in to Reply

        Thanks @mikeschinkel! Agreed that core could use a bit of enhancement as far as its image APIs go. I think this project is more focused (especially in early stages) on re-thinking the way we handle image flow in a general sense.

        That said, enhancements to existing image APIs can be considered at any time, and are probably best handled as tickets/patches in trac so that they don’t need to be held back by a feature plugin. Is there already a ticket for your suggestion? If not, I think that’s a great idea to post there for discussion.

        • Mike Schinkel 11:00 pm on July 7, 2014 Permalink | Log in to Reply

          Thanks @Mike Schroder; I just added those comments to ticket #21810, not sure if I should have created a new ticket or not.

          If image types were added then it would open up lots of possibilities for UX (that IMO could be significant improvements) so that’s why I suggested here.

          BTW, I previously implemented image types for a library used by many of one of my client’s sites, which helped a lot with UX, but I had to make some pretty nasty hacks to get it to work because core really didn’t envision those kind of enhancements.

      • Eric Andrew Lewis 2:32 am on July 8, 2014 Permalink | Log in to Reply

        Suggestions like this would be more productively discussed at a Media component weekly meeting rather than dumped on a semi-related blog post.

    • Chase Wiseman 11:01 pm on July 7, 2014 Permalink | Log in to Reply

      I’m really excited that this is being discussed and would love to throw my hat into the ring here.

      The bulk of the WordPress work I do is in building custom themes and plugins for clients. These often call for location-specific image sizes such as “hero” or “profile photo”, as @mikeschinkel mentioned. Along with an overall revamp of the image editing workflow, I would love to see a way for users to crop for these specific image sizes as part of the uploading/saving process.

      Granted, that’s a specific example that’s close to my heart and I’m sure others will have their own, but I think the key to enabling these will be making the editing workflow, interface, and underlying APIs as extensible as possible for plugin and theme developers.

      I hope to be able to contribute to the mockups and code when the time comes.

      Cheers!

    • Eric Andrew Lewis 2:37 am on July 8, 2014 Permalink | Log in to Reply

      @siobhan – I’m glad you’re taking the reins on this. During my gardening on the Media component I found a good number of minor bugs in the image editing experience, which led me to the same conclusion: let’s scrap what we have and build anew.

      I am eternally available for any JS architectural needs, and interested in UX/UI discussions. You have my Skype ;)

    • Graham Armfield 10:43 am on July 8, 2014 Permalink | Log in to Reply

      Please can we make sure that accessibility is considered when people are thinking about design and development of this. At the very least there needs to be a way of doing all this that doesn’t rely on the use of a mouse. We also need to ensure that there is enough information available to screen reader users too.

      Please contact members of the Make WordPress Accessible Team if you need help or guidance on this.

    • jlmaners 11:50 pm on July 12, 2014 Permalink | Log in to Reply

      I’m new to the Make community but as a WordPress user for almost 8 years and a WP focused developer for the past three, I’m really interested in this discussion and would like to throw my name into the ring if not too late.

      I work for a large University that is slowly but surely utilizing WordPress as THE tool for the majority of our websites across campus. My unit specifically encourages this and is active in the development of WP as a platform for our faculty, staff, and students looking to publish sites for research groups, departmental home pages, etc. I have a lot of different users of differing skill sets and differing use cases who I know would love to provide feedback.

      Please let me know what contact info might be needed if I can assist. Definitely don’t want to get in the way!

  • shaunandrews 5:14 pm on September 24, 2013 Permalink
    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

    • Weston Ruter 6:15 am on September 30, 2013 Permalink | Log in to Reply

      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/

    • Paal Joachim Romdahl 9:54 am on October 5, 2013 Permalink | Log in to Reply

      Woo Themes have made a very nice plugin: http://wordpress.org/plugins/woosidebars/

    • Michael Arestad 3:44 am on October 22, 2013 Permalink | Log in to Reply

      Initial thoughts after our earlier discussion: Reorder widgets without dragging

    • jameskoster 9:19 am on October 22, 2013 Permalink | Log in to Reply

      I have an idea regarding widgets I’d like to share, not sure if this is the right place (maybe trac would be better) but here goes.

      A problem I run in to quite often is adding widgets to a region via Appearance > Widgets. Well, not adding them, rather finding them. When you have a couple of big plugins activated, or a theme which adds it’s own widgets (ick) the Available Widgets box gets very crowded. I normally end up using ⌘F to find the one I’m looking for.

      So maybe add a ‘quick add’ text field to each region. Something like http://cl.ly/image/20212D1M332J . Typing in this input would load a live search with results dropped down beneath the input. Click the appropriate result and it’s inserted. If no results are found you could even include a link to search the plugins repo on .org.

      Or maybe this is an edge-case and would be better as a plugin? thought I’d share the idea anyway..!

  • Mark Jaquith 3:52 pm on April 11, 2013 Permalink
    Tags: post format ui   

    @saracannon has posted her take on a new direction for post format UI, addressing some of the concerns that surfaced after @lessbloat‘s tests. Re-thinking WordPress Post Format UI.

    The one that is closest to what I was thinking, and the best balance between showing the new UI (to people who are already using post formats or who have a theme with special support), and getting it out of the way once you’ve chosen, is the “In Page decision with post editor greyed out” one.

    post-formats-classic-i-copy-1024x698

    I’m curious to know what the UI team thinks. I’d like action taken on this ASAP, so that we can get the UI settled for beta 2.

     
    • Terry Sutton 3:59 pm on April 11, 2013 Permalink | Log in to Reply

      The modal doesn’t feel quite right to me. A) So many sites are adding those ultra-annoying modals, and It would feel a little like that to me, and B) with the exception of the Media modal, i feel like it doesn’t fit with the current UI direction. It’s very well done, so I don’t want to sound too critical, but it doesn’t feel quite right to me.

    • Mel Choyce 4:01 pm on April 11, 2013 Permalink | Log in to Reply

      Was just about to post this below, but I guess it belongs here now:

      I love these explorations! I know we don’t want increase the barrier between thought and post, but I do think that by choosing to write a post, you’re already making a decision. I like that we’re prompting users into action by making them decide on a post format. I wish we could test this with a selection of .org users, who might have different goals and behaviors than .com and tumblr users.

      Going on to the individual exploration, I’m not a huge fan of modals — especially since they never seem to act correctly on a small screen — but I can see them being a handy solution here. What would happen if someone automatically closes the modal, though?

      Overall, I agree with Mark — I definitely think #2 is the right direction. It makes a lot of sense to me, especially since it’s bringing you to the right screen and prompting you for action without the distraction a modal window might have. It helps directly reinforces how your decision effects what you’re posting. With a modal, there’s a little bit of a disconnect between what you choose and how that changes what you see.

      Building on this, I can also envision a setting that allows you to set your default post format, which would highlight your default when you land on the new post page and have the others greyed out. Alternately, we could do the selected/default icon in color and leave the others b+w. Power users, people who just post one type of content, or even professionals creating sites for clients could set defaults or disable formats entirely, and I think #2s method would make any of those changes easier.

      • Mark Jaquith 4:08 pm on April 11, 2013 Permalink | Log in to Reply

        So I was thinking that if you clicked into the post editor or title, it’d select Standard and let you go on your way. Just like before. And we could give focus to the post title, and select standard if you just started typing a title. Again, just like before. So this way you can’t miss the new UI, but you can also just skip past it when you just want to start composing.

    • esmi 4:09 pm on April 11, 2013 Permalink | Log in to Reply

      The perennial issue with modal windows is ensuring that they are fully accessible to those using screen reading software or those who don’t use a mouse. Ensuring this level of accessibility can put a lot of additional strain on the UI devs. Is that really something you want to impose at this stage of the game?

      • Mark Jaquith 4:13 pm on April 11, 2013 Permalink | Log in to Reply

        I’m not advocating that we use a modal. I agree with your concerns (and have more of my own). See above comments. Updated post with screenshot to be clear about the approach I was talking about.

    • sara cannon 4:13 pm on April 11, 2013 Permalink | Log in to Reply

      The greyed out area can also surface and choose “standard” as a format when clicked / tapped

    • Ipstenu (Mika Epstein) 4:17 pm on April 11, 2013 Permalink | Log in to Reply

      Would it still be possible to switch between? Sometimes I change my mind, and one thing I HATE about how Tumblr does it is that I have to totally start over :/ I Even if there was a warning that any standard specific content would be lost, the main part of the post below I’d like to keep.

      • Chip Bennett 4:19 pm on April 11, 2013 Permalink | Log in to Reply

        Looks like the sidebar meta box is retained – or, is rolled into the Publish meta box, as a dropdown or radio select.

      • sara cannon 4:20 pm on April 11, 2013 Permalink | Log in to Reply

        Yes, in the publish meta box there will be a switcher. I also think this is essential

        • Terry Sutton 4:53 pm on April 11, 2013 Permalink | Log in to Reply

          So I’m clear — the switcher won’t stay above the post title as it is now in Beta1? IE: the icon bar will go away after you’ve made your choice?

          • Mark Jaquith 4:59 pm on April 11, 2013 Permalink | Log in to Reply

            That’s the idea. Big and up top on first load. Tucked away once you’ve chosen (either explicitly or implicitly). Addresses the two big issues we’re having in beta 1: not obvious enough before choosing, in the way after choosing.

            • sara cannon 5:00 pm on April 11, 2013 Permalink

              and resolves any potential confusion for users that might think they can use all the buttons/formats on one post

            • Terry Sutton 5:06 pm on April 11, 2013 Permalink

              Ok. In that case, I’m split on the idea of it going away to a metabox, or staying above the post title as it does in Beta1. So after you’ve chosen which post type, here’s what you see: http://cl.ly/image/2g1f3o2D3m1U

            • Brian Richards 5:36 pm on April 11, 2013 Permalink

              I can’t decide whether or not I’d like for the UI to disappear completely after choosing my post format. I do like the notion of “putting it out of the way”, but what happens if I’ve accidentally clicked/tapped the wrong format and wanted to quickly click/tap on a different one — is the UI only removed after I begin entering content?

              I know from the explanation that the UI just gets moved into the Publish metabox, but it’s unlikely I would know or expect this behavior otherwise.

              The alternative of keeping it in place (and dimming the unselected choices) doesn’t sound like a great solution either because, as already discussed, it stays in the way and could lead to later confusion about the purpose of the buttons (e.g. “is this how I add a link to my post?”).

              Tough call…

    • Chip Bennett 4:17 pm on April 11, 2013 Permalink | Log in to Reply

      +1 to “In Page decision with post editor greyed out. Icons will go away and the “switching” will be in the sidebar like above.” It looks great, and appears to be a huge improvement to what we have now (3.5.1 and 3.6 beta 1).

      -(Eleventy Frillion) to a modal.

    • Robert Dall 5:06 pm on April 11, 2013 Permalink | Log in to Reply

      OMG you are awesome @saracannon I loved how you covered all the bases here… A couple comments.

      The Modal system as @AndyPeatling put it on twitter. “Not sure forcing the UX would be well received for dot org though. Most don’t care or use them.”

      The Post format switching as a radio button would to far to long leading pushing the category, tags, feature image to push them lower in the window.

      Icons with Text +10,000 looks awesome!
      One comment regarding the icons getting greyed out on the hover is it is opposite of the hover state in the admin menu on the left. We should keep the standard hover over icons the same through out the admin section of the site.

      Can we choose icons only or text only or both like Apple offers in there mail application? It seems that would suite the best of both worlds.

    • Tom Auger 5:08 pm on April 11, 2013 Permalink | Log in to Reply

      Really love this new direction. The in-your-face visual icons really bring this often-underused part of the post to the front.

      My only comment is – does the editor really need to be greyed out? Should we not just default to “Standard” and then let the user switch it up from there. I can just see a ton of bloggers who don’t currently use post formats get really annoyed when we add another click to the process.

      • Robert Dall 5:15 pm on April 11, 2013 Permalink | Log in to Reply

        I see your point most bloggers will choose the standard post… It beta1 it already chooses standard by default and I think we should keep it that :-)

      • sara cannon 5:19 pm on April 11, 2013 Permalink | Log in to Reply

        Mark pointed out above that we will still have the title field focused like normal – so start typing like normal and there is no extra “click” and standard is chosen for you

    • Ryan Cowles 5:38 pm on April 11, 2013 Permalink | Log in to Reply

      Awesome work, Sara! These concepts look rad.

      While I don’t have much to say in regards to the UI itself, I think this part is important: “you can turn all post formats off from within core settings to override what your theme set. ”

      If a new step in the post creation flow is introduced that forces the user to select a post format, I think the user should be allowed to disable it. Therefore users that only use one post format aren’t forced to go through an unnecessary step each time a new post is created. Just my $0.02.

    • Helen Hou-Sandi 6:04 pm on April 11, 2013 Permalink | Log in to Reply

      I think this is a good compromise between representing the “choose once” part and not blocking users from just writing a new post as they currently can. What’s currently in trunk definitely does not reflect that it’s (generally) a one-time format selection before you get started. I think with smart wording in the feature pointer letting the user know that they can turn this off in screen options in addition to the filter that’s already been committed, it will work out okay.

      Question about the “just start typing to make a standard post” interaction, though – what happens to the switcher? Does it disappear and cause everything to shift up while the user is typing? That seems less than ideal to me.

    • Chip Bennett 6:09 pm on April 11, 2013 Permalink | Log in to Reply

      Crazy thought: what if the big ol’ post format icons were stacked vertically, to the left of the post editor (i.e. a third column on the post-edit screen)?

      Still have the everything-grayed-out-before-selection UI, but then let the icons remain where they are after selection.

      That would allow for easy switching, and would not cause the UI to jump around with appearing-then-disappearing icons above the post editor.

    • thirzah 6:13 pm on April 11, 2013 Permalink | Log in to Reply

      (random person chips in) Love it – but minor thought – if they are at the top, and (what looks likely to be) more meta boxes pushing post/data entry ever downwards, would it be possible to make the ‘publish’ box pinnable, or copied at the bottom, or something? – Yours, Lazy Scroller :)

    • sara cannon 6:19 pm on April 11, 2013 Permalink | Log in to Reply

      For responsive screens, we can wrap the icons. because they will be eliminated after choice – we don’t have to worry about real estate

      980: ​​http://s.sar.ac/image/3B2H2v0P1841
      768 ​Option 1: http://s.sar.ac/image/1D1e002x2i0X (5 across slightly spread out)
      768 Option 2: http://s.sar.ac/image/2a3u3v3E3p03 (5 across slightly spread out & centered)

    • nathanrice 6:30 pm on April 11, 2013 Permalink | Log in to Reply

      I have some deeper issues with the new Post Formats, but first let me say that I like the idea of a “decision first” approach with the ability to change in the publish box. Makes a lot of sense to me, and doesn’t clutter the post UI with buttons. It’s a little out of the way, which may have UX implications, but the initial decision path more than makes up for that.

      As for the Post Formats strategy itself, I’m troubled by the decision to turn this feature on by default. From reading through a few trac tickets, I can see the logic behind why this decision was made, but it still seems like it’s going to be a bit of a shock, especially to theme developers who may not see this coming, and certainly to users who will now have a UI that their theme isn’t at all prepared for.

      If this is the wrong place for this discussion, please tell me where I can go to bring this up with the powers that be. I’d like to understand the rationale if there was no other alternative, but otherwise, I’d like to see if there isn’t a better alternative than what we’ve got currently. And if my initial assumption is incorrect, I apologize.

    • Hal Gatewood 6:39 pm on April 11, 2013 Permalink | Log in to Reply

      Rough potential tabbed idea… http://goo.gl/143Zu

    • Drew Jaynes (DrewAPicture) 7:40 pm on April 11, 2013 Permalink | Log in to Reply

      I really like this concept a lot better. Plus, there’s parity with the hide/show overlays we used in the menus UI refresh.

      The thing I’ve consistently heard from talking to people about the new formats UI is that an intermediary choice step would solve a lot of the headaches and I think take this approach over what we have now will be a big step in the right direction.

    • Archetyped 4:18 am on April 12, 2013 Permalink | Log in to Reply

      “In Page decision with post editor greyed out” seems like the best option as others have noted.

      I agree with @markjaquith that clicking the title/description fields should automatically select the default post format and close the selection UI, however, I would suggest it be even a bit more flexible than that. I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format (e.g. standard post) and close the post format selection bar just as if someone had selected the format itself. This allows for a much larger hit target for the user to get to the editor and start creating content without much delay.

      I think it was also suggested that the post format selection UI go away immediately if the user starts typing in the title field (focused by default). I like this as well.

      In addition, how about an option in WP’s settings to allow the user/author to set the default post format. The editor fields for the selected post format’s would be displayed by default when creating new posts and the appropriate button would be highlighted in the post format selection UI.

      This would be a productivity boost for users who post mostly videos, or mostly links, or mostly status messages, etc.

      • sara cannon 4:53 am on April 12, 2013 Permalink | Log in to Reply

        “I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format ” — yes! I’m not sure if this was mentioned in the above threads but this is definitely something that should be included.

        @melchoyce also has mentioned the idea of setting a default post format in a comment above. I think that idea should definitely be explored further and is a logical next step. Part of why I think this is – we have ten formats with no hierarchy for preference.

    • Grant Palin 6:48 am on April 12, 2013 Permalink | Log in to Reply

      I generally dislike popups, modal or otherwise, when they are not really necessary. I could have made an exception in this case since the choice it would provide would determine the appropriate UI. It’s something that kinda needs to be done up-front.

      That said, it’s still a jarring change, and the better option may be the row of icons above the editor, which maybe shrinks or fades when a choice is made in order to stay out of the way. At least it’s top and center that way.

    • Avryl 11:24 am on April 12, 2013 Permalink | Log in to Reply

      I don’t really get the concept of selecting a post format. All post formats do more or less the same, you can add media, add a title, add a description/content. Why not just have one and detect what’s posted?

      Or maybe, have two buttons in the media uploader, one “insert in post” and one “make an image post”, same for a gallery, video and audio. When the user adds a link to the content, give the option to make a link post. Maybe this would be more obvious if there’s an “add link” button next the “add media” button or by somehow integrating them both in TinyMCE. A status post can be created if there’s no title.

      I’m just wondering, but what happens when a user inserts an image into the content of a standard post format and nothing else? Then that would be an image post right? Maybe it’s possible to detect if the user assigns the “wrong” post format, as in the UI test?

    • jrbeilke 2:45 pm on April 12, 2013 Permalink | Log in to Reply

      Nicely done Sara. I also prefer the in-page decision for post formats and think it stands out more than the current beta UI without being too obtrusive.

      I am concerned about all of the new decisions that a writer will be faced with when adding a new post. At a minimum the screen options/theme support should help to control the available post formats. Defaulting to a standard post when no selection is made would also streamline the process for those that want to stick with their current workflow.

      Another issue that I’ve run into while testing is the admin Posts screen, and posts without a title. It would be nice to tweak the Posts screen to show a snippet from the post if no title has been set. Maybe it’s just me, but with some of these new post formats (ie Aside and Status) a title isn’t necessary, but makes administration difficult without it.

      Posts without titles – http://i.imgur.com/M40SwIR.jpg
      Mockup Posts with snippets – http://i.imgur.com/WtwfSnt.jpg

      • Konstantin Kovshenin 2:46 pm on April 12, 2013 Permalink | Log in to Reply

        Related/possible solution: #24011

        • jrbeilke 3:09 pm on April 12, 2013 Permalink | Log in to Reply

          Thanks, didn’t see that ticket.

          Looks like it might work, but if it’s tied into save_post then what if there are already existing posts without titles? Will the user have to go through and re-save all of the posts that are missing a title?

    • Matt Mullenweg 8:10 pm on April 14, 2013 Permalink | Log in to Reply

      Also as food for thought: we’re supporting too many formats. Anything where you’re giving a user 10 choices before they get started is going to be rough from a usability and design perspective, especially given it’s not really obvious what that choice does not just to the form, but to the post when it’s published.

      There is some direct and indirect data about which formats are most used, perhaps we could apply our 80/20 principle to just supporting the 3-4 formats that would make the biggest difference to users.

      • Ipstenu (Mika Epstein) 3:49 am on April 15, 2013 Permalink | Log in to Reply

        What if you consolidate?

        Image and Gallery – Make it one, and if someone puts in an image, it shows just one. If it’s a gallery code, or they attach mulitple images, then use a gallery? To steal a page from Tumblr, that’s how they do it.

        You could do the same for audio/video maybe. Though that would be harder to theme in both cases.

        • sara cannon 10:51 pm on April 16, 2013 Permalink | Log in to Reply

          ^ I really like this solution – we just use the format “image” in the UI, but then when a user attaches more than one, it automatically makes it the “gallery” format in the background (no need to manually switch). It solves a UX problem where someone might decide to upload more than one after-the fact. (image->gallery is really one of the main use cases for decision-changing that I foresee)

      • Mark Jaquith 12:46 pm on April 15, 2013 Permalink | Log in to Reply

        The formats have been defined in code and in the codex for a while, so dropping some formats would result in data loss for some.

        One thing that has been considered is hiding less-used formats, so that instead of 10 options, you might have 5 options and a “more” button.

      • Ian Stewart 3:21 pm on April 15, 2013 Permalink | Log in to Reply

        +1 for hiding seldom used formats.

      • Andy Peatling 5:09 pm on April 18, 2013 Permalink | Log in to Reply

        I posted usage stats for frontend WordPress.com posting here: http://core.trac.wordpress.org/ticket/19570#comment:154

    • chabis 10:32 pm on April 17, 2013 Permalink | Log in to Reply

      There needs to be some careful rethinking about the post formats. two assumptions:

      A. many users want to create a post with a single content (gallery, audio, image, etc) and a post format is fine for that.
      B. many other user want to create a post that contains an image, a text, another image, then a video, etc.

      Now how do you make clear to the user that A. is not equal to B.? A. is a complete view change from a Post to a Gallery whereas B. is a Post with multiple content elements.

      In my point of view, and as mentioned before, the user gets confused by post-formats and the icons. Especially the icons can me users think that they need to click on the format to insert a media. And at the same time the decision hurdle is too high, maybe a user changes its mind during the editing process, what do you do then?

      Maybe we need to think about the editor in a slightly different way. It should be intelligent enough to make assumptions with the added and future content. The text-editor of koken.me is just a wonderful inspiration for that:

      http://help.koken.me/customer/portal/articles/632095-text

      • Anointed 6:37 pm on April 21, 2013 Permalink | Log in to Reply

        WOW, just WOW, that koken admin is SWEET! Especially the media manager. thnx for the link, not sure I would have ever found it on my own. Really gives the WordPress media manager something to aim for.

    • Anointed 6:34 pm on April 21, 2013 Permalink | Log in to Reply

      Not sure where to make this request, but this seems as good a place as any.

      I actually like the new post-formats setup, especially the video format where the actual player shows up on the page after clicking publish. This makes it so much easier to understand what is happening and to make sure the video oEmbed url works and you have the right video.

      My only request, is it would be nice to have the video player display PRIOR to clicking publish.

      Right now, we are able to make sure we have everything else right prior to publishing, but cool as this new player showing up is, we still don’t know that everything is perfect prior to publish as we can’t see the player.

      So, please make the player show up as soon as the oEmbed url/embed code/etc is inputted into the box.

  • Helen Hou-Sandi 4:03 pm on January 31, 2013 Permalink
    Tags: , post formats   

    Have made it through the second round of user testing videos for post formats (thanks, @lessbloat). These were on core as-is, using Twenty Twelve as the theme. Should have switched to San Kloud to enable all formats, but it actually may not have made much of a difference for these. There’s a third round still to watch and annotate.

    Tasks:

    1. Login
    2. Look at the Dashboard and get to add post from toolbar
    3. Add a (standard) blog post with title and text
    4. Preview your blog
    5. Add an image blog post, with image from a URL
    6. Add a video post, with YouTube video URL provided
    7. Add a link blog post
    8. Add a quote blog post
    9. Add a gallery post
    10. Preview your blog again to see all the posts

    Test 1: http://wpusertesting.com/videos/DC7-3.mp4

    1. Fine
    2. Fine
    3. Takes a moment finding the Publish button, but otherwise fine.
    4. Fine
    5. Notices it says nothing about a title; adds one anyway. Uses Add Media -> Insert from URL.
    6. Again goes to Add Media -> Insert from URL. Inserts the video, which gets linked. Doesn’t work for oEmbed to have it linked :( Again adds a title herself
    7. Again goes to Add Media -> Insert from URL, but says she doesn’t think she’s doing it right. Tries to click the link that’s inserted in the editor to check if it goes to the right place.
    8. Corrects then to than :D Adds it as plain text in the editor.
    9. Add Media -> Media Library (woo!) Selects the three images using multi-select and inserts them all into the post.
    10. Checks the sesamestreet.org link, which works. Then she closes the tab, so it’s over before getting to see some things like video.

    Overall observations:

    • She never once noticed the post formats metabox or wondered why the instructions were telling her to write blog posts of various kinds.
    • Not having a title bothered her a bit, perhaps because it looks so important/required.
    • The media modal certainly seems usable/comfortable, as she kept returning to it and was really quite handy with it.

    Test 2: http://wpusertesting.com/videos/DC7-4.mp4

    1. A little copy paste mishap, but otherwise fine
    2. Fine
    3. Scrolls to look for the Publish button, then has to digest the whole Publish metabox to find the button. After publish, does not expect to stay on the edit screen, because she’s “done” / ready to move on.
    4. Fine
    5. Opens the URL and drags the images over to the other tab directly and drops into TinyMCE. Observes that more and more things on the computer support drag and drop, so it’s a familiar mechanism.
    6. Looks immediately for embed code. Copies and pastes code into the Visual editor; observes that it doesn’t show her what it will look like. Says that she would preview the post, but the test doesn’t say to do so, so she doesn’t. Wonders if there’s another way to embed; finds the format metabox. Selects “Link” and updates. Notes that changing and updating doesn’t seem to make anything look different. Wonders what it’s for – maybe a layout, but doesn’t make a difference to her.
    7. Remembers the format she discovered in the last task and selects it. Notes she wants selecting a format to come before adding information (not sure if flow or layout wise); because it’s under Publish she doesn’t notice it, and considers anything under there to be of use after publishing. Says she always previews/checks posts for formatting on her own blog :) Wonder what she uses…
    8. Selects format – “What is the difference here, exactly?” Is really expecting the editor area to change with selecting a format; wonders what the value even is.
    9. Selects Image format, presumably because Gallery isn’t available in Twenty Twelve. Looks around and eventually finds “Add Media”. Figures out to use shift to do a multiselect. Inserts them all; wonders if she did something wrong but notices that it’s formatted/shows images in the editor. Now wonders if Add Media should have been used for embedding the video to get a nice formatted view.
    10. Notices the “Link” flag on that post, but it doesn’t seem otherwise formatted. Considers lack of formatting in various posts to be a consequence of her mistakes.

    Overall observations:

    • Whenever a user thinks that it is their mistake that something didn’t make a difference or work right, we really need to look at how to fix that – to help them avoid the mistake in the first place and feel confident that they know what to do or can figure it out.
    • This could have been one of us testing such a feature. Her observations are all very astute – there’s no value in selecting a format when editing, which was further enforced by the theme display; the location on the screen is counter-intuitive to workflow; oEmbed is buried/not discoverable (and not just by WP); creating galleries as opposed to batch insertion is not something naturally thought about; and “Add Media” quickly becomes a familiar place to do more than insert images or upload files.
     
  • Helen Hou-Sandi 12:21 am on November 16, 2012 Permalink  

    Coming soon: Weekly updates 

    Part of the duties of a team rep for each area of contributors is to be responsible for a weekly update on the group. At this moment, there is not an established UI team rep, but as a core development team representative, I’m happy to step in until new elections are done sometime in the near-ish future.

    Part of our UI group discussion at the Community Summit was about how we can make these weekly updates both informational and effective, especially when it comes to attracting and retaining contributors. Here’s what we’re thinking:

    • A breakdown of what we did this week, such as discussions held (with links to IRC as applicable), patches uploaded/worked on, and what’s changed in core in a more prose-y manner.
    • Links to ideas from the community at large, which would likely be blog posts on other sites, including your own. Discussion would be encouraged over on those posts rather than here – the creator should be able to really take ownership and pride in their idea and be centrally involved in the discussion. The idea is to both expose some of the great ideas that are happening and open up a platform for idea generation that isn’t “from the top” or carrying the official weight that gets associated with a post on the Make P2s, which are largely status-driven rather than hypothetical.
    • Weekly IRC chat summary with anything not covered above.
    • What needs to get done this week, including any assignments that have been made and ones that need volunteers. We’re thinking this will be a great step toward exposing more ways to get involved in case you’re still figuring things out.

    Thoughts? Love it, hate it?

     
    • karmatosed 10:11 am on November 16, 2012 Permalink | Log in to Reply

      I really like this idea be great to keep up with things. The last point will help greatly in finding ways in for me and others also so that’s really cool. Not everyone can every time get to the IRC meeting so it’s a great way to keep up to date and involved.

    • McGarityDotMe 11:59 am on November 16, 2012 Permalink | Log in to Reply

      All of this helps me out, as I’m trying to get my feet wet and understand more about sub-groups like this I’m interested in participating with. The IRC chats have been where I’ve started, but that’s often like jumping into the deep end of a pool after a swim lesson. :) I especially like the last bullet point, as it’s not immediately clear to this n00b what’s in flight, what’s about to start, etc.

    • lessbloat 12:19 pm on November 16, 2012 Permalink | Log in to Reply

      Yep. +1 to all of it. :-)

    • Jane Wells 1:56 pm on November 16, 2012 Permalink | Log in to Reply

      I was going to post this proposal to the team reps blog, and will, but since you posted this, I’ll pre-empt myself and post my thoughts here as well.

      I’ve been thinking more about this since our team reps discussion at the summit, and I’m still thinking we should re-jigger the UI group. When we talk about core UI, it really seems like that discussion should be happening as a part of the core project, rather than sidelined as a separate group. When I started the UI group, it was because we weren’t a project that really had design contributors yet, and I wanted to change that, but it would have been disruptive to try to get that started on wpdevel (as it was called then). Now that it’s make/core, and now that there are a number of designers (members of this group) participating actively in core, I think it’s time for a change to recognize that core UI is not a separate project, it is an integral part of core.

      At the same time, there are design needs across the WordPress project, like for events, documentation, site improvements, etc. Just as developing a system of team reps was intended to put other contributions on a level with core, I believe it’s time to rethink the UI group altogether.

      What I’d like to see is the stuff going on as “the UI group” currently to be treated as a regular core component (with component owner, if that’s still the plan post-summit) rather than an entirely separate group. I’m thinking the same thing about Accessibility. If something isn’t a separate, sovereign group that gets to make decisions (in this case, UI decisions still are ultimately made by the core team/release leads, not by a standalone UI group), then it should be an active part of the main group. In other words, I think it’s time for UI contributors to level up to the main core team. Updates about what is happening with core UI would be part of the regular core team updates.

      Then, we’d create a Design Corps of all the designers (graphic, interaction, web, print, you name it) that would be contributing to the project as a whole, rather than just core, and to all design needs, not just UI. Each of the contributor groups would have its own embedded contributing designers (like the core ui contributors), while the design corp *group* would be a place to share resources, discuss design problems across teams, and for team reps to post requests for design assistance when needed. This would solve several problems (other groups don’t have design resources, and they see the UI group as limited to CSS or usability).

      I will admit that this is basically a ripoff of how Automattic handles design (just as our new contributor group blogs and team reps are a ripoff of Automattic’s team updates system). The Automattic design group system has been in play for three and a half years now, and I think it works really well. It allows designers to be integral members of project teams, while also being part of a broader design group.

      Anyway, I’ll be proposing this to the team reps for consideration, but would like you guys to be thinking about it, too. @lessbloat and @chexee, as UI Group members who have experienced the Automattic model first-hand may be the best able to comment on whether it is a good model.

      • Helen Hou-Sandi 2:40 pm on November 16, 2012 Permalink | Log in to Reply

        +100000000000 to the overall direction of this group within the project as a whole. Siobhan’s post about handbooks earlier is in a similar vein – UI isn’t a separate handbook, but a component of each contributing area’s handbook. I also think it would be really helpful to promote areas beyond the core web application for folks to actively contribute to – it’s definitely different than ideas for, say, a website. I see plugin developers especially liking having a way to join forces with UI/UX-minded types :)

        P.S. Hey everybody, do get involved in the handbooks if you’re able and willing!

        • Siobhan 6:47 pm on November 17, 2012 Permalink | Log in to Reply

          Yes! Handbooks are cool and awesome and people should get involved!

          Also, I think a design corps group is an excellent idea. I have been thinking that we’ll need design people to help out with making the handbooks look beautiful and I had no idea where to look. This would solve the problem for me :D

      • lessbloat 5:17 pm on November 16, 2012 Permalink | Log in to Reply

        Love it. I think that’s a great idea.

      • Mel Choyce 8:06 pm on November 16, 2012 Permalink | Log in to Reply

        This sounds like a great way to create more opportunities for designers to get involved. Awesome idea!

      • studionashvegas 11:13 pm on November 17, 2012 Permalink | Log in to Reply

        Multidisciplinary groups like what you’re suggesting are very common in the agency setting, and (from what I’ve experienced) seem to work very well, as all of the parts know what’s going on (which leads to a more cohesive experience).

        +1

      • karmatosed 11:53 pm on November 17, 2012 Permalink | Log in to Reply

        Sounds like a great idea and gives lots of scope for getting involved which is really cool.

      • Amy Hendrix (sabreuse) 2:26 pm on November 18, 2012 Permalink | Log in to Reply

        Yay! Destroy the silos!

      • Chelsea Otakan 10:12 pm on November 18, 2012 Permalink | Log in to Reply

        The Design Corps within Automattic work pretty well, IMO. We are a tight group and do our best to communicate well with each other.

        I really like the concept of spreading out the UI group to include design across the WP community. A lot of designers want to pitch in, but their skills might not be the best fit for core, but there’s currently no formal way to pitch in anywhere else.

        In short: Jane said all the things already :) Sounds great to me! Weekly check in post for each group would be helpful.

      • Sheri Bigelow 4:39 pm on November 27, 2012 Permalink | Log in to Reply

        +1 I like the proposal. Seems to me developers would be more likely to reach out to a multifaceted design group vs. the current setup which is pretty intensely focused on Core UI.

    • acsearles 4:35 pm on November 16, 2012 Permalink | Log in to Reply

      I’ve sat on the sidelines for a long time, wanting to get more involved but not knowing where to get my feet wet. I’ve been following along, reading what I can and trying to stay up-to-date on the happenings of this group. So, I think this could help more people have an easier entry point into contributing. So I can continue to keep watching and when I see some low hanging fruit I’ll be able to pick a few things off. Eventually, as I get more of a grasp about what’s going on, I’ll be able to contribute in a more substantial way.

      Jane, I also really like the idea of designers becoming apart of other groups that are working on other projects. I know that in my line of work I do best when working on a team of people with different skill sets, then coming back to the group of designers to share ideas and critique.

      Sounds like so many good things came out of the summit. I’ll be excited to get started. And hopefully we can see everyone in Birmingham at our next WordCamp. Which reminds me, @saracannon, we need to get that started really really soon.

      a

    • RDall 5:44 pm on November 16, 2012 Permalink | Log in to Reply

      I really like where this is going… I also agree with what Jane said as well… The UI group should be more then just the core dev… As I have struggled to find a place that I can contribute too that both use my strengths and fits WordPress needs as well…

  • lessbloat 4:16 pm on October 12, 2012 Permalink  

    Wow, loving the feedback that came in about the welcome screen. Thanks everyone!

    I’ve got another design challenge for ya. What (if anything) can be done for the “add new” buttons?

    They don’t really look like buttons to me. I tried simply adding the new default button style, but I wasn’t a fan. Thoughts on how these could be improved?

    Mockups welcome… :-)

     
    • Drew Jaynes (DrewAPicture) 4:26 pm on October 12, 2012 Permalink | Log in to Reply

      For reference, here’s what it looks like with .button-secondary applied (and vertically aligned): http://cl.ly/image/2z0s00030a0M

    • Helen Hou-Sandi 4:27 pm on October 12, 2012 Permalink | Log in to Reply

      They probably shouldn’t be conceived as buttons because it’s really a link to another screen, not an action on the current one.

      • Andrew Nacin 9:53 pm on October 12, 2012 Permalink | Log in to Reply

        Yes. As MT said elsewhere in this thread, it wasn’t designed to be a button. It’s a glorified link, not an action for the current screen.

    • Will Norris 4:28 pm on October 12, 2012 Permalink | Log in to Reply

      I think border shown in the screenshot Drew linked to goes a long way to call out that it’s a button. It probably wouldn’t even need to be that dark, unless you’re concerned about not having enough contrast.

    • esmi 4:28 pm on October 12, 2012 Permalink | Log in to Reply

      Can you re-use the button-primary class? As this is used for logins, publish actions etc. it should feed into the the “this is a button/action” mindset created by the rest if the UI/

    • saltcod 4:34 pm on October 12, 2012 Permalink | Log in to Reply

      A colour invert doesn’t make it more button-y, but certainly makes it more prominent:

    • JerrySarcastic 4:45 pm on October 12, 2012 Permalink | Log in to Reply

      Why not add one of @saltcod icons? Makes it pretty easy to understand what it does at a glance, without it being *too prominent*

      • Drew Jaynes (DrewAPicture) 4:46 pm on October 12, 2012 Permalink | Log in to Reply

        It’s an interesting idea but then I feel like the pin icon and the button icon are competing, with ‘Posts’ mashed in between them.

      • Ben Huson 12:42 pm on October 16, 2012 Permalink | Log in to Reply

        Also, for custom post types the icon may not be appropriate. Think “Add new Podcast” – A document icon probably isn;t as appropriate for that.

    • saltcod 4:48 pm on October 12, 2012 Permalink | Log in to Reply

      Nice. Like this.

    • lessbloat 5:03 pm on October 12, 2012 Permalink | Log in to Reply

      One note: I don’t think the change needs to be all that drastic. From a UX perspective, I don’t think the link is broken. People see it, and they click it as is. I just feel like the design feels off somehow (like it’s a leftover artifact from another admin design era).

      • lessbloat 5:08 pm on October 12, 2012 Permalink | Log in to Reply

        One idea I had was a lighter treatment with a flat background:

        Again, this link doesn’t need to command the attention of the user, it just needs to fit in.

        Other thoughts?

        • lessbloat 5:20 pm on October 12, 2012 Permalink | Log in to Reply

          Seems weird that there is semi-button treatment with blue text though…

          • JerrySarcastic 5:22 pm on October 12, 2012 Permalink | Log in to Reply

            Agree, it should be a button or a link, but probably not styled to look a little like both… You’re right that the change doesn’t need to be huge though; I like this look overall, minus the blue text.

        • Reji Thomas 6:04 pm on October 12, 2012 Permalink | Log in to Reply

          This treatment seems more in line with the rest of the screen’s workflow.

      • Daryl Koopersmith 5:22 pm on October 12, 2012 Permalink | Log in to Reply

        I just feel like the design feels off somehow (like it’s a leftover artifact from another admin design era).

        These styles were actually was added in the most recent redesign as the style for links in page headers. @iammattthomas would probably remember a bit more about the design decision.

        • Matt Thomas 9:09 pm on October 12, 2012 Permalink | Log in to Reply

          The idea, more or less, was to make the link stand out a bit more than a standard text link, but we specifically tried not to make it look like a button. as @helenyhou stated above, it’s a link to another screen, not an action. That’s the usability reason; but also visually the primary and secondary button styles seem way too heavy to use here.

          • Helen Hou-Sandi 9:17 pm on October 12, 2012 Permalink | Log in to Reply

            Thanks for the history, @iammattthomas :) I need to spin up some old version installs for more reference – I seem to have lost the ones I had. I hope others will take heed of this being a link and not a button as ideas are explored. Although, I’m impressed at how closely the comments have stuck to the spirit of the prompt!

    • lessbloat 5:28 pm on October 12, 2012 Permalink | Log in to Reply

      Another take:

      • Mel Choyce 6:20 pm on October 12, 2012 Permalink | Log in to Reply

        The color on this one feels off — it’s too desaturated. It doesn’t really fit with the other blue we’re using.

    • Drew Jaynes (DrewAPicture) 8:07 pm on October 12, 2012 Permalink | Log in to Reply

      I think @saltcod‘s is the best I’ve seen so far with button-primary. Here are three different screens of it:

    • Drew Strojny 8:59 pm on October 12, 2012 Permalink | Log in to Reply

      I like the primary action button too. I’d vote for shrinking the text size down to 11px on the button and making the text more descriptive of the action, adding some more space (above the h2 and to the left of the button), and increasing the size of the h2 and lightening it slightly.

      Add new post variation

      (I used a larger screenshot to show it with more context)

    • saltcod 11:17 pm on October 12, 2012 Permalink | Log in to Reply

      If just ‘fitting in’, as @lessbloat said, is the goal, I think the blue button style is a bit strong. A bit softer is inverting the colours as I mentioned above (swapping font-color and background-color). Perhaps @lessbloat‘s touchup of the original is enough? http://make.wordpress.org/ui/files/2012/10/add-new-mockup.jpg

      • memuller 2:18 pm on October 13, 2012 Permalink | Log in to Reply

        Agreed; @lessbloat‘s work is enough. Even so, if it can be somehow made to be even more bland, I’d go for it. It really, really, shouldn’t look like a button, since it’s not one in any way.

    • alberrrrt 4:21 am on October 13, 2012 Permalink | Log in to Reply

      Thanks for deep review of one button :) That’s my first attendant on this #BLOG, sounds like wierdo but it’s true :) And deep inspirational came after the first seeing of this conversation at once :)

    • lessbloat 2:55 pm on October 13, 2012 Permalink | Log in to Reply

      What if we just added a smidgen of padding, and a very very faint drop shadow?

      Original is on the top for comparison:

      • Ipstenu (Mika Epstein) 2:28 am on October 14, 2012 Permalink | Log in to Reply

        That’s nice. Subtle and yet I know ‘Click this to make stuff happen’

      • memuller 12:25 am on October 16, 2012 Permalink | Log in to Reply

        Nice indeed; it draws just the right amount of attention.

      • Ben Huson 12:47 pm on October 16, 2012 Permalink | Log in to Reply

        I prefer this option so far.

        A blue button feels too prominent.
        A text-only link does not feel prominent enough.

        I am open to the idea of using an icon as long as it is a generic icon like a “+” or something, rather that a document icon etc

    • @mercime 6:02 am on October 14, 2012 Permalink | Log in to Reply

      What if we add a simple arrow after “Add New” like so: Add New ->
      Arrow can represent call to action and new panel. Then hover can be blue with white font and arrow.
      [ Sorry, can't do a mockup right now. ]

    • kingbt 2:02 pm on October 15, 2012 Permalink | Log in to Reply

      Hi. Add New is a very important button and think that it should be blue (like WordPress 3.5 Publish button http://make.wordpress.org/ui/2012/10/12/wow-loving-the-feedback-that-came-in-about/#comment-22500 ) or at least white (with or without icon) like this http://make.wordpress.org/ui/2012/10/12/wow-loving-the-feedback-that-came-in-about/#comment-22486 but not flat.

    • Isaac Keyet 3:53 am on October 16, 2012 Permalink | Log in to Reply

      To preserve the hierarchy and not use the standard button style, I think it should just be a regular text link that’s made more prominent by association alone. After all, isn’t it confusing to style a link “a little” like a button if it’s clearly not supposed to be one? Having that secondary “in-between” type of navigation item doesn’t resonate so well with me.

      This is what I think makes the most sense for a link that is supposed to link to another page as highlighted in the main (sidebar) nav:

      This makes the page 8px taller though, not sure if that’s a concern.

      Anyone interested can append this CSS to try it:

      .wrap .add-new-h2 {
      background: none;
      margin-left: 44px;
      line-height: normal;
      padding: 0;
      float: left;
      clear: left;
      }
      
      .subsubsub {
      clear:left;
      }
      
      • karmatosed 10:14 pm on October 23, 2012 Permalink | Log in to Reply

        I really like this option. I’m not too keen on the blue backgrounds / buttonification of it. It’s not a button so shouldn’t be treated like it.

    • toscho 5:37 pm on October 16, 2012 Permalink | Log in to Reply

      How about removing the link? We have two other instances on this page and could just make the ‘+ New’ in the admin bar make stand out better.

    • Sebastian 7:39 am on October 17, 2012 Permalink | Log in to Reply

      What about adding a “+” icon next to a simple text link?

      Preview: https://www.dropbox.com/s/u2twyhxblxsrtk2/wp-add-new.png

    • KentonWebDesign 2:29 am on October 31, 2012 Permalink | Log in to Reply

      Why not maybe direct the button more towards the operation, like so?
      https://www.dropbox.com/s/g1w19z8uwsbfp4u/addnew-button-wordpress-v1.jpg

      or even use the lighter grayish style taking from the dash color scheme?
      https://www.dropbox.com/s/3xoa1nrg47ul4lv/addnew-button-wordpress-v2.jpg

      Might work, right?

    • Whirl3d 10:40 am on October 31, 2012 Permalink | Log in to Reply

      Personally, having used computers since before the internet, I don’t really have a strong memory of button functionality ever being an integrated piece of a section section header (other than maybe a close /min/help buttons). That is certainly not to say that it hasn’t been done or that I don’t see it every day and don’t think of it as such, just that I don’t think to look in my section header for a button unless it is strictly a ui-button that affects the object holding the header (like a close/minimize button). It would just make more sense to revamp the entire grid header for content types to include the basics like ADD, EDIT, LIST and then make them available in one and only one place. But if you are sold on the add new function being added to the header, why not follow most browser tab menus? Put a tab with + Add New tab behind it ghosted until moused over like the + tab in Google Chrome?

  • lessbloat 3:23 pm on September 21, 2012 Permalink  

    I sent a user through the new page on front flow, as well as a few steps in the customizer (including the new color picker). I sort of cheated on this one by telling him exactly where to click at times, but the purpose of this test was not to test if he could get there, but once he got there if the changes we’ve made make sense.

    Here’s the video, and my notes:

    Step One notes – Log in

    No problems.

    Step Two notes – Add static front page

    No problems.

    Step Three notes – Preview your blog

    2:19 – “So people can leave a comment on my homepage?” (see my note below)

    Step Four notes – Go to customizer

    No problems.

    Step Five notes – Change your tagline

    No problems.

    Step Six notes – Change your background color

    4:23 – Unfortunately, the new color picker failed again, even with the new “current color” tooltip. User simply clicked the right hue selector, and assumed that the color had been changed to blue.
    5:55 – “Ah, I have to drag this, oh. Well that was a little bit confusing”, as he goes back to the customizer color selector and discovers that he has to move the puck in the left-side box.

    Step Seven notes – Edit your home page

    7:31 – Makes it to the home page to edit it, but then says, “Alright I’m confused”.
    8:30 – Goes back to dashboard, “How come this doesn’t look the same as what I was just messing around with”, referring to the customizer.
    9:09 – He’s getting confused from my instructions, I said “Change the title” but he’s thinking about the site title, which he saw in the customizer. I’ll have to fix my wording here.

    Recap

    • He pointed out that comments are turned on for his static home page. Should we consider turning comments off by default when a static home page is enabled?
    • Having to click twice to select a color is still confusing.
    • Having the static auto-generated “home” page be blank might be a bit confusing. Perhaps we could pre-fill the page description with a bit of helper text. Something like, “This is your new default home page, you can edit the content of this page via the pages section of your dashboard.”.
     
    • Sheri Bigelow 4:10 pm on September 21, 2012 Permalink | Log in to Reply

      8:30 – Goes back to dashboard, “How come this doesn’t look the same as what I was just messing around with”, referring to the customizer.

      The difference is a little jarring if you’re not aware of the differences. It’s interesting to see stuff like that through the eyes of beginners.

      Should we consider turning comments off by default when a static home page is enabled?

      I would argue that some people do want comments on for a home page and some want them off. My assumption though, is that more people would want them off, so having them off by default seems like a good idea.

      Having the static auto-generated “home” page be blank might be a bit confusing.

      Maybe include a link to some documentation with the pre-filled text?

    • Isaac Keyet 8:35 pm on September 21, 2012 Permalink | Log in to Reply

      4:23 – Unfortunately, the new color picker failed again, even with the new “current color” tooltip. User simply clicked the right hue selector, and assumed that the color had been changed to blue.

      Makes sense – the left hand side only shows “one color” to the user, with a different white/black balance.

      In order to make the deadline we may want to consider simply “resetting” the left side (removing the picker bit) after you’ve changed the hue. The text could then read “no color selected and perhaps an outline is set to the left side.

      A better long term solution would still be a UI which puts the focus on the color instead of the shading of it, e.g. http://cl.ly/image/3B3S1q343218

    • NewClarity 11:46 pm on September 21, 2012 Permalink | Log in to Reply

      “He pointed out that comments are turned on for his static home page. Should we consider turning comments off by default when a static home page is enabled?”

      Oh please! I was begging for this years ago.

  • lessbloat 3:52 am on August 30, 2012 Permalink  

    Ticket scrub notes 8/29

    Needs patch

    Ready to commit

    Has owner, needs patch

     
  • lessbloat 1:04 pm on August 22, 2012 Permalink  

    Ticket scrub notes for 8/21

    Patches needed

    Status update

     
    • Helen Hou-Sandi 7:07 pm on August 27, 2012 Permalink | Log in to Reply

      I just realized that I never made meeting notes for the week, but this is not far from being them, so I will leave it alone. Just want to note that seeing the on-time progress on the welcome screen/panel and color picker by all involved parties was awesome! And also Sergey’s patch for page on front :) UI group rocks!

  • Helen Hou-Sandi 9:29 pm on August 15, 2012 Permalink
    Tags:   

    Meeting summary for 8/14 

    Note: meeting on 8/7 did not really happen, as many were traveling or otherwise out of commission post-WCSF.

    Meeting was largely focused on status check of various items and really bearing down on assignments and breaking down tasks into what can be realistically accomplished within a given time period (the next week) so we can regularly check in. Setting the goal is not the maximum that can be achieved – only the minimum. Things finished early or with aplomb are highly encouraged :)

    Reminder: devs should ideally be focused on one large item at any given moment. Working on your own pet projects and roaming around is always fine, but would prefer to stay away from overcommitment, especially for point people. This includes me :)

     
    • Kurt Payne 6:51 am on August 16, 2012 Permalink | Log in to Reply

      @helenyhou I can help with #21391!

      • Helen Hou-Sandi 1:09 pm on August 16, 2012 Permalink | Log in to Reply

        YAY! I will hit you up soon, then. I’ve also got blobaugh, maybe jeremyfelt, maybe tw2113, and possibly tomauger (although I think he is on the ImageMagick stuff as well; trying to avoid doubling up).

    • Shane Pearlman 11:43 pm on August 16, 2012 Permalink | Log in to Reply

      Thanks Helen, stoked to participate in brainstorming. Will work on the document.

      Things that we often debate that would be fantastic to get guidance:

      • When do you combine content into a single meta panel in a post type vs create a new meta panel?
      • When do you create a new submenu vs combine into a submenu
      • What is the proper ux for condensing long settings / form content (tabs?)
      • Thoughts on advance form permutations > thinks like chosen and select 2 which are wonderful aids, but aren’t standardized
      • Inline documentation styles

      • Helen Hou-Sandi 12:38 am on August 17, 2012 Permalink | Log in to Reply

        To be honest, I don’t think it is possible to provide be-all-end-all documentation on the first four items. The documentation would amount to something like “do what feels right and makes sense for your situation” – we can’t possibly expect software-specific guidelines to actually teach what usability means and what creating usable interfaces entails. That’s the issue that I sense will be run into in the end: we can have guidelines for the WordPress community, and we can create awareness via guidelines, but they are not a proper medium for a crash course in human-computer interaction. However, I’d love to be proven wrong, so please do work on the document, and perhaps try to find a time to have an actual discussion beyond notes on said document.

        Inline documentation styles sounds like something that could be looked at, though, and current core usages documented and ideas proposed for extension cases those don’t cover. What we really need is to get bodies on http://dotorgstyleguide.wordpress.com/ (or move it somewhere we can put more people on) and work on items that fall under the current style guide umbrella directly.

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