WordPress.org

Make WordPress Core

Tagged: post formats Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 9:57 pm on April 8, 2013 Permalink
    Tags: Audio, , MediaElement, post formats, ,   

    Audio / Video support in Core 

    Post Formats are a big feature in WordPress 3.6. What you may not know is: there is now native support for Audio and Video in core! There has been great support for embeds by way of WP_Embed and oEmbed providers for a while, but, if you wanted to play an MP3 from your Media Library, you had to install a plugin. Supporting audio and video in core gives bands, podcasters, vloggers, et al the ability to easily and beautifully expresses themselves through sounds and moving pictures without using an external service.

    How does this work?

    At the core of the experience is the fantastic library, MediaElement.js. MediaElement is the facade layer that gives us maximum file support and cross-browser compatibility. While some libraries require a Flash-only solution to make your media work cross-environment, MediaElement lets you use HTML5 audio / video tags in every browser, and, only when necessary, will use a Flash or Silverlight plugin in the background to make incompatible media work. Translation, things like this: <audio> tag works in old IE, Windows Media files work in Chrome.

    MediaElement uses the same HTML markup, regardless of playback implementation, and you can use CSS to skin the players.

    Shortcodes

    MediaElement’s great, but we don’t want to be locked in to one external library forever. Instead of using MediaElement-specific markup everywhere, we expose audio and video markup through shortcodes: [audio] and [video].

    For the following scenarios:

    • I have an old post that has a video in the Media Library attached to it, and I want to use the new shortcode: [video]
    • I have the URL for a video, from the Media Library or external, that I want to play:
      [video src="video-source.mp4"]
    • I have a source URL and fallbacks for other HTML5-supported filetypes:
      [video width="600" height="480" mp4="source.mp4" ogv="source.ogv" webm="source.webm"]

    Same goes for audio:

    • I have an old post that has an audio file in the Media Library attached to it, and I want to use the new shortcode: [audio]
    • I have the URL for an MP3, from the Media Library or external, that I want to play: [audio src="audio-source.mp3"]
    • I have a source URL and fallbacks for other HTML5-supported filetypes:
      [audio mp3="source.mp3" ogg="source.ogg" wav="source.wav"]

    Shortcodes focus on the “what” and abstract the “how.” If you want to use a library that is not MediaElement, you can! Just look at what to filter: here

    Embeds

    There are also new embed handlers for audio and video. Using them is easy as dropping a media link on a line by itself in the editor:

    http://my.mp3s.com/cool/songs/coolest.mp3

I like this song because it is really cool!

    Works for both audio and video with URLs matching the allowed (and filterable) list of extensions (see: here and here)

    Admin

    Using the new post formats UI, it is even easier to get directly at the audio and video in your Media Library. When selecting, the media modal opens to your library, filtered by media type.

    Metadata

    In previous versions of WP, you could upload audio and video, but we were not generating metadata like we do for images. In 3.6, using the getID3 library, we are able to extract data from audio and video like cover art, song length, artist, album, song title, genre, codec, etc. It’s pretty great. We will soon be exposing more of this data in the admin as well, along with inline previews on the Edit Media page:

    Themers

    Themers can get in on the action, too, using structured-post-formats in their theme (Twenty Thirteen is a great place to look). The admin gives users flexibility when associating media with a post. the_post_format_audio() and the_post_format_video() will automagically retrieve and output your media in the front end.

     

    • sourceforge 10:09 pm on April 8, 2013 Permalink | Log in to Reply

      thank you, is this the html5 vid player? looks good, newer java based audio player is also needed, flash is always prone to attacks

    • Manny Fleurmond 10:11 pm on April 8, 2013 Permalink | Log in to Reply

      How does this handle m4a files?

    • Konstantin Obenland 10:59 pm on April 8, 2013 Permalink | Log in to Reply

      The attentive reader might have noticed how the buffer- and play-time-bars in the first and second screenshot have different colors.

      Themes can style these elements of the players. The first example is a screenshot from Twenty Thirteen, with a white buffer bar, an orange play time bar and no border-radius.

    • John Saddington 11:11 pm on April 8, 2013 Permalink | Log in to Reply

      this is fantastic. john dyer’s MEJS is amazing.

    • AK Ted 11:32 pm on April 8, 2013 Permalink | Log in to Reply

      This is great news! Can’t wait for stable to play with, no time atm for beta. :(

      Small grammar correction: “ability to easily and beautifully expresses themselves” (in first paragraph), should be “express”.

    • Michael Beckwith 11:51 pm on April 8, 2013 Permalink | Log in to Reply

      That’s pretty hot

    • Ipstenu (Mika Epstein) 1:07 am on April 9, 2013 Permalink | Log in to Reply

      What’s the fallback? Like if I use and they don’t allow for HTML5 (yes, I have people who don’t), what shows? Right now I made an html5video shortcode that has, at the bottom ‘Can’t see a video? Click here…’ and it defaults to the MP4.

      • Scott Taylor 2:47 am on April 9, 2013 Permalink | Log in to Reply

        I am pretty sure MP4 will win and play via Flash. If no flash and no HTML5, there will be a link that goes straight to the file.

    • Jon Brown 1:09 am on April 9, 2013 Permalink | Log in to Reply

      Not sure how I missed this on trac, but “YAY!!! & Oh No!!!!”.

      I just spent a month (not continuously) trying to figure out why MediaElements.js conflicted with Soliloquy (Flex based Slider) when both appeared on the same page on mobile. Only on mobile, everything worked fine everywhere else. I finally gave up, ditched ME.js for Video.js.

      I’m now about to test that site on 3.6 just out of curiosity as to what happens.

      I too really dislike this using shortcodes and my bigger concern is what this does to other plugins that use the shortcode already.

      Always seemed to me WP ought to follow best naming practices and use [wp_gallery], [wp_video], etc…

      • Jon Brown 1:26 am on April 9, 2013 Permalink | Log in to Reply

        That was easy to test… still conflicting somehow. I’ve let Thomas know with urls to dev/staging/live servers showing it all. It’s really bizzare that it only happens on mobile browsers (iOS chrome and safari) anbd throws no errors. Either works fine on it’s own, and we’ve recreated it on vanila WP running 2010.

    • Beau Lebens 1:42 am on April 9, 2013 Permalink | Log in to Reply

      <3

    • Tomas 4:01 am on April 9, 2013 Permalink | Log in to Reply

      WoW! This is good news!

    • Robert Chapin (miqrogroove) 1:48 pm on April 9, 2013 Permalink | Log in to Reply

      That’s hot! :D

    • redwallhp 10:35 pm on April 9, 2013 Permalink | Log in to Reply

      Awesome! The assimilation of the Crowd Favorite post format UI and MediaElement.js support in one version.

    • Frank 10:46 am on April 10, 2013 Permalink | Log in to Reply

      Yeah, this is cool. And I miss some important points to have this as a useable feature for real blogger’s life: mejs is out of the box not resonsible and this allone makes the joy half at the first glance. Yes, there is a dev’s tip for videos out there, that, if you set the width to “100%” it will work. And it does, indeed! Maybe this width issue of mejs videos should go into core?

      Responsive mejs audio seems to be more complicated. A simple width attribute setting does not work. At this time the width of the audio bar overlaps the standard width of 480 even in modern smartphones.

      Regarding video: the poster attribute of the shortcode is rather important, since it leeds to a screenshot like above, showing this nice preview picture for the video – but it’s not as easy to implement as it looks like. If you take an image from the media library with its predefinded sizes, it is to small or you’ll have an overlapping picture. For me setting the CSS class “mejs-container” to “overflow: hidden;” seems to resolve the issue as a quick hack.

      I think, the feature of having core supported video and audio is great, and it should be delivered in a way, that avoids frustration of users. The poster feature for videos is essential I think, the contra responsive issues should disappear as well.

      Keep up the good work!

    • Eric Andrew Lewis 11:18 am on April 10, 2013 Permalink | Log in to Reply

      Totally wow.

    • hearvox 12:22 am on April 11, 2013 Permalink | Log in to Reply

      any hooks yet for skinning the default MEjs player?

    • rilwis 2:22 pm on April 11, 2013 Permalink | Log in to Reply

      This feature is really great and useful for all people. I’ve been using MEjs and it’s really great. Nice UI, great support.

    • johndyer 10:48 pm on April 11, 2013 Permalink | Log in to Reply

      So glad to hear it! Glad to have “contributed” :)

    • Maor Chasen 6:15 pm on April 12, 2013 Permalink | Log in to Reply

      Love!

    • Anderton 9:06 am on April 15, 2013 Permalink | Log in to Reply

      Have been playing around with it while developing a couple of themes for 3.6. It’s lovely, and easy to style. Have been using MediaElements,js before, and when i found out that it would be included in the Core, i was thrilled. Good move!

    • Bjarni Wark 10:25 pm on April 16, 2013 Permalink | Log in to Reply

      Really good news, thanks for the efforts of making this happen.

    • Maeve Lander 4:58 am on April 17, 2013 Permalink | Log in to Reply

      Just wondering how will this affect existing audio/video plugins? Any potential problems, conflicts, things plugin developers could do better to integrate with this etc?

    • esmi 7:49 pm on April 17, 2013 Permalink | Log in to Reply

      I have to say, I’m really disappointed that there’s no mechanism for people to add captions for videos or provide text transcripts with audio files. come on, people! We need to be encouraging people to do this kind of stuff but unless WordPress provides the methods, it just won’t happen.

      • Scott Taylor 7:57 pm on April 17, 2013 Permalink | Log in to Reply

        #patcheswelcome

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

        Speaking as someone totally ignorant of this, how DO you add captions to videos? Can I include a transcript.txt file like I do for different video versions?

        • Joe Dolson 11:26 pm on April 17, 2013 Permalink | Log in to Reply

          There are various formats for captions, but yes, essentially it amounts to referencing a text file with captions. Mediaelement.js supports .srt and .vtt caption formats, and they’re referenced as

          In this context, you should treat the terms ‘subtitles’ and ‘captions’ synonymously, although technically they are different.

          All the WP system needs to do for captions is provide a mechanism to upload them and auto-generate the relevant track elements, basically.

    • esmi 8:11 pm on April 17, 2013 Permalink | Log in to Reply

      We’ve only just picked this up in the make.wordpress.accessible group but, yes, we will be trying to come up with some patches if we can :)

    • FranciscoAMK 8:19 pm on April 21, 2013 Permalink | Log in to Reply

      Is the featured image set as the “poster” for the video post format?

  • Helen Hou-Sandi 7:49 am on March 15, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 3/14 

    As noted in The Road to 3.6 Beta 1, we’ve got quite a bit going on for post formats. Many of the tickets are in need of testing (including unit tests) and then a commit. As always, there are a few different fronts: UI/administration, data, and parsing. Here’s where we are with each, and what needs to get done. There’s a large variety of tasks here, and we are seeking contributors to help :)

    (More …)

     

    • Luke Gedeon 3:32 pm on March 15, 2013 Permalink | Log in to Reply

      “Add New Post: Status” in the refreshed layout wireframes shows permalink above status field (Hey User, what’s up?) and has no title. As a user, having the status field above permalink feels more natural.

      As a dev, I wonder if we could use the Title field to capture the status instead of a custom field. This would allow normal processing to generate the permalink and put the order of fields into something closer to what a user might expect.

      When generating output for a status it “might” be preferable to hide the title even in themes that don’t recognize post formats. If that is case, core could return an empty title and the status stored in title as content. My preference would be to receive the status as a title anyway, since that would look best in most themes I have looked at.

      • Helen Hou-Sandi 7:13 pm on March 18, 2013 Permalink | Log in to Reply

        Status is not a custom field – it’s post_content. I don’t think we’re going to be able to get so adventurous with the status format edit screen layout – it’s quite likely that it’s going to just look the same as aside – title optional (toggle or otherwise), regular editor area. I also don’t think core should just turn titles off in a theme – that’s completely up to the theme to decide. A theme may very well use the_content in a way that looks like a title – 100% presentation layer, not data.

    • Dravel 5:27 pm on March 15, 2013 Permalink | Log in to Reply

      As a regular “John Doe” user of WordPress I must say that the plan of ditching the tabs in favor for the drop down thingy from @lessbloat is a major disappointment. The tabs were a new fresh style (needed one to) to a stale design part of post area itself.

      Reverting to a style that best described as 1995-ish when we are in fact roaming in the year 2013 is a huge step back, not to speak of the user unfriendliness the current iteration presents (http://make.wordpress.org/core/2013/02/22/post-formats-ui-update-221/#comment-8182), that little blob before the “Enter title here” does in no way even hint that there’s option’s lurking there. As a blogger I want it easy and straight forward, not guessing around before I can actually start to write my things.

      The tabs were ok and had a fresh thing to it, shoot even a vertical row of the icon’s made by @melchoyce with a sub title “Post Format” as a <h2> heading right under the “Enter title here” is way better than a obscure drop down thing, especially from a user friendly point of view.

      Just 0.2 cent from a regular John Doe user

      • Helen Hou-Sandi 7:18 pm on March 18, 2013 Permalink | Log in to Reply

        There are a lot of problems with the tabs interaction-wise. They are not adaptive to screen widths, especially smaller ones, incorrectly represent selecting a format as a primary action when in reality it is one that is performed once and then left alone, and they cause confusion among users, both “regular” and ones we tend to think of as knowing better (like the very people writing patches). Some users interpret the tabs as needing to fill out all of them rather than making a generally-one-time choice that sticks, and yet others saw ones like “Audio” and “Video” as being points for inserting media into their content. We have a lot of exploration to do, but tabs are definitely not it. Again, I regret having put them in even as temporary UI – the distraction caused has been a bit time-consuming to respond to.

      • jltallon 1:00 pm on March 20, 2013 Permalink | Log in to Reply

        From another “John Doe” user (+developer +project manager):
        @lessbloat‘s proposal at the URL below is right on: discoverable, intuitive, unintrusive, practical… good.

        Though I’m a bit wary of content parsing, I trust you to get it right, and the “teeny” mode will be of much help in guiding the users along the right way (input the “correct” content). Less meta is good for performance, too.

        0.02€ from me :)

    • Hugh 9:25 pm on March 15, 2013 Permalink | Log in to Reply

      I’m a lurker, but can someone point me to a post or discussion on the history of post formats? I am curious to know why the post formats for audio and video are not separate content types. – I’m sure there is some good thought behind this but being newish I’d just like to read why it is the way it is.

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

        I suppose the Codex has some information about what post formats are: http://codex.wordpress.org/Post_Formats, notably “A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post.”. Separate content types (post types) would not show up in a blog archive by default and are not posts, whereas these are supposed to be posts that just happen to contain audio or video (or quote, image, gallery, chat transcript, or link). Think of post formats as a way for users to structure/think about the content of their blog posts and as a way for theme devs to be able to customize the presentation layer of a given format.

    • WraithKenny 8:38 pm on March 18, 2013 Permalink | Log in to Reply

      “…what it means to re-initialize TinyMCE…” Is there a ticket or comment on which scenario would require TinyMCE to be reset?

    • Scott Taylor 10:22 pm on March 18, 2013 Permalink | Log in to Reply

      I am on a plane home from my Mexication – I am going to refresh my patches tonight, based on the fact that #23282 finally landed (editors note: woo hoo!). The patch on #23282 had some new functions (`has_shortcode()`, `shortcode_exists()`, `get_tag_regex()`, et al) that were present in ~5 different patches. Will also streamline any dupe’d code elsewhere among the patches that haven’t been committed. That being said , #23673 should be the next one to go in.

  • Helen Hou-Sandi 8:56 pm on February 22, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 2/21 

    First run commit, mostly for soaking of functionality, went into trunk on Monday. This includes fallback output for theme compat and fields in the admin. The admin UI does not represent anything final – especially of note is the tabs, which are essentially the way they are in order to reuse CSS and avoid adding temporary code to core.

    (More …)

     

    • Beau Lebens 10:59 pm on February 22, 2013 Permalink | Log in to Reply

      Also of interest is #23282, which adds audio and video players to core to handle those post formats (and optionally be used anywhere else).

      • Helen Hou-Sandi 12:53 am on February 23, 2013 Permalink | Log in to Reply

        Good call, I keep forgetting to loop back to that.

      • Harish Chouhan 7:30 pm on February 23, 2013 Permalink | Log in to Reply

        Is it final that mediaelement would be used?

      • Anointed 2:50 am on March 7, 2013 Permalink | Log in to Reply

        I’m hoping that other systems other than medialementjs will be considered. Another ‘top” Option is definitely mwEmbed by Kaltura https://github.com/kaltura/mwEmbed

        • Helen Hou-Sandi 2:52 am on March 7, 2013 Permalink | Log in to Reply

          Licensing?

          • Anointed 3:02 am on March 7, 2013 Permalink | Log in to Reply

            All mwEmbed code is released under the AGPLv3 unless a different license for a particular library is specified in the applicable library path

            *I’m sure it could be adjusted if necessary

          • Anointed 3:05 am on March 7, 2013 Permalink | Log in to Reply

            Also, spend a few mins on the git site. Check the level of work put into this project over the years as one of the top active code sets on git. Then do a little digging into who kaltura is, (if you have watched a movie on an airplaine in the last few years, then odds are, it was built by kaltura). Bottom line, kaltura is one huge beast that would benefit both WP and Kaltura.

    • Harish Chouhan 6:54 pm on February 23, 2013 Permalink | Log in to Reply

      Just a question,
      For the meta field Image, will only attachment ID work, or if in a theme we are saving URL of the image in the “_wp_format_image” field, once WP 3.6 is released, will it work?

      • Helen Hou-Sandi 6:58 pm on February 23, 2013 Permalink | Log in to Reply

        A URL will work – the media modal just hasn’t had that panel added yet.

        • Harish Chouhan 2:07 pm on February 26, 2013 Permalink | Log in to Reply

          @helen,
          Currently the URL field for formats such as Link, Image & Quote is saved as _wp_format_url. Is this approach final? Or there is still chance of this being changed?

          • Helen Hou-Sandi 3:02 pm on February 26, 2013 Permalink | Log in to Reply

            It shouldn’t really matter to you if the meta key name changes or not – we’ve already introduced get_post_format_meta() as a helper retrieval function. It might be helpful if you could explain why you are asking these questions.

            • Harish Chouhan 6:16 pm on February 26, 2013 Permalink

              Hi Helen, since a year or more I have been using CF-Post-Format plugin which has different URL meta fields for Link & Quote format. I run a WordPress network and to avoid changes to my new themes in future, I am trying to follow the meta_key name based on WordPress 3.6. This will ensure I just have to remove the plugin when 3.6 is released.

              I also wanted to make a suggestion about Gallery meta box. Can you please let me know the best place to make that suggestion?

            • Helen Hou-Sandi 6:22 pm on February 26, 2013 Permalink

              We’re in active development – I would not change anything you are currently doing yet. You can make your suggestion here or on #19570.

    • rudwolf 3:41 am on February 25, 2013 Permalink | Log in to Reply

      Is there any planning to make filter and action hooks so we could be able to create our own new types of posts?

    • Lance Willett 6:00 am on February 26, 2013 Permalink | Log in to Reply

      I added a bunch of related tickets to for the default themes:

      Twenty Ten: gallery post format – #23617
      Twenty Eleven: gallery post format – #22907
      Twenty Eleven: link post format – #23618
      Twenty Thirteen: link post format – #23619
      Twenty Thirteen: video and image post formats – #23620
      Twenty Thirteen: gallery post format – #23621

      Seems like only Twenty Thirteen will need add_theme_support( 'structured-post-formats' ); at this time.

    • lessbloat 6:35 pm on March 4, 2013 Permalink | Log in to Reply

      Played with another design for the post formats selector this morning.

      Have a look:

      On load
      Active
      Formats without a title

      I figured it would be fairly discoverable, much less in your face than tabs, and work well for accessibility.

      Thoughts?

      • Seth Rubenstein 8:54 pm on March 6, 2013 Permalink | Log in to Reply

        I’m a fan. Agreed, much less in your face than tabs. Discoverable but out of the way.

      • mattyrob 8:57 pm on March 8, 2013 Permalink | Log in to Reply

        +1 from me for the cleaner interface. The tabs take way too much screen space and will surely just irritate bloggers who don’t use this aspect of WordPress.

    • Drew Jaynes (DrewAPicture) 6:49 pm on March 5, 2013 Permalink | Log in to Reply

      I really like this a lot. It fits with the existing UI much more seamlessly and it’s discoverable enough while not completely taking over the post editor like the tabs.

  • Helen Hou-Sandi 3:51 am on February 5, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 2/4 

    Not a whole lot to discuss today – working away at patches on #19570 (edit form UI) and #23347 (theme compat). Could use a patch on #15490 (retrieval of oEmbed data and previewing, which I suspect will become relevant to the edit form UI) and testing of #23282 (audio/video shortcode and player) and #16047 (list table column).

     

  • Helen Hou-Sandi 5:32 am on February 1, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 1/31 

    Had really good conversations in Wednesday’s dev chat and continued in today’s office hours. Seems like we’ve got a really good direction. All the UI will be available all the time and theme support for individual formats will shift to serving as a flag for whether or not the theme handles format-specific data for display. If a format is not explicitly supported by the theme, there should be simple, semantic fallback output that can be hooked on to the_content. This allows the admin UI to stay consistent and able to offer data fields that don’t just disappear into nothingness, and themes can actually support post formats with just styling rather than handling format-specific data themselves.

    @beaulebens is working on the fallback output on #23347, and @sabreuse is joining @rachelbaker to work on the edit form and switcher on #19570. @melchoyce has updated wireframes she’ll be linking to in a comment here. TBD: no-JS treatment, will also need to be keeping an eye on accessibility.

    Also, user testing was done with core as-is, and I’ve got videos to watch and analyze for post formats using Crowd Favorite’s UI and fallback code. These are extremely revealing and are really helping us identify pain points as well as setting a baseline for measuring any improvements we hope to make.

     

    • Erlend Sogge Heggen 7:44 am on February 1, 2013 Permalink | Log in to Reply

      Will the post formats update include any work towards making post formats more usable via the front-end? I really love the idea of bbPress being able to use post formats to distinguish between normal posts and support posts for instance, as well as its own take on link posts and so forth.

      • Beau Lebens 2:14 pm on February 1, 2013 Permalink | Log in to Reply

        The list of core-supported post formats will be (currently):

        • Standard
        • Status
        • Quote
        • Aside
        • Link
        • Chat
        • Image
        • Video
        • Audio
        • Gallery

        There are no plans to allow plugins/themes to modify that list

        • Erlend Sogge Heggen 5:02 am on February 4, 2013 Permalink | Log in to Reply

          So I suppose that means we won’t be able to easily create a post format like, say, “Forum Link” to mimic the Facebook style link posts with autoembedding? Too bad, I was really excited about the possibilities there.

          • Helen Hou-Sandi 9:35 am on February 4, 2013 Permalink | Log in to Reply

            Post formats already exists as an enumerated list and that will not be changing. In your cited example, not sure why a “Link” format post wouldn’t work.

    • Mel Choyce 12:21 pm on February 1, 2013 Permalink | Log in to Reply

      Updated wireframes: http://cl.ly/0p260s3U0L3p

    • Justin Tadlock 12:33 am on February 2, 2013 Permalink | Log in to Reply

      As a user, I hope there’ll be an easy way (via plugin if need be) to continue using things like post titles for “asides” since this is the way I’ve been doing them for the past 6+ years. Some people use titles and some people don’t. Personally, I like to have the title shown on the singular view.

      As a theme developer, I just want to ask that we make it easy to open any hidden fields back up without having to jump through hoops to do it, especially for those of us who have been using those fields in our themes. A simple filter hook or something like that would do it.

      • Helen Hou-Sandi 12:54 am on February 2, 2013 Permalink | Log in to Reply

        One of the things I’ve been thinking about suggesting (hadn’t gotten there yet) was that title always be editable, even if for some formats it’s more buried.

        Can you elaborate on what you mean by hidden fields?

        • Justin Tadlock 5:58 am on February 2, 2013 Permalink | Log in to Reply

          Any hidden fields that represent normal post_fieldname data such as the title field. I’m not sure if there are any others, but the title is the biggie.

          I definitely agree that the title should always be editable, especially because it’s the <title> element on a page and is what’s used to populate the permalink field. I like the wireframe of the chat format where it says “Chat Title (optional)”. I think that’d be a good use for the aside and status formats too.

    • Synapticism 10:57 pm on February 2, 2013 Permalink | Log in to Reply

      I was mucking about with the quote post format on my personal blog and ended up writing some thoughts about usage that may be of interest to the team. Here are the links:

      http://synapticism.com/working-with-wordpress-post-formats-and-quotations/
      http://synapticism.com/marking-up-quotations-with-html5/

      My main point: adding a third field, “source title”, to the quote post format will encourage HTML5 best practices.

      I’m no expert in these things so there might be something really terrible about this idea that I wouldn’t have thought of :)

  • Helen Hou-Sandi 3:10 am on January 30, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 1/28 

    @lessbloat has started new rounds of user testing – one with core as-is, and one using the Crowd Favorite code and San Kloud for the theme so that all formats are enabled. Will be reviewing and posting those when they come in.

    We’re going to go ahead and get patching so we can test and iterate, and still looking for somebody interested in creating icons. @rachelbaker will be working on the form itself and switching. Would love a volunteer or two on data retrieval and theme usage functions, but will likely be looking at that myself in the next couple of days.

    Office hour log

     

  • Helen Hou-Sandi 12:20 am on January 27, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 1/24 

    Apologies for the late update – helps if you actually publish the post! :) We were in #wordpress-ui due to a little scheduling conflict – we’ll hopefully be back in #wordpress-dev next week, and are sorry for any confusion.

    Discussion point 1: format switcher, with an example from @lessbloat: http://f.cl.ly/items/1t09071U2v1E2x2s3X2i/post-formats.png (we would use “Standard” as opposed to “Text” for that label). We will not be blocking the current behavior/ability to just start writing a post when you enter the add new screen, i.e. no forced selection of a post format before you can start writing. There is some concern about user confusion in that one might think that you can/should specify data for multiple formats in a single post if the switcher is always viewable. A viable idea seems to be that all formats are shown when you load the add new post page, which then collapse into one item (the selected one) upon a specific selection. Editing an existing post, including drafts, will only show the one format selected. Clicking on the selected format would allow for switching of the format via a to-be-determined interaction. There’s also the idea that a screen option would be provided to turn off the switcher entirely should the user so desire, just as the “Format” metabox can be turned off now.

    Action: Call for icons, one per post format. No dimensions determined yet; keep in mind that 2x versions will be needed.

    Discussion point 2: data structure needs, based on this really great start on wireframes by @melchoyce: http://make.wordpress.org/core/2013/01/22/post-formats-ui-update-121/#comment-7674. Proposed:

    • Media URL/embed code/shortcode (basically, text), to be shared between audio and video
    • Link URL, to be shared between link and image
    • Quote content
    • Quote source
    • Gallery, which would be a shortcode that likely needs to default to [gallery] for backcompat; would use shortcode with list of IDs for new style
    • Image, which could be an attachment ID or URL (this is separate from featured image)

    Sharing data fields (storage TBD, likely post meta) would mean that switching between formats that are similar in data needs would retain that field. Action: discuss proposed data structure in comments; pros/cons of sharing fields between formats, anything missed, etc. Also discuss anything related to the wireframes; @melchoyce was working on some discussed tweaks (although she may be understandably behind due to computer theft :( ), and there will likely be more that we’ll want to do.

    Finally, as a tightly-related item, @wonderboymusic started work on the possibility of an HTML5 audio/video player in core: #23282. Testing and feedback more than welcome.

    Full chat log

     

    • Marcus 3:24 pm on January 27, 2013 Permalink | Log in to Reply

      imo shared data fields (and preferably stored in post meta!) is definitely the way to go whenever possible

      easiest example… urls:

      videos, audios, links and more formats have a url field. Much less work to grab a url and distinguish between what post format you’re dealing with rather than figuring out the post format and finding the particular post meta field to look up (assuming we’re hopefully dealing with post meta)

    • Daniel Bachhuber 5:32 pm on January 27, 2013 Permalink | Log in to Reply

      Any talk of doing user testing with Crowd Favorite’s existing code?

      • Helen Hou-Sandi 6:50 pm on January 28, 2013 Permalink | Log in to Reply

        Yep, I’ve asked @lessbloat to do a new round of user testing with the current interface (consisting of the radio button selection) and Crowd Favorite’s code, using a theme with all the post formats enabled. Going to test a subset, because 10 formats is time consuming.

    • Mike Schinkel 5:29 am on January 28, 2013 Permalink | Log in to Reply

      Hi @Helen, Mockups look great. Curious though, where is URL slug field?

    • Peter Westwood 4:58 pm on January 28, 2013 Permalink | Log in to Reply

      We were in #wordpress-ui due to a little scheduling conflict – we’ll hopefully be back in #wordpress-dev next week, and are sorry for any confusion.

      Sorry about that, my fault – we have moved our Thursday slot an hour earlier so it won’t happen again!

    • Antonio 6:40 pm on January 29, 2013 Permalink | Log in to Reply

      Talking about data structures, it is worth considering Scott Clark’s Pods plugin, an interesting example of how to build custom data structures starting from simple fields. Ok, ok, we’re talking about post formats and not post types, but when you decide to reserve certain fields to certain post formats (and, from my point of view, this is the question) maybe we’re talking about not only post formats but post types too. An idea could be to build a framework that permits the assembling of post formats starting from smaller chunks, as Pods does with content type. What do you think about it?

      • Helen Hou-Sandi 9:46 pm on January 29, 2013 Permalink | Log in to Reply

        I don’t follow, although maybe somebody else does. These seem like simple post meta to me.

      • Scott Kingsley Clark 9:53 pm on January 29, 2013 Permalink | Log in to Reply

        I think I understand what you mean, all I know is that as the developer of a plugin like Pods, I want to be able to hook into post formats, at least on the meta-box level to extend them. That’s a reply to the comment, this may or may not apply to the actual discussion at this stage.

  • Helen Hou-Sandi 4:26 am on January 22, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 1/21 

    Still looking for wireframes/storyboards for possible UI ideas for each post format. To put it succinctly, we are looking to address discoverability, value, and usability, approximately in that order. We will at some point need to talk about how users get there in the first place, but again, for now let’s focus on the add/edit post screen. We briefly touched on what would happen to the UI if the theme doesn’t support the post format – there seems to be early consensus that the UI itself stay altered (e.g. if there were a separate input for a link URL) but there would be a warning of some sort about the lack of theme support.

    A large portion of our office hour today was spent discussing a script for user testing that we can use throughout this process to help us evaluate the changes proposed. We need to use a theme that includes all ten formats, doesn’t do anything to the admin UI, and preferably does something to the front end display for each. One that I know of is San Kloud, although it has some deprecated function usage (hey @kovshenin – want to fix that? :) ); other suggestions welcome.

    Since the first part of the issue here is discoverability, the script needs to not hand-hold the format selection or entry process. Here’s a rough outline of what it might look like – discuss any changes in the comments, and @lessbloat will help us get testing. Some of these are particularly difficult to describe in a non-leading manner. Through each of these, it would be good to have the user narrate what they want or expect will happen for each of these formats. A little fuzzy since we’re not going to point them at the format picker and a given tester may not be used to blogging, but the more narration of thinking/expectations, the better.

    • Standard/text: Add a blog post entitled X, with the following text. Publish and view the post.
    • Aside: Add a brief blog post without a title, or what might be referred to as an “aside”. Publish and view.
    • Status: Add a blog post that represents your current status as (provide text), the way you might on a site like Facebook or Twitter. Publish and view.
    • Chat: Add a chat blog post where the content is a chat transcript (provide something to copy-paste). Publish and view.
    • Quote: Add a quote blog post with X quote attributed to Y. Publish and view.
    • Link: Add a link blog post with X text linking to [URL]. Publish and view.
    • Image: Add an image blog post and insert X image into the content editor. Publish and view.
    • Gallery: Add an image gallery blog post with X images (this probably needs step-by-step instructions for creating a gallery). Publish and view.
    • Video: Add a video blog post with [something from YouTube]. Paste the URL on its own line without linking it. Publish and view.
    • Audio: Add an audio blog post with [something from SoundCloud]. Paste the URL on its own line without linking it. Publish and view.
    • View your site. (If they chose formats, it should show the differences pretty clearly in a post archive view, hence the importance of choosing an appropriate theme.)

    Full IRC chat log

     

    • Konstantin Kovshenin 5:54 am on January 22, 2013 Permalink | Log in to Reply

      Hey @kovshenin – want to fix that?

      Sure!

    • F J Kaiser 7:35 am on January 22, 2013 Permalink | Log in to Reply

      Status: Add a blog post that represents your current status as (provide text), the way you might on a site like Facebook or Twitter.

      The most difficult/unclear are imho Aside and Status. In my imagination, the difference between them would be two things: The profile image of the author and “time since published” as post date. Just my 2cents

      • Helen Hou-Sandi 2:48 pm on January 22, 2013 Permalink | Log in to Reply

        I think many of us would agree about “Aside” and “Status” being less clear-cut. I think in the end it’s still up to the theme as to how it’s displayed on the front, and I imagine that in terms of the admin they’ll probably have the same UI because there isn’t anything really different about what type of data they need/represent. However, for user testing, we need to represent some sort of difference and see if they spring for choosing a post format.

        • ipears 4:56 pm on January 22, 2013 Permalink | Log in to Reply

          In an early version of @kovshenin’s Publish theme (on github), the status used to be a status on another platform… showing a tweet for instance. This is something that still is interesting from a point of view in which referencing and/or cross-posting weighs in.

          Perhaps status should be linked to a (geo-)location or mood, whereas an aside gives more flexibility on the contents, just with less emphasis as full-blown article.

          (side-note: for all afore-mentioned post-types, it would come in handy when the Press-This bookmarklet would be more content aware and sensitive, saving much time editing.)

    • lessbloat 6:49 pm on January 22, 2013 Permalink | Log in to Reply

      Well… here’s one (fairly obvious) option:

      • sara cannon 11:36 pm on January 22, 2013 Permalink | Log in to Reply

        I know this is a bit out of the box, but I the the post format option should be chosen before going to the post screen. tabs and icons in the post screen will make a user think that they can toggle between the types easily and possibly even include multiple types in one post. why not choose before you even get here?

        • Beau Lebens 7:40 pm on January 23, 2013 Permalink | Log in to Reply

          For format-heavy sites, I agree that this workflow makes sense. Unfortunately for folks who’s site doesn’t make use of them (even if registered by the theme), this introduces a pretty horrible, extra barrier to publishing.

          I like the idea of an additional drop-down from the Posts > Add New menu, that’s a nice shortcut (although it’s a model not used anywhere else in the menu).

          I think whatever we need to do, needs to handle/prevent users from trying to switch between formats (once they’ve entered something in one specific format). I guess we could have an “Are you sure?”, like when you leave the post editor with unsaved content.

          • Helen Hou-Sandi 9:17 pm on January 23, 2013 Permalink | Log in to Reply

            Why do they need to be prevented from switching formats?

          • sara cannon 5:05 am on January 24, 2013 Permalink | Log in to Reply

            @beaulebens I can see how this can be a huge hurdle to people who dont want formats. I guess the question is: do we want to commit to this concept in a big way or have it be a subtle option? I feel that committing to formats and optimizing the workflow in that area is a good idea.

            If we do use a more aggressive workflow like above, we should have an option for a user who dose not want formats (even though their theme enables them, and no matter if you switch themes) to turn them off in core.

            If we’re not completely all-in with this concept, then I understand why we would want it to be more subtle, non-intrusive of a workflow. (“dont make me choose what format before I post, I just want to post” kind of thing)

          • Andy Peatling 11:46 pm on January 24, 2013 Permalink | Log in to Reply

            I agree with Beau about handing format switching.

            Originally on WordPress.com it was simple to switch between post formats while writing a post. The issue we found with this is that users would get confused between uploading a photo and the actual photo post format. They’d go to upload a photo to their standard post, switch formats to the photo format, upload, and then publish. They’d then lose the post content they had written on the previously selected format.

            We fixed this issue by first asking them to select a post format, but that’s tougher to change in core for reasons you’ve mentioned, it puts a decision in the way of posting that didn’t exist before.

            We also now tell them that they will lose their existing post content if they decide to select a different post format (if it hasn’t been saved as a draft). This helped a whole bunch, it dropped the number of tickets for this issue to near zero.

            • Isaac Keyet 3:42 pm on January 27, 2013 Permalink

              …it puts a decision in the way of posting that didn’t exist before.

              The decision has already been made. I don’t think many users just go to the post screen to just see what comes out of typing randomly for a while.

              Even if a decision has not been made when you go to post, don’t you want to know that you can post different types of posts? We’re not committing to the idea by having post formats if it’s not front and center.

              The sidebar menu should have “Add New” items for each of the post formats along with a full post editor.

              • Posts

                • All Posts
                • New Post
                • New Picture
                • New Gallery
                • New Status
                • New Quote

              This is also the direction that the vast majority of personal publishing platforms has taken on mobile, and one that we’re dabbling with too. In fact, these items don’t even belong in a “Posts” menu group since that makes them less action-centric.

              Just my thought on the subject.

            • Andy Peatling 4:51 pm on January 27, 2013 Permalink

              The decision to post has been made, yes, but the decision of which format to use has not. It might be tough to sell asking users to make that extra decision every time when they never had to before. As we have found on dot com the vast majority of users are still going to use the standard format.

            • Isaac Keyet 1:52 am on February 1, 2013 Permalink

              @apeatling: even if they haven’t made the decision the ability to just start a regular post from scratch would still be there. That’s not changing.

        • Helen Hou-Sandi 9:16 pm on January 23, 2013 Permalink | Log in to Reply

          That is definitely a part of what we need to consider outside of the context of the add/edit screen. @beaulebens is also correct – we must not block the way current workflows are for just plain posting without formats, only provide a different point of entry that includes pre-selecting a format.

          • ipears 2:43 pm on January 24, 2013 Permalink | Log in to Reply

            Without wanting to refer too much to tumblr, the “Press This” bookmarklet could be of importance for this: content awareness could suggest or decide the format.

            That same content awareness could transmogrify (yes, I like C&H) your post(-format) while editing, as you add certain media/content.

            • Helen Hou-Sandi 3:33 pm on January 24, 2013 Permalink

              There’s a slightly-separate initiative to improve Press This as a whole, and we will definitely at least keep parity with whatever we do to post formats in the regular admin.

      • sara cannon 11:55 pm on January 22, 2013 Permalink | Log in to Reply

        I like icons but here is words for concept:

        list posts: http://s.sar.ac/image/0a203Q3E391e
        post edit customized to format: http://s.sar.ac/image/3n1i1I1O3n2V
        menu: http://s.sar.ac/image/052U1C0y1R0s

        • Helen Hou-Sandi 9:22 pm on January 23, 2013 Permalink | Log in to Reply

          For the list table, we’ve got #16047 for adding a column for the format, and #15323 for a filter, which should probably be a dropdown like the others, not extra tabs.

          For post editing, I don’t think we should be changing the title like that. It then gets completely mixed up with a custom post type, and isn’t necessarily accurate, either. It’s “just” opting in to a theme-driven special format for a regular old blog post.

      • Slobodan Manic 3:40 pm on January 24, 2013 Permalink | Log in to Reply

        Another obvious option, similar to this one would be to have a dropdown where “Add New post” is now:

        A pointer could be used to make sure users don’t miss it.

    • Edward Caissie 8:30 pm on January 22, 2013 Permalink | Log in to Reply

      I’m still not clear on this … is the intent to dictate what each and every Post-Format will be used for and look like? IF that is the case, then why not simply make them all part of core rather than at the Theme Author / End-User’s discretion on how they will be used and / or implemented.

      Don’t get me wrong, a better UX would be more than welcomed but deciding on that interface under the assumption a specific Post Format will *only* be used in a specific fashion is not a good place to start from when whether or not the Post-Format is available is left to the Theme Author’s discretion.

      • Helen Hou-Sandi 12:45 am on January 24, 2013 Permalink | Log in to Reply

        Post formats are meant to be standardized and portable across themes, hence the lock on which ones are available. As @nacin put so well in his post:

        The idea behind the feature is this standardization and portability for a segment of bloggers. Many designers of themes used for microblogging wanted this ability to offer structured, well-defined content, beyond what could be done with categories and tags.

        However, without anything actually standardized or structured in the admin, it’s ended up being completely up to the theme to determine both display AND data. Of course a theme will still be in control of the display, but given that formats are about standardization and portability, the feature itself is half-baked until we actually do something to the admin and corresponding data structure. As far as what’s available, I actually am not a huge fan of the whole opting in to a subset thing, but rest assured that a theme will continue to function like it does now if it doesn’t support a post format. After all, as it stands, a user could have created a post with a post format before switching to one that doesn’t support it, and nothing breaks.

    • Justin Tadlock 10:13 pm on January 22, 2013 Permalink | Log in to Reply

      I know it’s been mentioned before, but I have a PHP script for handling post formats on the front end:
      https://github.com/justintadlock/hybrid-core/blob/master/extensions/post-format-tools.php

      If you need to see it in use in an actual theme, here’s one I’m working on:
      https://github.com/justintadlock/chun/tree/0.1

      All of this is based off how my users at Theme Hybrid are using post formats. Most of it was developed over the course of the last year based on feedback and seeing how individual components worked in various projects.

      The biggest thing I’d welcome as a theme developer is some metadata saved for embeds in audio and video posts. I can pull embeds from posts with a regex (what I’m doing now), but there should be an easier method.

      • Helen Hou-Sandi 9:30 pm on January 23, 2013 Permalink | Log in to Reply

        Yep, your post format tools is on the list of examples for regex pulling of data. Thanks for the reminder :) What you’re saying about metadata is exactly why we’re working on this, although from the workflow/UI end first to really make it useful and valuable for users, which in turn will make it useful for theme authors.

        • Justin Tadlock 10:05 pm on January 25, 2013 Permalink | Log in to Reply

          Thanks for getting back to me on that. I just wanted y’all to be aware of how several theme companies are using post formats at the moment (it’s baked into my dev framework).

    • Mel Choyce 3:42 am on January 23, 2013 Permalink | Log in to Reply

      I actually agree with sara cannon and think users should chose a post format before being able to enter any content. I’ve thrown together some wireframes to show how that would work. I’ve leaned heavily on wp.com’s post format UI, but have organized formats by text vs. media:

      Add New Post: http://cl.ly/image/0N04382M2L1u

      **Text**
      Status: http://cl.ly/image/170O1N0L062U
      Quote: http://cl.ly/image/1V0h3O211K2T
      Chat: http://cl.ly/image/2T1X2I0f2R0z
      Aside: http://cl.ly/image/3v3T3b3L2s1o
      Link: http://cl.ly/image/2l213j3i2625

      **Media**
      Image: http://cl.ly/image/2X0S2u2f053c
      Gallery: http://cl.ly/image/032J3l2w1t10
      Video: http://cl.ly/image/3J2v2v0j0o37
      Audio: http://cl.ly/image/2y2x382v362Z

      All wireframes in pdf: http://cl.ly/3G2k2R01010q

      • Helen Hou-Sandi 12:50 am on January 24, 2013 Permalink | Log in to Reply

        I like this direction – will make a point to discuss these in tomorrow’s office hours. The one thing I want to avoid is blocking access to posting a regular post without specifically selecting the standard format. Would rather keep a switcher on this screen, and have a one-click point of entry elsewhere (e.g. Dashboard).

        • sara cannon 4:51 am on January 24, 2013 Permalink | Log in to Reply

          I kind of think “choose your format initially” will ease content switching confusion. because, If someone switches from audio to gallery after uploading their audio, wouldn’t their audio get dropped? I can see the case for not getting locked in.. but it seems like these formats are really specific that they are a very intentional choice. People who post to tumblr do this constantly.

          • Helen Hou-Sandi 1:49 pm on January 24, 2013 Permalink | Log in to Reply

            I agree that it would be good to have “choose your format” initially BUT I don’t think it should block the current way of directly going into creating a post, so in my eyes it should be a different point of entry, not an extra step on the add new screen.

            I don’t really know it means by “their audio would get dropped” – an upload would stay uploaded.

        • Slobodan Manic 3:51 pm on January 24, 2013 Permalink | Log in to Reply

          Also in the admin bar, New > Post > {List of supported formats} could be helpful.

      • sara cannon 4:40 am on January 24, 2013 Permalink | Log in to Reply

        agree! very tumblr esque :)

      • cramdesign 9:26 pm on January 28, 2013 Permalink | Log in to Reply

        I disagree, I do not think it is a good idea to force users to select a format before entering any content. Choosing a post format should determine what admin ui gets presented and what data the theme calls to format a particular way. All of the data gets saved as part of the post anyway.

        We should force the choice initially only if it is an absolute necessity, and I am not convinced that it is. If I start with an audio format and change to image format I would expect that the audio data no longer gets presented by the theme. No confusion. What harm would it be if a post has both image and audio meta after my change?

        Something I would like to throw into the mix however is for some way for theme developers to specify the default format for new posts. So if my theme focuses on galleries, that is the first ui that is displayed (or maybe only depending on my theme intent).

    • Scott Taylor 4:09 pm on January 23, 2013 Permalink | Log in to Reply

      I am starting to think that encouraging Audio and Video posting without a native way to play it is going to be super lame. *Yes I realize scope etc etc* But for instance: “Hey I’m posting Audio!” but what you’re really posting is a YouTube?

    • Helen Hou-Sandi 1:06 am on January 24, 2013 Permalink | Log in to Reply

      Idea: for gallery format, we could have the modal view go straight into creating a gallery. Selecting a bunch of images should create the gallery and close the modal rather than having a second “insert” step. Going back into the modal should go into adding images to the gallery. The preview of all images in that gallery would appear on the edit screen.

    • unsalkorkmaz 10:15 pm on January 26, 2013 Permalink | Log in to Reply

  • Helen Hou-Sandi 4:36 am on January 18, 2013 Permalink
    Tags: , post formats   

    Post Formats UI Update, 1/17 

    The post formats UI feature encompasses a couple things: the add/edit UI itself, and also what this means in terms of structured data and theme usage and expectations of data. Our goal is to make post formats meaningful and usable, because let’s face it: they’re not. What can we do in the admin to help a user understand what a given post format means and how it behaves in use, and what can we do to give themes something standardized and portable when it comes to data available for display?

    Had our first office hours chat today to get started – great discussion happening on a lot of fronts, especially theme compat. We identified two distinct tasks to get us through the weekend.

    The first, and most crucial piece, is thinking about/identifying what users are doing when creating a post using a post format and turning that into (likely annotated) wireframes/storyboards. That is to say – what sort of UI might we want want to see on the add/edit post screen? We’ll want to think about things like what makes it easy for a user to select a format, what a user might expect to see on the edit screen for a given format (no title, or the title is de-emphasized, or what images show in that gallery, etc.), and what happens when switching between formats. Some existing examples are CF Post Formats and WordPress.com. We also shouldn’t ignore what Tumblr does for its various formats. @alexkingorg gave us a demo link for CF and @beaulebens was kind enough to take some screenshots:

    Please post in a comment here with anything you come up with. Don’t worry about anything beyond the add/edit post screen for the moment. Also don’t worry about what data exactly is or is not represented – base your ideas on user workflows. The workflows and UI will heavily influence any structured data. There are also some other things to keep in the back of your mind as possible influences for anything core UI-related: how might a layout you’re imagining adapt to various screen sizes and devices, and are there pieces that can be used as the basis for more generalized core UI components.

    The second piece for now is functions (probably using regex, and I know) for pulling out relevant data for post formats as appropriate, e.g. the first URL in the content for the link format, oEmbed URL or appropriate HTML element for audio/video formats, etc. What might or might not be done with the data hasn’t been determined yet, but we can at least start here. Some existing examples are the twentyeleven_url_grabber() function and what they use on WordPress.com. Nobody has claimed this task. For now, go ahead and upload any patches to the main ticket, #19570.

    There are also some related existing tickets that could use testing/+1′s or patches:

    • #16047 – separate column for post format in the list table
    • #23198 – pass the post format as a class to TinyMCE
    • #15323 – list table filter by post format
    • #15514 – add to the cat-tag convertor plugin

    Read the full IRC log here.

     

    • Piet 6:52 am on January 18, 2013 Permalink | Log in to Reply

      Thinking out loud without having put too much thought in it, I think it would be user friendly that before a user starts writing a post, he/she can already choose the format.
      Upon choosing this format, the backend changes with the relevant fields. Sort of like different templates for the backend.
      Not sure though how feasible that would be.

    • Mang_ 7:44 am on January 18, 2013 Permalink | Log in to Reply

      I like a wp.com, also for continuity

      Paolo

    • Shea Bunge 7:56 am on January 18, 2013 Permalink | Log in to Reply

      I was working make a plugin a bit like this – very incomplete, but contains some regex and implementation. Most of the snippets are by @Justin Tadlock. https://github.com/bungeshea/post-formats

    • htrex 9:56 am on January 18, 2013 Permalink | Log in to Reply

      http://schema.org/docs/schemas.html
      Google,Yahoo and Bing converged on schema.org during 2011 and recently started to use it in serps displaying special snippets, that’s the effective beginning of a radical change named Web 3.0.
      Schema.org involves a radical change in how users produce content and requires structuring data far more than we do today, there are currently more than 400 standard entities and no space for interpretation: search engines expect “things” to be described in that way.
      To handle this WP backend UI needs to change and probably stop showing every custom post format at the root menu level, in the near future we may need to use post formats much more and evidently there’s no room for 400 first level menu slots.
      Schema.org entities allow inheritance with every entity as a child of “Thing”, and 8 basic direct childs:

      • Creative Work
      • Organizzation
      • Place
      • Intangible
      • Medical Entity
      • Event
      • Product
      • Person

      but there’s multiple inheritance level (eg: Thing > Organization > LocalBusiness > GovernmentOffice > PostOffice) where each subsequent child can add more fields…. in some types there are literally hundreds of fields, too much for us humans.
      How to handle all this stuff?
      The most promising idea and implementation seems to be http://decoupledcms.org/ http://bergie.iki.fi/blog/decoupling_content_management/

      • Helen Hou-Sandi 1:39 pm on January 18, 2013 Permalink | Log in to Reply

        You are talking about custom post (content) types, not post formats, and they can be submenu items rather than top level items.

    • Tom Lynch 3:07 pm on January 18, 2013 Permalink | Log in to Reply

      Just thought I would share my current solution for a network of blogs we run called GDNM.org…

      On image and video posts there is a URL box where you can enter a URL and when you tab out it will fetch the image or embed the video using oembed:

      https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:07.%20oembed.png

      The box sits just above the first post, as it’s for quick posting in the theme but either way it works well!

      No post format selected:
      https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:01.%20closed.png

      Blog post format:
      https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:02.%20blog.png

      Image post format:
      https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:03.%20image.png

      Video post format:
      https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:04.%20video.png

      Link post format:
      https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:05.%20link.png

      Quote post format:
      https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:06.%20quote.png

    • Mike Schinkel 5:58 pm on January 18, 2013 Permalink | Log in to Reply

      Hi @Helen, I’m not a UI person so don’t have any relevant comments there. However whatever get’s implemented it would be great if it can be controlled via hooks and/or if a class was introduced.

      As you know there’s a lack of flexibility for the plugin developer around the top of the post edit page and it would seem this type of UI change would require flexibility; I hope that flexibility can make it’s way into being addressable by plugin developers.

    • Manny Fleurmond 4:58 am on January 19, 2013 Permalink | Log in to Reply

      Just riffing for a bit: I hope people get what I’m trying to convey:

      So when I look at a post, I see the content data (the title and content), ie the meat and potatoes of a post and I see meta data/ taxonomies that add to the main data to categorize/tag/describe it. The content has is own area and meta data/ taxonomies/ etc are relegated to meta boxes. Looking at the different post format examples from other CMS’s, you are basically changing the type of content and therefore are changing the type of content fields you are using. Video posts may need a title and description, but they also need a video source url. An aside doesn’t even need a title. Post formats are just presets of custom content fields.

      In order to beef up post formats, I think we need to add hooks and an API that allows developers to change the content area of a post; to basically upgrade a few custom fields to content status. Not only should developers be able to add fields that are important enough to be content alongside the post title and post content fields, they should be able to replace those fields entirely, if they so wish. I have a side project where I disabled the title and content, to be replaced by a URL field and it always felt weird to me that I had to put that field in a meta box when it should have been considered the main content. A new post format UI would basically just be picking out a preset of fields that best fits the format of content. As Mike Schinkel suggested, flexibility is key as it would open some nice functionality for plugin developers as well as make WP a lot more robust.

      • Helen Hou-Sandi 5:24 am on January 19, 2013 Permalink | Log in to Reply

        The point is to create a core UI for the post formats, not leave it up to themes and plugins. Implementation details will come after a UI the supports good workflows is decided upon.

    • lessbloat 2:04 pm on January 19, 2013 Permalink | Log in to Reply

      I thought I’d run a couple users through some post format tasks to give us a baseline comparison for improvements/patches. Here are the videos from user 1 & user 2.

      User #1

      Step 1: Log in

      No issues.

      Step 2: Go to add post screen

      No issues.

      Step 3: Add text post

      No issues.

      Step 4: Add image post

      No issues.

      Step 5: Add video post

      4:34 – He tries to add the video URL through the media modal (Insert from URL screen), it inserts a link to the video instead of embedding it.
      6:55 – He finally gives up on trying to get the video to embed, “I’m assuming it just want’s me to insert this link”, he says as he moves on to the next task.

      Step 6: Add link post

      7:55 – since adding a link worked for the other two tasks, he actually used the media modal to add a link this time as well, and it worked. :-)

      Step 7: Add quote post

      9:07 – He clicked the “text” tab thinking that is where he would add the quote.

      Step 8: Preview site

      No issues.

      User #2

      Step 1: Log in

      No issues.

      Step 2: Go to add post screen

      No issues.

      Step 3: Add text post

      No issues.

      Step 4: Add image post

      4:10 – She wonders if she needs a title for the image she’s posting.

      Step 5: Add video post

      5:20 – She tried using the media modal (Insert from URL) as well.
      6:30 – She’s still searching for a way to add the video, “Not quite sure how to add the video”
      12:25 – She gives up and moves on to the next task, after making multiple attempts to embed the video.

      Step 6: Add link post

      No issues.

      Step 7: Add quote post

      14:55 – She selected the “quote” post format radio option wondering if something would happen.

      Step 8: Preview site

      No issues.

      Observations/Thoughts

      • In general, other than video embedding, everything seemed to go really smoothly.
      • I almost wonder… Could we get away with simply implementing video embedding in the media modal (on the Insert from URL screen) and calling it good? Just a thought.
      • Excited to see what comes out of this :-)

      • adamsilverstein 9:32 pm on January 19, 2013 Permalink | Log in to Reply

        love these user tests, great way to get real feedback. thanks!

      • Helen Hou-Sandi 1:49 am on January 20, 2013 Permalink | Log in to Reply

        It’s possible I missed a task (I was clicking through the videos a bit), but it doesn’t seem like they were directed to the actual post formats, not all of which are turned on in all themes. Maybe we can talk about an alternate task script to try.

        Definitely agree we could do something to pull in oEmbed data for a preview where it exists, though. Doing it in the media library also means a TinyMCE view and is probably a general thing, but what WordPress.com does is pretty neat.

        • lessbloat 1:15 pm on January 21, 2013 Permalink | Log in to Reply

          Let me know. I’m happy to run more users through with a modified script.

    • rachelbaker 1:17 am on January 21, 2013 Permalink | Log in to Reply

      My favorite example of an existing WordPress UI for adding a new “post format” post would be the P2 theme. Only the relevant fields are displayed for each post format.

      Screenshot: http://cl.ly/image/2p1H290d1T2B

      The status and link post formats only display a content textarea (no title).

      The quote format displays the content textarea and citation text input fields.

      The blog post format displays the standard title and content fields.

  • Helen Hou-Sandi 10:49 pm on January 16, 2013 Permalink
    Tags: post formats   

    Office Hours: Post Formats UI 

    We’ll be having our first feature team meeting in IRC tomorrow (Thursday, January 17) at 11AM Eastern/16:00 UTC. Please join us if you’re interested in participating in development of this feature, which does involve more than “just” UI, as we’re going to hit the ground running. We’ll keep that time every week, along with Mondays at 2PM Eastern/19:00 UTC. Updates will be posted here on Make/Core after each meeting. Pete Mall will be my backup lead.

     

    • Japh 11:14 pm on January 16, 2013 Permalink | Log in to Reply

      I’ll keep an eye out for the updates here and read the IRC logs, as 16:00 UTC is 03:00 my time, and 19:00 UTC is 06:00 my time.

← Older posts

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