GSoC Chat
Mentors: GSoC chat in #wordpress-gsoc in about an hour if you’re available.
Updates from Jen Mylo Toggle Comment Threads | Keyboard Shortcuts
-
Jen Mylo
-
Jen Mylo
Post Formats, Schedules, and Philosophy
Post Formats UI is looking like this right now:
This seems confusing, because it looks like they are icons to insert something (Image, Gallery, Link, Video, etc), but instead of launching a popup to insert a link or an image, the screen changes and the navigation that was just used to choose disappears completely. (Note: If Standard had some indication of being the default/current selection it wouldn’t be as confusing)
Clicking on one — say Link — makes the UI change, the big icon row go away, and a format switcher link drops below the title rather than keeping its visual hierarchy above the post stuff, and it’s generally disorienting.
If the user thinks, “Whoa, what happened, I better change format again,” and they click on the “Change format’ link under the title field and next to the “Enter URL” instruction, the screens morphs again to this:
Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing. Does it still think it is a link bc they didn’t actively choose to return to standard, they just chose to see the options? If that’s so, why did the url field disappear?
Looking at the release schedule:
We launched Beta 1 on April 4, and it’s been almost 3 weeks without a follow-up beta 2.
…I am wondering if the post formats ui is really prime time ready, or if it should be one of the very first thing sto land in a 3.7 branch so we can get the things that are completely ready into the hands of users sooner rather than later?Since I’m outside the core dev group now, I’ve been on both sides of the deadline delay dance. I know how hard it is to let go of something that feels like it is thisclose to done. And I know that just about everyone on the core team will be thinking right about now that I should shut up (and I’m okay with that, because it used to be my first response to deadline questions to core, too). But we have this philosophy posted on wordpress.org:
Deadlines Are Not Arbitrary
Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and not so much that we end up breaking more than we add.
Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.
The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.
The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.
I’m not trying to be a troublemaker or imply that anyone isn’t doing everything they can — I know for a fact that people are working themselves into the ground on this release. Nor am looking to incite a debate about deadlines or all the explanations of how we fell behind this time (I’ve been following along, everything is really pretty normal). But would it be better to not try to squeeze it all in, get out what we can ship now (including the awesome 2013 theme that regular people still don’t have access to), and take a quick breath to relax before diving back in on a new cycle? Shipping is a feature, too.
-
mordauk
-
Jon Brown
Ditto. Current UI is confusing for all the reasons Jen documented. I was actually starting to like the UI just before beta,, but beta 1′s change post format link is awful. Fix or punt, but don’t release it like this. Do keep API’s either way, I’d assume changing those might cascade into post revision changes?
-
lisafirke
On the UI, yes, it’s confusing, even to an experienced user. The fix doesn’t seem that tough, though. Keep in mind that icons don’t have to carry all the weight. Words are useful, too! What would be wrong with adding a simple: “Choose a post format:” label?
Also, standard icon shouldn’t be a pin. That to me signifies a *sticky* post.
-
-
Harish Chouhan
Yup pushing back 3.6 seems better path. So much work has been put into this already. The Tabs that were there very early in the development of 3.6 were annoying but more usable. Hiding and displaying the Post Format icons, involves extra click and confusion.
-
-
Caspar
tbh, I have no idea why post formats made it into core. They have, so it’s useless to complain. But if Links got removed from core into a plugin, so should post formats.
The UI itself looks very nice, though, if one likes the feature. Yet I think Jen is right: give it the time it deserves. I don’t think a majority of users would miss it if it had to wait until 3.7.
-
George Stephanis
Post formats have been in core for some time now. It’s just the UI implementation that’s new, to make it easier for people to use, as well as implementing the custom fields for each.
-
Jen Mylo
UI enhancements are, well, enhancements. This is what the schedule says about Beta 1:
From this point on, no more commits for any new enhancements or feature requests in this release cycle, only bug fixes. Any enhancements/feature requests not completed and committed by this point will be punted to future. Please don’t get angry and complain when this happens; it’s necessary to get us to an on-time release. You can keep working on your pet ticket and have it ready for early 3.7.
Saying that the UI was an overall bug is enough stretch to snap a tendon.
-
Aaron D. Campbell
The new UI was in before beta but the tests revealed bugs. I think that saying we’re trying to stretch the definition of bug to include the original UI enhancement is an equally tendon-snapping stretch.
-
Jen Mylo
Poor usability isn’t really a bug, it’s unfinished design.
-
-
-
-
Mike Schinkel
I have no idea why post formats made it into core. They have, so it’s useless to complain. But if Links got removed from core into a plugin, so should post formats.
In hindsight, compared to my opinion when they were first announced, I definitely have to agree. With everything you just said, except the first part; I do have an idea of why.
-
-
John Blackbourn (johnbillion)
+1 on punting the post formats UI to 3.7, and releasing 3.6 with the other great features we have, including Twenty Thirteen. I think to bring this UI up to scratch we need to re-address it without the impending delay of 3.6 looming over our heads.
-
George Stephanis
Twentythirteen is kinda based off post formats, if we nuked it, twentythirteen would lose a lot.
-
Jen Mylo
If you ditched the chooser ui and used the old radio button box, it would still be available, yeah?
-
Beau Lebens
I believe it uses the new, postmeta-powered storage of individual data elements (link, image tag, video embed, etc) for the different formats.
-
-
Matt Mullenweg
I think of it more that 2013 gets super-powers down the road.
-
-
-
Aaron D. Campbell
Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing.
I agree that the icon should change back to standard. That’s a bug.
-
Chip Bennett
+1 to releasing the Post Formats UI updates when they’re ready: either by delaying 3.6, or punting the implementation to 3.7.
Can we keep the underlying functions, though? Standardizing on post-format related post custom meta data, and standard data fields for each post format type, is equally (if not more) important than the UI improvements.
-
Jen Mylo
I would agree.
-
George Stephanis
+1
-
Beau Lebens
Can we keep the underlying functions, though? Standardizing on post-format related post custom meta data, and standard data fields for each post format type, is equally (if not more) important than the UI improvements.
Definitely agree on this bit.
-
Konstantin Kovshenin
What exactly is the benefit of keeping the APIs to access meta data, without keeping the UIs exposing that data?
-
Chip Bennett
Because the back end isn’t the only place that those meta-data are exposed? Theme-rendering of the meta data is completely unaffected by back-end UI.
-
Drew Jaynes (DrewAPicture)
I can see some benefit in keeping the APIs to access the metadata, which is to make it available and allow the wider WordPress community to innovate and iterate on that information. Of course, it doesn’t really solve the issue of Twenty Thirteen relying on that metadata and having no UI to handle it.
-
Chip Bennett
The API handles migration of appropriate data to post meta data. Could that be confusing? (Where did my video go?) Sure. That can be addressed, though, with simple metaboxes for relevant data, even without the contextually changing icons/UI. And post format selection is already available via meta box.
-
-
Drew Jaynes (DrewAPicture)
I’m with @chipbennett that we should either extend the release or punt the UI to 3.7 while at the same time keeping and exposing the underlying functionality.
As I said in response to @koveshenin, I can see one major benefit of exposing the meta data APIs as allowing for community innovation and iteration. I’d like to see us expose the APIs and maybe package core’s version of the UI into a plugin. The ability is there, the implementation is not and I’d like to see us give it a better measure of caution before we roll it as a core UI.
-
krogsgard
I already do custom UI interfaces for clients w/ post formats, and the new functions and standard meta data conventions are enormously helpful for future proofing a custom UI. If the UI gets bumped, keeping the new functions will still be a big win for theme developers.
-
-
Marcus
+1
the ui is too important to rush, since it’s used by everyone
-
-
Hassan
I don’t really think that Post Formats UI are that important of an addition to make the release date pushed back again and again. I know some people might want it, but for me I’ll probably won’t use it all. Btw, if my theme doesn’t support it, I won’t see it, right?
So, yeah… I don’t mind pushing it to v3.7 instead. I’d rather ship something fully tried, tested, and trued than half-bake it and rush the release.
-
mindctrl
I’d like to see this come in 3.6, even if that means pushing back the date. If this version is all about “content”, and Twenty Thirteen is all about blogging, it makes sense that this UI makes it in and launches with 3.6 and the theme.
I don’t think there are millions of people sitting around tapping their feet saying WordPress 3.6 better come on 4/29, or even know that’s the date. The devs and core team, sure. Users, not so much. It is about the users, right?
The rabbit hole thing kinda doesn’t apply in my mind. It’s not adding one more feature here or there. It’s getting one of the centerpiece features of this release finished and included.
If everyone agrees to push back the release date and that no work gets done in 3.6 that’s unrelated to Post Formats UI, there is no rabbit hole.
-
Daniel Dvorkin (MZAWeb)
Personally, I don’t really like the new Post Formats because I don’t find it very useful for my use cases. Having said that, I must say this argument makes a whole lot of sense.
-
Nashwan Doaqan
I agree with you, The post formats is not very useful to me, but maybe for others it may be very important … anyway after all work on The New Post Formats UI it will be hard thing to move it to 3.7
-
nofearinc
I do agree with you; don’t get their concept, not sure if I will. I’ve seen other systems using this approach though and it would be interesting to see what users would judge here if they get an access to the post format switcher. It’s still a common blogging platform even if we build CMS-based stuff out of it.
Problem is we can’t easily deprecate anything that’s open to the public and it might be the new ‘Links’ thingy that lives and dies notoriously.
-
mattyrob
I can’t see a use for this section either so I’ve hidden it on my testing sites.
That said, if this is supposed to be a new core feature of 3.6 then releasing a new version without it and bumping to 3.7 seems ill advised.
I’d say get it fixed, delay the release to all this to happen (and if possible while fixing it, allow it to be hidden from the Screen Options).
-
-
kevinjohngallagher
I don’t think there are millions of people sitting around tapping their feet saying WordPress 3.6 better come on 4/29, or even know that’s the date. The devs and core team, sure. Users, not so much. It is about the users, right?
I disagree.
It’s not about “millions” of people, it’s about the businesses and organisations that based themselves on top of WordPress. As we move out of the small shops, and small website builds into larger engagements (Government, Enterprise, Education, and Charity sectors) we start to hit more and more procedural issues and legislation.
There is a huge challenge for many of us of balancing Open Source agility against Service Level Agreements. We’re navigating digital security engagements, code freezes and legal red tape (hello disability discrimination act versus our love of mouse-only hover menus and slight shading that colour blind people cant see) – and these things are planned well in advance.
For example, the Release Date for WP3.6 is the same week as the big bank holiday weekend in the UK (most don’t happen in both Scotland and England), so we’ve had to make plans around it in February. We are so focussed on blogging end users that we forget about the business ecosystem thats built around WP beyond that of 5 or less people organisations.
if we want WordPress to scale, in a non-technical sense, then we need to address some of the fundamentals of our product management.
-
mindctrl
Major WP versions are mostly about features, and if your SLAs for large organizations require you to be on the cutting edge of Feature 1.0 at release time, you just might be insane.
-
-
-
Ryan Boren
The four month deadline is so fanciful as to be arbitrary. It always has been. Historically, we just can’t do a major release with a marquee UI feature in that time, certainly not without heroic efforts of the 3.5 sort. So we end up facing decisions like this. Every single release we wonder if we have to punt the marquee feature. Punting often requires major surgery that can be as much work as finishing the feature. Punting is demoralizing. Four month releases are empty promises that bring us here.
-
Jen Mylo
I used to argue that a 6-month schedule was more realistic with the kinds of features we choose, so I don’t disagree with you, but the people who made the 3.6 schedule and chose the scope for it are the core leads, no?
At least change the schedule page if a decision was made to push back release by a month or whatever.
-
kevinjohngallagher
I can’t disagree with you Ryan, but in an agile methodology – and again thats what the core team has embraced – it’s a completely moot point.
Every completed work that is signed off in each sprint that matches “definition of done” makes it into a releasable candidate. Work that is not integrated into the “master branch” isn’t released.
The issue is not a 4 month, or a 6 months or a 4 week or a 12 month release cycle, it’s the management of scope of what can be done in that time period. Can we release a new WordPress version every 4 months? yes. Can we release a new WordPress version every 4 weeks? yes. Can we do that regardless of the amount of scope we presume we can deliver? heck no!
The developers that work on care are amazing. As a failed developer myself I’m always in awe of what gets done. But there are 4 factors in the engineering pyramid: Scope, Time, Quality and Resource.
> When Scope is more than should fit into time, and resource stays the same, the only variable that moves is quality.
In WP’s history, thats usually to the detriment of edge cases. Especially when we’re talking about UI changes.
Historically, we just can’t do a major release with a marquee UI feature in that time
That to me suggests that Marquee UI features should be done over 2 (or more) releases. We should release features when they are ready in accordance with our definition of done. Releasing a feature that isn’t up to our MVP isn’t going to do any good, and neither is changing our release date. We shouldn’t try to change our release date to fit in with our feature set, nor vice versa.
I suggest the Project Manager reads: http://ma.tt/2010/11/one-point-oh/
Punting often requires major surgery that can be as much work as finishing the feature
Thats a very different issue. We should be managing integration in the most decoupled way possible. Tight coupling of features into the core so that they *have* to ship is a scary scary path that leads through “bloatville” to “dependancy-city”. If something can’t be built as a plug-in, then thats the issue that should be solved first.
-
-
Scott Taylor
I would argue that the deadline is entirely arbitrary, and it was never realistically altered based on shifting resources. That being said, we had a previous UI iteration we were all proud of, and then user testing said otherwise. The new UI tested about 3 million times better (I’m a data scientist by trade). Since we are in beta (shipping late for sure), now is the perfect time for more testing and tweaks, not less.
In the past few weeks, we have landed some huge and wildly complex commits, but there are not a litany (or really any) of those left. There are things here or there, but none (?) are blockers.
I agree it’s crunch time, but I would rather we all pull together and use our noggins rather than criticize and shelf it. What’s *really* missing? *How much* needs to change? @lessbloat and I rejiggered the entire UI in 1-2 days. I doubt that kind of effort is needed again or a that complete reboot is necessary
-
Tom J Nowell
I’d suggest:
- The post format icons should never go away, they provide a second purpose as an indicator and feedback once clicked, hiding them removes that function and forces the user to either remember what they clicked, or figure out from scratch if they’re looking at an existing post.
- Icons and labels at the moment look arbitrary as if they’re just floating in the middle
- When opening a new page, how do you know that it’s a standard post, it’s not highlighted in any way or shown to be active. It’s not obvious that the icons are a toggle/selection
- The icons look more like buttons, actions, that they do something rather than set a status/toggle/selection
So I’d say that they would be better as tabs, always visible, or at least with a separating line so it’s clear that they are separate from the controls underneath and have a high level purpose, associating them with the Add New Post rather than the content box.
-
Jen Mylo
I would agree that keeping the icons present would be less disorienting.
-
Andrew Ozz
A post format is something that should be chosen once at starting a new post. It could be changed later but that would mean loosing/removing some of the data that the user has entered (well, we don’t “loose” the data but it becomes unreachable/useless).
In that terms hiding the icons after a post format has been set makes sense. Perhaps the link can be more prominent and be above the title field (or whatever field is at the top for the current format).
Keeping all post format icons visible at all times is not good imho. We still need to educate many users what post formats are and how they can be used. Part of this is that changing a post format comes at a cost.
-
Erlend Sogge Heggen
+1 for icons never going away. If that was the case however, I think it should be possible to turn off post formats altogether. If you’re using a format-supporting theme but your client is only interested in making ordinary posts, you’d want those tabs out of there.
+1 for making them look more like tabs.
-
Tom J Nowell
Here’s a UI that fixes the issues, doesn’t have the pretty images, but that can be fixed ( look at your browser tabs for an example )
http://alexking.org/wp-content/uploads/2011/10/format-standard-510×244.png
-
Tom J Nowell
hmmm image broken
Point was the original UI worked better, we should return to it until we’ve devised a better one as it was an improvement on the radio buttons
-
Alex King
Here a link to the post that includes the image: http://alexking.org/blog/2011/10/25/wordpress-post-formats-admin-ui
-
-
Erlend Sogge Heggen
I think he’s got some kind of anti-spam measure in place. I got a 403 at first as well, but after I had visited the original article and opened the image from there, your link worked too.
-
-
Justin Sainton
I’d agree with Pippin, Scott and Ryan. Do what’s necessary (which most agree, is not much) to ship with this in 3.6. We’ve already lost one original content feature (to @danielbachhuber and @kovshenin’s great malaise), I don’t see the benefit in shipping without a Post Format UI.
It also seems that the general opposition to the new UI is “It’s awkward…people won’t know what to do…it’s jarring” – all of that is also true of the Post Format concept in general, we heard the same arguments when the initial API was introduced. Give people time and give them credit to work it out.
-
Jen Mylo
Millions of people have no trouble understanding the concept with Tumblr. Regular users don’t even think about “post formats,” they think about “posting a video” or whatever the format is.
-
kevinjohngallagher
The difference with Tumblr is that it is not a post format change, it’s a post type.
We have post types (with custom UIs to look like post formats), and post formats that have the same functionality as post types.Post formats are essentially standardised custom post types with a unified UI – but only accessible from a totally different place in the admin section.
( CPT called “quotes” is a main navigation link, while post formats is inside post, and then choose quote)Post Formats are a great idea, but in a rush to get them out the door in 3.1 we took a tactical decision rather than a strategic decision which has led us to where we are now.
-
Manny Fleurmond
That’s actually a good point. I’ve been trying to figure this one out myself.
-
-
-
-
nphaskins
I think it’s right on the money how it’s currently sitting. I wasn’t too keen on how it sat previously (small icons and boxes) so to the guys who re-jigged it, I think you did a stellar job. I’ve been using this (the new UI and functions) extensively over the past week or so as I’ve been rebuilding a few products against the current beta and the current UI. I find it quite nice and don’t consider it confusing at all. I asked my wife to look, and she knows nothing about web shit, and even she could figure it out.
I’m typically a “hard to please” kind of person and I really do think that this is damn close to being kosher.
-
Nashwan Doaqan
The new post format UI is a main feature in 3.6, I can’t imagine the 3.6 version without it… but if you think it is not ready yet you can move it to 3.7 and focus on other bugs tickets…
My opinion is to do one idea perfectly is better than doing a lot
-
BobDunn-Trainer
Yes, I do believe if it is released, we will all adapt, even though it is confusing for the average user. The big question is will they even attempt to use these, or totally ignore them. Putting them up front and center will force them to at least try to understand.
At our last WordPress meetup we did an overview of 3.6. I asked all the casual users to raiser their hands. Then I asked them to keep their hand up if they had ever used post formats or even understood them. All hands when down.
From the perspective of the people I work with, casual users, I am good either way
-
Stuntbox
I’m just one person, but I’d vote for keeping Post Formats in 3.6. Until now, the lack of any kind of admin UI has made Post Formats an incomplete feature. Most casual users aren’t using or discovering them because it’s completely invisible to them without a UI.
Tweaking and refining the existing UI design seems like it would benefit from this shipping. While there’s been user testing on the Post Formats UI, it’s limited in scope compared to the total number of users who will be exposed to it and provide useful feedback once it goes live.
It also seems like there are small tweaks that can be made to improve the current UI without punting on it altogether or causing huge delays. Things like simply updating the main heading in the admin UI as the user makes a selection. It won’t cure everything, but it would be a subtle reinforcement if it changed from “Add New Post” to “Add New Image Post”, etc, as a user made selections. (I know I’m getting off topic here, but you get the idea.)
-
Robert Dall
On Schedules:
To use an analogy… If the ferry is always late… I don’t say the ferry is broken… I say change the scheduled…
-
Grant Palin
The post formats basic functionality has been in place for some time already. I’m surprised there hasn’t been an official UI for it sooner. It’s something I think is core to blogging, and could be worth pushing on it a little bit more to get it done now. And ship it when it is ready, rather than committing to a deadline. I thought the 3.6 cycle was surprisingly short anyway, so there’s room to extend it a bit.
-
Knut Sparhell
My first impression after seeing this new post format UI was: How elegant! Sometimes something will feel confusing to someone. When introducing new features the questions should be if the UI at least is educating and guiding the road to understand the purpose.
These post formats are a major leap forward. Removing (punting) this would reduce 3.6 to a release that just fixes some old bugs. Push the scheduled dates a few weeks more and get it released.
Lesson to learn is to start working on major new features in the cycle preceding the cycle it’s going to be released. Use a plugin to iterate, like with the MP6 project.
-
Jen Mylo
I do think the icons look elegant. Remember that in 3.7 that icon style will be replaced by the icon style in MP6, so it will likely have a pretty different feel.
-
kevinjohngallagher
I think thats an issue right there.
We’re considering releasing something that we KNOW we’re not happy with, and that is changing next release anyway.
Why are we forcing multiple UI changes on our users?
I personally like the UI, though the UX is lacking, but if we’re changing it anyway – what are the advantages of releasing it?
-
-
-
Arnan de Gans
Sure let’s turn WP into the next Facebook
Can these buttons be hidden in a jquery slide in/out kinda thing?Think of the 2nd screenshot, where you click the “change” format and a section slides out pushing all elements on the page down. You click the post format you want. It slides back up and the below form changes accordingly.
That’s unobtrusive, non-confusing and is “trusted” since some other sites use a similar approach for posting items or hiding options.
-
Scott Taylor
I have yet to hear specifics from anyone about what they want to change and how. No patches, no mockups, no explanation of what actually sucks and a plan to start attacking it. So, sounds like we’re still in beta and could use some Trac activity from those with an opinion.
I’ve been actively working on this stuff for the past 3 months and most of the people on this thread have had light involvement, if any at all. I am trying to figure out what is constructive about pointing fingers right now.
-
Jen Mylo
I’m not trying to point fingers, as I said. I’m trying to get us to take a look at what is ready to go and what still needs more work, and re-assess the scope/schedule as needed. I also didn’t say it sucked, I said it was confusing, and I posted a step by step outline of why along with screenshots. I have been on the receiving end of the “should it be cut so we can ship” with a WordPress release many times, so I get it that defensiveness is the first reaction. Everything you just said, I’ve said before.
If the decision is to extend the cycle and try to deliver in May instead, that’s a valid outcome too, but it’s not reflected anywhere on the schedule, which still says there’ll be a beta every week. Being late isn’t the end of the world, but going 3 weeks without another beta makes it seem that there are bigger problems than just fixing bugs, and if the schedule needs to be adjusted/updated to allow for more design/dev time then it should be.
*I’ve *also* been the pm in the past who extended the dev cycle without updating the schedule page, and got comments asking about it on this blog, so I understand the natural reaction to that is, “Hey, we’re spending all our time on the product, don’t hassle us about a blog page.”
-
-
Matt Mullenweg
We shouldn’t take this personally. Features get adding and removed from releases all the time, even ones I’ve advocated for or worked on, and even at the eleventh hour.
It’s also very normal to get tons of feedback after all the work on a feature has been done, or often after it’s been shipped.
Even if it was pulled from core entirely, the work could be put into a plugin that we can see how it gets adopted and used in the WP ecosystem.
-
toscho
I think this is a good idea. We could put it into a plugin and ask the users to allow us collecting usage data to see what elements should find a way into 3.7. Empirical data would surely help.
-
nofearinc
Sounds like the best way to test something major and trendy without risking to think about deprecating and cleaning the codebase afterwards. +1
-
kevinjohngallagher
I’m not against this thinking at all.
My concern from a purely Project / Product management point of view is that the decision was made to tightly couple this specific change with an external dependancy in the 2013 theme.
I’m a huge believer in MVP, or MMS depending on where you did your Agile training, and that we’ve fallen foul of the desire to push things into a core release when they weren’t ready before.
I also believe that this is a prime example of the 80/20 rule causing issues with the decision making for core. As we move more towards CMS and away from purely blogging, WP.com is always going to enforce “purely blogging” concerns/issues/features into the 80 camp.
[One] can’t imagine the fun conversations that we’ve already had with government agencies around the delay in the beta2 of their chosen CMS due to blogging UI concerns…
-
Erlend Sogge Heggen
The plugin route for developing and testing flagship features across several cycles has proven to work very well for MP6. I hope the WP team will adopt this method for more core features in the future.
In this instance though, I don’t see why it would be necessary. Even with its current quirks (make it always-on and tabbed-styled and it’s perfect imo) the new post format UI is a HUGE step forward for this very little known feature, all because of an incomplete UI.
No one’s going to be worse off for this update. They’re either gonna continue making standard posts like they used to, or they’re gonna click those buttons and start learning about post formats.
-
Matt Mullenweg
FWIW, being freed from core was the best thing that ever happened to MP6.
I do think people will be worse off with this update though. It’s really disheartening to see the confusion that people have when they face the dashboard and the post page, and the overwhelming majority of people who start WP give up without ever making a first post. I think for reasons like Jen pointed out and that came up in user testing.
The downside of not putting it in is there will be 4-5 months until the next release. Since people think it’s worth waiting at least a month for that doesn’t seem that bad. The downside of putting it in would be the millions of new WP users that are exposed to it for the 4-5 months until the next release (assuming we even do another iteration on it immediately post-release, which we’re not historically great at).
-
-
mor10
Putting Post Formats in a plugin is definitely the right thing to do. The UI and implementation is confusing but more importantly most current themes don’t have much support for the feature and the output in these themes will be unreliable if not bizarre. Additionally Post Formats are only relevant for blogging. For those who primarily use WordPress as a CMS they are a distraction and end up being in the way. The key questions here are: Do new users understand how Post Formats work? And do WordPress users actually want and use Post Formats at all?
-
kbiglione
This is exactly the problem. New users are baffled by post formats as it is, and the new UI doesn’t do much to solve that problem.
Honestly, the new UI seems designed to promote a feature that hasn’t been embraced by theme designers. It’s almost as if we’re doubling down on a bad decision (adding Post Formats to core).
-
-
-
Mike
Very dumb idea to pull it out! It is better – if necessary to delay the release. If the process works and it’s the GUI that is the problem [for some] just add a toggle to disable it in the Writing settings.
The Post Formats concept – as presented is very clever, even radical. That’s what a WordPress release should be – moving the bar, innovating, taking blogging to where it’s never been before. It is very likely that this attempt – while far superior to the previous version – is not perfect. But an insular GUI testing audience is not the best group to really charter a path through future waters.
WordPress is too big now to rollout helium releases. Too many people are putting in big efforts. Taking the Post Formats changes out at this point is disrespecting the great work that’s gone into developing it and disappointing large numbers of developers and users looking forward to innovating with yet another groundbreaking WP technology.
-
Chris M.
Give it time. Here’s a thought from the UI perspective:
-
Samuel Wood (Otto)
I say delay the schedule, address the minor concerns that remain. and roll out up to a month late if needed.
This is the big feature for 3.6. It’s the one that has gotten the most work. And at this point, I think the UI concerns remaining seem relatively minor and fixable, with proper suggestions and input. Nothing here looks like it’s drastically broken enough to go to the MAJOR task of ripping it all out of core just in order to do a release and hit the deadline.
Deadlines Are Not Arbitrary, this is true. But that point is there specifically to address the issues of feature-creep and unmitigated-scope-expansion. This is neither of those things. Taking the time to make some relatively minor adjustments and polish to the UI seems minor by comparison to hitting that deadline at-all-costs.
-
Samuel Wood (Otto)
Specific suggestions to address the UI concerns in the OP:
- Make the “current” format have a highlight of some type. Slight background shading. Something.
- Instead of putting the “change format” below the title, have a selection-action cause the bar to scroll upwards, hiding it or reducing its space-on-page. Not completely hiding it, maybe leave the text visible, and still shaded to show the current format.
- On mouseover or some other form of indication of change, scroll the bar back down again, but without scrolling the whole page down. Make it overlay the existing area, then change the displayed UI when a new format is selected.
-
Mel Choyce
For a “current” state, we could pair color with a secondary indicator, maybe like a light border or background shading, like you mentioned?
-
Mel Choyce
Color example: http://cl.ly/image/3K090D3H3M0U
-
Samuel Wood (Otto)
The colored icon is a good one, I like it. Paired with a light background shading around the whole box (text included) it could work out nicely.
-
-
-
Chris M.
Similar to my mock-up above: http://make.wordpress.org/core/2013/04/23/post-formats-schedules-and-philosophy/#comment-8560
-
kevinjohngallagher
Brother,
I agree with your premise in an abstract sense, but not in the specific one.
We should not stick to a release schedule (really a guideline) just because we posted it, but we should also be aware that companies and organisations do plan against the schedule as posted.
Given that agile, and we’re using the modified Scrum methodology, states that every sprint has a releasable product as per our “definition of done”, one has to wonder how we’re so off track. I can’t be alone in having a meeting with a client tomorrow morning who will ask why there is no Beta2 at the date when RC2 was meant to be released.
If we’ve bitten off more than we can chew, then we need to change something:
- ship with what works (and meets our definition of done) and push the rest to the next release as per the management methodology that we prescribed to
OR
- delay the launch to squeeze in as much as possible, and accept that the amount of UAT testing is going to diminish.
My concern is that every time we’ve made a UI change where we’ve shipped it ASAP, we’ve caused issues. I’m all for release early, release often; i’m all for an agile methodology; but that way of thinking requires a lean model where you release the Minimum Viable Product every time possible. This is not the MVP of 3.6.
We need to get out of Developer mode and into release management mode. Thats incredibly hard for amazing developers to do. it’s so hard to say, damn it we’re close but it’s just not ready. But we’ve been here before, lets learn some lessons (Capital P Dangit… Inaccessible menus in 3.3… inability to log out without a mouse in 3.3 and 3.4 etc etc).
-
Samuel Wood (Otto)
Sorry, you lost me when you started talking “agile” and “scrum” and all that other nonsensical project management stuff that I kinda don’t care anything about.
I’m talking about this specific case. Not a methodology. Not some buzzword-heavy stuff that is, IMO, completely meaningless to real-world software development. I don’t subscribe to any of that jazz, and am totally uninterested in arguments based on it.
For this specific case, at this specific time, the UI seems quite good and only needs some minor improvements to be polished enough to be usable. That’s what I’m saying. Is it worth delaying a bit to finish it? I say “yes, it is”.
If you have arguments relating to that particular, I’d be happy to listen to them. I’m a coder, I speak as a coder. I don’t do project management, nor have any opinions based on it.
-
Konstantin Kovshenin
+1 billion.
-
kevinjohngallagher
I’m a coder, I speak as a coder. I don’t do project management, nor have any opinions based on it.
Totally here you. So can I ask then, WHO IS THE PROJECT MANAGER?
Is it worth delaying a bit to finish it? I say “yes, it is”.
Cool. When you say “delaying a bit”, how much is “a bit” ?
10 minutes? 1 day? 1 year? 1 month? 1 week?
-
-
Mel Choyce
+1. We’ve already made good strides improving the usability of the post formats UI, and I think with some further tweaking and testing we can get it done for 3.6.
-
-
nathanrice
Not that anyone is taking a vote, but as was mentioned earlier, I really don’t see why Links was removed, but post formats needs to be a core feature.
Or if it MUST be core feature, why the UI needs to be exposed to users with themes that don’t DO ANYTHING in particular with the data, or to users who don’t need, or don’t want, post formats or the associated UI to be part of their publishing experience.
Or if it MUST be forced on users regardless of whether their theme supports it or they want it (ugh), then why does it HAVE to be part of 3.6? I’m not even sure it’s conceptually sound, much less functionally sound.
So I’m with Matt, there’s good reason to make this into a plugin, test and iterate, get feedback, and maybe one day it makes it into core.
-
Mark Jaquith
The concerns here seem relatively minor, and can be addressed with a few small tweaks. The treatment we have now tested very well (whereas the one in beta 1 did not).
I was going to make this point, but I’ll just quote Ryan:
Punting often requires major surgery that can be as much work as finishing the feature.
This is absolutely the case here. It it were a matter of removing a file and shipping an RC, that might be a different conversation. If people are willing to help out, we can get these tweaks done tomorrow and ship another beta.
-
Knut Sparhell
How much work is it to remove the new post formats UI from trunk? This has to be compared with the work that remains to make the feature and the UI great.
Do another iteration on the UI presented here, before making a decision. You guys in the post formats team have done so much great work. It’s already 90% perfect.
-
-
bobbingwide
Simple question. Is there an approved design for the post formats UI? Failing that, documentation on what each post format is supposed to do and how it does it.
-
Tom Auger
Hi Jen, thanks for this post. I also agree the the current UI is confusing, but I also really like it, AND I also agree with others who point out that changing a post format once the post has been started can be a Bad Idea. Our UI should allow, but not facilitate any workflow that involves changing the post format after the fact.
So:
1. When you create a new Post, the input fields are all greyed out until you select one of the post formats.
2. Once you have selected a post format, the currently selected post format icon remains lit up, and aligned to the left, just above the title. The remaining post format icons collapse under (and behind) this icon – in other words, they disappear.
3. Where the strip used to be, we now have the text that says “Change post format”.
4. Clicking this link invokes some kind of confirmation that essentially says “data could be lost”.
5. Clicking the confirmation brings back the Post Formats ribbon, while greying out the other input fields again.The only thing I don’t like is if you want to just get in and write a Post post, you still have to click on the “Post” format icon before you can get started. One solution would be to enable a third-level flyout on the “New Post” menu item that lists miniature versions of the post format icons, so you can jump right into creating the type of post format you want.
-
Mark Jaquith
Clicking this link invokes some kind of confirmation that essentially says “data could be lost”.
It isn’t lost, actually. I don’t know if that changes your thoughts on anything. Whether or not the choosing UI should be always visibile is pretty much the last big decision to be made.
-
mindctrl
The old UI was always visible. That’s not to say the new one has to follow suit, but the current sliding out of view is awkward. I’d prefer it stay visible, highlight the current selection (color icon for active?), and ditch the “change format” text link (which BTW is disconnected from the previous format choosing location).
To repeat an earlier statement about image post format, the “Link URL” box is confusing at best. Nothing there that suggests “this is the place your image will link to”. Also, I’d guess that most people will be interacting with the media library “Select/Upload Image” far more than the “Image HTML or URL” box. Something should be changed there. The latter is far too prominent, imo.
The “Image HTML or URL” box is very large, almost suggesting more than one URL can be pasted. However it doesn’t work if you try it. But more importantly, if you paste a long URL and decide to erase it and replace it with another, the box totally disappears. (I should add this to Trac).
-
-
Brent Logan
I disagree that changing post formats is a bad idea. I use post formats and change formats *all the time.* Here are some examples:
1. An image in the post becomes the point of the post so it changes from standard to image.
2. An aside becomes a status and maybe back again. (I have changing definitions, for what is what.)
3. A gallery gets culled to a single image.
4. A standard becomes a quote.It’s really no big deal to change formats. At least, it shouldn’t be. The tabbed interface used by FavePersonal is easy to use, shows the current format, and makes it easy to switch between formats. http://crowdfavorite.com/wordpress/themes/favepersonal/
Sure, not everyone is going to want or use post formats. Give them an option to hide the UI. But for those of us who are waiting for this, make it easy to switch, please.
-
-
Franz Josef Kaiser
After reading that MP6 will be integrated/finalized for WP 3.7, I can’t understand why the post formats UI was ever proposed for 3.6. When we already got a new UI in the line, why not introduce new features right when we got it? Would lower the needed UI work, would integrate better, would be more consistent.
For now just pulling the UI (or post formats completely) out of core and delivering it as plugin that “does phone home” to provide feedback sounds like the only right decision. +1 for that idea.
-
mor10
I just demoed the current iteration of the Post Formats UI to someone unfamiliar with WordPress but familiar with online publishing applications in general. This is what he said:
“Based on the UI, my assumption would be that I could write an article and when I wanted to insert an image, a quote, a gallery, a video, or whatever, I just hit the appropriate button above and the fields that show up allow me to do that. What actually happens is not at all what I anticipated.”
I think there are several issues with the way Post Formats have been implemented in general and how they are presented here, but the most important thing right now is that there is an assumption new users will automatically know what post formats are. The way they are presented doesn’t give any indication of what they are or how they work, and the interpretation of my friend is far more intuitive than the one being assumed by proponents of the current UI.
-
Matt Mullenweg
I was thinking about this a lot yesterday, and it could actually be an interesting approach to a next-gen editor if you think of a post as a series of blocks some of which are full-width and some of which are pulled to the left or right with the text flowing around them. These blocks could be a quote, image/caption, video, gallery of several images, slideshow… with the first two covering 95% of what frustrates people when trying to “lay out” posts. Imagine it a bit like the Storify creator, or a TGD story, or post on Joen’s blog, though there’s probably a better example of what I’m talking about out there somewhere.
-
Mike
There are quite a few “block” CPT plugins (or one could roll his/her own CPT) and with the Display Posts Shortcode plugin (for example) it is easy to insert these into posts.
Another option is to go back one step to the Media CPT features and re-design the approach to inserting media elements into posts. This would extend existing core technologies that already offer quite a bit and preserve workflow traditions.
It comes down to what is desired out of the box. I like Beta 1 with a settings option to disable the new GUI (similar to turning off the Tool Bar).
While it’s not perfect (what is?) it would be great to take an holistic approach to an overhaul of the edit post page that re-examines what’s there and reconsiders how to approach extensibility going forward. -
mor10
I recently worked on a site where we did something very similar: instead of displaying images, video, and audio mixed in with the content, these elements were pulled out and placed in the area usually used for the sidebar. It worked especially well with image galleries because it allowed us to display the images in larger sizes with full captions. There is something there for sure.
-
-
-
Matt Mullenweg
I know it’s not fashionable at the moment, but we should include the Press This posting screen in our support for formats if we’re going to do it right in a core release.
-
KirkM
As a veteran user of WordPress and chronic (albeit quiet) WordPress beta tester, the only real thing I find confusing about the new post format layout is that there’s nothing there to tell the user what exactly those icons are for. Okay, so it may seem obvious to some but in real use, it ain’t so obvious. But this has already been said.
From my point of view, some added text, above the post format icons, that simply stated something like “Choose your Post Format” or “Change you Post Format” or simply “Post Formats”. Anything that will tell the user exactly what those buttons are for. You could even add a “Learn More” link after the post format “title” that opens a page in another browser window/tab that briefly explains what each post format does and what it’s used for. But for the now adding description “title” above the post format icons would be enough?
-
paaljoachim
I just do not get it. Why of why have multiple post types, when all one needs is one post type.
There is a toolbar above the content area that the group could have spent time on improving. For adding media there is the Add Media button. Everything else there is the existing toolbar and the toolbar needs improving to make creating and adding content easier and better looking.I did see the http://wpusertesting.com/videos/DC7-7.mp4 and totally agreed with how she did things. I do believe that most new users will also create posts in a similar way.
The more options available the more confusion the result can be. One Page type and one Post type seems like a good option to me, and then make the toolbar for adding/editing content amazing easy to use.
-
ezhil
The current post format reminds me of tumblr interface. wordpress is mostly used as cms and for regular websites. This post format would typecast wordpress as a personal blogging s/w. i hope we can add a settings option to enable/disable this so that it would be usefull for people who wants it.
-
Jeff Cohan
I know I’m late to the party. And all of you probably have more WordPress knowledge in the tips of your pinky fingers than I do in my old brain.
But here’s my $0.02 on the issue of POST FORMAT CHOOSING/SWITCHING:
Forget icons. Forget tabs. Put the Post Format options in the “Publish” meta box, after the “Published on” section. Make it work like the “Status” and “Visibility” options: a select menu with an “Ok” submit, which causes the UI to display the pieces appropriate for the selected format. Default (obviously) would be standard.
For users who don’t know/care about Post Formats (yet), the choosing/switching function would be out of the way. For those who do, they know where to get it.
There. I said it.
-
-
Jen Mylo
GSoC 2013 Update
We have been accepted as a mentoring organization for GSoC 2013. I’m already being bombarded by overenthusiastic students with questions, so we need to get our act in gear re mentor list and project list more or less now. Definitely by tomorrow.
IF you have worked on an assigned feature team in one of the last few releases, you can be a mentor, yay!
IF you haven’t worked on an assigned feature team but you’ve had multiple patches accepted in one of the last few releases, you can be a mentor, yay!
IF you have themes/plugins in the .org repo and the lead devs say your code is good, you can be a mentor, yay!
IF you don’t meet either of these criteria but think you’re skilled enough and want to contribute, I need to have your code vetted by the lead devs.If you are in one of the “yay” categories, please add yourself to the mentor list at http://codex.wordpress.org/GSoC2013 and leave a comment here saying you did so. Then, go to http://www.google-melange.com/gsoc/org/google/gsoc2013/wordpress, scroll down, and follow the process to apply to be a mentor in the gsoc system. Note that it’s a little bit busted right now, so you might not get a confirmation back from me until they fix the existing bug there.
If you are in the maybe category, you can ping me in irc, comment here, or email ([my username/irc nick]@wordpress.org) me to get on the list of potential mentors that will have code reviewed by the leads.
Also, project ideas can be added to the wiki page as well IF you fall into the pre-approved to mentor category. Worth running ideas past the leads in irc for a gut-check first. Other ideas can be posted here for review.
Thanks!
-
Eric Mann
The Codex article looks to be a copy-paste of the last SoC one … including ideas and the mentor list. Is it going to be cleared out? Should we hold off ’til then?
-
Jen Mylo
That’s exactly the point. People were so busy trying to make the beta release, there wasn’t really anyone to help on that page. The mobile stuff is all new, and I pulled some old stuff, but since I wasn’t getting much response from previous call for help, I reused old stuff so that we wouldn’t be rejected. We now need to update it to only have stuff people want to mentor and people who want to be mentors.
-
Eric Mann
OK, I’ve moved over my potential idea from the previous GSoC page om Make.core and updated personal interests (since I was already on the confirmed mentors list). Are you acting as the point person this year? I’d like to offer to help clean up the list if you need it.
-
-
-
Marko Heijnen
I had the same feeling.
-
Jen Mylo
You are not wrong. Please help update the wiki page with new ideas and all will be well with the world.
-
Marko Heijnen
Will looking into it in the next day. I did put myself on the list as mentor.
-
Jen Mylo
Great, thanks!
-
-
-
-
George Stephanis
Added.
-
George Stephanis
Also, the signup 500′d me. http://cloud.stephanis.info/image/130r1p2s2s0Q
-
Jen Mylo
You need to create an id first. Yes, it’s dumb. Also, stuff is broken.
-
George Stephanis
Now it prompted me to open a connection? So I think it took?
GSoC project: Fix GSoC codebase.
-
Jen Mylo
That’s the Melange project. And ironically, this bit that’s messed up? A GSoC project from last year.
-
George Stephanis
D’oh!
-
-
-
-
-
Alex
Some points on the list already have been coded in 2011. Are they intended to be coded again? I am looking for a project so this would be good to know
E.g. template versioning, move, language packs and enhanced emails. Some of those are outdated and do not work with 3.5.
https://code.google.com/p/google-summer-of-code-2011-wordpress/downloads/list-
Jen Mylo
The list is currently being updated, per the post and comments above. Some projects were done by students but not rolled into core, while others aren’t relevant anymore. We are doing an updated list today, and will post more information for students, including some scheduled IRC sessions for questions, later today.
-
Alex
Awesome, thanks!
-
-
-
Norcross
Got the email, and (after viewing the source) I found the link. I was signed up with a different Google Apps account so it’s not sync’d with the email address you sent it to. Should I just delete the old profile and make a new one? (they don’t seem to offer a way to fix it otherwise)
-
Jen Mylo
Alternately, go to http://www.google-melange.com/gsoc/org/google/gsoc2013/wordpress, scroll down and click apply to become a mentor and use the id you want to use.
-
Norcross
FWIW I also emailed Melange directly to see if they can fix it. Otherwise I’ll just use the profile I made.
-
Jen Mylo
It’s already in their issue tracker. I spent several hours in the #melange irc channel yesterday identifying bugs that were and weren’t already known. They are basically all known. I have no idea why they they didn’t just delay the announcement a few days to give them time to fix stuff.
-
Norcross
Gotta love it
They emailed me back quickly, and deleted my profile so I could make a new one. Did that, and did the ‘become a mentor’ link as well.
-
-
-
John James Jacoby
I am pretty sure I have two Melange accounts now, too. My new one is ‘jjj’ because ‘johnjamesjacoby’ was already taken, even though when I tried to login or reset my password, it said it could not be found. Annoyed, but still excited about GSoC.
-
Jen Mylo
I can try inviting the other name to see what it says. Alternately, hop into #gsoc or #melange on freenode in irc and ask someone to check it out for you.
-
-
-
Justin Shreve
Applied as a mentor under melange. So much excite!
-
Daniel Bachhuber
Applied as a mentor under melange (I think), and added myself to the possible mentors list.
Have to share this gem: https://www.evernote.com/shard/s2/sh/d87d31b9-792f-4993-a84c-d2d717a802fc/d284672fdefdbf8c7bce65c24cb18c4a
-
Daniel Bachhuber
Oh, I spoke too soon I think. Here’s the “success” message I got: https://www.evernote.com/shard/s2/sh/6de8aa96-943e-4e71-b63c-66626697888f/730cbe0f45ff51ee6de14f4f346e70f0
Did anyone else run into this?
-
-
-
Jen Mylo
GSoC 2013
It’s time for us to apply for GSoC 2013 if we want to participate. I can take care of the application, but will need everyone’s help in producing the project ideas and mentor sections.
“Why didn’t we get accepted last year?”
We didn’t get accepted last year because our Ideas page wasn’t as good as it had been in past years, and they wanted to make room for some new orgs, so we got cut. Our ideas page wasn’t great because we were planning to embed students in regular cycle feature teams, but we didn’t write up all the potential features this might have included. This year we need to write out all the possible features.
PROJECT IDEAS:
The more project ideas the better, so things that aren’t targeted for the next cycle but that we might want to do as a plugin to get some traction for inclusion in a later release would be great projects, too. Project ideas can include core features, plugins, themes, unit tests, etc. This includes work on .org site things like the plugin used to power WordCamp sites. The projects must be code, though, not design, documentation, etc. List your project ideas in a comment on this post. Please give it a title, and a short one-paragraph description. If there’s a ticket or relevant thread somewhere, link to it.
POTENTIAL MENTORS:
Want to volunteer to be a mentor? You need to be good enough with wp coding that you currently don’t need oversight to generally get it right (though obviously we all can get better with more eyes on code), and have enough time to be available to your student for feedback and code review (at least once per week, though more often is better). The time commitment can be anywhere from one hour to ten hours per week, depending on how far along your student’s project is, and what there is for you to review (an hour or two a week is typical). You get a GSoC tshirt at the end. Want to be a mentor? Leave a comment on this post with a short/one-paragraph little bio about yourself, what kinds of projects you are interested in/qualified to mentor, and links to your website, wordpress.org profile, and twitter account.
LEAD DEVELOPERS:
I know you are right smack dab in trying to get this release out, which is why I’ll take care of the application and associated materials. That said, I’m a bit out of the loop with core plans, so coming up with the potential projects list on my own would mean they might not mesh with the actual goals/plans of core team very well. I’ll be looking to you guys to give me a sense of priority/possible plans for the next dev cycle, and to tell me who is qualified to mentor a project from the final list of volunteers. Will ping you offline for this.
Not sure how to write up a project idea or your short mentor bio? Take a look at the ideas page from 2011 for a guide.
Note 1: This year BuddyPress will be applying as a standalone organization with WP as the vouching organization. I’ll be helping Paul Gibbs get their application going.
Note 2: I haven’t announced it yet since it just happened, but we’ve been accepted as a mentoring organization for the Gnome Outreach Program for Women for the summer session. Unlike GSoC, where Google foots the bill, we’ll have to raise the money to cover our interns for the Gnome program, so I’ll announce it along with a fundraising drive. The Gnome program is a little broader than GSoC, and does allow non-code projects, so things like design, ux, documentation, translation, community management, etc would all be possibilities there.
-
trishasalas
Jen, I appreciate all the work you (and others) are putting into this. I’m fairly certain I wouldn’t qualify as a mentor (at least this year) as my WordPress coding knowledge is just now starting to solidify. However, I would like to know what I can do to prepare for future involvement (if anything). I would also be interested in learning more about the Gnome Outreach Program.
-
Eric Mann
I have a few ideas …
Idea 1: Dashboard Widget API
We have a great widget API for sidebar widgets, but the admin dashboard widget API is far less reusable. Certain widgets rely on the same code (i.e. feed widgets) without a clean abstraction layer to prevent changes to one from breaking another. This is one of the biggest reasons #19239 hasn’t gone anywhere yet. Merging the widgets required some hackery and the new widget in that proposed patch isn’t abstracted enough to be reusable anyway.The idea would be to create a basic object template for dashboard widgets that can be extended in the same way WP_Widget can be, then to revise existing dashboard widgets to use the new API.
Idea 2: Post by Email Plugin
Deprecating the post by email functionality has been on a list of proposals for quite a while, and despite a patch (#22942) that disables the feature (similar to how Links were recently disabled), momentum has stalled since no clear alternative exists.The idea would be to create a new plugin that extends post-by-email functionality in a clean manner. Host the plugin in the .org repo. Then update the existing patch on the above ticket for 3.7.
Idea 3: UUID Abstraction
One of the most talked-about “vulnerabilities” in WordPress is the ability to slurp down user IDs and login names programatically since user IDs are auto-incrementing integers. This could be prevented by changing the data structure to use UUIDs instead.Also, updating post data structures such that new posts populate the GUID field with a true UUID (rather than the current post permalink) would prevent a lot of developer confusion as to what the field is and how it’s used. (Regular post IDs should remain integers since they’re used in the default link structure.)
Other objects in the database can be rekeyed as UUIDs as well, but my proposal is to start with user IDs and post GUIDs since changes there would solve specific problems that exist today.
-
Eric Mann
Just to clarify, I’m willing and capable of mentoring any of these projects. I’ve worked with data abstraction in the past, and I wrote the first patch approaches for the two linked tickets above. For anyone unfamiliar with me … I’m @ericmann on Twitter, WordPress.org, and just about everywhere else. I also speak at WordCamps, moderate the WP Stack Exchange, and geek out on WordPress projects for a living.
-
-
jltallon
Idea N+1: Plugin/Theme dependencies in core
Work can begin from Scribu’s plugin +improvements ( Debian-style version comparisons: >=, >>, <=, <<, =), there is a proposed patch out there.
Second step: Theme *code* dependencies: just like parent-child relationships are declared within the style.css (child themes), themes that need certain plugins to work properly (not enhacements, but hard dependencies) can declare so in a comment at the beginning of functions.php
RATIONALE: just like plugins can declare "Depends" and "Provides" within their meta information in the plugin's header comment, themes can depend on certain functionality from plugins.BENEFIT: ability to "mix and match" code and allow for more modular code. Individual, granular updates to functionality via plugins, where all other components benefit from the upgrade without intervention.
BASIC FUNCTIONALITY:
- Plugin needs certain other(s) plugin(s) to be active before this one can be activated (or at the same time, think “bulk activate”) + feedback in the plugin screen (Depends: plugin1, plugin2) with colors.
(thisi is basically the functionality present in Scribu’s plugin right now)
- Plugin needs certain other plugin and version (equal, newer, older) to work.
- Theme needs certain plugin(s) (and particular versions, while at that) to be activated. Clearly show it at the theme selection screen (just like “theme tags”, maybe?)
- When a dependency is deactivated/removed, all dependent items (plugins, themes) SHALL be deactivated in turn (for a theme, fallback to “default”)
I’m proposing this for a GSoC project since I guess it would need quite some more work over what we currently have, and It would need a close eye before it can go in core (where it belongs, IMHO)
-
petarpetrovic
IDEA: REWRITE WORDPRESS’ CODEBASE TO BE FULLY OBJECT-ORIENTED
I have been using WordPress for a long time, but, sadly, I’ve never contributed any code to it. The main reason for that is that WordPress’ codebase is not fully object – oriented. I know that someone will say “don’t fix what isn’t broken”, but I really think that rewriting the codebase would be extremely beneficial for everyone. It would make a much cleaner API for plugin developers and it would be easier to maintain the codebase. I’d like to work on this through my GSoC participation. For the beginning, we would have two API interfaces – the current one which will become deprecated after the rewrite has been done, and a new one which will allow all plugin developers to gradually switch to new API as the time progresses. Then, say, in WordPress 4 the deprecated API would disappear (or we can provide some sort of plugin for the deprecated API) and a new, OOP – way API will be in place. I know, rewriting the whole codebase can break many things, but no one said that the transition won’t hurt.
-
Jen Mylo
Rewriting the entire WordPress codebase is completely outside the scope of a GSoC project, which should be discrete, easily tested, reviewed, and launched.
-
-
Justin Shreve
I’m interested in mentoring this year!
For those of you who don’t know I’m Justin Shreve. I’m a former GSoC student (2009, 2010) and co-mentored Summer 2011(with Aaron as lead mentor) the HTML Emails project. I also work on social projects over @ Automattic.com
I’d be interested in mentoring any general projects but specifically: API projects (XML-RPC, REST/JSON API in Core, etc), Projects around things like Post Formats, Multi-site improvements, and any social projects (if there happens to be any plugin proposals, etc).
Website: http://justin.gs/
.org profile: http://profiles.wordpress.org/jshreve/
twitter: https://twitter.com/justinshreve/ -
Marko Heijnen
I would love to be a mentor on one of the projects. I’m can work on Media (no backbone yet), mobile projects and on the API. Maybe a RESTfull API. But any other related project is fine.
I’m @markoheijnen on Twitter, WordPress.org, and just about everywhere else. My site is http://www.markoheijnen.com and I speak at WordCamps and WordPress meetups.-
Jen Mylo
Can you write up a couple of specific project ideas with short descriptions, as shown on the codex page from 2011? That would be a big help.
-
-
Prasath Nadarajah
I am interested in mentoring this year!
My name is Prasath Nadarajah and i did GSoC with WordPress back in 2011 working on the new XMLRPC API. I work at Automattic as a code wrangler.
-
-
Jen Mylo
Will need two volunteers to be the admins for GSoC, overseeing our application, mentor wrangling, and if we get selected, student wrangling. Good project management skills required, familiarity with core contributors a plus. Note: though most mentors will likely come from this group, it’s not my intent to pull devs away from development to be admins. Just posting here bc I know a number of project managers follow this blog. The admin volunteers would be coordinated via the community group and would work with devs across core, themes, and plugins as needed. If interested in volunteering as an admin, ping me. Thanks.
-
Jen Mylo
Contributor Stats
Going to be working on a project around stats for the contributor community, something at which we currently suck (even creating the list of people with props each release is still a fairly manual process). For the sake of this exercise, ignore the voice in your head that thinks, “There’s no way to gather that information,” or “We’d need a new API for that,” and just brainstorm. What stats would it be cool for us to have about the activity of core contributors? Leave your ideas in the comments, and they’ll be cobbled together into a big list that I take to Otto to see what’s possible (at which point Nacin can start daydreaming about APIs, but not until then).
-
Jane Wells
Some of my ideas:
- Automated props list
- Number of props per person per release (plus high/low/average for most of these)
- Number of contributors with props in prior releases (43 1st time props, 26 2-releases, 66 3-releases, 12 4-releases, etc)
- Lines of code contributed, also per patch, also per person, also per person per patch
- Number of screens affected by UI changes
- Number of strings being translated (this one will be more of a polyglots thing)
- Number of hours spent on creating patches/reviewing and testing patches/running unit tests/etc by contributors
- Average time from ticket open to ticket close
- Average number of people commenting on a ticket
- Average number of comments per person on a ticket
- How many tickets each person created, how many commented on, how many uploaded a patch to
-
Helen Hou-Sandi
I’m not a fan of the lines of code metric – removal is just as valuable, and sometimes more so. I probably come out close to zero
-
Jane Wells
Sorry, imprecise language on my part. Because I’ve been indoctrinated so well, my “lines of code” is shorthand for “lines of code changed,” not “lines of code added,” so removal/cleanup patches would still count based on lines affected.
-
-
Benjamin J. Balter
- Number and Percentage of first time contributors
- Number / Percentage of personal time versus contributing for work
- Number / Percentage of Automattician contributions
- Number / Percentage of core team vs. community contributions
- Number of people who opened their first ticket ever
- Ratio of tickets opening to tickets closing
- Velocity
- Number of plugins created
- Number of commits to plugins
- Number of contributors added to plugins (immagine this is super-low)
- First time plugin creators
- Number of plugins that haven’t had a commit in X months
- Number of plugin support forum tickets opened
- Number of forum comments
- Number of tickets closed
- Open / closed support forum ticket ratio
- Number of posts on dev blogs
- Number of comments in dev blogs
- Lines in IRC
- Number of first timers in dev chat
- Number of flame wars on twitter
- Number of posts on nacin.org
- Running average of all of the above to baseline (e.g., this release had N fewer contributors than average)
-
Jane Wells
Hey Ben. This one is just for core. Stats on plugins etc are being brainstormed on those make/teamname sites.
-
Scott Taylor
I like the idea of a historical leaderboard. Number of patches committed historically plus last commit date would separate “was active” and “is active.” I ran some perl / grep / sed earlier in the year to see how many patches Sergey had committed and it blew my mind. Also, I like the idea of distinguishing who works for Automattic-like companies and who doesn’t. If your job is *core*, it’s a lot easier to crush it every release than the people who are using 100% of their spare time to do it.
-
Matt Mullenweg
In terms of what can be extracted from SVN, Ohloh has some interesting stats for WP:
http://www.ohloh.net/p/wordpress
They also have some interesting historical data, like in Dec 2007 our codebase was 34.5% Javascript, Dec 2012 we’re about 19.6% (lines of PHP has increased way faster than lines of JS).
-
Andrea Rennick
OoooOOOoooo those stats are drool-worthy!
-
-
Aaron Jorbin
Number of people reporting bugs
Mean, median and mode of number of bugs reported by a person
Companies that contributed employee time towards WordPress core (and the number of hours per time period (not sure if per month or per release is a better metric here)
Number of patches submitted per ticket
Days between posts on nacin.com
Number of core contributors who don’t run there own blogs on WordPress -
Andrea Rennick
Contributor status over releases. Like, if someone was around for 3.3, but not for 3.4 and back again for 3.5
And attrition rate – do people drop off or ramp up? Why or why not?
How many tickets or patches does one file, on average, before they get props that go in?
-
-
Jen Mylo
Team Reps
Heya. Now that we know Mark will be the release lead for 3.6, on with team rep voting results.
Part of why I wanted to wait was because the people with the most votes were Nacin and Jaquith, and I suspected Jaquith would be leading 3.6 (so he shouldn’t be team rep also, per earlier discussions).Core team reps: @nacin and @scribu. Woohoo!
Term begins with the new year and goes through June.
-
Jen Mylo
Antsy for 3.6 to start and need a project? Who wants to make an official importer for the new Twitter archives? Would think we’ll want to add that into the importers list. Would suggest importer auto-assign “status” or “aside” post format (or make it an option in the plugin to choose format). Who’s in? I volunteer to ux review and test.
-
Aaron Brazell
I already was planning on doing this as a plugin, and I’ve been quiet for awhile. I can do this. But… I need to have the archives available to me, and my account doesn’t have it yet.
-
Jane Wells
Mine either, but I’ll see if I can wrangle one we can use.
-
Ryan Duff
Or as soon as someone gets and volunteers a copy of their archive. From the post it doesn’t seem there’s an api, but a set of html pages + xml, or json files (pick your poison)
Also, from what I’ve heard they files are monthly, so if you’ve been on Twitter for 4 years you’d be looking at 48 json files to handle w/ an importer.
Of course that’s all based off what I’ve read. I don’t have it yet. Just something to chew on.
-
Aaron Brazell
Yeah it’ll be an interesting challenge but I wanna see what the data looks like first. If they turn it on for me, I’ve got 6 years of archives which would be a good stress test too.
-
Andrew Nacin
Could handle the zip that they send you as-is. In fact, I imagine that would be the best approach for users.
-
Aaron Brazell
I feel like we need to be able to parse the HTML, CSV and JSON in any zip file if we approach it that way. From the user perspective, I think you’re right but I sure hope the CSV and HTML are decent enough.
-
-
-
Samuel Wood (Otto)
It’ll just be a matter of iterating the json. Simple stupid, for the most part.
-
-
-
Samuel Wood (Otto)
If they actually roll it out to people unchanged, then it should be fairly trivial. When I get it on my account, I’ll let you know.
-
Phil Erb
When archives are available to me, I’d love to help test.
-
Andrew Nacin
We now have an API for importers, which means we can add this to wp-admin/import.php the moment it is done.
When anyone gets access to their zip, please share it (or at least a sample so we can learn the format).
-
Aaron D. Campbell
Looks like my account has the option. I’m requesting an archive and will post it somewhere to use.
-
Aaron D. Campbell
Looks like it comes down to a bunch of poorly formatted CSV files. Here’s what they sent me: http://s.ran.ge/0o2F011v3I2p
The CSVs don’t quote data, so commas in the tweet will be a bit of a pain. However, since it’s ID, time, tweet you can probably just process the ID and time, then assume the rest is the tweet (trimming the strange trailing comma).
-
deltafactory
I’d be curious to peek at the format. Your link is broken – not sure if that was intentional or not.
-
Aaron D. Campbell
Sorry about the broken link. I uploaded the export to the Trac ticket: http://core.trac.wordpress.org/ticket/22981
-
-
Jane Wells
I mentioned to Ev that commas in tweets was requiring some hackiness.
-
Pete Mall
We don’t have to worry about it since we are using the JSON instead of the CSV.
-
Alex Mills (Viper007Bond)
True, but still a bug. Delimiters in CSVs need to be escaped.
-
-
-
-
-
Myatu
Wouldn’t it be more sensible to have this as a 3rd party plugin, rather than having to maintain more bloat?
-
Peter Westwood
It will be a plugin anyway not in the core download – all the importers are plugins now.
-
Myatu
Actually forgot about that! Shows how often I’ve used that feature. I stand corrected
-
-
Jane Wells
As @westi states, all importers are plugins, not core code. I didn’t specify that in my post, since I took it as a given that core developers know that.
-
-
Simon Wheatley
Note that the current Twitter IDs overflow (?) and corrupt if you convert them to integers on a 32bit system. That one has got me before. (Apologies if that’s teaching everyone to suck eggs.)
Also, would you mind putting in a filter for the post data before save… I’d prefer to store tweets in a custom post type. Ta!
-
Brad Williams
Was thinking the same thing regarding CPTs. A filter would be perfect
-
-
Andrew Nacin
I’ve outlined a potential plan for such an importer on a Trac ticket: http://core.trac.wordpress.org/ticket/22981. If you want to continue to discuss the idea, feel free to do so here. Implementation can occur on the ticket. (This is a plugin, but an official importer is also a core priority, hence the use of core trac.)
I’ve also uploaded a tweet archive contributed by @chadhuber to the ticket. It does contain sane json.
-
Pete Mall
@aaroncampbell and I worked on the plugin yesterday. There’s an early patch on the ticket already. I’m working on it today and will add an updated patch eod.
-
-
Beau Lebens
In case it helps, I already made one, packaged in here: http://wordpress.org/extend/plugins/keyring-social-importers/
-
Pete Mall
Looks like we should be able to use your “parser”.
-
-
-
Jen Mylo
Went to tally team rep votes and only 9 people voted, none of whom had actually contributed to core. I
I just re-opened the voting survey. If anyone who does actually contribute to core wants to vote for team reps, please do it today. I’ll close the voting again tomorrow. Thanks!http://wordpressdotorg.polldaddy.com/s/team-rep-vote-core-team
-
Japh
That’s odd. I voted, and I’ve actually contributed to core…
-
Jane Wells
Can you go and vote now? If you voted before, you didn’t put your name down (which is fine, just means I can’t see which vote is yours, and none of the IP addresses are from Australia, vs being able to see your vote as from Australia for the theme team vote).
-
-
Knut Sparhell
Q3 is a turn off. When not an “Active member of the core team”, but have contributed to the 3.5 cycle, there is no valdi alternative.
-
Jane Wells
If you contributed to 3.5, that makes you an active member of the core team.
-
-
Marko Heijnen
Thats weird. I also voted and filled in all my information.
-
Jane Wells
Knowing this I investigated more and found a filtering bug. Whew! I *thought* that was weird. We have 27 votes from actual contributors, enough to feel it’s representative. Will pass on the bug to the polldaddy guys.
-
Ipstenu (Mika Epstein)
Thank goodness. I was about to say ‘Hey, I voted!’
-
Drew Jaynes (DrewAPicture)
Yes, thank goodness. Same here.
-
-
-
-
John P. Bloch
Since it was requested that people volunteer to be considered, I was waiting for more people to reply to the original announcement post. It would appear nobody threw their name in the hat, though.
-
-
Jen Mylo
Team Reps for Core Team
I was going to wait until after 3.5 came out to post this, but since you all have the weekend free now, might as well take advantage of it, right? Time to vote for team reps again!
Right now there are 8 team reps for core team. Count ‘em, 8! (Counting them: Boren, Jaquith, Nacin, Koop, Aaron Campbell, Scribu, DH-Shredder, and Helen). We need to whittle that down to 2 so that there’s more balance with the other contributor groups. Much simpler voting this time around: just write down the names of the two people you’d like to see as team rep. From now on we’ll be doing these votes every 6 months so we can share the responsibilities and continue to grow new leaders.
Consider before you vote:
- People you vote for should WANT to be the team rep, since there are responsibilities involved. People willing to do the job can help voters by leaving a comment on this post saying they are interested in being a team rep this term.
- Team reps should not already be responsible for another group (and realistically, probably shouldn’t be the release lead, but that’s hard to guess at since the 6 months between team rep votes isn’t the same as the time frame for release cycles).
Easy-peasy, yeah? Voting will end on December 15, so vote before then, please.
Here’s a big, easy-to-spot link to the voting survey!
Longer explanation of team reps, why we’re voting now, etc after the jump if you don’t know the background or weren’t around when we did team reps before.
ezhil, 
Prasath Nadarajah, 
I love where the new post formats UI is going, but I have to agree with Jen about the confusion a lot of users are going to see. When playing with them last week, I caught myself asking some of the exact same questions Jen mentioned above, and I’m a “power” user.
If it is one or the other, I’d prefer to see 3.6 pushed back a bit so that it can still include the new post formats.