[wp-hackers] Compose Screen

[Scott Merrill]

Owen Winkler wrote:
> Scott Merrill wrote:
> 
>> I was thinking how most posts are displayed on blogs:
>>    Post title, published @ timestamp by so-and-so
>>    in the following categories
> 
> 
> My published posts wouldn't be organized visually the same as everyone
> else's.  We wouldn't want to change the Write page for every theme. Best
> to organize the page by most significant details on top (title, content)
> and move everything else down or off to the side.

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.

Keeping all these elements in one horizontal row makes it easy to access
those items you use, and easy to ignore the ones you don't, without
wasting space.

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

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

>> 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.
> 
> 
> There are plugins that get most of this done.  For example:
> http://fortes.com/2005/01/22/introducingpostlevels/

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

> Remember, if you add Ajax-enabled stuff that it has to degrade.  So a
> sub-form that allows you to create a new category on the fly has to also
> work without the Ajax.  Ajaxifying the custom field form would be neat.

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?

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.

> Also remember that existing plugin hooks on these forms should continue
> working for the plugins that use them.  I don't see any problems yet,
> but it's something to note.

Ideally, yes; but I'm not entirely opposed to breaking admin plugins, as
long as we announce well ahead of time that the underlying structure has
changed.  Announce it early, publish the new functions / features, and
let plugin authors update.

> A question about the function of the Save button-  When you click it,
> what happens?  Does it return to the prior page?  Does it re-display the
> Write page?  Does it forward to the post itself?  Is it dependent on the
> option set for the post_status?

What do you want it to do?

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.

-- 
skippy at skippy.net | http://skippy.net/

gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49  3544 476A 7DEC 9CFA 4B35