Stuck with hundreds of skeleton articles. How to avoid and resolve?

Our wiki is widely used and viewed. We have templates that show wiki writers how to write a good wiki and this leads to well written wiki articles.

However there is an issue that we keep encountering and it really devalues our website. Stubs or poorly filled wikis generally get the template dumped in it. Then a few users add a tiny amount of information and the article then only has an almost empty skeleton. This of course causes a very high bounce rate and google indexing such pages as poor.
Not only readers feel lost on such pages, but also writers. Its overwhelming to see so much useless meaningless words, which buries the titbits of information available.

This problem concerns hundreds of wiki articles.

Its clear that the approach is wrong. We need an alternative approach which still inserts useful data and also allows users to follow templates but without rendering articles with a basic status completely useless.

Is there any functionality in vaultwiki that can be used to resolve this? Preferably something that does not exclude wiki writers with just basic technical capabilities.

I was think about suggesting functionality to resolve this problem, but I think its best to have some discussion about this first. What do you think about this?

It is very difficult to resolve this problem at the source. If some users are writing meager articles, I think there is little you can do before they actually submit the article.

At this time, the only existing tool you have to combat this is moderation. Maybe, add users who consistently write articles like this to a group whose new articles must be approved first.

Other future methods that I see for combating this are also response measures:
- When more page settings are added, have a setting for whether a page should be indexed by Google. If a page is especially poor, you can mitigate your bounces by removing it from search results.
- When flags are added, we can have a setting where if a page has certain flags (like "Stub"/"Skeleton"/etc), then it is not indexed by Google.

Unfortunately, if users are having trouble making sense of the content of a submission or are overwhelmed by the words they wrote, there is little VaultWiki can do to help them understand the actual text.

To reduce this at the source, you might need:
- More visible policies about what constitutes acceptable submissions. Explain that users who consistently violate these policies will be moderated.
- When default-templates are added, have an option to only allow the template values to be filled and no other text, and treat parameters that have no default values as required fields. It won't stop users from entering useless information, but the form layout (vs the editor text now) might make it easier to visualize which answers need to be changed.

I don't think this is a problem that can be eliminated entirely, but there are definitely some tools that might make managing it slightly easier. You said you had a functionality idea. What is it?

I dont think I have you have understood well what I intended to convey. I will try to explain it better:

Before starting, please note that by chapter I refer to an article section. I know that in VW the term section is used to avoid confusion with book chapters, but chapters in articles will always be chapters to me and my users. My members simply do not understand the term section in this regard.

In order to have standardized wiki articles we need extensive template texts.
The templates introduce up to 50 article chapters(VW sections) & sub-chapters(VW sections), each containing tables, bbcode functions, tables, instructional text, etc, etc. Such template is typically 500 - 1000 words.
For example:

Code:

---

chapter 1: The history of VARNAME
VARNAME was invented by ____  in ____.
chapter 2: threads about VARNAME
SHOWTHREADS

---

After the empty template is added to the article, then wiki writers can easily start filling in the variables and blank.
There is a lot of benefit in this approach as it results in standardized articles with a common structure and address all the right topics. These templates also make the article relatively easy to fill in and thereby reduce work.

The problem arises if someone adds the template and then only adds a little information. For example: the user only wants to write a bit in one particular article chapter. (or section as its called in VW) Then we are left with 49 article chapters (sections) each with only template text. The article chapter (VW section) that the user has written as valuable as it is, will stay unnoticed due to the sheer amount of chapters(sections) and template text.

This is not a matter of problematic writers or lack of moderation. We live in the mobile age now where people will not look beyond the page they are on right now. If we make it very clear to users what topics they can write about and what templates they need to fill in, then they will do it. Most users will not or are not even able to find a template somewhere and dump it into a wiki. Vaultwiki is too complex for many users when it comes to templates. If they see too much useless data on the screen they will simply leave.

In terms of functionality that would really help, is to serve the user with a choice of article chapters (VW section) they want to work on. For example after clicking the edit button, let them select the possible article chapters (VW section) they can work on. (These would be defined per category/area by the admin)
After selecting the chapter, the chapter is created(if it doesn't exist yet) and the template for that chapter appears. Which they can fill in and add text to.

This way we would avoid a whole wiki article with dozens of empty chapters and meaningless template text, but still have the benefit of using template text. The wiki would only contain useful information.

Okay, there are some features in the pipeline for 4.1 that would do what you are talking about.

In the mean time you can use IF statements in your templates to hide sections that do not have enough information. In this way, users can enter only the parts they want to work on, and the unfinished parts will be hidden.

Code:

---

[if="{{{important}}}"]
[h=2]Section[/h]
This section should only appear if the user filled in the {{{important}}} information. If {{{important}}} was left blank, this whole paragraph will not appear.
[/if]

---

Interesting. Does that also work for VW3?

Yes, IF has been available since 2.0.0 Beta 1, when VaultWiki was still a plugin for NuWiki.

We have not used IF because we do not understand its use.

Code:

---

[h=2]chapter 1: The history of VARNAM[/h]E
VARNAME was invented by ____  in ____.

---

How would you use the IF function to only show chapter 1 if both blank spaces are filled in?

For an AND condition, you need to stack two IFs:

Code:

---

[IF="{{{arg1}}}"][IF="{{{arg2}}}"]
Shows when both IF conditions are satisfied
[/IF][/IF]

---

Otherwise IF performs an OR condition:

Code:

---

[IF="{{{arg1}}}{{{arg2}}}"]
Shows when either {{{arg1}}} or {{{arg2}}} is satisfied.
[/IF]

---

The IF option collapses args into their text values. If multiple args are side by side, the text is concatenated. After doing this, if the IF option is non-empty, it evaluates to true.

If you use <,>, ==, or != between args:

Instead of checking for non-empty, IF will compare the text on either side and evaluate to true as appropriate.

Code:

---

[IF="{{{arg1}}}=={{{arg2}}}"]
Shows when {{{arg1}}} and {{{arg2}}} have the same value.
[/IF]

---

IF has occasionally been victim to unusual bugs, so in some old versions it might not work as expected. As far as I know, it works as designed in recent versions.

It still doesn't make sense. Your examples are similar to the examples visible on special:wikicodelist
It's clear that conditions can be set in the options. But it still doesn't explain how to use this in practise. What I do not understand is: how exactly are conditions satisfied?
Lets go back to my example:

Code:

---

[h=2]chapter 1: The history of VARNAME[/h]
VARNAME was invented by ____

---

How do I make the section appear if it is filled in who the inventor is? We dont know the value that is going to be filled in. It can be any value. What code do I use?

Again:

Code:

---

[IF="{{{inventor}}}"]
[h=2]chapter 1: The history of VARNAME[/h]
VARNAME was invented by {{{inventor}}}
[/IF]

---

I have explained in my previous post how conditions are satisfied:

Quote:

---

The IF option collapses args into their text values. If multiple args are side by side, the text is concatenated. After doing this, if the IF option is non-empty, it evaluates to true.

---

That part was relevant to what you want to do. If {{{inventor}}} was filled as "Alfa1", then the IF looks like this internally:

Code:

---

[IF="Alfa1"]

---

The condition is not empty, so the condition is satisfied.

If {{{inventor}}} was not filled, then the IF looks like this internally:

Code:

---

[IF=""]

---

The condition is empty, so the condition is not satisfied.

There were some versions where this is-not-empty check did not work correctly and still satisfied when empty.

I then went on to mention comparisons, because less commonly you will want to do that.

Quote:

---

If you use <,>, ==, or != between args:

Instead of checking for non-empty, IF will compare the text on either side and evaluate to true as appropriate.

---

When those symbols are hard coded in the IF option (if they were not added by an {{{arg}}}), then everything to the left of the symbol is compared to anything on the right of the symbol. If the comparison is a true statement, then the condition is satisfied. There were some versions of VaultWiki where this type of comparison did not work correctly when an {{{arg}}} contains one of these symbols.

Since there were bugs in some versions, if you are trying these out and the output does not make sense to you, then you might be encountering a bug.

OK. So we have this template:

Code:

---

[IF="{{{inventor}}}"]
[h=2]chapter 1: The history of VARNAME[/h]
VARNAME was invented by {{{inventor}}}
[/IF]

---

The first wiki is about the lightbulb. So a member uses this template and fills in the inventor.

Code:

---

[IF="{{{inventor}}}"]
[h=2]chapter 1: The history of the lightbulb[/h]
the lightbulb was invented by Edison.
[/IF]

---

The next article is about the steam engine. Again a member uses this template and fills in the inventor:

Code:

---

[IF="{{{inventor}}}"]
[h=2]chapter 1: The history of the steam engine[/h]
the steam engine was invented by Watt.
[/IF]

---

It seems to me that in my examples the IF condition is not satisfied. If I am correct, then what do I do to only show the section if an inventor is filled in? Mind that this can be any value/name and we have no way of knowing what value/name will be used.

In both of your examples the IF condition is satisfied:

In the article about the lightbulb, {{{inventor}}} was provided as Edison. When {{{inventor}}} is replaced in the IF condition, the condition is not empty, so the condition is satisfied. The wiki sees the code like this:

Code:

---

[IF="Edison"]
[h=2]chapter 1: The history of the lightbulb[/h]
the lightbulb was invented by Edison.
[/IF]

---

In the article about the steam engine, {{{inventor}}} was provided as Watt. When {{{inventor}}} is replaced in the IF condition, the condition is not empty, so the condition is satisfied. The wiki sees the code like this:

Code:

---

[IF="Watt"]
[h=2]chapter 1: The history of the steam engine[/h]
the steam engine was invented by Watt.
[/IF]

---

Where does VW get the information that {{{inventor}}} = Edison?
Does it get this from previous edits?

When you use the template:

Code:

---

[template]Example
| inventor=Edison
[/template]

---

And "Example" was an article with the "Template" page-type (VW4) or in the Template namespace (VW3), with the content:

Code:

---

[IF="{{{inventor}}}"]
[h=2]chapter 1: The history of the [var]PAGENAME[/var][/h]
the [var]PAGENAME[/var] was invented by {{{inventor}}}.
[/IF]

---

Aha! I see now what you mean. What I meant with Template is a text that a user can simply dump into a section and start filling in the blanks. Text templates as such have no functions. Its just text that can be copied and pasted. They cannot be called.

What you mean is a "Template" page-type which enables us to do more advanced things. The template text is not manually added to the article section, but instead a call to the template is added.

We were talking about two completely different things. Lets call what I am talking about a text-template, while your is a vaultwiki-template.

After clearing up this misunderstanding: how would you answer my question on how to resolve this problem?

The existing way to manage your problem is to invoke VaultWiki templates and to show/hide the parts of the templates based on how they are filled in.

Conditional processing is only available within a VaultWiki-template context.

The additional tools that I mentioned being in the pipeline as new features, which might have also been helpful, such as an option for creating new pages from form-based templates (rather than copy-pasting the template invocation), are still intended to be improvements upon the existing VaultWiki-template system.

The drawback to using VaultWiki-templates is that H tags (sections/chapters) cannot be individually edited if the H tag was invoked within a template. However, if you believe that losing the ability to edit individual paragraphs is an acceptable trade-off for limiting your "skeleton" problem, then I encourage you to try VaultWiki-templates before you have too many more pages to convert.

You can start by converting two or three existing articles to see if it works well for you, and if so, update your site's copy-paste tutorials to just have the template invocations. I say to try it first, because I do not know whether IF conditions will function correctly in your version.

I will await the new features, as I dont think that the current VaultWiki Template functionality is a solution to my problems.

Google seems to be penalizing for such pages, as searches that include such low quality wiki pages will not come up in google. Yet, other searches for my site content is always top ranking.

So in other words, you have not seen that your site is being penalized overall, just that the low-quality pages are not ranking well. I'm not sure you would want low-quality pages to rank well, or at all. That's why I suggested this earlier in the thread:

Quote:

---

Originally Posted by pegasus

Other future methods that I see for combating this are also response measures:
- When more page settings are added, have a setting for whether a page should be indexed by Google. If a page is especially poor, you can mitigate your bounces by removing it from search results.
- When flags are added, we can have a setting where if a page has certain flags (like "Stub"/"Skeleton"/etc), then it is not indexed by Google.

---

No, I think the solution you are suggesting may be a good patch. But what I am saying is something different:
A search on google for a term will yield a number of pages from my site.
If one of these pages is a wiki with lots of text code, then google will not show any of the pages. Even though the quality of other pages is good.

I will attempt to add page-level toggle for search indexing for the next release. Maybe once low-quality pages are excluded from your index, your high-quality pages will begin appearing again.

Maybe allow users to add a 'stub' or 'empty page' status to pages. And automatically add no-index to such pages.

Related suggestion: https://www.vaultwiki.org/issues/3508/
If all members and guests would be able to rate articles as 'empty page' then all my wiki articles would have the correct status in no time and empty articles would get no-index fast.
A very basic drop down select at the bottom of the article would be really great.