Manage Mockup

[khaled Abou Alfa]

Well I've been playing around with the Manage section. Still got loads to do but it's just usually good to get it out so that I'm not operating in a vacuum and get people's thoughts about additional elements that I might have missed that could be important etc.

This is for the posts page which is comes from the top level drop down menu. Similar looking pages for comments etc would be used. The inline editor could be as complicated or as rudimentary as we want it to be. What I mean by that is we could keep the inline editor simple for quick fixes that most of us do say after a post and then have the title of the post on the far left be the link to the full page editor (which would include the media browser etc).

Khaled

[Owen Winkler]

On 2/25/07, khaled Abou Alfa <broke...@gmail.com> wrote:
>
> This is for the posts page which is comes from the top level drop down menu.
> Similar looking pages for comments etc would be used. The inline editor
> could be as complicated or as rudimentary as we want it to be. What I mean
> by that is we could keep the inline editor simple for quick fixes that most
> of us do say after a post and then have the title of the post on the far
> left be the link to the full page editor (which would include the media
> browser etc).

It's a neat idea, and it looks spiffy.

One thing we'll need to consider when building it is the burden of
potentially maintaining two separate codesets for editing posts - one
on the post page itself, and one on the Manage page.

Does the utility provided by the feature outweigh that burden,
especially if the editor isn't as functional as the full editor?
There may be other potential issues with allowing decentralized
editing in regard to plugins. For example, a plugin that adds an
extra field to the post entry page might hiccup when its data isn't
present because the field was not inserted into this other, minimal
editor.

Perhaps we can come up with a way to share code between these pages,
which would be ideal. Also to note is that inline editing like this
would require Ajax to function correctly, and users who have Ajax
disabled (by disabling javascript or whatever) will be forced into the
old method of editing anyway.

Just preliminary thoughts. I'd like to hear potential solutions for
these snags, because it's a darn cool feature.

Owen

[khaled Abou Alfa]

Ah yes, I see your point. I guess the idea of the quick edit is simply a thought that I only usually ever go and edit a post after I've just published it and have a skim and see a mistake. I understand the thought behind it being counter productive, but we can call it quits after we've got it working in the most fundamental way. We could include the function buttons (link, bold etc) in there but keep it simple. Sure we could include for hooks onto it for plugins but my immediate reaction is that by having it do more kinda makes it a bit redundant. It's more of a nice quick way to edit the content itself rather than all the stuff that's getting added on top of the post itself if that makes any sense.

Regards to AJAXing it up, I'm going to leave it up to those who know what you're doing. How are we going to be showing error messages for non-javascript enabled browsers? Are we going to have system messages that pop up or are we going to try and embed them into the interface as per the normal version, and if so how would we go about that? This basically will answer how we ask the user to either enable javascript on their browser or use the main title link to go to the edit post page.