Make WordPress UI

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Chelsea Otakan 2:51 am on August 6, 2012 Permalink | Log in to leave a Comment
    Tags: help, screen options   

    We did some brainstorming at Dev Day today around improving the Help and Screen Options tabs in the admin. Keep in mind nothing here is a final decision, just some exploration of what we thought would be easy wins to make these tabs more useful.

    Here are the problems with them right now:

    • Most users are blind to these tabs.
    • The labels and positioning give little indication as to what these tabs actually do.
    • For a lot of users, Help is not that helpful.
    • They’re position in the admin creates yet another point of navigation for users to be aware of (and per #1, most of them aren’t).
    • The very wide container for text makes a lot of the help text difficult to read.

    Here are some of the possibilities we brainstormed (see notes below image):

    Ideas:

    • Adding icons to these tabs would (hopefully) both make these tabs more visible and give a better indication as to what these tabs too.
    • Moving these to the right side of the toolbar would give even more context to what these do, as they would be grouped with other user-specific settings.
    • (6) The toolbar dropdown would allow for a slimmer content area for better readability.
    • (7) The slimmer content area would let us make screen options read like a list for better scannability.
    • (4/5) Putting the gear on the upper right would standardise with several other web apps (Twitter, etc).

    We discussed possible changes to the labels:

    • Screen Options -> Screen Preferences
    • Help -> Screen Help
    • (3) Removing the Screen Options label altogether and only showing the icon (since the gear icon is so universally recognised). Possible expanding this to Help.

    I did a hi-fi mockup of what the new Help dropdown might look like:

     
    • Ipstenu (Mika Epstein) 3:41 am on August 6, 2012 Permalink | Log in to Reply

      My only worry is that makes the menu bar very crowded. A lot if plugins add to that :/ The 2 b mockups I like because you could change the color and make them more visible. Pop a little :)

    • GrahamArmfield 9:42 am on August 6, 2012 Permalink | Log in to Reply

      Coming from an accessibility perspective I’d favour the combination of icons and words. But I don’t have a strong view about the positioning of the links – existing location/toolbar.

      There is a Trac ticket open (See #21326) about making the screen options more accessible to sighted keyboard users and screen reader users. I believe this has been accepted into 3.5. Any further changes to the functionality must ensure that the information and options are keyboard accessible and keyboard operable as appropriate. If a panel is to be used to contain the information it is important that focus is transferred to an appropriate place within that panel and that the tab order of any options makes sense. Will ‘Close Panel’ links be included at the bottom of the options/help?

      • Chelsea Otakan 6:25 pm on August 6, 2012 Permalink | Log in to Reply

        If we chose an approach with icons only, we would still leave and text in the DOM (we could use text-indent to hide the text) for screen reader compatibility. Ref: http://css-tricks.com/snippets/css/standard-css-image-replacement/

        “Any further changes to the functionality must ensure that the information and options are keyboard accessible and keyboard operable as appropriate. If a panel is to be used to contain the information it is important that focus is transferred to an appropriate place within that panel and that the tab order of any options makes sense. Will ‘Close Panel’ links be included at the bottom of the options/help?”

        AFAIK the current toolbar is keyboard accessible. It would theoretically use a lot of the same code as the current Toolbar and the current Help module. Since the menu item would now be above the content of the Help and Screen Options modules in the DOM http://core.trac.wordpress.org/ticket/21326 would be easier to resolve with the above approach.

        We could add “Close Panel” or “Dismiss” links, but, since I’m not familiar with this aspect accessibility, what’s the reasoning behind adding them?

    • Andrea Rennick 2:54 pm on August 6, 2012 Permalink | Log in to Reply

      On the other end, we’re making sure pages will be available in the codex to be able to link to them in screens like this, to explain to the user what those screens actually DO.

  • Helen Hou-Sandi 1:12 am on August 2, 2012 Permalink | Log in to leave a Comment
    Tags:   

    Meeting summary for 7/31 

    Logs: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-ui&day=2012-07-31&sort=asc#m49644

    • Media wireframes: look at them if you haven’t yet, and leave feedback. Development breakdowns and work will happen in #wordpress-dev when we get there, for the development-minded. WCSF dev day will also be a forum for more discussion for those who are there, and we will be vigilant about sharing those conversations publicly. Tickets to keep an eye on: #21390 and #21391
    • Accessibility is still a big need in terms of expertise and hands on deck, and there are plenty of tasks with UI implications. Discuss on the post if you’re interested or have knowledge when it comes to making things accessible on the web (screenreaders and non-mouse users, for instance) or hit up @sabreuse, who is helping shepherd efforts. Also keep an eye on Make Accessibility.
    • Welcome screen v2 is also still in wireframe and copy feedback stage. We need to drop the Spotlight/Alfred/Quicksilver search thing in terms of core development this cycle (sorry, we know how cool it is) and focus on iterating on the panel that is there. We also need go back to focusing on new user experience (NUX) and initial walkthroughs/links for now. The ideas have been great, and are not being thrown away by any means – we just need to focus so that we can actually get something done in time. Who knows, if we move fast, and get user testing rolling, we might be able to look at more iterations (and toss in a hook to make a plugin for the Spotlight thing possible) :)

    And finally, a reminder that open office hours are every weekday at 19:00 UTC (3PM EDT). #wordpress-ui is always open for discussions, but if you’re a little more nervous about just poking your head in or want to schedule something with a group, it’s a great time to do just that!

     
  • Mark Jaquith 9:30 pm on August 1, 2012 Permalink | Log in to leave a Comment
    Tags: Development, HiDPI, Retina   

    How to Develop for HiDPI (“Retina”) without a Retina MacBook Pro 

    We’re working on HiDPI (“Retina”) support for WordPress. Of course, most people don’t have a Retina MacBook Pro at their disposal. So here’s how OS X-using WordPress developers can do HiDPI development without dropping $3,000 US on a laptop.

    What you need

    • OS X 10.8 Mountain Lion
    • A monitor, with a resolution of at least 2048×1536 (probably just 27- and 30-inch monitors)
    • An Apple developer account

    Steps to enable HiDPI mode

    1. Click here and log in with your Apple developer account.
    2. Find “Graphics Tools for Xcode” (the latest version offered) and download the DMG.
    3. When the DMG opens, drag the contents somewhere (I put them in /Applications/Xcode Tools/).
    4. Launch the “Quartz Debug” app (this is the only one you need, so you can get rid of the other ones if you like).
    5. Press ⌘2 or go to Window > UI Resolution.
    6. Check the “Enable HiDPI display modes” checkbox.
    7. Log out of OS X (⇧⌘Q), then log back in.
    8. Pull up your Displays preferences pane ( > System Preferences > Displays).
    9. Check the “Scaled” radio button.
    10. Look for the highest resolution mode listed that says “(HiDPI)” after it, and select that.
    11. Lean way, way, way back in your chair and apply a saline solution to your eyeballs.

    You can now use Safari 6+ or Chrome 21+ to view your WordPress development site and do HiDPI development. Note that while you can do this with lower resolution screens, I’m not sure I’d recommend it — it’d be very cramped.

     
    • Clifford P 9:37 pm on August 1, 2012 Permalink | Log in to Reply

      Hi Mark. Great topic! I wrote this article not too long ago: http://wpmu.org/wordpress-retina/ Good article.

    • Russell Jamieson 10:05 pm on August 1, 2012 Permalink | Log in to Reply

      Many Thanks Mark, you saved me $3k on replacing by MacBook and gave me some more good reasons to upgrade to Mountain Lion and ditch my 24 inch monitor.

      Russell

      PS
      My new motto for WordPress themes and plugins is:

      If it ain’t responsive, it’s dead!

    • Pete Schuster 10:49 am on August 7, 2012 Permalink | Log in to Reply

      If you’re installing Xcode you can also check out retina elements with the iPhone (retina) and iPad(retina) selections in the device options in the simulator app. It’s not going to give you full screen, but you can check your dpi media queries.

  • Daryl Koopersmith 4:03 pm on July 30, 2012 Permalink | Log in to leave a Comment
    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? ;)

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

            This is actually already doable. When you do [gallery include="1,2,3"] there is no requirement for those images to be attached to the current post. We’ll be piggybacking on that.

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

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

  • Amy Hendrix (sabreuse) 4:40 pm on July 25, 2012 Permalink | Log in to leave a Comment  

    Accessibility tickets with UI implications 

    There are a number of recent tickets about accessibility improvements in the admin, several of which raise questions that relate directly to the UI group. In particular:

    #21283 Keyboard focus in the theme customizer should be on left options panel

    #21310 Need skip link(s) at top of admin pages

    #21312 How to log out of WordPress without a mouse?

    #21324 Visible Focus within Admin Screens could be much clearer

    #21326 Screen Options in Admin – Accessibility Enhancement

    #21334 Accessibility of Quick Edit panel in Posts/Pages/etc

    Please check them out and comment in-ticket with any feedback you may have; the same goes for any of the open tickets in the Accessibility component. Also, there are some tickets in the most recent batch that should be fairly easy for people who are just learning how to contribute. As always, you can ask here or in #wordpress-ui or #wordpress-dev any time if you need help with the whole process of working with trac and trunk, applying and building patches, and the like.

    In general, we want to be keeping accessibility in mind with all UI work and working closely with the accessibility group. Major thanks to everyone who has been stepping up and raising these issues lately!

     
  • lessbloat 12:49 pm on July 24, 2012 Permalink | Log in to leave a Comment  

    Welcome screen design v2 

    I’d like to get the ball rolling on the new welcome screen redesign for 3.5. I started playing around with a few ideas and I’d love to hear your thoughts:

    My hope for this screen is that it will serve as a proper “home” that users can come back to again and again to find anything they need in the admin. As I mentioned here, this was a big stumbling block for each of the users we tested.

    A couple of notes:

    • All of the copy and links are super generic, and need work.
    • You’ll notice the addition of tabs to the dashboard. My thought was that new users would be taken to this “Welcome” tab just after install. If they clicked the “dashboard” tab, we’d save that to the DB via AJAX, and on refresh, you’d still be on the dashboard tab.
    • On the right you’ll see the “viewing” drop down. My hope is to make the entire welcome tab extensible, so that you could add your own custom screen (set of links, and quick links) as an option. This dropdown would only show if you’ve added your own welcome screen option.
    • You of course should be able to easily hide the “welcome” tab (if you wish) through a hook. As well as having hooks anywhere else they make sense.
    • The “What are you trying to do” text box should suggest links as you type – similar to the idea here. I will note that while there are 1000 things that we could add to this auto-suggest dropdown, I’d prefer to just focus on adding links to functionality within the admin for the 3.5 release (and really making that experience solid).
    • The “Quick links” bar would be links to the most used sections of the admin (for new users). I was hoping we could find a nice library of open source vector icons to use there.

    Here’s the balsamiq source file if you’ve got some ideas based on this wireframe: http://cl.ly/1K3R2u383f28

    This is all still very rough, and I expect that we’ll go through a couple rounds of iteration before we get it right. Thoughts?

     
    • Tom Auger 1:29 pm on July 24, 2012 Permalink | Log in to Reply

      Yeah, I’m really digging the Quick Links, though you may be missing proper space for the actual welcome message, which I think some will want as it may be the only opportunity for any messaging regarding the current release, and/or more general/marketing messaging regarding WordPress.

      I wonder whether there shouldn’t also be more differentiation between the roles of the right-hand widget area vs. the lower widget area. In the current mockup, it’s just got this “wrap around” feel, but there should be a stronger sense of hierarchy in the areas. What about, going from left to right: (1) Main Nav (menu), (2) Tasks, welcome and help area, (3) Info/Feeds area.

      Given the current usability issues around feeds as they are now (for new users that is), perhaps the feeds start out minimized or otherwise hidden, to be revealed as an option once the user wants to “learn more” or “stay current” (or whatever the right nomenclature for that action might be).

    • Eric Mann 3:04 pm on July 24, 2012 Permalink | Log in to Reply

      I like the general layout of the screen, but I’m not sure that I’m sold on the tabbed interface. We would then have tabs at the top, the nav column on the left, and (presumably) the toolbar at the top of the screen. That kind of redundancy is … bulky.

      However, I do very much like the Quick Links idea and the omnibar/spotlight functionality. I can see both being used quite heavily by just about everyone I know who publishes with WordPress.

    • Ipstenu (Mika Epstein) 3:34 pm on July 24, 2012 Permalink | Log in to Reply

      I’m not sure ‘post a new image’ and ‘post a new video’ are that helpful, since generally we don’t do those things outside of writing posts/pages.

      ‘Customize settings’ or ‘customize site’ so people know right away to change ‘Yet another WordPress Site’ would be IMO a little bigger on the list, since really, how many sites are still stuck with that.

      • helenyhou 3:42 pm on July 24, 2012 Permalink | Log in to Reply

        I think quick posting in post formats would actually be a really good thing, especially if it’s in-screen (e.g. a slide-down panel or some such) – those of us who don’t maintain tumble-style blogs but write long-form instead aren’t really sensitive to that usage. Those kinds of actions seem like a really natural progression of Quick Press, IMO.

        Of course, there are some other considerations (meta keys, linking to an add screen and setting some fields via query args, etc.) to making that really work, but worth thinking about.

      • lessbloat 4:03 pm on July 24, 2012 Permalink | Log in to Reply

        To be honest, I didn’t put any thought into the links I added there (other than the customizer link, I’d like for that to be front and center). I just looked at the icons included in balsami1, and threw a couple in to mock it up. We’d need to think all of the links through for sure.

    • helenyhou 3:37 pm on July 24, 2012 Permalink | Log in to Reply

      The “Quick Links” box is really what I was imagining for the Dashboard in general, so +1 to that. Hooks are especially important there, and doing some smart things like “Edit your home page” when a page is set as the static front page, etc. would be nice.

      My concern here is when this isn’t really a “welcome” screen anymore, or if it never is (e.g. an upgraded install). I wonder if we can explore different language that’s more along the lines of “quick start” or something else that isn’t necessarily tied to a fresh install, since we’ve learned that a) users go back to their first place of success (so in future versions, how would this function?), and b) this could head toward the “doing” side of the Dashboard, as in a more permanent fixture.

    • lessbloat 4:38 pm on July 24, 2012 Permalink | Log in to Reply

      Some additional commentary via IRC.

    • lessbloat 4:59 pm on July 25, 2012 Permalink | Log in to Reply

      I worked up a v2 this morning (based on feedback from v1):

      A couple notes

      • I dropped the tabs.
      • I removed “Welcome”.
      • Again, the links, and copy all still need some thought (this is just a rough mockup – nothing is finalized).
      • A link to the customizer is both first in the row of icons and first in the “New User Walkthrough” section. This is important because within the customizer they can change their: site title, tag line, site colors, header image, background image, and static front page setting.
      • I’ve encapsulated all the links in a single dashboard widget container which can be hidden in screen options, or minimized (just like any other widget). However, we’d still want to load this with an action so people could remove it altogether if they wish.
      • For the “Post an image” and “Post a Gallery” links, I was wondering how hard it would be for us to link to the new post page with a $_GET var at the end of the link which would auto-load the media manager (since this would work whether their theme has post formats or not), and if the theme has post formats, auto-select the right format. Just a thought…
      • For the “Post a Video” link, can we come up with something clever there as well? I’m not sure…
      • In terms of responsiveness, this could all scale down relatively well I think.

      Am I missing anything?

      Here’s a link to the balsamiq source file: http://cl.ly/2a2I0U393C28

      Thoughts?

      • alternatekev 6:30 pm on July 25, 2012 Permalink | Log in to Reply

        While I’m really digging the spotlight-centric top area, something about having 8 icons in a row like that turns that entire area into noise for me. I feel like 4-5 is a more manageable number of options there. I also wonder if some even earlier-type options should be there, like adding plugins or themes via the UI.

    • Ipstenu (Mika Epstein) 6:27 pm on July 25, 2012 Permalink | Log in to Reply

      We could drop ‘QuickPress’ if ‘Write a new post’ did a dropdown (wrong word, hungover) to show the quickpress box?

      Call the top box ‘Welcome to WordPress!’

      I like the New User Walkthrough!

      • lessbloat 5:17 pm on July 27, 2012 Permalink | Log in to Reply

        Thanks @ipstenu!

        While I’d love to re-work the QuickPress area, I’m afraid it’s a bit out of scope for this release.

    • MartyThornley 7:02 pm on July 25, 2012 Permalink | Log in to Reply

      Very cool! Would be great if users could show/hide the row of quick links and the bulleted lists of links section. Only thing that made that come up is I feel like more advanced users would get sick of looking at the New USer Walkthrough and Basic Settings sections. But this would be awesome for new users!
      Also huge +1 for the expanding Quick Press idea!

      • lessbloat 5:19 pm on July 27, 2012 Permalink | Log in to Reply

        I think the idea will be that you can hook in and change those links however you’d like, which would also allow you to remove any of these sections if you choose.

    • lessbloat 5:06 pm on July 27, 2012 Permalink | Log in to Reply

      Here’s a quick v3:

      I’ve promised Nacin that we’ll focus on nailing down the basics first before trying to figure out any quick search functionality. As such I’ve removed it for this iteration.

      At this point, I’d love your thoughts on the copy, the order of the links, and the sections (though other feedback is also welcome).

      • Amy Hendrix (sabreuse) 5:22 pm on July 27, 2012 Permalink | Log in to Reply

        Thoughts in bullet-point form:

        • I wonder if the copy in the quick links section is too beginner-oriented. The eye-opener for me from your testing rounds was that people were using the welcome screen as a functional dashboard rather than an intro/overview. Too much “here are some things to do when you’re new”?
        • (I also suspect that the 20% may reject it because of the old fallacy of if it’s easy it must be “dumbed down”. I’m less concerned with that.)
        • Are the default widgets up for discussion? I rarely see any reason for the Plugins, WP Blog, or Other WP widgets to be there at all; the dashboard should be for doing, not reading. (OTOH, I think more people would use QuickPress if they got in the habit of actually looking at their dashboards. At least for drafting things.)
        • Next round, kill Links in the side menu ;)
      • Ryan Boren 5:36 pm on July 27, 2012 Permalink | Log in to Reply

        Would this be a good place to put a “Visit your site” link?

        I too would like to get rid of most of the boxes, particularly Links, Plugins, and the WP feeds. But really I’d like to get rid of all of them. Our options tables would all breathe a little easier without caching feeds that nobody looks at. But, I have yet to win that argument. :-)

        • lessbloat 6:08 pm on July 27, 2012 Permalink | Log in to Reply

          Well I for one +1 everything you said. ;-)

        • lessbloat 9:00 pm on July 27, 2012 Permalink | Log in to Reply

          As a practical first step for 3.5, could we uncheck all of the dashboard boxes in screen options on install (other than the welcome screen of course)? Then for 3.5.1 plan to recheck any that we hear a huge uproar about (I’m guessing there would only be a few, if any at all).

          This way, users could always activate any of them with a few clicks.

      • Isaac Keyet 6:05 pm on July 27, 2012 Permalink | Log in to Reply

        Looking at this I don’t know what will happen if I click either of the icons at the top. Do I get to a walk through? Is it a direct link to that section of WP? That’s the main concern for new users.

        For returning users, I think they’d (almost) be offended to see links to change the theme or write a post – if I’m a tech person or have ran a blog in the past most likely I already know these things. Unless it’s a comprehensive array of action-centric actions to perform across the entire install I think this is very much redundant and in your way.

        I think the solution is to ask the user a simple question once they’ve successfully installed 3.5, then show something customized for each Quick links screen depending on choice. After a while you should be able to hide the set up links but be able to keep the action-centric buttons (customize theme, new post, add page etc). Mocked this up real quick, screenshots and source files below.

        Welcome box (“hey, welcome! great to see you! here’s what’s awesome!”):

        Quick links for beginners:

        Quick links for returning users (advanced):

        Quick links in Default mode (a good start on an action-centric Dashboard IMO):

        Source files: http://cl.ly/0f2Y341e3i36

        • lessbloat 6:16 pm on July 27, 2012 Permalink | Log in to Reply

          As usual Isaac, I’m a fan. :-)

          Thanks for taking the time to crank these out. I’m really liking the flexibility that this approach provides.

        • Ipstenu (Mika Epstein) 8:46 pm on July 27, 2012 Permalink | Log in to Reply

          There’s no Like button on .org, but Like!

        • MartyThornley 10:15 pm on July 27, 2012 Permalink | Log in to Reply

          This looks great!

        • karmatosed 6:35 pm on July 29, 2012 Permalink | Log in to Reply

          Looking at these I think that the splitting in direction really is great. I was going to join in with mockups but to be honest, this about nails it for me it really solidifies everything. Like, +1 and any other way of saying this rocks :)

    • lessbloat 8:51 pm on July 27, 2012 Permalink | Log in to Reply

      Here’s my rather crude experiment to see if we can make this block responsive: http://f.cl.ly/items/0K0B3E2o0S023f3S2b3k/responsive-welcome-screen-v1.html – It’ll still need lot’s of love.

      • karmatosed 6:37 pm on July 29, 2012 Permalink | Log in to Reply

        For the bottom links is there any way to add in a 2 rather than the jump from 3 to 1 as it seems like that might be smoother?

    • lessbloat 2:24 pm on July 30, 2012 Permalink | Log in to Reply

      Here’s a v4:

      Some thoughts

      • In Isaac’s first screen he had two buttons which allowed the user to choose which welcome screen they would see. My worry in doing this is that these buttons might get lost in the noise from the rest of the dashboard, and users wouldn’t be able to see at a glance what happens once they click one of the buttons. I think I’d prefer to skip this step if at all possible, and just hop straight into showing the “get started” screen. At which point, users could change it to another screen through the options drop down.
      • Next, in Isaac’s mockups he also had an “Advanced” option. I thought about this a lot actually, and decided to leave it out as well. My hope with the welcome screen redesign is that we can get a bunch of hooks in place so that if you want to add/remove links you can. Again, I’d love to hear your thoughts here (and if you think the advanced option should stay, what links would you place there?).
      • I reduced the number of links under each column from 6 to 4. I feel like this still works well, while keeping things tidy.

      Dev tasks

      We can likely get started planning the dev side of things. cc// @sabreuse, georgestephanis, & @azaozz

      A couple of questions/considerations:

      • What is the best way to make this area easily extensible?
      • Can developers change a single link in one of the existing screens?
      • Can developers create their own screens (which are added to the dropdown options)
      • Can developers easily remove the entire “Quick links” box?
      • Can developers change the “Quick links” title
      • Can developers easily remove the options dropdown, and force either the “get started” or the “default” screen to show?
      • Can developers remove a single section within the box (e.g. remove just the “New user walkthrough” column)?
      • Can developers rename a section (e.g. change “New user walkthrough” to “Get started”)
      • Can developers add their own top icon links? If so, how do they add the icon image?
      • How/where do we save which screen the user has selected, so that on refresh they see the same screen?
      • Is there anything else we need to consider?

      I’m not saying we should support all of these scenarios. :-) I’m just trying to get them all on the table so that we can make a decision as to which we should support.

      Thoughts?

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

        Extensibility for everything mentioned (titles, additional screens, links, etc.) can and probably should all be doable via filters. Nothing in the box should be hardcoded in, but use actions instead. I think it’s pretty important to give a programmatic way to alter or turn off this particular metabox (which is special in its full-width treatment) to fit the needs of a particular site or network. Visual options not needed, though :) Besides the usual screen options checkbox.

        We can save the user’s selection the same way we do any other screen preference – user meta.

      • Sheri Bigelow 7:46 pm on July 30, 2012 Permalink | Log in to Reply

        You might consider the “advanced” option as the actual entire dashboard itself, and in that case you don’t need a separate advanced option inside the welcome screen. If you did have one though, I love the idea of a smart “common tasks” list that updates based on most-used areas (out of scope and maybe not something everyone would like).

        Regarding labeling, I think “Welcome” is fine. You can welcome advanced users back into their dashboard and they may appreciate a set of icons or links just as much as beginner users. “Welcome” also fits with what I think of as the original goal of the welcome screen—to help new users get started (correct me if that’s wrong). Keep the problem you’re trying to solve in mind.

        You lost the link out to the Codex: http://codex.wordpress.org/First_Steps_With_WordPress Do you want to promote the Codex at all? If so, maybe consider adding back a Codex link under the “Get Started with WordPress” heading. I feel like there should be something in this screen that stands out and says, “if you’re really lost and don’t know what to do, go here.” A Codex link could be it. You might even consider it (Help|Codex|Documentation) as one of the main icons (though maybe there’s not enough space).

        This will probably just reinforce some of the decisions you’ve already made, but here’s a snippet from some recent user testing I did where the user got stuck trying to get past the welcome screen after they’d been given the task to go to Appearance → Themes. It’s interesting to see it out of context (i.e. intermediate user, main goal is not getting started). Note: I cut out the top part to hide personal info displayed at the top of the page.

        http://designsimply.files.wordpress.com/2012/07/welcome-screen-406008e.mov

        One thing I did like about the old 3.4 welcome screen is that the lists felt like logical sets of steps to me: 1) Basic Settings, 2) Add Real Content, and 3) Customize. However, even if you didn’t arrange the lists like that, your v4 is still a killer improvement building up the original welcome screen work.

        One problem I’ve found in testing the Customizer is that most themes don’t lend themselves to a good customization experience for new users because brand new blogs are typically empty. Even adding a little “real” content first makes the customizer user experience 10x better. Something to keep in mind when arranging icons/lists.

        “Default” as a top right drop-down option doesn’t make sense to me because it’s not really the default panel (I think).

      • Syed Balkhi 3:05 pm on July 31, 2012 Permalink | Log in to Reply

        I don’t know if it would help to show the Get Started with WP 3.5 text/link all the time. I think after the first few times, it would get super annoying. I love the quick links icons idea, and I think many will benefit from it.

        What would be even cooler is if the user can determine their own quick links. (i.e drag Add a Post link to the icons area and it makes it into an icon link). This would be really handy for CPT’s. For example if you are running a coupons site… the quick link would then say Add a Coupon etc.

        • lessbloat 3:13 pm on July 31, 2012 Permalink | Log in to Reply

          Thanks for the feedback! The icon links will be easy to hook into and change, but they won’t be drag and drop.

      • Mel Choyce 6:34 pm on July 31, 2012 Permalink | Log in to Reply

        There doesn’t seem to be any mention of pages — it almost feels like the only major feature missing. Perhaps we could find some way to integrate it into “new user walkthrough”?

        • lessbloat 6:45 pm on July 31, 2012 Permalink | Log in to Reply

          Ah, you’re right. That must have slipped out in revision. I’ll make sure to get “pages” back in there. Nice catch!

    • Sean Butze 6:38 pm on July 31, 2012 Permalink | Log in to Reply

      +1 for the ability to customize the icons via plugins/themes. I think this is something that should definitely be customized for different use cases.

      Also agree w/ Mel that Pages should be considered for being one of the default icons. For virtually every WP site I’ve built Pages is the #1 most used feature.

    • burtrw 9:42 pm on July 31, 2012 Permalink | Log in to Reply

      I absolutely love that the dashboard and new user experience is getting some love here. I’ve thought a lot about it over the years, and in my day job, worked on lots of different plugins, dashboard widgets, and ways to improve this experience on our large multisite networks. Some of my ideas from a few months ago are here: http://wpmu.org/making-wordpress-more-user-friendly-a-usability-audit-of-joomla-drupal-blogger-tumblr-and-squarespace/

      Looking at these mockups, what I would really like to see is a whole lot less. Less redundancy. And less intimidation.

      For what it is worth, I would love to throw out a couple of ideas. Not sure how I can help or what that process looks like, but would definitely to do what I can!

      1. I’m not a fan of all the links, icons, and guides of things that are really just a click away in the flyout menus on the left. We don’t want to train users to look for these in the dashboard, as once they go to write a post, for example, they probably won’t realize how to get back to that dashboard or welcome page. We really want to train them to use the menus from the very beginning.

      2. I think the whole dashboard should be very clean and sweet – basically more like a notifications or “To-do list” area. Completely get rid of all of the overwhelming dashboard widgets and everything.

      • if this is the first time the user has logged in, welcome them, have them review their profile info, upload an avatar, etc.
      • if the theme is a default theme, suggest they may want to check out others
      • if there aren’t any posts written, or it has been more than say a week since one has been published, suggest they write a post
      • if there are comments to be moderated, show them, and let the user moderate them
      • if there are posts to be moderated, show them, and let the user moderate them
      • if plugins, themes, or WordPress needs upgrading, let ‘em know

      And so on, and so on.

      Could only show 2 or 3 at a time, so not to be overwhelming and users could dismiss them.

      As it is now, when a new user logs into the dashboard for the first time, they are left to figure it all out on their own. In this way, they would always have one simple action item or task they can complete, and in the process, would learn on the job and would know where to start.

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

        Redundancy is a good point. It’s almost like the smaller version is a rewrite of the Right Now meta box and the Get Started version could be it’s own separate meta box for welcoming new users.

    • rubai 8:42 pm on August 3, 2012 Permalink | Log in to Reply

      I like to say that the v4 is nice but I would have liked if some of the links can be turned off. and I am not a big fan of the full width box.

  • Helen Hou-Sandi 4:52 am on July 24, 2012 Permalink | Log in to leave a Comment
    Tags: , , , Trac tickets   

    #21019 – Retina All the Things 

    The current goal is to HiDPI/2x current assets, whether that’s through making new versions of various images/icons or converting to CSS solutions (pretty much gradients and perhaps comment bubbles). Longer-term we may end up using other solutions, but for the moment let’s focus on the task at hand.

    I’ve left a long comment about things I’m seeing as still needed. No need to know how to do the CSS patching – a dev can jump in and do that part if you’re more comfortable with the graphics side. What we need is people helping out with creating 2x versions of things, sometimes in various colors. We may need to coordinate with @empireoflight (Ben) to make sure there’s no duplicate effort.

    You’ll want to be uploading files to Trac for the most part – if you want to have somebody take a look first, feel free to post a comment here or talk about it in IRC (office hours are a great time for that). Note that uploading files to Trac does not trigger an email notification, so you’ll want to leave a comment noting what you’ve added so it’s not overlooked. Again, feel free to ask questions here or in IRC if you’re not sure what to do and we’ll try to get you sorted!

     
    • helenyhou 1:52 pm on July 24, 2012 Permalink | Log in to Reply

      @empireoflight has indicated that he’s looking at these now. Keep an eye on the ticket in case he gets to something first.

  • Andrew Ozz 8:01 pm on July 23, 2012 Permalink | Log in to leave a Comment  

    Most links and buttons in the admin don’t have clear :focus and :active styling. This is a big problem when using the Tab key to navigate. There is usually no indication of what element is focused and if there is some, like on the admin menu, it’s quite weak/unnoticeable.

    Thinking we should add clear and visible styles for :focus and :active everywhere by default. If this is impossible to do without making the UI “ugly”, can add another global screen option “Enhanced Accessibility” or similar that would turn these styles on.

    Pinging all designers, if you come up with a nice solution, please add a screenshot (and possibly a patch) to ticket 21324.

     
  • Jane Wells 5:08 pm on July 19, 2012 Permalink | Log in to leave a Comment  

    Heads up: I’m taking a leave of absence! See the post on wpdevel make/core for details.

     
  • Daryl Koopersmith 11:47 pm on July 18, 2012 Permalink | Log in to leave a Comment  

    Media in 3.5 

    One of the goals for 3.5 is to redesign and improve the workflows for uploading and selecting media in WordPress. Over the next week or so, we’ll be working to flesh out exactly what this will entail from both a technical and design perspective.

    Scope

    To ensure we stay on track, our focus and top priority is to improve the “Upload/Insert” modal window. Anything outside of that modal UI is technically out of scope — nice to have, but by no means necessary.

    For the 3.5 cycle, we have allotted two months for feature development. Due to the size of this project, a lot will be going on at once. Development on basic structures will begin this week.

    What can I do?

    Over the next few days, feel free to comment with:

    • Ideas
    • User tests (for the current UI)
    • Concepts and wireframes (quick sketches or text descriptions, it’s all good)

    Keep in mind…

    We should also be keeping an eye towards the future: we should build modular components that can be adapted for other workflows and potentially be reused in inline UIs.

    The media modal currently covers media in posts, galleries, custom headers, and custom backgrounds. Several elements in the modal also blend into the media section of the admin.

    Most workflows include a handful of processes:

    • Uploading media.
    • Selecting item(s) from the media library.
    • Editing media details (both item-specific and workflow-specific).

    I highly recommend reviewing our current media model. It is fairly complex, and reducing it to a simple system will be quite the challenge.

    Let’s talk!

    If you’d like to chat with myself and other UI team members about media, comment here, or ping us in #wordpress-ui (especially during office hours).

     
    • Travis Smith 12:40 am on July 19, 2012 Permalink | Log in to Reply

      Personally, I would really like to see WordPress be able to switch to Imagemagick via an option in Settings > Media if Imagemagick is recognized on the server. I have had a ton of requests for this in my development, especially for those photographers and journalists.

      • Daryl Koopersmith 12:50 am on July 19, 2012 Permalink | Log in to Reply

        We were discussing abstracting the image APIs to able to use either ImageMagick or GD in IRC last week and earlier today:

        nacin: I would really like someone to implement ImageMagick alongside our use of GD. If someone is willing to step up on that…

        Using ImageMagick would fall more on the API / dev side of things, and less the UI side. That said, I’d love to see it happen.

    • Mel Choyce 1:58 am on July 19, 2012 Permalink | Log in to Reply

      I decided to take a shot at a really rough comp for uploading outside of the modal window. At some point we had talked about integrating media into the post page (especially adding media) so people can still work on their post while images are uploading.

      Here’s a screen to show the media uploader on the post page.

      Here’s a screen to show uploading images.

      I’ve added a media button to the content editor to pull up the media modal window. Clicking on “Show Details” and/or “Edit Image” in the completed upload listing would also pull up the modal window.

      An immediate problem I see: Putting media uploading on the post page takes up a lot of space. If we wanted to go this way, maybe we could consider putting it into a collapsible panel so users could show or hide the image uploader.

      • Mel Choyce 3:01 am on July 19, 2012 Permalink | Log in to Reply

        Err, one other thing I just realized is that as things are set up now, “show details” would have to expand on the post page so people could choose what image size they’re going to be inserting into their post (along with the other meta data). So maybe having “add to post” along with “show details/edit” wouldn’t work.

      • Ben Huson 11:55 am on July 19, 2012 Permalink | Log in to Reply

        I think probably in a collapsable panel would be a good idea and I would suggest maybe it could be below the main editable area?

        • José Marques 10:18 am on July 20, 2012 Permalink | Log in to Reply

          Hello everyone (my first post here!).
          I like this concept, having an area to drop a bunch of files, collapse it and continue to compose your post. Maybe the collapsed area could have a progress indicator referring to the status of the uploads?

      • MartyThornley 5:44 pm on July 19, 2012 Permalink | Log in to Reply

        I agree with the problem of too much space. An in-page upload when dding a lot of images could take up a lot of real estate. I would love to see an overlay style box, similar to this quick mockup: http://grab.by/eR2C. I tried to style it after the existing tooltips.

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

          The only problem with keeping a modal window is that users aren’t able to work & upload images at the same time. The less we interrupt our users’ workflows the better.

          • MartyThornley 8:03 pm on July 19, 2012 Permalink | Log in to Reply

            How is this any less disruptive than thickbox? It covers the whole screen while you upload.

          • MartyThornley 8:04 pm on July 19, 2012 Permalink | Log in to Reply

            Or you mean thickbox, modal, etc. vs in-page, where in-page could be working while you write?

            • Mel Choyce 8:15 pm on July 19, 2012 Permalink

              Modal vs. in-page, so you can write your post as images are uploading. I personally like your modal window so far better than thickbox.

          • MartyThornley 8:23 pm on July 19, 2012 Permalink | Log in to Reply

            Gotcha. Hadn’t thought of it that way. But there is talk of maybe processing it all in the background, so maybe it wouldn’t make a difference?

            • Mel Choyce 9:12 pm on July 19, 2012 Permalink

              Didn’t know that! Definitely interested in seeing how that pans out. Thanks for the info.

    • Isaac Keyet 11:55 am on July 19, 2012 Permalink | Log in to Reply

      Talking about low-hanging fruit outside the modal view itself, I think something like this would be huge for new users:

      http://f.cl.ly/items/3A1U0W0o221z3X1k0R0k/media-insert-button-sketch.png

      If we’re going to tamper with TinyMCE in 3.5 though, it may make sense to instead group it with the other tools somehow.

    • Ben Huson 12:06 pm on July 19, 2012 Permalink | Log in to Reply

      A tiny little thing but something I have already semi-written a patch for…
      When you launch the image edit popup from an image in the editor, it would be nice if you enter image dimensions if you could choose to lock the width/height aspect ratio.

      Example: http://imgur.com/zZZOd

    • Andrea Rennick 3:08 pm on July 19, 2012 Permalink | Log in to Reply

      One thing that isn;t clear to users is that the action of uploading media while composing a post does create a relationship between that post and media, the “attachment” as you will.

      No idea how to relay this to users – just thought it deserved a mention.

    • Cliff Seal 3:33 pm on July 19, 2012 Permalink | Log in to Reply

      I’d love to see multi-image insert and the general flow discussed and improved (i.e., http://core.trac.wordpress.org/ticket/7013). It’s a consistent snag for newer users who expect to be able to select and insert multiple images immediately after upload or from the Gallery/Media Library. Perhaps even more frustrating than this is that the modal window closes after insert. That’s unexpected, then they open the window again, only to be confused about where the images actually are now (because there’s no sign of them in the ‘From Computer’ tab for obvious reasons).

      Some of these ideas have been addressed in the ‘Faster Image Insert’ plugin: http://wordpress.org/extend/plugins/faster-image-insert/screenshots/

      I’m going to mock a couple of views up, but I’m thinking a combination of better tab labeling, good feedback while keeping the modal open (i.e. “Image was inserted.”), and multi-upload (gallery use notwithstanding) would make the flow and usability much better.

      Isaac’s and Ben’s suggestions are much needed as well.

      • MartyThornley 5:54 pm on July 19, 2012 Permalink | Log in to Reply

        Definitely agree about the multi image insert. I actually wrote a plugin for it that we use on PhotographyBlogSites. It has been working since before the new uploader and to my surprise worked just as well with the new drag and drop uploads. I never got around to adding it to the repository but I have attached it to that ticket (http://core.trac.wordpress.org/ticket/7013#comment:21). It was based, at least at the start on that Faster Image Insert plugin.

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

        +1. Re: multiple image insertion, I like the idea of checkboxes and an “insert all selected” button.

    • ovedmo 6:35 am on July 20, 2012 Permalink | Log in to Reply

      I think media files must group under media-category!!

      • MartyThornley 8:55 pm on July 20, 2012 Permalink | Log in to Reply

        Big +1 fro grouping of media. It fits into the process of how things are uploaded, attached, etc. Ideally you could upload images, use different ways of grouping ( tags, categories, etc. ) to group them. Then as you browse media, you could sort based on those. This could even be a way to approach galleries. If galleries were just a taxonomy or meta info attached to images, you could add images to any number of “galleries” and then add galleries to any number of posts/pages.

    • lessbloat 2:27 am on July 24, 2012 Permalink | Log in to Reply

      Here are a couple of wireframes that I’ve been working on: http://davemart.in/?p=28

      I’d love to hear your thoughts.

      • MartyThornley 8:07 pm on July 24, 2012 Permalink | Log in to Reply

        I had a couple initial thoughts and did some quick hackups of your mockups to help illustrate.

        1) Love the separation of upload/select workflows but I think it could add confusion by making the first step be a choice between those two and having the buttons trigger separate windows. If a user thinks Select is the right one but decides to upload, you would have to close the window and start again it looks like? I think a better way would be to keep the idea of one “Insert Media” button, then in the window, you can decide where it is coming from.

        2) Along the same lines, if the upload/select/remove buttons could all be similar wording and look, then it would help in a few areas – save space, save time/effort of design and coding (all would just say “Upload” not “Upload Background Image” or “Upload Header” for example. ( see linked mockup of background image )

        3) The black boxes in the select workflow look too big if you ever have to scroll through lots of images. Maybe a much smaller grid so we can see at least 20-something images at a time and maybe a choice to expand to a larger view?

        4) The addition of seeing both select new and remove for the featured images is a great idea. Users tend to get confused about adding a new one right now when the only link visible is “Remove Featured Image”. I added a couple ideas towards making it more consistent and easy to use.

        Featured Images and background image mockups
        http://grab.by/eXda

        Media library
        http://grab.by/eXfm

    • GrahamArmfield 5:41 am on July 24, 2012 Permalink | Log in to Reply

      One key requirement for this moving forward would surely be to make the whole process keyboard accessible – for those users who don’t or can’t use a mouse. It’s an interesting challenge to be able to allow keyboard users to upload media and add title, alt text, choose size etc whilst at the same time saying “I want to insert the image here” ie at a point inside the TinyMCE editor. I’m trying to think of solutions but wanted to place the thought in people’s minds.

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