Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#16 2011-08-10 10:23:58

net-carver
Archived Plugin Author
Registered: 2006-03-08
Posts: 1,648

Re: sed_default_article_status

I’m tempted to remove live from the running. After all, you’d not need to install the plugin if you wanted that as your default :)

Phil: If that were the case, how would you vote?


Steve

Offline

#17 2011-08-10 10:40:52

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,565
Website GitHub Mastodon

Re: sed_default_article_status

Well… there are two opposite arguments I guess:

From a UX perspective it’s always best, when adding new features to an app, to leave any preference affected by that new feature at it’s default (in this case ‘live’), and from there the user can modify to a new setting if they wish.

But since this is an additional plugin that someone has to manually install anyway, I guess it would be OK to move the default to a different setting on install. My vote would be ‘draft’ in this case.

Offline

#18 2011-08-10 12:46:00

merz1
Member
From: Hamburg
Registered: 2006-05-04
Posts: 994
Website

Re: sed_default_article_status

Help text: After installation and activation article status draft (<- link to article status help) is the active default setting for saving a new article. This setting is changeable via extended preferences under publishing.

Help text: sed_default_article_status is a Textpattern wide setting and can not be set to a different individual value for every user.

Q: Btw … Which user roles are affected?

I’m tempted to remove live from the running.

Don’t :) I see screaming authors who want to switch back & forth eg when hammering out batches of announcements but want to have ‘draft’ for the deeper thoughts on 42.

Last edited by merz1 (2011-08-10 12:49:21)


Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML

Offline

#19 2011-08-10 17:58:45

net-carver
Archived Plugin Author
Registered: 2006-03-08
Posts: 1,648

Re: sed_default_article_status

merz1 wrote:

Don’t :) I see screaming authors who want to switch back & forth eg when hammering out batches of announcements but want to have ‘draft’ for the deeper thoughts on 42.

Hi Markus, when I said “remove live from the running” I was only talking about options for the initial value of the pref when the plugin is enabled for the first time. Live will still remain in the list of choices so it can be changed.

Help text: After installation and activation article status draft (<- link to article status help) is the active default setting for saving a new article. This setting is changeable via extended preferences under publishing.

Help text: sed_default_article_status is a Textpattern wide setting and can not be set to a different individual value for every user.

Thanks for the suggestions. Once the final functionality is agreed and in place, I’ll revisit the help page for a tidy-up.

@philwareham Thanks for the feedback. I’ll keep that in mind & I’ll leave your vote where it is for now.


Steve

Offline

#20 2011-09-26 15:52:12

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,565
Website GitHub Mastodon

Re: sed_default_article_status

I seem to be having a conflict between this plugin and arc_twitter. When they are both active I get the article status radio buttons displaying twice on the write page. Weird.

Offline

#21 2015-05-12 11:00:17

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,912
Website

Re: sed_default_article_status

+1 for “Draft” status as default. It follows a fundamental editorial workflow. That’s why I (with Blokes help) created the original plugin, to fix backwards behavior that core has.

+1 that this is built directly into core. (4.6?)

Nobody, qualitatively speaking, should immediately publish anything live until the draft has had a couple goings over first. I think any writer would tell you — despite what is convention conceived by a dev/designer — is that you draft first, save, revise, save, revise again, perhaps, then publish live after it’s ready.

Are you a shooter? Think of it as a gun. You don’t give a loaded pistol to anyone with the safety off in case they shoot their foot while taking it. Let them feel the weight and handling, then when comfortable, turn safety off.

Or to think of it another way… Opt in (to publish your mistakes “live”), not out. Plus, it’s a good way to get new users to look at the preferences and think about what’s there.

My two cents.

Offline

#22 2015-05-12 11:15:30

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 12,446
Website GitHub

Re: sed_default_article_status

Destry wrote #290685:

Opt in (to publish your mistakes “live”), not out.

I’m of this opinion too. How about a pref for “Default publishing status”, set to Draft on new installations, but which retains your current setting on upgrade from 4.5.x to avoid any surprises? Github issue raised to track this.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Hire Txp Builders – finely-crafted code, design and Txp

Offline

#23 2015-07-08 14:34:06

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,727
GitHub

Re: sed_default_article_status

Destry wrote #290685:

Nobody, qualitatively speaking, should immediately publish anything live until the draft has had a couple goings over first. I think any writer would tell you — despite what is convention conceived by a dev/designer — is that you draft first, save, revise, save, revise again, perhaps, then publish live after it’s ready.

The obvious exception being instant gratification bloggers who want to Write, Publish and Be Damned.

I haven’t done extensive research into this, so take this with plenty of salt, but I would hazard a guess to say that many or most blogging-centric CMSes put an article live as soon as publish is clicked or tapped.

Offline

#24 2015-07-08 15:30:26

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 12,446
Website GitHub

Re: sed_default_article_status

gaekwad wrote #292867:

I would hazard a guess to say that many or most blogging-centric CMSes put an article live as soon as publish is clicked or tapped.

Yeah probably. So having the option/pref to move to a more structured publishing methodology is a good thing, right? Maybe we stick with Live as default, and you can just set your preferred status from prefs if you don’t like it.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Hire Txp Builders – finely-crafted code, design and Txp

Offline

#25 2015-07-08 15:34:23

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,727
GitHub

Re: sed_default_article_status

Bloke wrote #292877:

Yeah probably. So having the option/pref to move to a more structured publishing methodology is a good thing, right? Maybe we stick with Live as default, and you can just set your preferred status from prefs if you don’t like it.

The option to change it: yes, make that a thing – default should, in my humble 2c, stay as Live.

Offline

#26 2015-07-08 15:41:27

hcgtv
Archived Plugin Author
From: Key Largo, Florida
Registered: 2005-11-29
Posts: 2,722
Website

Re: sed_default_article_status

Bloke wrote #292877:

So having the option/pref to move to a more structured publishing methodology is a good thing, right? Maybe we stick with Live as default, and you can just set your preferred status from prefs if you don’t like it.

Yes, thank you. I always have to remember to place the article I’m working on in Draft mode, lest I forget and an unfinished piece floats to the front page, which has happened on a few occasions.

Offline

#27 2015-07-08 15:49:58

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 12,446
Website GitHub

Re: sed_default_article_status

gaekwad wrote #292878:

The option to change it: yes, make that a thing – default should, in my humble 2c, stay as Live.

Will do it tonight, with luck.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Hire Txp Builders – finely-crafted code, design and Txp

Offline

#28 2015-07-08 15:56:46

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 976
Website

Re: sed_default_article_status

Preference – easiest way to satisfy different desires. So, yeah, probably a good idea. Even though I get uneasy with preference overload/bloat.

My personal preference is that publish as draft is the default. Then those who want to publish live can change it.

Otherwise, should you overlook setting the preference, the unsuspecting end user doesn’t find a half-baked article sent out for public consumption.

In this case, given the possible outcomes, assume the worst case and set the defaults accordingly.

Offline

#29 2015-07-08 21:53:23

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 12,446
Website GitHub

Re: sed_default_article_status

Landed.

For better or worse I took the path of least resistance and left the default status at Live until you explicitly change it. Fewer surprises for veteran users on new installs. less documentation to hunt down and change. Easy enough to alter for those people that prefer a more editorial workflow.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Hire Txp Builders – finely-crafted code, design and Txp

Offline

#30 2015-07-09 08:13:40

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,912
Website

Re: sed_default_article_status

Bloke wrote #292909:

Landed.

Yay!

Bloke wrote #292877:

Maybe we stick with Live as default, and you can just set your preferred status from prefs if you don’t like it.

Oh well, can’t win ‘em all. Makes me realize the pub_draft (plack/hugin?) is a thing of beauty. And no preferences involved. ;)

gaekwad wrote #292867:

The obvious exception being instant gratification bloggers who want to Write, Publish and Be Damned.

I haven’t done extensive research into this … but I would … say that many or most blogging-centric

Just curious, though, Stef, did being consistent with other single-user blogging tools, and not what’s actually logical in a multi-user editing workflow sway the decision?

Seems to me the default would be suited to the use-nature of your primary (desired) target audience, even if that audience is a new goal, not based on what other systems are doing (which could very well be doing it wrong) or for a blogger audience that’s already tapped out, or even for veterans who might be used to it (humans adapt to bad design).

I’d think, with the tremendous visibility of content marketing and content strategy in recent years that even mommy bloggers are realizing you need to review your drafts once or twice — maybe even write a few in advance before finalizing a given one.

But, it’s done. Move on. Don’t mind me. I’ll make coffee now and be right as left.

Last edited by Destry (2015-07-09 08:23:43)

Offline

Board footer

Powered by FluxBB