Make WordPress UI

Updates from Mark Jaquith Toggle Comment Threads | Keyboard Shortcuts

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

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

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

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

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

     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

              Tough call…

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

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

      -(Eleventy Frillion) to a modal.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Awesome work, Sara! These concepts look rad.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        Related/possible solution: #24011

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

          Thanks, didn’t see that ticket.

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

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

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

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

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

        What if you consolidate?

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

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

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

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

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

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

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

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

        +1 for hiding seldom used formats.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Mark Jaquith 8:37 am on March 22, 2013 Permalink  

    Should we tab the Plugins page with Manage Plugins / Install Plugins in the same way that we’ve done with Themes? Why or why not?

     

    • Franz Josef Kaiser 10:14 am on March 22, 2013 Permalink | Log in to Reply

      Personally I don’t see any value in adding tabs. What I would see value in, is having a way to organize or group plugins. Currently I have ~200 custom written plugins that I manage with this [1] plugin, which makes my local stack quite slow. As a developer I’d really like to have any kind of way to better organize those plugins and not use a slightly fragile, slow plugin that took a lot of time to develop.

      From a user perspective I’d like to see an UI that is equally designed and usable to the one we have for themes. Basically both are the same so I would expect to have a lower entry barrier for new users. From a core dev perspective this would as well offer a chance to remove redundant code pieces when both screens can share parts of their view building code.

      [1] https://github.com/franz-josef-kaiser/WP-Plugin-Directories

      • Russell Heimlich 12:54 pm on March 22, 2013 Permalink | Log in to Reply

        +1 on the idea of better organizing plugins. I thought about writing a plugin that lets you type in a field and the plugins shown get whittled down to only show the ones that match parts of what you type. Similar to the filter topics feature of this page http://www.pewresearch.org/topics/

      • Scott Kingsley Clark 1:25 pm on March 22, 2013 Permalink | Log in to Reply

        I also would like to see some sort of categorization (whatever that is) in the plugins list.

      • Shane Pearlman 3:10 am on March 23, 2013 Permalink | Log in to Reply

        +1 of on plugin organization, at least in regards to add-ons and extensions to larger plugins. The events calendar has a number of add-ons and it would be nice if they were grouped visually.

    • Russell Heimlich 12:55 pm on March 22, 2013 Permalink | Log in to Reply

      Yea I think so. It follows the theme of tabs that I’m starting to see show up in the admin interface. This would make a great user test to see if new users can find where to add new plugins easier than the way it currently is set-up now.

    • Scott Kingsley Clark 1:27 pm on March 22, 2013 Permalink | Log in to Reply

      I’d like to see tabs used here, not for just using tabs, but in hopes that the theme search UI may eventually be used for plugins too so you could filter by category (see Franz’ comment above) and other criteria (maybe).

      In my opinion, it would make the plugins page and add plugin page a little more consistent with the themes and add/search theme pages.

    • Tevya 2:32 pm on March 22, 2013 Permalink | Log in to Reply

      Plugins should look like Themes or Themes should look like Plugins. As far as I’m concerned, either is fine, just make it consistent. I’ve long wondered why they’re so different. Consistency please.

      • Tevya 2:44 pm on March 22, 2013 Permalink | Log in to Reply

        On 2nd thought: I’m not a big fan of the “tabs” on the Themes page. In MP6 they don’t really look like tabs anyway. Why not make it more like every other page in the WP admin and remove the “Manage Themes” tab entirely, and turn “Install Themes” into a small “Add New” button like on Plugins, and Posts, and Pages, etc???? That would be the most consistent.

      • Chip Bennett 9:34 pm on March 22, 2013 Permalink | Log in to Reply

        +1 for consistency between Themes and Plugins, whichever UI is ultimately chosen.

    • Ipstenu (Mika Epstein) 3:07 pm on March 22, 2013 Permalink | Log in to Reply

      Tabs, or buttons, since right now the links are small and I’ve had to send that screenshot of ‘This’ circled enough times this month ;)

    • Helen Hou-Sandi 3:14 pm on March 22, 2013 Permalink | Log in to Reply

      They should be consistent, yes.

    • sara cannon 6:09 pm on March 22, 2013 Permalink | Log in to Reply

      yes.. but if we go that direction, it would make sense to match the levels that they are in the menu hierarchy: possibly bringing themes top level (matching plugins) and letting appearance be about visual modifications / theme customizations & menus, widgets.

      • tomdryan 10:42 pm on March 27, 2013 Permalink | Log in to Reply

        Yes! Speaking as a relatively new WP user, there do need to be some simple changes to the menu hierarchy (and elsewhere) that can reduce the learning curve and increase the usability of WP. Is there a usability work group for WP or is that addressed in this group? In any case, I would love to contribute some usability feedback while all the fumbling around I did is still fresh in my head. :)

    • Mike Schinkel 12:15 am on March 23, 2013 Permalink | Log in to Reply

      I’d really like to be able to archive plugins, i.e. not delete them but ZIP and keep on the local system for later unarchive and (re-)activation. It would also be really great if we could group plugins and collapse the group so we don’t have to look at the long list of plugins. Finally a simple thing would be to have the list of activated plugins be the default rather than all plugins.

    • buzztone 2:21 am on March 23, 2013 Permalink | Log in to Reply

      I’d like to put in a cheer for Tabs on the Plugins Page. Used well they could significantly improve the usability of the interface.

      Some of the better plugins, like Yoast WordPress SEO, are now using tabs to significantly improve the ease of use of their plugins. Ease of use of the Plugins page could similarly be improved by adding some useful Tabs, starting with Manage Plugins / Install Plugins.

    • Matt Thomas 5:34 am on March 29, 2013 Permalink | Log in to Reply

      My +1 would go to making Themes work like other sections — where there’s an “Add Theme” button-like link next to the main themes header (this would re-use the same pattern as Posts, Pages, etc. too, not just Plugins). We struggled a little bit with what to do with this tabbed style in MP6, since it’s unique to the Themes pages (it appears on the About page too, but in a little different context).

  • Mark Jaquith 9:30 pm on August 1, 2012 Permalink
    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.

  • Mark Jaquith 7:54 pm on May 6, 2011 Permalink
    Tags: , ,   

    Not quite loving the metabox h3 style. The title of the box doesn’t stand out enough. Played around with some CSS gradients as a background, which was promising. But I’m sure someone else can mock up something quicker than I can. Not looking for a big change here, just something subtle so that the title doesn’t blend into the metabox text so much. Any ideas?

     

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