Away from blogs: Create sections with default "Not on front page"

uli · 2014-07-15 21:30:43

I just explained a proactive client of us to look for the section’s options every time she creates one and set its value for “Section appears on front page” to No. Then I recognized that this is a legacy of Textpattern’s past as a blogging engine, the most sections created with a CMS will probably be set to “No” for that option, requiring additional attention and an extra step.

Here’s my vote for an new preference setting “Set new sections to not publish on front page” in order to remedy that issue and for remaining backwards compatible with existing websites.

Bloke · 2014-07-15 23:19:56

uli wrote #282164:

Here’s my vote for an new preference setting “Set new sections to not publish on front page”

How about not having a new pref, but remembering all three of the radio button settings from last time when you go to create a new Section? Then you just have to do it once when you create/edit your first Section.

Using a dedicated pref is all well and good, but I feel it’s overkill in this situation. Haven’t fully thought it through, but on the surface it seems that remembering state would work quite nicely.

Whaddya think? Have I missed something obvious?

gomedia · 2014-07-16 07:03:38

Sounds good to me!

etc · 2014-07-16 11:47:26

uli wrote #282164:

I just explained a proactive client of us to look for the section’s options every time she creates one…

A little OT, but why a client would create many presentational units that sections are?

uli · 2014-07-16 13:45:54

Bloke wrote #282165:

How about not having a new pref, but remembering all three of the radio button settings from last time when you go to create a new Section?

I’m not keen on new prefs, either. It’s just that cookies/local storage are device/browser/user based. That’s acceptable for one-man-websites (though not for multi-device operators), and not for teams, either.

A new snippet in textpattern.js to change the radio button on creation of the section (if possible at all, which I doubt but just to demonstrate I’m open to alternatives) would permanently interfere with the operating for blogs and blog-like websites.

We probably can’t change the setting Textpattern uses when sections are added (which would be my actual favourite) without loosing backwards compatibility for websites that rely on having everything on the front side

Hence my thought to leave Textpatterns behaviour as is and rather introduce a chooser, whether the user wants all new sections be visible on front page by default or not.

But I’m sure I’ve not thought through every aspect.

uli · 2014-07-16 13:47:12

etc wrote #282187:

A little OT, but why a client would create many presentational units that sections are?

About pages, legal sections (when adding a shop, as in the actual case), adding product ranges, …

Bloke · 2014-07-16 14:27:12

uli wrote #282193:

cookies/local storage are device/browser/user based. That’s acceptable for one-man-websites (though not for multi-device operators), and not for teams, either.

Txp’s per-user prefs are just that: per user. When you next log in, regardless of device or browser, your settings are restored. There are also global prefs which override these local prefs if they have the same name.

leave Textpatterns behaviour as is and rather introduce a chooser

That’s ok in principle, but where does it end? Following that logic we should have prefs for setting the default values for ‘Syndicate’ and ‘Include in site search’. And then what about other panels: prefs for default article status? File status? Prefs for whether ‘detail’ checkboxes are on or off? Prefs for number of rows to show on list Panels, per panel?

It just starts to flood the prefs with things that aren’t really preferences, per se. From an end-user perspective, having it remember your settings is more personal and useful because it suits your workflow. I’m actually trying to think in terms of removing some of the existing prefs in favour of per-user defaults rather than add prefs, unless strictly necessary.

As counterpoint to your scenario, imagine a different type of multi-contributor site. One user might be in charge of Presentation for the corporate area of the site, another might be in charge of the company’s events, competitions and blog areas. If they both have free reign to create Sections (which is not something that’s a great idea unless they understand the SEO ramifications anyway, but let’s assume they have been given the green light to do so), then setting your pref to ‘No’ means the events editor has to click ‘Yes’ every time they create a new Section. Corporate person happy; Events person slightly miffed. And of course the level of miffness(!) is reversed if the pref is switched.

Having a per-user pref means, on average, roughly half the people are inconvenienced only once, then everyone’s happy as the interface has adapted to their workflow.

Does that make sense or have I totally lost the plot?

uli · 2014-07-17 15:30:15

Sorry for the late reply, I’m again in vacation substitution modus.

Like I said, “I’m sure I’ve not thought through every aspect”: I didn’t think of something like your counterpoint to my scenario, and seen in that light you’re of course right, you won’t satisfy everyone.

Once I can be sure I find a little time again I’ll stick a JS band aid on our client’s website, had a quick look there today and I’m confident now that it’s doable.

Textpattern CMS

Textpattern CMS support forum

#1 2014-07-15 21:30:43