[wp-hackers] Re: New Posting Screen

[Owen Winkler]

After an evening to reflect on the position of things and hear Matt 
defend himself from all comers, I want to present my thoughts to the 
group for comment.


Matthew Mullenweg wrote:
> The current implementation ("unpleasantly long" load times) is 
> something that can be improved with time and iteration. (Much like the 
> original code for Kubrick was nearly unusable, but got much much better 
> with iteration even though the general concept stayed the same.) If 
> something *can't* be improved or iterated on, then it is worth 
> discussing the validity of the concept itself.

I'll admit to being the one responsible for the initial "unpleasantly 
long" comment.  I did test the code, and this was one of the things I 
left out of the report I posted on my blog.

It is very important to note that the underlying changes (which Matt 
points out) that prompted the javascript/collapsible interface are 
**such a good development event** that the collapsible panels are almost 
a footnote.  We can make the collapsible stuff better - prettier or less 
intrusive.  But something of this nature is going to be a requirement to 
support the underlying improvements in the posting interface.

For the uninformed, the new interface unifies the advanced and simple 
posting pages into a single code path.  This reduces the overall code 
used, which makes the code more stable and readable.

The major objection I have to the current codeset (not that it can't be 
improved) is that the interface is largely unusable until the collapsing 
javascript executes.  These extra javascript modules (Dojo, if used, 
will be a big offender) are rather large, and take a "while" to process 
even on my heftier desktop system.  It's a sore point in the code 
execution.  If we're looking for constructive criticism on the trunk 
code, my initial thought is that this needs to be much faster.

As far as the look of it goes...  I'm certainly no design expert.  The 
chief idea behind the javascript code seems to be "retain the old 
functionality".  This entails hiding the advanced interface by default 
and allowing the user to set their preference of what appears.  Indeed, 
the new interface does this *better* than the old, since you can hide 
and show the parts by default as you require, and these settings "stick".

> Before you get excited here, I haven't seen the code either! Someone 
> poke Owen. ;) I "delegated" that part of 1.6 to Owen because he had 
> already written a really excellent plugin for WP for media handling and 
> he was also able to grok the media model for WP. (The post/sub-post 
> thing that was discussed on this list ages ago but lost now because it 
> wasn't archived in a wiki or blog.) This is also part of me letting go 
> of aspects of development to third parties. As soon as I know more about 
> the code or get a peek at it, I'll let people know.

I actually sent Matt an email a while back with a few questions on this 
that I hadn't received a response to, and I stalled.  If you like, Matt, 
I will gladly write up the concept and present it to the list for comment.

I feel mostly responsible for keeping these feature additions under 
wraps, since I agreed with Matt's idea of having something to play with 
before letting everyone here pick over it.  I'm sorry that I've been a 
party to keeping potential players out of the loop.  If you have 
specific ideas about the media management components you want to discuss 
or suggest (and I am sure some will attest to my openness on this - 
skippy, mdawaffe, et al), please email me and I will happily discuss 
them with you.

>> If I want to "discuss" some major overhaul of WordPress, it's a little 
>> harder for me to get everyone to download and test it, regardless of 
>> the possible merits of my suggestion.
> 
> See and touch doesn't need to be core code, it can be graphic or HTML 
> mockups, or even just ASCII drawings like the other Matt used to do. In 
> theory plugins could do this as well, but your point is taken.

At this point I would interject a few items.  First, I disconnected from 
all of these WordPress lists and meetings for a few weeks while dealing 
with many issues, and I'm still not convinced that jumping back in now 
is a great idea.  But I see that WordPress the community needs some 
bolstering, and as it's really (sometimes sadly) the only cause I've 
been able to stand behind, I'm here right now.

That said, it should be obvious that I didn't get the memo about not 
writing about 1.6.  Oh well.  (In my defense, I wouldn't even have known 
about it if I hadn't seen Ryan's post in the Dashboard.)  I've received 
a lot of good comments about the new interface based on the animated 
screen shots I took.  To my recollection, nobody commented negatively, 
and I only received one question of, "Release date?"  As if I would know 
the answer to that!

I agree with the simple idea that Mike presents about sharing the idea 
of, "Here's what's going to happen with WordPress."  A 'heads-up', if 
you will.  That's why I didn't see any problem in writing my post, with 
all of the added caveats that a pre-alpha requires.  Although everything 
that I discussed was obvious from the SVN mailing list, it's often not 
apparent what a chunk of code does, and the notes that go with committed 
code are often too short to describe what is really going on and why.

After reading the replies here, I believe that Matt intended the commit 
of the new interface as a discussion point, not as something firm in 
stone that we'd have to live with.  There have been instances in the 
past where committed code has seemed to be beyond discussion, which is 
why I think everyone took the code commit as gospel.

Can we all possibly agree that the current 1.6 in SVN is a prototype 
rather than the actual deal?  That we're all going to get our chance to 
debate its merits?  It's better to see actual working code and 
understand what is in mind than discuss hypotheticals unendingly?  I 
don't intent to be snarky, but if you want the code to be different than 
how it is, you need to not only defend your position, but provide at 
least as much working code as your opposition so that others may weigh 
the merits of both options.

Assuming the SVN list/Trac describes an evolving prototype, and that it 
is still possible to rollback these changes, is that enough of a 
description of where the project is going?  What suggestions do you all 
have for monitoring the project direction?

Some minimal effort to get ideas flowing would be more than useful. 
"I'm starting to code X now, and here's my plan..."  Even I find this 
distracting from my style of just coding the solution freestyle, but a 
simple message like this would sure be useful to people who want to be 
in the loop.  Who knows, you might even get some great suggestions about 
implementation that you hadn't even considered.

Also, devs need to at least seem willing to roll-back changes based on 
thoughtful debate.  If it turns out that this collapsible thing is not 
feasible, we're going to need a suggestion to take its place.  Someone's 
going to have to code that.  I can understand the unwillingness to 
consent to roll back such significant changes, but provided that civil 
discussion results in good arguments against it, the option should 
always be available, at least until a Code Freeze (a topic for another 
time).  The idea for official polling on these contentious ideas is a 
good one, as long as we can all live with the poll results.

Is that enough commentary for today?  Why do I always write a book?

Owen