r3822/3: New Sections panel

Bloke · 2012-06-22 14:35:03

Please test and report.

The multi-edit checkbox column moving to the left, and ‘toggle all’ checkbox at the top of the column will become the new position for all the list panels over the next few days. The multi-edit tools at the bottom of the table will go to the left accordingly, and towards the end of the standardization process, the ‘All/None buttons will probably be dropped as the functionality is not required since the checkbox in the header does it. The new ‘toggle’ button should help get those hard-to-reach things without masses of clicks on long list pages.

There’s a possibility the positioning of stuff is still not final yet (for example: multi-edit tools at the top instead of/as well as the bottom?) but on the whole I think this layout works well and is more mobile friendly too.

Feedback welcome on all this as we forge forward and migrate the other list panels. Thanks in advance.

Last edited by Bloke (2012-06-23 01:09:40)

philwareham · 2012-06-22 14:48:44

I’m toying with moving the ‘show details’ toggle to the top right side of the page, since we have some dead space there and it’s logical for the details toggle to be before the table itself. Maybe after v4.5 we could expand this feature to allow users to show/hide exactly the columns they want to see (instead of dictating to them which columns should be hidden).

My initial thoughts were to have the multi-edit manage fields duplicated at top and bottom of table list, but I’d like to hear user opinions on that. Obviously the more chrome we add to a page, the more cluttered it may become, which could have adverse affects on UX then we were intending.

EDIT: also, we are considering removing the ‘odd’ and ‘even’ classes from table tbody rows. Now that table layouts throughout the admin-side are tidied up this can be achieved with nth-child CSS rules by theme authors instead (OK, I know IE8 and below don’t support that rule but since it’s purely aesthetic we can accept that regression, right?).

Last edited by philwareham (2012-06-22 14:56:35)

Bloke · 2012-06-22 15:16:01

philwareham wrote:

I’m toying with moving the ‘show details’ toggle to the top right side of the page

OK. Any thoughts on the other ‘Show’ buttons like Show spam? Inline with the Show details at the top, or somewhere else?

philwareham · 2012-06-22 15:27:44

Probably inline. I need to mock it up and see.

I’ll also try to work out a solution to showing subsections in the sections table. For if/when that feature becomes a reality.

Looking at my TO DO list, I need to work on the installation/setup pages next.

Last edited by philwareham (2012-06-22 15:31:21)

Bloke · 2012-06-22 15:48:08

philwareham wrote:

Probably inline. I need to mock it up and see.

Oki doke. Will await your prognosis.

I’ll also try to work out a solution to showing subsections in the sections table.

If you can do it, fine. If not, then don’t worry too much about it. I’m kinda resigned to the fact that the best we can do is show a ‘parent’ column in the table and then have a different ‘tree view’ to show the hierarchy, similarly to the Categories tab (but done better, perhaps with collapsible ul/li lists or something). Not sure whether to only show one tree at a time and allow you to switch root or try to cram them all on one page, or whatever. It could even open out a sidebar/overlay with the hierarchy of the currently selected parent in the list, I really don’t know.

Ultimately, if subsections ever see the light of day, a tree view ought to offer drag ‘n’ drop, but that’s a loooooong way off and may bring with it more hurdles than it fixes. Like what to do with page/style assignments. Also:

Do subsections always inherit the page template of the root element or does each section have its own discrete identity?
Should new sections inherit the values of the immediate parent? The root? Or the current default section?
What happens if subsections are moved between branches? Are pages/styles reassigned or left intact? Or is it a choice?
What if a whole branch is moved to a different root?
What of the URL structure / SEO? Warnings about what article URLs are going to break? Maybe create an automatic list of rewrite rules after completion of the move that can be copied and pasted?
What should the core offer and where should plugins take over? (hint: the core should do the bare minimum :-)

Thoughts on this topic of course welcome too.

maruchan · 2012-06-22 16:33:06

what to do with page/style assignments

Is there anything that has to be done there? I think “inherit parent + provide some extra parameters to if_section would solve every problem I can think of.

Do subsections always inherit the page template of the root element or does each section have its own discrete identity?

Yes, I would say so, noting that an enhanced if_section would maybe eliminate the need to care too much about managing this, perhaps leaving the question of what inherits what to a plugin, beyond the defaults.

Example attributes for if_section:

<txp:if_section rootparent="default" /> could help make decisions around what the 1st-level parent is.

<txp:if_section parent="name" /> seems fairly important

<txp:if_section child="name" /> would be nice; not sure if it’s necessary

Combine one of those with child_offset and parent_offset (with a possible value like “any”) to help make choices based on the current page’s relative location in the tree. Example: <txp:if_section parent="grandpa" parent_offset="1"> would test one level above the literal parent.

Other nice but not necessary attributes: parentcount, childcount…perhaps for a plugin

Should new sections inherit the values of the immediate parent? The root? Or the current default section?

Immediate parent seems like a sensible default to me. Again, with the ability to test one’s location in the tree, I think the situation wouldn’t become too inflexible.

What happens if subsections are moved between branches? Are pages/styles reassigned or left intact? Or is it a choice?

IMO, keep the assigned pages/styles at the time of the move. Then anything else, plugin territory.

What if a whole branch is moved to a different root?

I’d suggest same as above. I think in the broad cases I’d be pretty annoyed if an entire branch lost its page/style relations when I moved it.

What of the URL structure / SEO? Warnings about what article URLs are going to break?

Plugin? I’m not sure I understand, but if I do, that seems like a pretty fancy feature when I’d be happy to redirect on my own.

Maybe create an automatic list of rewrite rules after completion of the move that can be copied and pasted?

Wow. This would be awesome for a plugin. In core though…most of my moving branches is going to take place in development, not on the live site.

Good questions!

Edit: I guess article_custom could use some new attributes if this becomes reality, too. Like, grab an entire branch or just n levels from a specific parent, that sort of thing.

Last edited by maruchan (2012-06-22 16:50:57)

Bloke · 2012-06-22 17:10:26

maruchan

I like the <txp:if_section> additions. And I agree with leaving sections/page assigned on move, with sensible (potentially overridable under an ‘advanced’ twisty at creation time?) defaults.

Of course, this is all a moot point if we can’t get the table structure right. Current Txp aversion to 4NF dictates that the ‘parent’ column be added to the txp_section table. It would be prudent to add an auto-incrementing ID so the parent could reference that rather than manually have to maintain referential integrity every time a section name changes (like we do now with the “foreign key” (he says, using the term loosely) being inserted in the textpattern table).

Then comes the notion of whether we need it to behave like a binary tree or not. And, if so, whether the tree fields go in the txp_section table or in a joining table. Do we care about lft and rgt? Perhaps, if we want to know parent / child counts or wish to delete subtrees without long walks. But does it matter given the number of Sections a site might have? Is it right to dictate that if your site has 500 sections (heaven forbid, although I think I read about someone who set up a site with over 1000 once!) that it’s going to be slow, or can we assume that 90% of people are going to limit (sub)sections to a sensible, manageable number? Assumption being the mother of all cock-ups, and all that.

The SEO stuff was just me being daft, as the core would unlikely ever go that far, but as you say, a plugin that could write the rules out after a move would be pretty handy for mass edits of a site in a dev environment.

Lots to think about before even touching code, methinx. I want to be sure we’ve got some concrete rules in place that pretty much everyone agrees are sensible, then we’ll go from there. If anyone wants to mock stuff up on how panels might look, trees might hang, what options are available, or even if some SQL geeks want to propose table layouts and queries then please get stuck in.

Last edited by Bloke (2012-06-22 17:13:40)

maruchan · 2012-06-22 17:23:10

As someone who counts hardcoded TXP section levels every night in order to fall asleep (“you only really need one more level…well, maybe two…or six then? Surely no one needs more than six”), I’m glad someone else is able to consider the schema in such a thoughtful way. :)

Last edited by maruchan (2012-06-22 17:23:27)

sacripant · 2012-06-22 19:24:48

I installed the beta of curiosity. I love the changes. Thank you Philwareham for all this ergonomics work and code cleaning.

A bug. The toggle yes/no works well in English. But it works for half of it in French: you can switch to non to oui, but not the inverse.
The value is locked to oui.

Dragondz · 2012-06-22 19:40:20

Hi

I installed on local, i see on language tab that when i update a language it gives me a green message on top that it s ok, but in the table below it nothing changed i still get “update” link, is this normal behaviour?

Cheers

Bloke · 2012-06-22 19:51:43

maruchan

I’m glad someone else is able to consider the schema in such a thoughtful way.

Hehe, I’m doing my best. Given my background in databases, trying to talk in terms of 4NF, relational tables and indexes is a struggle. I sometimes wished I’d seen a relational database first instead of being blown away by the beauty of that first database and then having a rude awakening when downgrading to the day-to-day administrative nightmare in the business world. Whatever you do, don’t ask me about SQL Server or you’ll regret it… unless you’re a fan of expletives :-p

sacripant / Dragondz

Thanks for the reports, I’ll look into them. I guess they may be related to non-English which I must admit I didn’t test fully. Naughty of me.

Last edited by Bloke (2012-06-22 19:54:41)

Dragondz · 2012-06-22 20:22:10

Hi Stef

for my case it s english language.

Textpattern CMS

Textpattern CMS support forum

#1 2012-06-22 14:35:03

r3822/3: New Sections panel

#2 2012-06-22 14:48:44

Re: r3822/3: New Sections panel

#3 2012-06-22 15:16:01

Re: r3822/3: New Sections panel

#4 2012-06-22 15:27:44

Re: r3822/3: New Sections panel

#5 2012-06-22 15:48:08

Re: r3822/3: New Sections panel

#6 2012-06-22 16:33:06

Re: r3822/3: New Sections panel

#7 2012-06-22 17:10:26

Re: r3822/3: New Sections panel

#8 2012-06-22 17:23:10

Re: r3822/3: New Sections panel

#9 2012-06-22 19:24:48

Re: r3822/3: New Sections panel

#10 2012-06-22 19:40:20

Re: r3822/3: New Sections panel

#11 2012-06-22 19:51:43

Re: r3822/3: New Sections panel

#12 2012-06-22 20:22:10

Re: r3822/3: New Sections panel

Board footer