WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 8:18 pm on November 5, 2013 Permalink  

    #22862: Consider a CSS preprocessor 

    In #22862, it was proposed that core move to using a CSS preprocessor. Given that we now have the appropriate tooling in place and MP6 has been greenlighted for preparation to merge into core, it is time we hash this out: which, if any, CSS preprocessor should we use, why that particular one, what does implementing it take, and what does the contribution process look like? Some of this discussion has already taken place on-ticket, which is great, including a ton of proof-of-concept patching by @wonderboymusic.

    For further reference, MP6 currently uses SCSS for its color schemes, with a branch that demonstrates what it would look like in LESS. Many thanks to @ryelle for maintaining the LESS branch. By no means does this dictate what happens in core itself, but it is certainly an influence and a great data point.

     
    • Helen Hou-Sandi 8:18 pm on November 5, 2013 Permalink | Log in to Reply

      Here’s my personal opinion:

      Current admin CSS is heavily ID-based, generally overqualified, and insanely clunky to maintain after having been merged into one giant sheet (see #18314). I see very little benefit in putting effort into truly converting wp-admin.css in its current state (sorry, @wonderboymusic), especially given back-compat concerns. What I do think we can benefit from is going back to separate, modular files, and taking advantage of a build process to concatenate them for actual use. Yes, I do know that a preprocessor can do that in a build process, too. :)

      I imagine a build process could do something like this:

      1. For the purposes of SCRIPT_DEBUG and people who start in browser inspector tools, concatenate all non-color admin CSS files into one large unminified wp-admin.css, with comments added that denote where the development files are located and where each section starts to help with patching. If there’s a standard that web inspectors use or are beginning to adopt (e.g. source maps), we should take advantage of that.
      2. For production usage, minify the concatenated version, as it does now.
      3. Basically, the current wp-admin.css and wp-admin.min.css would still exist and essentially be as they are now, but patches would be against smaller, easier to digest files. This does raise the barrier to contributing actual patch files, but I think we should be open to helping people create patches out of notes from something like a web inspector (which does occasionally happen now, too, for what it’s worth).

        Bonus: we could also take advantage of an awesome tool like Autoprefixer (https://github.com/ai/autoprefixer) to automate that part of the CSS development process, rather than adding and removing vendor prefixes manually, and still missing them sometimes. Again, yes, I know preprocessors can do this with mixins (which have to be written/maintained) or libraries like Compass.

        Color schemes are pretty awesome with use of a preprocessor, as I’ve long suspected. We should do that as a starting point.

        In general, I think that a conversion can also espouse the iterative improvement philosophy – in this case, we can start with color schemes and really test out our tools and development process (including better documentation) in practice. In time, we may/probably will find areas where moving a file/component to being processed makes sense.

        Finally, I still have no preference when it comes to LESS vs. Sass. They don’t seem fundamentally different to me, even in practice. Sass in the form of scss seems to be gaining momentum in general.

      • Aaron Jorbin 8:37 pm on November 5, 2013 Permalink | Log in to Reply

        I love the idea of autoprefixer and concatenation as a first step. I’m happy to work on the grunt tasks for this if you want me to mock something up.

      • Scott Taylor 8:49 pm on November 5, 2013 Permalink | Log in to Reply

        Concatenation would be killer – as long as that 2 million line file is broken, I am happy.

        Outside of that, I don’t plan on doing any CSS, so it doesn’t *really* matter to me which is picked. I prefer LESS, and it’s what we use at the Times, but whatevs.

      • kkalvaa 10:22 pm on November 5, 2013 Permalink | Log in to Reply

        When you say “truly converting wp-admin.css” are you refering to changing to class based selectors? Or even going for OOCSS/SMACS/BEM?

    • nofearinc 8:21 pm on November 5, 2013 Permalink | Log in to Reply

      I like Sass as being backwards compatible with CSS, i.e. it would make no difference (in theory) if all the CSS is moved to Sass and it would require no conversion for starters, however enhancements and simplification would probably drastically improve the level of maintenance.

      Decoupling the file to smaller chunks and just combining on generation is also a good option.

      • Helen Hou-Sandi 8:34 pm on November 5, 2013 Permalink | Log in to Reply

        FWIW, I think LESS has the same compatibility without actual alterations.

        • nofearinc 8:43 pm on November 5, 2013 Permalink | Log in to Reply

          Wasn’t sure, last time I checked it wasn’t complete, but I might as well be wrong (or it could have been updated).

          • Andrey "Rarst" Savchenko 8:12 am on November 6, 2013 Permalink | Log in to Reply

            Wasn’t complete how? LESS maintained that valid CSS is valid LESS as far as I can remember, as well as getting plain non-compile CSS imports later.

            I cannot make sense where the lack of compat complaint keeps coming from, as far as I know it was never an issue (unlike SASS with their first syntax).

          • Remkus de Vries 8:26 am on November 6, 2013 Permalink | Log in to Reply

            you should see what LESS 1.5 had added to the mix; it’s quite complete nowadays.

    • nphaskins 8:24 pm on November 5, 2013 Permalink | Log in to Reply

      +100

      LESS is a little friendlier and easier to learn vs SASS IMO. I use LESS with every project. I’d also like to point out that Bootstrap opted for LESS instead of SASS.

      With this type of approach we can really start to get real color automation in place. Example, choose a base color and like items are styled appropriately. This lets devs cut down on options as well.

    • Jeff Behnke 8:30 pm on November 5, 2013 Permalink | Log in to Reply

      I think this will end up a opinionated discussion, since its going to be what ever the commentator is used to.
      Not sure how to solve that. (Voting) ?
      I agree that Sass in the form of scss is picking up speed. I actually prefer it over Less, but again thats an opinion.

      • Helen Hou-Sandi 8:33 pm on November 5, 2013 Permalink | Log in to Reply

        I sat on this post for weeks (months?) because I stress about starting wars of opinion :) Voting sounds nice, but I don’t think a vote would be a final decision, so it’s sort of misleading. We’ll just parse general sentiments out of comments, I suppose.

    • Travis Northcutt 8:50 pm on November 5, 2013 Permalink | Log in to Reply

      As many have noted, this is largely a personal opinion thing. However, for anyone who isn’t already familiar with one or the other or both, the following comparisons may prove informative:

      http://css-tricks.com/sass-vs-less/
      https://gist.github.com/chriseppstein/674726

    • Pbearne 8:53 pm on November 5, 2013 Permalink | Log in to Reply

      It may come down that we are PHP programmers and know where the $ key is!

      Pick one and import the current CSS and break out overtime ;-)

    • PeterRKnight 8:59 pm on November 5, 2013 Permalink | Log in to Reply

      I think Less is the more accessible of the two with more familiar looking syntax, also Lessphp is an excellent library to use and is extendable.

      • Bryan Petty 9:13 pm on November 5, 2013 Permalink | Log in to Reply

        When you say “accessible”, what do you mean?

        Also, note that when @helen mentions “appropriate tooling”, she’s referring to our Grunt build system, which would end up either using grunt-contrib-less for LESS, or grunt-sass for SCSS. LessPHP isn’t even necessary or being discussed anymore as we aren’t talking about bundling a compiler with WP anymore (Grunt has made this fairly pointless).

        • PeterRKnight 12:26 am on November 6, 2013 Permalink | Log in to Reply

          I admit to not being fully up to date on the latest SCSS/Sass syntax, I remember it looking more like a programming language in places (which a lot of people think is a pro). Further, what I like about using LessPHP is that it can compile on the server and plugin developers can extend it. Compiling via grunt or otherwise require dependencies that makes things less accessible (installing ruby/node.js etc). Having said that, I’m not sure how much these arguments apply to what’s being discussed here. I just chimed in because I’m superhappy with my lessphp workflow.

    • Amy Hendrix (sabreuse) 9:05 pm on November 5, 2013 Permalink | Log in to Reply

      Just to get clear before we get further into I Like Chocolate vs. I Like Peanut Butter, I’m pretty sure that adopting Sass would mean using SCSS syntax, not old-style (indented) Sass. It’s been the default in Sass for several years now, and is essentially the only thing being used any more except by a few HAML and Ruby fan holdouts.

      In that case, the “syntax is more accessible” and “easier to learn” arguments are basically moot. Both of them use a “Looks like CSS with some variables and stuff mixed in” syntax.

      That said, I prefer Chocolate. Err, Sass. Mostly because it’s what I already use.

    • Chris Van Patten 9:12 pm on November 5, 2013 Permalink | Log in to Reply

      I would like to voice a *strong* preference toward Sass, specifically using the default SCSS syntax. Syntactically, Sass w/ SCSS is really quite similar to LESS, although this article from Chris Coyier outlines the differences (and he ultimately says to use Sass).

      This is totally an opinion and based on my own perceptions (I’m not trying to incite a flamewar!), but Sass strikes me as more actively (and more seriously) developed. They have an intense focus on stability and maturity.

      Again, this is based on my own (biased) perceptions, but I also don’t see any serious professional front-end devs recommending LESS, and I can’t name anyone in my circle of front-end developers using LESS on a day-to-day basis. I’m sure they’re out there, but Sass seems to be the overwhelming choice for the front-end developers I know and trust.

      I realize this is largely an emotional response to a technical issue, but Sass just *feels* right to me, in a way that LESS does not. And—not to get too precious about the tools or anything—I would be much more likely to contribute to a Sass-based Core than LESS-based Core (for whatever little that’s worth, natch).

      • Bryan Petty 9:19 pm on November 5, 2013 Permalink | Log in to Reply

        I’ve already voiced my opinion pretty clearly on #22862, but I also agree with @chrisvanpatten.

      • Chris Van Patten 9:21 pm on November 5, 2013 Permalink | Log in to Reply

        I’d also add to this that if you look at the major open source projects that the big front-end devs are working on there is a clear consensus around building with Sass.

        For example, see this discussion on Github discussion a pre-processor to use for Effekt.css. The consensus overwhelmingly tipped toward Sass (and very quickly too).

        That’s *not* to say that Sass is the right choice for WordPress just because everyone else is doing it, but I think it does show that the industry is definitely heading in a Sassy direction.

      • CreativeNotice 9:42 pm on November 5, 2013 Permalink | Log in to Reply

        Agree completely. The only project I utilize that uses LESS is Bootstrap and even there I use the SCSS version provided by the folks maintaining Yeoman.

    • Paul Clark 9:28 pm on November 5, 2013 Permalink | Log in to Reply

      I’m with @chrisvanpatten on this — SASS — with SCSS syntax and no Compass. My reasons are:

      • SCSS shares variable syntax with PHP, so more conceptual overlap for beginners (Less uses Ruby syntax).
      • For advanced users, SCSS can be extended with Compass, which requires a bit more setup, but may be useful for some specialized purposes.
      • For team projects, I generally discourage the use of Compass, only because of decreased portability. Again, if there’s an extension that saves much time (or is only used for prototyping), that may override that.

      Quicker learning curve for beginning PHP developers and more extensibility for advanced users makes a clear case for SASS over LESS in my mind.

      • Chris Van Patten 10:19 pm on November 5, 2013 Permalink | Log in to Reply

        I’m a big fan of Compass (we use it at my company) but I’d tend to agree that it isn’t right for a project like WordPress. I think it would add too much overhead and increase the barrier to entry for new contributors.

      • Taylor Dewey 10:26 pm on November 5, 2013 Permalink | Log in to Reply

        I agree that Compass doesn’t have much of a place in WordPress core. I don’t think that it, in and of itself, should be seen as a +1 for SASS. However, the fact that a library like Compass can be built, may indicate deeper core extensibility. This is something WordPress core is unlikely to need or use in the short term (I can’t see us writing ruby gems to do anything in the short-term), but it’s presence is a comfort to the developer side of me.

    • Taylor Dewey 9:33 pm on November 5, 2013 Permalink | Log in to Reply

      sourcemaps are pretty (very) awesome as a dev tool, but may be difficult to implement by hand (the syntax is ugly and requires a sourcemap file to be generated). I believe both Sass and LESS have sourcemap support in trunk, but not stable at the moment. FWIW, sourcemap support could potentially extend to concatenated javascript.

      +1 for first steps being to break up the files and trial a preprocessor with color schemes.

      +1 for Sass / .scss syntax (yeah, it’s what I’m familiar with… there was a reason once…)

      As much as I’d love to see everything fixed — there’s a very real potential to preprocess our way into something even worse. IMO, there are a lot more best practices to keep in mind when using a preprocessor. Let’s focus on step 1 — and figure out the rest of the roadmap as people (core contributors, committers, etc) become familiar with the tool and folder/file structure.

    • CreativeNotice 9:34 pm on November 5, 2013 Permalink | Log in to Reply

      I’m also a fan of SASS w/ SCSS.

      It might be best to develop a set of requirements you need met by preprocessing and see which best meets those. Otherwise you end up with a game of tug ‘o war; consensus does not always provide the best solution.

    • Andrew Woods 10:01 pm on November 5, 2013 Permalink | Log in to Reply

      Recommendation: SASS using SCSS syntax

      Both are useful, and everyone should be using a preprocessor to manage their CSS. IMHO, SASS using SCSS is the better choice. From what I’ve seen SASS is used more by the Design community. There are also more tools that support SASS. the ‘compass watch’ command is invaluable and comes as part of SASS upon install. I’ve used both LESS and SASS. Even thought I’ve used LESS successfully on projects, I think SASS’ SCSS syntax provides more clarity. I think that helps with the on-boarding of new team members.

      • Taylor Dewey 10:20 pm on November 5, 2013 Permalink | Log in to Reply

        ‘compass watch’ would only be valuable if we adopted Compass + sass — which isn’t neccessarily on the table. Furthermore, we’d be processing sass using the grunt-contrib-sass plugin for Grunt. This way we can also benefit from additional processing on the resulting css file (e.g. autoprefixr). Since we’re in the context of grunt, the grunt-contrib-watch command will be quite flexible.

        I would, however, love to see an example of how scss is more clear than LESS. Is it just the $ variables being familiar to php devs, or is there something else?

    • kkalvaa 10:19 pm on November 5, 2013 Permalink | Log in to Reply

      I’m also a fan of sass/scss over less.

      I used to favour less, mostly due to it being easier to set up (less.js mainly), but i’ve changed my mind lately and now prefer sass. Sass seems to have a better defined goal and the newly redesigned website makes it quite a bit easier to read documentation. Also I’ve been finding more interesting projects released i sass than less lately (though that might be my bias).

    • Matt Wiebe 10:33 pm on November 5, 2013 Permalink | Log in to Reply

      The big thing here is to use one. Variables will make abstracting colour schemes far easier. Partials promote code organization and abstraction, allowing more and better collaboration.

      My only personal preference here is for Sass with the old whitespace-sensitive syntax, but even the Sass project understood that’s a non-starter when they introduced the now-default SCSS syntax. Much of the “LESS is easier” sentiment stems from this now-irrelevant item, as SCSS syntax provides you with familiar curly braces. (The other reason is that the LESS website was prettier. The Sass site was recently redesigned and this will no longer be an issue.)

      Sass and LESS are largely functionally equivalent, but here is why Sass is a better choice:

      1. The Sass project is under much more active development. Sourcemaps came to Sass first. Chrome devtools supported Sass first. There’s active work on libsass, a C-based Sass implementation that supports bindings for any language, like PHP and JS.
      2. Sass has a very active community; from frameworks like Compass and Bourbon, to simple (and not-so-simple) functions: https://github.com/Team-Sass I would not recommend using a framework, but active communities are one of the best ways to evaluate which technology to support.
      3. Any comparison list will show that Sass simply does more. It is more fully featured, particularly their extends functionality. (LESS now has extends as well, but Sass’s implementation is more mature and fully-featured)
      4. I was going to rant here about LESS’s homepage promoting client-side compiling on their home page, but they recently (finally) changed that. Good on them!
      • WraithKenny 1:56 am on November 6, 2013 Permalink | Log in to Reply

        I don’t think it’s clear that Sass has a larger, more active community or development. LESS has Twitter’s Bootstrap (and about a million projects based on it) among others and less.js core seems to have gotten a new stable of (really active) maintainers.

        The other point is of the programing language logic features of Sass versus the intentional avoidance of those in Less.js, which is also a feature (less went with gaurds). I don’t see WordPress using, or rolling it’s own, Compass, so I think the Less.js feature of not having complex programing logic in CSS preprocessing, is a actually a better fit.

        Other then that (and that in the WordPress build system, LESS doesn’t have extra dependencies like Ruby for compiling) feature wise, LESS and Sass are essentially the same.

        (Also, the ability of manually compiling LESS client side certainly has it’s uses, and is a great feature.)

        • WraithKenny 4:05 am on November 6, 2013 Permalink | Log in to Reply

          Turns out you can do complex logic and loops and whatnot in less.js, but the philosophy is that you probably shouldn’t…it’s just css after all.

        • Matt Wiebe 8:31 pm on November 6, 2013 Permalink | Log in to Reply

          Bootstrap is one project, albeit a massively successful one. One project (and its derivatives) does not a community make. Sass’s community is both broader and deeper.

          I don’t see WordPress using, or rolling it’s own, Compass, so I think the Less.js feature of not having complex programing logic in CSS preprocessing, is a actually a better fit.

          If we’re going to the trouble of using a preprocessor, I think that having the most powerful one is the better choice. We don’t have to use all that power, and I’m sure we won’t, at first. But we’ll be happy it’s there if/when we want it.

          I don’t just say this to cheer on my language of choice. There’s loads of people who start with LESS and end up with Sass. (Like Andy Clarke, who was vocally anti-Sass before that.) I have honestly never seen a single person move in the other direction. This tells me something.

    • Matt Wiebe 10:35 pm on November 5, 2013 Permalink | Log in to Reply

      Complete pedantry aside: Sass is not all caps. LESS and SCSS are.

    • OC2PS 10:36 pm on November 5, 2013 Permalink | Log in to Reply

      Does it matter that SASS is written in Ruby? Specifically, would that mean that Ruby would become a dependency for WordPress?

      Remember, while Ruby is expanding like nobody’s business, it is still not available on most hosting servers.

      • Taylor Dewey 10:43 pm on November 5, 2013 Permalink | Log in to Reply

        That’s a good point to make: Sass does have a *development* dependency of Ruby and the Sass Ruby gem.

        We also have a development dependency in this workflow (no matter if we go Sass, LESS, or even just separate CSS files) of Node, NPM, and Grunt.

        • Matt Wiebe 10:48 pm on November 5, 2013 Permalink | Log in to Reply

          Yes. That being said, it would be killer to have server-side compilation in the future (with appropriate caching etc)

          • Helen Hou-Sandi 10:57 pm on November 5, 2013 Permalink | Log in to Reply

            A script would take care of running the build that’s used for packages and the core repo, just as it already does for minified/uglified files. Otherwise: grunt watch, yo.

            • Matt Wiebe 8:21 pm on November 6, 2013 Permalink

              Yes, but that’s just for core. Let’s imagine a world where asset concat/minification for all enqueued styles/scripts happened on every page. I like that world.

        • Helen Hou-Sandi 10:56 pm on November 5, 2013 Permalink | Log in to Reply

          Develop repo already uses Grunt. I guess you don’t *have* to run out of build right now, though (I don’t, actually, I run out of src).

        • WraithKenny 11:29 pm on November 5, 2013 Permalink | Log in to Reply

          What’s that mean, “*development* dependency?” You do need Ruby installed to compile Sass. If Node, NPM and Grunt are the dependencies of the workflow, then LESS has no further dependency, but Sass (SCSS) does, right?

          • WraithKenny 11:30 pm on November 5, 2013 Permalink | Log in to Reply

            In my experience, setting up Ruby on a Windows environment is a pain, but installing Node/NPM was super simple.

          • Taylor Dewey 12:25 am on November 6, 2013 Permalink | Log in to Reply

            I was emphasizing that the dependencies are for those developing core — not for those using the product. As you mentioned, LESS would have no further development dependency beyond what is already in place (node/npm/grunt). Sass has the additional requirement of ruby/sass.

            Think we’re on the same page here.

            • Bryan Petty 4:32 am on November 6, 2013 Permalink

              On the same page, except that using Sass from Grunt does not actually require Ruby, not even as a “development dependency”, see below.

      • Helen Hou-Sandi 10:54 pm on November 5, 2013 Permalink | Log in to Reply

        Yes, it does mean requiring Ruby for development and build, but there’s not really a good reason to be running the develop repo on a host somewhere – you’d want to either use the old core repo that receives built files or a regular old package, both of which include and use compiled files (see, for instance, our unminified vs. minified CSS and JS). Doing a build would be done because you’re using the develop repo, which as its name indicates, is for developing WordPress core itself. A typical user or hosting environment shouldn’t be subject to any changes.

        • Bryan Petty 12:21 am on November 6, 2013 Permalink | Log in to Reply

          Actually, it doesn’t require Ruby if we use grunt-sass instead of grunt-contrib-sass (many projects have made this migration already) as I’ve mentioned in #22862 already, and as referenced by @mattwiebe here earlier.

          • WraithKenny 3:48 pm on November 6, 2013 Permalink | Log in to Reply

            Well, that’s nifty. I’ll definitely check that out.

          • Taylor Dewey 8:54 pm on November 6, 2013 Permalink | Log in to Reply

            I’m actually very interested in trying this out (libsass is supposed to be superfast), but it’s something to keep in mind, but it is considered “under development”

            Thanks for bringing it up.

    • Doug Wollison 11:19 pm on November 5, 2013 Permalink | Log in to Reply

      I say SASS.

      1 major advantage: if/then/else and for/while/each statements. It’s more of a programming language than LESS. There’s nothing super complicated about either language once you get past the nested styling and variables. Also, I feel SASS as a slightly more informative syntax and can give you a better idea of what’s going on in the code.

      Granted, SASS runs on Ruby/Gems, which I always seem to have trouble installing properly, but as long as somebody provides a decent how-to for setting it up on a dev server, we should be fine.

      • WraithKenny 11:32 pm on November 5, 2013 Permalink | Log in to Reply

        As far as I understand it, Windows is not supported by Ruby. They suggest using a 3rd party library to get it working.

        • Taylor Dewey 12:28 am on November 6, 2013 Permalink | Log in to Reply

          It doesn’t appear Ruby itself supports anything beyond compiling it yourself. All the third party tools to install are “not supported”

          That said, for Windows they suggest: http://rubyinstaller.org/ — would love to hear someone’s experience with it.

          • CreativeNotice 2:26 pm on November 6, 2013 Permalink | Log in to Reply

            I used the rubyinstaller last month, it ran like any other windows installer. No configuration needed post install if I remember correctly.

      • Mel Choyce 1:47 am on November 6, 2013 Permalink | Log in to Reply

        Do you have some examples where using if/then/else and for/while/each statements in Sass could be helpful? Just curious because I haven’t seen them used before. :)

    • Andrew Ozz 12:57 am on November 6, 2013 Permalink | Log in to Reply

      I’m still not 100% sold on the advantage of using a CSS preprocessor. Starting a new project and implementing a preprocessor is quite nice, importing and redefining 10 years worth of incremental (unorganized, often accidental) CSS is a nightmare :)

      Don’t get me wrong: as a coder I’d prefer to be able to use at least variables and conditionals in CSS, loops would be nice too.

      Advantages of using a CSS preprocessor:

      • Changing something in one place would automatically change it in many places in the final stylesheet.
      • (Can’t really think of another… The above is pretty nice though.)

      Disadvantages:

      • Requiring all contributors that want to be able to build trunk, to install another application or bunch of applications (for SASS).
      • Rising the bar for all contributors that may consider contributing CSS.
      • Making it (much) harder to debug CSS in a browser console.
      • Making it harder to test CSS patches.
      • Will be exposed to regressions in the build tools (that’s a big one…) and differences in the output for different versions of the tools.

      Requiring every patch that touches CSS to include both the changes to the preprocessor file and the actual wp-admin.css would make it easy to test but would increase the chance of differences in the final build.

      • Dion Hulse 1:28 am on November 6, 2013 Permalink | Log in to Reply

        Prefix: I’m using SCSS below, but I’ve only ever used LESS.. so it’s really just a placeholder.

        So far the ideas mentioned seem to suggest to me that:

        • We’d have .scss files in /src/
        • We’d have built .css files in /src/ (ie. We’d have a CSS file for each SCSS file)
        • We’d have concat’d and minimised .css files in /build/
        • We’d have Sourcemaps in /buid/ pointing to the exact location in the SCSS file that the rule came from
        • We’d have a grunt task to convert the SCSS to CSS in /src/

        Due to the higher bar of entry, we’d probably:

        • Willingly accept patches against the .css files in either /build/ or /src/ and convert them to .SCSS patches

        Migrating old CSS would happen as it’s rewritten or altered, there would be no need to suddenly change all of our code to SCSS-style.. with MP6 being added in 3.8, it seems like 90% of our admin CSS is going to be re-written or modularized anyway, so it’s not such an issue.

        Sourcemaps make debugging in browsers much easier (I recently tried debugging a sites compressed JS, only to suddenly be looking at the exact character in the uncompressed/non-ugly code, Sourcemaps work great).

        As for regressions in the tooling, yes we’d be susceptible to those too, but as has been shown by 3.7.1, we’re already susceptible to them and it drives home that all testing should be done on a /build/ and development done on a /src/.

        • Andrew Ozz 3:33 am on November 6, 2013 Permalink | Log in to Reply

          Yes, that’s pretty much how I imagine the implementation too. The “(much) harder to debug CSS in a browser console” is mostly a concern about somebody trying to debug a client site remotely, or trying to pinpoint a problem described in a forum post. Especially in older browsers where sourcemaps wouldn’t be helpful.

          …it drives home that all testing should be done on a /build/ and development done on a /src/.

          Right, but the bug in 3.7 was caused by a regression in the newest tool version, while testing was done with earlier versions. I’m pretty sure we won’t let that happen again. Finding a way to “lock” the build tools versions and force an upgrade when needed would be best.

      • WraithKenny 1:33 am on November 6, 2013 Permalink | Log in to Reply

        Another often overlooked advantage of a preprocessor is that using nested rules and mixins naturally organize rules, uncovering and preventing many problems with redundant and conflicting rules. Maintainability and Reuseability are Huge advantages.

        To address your concerns:

        • Building the css *can* be a separate process for css contributors (for testing at least, the css core would use and ship would be from the automated build process, only). For example, Sublime Text can be easily set up to build LESS with a key stroke; the tutorial on that is simple.
        • Using a preprocessor is becoming a basic and expected entry-level skill for working with css.
        • Chrome and LESS (and Sass, I think) now support Source Maps (it’s not beta anymore). This makes it just as easy to find the file and line number of the source, using Dev Tools (no plugin needed).
        • patch and build wouldn’t be too hard for contributors, if they have the requisite basic entry-level skill mentioned above.(Alternatively, I did put a proof of concept plugin on the Ticket that could ultimately edit, compile, and show LESS changes live in the browser. There’s no technical reason the plugin couldn’t be extended to accept and output diff files.)
        • I don’t have an answer to this one, but I’m not convince it’s a big problem. Core will use Grunt, with a specific version of the preprocessor, so with care, it shouldn’t be a big deal. The preprocessors simply aren’t as complicated as a language like php or javascript. Any regression is easy to notice, and has no security implication that I can think of, and easily corrected.

        I don’t think requiring the compiled css in the patch is the right way to go.

        • Andrew Ozz 3:49 am on November 6, 2013 Permalink | Log in to Reply

          …using nested rules and mixins naturally organize rules, uncovering and preventing many problems with redundant and conflicting rules. Maintainability and Reuseability are Huge advantages

          Right, that should have been point two in my comment above.

          I don’t think requiring the compiled css in the patch is the right way to go.

          My concern is mostly about people who want to test (bigger) patches that contain CSS. Not sure if we should require them to be able to generate the stylesheets.

          • WraithKenny 3:59 am on November 6, 2013 Permalink | Log in to Reply

            Maybe a “companion” patch that just contains the .css changes? It’d be a courtesy patch that wouldn’t be commited, but is just available for testing, for use by folks who can compile the css.

    • Brendyn Montgomery 1:16 am on November 6, 2013 Permalink | Log in to Reply

      We use Sass (specifically .scss) in all our projects and so would have a preference for it over LESS.

      I love the idea of a preprocesser being built into the core, especially if it could be extended to include other addtions if a developer wants it (we also use SUSY grids, breakpoint and compass on all developement projects).

      Could it be implemented in such a way as to be an optional flag in the wp-config.php that defaulted to off? That might get around the issues of old CSS that could be problematic or people not wanting to use it for any reason?

      Another major advantage of Sass (can’t speak for Less) is that you can define the output to be compressed which will strip all the white space and comments out of the CSS and reduce file size. That means that you can be really verbose with comments in the Scss file and then know that this isn’t going to effect the size of the .css file.

    • fightthecurrent 1:47 am on November 6, 2013 Permalink | Log in to Reply

      I’m definitely in support of sass. Plenty of valid arguments have already been made :)

    • Till Krüss 3:38 am on November 6, 2013 Permalink | Log in to Reply

      I prefer Sass (SCSS syntax) over LESS.

      LESS is a good CSS preprocessor, but Sass is IMO simply better. It has a cleaner syntax, it supports conditionals & control structures like loops and variable defaults which LESS doesn’t or in a bad way. Plus Sass supports one-dimensional lists and with 3.3 multi-dimensional lists.

    • Remkus de Vries 8:31 am on November 6, 2013 Permalink | Log in to Reply

      I personally prefer LESS over SCSS, but surely this is influenced by my experience with Twitter Bootstrap. Does anyone remember why they opted for LESS at the time?

    • Nashwan Doaqan 9:11 am on November 6, 2013 Permalink | Log in to Reply

      I use LESS in all of my projects, never used SCSS before.. LESS gives me all what I need and I didn’t get a reason why I should learn SCSS!

    • Gary Jones 9:26 am on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS. When I looked at the differences a while ago, Sass as SCSS just had more development features and flexibility (i.e. you could do a little more with it as it was more powerful). When everything is generally status quo, having the *option* to use one of the advanced features at some future point should be a valid consideration.

      • Christian Foellmann 10:47 am on November 6, 2013 Permalink | Log in to Reply

        +1 for SCSS. I am with Gary on this. SCSS seems to be more powerful and thereby more future-proof.
        I really love the idea of using a CSS preprocessor and I think the concept of both is so similar that people familiar with LESS can switch pretty easily.

    • Josh Eaton 1:36 pm on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS

    • atadams 3:40 pm on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS.

      I think it should be pointed out that Linkedin has hired Chris Eppstein to maintain Sass (and Compass). Having a dedicated developer is a big plus. I don’t know if LESS has anyone comparable.

    • Pbearne 4:13 pm on November 6, 2013 Permalink | Log in to Reply

      I have thinking a bit about this and wondered if we should ..

      leave the current css tools (wp_enqueue_style) and add a whole new stack

      wp_enqueue_sass to add files
      wp_enqueue_sass_folder for all file in folder
      wp_enqueue_sass_fagment do just pass string of scss

      if debug on we compile every page load otherwise we cache a single css file and rebuild on plug-in / theme activated / deactivated etc. (add wp_complie_sass() so it can be called)

      I see the need for filters pre_complie_sass and post_compile_sass

      If do this plugin’s and themes can convert as they see fit

      let’s also fix/add conditional CSS and possible provide a ordering options

      does this make sense?

      • Helen Hou-Sandi 4:24 pm on November 6, 2013 Permalink | Log in to Reply

        I don’t think core should be compiling CSS on the fly. We already use a Grunt-based build process – this would be an extension of that.

        • Pbearne 4:45 pm on November 6, 2013 Permalink | Log in to Reply

          I can see that makes sense.

          Sorry to get it clear in my head are talking about adding a server side compiler or just a developer grunt script?

          What I believe we need is a server side compiler as will get more adoption in the community.

          So do we end up with 2 css files wp-admin core and plug-in’s

          Part of the benefit of sass is the reduction of css files I feel we should pursue this benefit as best we can.

          • Taylor Dewey 9:11 pm on November 6, 2013 Permalink | Log in to Reply

            The plan so far would be to use Grunt to process (if necessary), concat, and minify css files. So a developer build process using grunt.

            Server side concat and minification is an entirely different discussion that wouldn’t be influenced by our preprocessor usage.

            Server side processing is also a different discussion and shouldn’t influence our decision to use a preprocessor or not (nor which one).

            Reducing http requests is a noble goal—but has no relationship to this thread.

    • Shea Bunge 11:30 pm on November 6, 2013 Permalink | Log in to Reply

      I used to use Less before switching to Sass’s SCSS syntax. One of the main things that held me back was implementation, but this wouldn’t be an issue as we are using Grunt.

      Aside from Compass, I enjoy how much more powerful Sass is over Less. For one thing, Sass supports nested properties:

      body {
      	background: {
      		color: red;
      		image: url( 'foo.png' );
      		size: 42px 42px;
      		position: top right;
      	}
      }
      

      Sass also supports nested media queries – an invaluable feature, IMO.

      body {
      	background-color: blue;
      
      	@media screen and (min-width: 130px) {
      		background-color: green;
      	}
      }

      In Less, the above code would have to look like:

      body {
      	background-color: blue;
      }
      
      @media screen and (min-width: 130px) {
      	body {
      		background-color: green;
      	}
      }

      Sass also supports much more advanced logic and control than Less.

    • Shea Bunge 11:33 pm on November 6, 2013 Permalink | Log in to Reply

      Additionally, I would also like to suggest using the excellent Autoprefixer tool for automatically adding necessary CSS prefixes. There is also an Autoprefixer Grunt task available.

    • Sofia Rose 7:35 pm on December 25, 2013 Permalink | Log in to Reply

      @helen Are you still working on a 3.8 Style Guide? If so where can i get a copy? I would love to help with this. :)

    • Cameron Roe 11:07 pm on January 26, 2014 Permalink | Log in to Reply

      As the web moves forward, how are devs keeping up WITHOUT SASS?? I feel like it’s a must nowadays, and it would be extremely helpful to have Grunt running watch and build tasks with Core. The beauty of Grunt is that LESS users could easily add their LESS plugin if they wanted, but the majority would see built-in SASS. Compass, Bourbon, and most of the dev community pushed for SASS. Bootstrap is the exception in my book.

      +1 SASS.

    • Cameron Roe 11:17 pm on January 26, 2014 Permalink | Log in to Reply

      The other awesome benefits of this are the use of partials within themes and the nature of reusable variable declarations. It would allow for a more modular approach for styles.

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

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

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

    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.

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