[wp-hackers] Compose Screen

[Scott Merrill]

Owen Winkler wrote:
> 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.

No, it's not a big deal to me, either; but I know a lot of folks do
twiddle timestamps.  As long as it's above the fold, I don't think there
will be a huge problem.

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

If you adjust the timestamp on an existing post, then move on (without
saving) to edit content, and finally (before saving) decide to review
all your changes, it would be nice to compare the original timestamp to
what you entered, without having to memorize it.

Either display the original, or provide a "reset" button, to restore
whatever was there before.

It would be super nice if this form could be a text form, allowing input
in the format the user has specified in their options.  That
significantly complicates things for little real benefit, though.

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

Sure; I can agree to that.  The postlevels plugin for fortes.com uses
post-meta, so we're not introducing any structural changes to the
database for this feature.

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

Some folks are hell-bent on keeping their post IDs in order.  Is there
any value to adding a new "drafts" table, which can hold all the drafts,
so people can use their post IDs without worry?

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

If you arrived at the edit screen from a published post page in the
non-admin display of your blog, then clicking save should preserve the
current behavior, and return you to the non-admin display.

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