h1

HTML Draft of the new WordPress page list

June 16, 2007

I managed to put together a HTML/CSS draft of what the new page list should look like. It can be viewed in this link. Please note it’s only static HTML, and the “Save Page Order” still doesn’t do anything.

The list, that looks like it was done with a HTML table, was implemented using only DIVs and ULs. This effect was quite hard to achieve, because CSS positioning was actually not designed to do that kind of stuff. A lot of tweaking had to be done. Some extra tweaking also had to be done to make it work in both Firefox and IE7 (didn’t test in other browsers).

As discussed in my previous post, using HTML tables (like the page list is currently implemented in WordPress) would make it very hard to implement the AJAX sorting behavior. Nesting of table rows is not supported by HTML (ok, I could nest whole tables, but the resulting HTML would probably look nasty, and I am still not quite sure it would be usable with jQuery’s Sortable class – I will probably try it latter on).

This UL/DIV approach does have some shortcomes. First, the columns don’t adapt to their contents like in regular HTML tables (when there is big chunk of text). If you enter more text than would fit in its original size, some text will overlap. This could be a problem with extra long user names and page titles (a solution would be to truncate the text, with JavaScript probably). Second, notice that I removed the “ID” column, present in the original WordPress page list. I wanted an “auto-stretch column” for the page title, but I could have only one, and it needed to be in the left side (if you see how the HTML you will understand why). Also, since the left side column size will vary to show nesting, the ID column, being very small, would fall out of place and look weird. I intend to write the ID at the end of the page title (something like “Page Title (ID:12)“). It could also be in one of the fixed columns in the right.

If you use Firefox and try to change the text size (View>Text Size), you will notice the list will resize gracefully and nothing will fall out of place. This is thanks to the fact I used “em” as the measure unit in the CSS positioning code.

The javascript (jQuery) that implements “drag and drop sorting” was ripped from bbPress, with minor modifications. A lot still needs to be improved/adapted/implemented on it, but already serves as a “proof of concept”.

I believe the end result resembles the original Page list quite satisfactory. This approach allows us to add/remove as many fixed width columns as required, making it usable also for other parts of WordPress that require sorting. The HTML code is quite clean (although the CSS is pretty complex and not so easy to maintain).

Advertisements

4 comments

  1. Why does it have to be on the manage page page? Would it be easier to have a cleaner interface on another page, where you don’t have to conform to an existing table structure?


  2. @Matt:
    I agree it would be a lot easier to do it in another page. There is a plugin that does that (it is really nice, but uses scriptaculous and doesn’t treat hierarchy very well): http://geekyweekly.com/mypageorder.

    But does it make sense, “semantically” speaking, to put it in another page? I think it wouldn’t be very natural for the user and would pollute the admin with another page.

    Anyway, you guys are the bosses and I would stick to your decision, if you think changing the structure on the page list is too much. Also, it was nice getting some feedback from the creator. 🙂


  3. I can’t make a row a child of another row. FF 1.5.0.12/Mac

    Looks pretty though 🙂

    A separate page for this wouldn’t have to have it’s own tab in the menus. It could just be editp-pages?reorder or something and accessible from a link on Manage -> Pages.

    But I’m not sure it needs to be on another page. Why do we need to conform to the existing structure at all? Manage -> Pages isn’t nearly as pluggable as Manage -> Posts, so there are probably fewer things that will break.


  4. You are right, Mike, making a row a child of another is not working yet.

    Maybe, when the user pressed “Edit Page Order”, we could replace the legacy HTML table “on-the-fly” with a simpler UL based version, and, after the user pressed “Save Page Order” or “Cancel”, redisplay the legacy table again. I think it brings the best from both worlds together.

    It could be done with AJAX, without a page reload. Ok, maybe a page reload only after the user pressed Save, to redisplay things in the correct order. It really doesn’t make much sense for the user to have access to the ‘View’ and ‘Edit’ buttons while he is reordering pages, so we could make the UL based list cleaner.

    I am beginning to like this approach. What do you think?



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: