Make WordPress UI

Updates from April, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 3:52 pm on April 11, 2013 Permalink | Log in to leave a Comment
    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:

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

        I about it being more prominent. I also tried it with a rudamentary + symbol down next to Bulk actions:

      • Ipstenu (Mika Epstein) 5:09 pm on October 12, 2012 Permalink | Log in to Reply

        This one, unless we have an intermediary blue (tertiary?) css for less bold. I like the blue background better than an icon + words.

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

    • Welcome screen/panel refinements are still chugging along after @lessbloat‘s paternity leave (CONGRATS). Latest iteration at http://make.wordpress.org/ui/2012/07/24/welcome-screen-design-v2/#comment-22349. Discussed possibly having different paths based on whether or not a static front page is assigned. @lessbloat, @melchoyce, and @chexee are looking at the UX/language side. @sabreuse and @georgestephanis are on the dev side. Would like UX/language nailed down before next meeting and rough patch started. Testing can start anytime there’s something testable. Dev-wise, all hook-ability issues should be addressed this go-round. Tickets: #21368, #21331
    • Color picker. @mattwiebe and Devin Price worked on this at WCSF dev day, going with integrating Automattic’s open source Iris color picker, and will continue to work together toward a patch. @mattwiebe worked with us directly on some UI/UX picking and will continue to refine. Designers welcome to take a look and give feedback as well. @koopersmith is on JS consult. We should be able to knock out the consistency issue while we’re at it. Would like to see basic implementation in at least one place (settings screen or customizer – both are needed for final product) by next week. Tickets: #21206 and #19616
    • Cookies are on offer for a solid patch on #16379. There are some finer details that need consideration, such as editing screens and title + slug. More details in the IRC log: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-ui&day=2012-08-14&sort=asc#m51505
    • @tddewey put up a nice big patch for the remainder of the admin UI images needing HiDPI treatment on #21019. Leaving this to @azaozz for review and dropping in, now that gradients are in and extraneous images have been deleted.
    • I (@helenyhou) am on #21391 as my singular dev task – using the post edit screen for attachment editing, and any CPT support and edit screen enhancements that come with. It is quite full of rabbit holes. Would love a dev partner or two (or more) on this – have some leads now thanks to dev chat.
    • Media. @koopersmith is working on making those lovely wireframes a reality. @azaozz working on preview in the editor: #21585
    • Bonus item: UI/UX guidelines for plugins and themes. Discussion stemming from http://wp.smashingmagazine.com/2012/08/08/help-us-help-wordpress/, with a rough potential document started by @melchoyce at https://docs.google.com/document/d/1ZWPeUSFVYlMxClmHFjuAXuekXcZsLso49G3bDRquHcs/edit. Would just like to see how this might pan out in terms of a publishable document. Will be leaving my own comments over on Smashing Mag.

    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.

  • Daryl Koopersmith 4:03 pm on July 30, 2012 Permalink
    Tags: ,   

    Media Wireframes 

    Over the past week or so, I’ve worked closely with @lessbloat (Dave), @nacin, and @markjaquith to create a set of media workflows that will hopefully serve as a foundation and guide for the improvements in this release. (This is the fifth version of these wireframes — you can see the first four on Dave’s site.)

    The usual disclaimers: None of this is final. These are wireframes, so please focus your feedback on the experience, not the aesthetics. As for scope, we are focusing our changes on improving the modal experience. This focuses on the overall picture; not all of this will necessarily make it into the final release.

    So, without further ado…

    Wireframes and workflows — fullscreen recommended.

    The media library.

    The media library, while uploading three files.

    The attachment details screen.

    Relevant Trac tickets: #21390, #21391.

     

    • Scott Kingsley Clark 4:16 pm on July 30, 2012 Permalink | Log in to Reply

      Yes! WP 3.5 is easily the most anticipated release for me in a long while. This is beautiful!

    • Mel Choyce 4:18 pm on July 30, 2012 Permalink | Log in to Reply

      Looking good! I just noticed one thing missing — on the attachment details screen, there’s no longer an option for linking an image to a specific URL (like to another site).

      • Vitor Carvalho 4:20 pm on July 30, 2012 Permalink | Log in to Reply

        Maybe because you can do it in the editor, selecting the image and then click on “link button” which will give you more options than the ones you had before.

      • Andrew Nacin 4:22 pm on July 30, 2012 Permalink | Log in to Reply

        Not a deliberate omission — thanks for pointing that out. We should definitely look into making that UI support a custom URL.

        • krogsgard 5:34 am on July 31, 2012 Permalink | Log in to Reply

          I’d love to see an option to link to the parent post as well (or current post if media won’t include a direct attachment relationship anymore). This isn’t included now, but it’s a great time to add the ability, or at least a hook, which I don’t think is there now.

          Absolutely incredible work y’all. This is really, really great.

      • Russell Heimlich 4:59 pm on July 30, 2012 Permalink | Log in to Reply

        +1 for this. We use this feature a lot. Uploading an image then copying the URL of the image for use in a widget or somewhere else. If it were easy to select an image from the media library and reference the URL in something like a widget, that would be great as well.

        • Daryl Koopersmith 5:14 pm on July 30, 2012 Permalink | Log in to Reply

          Ah, I think you and Mel are talking about two different things (using a custom url when linking the image to in the post, versus the showing the permalink to the image itself), but you also have a point.

      • bradyvercher 5:20 pm on July 30, 2012 Permalink | Log in to Reply

        +1 for me, too. I’d like to be able to save a custom URL for each image and have that available as an option when inserting a gallery. I’ve found it useful for linking thumbnails to PDFs or press photos to external websites.

      • Brady Vercher 5:39 pm on July 30, 2012 Permalink | Log in to Reply

        This is looking pretty sweet! Great job so far. I had a couple of thoughts that might be outside the scope of this refresh, but would be nice to consider:

        Embedding the media iframe directly on a CPT edit screen (or potentially the gallery post format) without having to open the media popup would be killer. Inserting a gallery into the post editor doesn’t always make sense.

        Allowing a target field for the “Insert” button would be quite helpful for inserting an image into a widget or option field. Being able to specify whether the image URL, ID, or maybe a JSON object is returned would be even better. And can the “Insert” label be filterable?

        I’ve found it fairly difficult to re-crop an automatically cropped thumbnail and have it link back to the original image.

        Anyways, I’m looking forward to seeing how this turns out!

    • Vitor Carvalho 4:19 pm on July 30, 2012 Permalink | Log in to Reply

      Fantastic concept! This new release will give us a good reason to not install any other gallery plugin. :)

      • wlindley 12:42 pm on August 1, 2012 Permalink | Log in to Reply

        Unless you want to do something automatic, instead of manually. The AutoNav plugin, for example lets you resize thumbnails on-the-fly: [autonav display="attached" size="200x175"]… or sort by different fields (date, title), or automatically display the first few attachments, or display attachments from other posts according to their tags or category… things which are “reactive” as you change other things in the site, versus this UI which lets you manually control everything. Both can be useful.

    • Mert Yazicioglu 4:20 pm on July 30, 2012 Permalink | Log in to Reply

      I really like it, looks like the media management aspect of WordPress will finally get some love :)

      One question though, what happens when an image is clicked seem to differ from one action to another. I personally prefer this method but would that confuse the new users is what is bugging me.

      • Andrew Nacin 5:16 pm on July 30, 2012 Permalink | Log in to Reply

        It does differ, for sure. But we also think this will be intuitive, depending on what the user is trying to do. The different actions are glaring in the slide deck, but I doubt it will be as obvious when you’re actually using it.

        There’s also a “Back” button, and we intend for these dialogs to be lightning-fast, not full page reloads, so it’s easy to return to where you left off.

        But that said, this will all get heavily user-tested. And so if we find that we need to make modifications to our hover/click/next workflow, we will adjust it for sure.

    • Ben Huson 4:20 pm on July 30, 2012 Permalink | Log in to Reply

      I think the wireframes look really good.

      I particularly like the status to indicate the current selection.

      Not 100% convinced on the infinite scrolling but that may just be because I am used to paging – I like having the option of being able to browse the image library but easily jump forward huge jumps, or to the last page etc.

      Noticed one thing missing – there is currently an advanced tab when you edit an image which allows you to change classes etc.

      Also, it wasn’t clear what “Create a Gallery” does and wether you can create multiple galleries?

      • Andrew Nacin 4:31 pm on July 30, 2012 Permalink | Log in to Reply

        No, that Advanced tab is going to go away. That entire dialog goes through TinyMCE’s media handling, which makes for some awkward asymmetry. As implied in the “Edit an image” section, it opens the WP “Edit Media” window, not a TinyMCE window.

        We discussed this pretty extensively. If you want to set things like CSS classes, custom styles, borders, horizontal/vertical padding, etc., you should be opening the Text (HTML) editor and doing it yourself. There’s no need for a UI for this. It’s been quite the hidden UI (and a confusing one at that), so this isn’t much of a loss.

        • thenbrent 6:45 am on July 31, 2012 Permalink | Log in to Reply

          you should be opening the Text (HTML) editor and doing it yourself

          Praise! Ditch redundant UI.

        • Sheri Bigelow 2:33 pm on August 1, 2012 Permalink | Log in to Reply

          If you want to set things like CSS classes, custom styles, borders, horizontal/vertical padding, etc., you should be opening the Text (HTML) editor and doing it yourself.

          I don’t know. From my experience working with WP.com users, here are the things I think users will most miss from the advanced options:

          • Custom URL (I think you’ve already said it was overlooked and should be there)
          • Featured Image (looks like you’re adding that back too)
          • Alt text (accessibility-wise, it’s really not the same as title or description)
          • Explicit size settings (users use way more size options than the Settings → Media presets offer)
          • Border
          • Target

      • Andrew Nacin 4:36 pm on July 30, 2012 Permalink | Log in to Reply

        Yes, this will likely support multiple galleries in some way. I think multiple galleries are really important when telling a story with photos — we’ll see what we’re able to do.

        • Simon Wheatley (Code for the People) 4:56 pm on July 30, 2012 Permalink | Log in to Reply

          I think you are, but to check: do you & Koop envisage being able to add one attachment to more than one gallery, i.e. break the requirement for an attachment to be the child of a post in order to feature in a gallery on that post? (That would be cool… and I have some code to do it, but you won’t like it as it’s serialised in a meta.)

          • Daryl Koopersmith 5:06 pm on July 30, 2012 Permalink | Log in to Reply

            In a word, yes. We’re thinking of using the current post_parent-based connection to mean “this media item was uploaded to this post object”, and changing galleries to be an explicit list of IDs (using the existing shortcode). We discussed this a bit in dev chat last week.

            • Ben Huson 7:40 pm on July 30, 2012 Permalink

              Could galleries basically be a ‘gallery’ taxonomy for media or is an explicit list of IDs better?

            • Andrew Nacin 8:52 pm on July 30, 2012 Permalink

              @Ben We discussed this, and think that it would be better for now to continue with the ‘transient’ galleries, rather than moving to persistence with galleries as a taxonomy. We’d rather not conflate workflow changes with underlying schema changes, and a few of us don’t think that galleries necessarily work best as a simple taxonomy (as you only get a description out of it, for example). This is something a plugin can do for now. Ideally we’ll revisit it in the long-term.

            • Ben Huson 9:03 am on July 31, 2012 Permalink

              Makes sense.

            • Ben Huson 9:04 am on July 31, 2012 Permalink

              … maybe when we have taxonomy meta in core? ;)

            • Peter Chester 3:31 pm on August 15, 2012 Permalink

              +1 on @Ben’s p.s. about taxonomy meta :)

          • Andrew Nacin 5:08 pm on July 30, 2012 Permalink | Log in to Reply

            This is actually already doable. When you do there is no requirement for those images to be attached to the current post. We’ll be piggybacking on that.

        • GreenDiablo 3:03 pm on August 22, 2012 Permalink | Log in to Reply

          Love the new concept for the Media Library and the fact that multiple galleries are supported and you can select the images that go into the gallery (not mandated anymore by the images that are uploaded to a post)! Great job on the wires!

          Would love to get more involved and help work on UX/UI. Where do I best get started to help work on concepts etc. even in the early stages?

    • Brian Richards 4:21 pm on July 30, 2012 Permalink | Log in to Reply

      This is AB-SO-LUTE-LY amazing! Great work to everyone involved so far!

      Flipping through these, I think you guys have covered the entirety of what I was hoping to see in the media upload enhancements. I’m very excited :)

      As I was thinking about all the changes this weekend I pondered about the possibility of incorporating a drop-zone within the Featured Image metabox itself, so a user can drag-n-drop an image directly into the Featured Image metabox and it will upload and be set as featured. It’s likely this was already discussed somewhere and I missed it.

      If not, would you say that action falls in line with the rest of these changes?

      • Daryl Koopersmith 4:25 pm on July 30, 2012 Permalink | Log in to Reply

        Glad you like it! We’ve discussed integrating dropzones and other media bits outside the editor and decided that would be a bit too much for 3.5… but an easy first step will be to make the “choose a new x” buttons dropzones as well.

        As for featured images, depending on what we do with thumbnails, there’s a chance we’ll run them through the crop step as well.

        • Nick 9:17 am on August 10, 2012 Permalink | Log in to Reply

          If using a drop zone for the Featured Image metabox is too much for 3.5, might I suggest automatically setting the image as a featured image if the user opened the media window by clicking on the “Set featured image” link in the featured image metabox?

          The current workflow for setting a featured image (Click “set featured image”, upload the image in the media popover, scroll down and click “use as featured image” after it’s uploaded) is one that new users of WordPress seem to consistently trip up over, from my testing. (They forget the last step and wonder why the image isn’t listed as featured when they close the media window; they have already told WordPress that they’d like to set a featured image, after all.) Removing the need to click “set as featured image” would improve usability a great deal.

          Love the new changes, though. Great work!

    • Andrew Nacin 4:21 pm on July 30, 2012 Permalink | Log in to Reply

      I’ve had the opportunity to do in-person walkthroughs of this slide deck with a number of people who work with WordPress regularly, including @matt, a UX expert, a journalist, two developers, and a blogger. The feedback was overwhelmingly positive.

      It is great to have distinctive steps for the user, especially since they can jump into a specific dialog (such as jumping straight to the “Edit Media” screen from TinyMCE). However, when it comes to implementation, the screens are tightly coupled —

      One question I was asked (@matt brought it up, in particular) is at what point does a caption save to the DB against the attachment, and at what point is it stored only in the post (and no longer syncs)? @markjaquith, @koopersmith, and I literally spent a number of hours discussing this issue, and how it relates to the usefulness of attachment pages, etc. I *do* think there is a way to implement this seamlessly and intuitively, without forcing users to make a decision on where, when, or how something gets saved. (It should “Just work.”)

      Ultimately, we’re just going to have to put our heads together to work this out. And so I intend to have a discussion and resolution on this at the WordCamp SF Hack Day on Sunday.

      You’ll note that “Title” and “Description” are now omitted from the Insert/Edit Media screen. That is intentional, given how ridiculous it is to have four fields here, when these two apply only to attachment pages. See #21391 on how we hope to improve this by separating the UIs.

      • Archetyped 6:00 am on August 6, 2012 Permalink | Log in to Reply

        Great wireframes and great discussion thus far! This is probably something that many have wanted to see get an overhaul (myself included). Here’s a suggestion for handling instance-based media properties (e.g. caption, etc):

        The main difference is that selected images are displayed at the top. This is done for a few reasons:

        • Images to be inserted are clearly defined – when selected images are inline with entire media library, they can easily get lost in the noise– especially with infinite scrolling.
        • Changing order of selected images is straightforward – it’s not immediate obvious to users how to change the order of the selected images when they are inline with the rest of the media library. Will I be able to drag them around? Will moving an image affect its position in the media library as a whole?
        • Instance-based properties are made available only for selected images – For example, caption property can set once the image is selected. There is no reason for it to be accessible prior to this and it is clear that the properties being set affect the current instance of the media to be inserted (i.e. not saved to the DB).
        • Enables multiple instances of the same media to be inserted – An edge case, yes, but it also removes an arbitrary limit on how a user can build their content.

        Again, great work all, I look forward to seeing this progress!

        • Archetyped 6:12 am on August 6, 2012 Permalink | Log in to Reply

          Just a quick note regarding handling large quantities of selected images in the top area. There are several potential solutions, a few of which are:

          Carousel/slider display – Horizontally scroll through images.

          • Pro: Maintains a fixed amount of vertical spaced used by selected images to allow for maximal area for browsing through media library
          • Con: Can take time to horizontally scroll through many images

          Expand-o button – Hide selected images until done selecting all desired images. Then hit button (e.g. placed near “3 images selected” element) and grid of selected images takes center stage.

          • Pro: Allows quick and easy management of large amounts of selected images and keeps selected images out of the way until needed
          • Con: Requires an additional click to manage selected images

          Horizontal Row + Expand-o button – A combo of the best of both worlds. Display a single row of selected images, but hide additional images when more items than can be displayed until the “show all” button is clicked.

          • Pro: Small amounts of selected images can be easily managed without any additional clicks
          • Con: Requires an additional click for large amounts of images

    • Isaac Keyet 4:23 pm on July 30, 2012 Permalink | Log in to Reply

      Amazing work here. Even without a complete overhaul, the main window for browsing existing media library content or uploading new, which also combines a “shortcut” to create a gallery would be enough of an improvement going into 3.5.

      Some things I noticed/wished for while viewing the slideshow:

      • Edit image modal should probably have a Delete button to keep it consistent with the zoomed out view and it’s options – if Edit image is the expanded options it should have the same functions as the thumbnail and then some.
      • Since every upload to WP adds the media to the Media Library, it would make more sense (and save space) to have the “drop area” be the first item in the list from the media library, it would also help make the transition to showing uploads in progress make more sense.
      • Love the insert media button from the post editor itself, that addition in itself is a huge step towards increased usability. I’d argue it should be a part of the formatting toolbar though – especially if we’re going to fork TinyMCE.

      More to come, will need to let this settle for a bit.

      • Devin Reams 4:29 pm on July 30, 2012 Permalink | Log in to Reply

        Love the insert media button from the post editor itself, that addition in itself is a huge step towards increased usability.

        It looks nice but not sure how it’d work with multiple “types” of things to insert (forms, polls, other plugin features).

        • Andrew Nacin 4:38 pm on July 30, 2012 Permalink | Log in to Reply

          We’re really just styling the existing link + icon as a button, so I don’t think this is much of an addition, or how it’d affect other forms of media.

        • Isaac Keyet 4:40 pm on July 30, 2012 Permalink | Log in to Reply

          It’s true that it doesn’t really scale. Ultimately though, you’re inserting something into the body of a post, to me that should mean that it should be in the formatting toolbar itself (tinyMCE).

          In the meantime Insert/Upload Media could receive special treatment and be the only button there, while “secondary” options that plugins would add could be styled the old way with a label on the left.

      • Andrew Nacin 4:41 pm on July 30, 2012 Permalink | Log in to Reply

        A few thoughts:

        • The problem with “Delete” is, what does it mean? Does it mean you want to remove that image from the post, or do you want to delete it from the media library? What if you have it inserted in other posts or included in other galleries? “Edit Image” (as in, cropping, etc.) has its own troubles in this regard as well. We need to be careful not to conflate different things.
        • We considered this. But since that pane will scroll, you lose a persistent location for uploads. It doesn’t make sense. The nice thing about the persistent left location is that it can be used across a number of screens, and have a contextual response depending on the screen. For example, if you’re actively creating a gallery, your uploaded image can be added directly to that gallery.

        • Daryl Koopersmith 4:45 pm on July 30, 2012 Permalink | Log in to Reply

          But since that pane will scroll, you lose a persistent location for uploads.

          This is the main issue with using the dropzone as the first item (we debated it for quite a while). Also, on multisite, the dropzone is accompanied by several lines of text (space remaining, acceptable filetypes, etc), so squeezing that all into a single item would be a bit cramped.

          • Andrew Ozz 2:53 am on August 8, 2012 Permalink | Log in to Reply

            Imho the whole area should be upload drop-zone. Makes the most sense to drop images straight in the library, where the other uploaded images are (consistent with moving images from one folder to another on MacOS or WIndows).

            A Select Files button can be at the top for users that prefer to click something or use non-html5 browsers. Don’t see a problem if button is hidden when the page is scrolled down, the users would know where to find it.

            Alternatively can have a persistent (position: fixed) toolbar, much like the toolbar on other admin screens where the Upload button would be. Also good place for Help button, search etc.

          • Andrew Ozz 2:56 am on August 8, 2012 Permalink | Log in to Reply

            This would make the whole layout cleaner too. No need for thin “sidebar” and small drop-zone that might be hard to hit when dragging.

        • Isaac Keyet 4:47 pm on July 30, 2012 Permalink | Log in to Reply

          • To me it’s just a matter of labeling the delete action correctly, could even have different removal options and have primary and secondary removal actions. Default is to Remove from post, secondary Remove from Media Library (the latter should have a profound warning about the implications of removing the item from the media library). Image editing options “delete” button could simply be “reset”.
          • Regardless we need to consider smaller screen devices from the start, this layout assumes a wide computer screen. Uploaded media items on a selected post are automatically attached to the post, so why not have this be the selected section where you could compile your gallery? It would also be the perfect place to display help text like “You have not attached any media yet, upload or select from library below”.

          • Daryl Koopersmith 5:01 pm on July 30, 2012 Permalink | Log in to Reply

            Regardless we need to consider smaller screen devices from the start, this layout assumes a wide computer screen.

            Absolutely — most of this UI can be built in a responsive/reactive fashion. Mobile-sized screens will likely need a few extra changes, but hopefully we can make that experience just as smooth.

            Uploaded media items on a selected post are automatically attached to the post, so why not have this be the selected section where you could compile your gallery? It would also be the perfect place to display help text like “You have not attached any media yet, upload or select from library below”.

            • We’ve been discussing changing the meaning of “attaching” a media item to a post object (see last week’s dev chat for details).
            • Since we’re also looking to support multiple galleries in a post, we can’t immediately jump from batch upload to the gallery UI.
            • Help text and good copy will be key here.

        • Brian Richards 5:04 pm on July 30, 2012 Permalink | Log in to Reply

          I think the “Delete” action could be handled most simply by a confirmation modal for the user, “Are you sure you want to permanently delete this image from your entire site?” and then give them three very clear options, “Cancel”, “No, just remove it from this post”, “Yes, delete it site-wide”. We could even humanize it further by making the site-wide delete a red button.

          • Daryl Koopersmith 5:09 pm on July 30, 2012 Permalink | Log in to Reply

            Permanent delete will have to be well marked, that’s for sure. I dislike the idea of conflating both under a single “delete” action, though — that will only add to the confusion. Instead, we can just label each accordingly (we deal with “remove” versus “delete” in several other places in core in a similar fashion).

      • Isaac Keyet 5:49 pm on July 30, 2012 Permalink | Log in to Reply

        Some quick thoughts in images (playing with this).

        Uploading an image from the post editor has only one purpose, you want to use it in the post you’re editing somehow, most likely creating a gallery. This UI would be a better way to keep an overview of what you’ve done so far, and if you’re adding old images from the library even getting an overview of what’s selected and what’s not is going to be hard (imagine if you’ve “infinite scrolled” 2-3 page folds down, only way to get an overview then is to go to the gallery tab).

        Uploading media/inserting individual image. The last uploaded item(s) should be to the left, to origin from the drop zone. Assuming ascending sorting.

        Many attached items, some selected from library

        • lessbloat 6:33 pm on July 30, 2012 Permalink | Log in to Reply

          A couple thoughts:

          • Having 5 columns if space allows is a nice touch.
          • I still prefer to have the “Drop files here” box persistent on the side. If I scroll at all in these mockups, I would immediately lose the “Drop files here” box.
          • I don’t think the visual separation between “Selected media” and “Media library” really adds anything (except a few additional px of extra height ;-) ), in fact I like the idea that the lines between these two are blurred (everything you upload goes to the same place).

    • Devin Reams 4:27 pm on July 30, 2012 Permalink | Log in to Reply

      Cool stuff, great work everyone.

      One question I was asked (@matt brought it up, in particular) is at what point does a caption save to the DB against the attachment, and at what point is it stored only in the post (and no longer syncs)?

      We often have the same problem (training) when a ‘description’ or ‘caption’ is something dynamic (saved to db) and can be used consistently versus inline (when inserted)

      I also see a little bit of headache not being able to set the ‘Featured Image’ from the Insert/Upload screen as this is a pretty common workflow (again, training) that folks use: Upload > Set as Featured. Or Upload > Find image > Set as featured. Keeping in mind that some folks use multiple ‘Featured’ slots, too.

      • Andrew Nacin 4:33 pm on July 30, 2012 Permalink | Log in to Reply

        Upload > Set as Featured — that’s a good thing to keep in mind. That’s probably something we can add to the “Insert Media” dialog once you click “Insert.” Not quite the same workflow we have now, but, yeah… Keeping everything compatible with multiple featured image implementations is going to be fun, to say the least.

      • Daryl Koopersmith 4:34 pm on July 30, 2012 Permalink | Log in to Reply

        We often have the same problem (training) when a ‘description’ or ‘caption’ is something dynamic (saved to db) and can be used consistently versus inline (when inserted)

        This is a particular pet peeve of mine — I’d really like to find a way to communicate this well.

        I also see a little bit of headache not being able to set the ‘Featured Image’ from the Insert/Upload screen…

        One of the goals of this release is to separate out the various media workflows into their individual components. A side effect of that is separating inserting media into the post and setting a featured image. If testing reveals this to be a mistake, we can always discuss merging them back. That said, as with any UI change, will be a bit of an adjustment phase for existing users.

    • Scott Kingsley Clark 4:30 pm on July 30, 2012 Permalink | Log in to Reply

      Do we know yet how extensible this new UI will be from a plugin standpoint? Will the Media editor form be given proper hooks for adding additional fields? The current filters really stink and I bet we could do something much better during the dev of the new UI.

      • Andrew Nacin 4:35 pm on July 30, 2012 Permalink | Log in to Reply

        The priority is going to be keeping the current filters working, which isn’t going to be a cakewalk. But yes, this will be extensible.

        • Scott Kingsley Clark 4:36 pm on July 30, 2012 Permalink | Log in to Reply

          Excellent, that’s music to my ears, I’ve been working closely with these filters and know of their many failings, looking forward to seeing what we can put together that supports the old filters as well as improving upon them for the new UI’s needs.

    • Helen Hou-Sandi 4:39 pm on July 30, 2012 Permalink | Log in to Reply

      On the accessibility front (since I’ve promised to keep an eye on it):

      • We need to make sure that everything is accessible, both via keyboard and assistive tech. Not sure if we’ll be able to make it absolutely perfect, especially without more help and expertise, but we should definitely not be neglecting this during feature dev.
      • There needs to be an alternative (or a change) to important interactions/reveals that rely on hovering. Again for non-mouse users, and also including touch devices.

      • Isaac Keyet 4:42 pm on July 30, 2012 Permalink | Log in to Reply

        +1, accessibility mode much needed to think through. Also of note: placeholder HTML5 element is only supported by the latest mobile webkit browsers, if possible we shouldn’t rely on it for important field labeling or at the very least have a fall-back (regular label outside the field).

      • Andrew Nacin 4:45 pm on July 30, 2012 Permalink | Log in to Reply

        • Yes — we extensively discussed accessibility when planning these out. In particular, the main pane should be navigable via the keyword. So, up-down-left-right should move through the media library. Space or enter should select that image. In the case of a gallery, a “space” would select an image to then move it, until it is “dropped” again later. We can discuss and test these exact interactions during development.
        • This will most certainly need to work on touch devices.

        • Andrew Ozz 3:52 am on August 8, 2012 Permalink | Log in to Reply

          So, up-down-left-right should move through the media library.

          Using the arrow keys is usually reserved for navigating tree-like structures, mostly menus with several levels of submenus. For the gallery it would be better to use the Tab key.

          Arranging the gallery images would be hard without an accessibility mode similar to the widgets screen.

      • Daryl Koopersmith 4:48 pm on July 30, 2012 Permalink | Log in to Reply

        All hover interactions will be taps on touch devices (as they are in most of our other UIs), and if there are holes in the touch device workflow we can add tweaks to make the process better. We won’t leave them high and dry. :)

    • Sami Keijonen 4:57 pm on July 30, 2012 Permalink | Log in to Reply

      Looks great! I’ve been wondering can images be also filtered by author? I have magazine with students (authors) and they upload a lot of (unnecessary) images. It would help if they could filter they own images or admin could do it. This might be out of scope here.

      • Daryl Koopersmith 5:03 pm on July 30, 2012 Permalink | Log in to Reply

        Interesting thought. We hadn’t discussed adding filter by author, but depending on how the sort/filter/search UIs turn out, it might be feasible. If not, we should make this easy to do with a plugin.

    • RDall 4:57 pm on July 30, 2012 Permalink | Log in to Reply

      I would absolutely love to be able to type in the width and get the constrained proportion. So many times I have typed in 150 width only to see the height doesn’t change as well…

    • DrewAPicture 5:12 pm on July 30, 2012 Permalink | Log in to Reply

      This is a really good iteration and I’m looking forward to seeing more.

      One inconsistency that kind of sticks out for me is the ‘Edit’ button vs the edit icon button. In some places you click the icon, in some places you get both the icon and ‘Edit’ but then you’re clicking ‘Edit’ and not the icon. Personally, I’d prefer we stick with one or the other. My vote’s on the icon :)

      Per the ‘captions to DB’ discussion, why not just run some kind of ajax autosave?

      • Daryl Koopersmith 5:21 pm on July 30, 2012 Permalink | Log in to Reply

        One inconsistency that kind of sticks out for me is the ‘Edit’ button vs the edit icon button.

        These buttons actually lead to different places, so we should probably hide the paintbrush icon in those cases. The paintbrush icon will actually lead to the image editor (crop, resize, etc), which is also accessible from the “edit attachment details” screen. We haven’t entirely decided on the technical requirements around the editor, so those screens have not been mocked yet (and will likely be decided at the WCSF hack day).

        • Daryl Koopersmith 5:23 pm on July 30, 2012 Permalink | Log in to Reply

          We definitely need to figure out how to disassociate editing an image’s details (alignment, caption, etc) from editing an image itself (resizing, cropping, etc).

      • Andrew Nacin 5:22 pm on July 30, 2012 Permalink | Log in to Reply

        Per the ‘captions to DB’ discussion, why not just run some kind of ajax autosave?

        Oh, don’t worry, these will save via ajax. :-) But once you insert an image into the editor, that caption is free-form text. Under what circumstances should that caption text remain synced with the attachment in the DB, versus allowing them to diverge? You can use the same image in multiple posts, and captions from the DB are used in galleries, so it can get confusing very quickly.

        • Andrew Ozz 3:33 am on August 8, 2012 Permalink | Log in to Reply

          Yeah, and annoying too. If all is synced with the DB that means there would be impossible to have different caption on the same image when the image is used in different places / different context. What’s more: if an old image is reused later and the caption is edited, that edit would show in the gallery. This may not be intended.

          Currently the captions are disassociated from the DB as soon as the image is inserted in a post. Seems we can keep this.

    • Mark McWilliams 5:16 pm on July 30, 2012 Permalink | Log in to Reply

      It’ll be good to see the wireframes make their way into Core! :)

    • DrewAPicture 5:17 pm on July 30, 2012 Permalink | Log in to Reply

      I’m curious about the thinking behind moving the drag-n-drop zone from right (Dave’s 4th iteration) to the left (this iteration). I kinda like it better on the right, myself.

      • Daryl Koopersmith 6:22 pm on July 30, 2012 Permalink | Log in to Reply

        We moved the dropzone to bring more balance to the UI. All of the primary actions are aligned in the top right of the selection UI so aligning them with the right edge and bringing them closer to the dialog close button makes them more prominent. Also, when uploading is involved, it usually is the first step a user takes, so it makes sense to align it on the left side of the screen, where a user will see it sooner.

        • Dominik Schilling (ocean90) 8:05 am on August 1, 2012 Permalink | Log in to Reply

          Maybe we could use the dialog itself as a dropzone, so that it’s not necessary to drop it specific to this small box on the left side.

          If you have a big screen the browser is normally on the left side and the file explorer or desktop on the right. Yet you have to drag your file from right to the far away left side, which isn’t the best usability I think.

    • Chris Jean 5:18 pm on July 30, 2012 Permalink | Log in to Reply

      This is eerie. Really, really eerie. I talked with my coworker last week about a better Media Library screen, and this has all the key elements I talked about. So very, very weird.

      I’m excited. Please oh please let it be easy for non-core developers to use the full functionality of it.

      From the mockup, it looks like we will finally be able to create galleries with media that is not directly attached to that content. If we can make this happen, it will be awesome. I tried to make a gallery site for an artist friend of mine, and that limitation made me use a plugin when 95% of everything else was built into core.

    • zekeweeks 5:26 pm on July 30, 2012 Permalink | Log in to Reply

      I love the seamless flow between upload/select, gallery and image details, and insertion. And the contextual reactions between “insert single” and “insert gallery” are a huge usability plus. Very excited about this.

      One worry I have is on slides 12 and 13: https://speakerdeck.com/u/koop/p/wordpress-3-dot-5-media-wireframes?slide=12 . When one image is selected, we have two “insert” buttons which do the same thing- one persistent one at the top, and one on the individual image. However, when we have more than one selected (slide 13), the top button contextually switches to provide “insert gallery” functionality, but we still have an “insert” button on each individual image.

      I worry that this will create two problems:

      1. When selecting a single image, users may not notice the “insert” button on the top, and therefore never notice that it switches to support a gallery when multiple images are selected
      2. Worse: when intending to select multiple images and create a gallery, clicking “insert” over an image will lose their selections and take them into details for the insertion of just one image without even realizing it.

      For these reasons, I’d lean toward getting rid of the “insert” buttons over individual images altogether, and make the button on the top right be a consistent, universal button that is the “next-step-here” button for all contexts. However, this issue could be addressed other ways (only showing “Insert” for single selections, making “Insert” react as a gallery when multiples are selected, etc.)

      • Andrew Nacin 8:58 pm on July 30, 2012 Permalink | Log in to Reply

        I was strongly for the individual Insert buttons for a few reasons. Without them, I think the ease in which you can select multiple images (particularly since you can scroll so a selection is outside the viewing area) could cause people to create galleries when they don’t want to. They would need to clear the selection and then look around again to select the single image they originally wanted to insert.

        Note that we deliberately chose two different verbs: The current “Insert” into post, versus “Create” a gallery. Now, maybe that isn’t enough. This is all testable — we’ll find out during user testing. We can figure out what works and what doesn’t, and adjust the button placements, strings, and the like.

        We could also consider showing the selection status bar only once you have two images selected, and have individual insert buttons otherwise. I think this change could handle all of the issues we’ve both highlighted. Very good points, thanks for the feedback.

    • RDall 6:04 pm on July 30, 2012 Permalink | Log in to Reply

      Hey guys one thing. You know how you can show the amount of post to show in the screen via “Screen Options” Can we add that to the media library? Once I got a site that have 100 or so images scrolling through them wasn’t that easy and the search was only good if I remembered what I named it. (And some days my naming convention was better then others… )

    • RDall 7:22 pm on July 30, 2012 Permalink | Log in to Reply

      You guys rock! That will be awesome!!!!!!!!!

    • MartyThornley 8:26 pm on July 30, 2012 Permalink | Log in to Reply

      This all looks awesome! One thing I noticed is that you either insert one image or insert a gallery. There are a lot of uses for inserting multiple images, yet not in a gallery, especially for photobloggers who write a few words then say, here are ten images… And they just show ten images one after the next. Adding that option to the “Insert” buttons would be great!

      • Andrew Nacin 9:01 pm on July 30, 2012 Permalink | Log in to Reply

        If you want 10 images consecutively, then chances are you do want a gallery. Specifically, of the one-column, full-width variety.

        If you don’t want 10 images consecutively, then you need to adjust your cursor each time so we know where you want those images. (If, for example, you’re telling a story and want text in between the photos.)

        This dialog is not going to be a separate load of WordPress inside of a frame, like the current thickbox implementation. It’ll open (and re-open) immediately, like internal linking. So it shouldn’t actually be painful to individually insert these images if that’s what you wanted.

        • MartyThornley 5:01 pm on July 31, 2012 Permalink | Log in to Reply

          I was actually thinking the same as I looked through the workflow more. It is not possible with the current (old) one, but I think new workflow would definitely work for this.

      • Dominik Schilling (ocean90) 1:49 pm on July 31, 2012 Permalink | Log in to Reply

        +1 for an option to insert all selected images.
        When I start to write a post I upload the images first.
        My preferred workflow would be to insert all uploaded images and then write the text between the images and/or adjust the images. And I know many people who would like this too.

        See also #7013.

        • Andrew Nacin 2:53 pm on July 31, 2012 Permalink | Log in to Reply

          The problem with this is it confuses users, who will wonder what the difference is between inserting multiple images versus creating a gallery. A gallery really doesn’t mean that much in WordPress, but it is better when it comes to handling more than a few images. We want to keep the UI simple.

          Something we should think about, though.

        • MartyThornley 5:05 pm on July 31, 2012 Permalink | Log in to Reply

          This is one spot where a gallery doesn’t work. Thinking of them all in a row, it makes more sense to have a type of gallery that is one image after another. But there are spots where you need to just insert a few images quickly then add some text.
          Maybe it could be “Insert Multiple Images” instead of “Insert Gallery” and then what is mocked up here as the gallery options would let you choose “Insert as Gallery” and choose columns, etc… or “Insert Images” which would just add the multiple image tags.

          • Andrew Nacin 5:18 pm on July 31, 2012 Permalink | Log in to Reply

            I understand the latter point, but just a note, a one-column gallery with full-width images does work, if you want images one after another.

    • ChaseWiseman 10:44 pm on July 30, 2012 Permalink | Log in to Reply

      First of all, great work. I am very excited about this. One question: is there any reason the Featured Image dialog can’t get the same cropping features as the Custom Header dialog? Both the custom header and featured image sizes are defined in a similar fashion. It would be nice to choose which area of an image you want to use as the Featured Image.

      • Daryl Koopersmith 10:54 pm on July 30, 2012 Permalink | Log in to Reply

        We’ve discussed it and might do just that. It depends on how the image editor (discussed above) turns out.

        • DrewAPicture 4:31 pm on July 31, 2012 Permalink | Log in to Reply

          This would be a really ‘good-to-have’ feature. Most of the time we’re using resized thumbs on archives and cropping from center on vertical images or images where faces are near the top is frustrating when it’s forced from the center. Being able to manually crop would be fantastic.

    • nhuja 3:49 am on July 31, 2012 Permalink | Log in to Reply

      Great work. Having been solely into Photography themes, this is an awesome development. I always thought media management was the weakest part of WordPress. And I was planning to develop this on my own as well. :) I would love to know how these things are addressed or can be addressed:

      1. I see the Create New Gallery option which is great. So, will there be a link where we can manage those Galleries (Albums), list of galleries available? Like delete an image or add another image to the gallery ?

      2. Can one image be assigned to multiple galleries ? Currently it doesn’t allow unless we do shortcode cheat (I think). Also, if we are viewing the Media Library view (list of images), in the grid style, it might be great if there is a “belongs to X gallery”.

      3. Can we insert one gallery to multiple posts ? Now this is one prime feature I get requests from customers. :)

      Thanks, I am really looking forward to this development. :)

      Cheers!
      Chandra

      • lessbloat 12:06 pm on July 31, 2012 Permalink | Log in to Reply

        1) Yep. The idea is that once you add a gallery to the editor, you can click the edit button on that gallery in the visual editor mode, and add/remove images from that gallery.

        2) Yep, any image will be able to be added to any gallery.

        3) Perhaps. I’m not certain this has been worked through at the stage, though I agree this would be nice. :-)

    • Konstantin Kovshenin 4:41 am on July 31, 2012 Permalink | Log in to Reply

      This is just awesome! I’m glad that media management is getting some serious love in this release. Great work everyone!

    • thenbrent 6:53 am on July 31, 2012 Permalink | Log in to Reply

      This looks fantastic, thanks for all the hard work you’re putting in to get media handling right.

      When opening the Insert Media dialogue, will it display *all* media, or just those attached to the post? I’ve had complaints from users in the past about different tabs for all media and media uploaded on the one post.

      The Insert Gallery looks identical to the Insert Media. This could lead to occasional disorientation. But that’s nothing a different shade of grey or some other bit of CSS wouldn’t fix.

      • Andrew Nacin 2:43 pm on July 31, 2012 Permalink | Log in to Reply

        It’ll display all media.

        The two screens do look similar, yes, but these are only wireframes, not designs. I too have noted that disorientation is possible here. We will make sure the screens are designed with that in mind.

    • andyadams 1:42 pm on July 31, 2012 Permalink | Log in to Reply

      For some reason, my last couple of comments never made it through, so I’ll try reposting the general idea:

      I like the improvements, but have you considered ditching the modal window for something less obtrusive? Perhaps something more like the Theme Customizer that pops out on the lefthand side?

      I say this because 2 major problems I have with modals are:

      • Loss of context of the content editor.
      • Difficulty in inserting multiple single images.

      Having a modal take over the whole screen makes inserting media feel like a completely different operation than writing your content, and I feel like the two tasks could potentially be toggled in a less jolting way. This would make writing your post with lots of media a much smoother process.

      • Andrew Nacin 2:42 pm on July 31, 2012 Permalink | Log in to Reply

        We’ve discussed ditching the modal window for years. Literally, here’s some sketches from @jane from October 2009.

        I used to be squarely in the I-want-my-media-inline camp, but I’ve adjusted that a bit. Certain actions should actually be blocking. Also, since we’re aiming for a super-fast dialog that remembers where you were, speed should not be a factor in repeated actions like inserting multiple images. As the dialog will likely be movable (like internal linking), context also becomes less of a problem.

        Perhaps over time, more things move inline. Uploading, for example, should not be a blocking action. But our goals for 3.5 include separating out the overlapping and confusing workflows, which means individual, contextual dialogs. Moving everything inline at once would be a huge challenge of balancing a desire to create distinct workflows with a small space to work with.

        • andyadams 3:44 pm on July 31, 2012 Permalink | Log in to Reply

          Perhaps the blocking and more complex dialogs could be expanded to fill the whole screen, while the simpler and more common tasks (such as inserting an individual image or gallery) could be moved to something more inline, like the customizer?

        • Alex King 12:07 am on August 2, 2012 Permalink | Log in to Reply

          > Perhaps over time, more things move inline.

          I’ve considered creating a plugin to provide a pop-over menu of images attached to the post for easy insertion into the content. Perhaps this is an area where some API enhancements (JS to insert, for example) might drive some creative plugins. Some of those ideas might in turn suggest useful enhancements to consider in core.

    • Dominik Schilling (ocean90) 2:03 pm on July 31, 2012 Permalink | Log in to Reply

      I really like this wireframes, great job.

      One question, is it planned to be able to adjust the image size (maybe via a slider) or to get a list view?

      • Andrew Nacin 2:24 pm on July 31, 2012 Permalink | Log in to Reply

        We did discuss the slider idea! We didn’t include it in the wireframes, but it would be a great enhancement to this.

        List view, I am not sure — depends on whether it can be designed to be useful. I would think that the view area itself would be pluggable.

    • sanchothefat 2:06 pm on July 31, 2012 Permalink | Log in to Reply

      What considerations are there for other media types? In particular video and audio.

      I can understand the desire to leave creation of things like playlists to plugins but the above wireframes are purely image focused. Will non image files be treated in the same way visually?

      Also how will the above wireframes cope with how the media upload tabs can currently be extended by plugins? For example the ‘Upload’, ‘upload from URL’, ‘Gallery’ and ‘Media Library’ tabs that there are currently? That ability is crucial to some of my plugins.

      • Andrew Nacin 2:48 pm on July 31, 2012 Permalink | Log in to Reply

        This will be pluggable, which means a video could show a single frame, audio could have an embedded player, PDF documents could have an image thumbnail, etc. But by default, non-image files will likely be greeted with a generic icon/thumbnail — images first, then everything else.

        I am not yet sure how we will handle tabs added by plugins. What are some examples you have seen or used?

        • sanchothefat 3:20 pm on July 31, 2012 Permalink | Log in to Reply

          That sounds fine re. the handling/display of different media types – it’s pretty much what happens now and I agree you’ve got to prioritise this stuff!

          A good example of using media upload tabs out there in the wild that’s widely used would be the JW Player plugin – it lets you create playlists in one of the tabs it adds. http://wordpress.org/extend/plugins/jw-player-plugin-for-wordpress/

          Also currently I’m working on a plugin that splits out media by type – it doesn’t make a whole lot of sense that all attachments regardless of type appear under ‘Gallery’. My plugin creates tabs for Audio, Video and Other and for audio and video it has a form at the bottom for inserting a playlist shortcode similar to the way galleries are inserted currently.

          I think the new wireframes are great and show a huge improvement to creating & embedding galleries but if possible it’d be good to have some way to see what attachments you’re looking at by source (post/media library) and then also to have them separated by type – Image / Video / Audio / Other.

          Say I’m looking at audio attachments only – the add to gallery button could become ‘Add to playlist’ (assuming it’s feasible to code the gallery functionality in a generic way rather than strictly coding for images). I’d at least like to be able to plug that in if possible.

          Sorry for rambling! Just getting my thoughts down – check out the JW Player plugin anyway

    • Anthony Hortin 2:22 pm on July 31, 2012 Permalink | Log in to Reply

      Wow. Great work guys! This is looking seriously sweet. Some really nice improvements to the workflow.

      One thing I’d love to see, as @bradyvercher touched on briefly up above, it would be great to be able to link each gallery thumbnail to a individual url. It’d make the gallery functionality much more versatile.

      Looking forward to seeing some or all of these improvements in the next release. Keep up the geat work!

      • Sheri Bigelow 1:59 pm on August 1, 2012 Permalink | Log in to Reply

        Linking gallery images to outside URLs is a fairly-common request on WordPress.com.

        • Ipstenu (Mika Epstein) 2:04 pm on August 1, 2012 Permalink | Log in to Reply

          But is that even really a good idea? Too many people don’t know about the dangers of hotlinking as is, and encouraging it …. Okay, I know a lot of that is my buggaboo, but it seems like a bad idea. If flickr etc allow it, then that’s a plugin use-case, so I can see making it pluggable/hookable so a plugin can grab onto it, but I really would hate to see external image inclusion overtly included in core.

          • Anthony Hortin 12:30 am on August 2, 2012 Permalink | Log in to Reply

            I wasn’t actually meaning the ability to include external images. I meant that it would be good to be able to link the thumbnail images to a specific URL (ie. other than just the larger version of the image or the attachment page). For example, It would be handy to have a gallery of 5 images that link to 5 different pages on your site.

    • Ryan Hellyer 7:48 pm on July 31, 2012 Permalink | Log in to Reply

      This looks really slick.

      I’m not sure it fits into this particular area of core, but some sort of system to allow us to move attachments between folders would be darned handy. It gets really messy handing large numbers of images if they’re just chucked into folders based on the date they were added.

    • Reji Thomas 8:52 am on August 1, 2012 Permalink | Log in to Reply

      This is excellent work!

      Some thoughts:

      • The Gallery workflow could have some extensions. At ‘Create/Edit’ Gallery, show Gallery Title and Description fields, above the Display Properties settings.
      • Bring Gallery Management under the Media > Library. Add an additional listing type ‘ Galleries’ and enable it to be searchable (based on the above). That way a user can quickly identify galleries attached to posts or post types

    • John Smith 9:10 am on August 1, 2012 Permalink | Log in to Reply

      Looking very, very nice.

      The only thing I had hoped was that the insert button would be moved down into the actual WYSIWYG toolbar. Any reason why we keep it at the top, it’s a little confusing for first-time users until it’s pointed out.

    • wycks 12:38 pm on August 1, 2012 Permalink | Log in to Reply

      Please consider adding some of the gallery options (http://codex.wordpress.org/Gallery_Shortcode) into the actual UI .Most end -users do not even know about them.

      Also please add as many filters as possible for developers, for example ‘image_size_names_choose’ for the size dropdown, which should work with add_image_size.

      Looks awesome can’t wait because this improves everyone’s experience with wp!

    • Sheri Bigelow 2:39 pm on August 1, 2012 Permalink | Log in to Reply

      The Edit Image dialogue seems to be missing, specifically: crop, rotate, flip, and scale.

      • Sheri Bigelow 2:41 pm on August 1, 2012 Permalink | Log in to Reply

        I just realized this is in the media library, not the Upload/Insert media workflow. Sorry!!

        • Andrew Nacin 2:44 pm on August 1, 2012 Permalink | Log in to Reply

          This screen is reachable from an “Edit Image” button, and buttons to this screen appear in a number of places. But no, we haven’t mocked up the screen yet.

          • Sheri Bigelow 2:50 pm on August 1, 2012 Permalink | Log in to Reply

            Aha, gotcha. It does seem like these are advanced image edit options and some of the things you were planning to cut (i.e. border, target, file URL) might make sense to keep here while removing duplicate edit fields (i.e. title, caption, description).

            • Andrew Nacin 3:16 pm on August 1, 2012 Permalink

              Well, they’re two different workflows. The fields we want to cut are glorified HTML controls that have to do with how an image is presented/displayed in a post. This screen is about modifying the image itself — scaling, cropping, generating thumbnails, etc. Conflated fields and windows are what we’re trying to get away from as much as possible.

    • Jonathan Davis 3:13 pm on August 1, 2012 Permalink | Log in to Reply

      On the image dropzone positioned to the left, I realize it is likely a decision based on the most economical use of the space and allowing a clear visual prompt for the user to put it one side or the other. For usability, having it stretch across the bottom (or top) horizontally provides better drag access regardless of the user OS (regardless of whether the host OS keeps files on the left or right). I realize that the vertical screen realestate is at a premium. That makes it a decision of priorities. Is the drag access from left or right important enough to take up that vertical space? Is there a balance in height/size of the dropzone horizontally that won’t chew up too much space but is large enough for clumsy drags? Is left or right enough of a hindrance on usability to be worth taking up vertical simply for the sake of universal access from one side of the browser or the other?I’m not advocating one way or another, just bringing it up for the sake of discussion. Question everything and all that.

      Aside from the problem of the “prompt” (how you prompt the user) with the dropzone, it would be ideal if the entire modal were a dropzone, understanding that may not be possible with how pupload’s mecahnism works, or that it might interfere with the rest of the UI. Still I wonder (thinking out loud) if you could detect the mouse drag and setup the drop zone over top the entire modal area. Probably too divergent a thought to gain traction, but thought I’d share my musings anyhow.

      Good work team. It really is very well thought out. It will be very interesting to see how the user tests go.

      • Daryl Koopersmith 7:20 pm on August 1, 2012 Permalink | Log in to Reply

        …it would be ideal if the entire modal were a dropzone…

        It wasn’t shown in the mockups, but this will indeed be the case. It’s certainly possible, and just a matter of getting the UI right.

        • Jonathan Davis 6:42 pm on August 2, 2012 Permalink | Log in to Reply

          Well, there you go then. That makes most of my earlierr usability feedback moot. No need to take up precious vertical space on the prompt if the entire modal is a drop zone.

    • gabediaz 3:28 pm on August 1, 2012 Permalink | Log in to Reply

      This is fantastic, really great to see all these wireframes and can’t wait to see more.

      Just want to ask if there was any thought about providing a List View with Order Number option when editing/sorting a gallery?

      Starting with Slide 55 the only way to rearrange gallery images seems to be with a drag and drop. This works great for smaller galleries but with larger galleries you’ll find yourself dragging up/down through several slides of your infinite scroll. The currently Media Gallery Screen allows for sorting via order numbers which you can quickly tab through and manually sort with a number.

      Keep up the great work!

      • Daryl Koopersmith 7:27 pm on August 1, 2012 Permalink | Log in to Reply

        Just want to ask if there was any thought about providing a List View with Order Number option when editing/sorting a gallery?

        We will certainly have to hone the sorting UX. I’m not convinced that manually typing in order numbers is the best possible experience (or necessary). We also will support keyboard-based image organization (with arrow keys). That said, this should be possible in a plugin regardless.

    • Maor Chasen 8:13 pm on August 1, 2012 Permalink | Log in to Reply

      Wow, what a great work. Can’t describe in words how excited I am to see this great progress!

    • bakaburg1 1:25 am on August 2, 2012 Permalink | Log in to Reply

      Maybe this is more specific to mac users since stuff tend to pile up on the right side of the desktop, but when i drag and drop stuff I use to mouse in from the right of the window. I wouldn’t find it nice to drag all the way to the other side of the screen.

      I would then suggest to put the drop area, if not on the right which wuold be best for me, on the bottom center, large as much ad the panel, so that you don’t have a preferred dragging side, but this is left up to the users.

      HWR extremely nice work! especially being able to drag directly in the editor!

      One more thing I would is to be able to resize pictures directly in the editor, with text moving away during resizing. Pretty easy to achieve with javascript.

      Is still possible to use external images with URLs?

    • Maor Chasen 12:33 pm on August 3, 2012 Permalink | Log in to Reply

      Hi, just wanted to ask with what software did you guys create these wireframes? Looks amazing! Thanks!

    • MacItaly 4:28 pm on August 3, 2012 Permalink | Log in to Reply

      Hi, great work indeed, Media Library needs a deep remake.
      But nobody are interested to upload and organize files in folders/subfolders?
      WP isn’t anymore only a blog and many people use it as CMS and, in those cases, have media organized per year and month it’s useless and have all of them in one folder it’s confusing.
      Should be possible to have an option, on media settings, to enable a folders manager?
      Something that when I upload one or multiple files, I can choose in which folder will be.
      Does it make sense?

    • Dennis Whiteman 7:14 pm on August 3, 2012 Permalink | Log in to Reply

      Will it be possible when creating a new gallery or uploading files to manage the upload location in the file system in the upload UI? I have some sites with thousands of posts and thousands of images. If I use the built-in media uploader, I end up with thousands of files in a directory. It would be nice for end users to have the option of uploading images within the media upload directory to a new folder with a name of their choosing instead of being limited to segmenting out files only based on date as is currently the option. Another example is that I have a bunch of images that I’d want in a directory called ‘images’ and podcast audio files in a directory called audio, etc.

      This is particularly a problem when migrating from another CMS where the files have been manually uploaded for years. Without some choice in where files go, I usually end up having the client continue to use an ftp program to upload instead of getting the benefits of having an actual media library with meta data that’s provided in WordPress.

      I have conceptualized being able to choose a folder on upload within the existing uploader, but it would be so much better if it were just builtin.

    • lonchbox 11:37 pm on August 4, 2012 Permalink | Log in to Reply

      Hi!, finally! that part of the WP was too old, all my clients will love this new feature :) Good Job!

    • Ayman Aboulnasr 9:41 am on August 5, 2012 Permalink | Log in to Reply

      Wow, a very interesting new facelift to the WordPress Images and media handling! Well done guys.

    • Jan Fabry 1:25 pm on August 5, 2012 Permalink | Log in to Reply

      Have you considered making the individual edit dialog (alignment, caption, alt text, …) non-modal? I was thinking of a floating widget, that would only appear when you have selected an image in the post editor. This gives you instant feedback (alignment, size), and could be extensible (so plugin and theme authors could add or hide controls to suit their client).

      https://img.skitch.com/20120805-ruuippsxadef54fm4qcdcj8guc.png

      This could also solve the problem of “saved in the db/saved in the post”. Everything you edit here is just for this post.

    • hearvox 3:46 pm on August 6, 2012 Permalink | Log in to Reply

      This beautiful new Media rewrite might also be an opportunity to look at the way the attachment’s Title text is auto-used in two different ways.

      1. As the post_title of the attachment post, which then is used:
      a. in the Media Library’s column “Title”, and
      b. in many Themes, as HTML text for the H1 and head’s title elements, when displaying the attachment post.

      2. As the title-attribute of the img element when using the “Insert into Post” button.

      #1 is expected behavior, and makes sense-
      an attachment’s Title is meant to be the document title, like any other post..

      #2 is hidden to many users and can make little semantic sense.
      an img’s title attr should: “offer advisory information about the element” (w3c).
      this is often NOT the same as document title

      Perhaps WP might consider adding a field,
      so there’s one for each of the two different “titles”, like:

      Attachment Title * ___________
      Alternate Text __________
      Image Title Text _________

      (and like “alt”, the img “title” wouldn’t be written if this new last field was empty).

      • hearvox 3:46 pm on August 6, 2012 Permalink | Log in to Reply

        Here’s a couple common use cases that shows why current WP default
        may not be optimum:

        1. You have several versions of an image or scene, you may Title them
        so you can easily distinguish them in Media Library list:
        “Me & Crew: wide-shot”
        “Me & Crew: close-up”
        “Me & Crew: close-up cropped”

        now say you chose not to caption the image,
        but do want some img title text (a tool-tip in many browsers), like:
        “Me and the home-town Crew chilling at WordCamp”

        That’s great “advisory info” but maybe not-as-great a doc title.
        So you must edit HTML manually to make them different.

        2. Imagine the oh-too-frequent case:

        • User uploads image w/ name: image0001.jpg.
        • User does not re-Title attachment, so post_title is: “image0001.jpg”

        so, user gets a poor attachment title, but no harm done.
        until the Insert into Post grabs the post_title field as text for the title element:
        <img title= "image0001.jpg" src="image0001.jpg"…

        now WP's default behavior subjects the whole web to useless/redundant "advisory info".

        if this is something the WP community feels needs amending,
        i'd be happy to start working on the code changes in media.php.

      • Andrew Nacin 8:31 pm on August 7, 2012 Permalink | Log in to Reply

        We noticed this double-use of the title as well. We’re simply going to eliminate title attributes from images inserted into posts, and viola! #18984

    • Bruno Costa 8:51 pm on August 6, 2012 Permalink | Log in to Reply

      I think you only forget the image link.

      The layout is very beautiful, I only think all this page changes won’t please a lot of people.

    • John 5:39 pm on August 8, 2012 Permalink | Log in to Reply

      Are these rewrites going to be adapted to the Media Library screen itself ( upload.php )?

    • fanderzzon 9:23 am on August 13, 2012 Permalink | Log in to Reply

      Great work, it’s looks amazing!

      How is the search function working? Are you adding AJAX search so the user automatically get a list of objects/images that matches their search query on the fly?

    • Peter Chester 3:37 pm on August 15, 2012 Permalink | Log in to Reply

      Great work Daryl!

    • hixen 12:49 pm on August 16, 2012 Permalink | Log in to Reply

      This is really awesome, great work.

      Just got one question, are you guys looking into adding more ways to structure your media library? (tags, categories?)

    • jamesmehorter 7:29 pm on August 22, 2012 Permalink | Log in to Reply

      I would LOVE it if galleries/albums did not need to be linked to a specific post.. but could be if wanted. Many times this is the only reason I will choose NextGen Gallery. PLEASE make NextGen obsolete!

    • Jesper van Engelen 4:36 pm on August 24, 2012 Permalink | Log in to Reply

      I am very pleased to see that some major changes are finally being made to the media UI, great work on that! I am wondering though: in what way will this affect the countless plugins that change the media interface currently. Many plugins add buttons to the media interface for allowing users to upload media for use in their plugins. This includes many popular plugins such as Advanced Custom Fields and Option Tree – to what extent will these plugins be affected by these changes?

    • kkalvaa 1:16 pm on August 25, 2012 Permalink | Log in to Reply

      Looks amazing, as people above has said, this alone makes 3.5 one of the key releases to look forward to.

      I think the drop zone should be on the right, in a RTL setting it feels like the second step should be to the right rather than the left.

    • deursmo 11:15 am on August 26, 2012 Permalink | Log in to Reply

      This looks great. Discussion here is too ‘technical’ for me but a question about using images in multiple posts. Will it be possible to see in which posts (and pages) one particular image is used? From the editor’s point of view? I don’t mean (nor use) galleries, but perhaps that is the answer. Thanks for all you people make, good whishes.

    • ms-studio 7:59 pm on August 26, 2012 Permalink | Log in to Reply

      I love that concept, it’s pretty much the best system I could imagine. But I have one big question: how is the default ordering of uploaded files being handled? To me, this is a weak point in the media management, and must be improved.

      Currently, the default is “by upload order”, which means that if you upload a bunch of pics from a photo camera, numbered from 00001 to 00020, the last one (00020) will be on top, the first one (00001) will be at the bottom (because the OS tends to send 00001 first).

      If you want a chronological gallery, you need to reorder them each time.

      Personally, I mostly want the files inside a batch upload to get ordered by filename – 00001 on top, 00020 at the bottom. But if I add a second batch of files, I want them to be added at the bottom of the list! So it’s a very tricky issue to solve …

      I just openend a thread on that topic in trac – http://core.trac.wordpress.org/ticket/21643 – but I believe it’s more appropriate to continue the discussion here.

    • ms-studio 8:31 pm on August 26, 2012 Permalink | Log in to Reply

      Just a few more words about the “default ordering” issue.

      The wireframes show the ordering option “Sort by upload date”, so I assume that could be the default.

      • Is this really the best default? How is that “upload date” determined if the user batch-uploads multiple files at once?
      • Do we have any stats about how people tend to order their images, in image galleries? Chronologically? By upload date? By file name?
      • “By upload date” doesn’t actually tell what direction is applied. Newest first, or oldest first?
      • If the user changes that setting (let’s imagine that she prefers alphabetic ordering), we must make sure that WP remembers that change and applies it for future uploads.

      To understand the problem I see with the current setting, have a look at that quick demonstration in WP 3.4:
      http://sandbox.4o4.ch/wp/WP-3.4-uploader.swf

      And see here the (much more intuitive) behavior in Facebook:
      http://sandbox.4o4.ch/wp/facebook-uploader.swf

  • lessbloat 6:53 pm on July 16, 2012 Permalink  

    Since 3.5 hasn’t officially started yet, I thought I’d play around with a quick proof of concept for the “Spotlight” search functionality this morning. Here’s what I’ve got so far:

    There are still heaps of rough spots.

    Here’s the plugin if you’re interested in taking it for a spin: http://cl.ly/0E3G2Y1J33372C3f3W3Q

    Let me know if you think this is worth pursuing (even just as a plugin).

     

    • Mel Choyce 7:00 pm on July 16, 2012 Permalink | Log in to Reply

      Haven’t had a chance to download / play around with it, but my immediate reaction to watching your video demo is overwhelmingly positive. Love the addition of a keyboard shortcut for convenience. We’ll definitely need to work through the rough spots, but this is a really good start. I’d love to see it included in 3.5.

    • Tom Auger 7:15 pm on July 16, 2012 Permalink | Log in to Reply

      Very cool. But how to disambiguate “content search” from “admin search”? IE: on the front-end, users are used to and expecting the search to search through site content such as post body, titles etc. By using the same icon in the same place, just on the Admin side, there’s the danger that that expectation extends to the new “Spotlight” search you are proposing. Is it as simple as changing the icon used? Or adding a label such as “Admin Search” or even “Find Tool”?

    • Vitor Carvalho 7:19 pm on July 16, 2012 Permalink | Log in to Reply

      @lessbloat Thankyou!! This will be really good if in 3.5.

    • Mike Schinkel 7:23 pm on July 16, 2012 Permalink | Log in to Reply

      @lessbloat This is quite awesome. I would love to see this hookable so we I could use it for the front end of a CMS. We’ve implemented something similar, take a look at http://www.haslaw.com/ and search for “John” or “Real Estate” in the top right blue search box but it would be nice to be able to re-implement using core code instead.

    • Isaac Keyet 7:34 pm on July 16, 2012 Permalink | Log in to Reply

      I like it, but I’m wondering how you’d present the regular search functions (i.e. searching the entire site).

      In my mind it would make sense if you could search your site’s content as well, maybe have the first, selected, option be to search the site so you’d have to press down once to get to the first actionable result. Of course it’d be even more useful if it searched for pages/posts/etc right there and grouped them accordingly (like Apple’s Spotlight) so you could get to non-action items fairly quickly by a mouse click instead.

      • lessbloat 7:44 pm on July 16, 2012 Permalink | Log in to Reply

        Yep. Currently, If you don’t select one of the auto-suggest options, it just searches the site like normal. But I agree, maybe the top option could be “Search Site | KEYWORD”.

        Searching posts and pages within the same drop down would be awesome. With that said, I’d be worried about how long it would take. Maybe we could cache the list of posts and pages in localstorage (to avoid having to wait for a trip to the DB and back on each keyup)?

    • Brandon Dove 7:47 pm on July 16, 2012 Permalink | Log in to Reply

      Love the concept. I’m with Issac though, the integration with that search field seems strange. I guess I’ve never used that search field, but it also seems weird that when you search from the dashboard it directs you to the search results on the front end (but that’s a separate issue). Maybe adding keywords to spotlight searches would help contextualize the search.

      For example:

      • by default, any search would search content and return results on whatever side of the site you’re on, dashboard via edit.php or front-end using the search results template.
      • the keyword prefix “add” could be used as you have it now, to display add actions
      • the keyword prefix “change” could be used to display settings screens or theme options
      • the keyword prefix “search post_type” would take you to edit.php for that post type in the dashboard if you’re in the dashboard

      Something like that. What do you think?

      • Helen Hou-Sandi 8:12 pm on July 16, 2012 Permalink | Log in to Reply

        You probably haven’t used that search field because it doesn’t currently exist when in the admin :)

        Can we somehow change the iconography to indicate quick jump rather than searching content? Not sure what that would be. I’m also a little concerned about putting it in the same spot as the search is located on the front. I’ll have to play with it once I have Internet beyond my phone again.

    • beaucollins 7:53 pm on July 16, 2012 Permalink | Log in to Reply

      I was tackling something similar a little while ago but it was more inspired by the Alfred App UI. The goal for mine was to have mouse-less navigation.

      I haven’t worked on it much so far but it is similar in that it indexes the Admin’s navigation and is accessible on the front/back of the site.

      We had talked about adding drag/drop media uploading to it as well as accessing search content via XHR.

      Hopefully this video shortcode works:

      Source is here: https://github.com/beaucollins/hopscotch

      • beaucollins 7:55 pm on July 16, 2012 Permalink | Log in to Reply

        Here’s a link to the screencast: http://www.screenr.com/vffs

      • lessbloat 8:28 pm on July 16, 2012 Permalink | Log in to Reply

        Check you out! ;-) Nice stuff Beau! This is way more polished my little proof of concept!

        • Beau 8:35 pm on July 16, 2012 Permalink | Log in to Reply

          I think I could pretty easily work mine into a WordPress plugin vs being a browser extension. I think that’s the best direction to go to hook into searching for posts, users or whatever else.

          I just didn’t think it would be something most users would use since activating it is hidden. Integrating into the search bar like you have is much more discoverable.

      • Mark Jaquith 8:38 pm on July 16, 2012 Permalink | Log in to Reply

        Wow. That looks really slick.

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

        Nice, also reminds me of Quicksilver.

      • Elio 12:47 pm on July 17, 2012 Permalink | Log in to Reply

        That’s truly awesome Beau. Do all terms have the same priority or for example, if you have a post and a page that start with the same word and you’re in the posts list screen, the one with the post will come up first?

        • Beau 5:30 pm on July 17, 2012 Permalink | Log in to Reply

          As it is now, the /wp-admin navigation get’s indexed as “$submenu $menu” in the order they appear in the menu. So if you type “Add New” in a default WordPress 3.x install it would filter down to:

          • Add New Posts
          • Add New Media
          • Add New Links
          • Add New Pages
          • Add New Plugins

          Currently it doesn’t actually give you access to your posts/pages from within the interface but that was a feature I definitely desire to add. And it would make sense to be contextual to what page you are in the admin.

    • Amy Hendrix (sabreuse) 9:18 pm on July 16, 2012 Permalink | Log in to Reply

      Like others, I’m seriously impressed with the slickness, but concerned about mixing up content search with admin search (search? It almost doesn’t feel like search at all in my mind, but that may just be the fact that I use the mac spotlight almost entirely as a launcher and not a content search…)

      I’m less concerned about that in the admin (where content search might sometimes be desired, but we don’t currently have it), than on the front-end — the assumption of working with/searching for content seems a lot stronger in that context.

      I love launcher-style things and keyboard shortcuts (Gnome-Do represent!), but I’d want to be sure we look hard at whether whatever launch trigger is chosen.

      Aside from that, though, both of these visions are just fantastically cool.

    • Konstantin Kovshenin 9:18 am on July 17, 2012 Permalink | Log in to Reply

      @lessbloat this is slick!

    • Kurt Payne 2:52 pm on July 17, 2012 Permalink | Log in to Reply

      Absolutely worth pursuing! Two thoughts: 1.) i18n may present a few surprises with string matching and 2.) this needs hooks for other plugins to add their menu items to the list.

    • Anointed 7:09 pm on July 17, 2012 Permalink | Log in to Reply

      Absolutely amazing, love the concept and is something I could see using someday

    • ahuggins 8:52 pm on July 27, 2012 Permalink | Log in to Reply

      Proposal: Would it be nice to have the “spotlight” feature work on the front end search field for admins? Thinking you might be checking your sight out and think I need to “Add/Edit Something”, it would be sweet to be able to use the keyboard shortcut and “spotlight” to the something you want to add/edit. Obviously you wouldn’t want the admin commands to show to non-logged in users.

      Just an idea.

← 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