[wp-hackers] Compose Screen

[Owen Winkler]

Scott Merrill wrote:
> There's never going to be an interface that satisfies everyone.  I was
> shooting for "good enough".  Titles, timestamps, and post contents are
> what I consider to be fundemental elements of a post.  I more often
> change timestamps than I do post slugs.

I more often change titles and contents than timestamps.  I suspect the 
same is true for you.  It's just not something I would group so high on 
the page.  Post-dated posting seems like something Advanced to me.

It's not really a big issue to me.

>>>>* The 'existing timestamp' note needs to go; the existing timestamp is
>>>>the timestamp in the date/time form.
>>
>>What was the original reason for showing this?  Anyone know?
> 
> So you can see when the post was originally (set to be) published.

I was unclear.  The form fields already show this information.  So was 
there a reason why it was deemed necessary to do it for this field when 
none of the other fields do it?  (There's no "Current Post Slug")  If 
there was a reason, then maybe we should consider that in the design. 
If not, then chuck it.

>>As mentioned in the original note though, Pages will need to be
>>categorized.  The user should be allowed to choose a Page Parent for a
>>new Page.
> 
> Yes.  Should the page parent element only show up when the "Page" option
> is selected?
> 
> That might be a neat trick:
> left-align the type drop down, defaulting to draft.
> When "Post" is selected, the Post Password input becomes available in
> between the type drop-down, and the save button.
> Whent "Page" is selected, the page parent input becomes available.

Neat, sure.  Still, javascript has to degrade nicely, so those fields 
will both appear in a browser that has no javascript.

>>>Maybe if we could roll in "user levels" with private posts, we could
>>>keep "Draft / Page / Post", and introduce a new control to set the
>>>minimum level required to see the post / page.
> 
> Yes, and it's been a fairly frequently requested core feature.  It
> provides another benefit for registering to the blog.  Currently the
> only real benefit is to write posts.
> (I've not seen too many blogs that require registered users to post
> comments.)

Ok.  Using existing plugin code to implement this should be considered 
both to minimize development time and so that people already using the 
plugin will be minimally affected.

> Maybe instead of Ajaxing it, all the submit buttons _except_ SAVE will
> post all the page data (post, cats, title, etc etc) to itself, update
> meta / new-categories / etc, and re-display the form, with everything
> user-entered intact.  Make sense?

Yes.  Even if you do enable the form that way, you can still add Ajax 
for browsers that would support it.  It just has to degrade nicely.

[This is one of the things I never got about Ajax.  If you have to code 
everything so that browsers that don't support Ajax still work, then 
you're practically writing server-side code twice just to enable both 
the standard form submissions and the Ajax features that save you, what? 
  Forcing the user to reload a page by instead loading something in the 
background?  I'm still unclear on the true benefits of applying Ajax to 
a feature that isn't going to exclusively operate via Ajax.]

It will be difficult to add new metadata via Ajax to posts that have not 
yet been saved unless there is some ID already reserved for that post 
somehow.

> Hrm... I was about to say "In this way, only the SAVE button would
> actually commit the post to the database", but that won't entirely work,
> since post_meta requires a post ID... I'm sure someone can devise a nice
> solution to this.

It would be nice if the code somehow reserved a post ID before the Write 
page was generated.  Very nice.  Especially if you're trying to attach 
sub-posts or metadata to a post that is not currently complete.  Someone 
else please write this code because I'm tired of messing with it and I 
need it like a chrackwhore needs her fix.  Yes, I will totally do you if 
you hook me up.

> When you click "Save" in your word processing application, you're not
> returned to a main menu.  I think that clicking "SAVE" in the write
> screen should commit the data to the database, and return you to the
> same page, filled with the contents you just saved.

Makes sense.  It's usually better to emulate common behavior.  Although 
I do like when I click on "edit" on the published post and then Save 
after making changes how it returns me to the published post so I can 
see the results.

Owen