What makes a wiki suck?

CoyneTheDup

What makes a wiki suck?

I know this is bad, but the first answer I though of when I saw this question was, "Users."

PleegWat

I think updating on an interval would be a good idea. No need to bother the server every keypress, but maybe every 20-30 seconds, or when I haven't pressed a key for 5?

RaceProUK

I'd still, given the choice, prefer a dedicated 'Preview' button; no need to spam the server more than absolutely necessary

PleegWat

Could be a user setting, though I think it would be desirable to have an admin be able to force preview-before-save.

RaceProUK

@PleegWat said:

force preview-before-save

For a wiki, that's a damn good idea

HardwareGeek

@blakeyrat said:

On purpose, or just as a result of developer incompetence?

These are not mutually exclusive. In fact, the former is often due to the latter.

Luhmann

@RaceProUK said:

It's also true they're not a panacea; many WYSIWYGs are more like WYSISOWYGIYALs, especially when it comes to generating HTML from them.

Then add an 'edit source' button ... like euh ... SharePoint has.

95% of the people will be using the lint options and once in a while someone has to pull out the source behind the page (actually only the content frame) to edit some strange markup (almost always because of copy-pasta from word).

Luhmann

@PleegWat said:

force preview-before-save

Or just dunk the whole preview button/timer discussion and use a set of buttons to control basic markup?

HardwareGeek

@Luhmann said:

just dunk the hole

I'd rather dunk the doughnut; holes are rather insubstantial.

dkf

If you want a wiki to not suck, focus on keeping the markup simple and the curation tools capable.

The #1 problem of any starting wiki is getting content in. People don't go to a wiki just because it's made with a particular piece of software, they go because it has content which is of relevance to them.

The #1 problem of any wiki that's even moderately successful is keeping the content relevant and (where applicable) fresh. Keeping the markup simple makes that easier. Making the curation tools good makes that much easier.

That aside…

Good curation tools can also help with the spam patrol. It's awful that it is necessary, but you really need to take action to deal with that sort of thing early. Sticking with a simple markup format has a few advantages too, such as not needing to worry about someone figuring out how to work a <script> tag in there. Yes, it limits what you can do. But stopping screwing around with the formatting and starting working on the content itself is far more important to success. (The same applies if you're writing a book or a paper or a letter or a program or … Quit fucking around with how it looks and write the silly thing.)

Bort

Keep in mind the typical authoring pattern for wikis:

Brain dump
Clean up
Goto 1
Profit

mott555

My input on what makes wikis suck has to do with administration. If you're going to support any kind of security/ACL stuff, make it easy to find.

For example, I'm using a "secured" login-only MediaWiki install for some stuff. User administration is a complete charlie-fox, it took a partner and me the better part of two hours to find the pages (stuff is NOT logically named nor organized) to edit someone's account, only to find that there is no way for an admin to reset a specific user's password which was a problem because the user had forgotten his password! (I should also point out we never got email working.) Then we figured we'd delete the account and we'd reregister him, but there was no delete account option, just some weird "flagged as deleted but not actually deleted so the username can't be used again" thing.

Keith

@cartman82 said:

I think tables are disabled in Discourse markdown.

@blakeyrat said:

On purpose, or just as a result of developer incompetence?

@boomzilla said:

Pretty sure it's on purpose.

Yup, here's a topic about it:

https://meta.discourse.org/t/markdown-table-support/13546

and here's a comment from another topic:

https://meta.discourse.org/t/html-table-support-not-working-in-post/7733/3?u=keith_tdwtf

Bulb

@blakeyrat said:

Mostly I'm still bitter than it's 2015 and we have worse text editing options than we did in 2008, because douchebag programmers keep getting obsessed with backwards dead-end bullshit like Markdown.

Despite the fact WYSIWYG editor is now built into HTML itself, via the contenteditable attribute.

Actually it might be a good way to go though. It requires adding some javascript-powered controls because the raw thing does not seem to allow any formatting beyond bold and italic via the usual keyboard shortcuts (and I would not rely on them working in all browsers), but it should still be easier than baking it having to also handle the rendering.

@RaceProUK said:

@PleegWat said:
force preview-before-save

For a wiki, that's a damn good idea

No, it's not. WYSIWYG editor is. In this I am with blakey. While I have no problem with writing in markdown myself, WYSIWYG is simply easier for most people.

@dkf said:

focus on keeping the markup simple

Not needing it is still better ;-).

RaceProUK

@Bulb said:

@RaceProUK said:
@PleegWat said:
force preview-before-save

For a wiki, that's a damn good idea

No, it's not. WYSIWYG editor is. In this I am with blakey. While I have no problem with writing in markdown myself, WYSIWYG is simply easier for most people.

It is a good idea.

WYSIWYG is better though ;)

Onyx

@Bulb said:

Despite the fact WYSIWYG editor is now built into HTML itself, via the contenteditable attribute.

I played around with it a few years ago when it was pretty much brand spanking new. It worked rather well, although I do remember that adding paragraphs was inconsistent among browsers at the time (some browsers would add a paragraph on two newlines, some would add two breaks and keep the whole thing in a single paragraph).

Might be more reliable now, I should really give it another whirl one of these days.

tar

What's that? The Markdown standard doesn't support tables? Or it does? There's no standard Markdown? Markdown is basically a blight on good software? I'm doing a plausible impression of a valley girl? The way each sentence sounds like it's a question? My back hurts? What were we talking about again?

boomzilla

@tar said:

There's no standard Markdown?

There's a Common one, though.

tar

@Bulb said:

WYSIWYG editor is.

I don't have any objections to WYSIPABLWYGMLHSA per se, but having an advanced/markup editor view can be useful for power users, and importing formatted text via copy/paste from other sources. http://blogger.com/ editor is maybe not the best example of anything, but it allows you to switch from 'live edit' to 'markup edit' and back...

Yamikuronue

@tar said:

I'm doing a plausible impression of a valley girl?

Needs more likes.

tar

@boomzilla said:

There's a Common one, though.

Hehe, the Gruber/Attwood fracas. That was mildly entertaining, back in the day...

antiquarian

@HardwareGeek said:

I'd rather dunk the doughnut; holes are rather insubstantial.

I'm surprised no one flagged this for a spellar badge.

HardwareGeek

@antiquarian said:

I'm surprised no one flagged this for a spellar badge.

Nobody is stopping you from doing so.

HardwareGeek

@boomzilla said:

There's a Common one, though.

But if nobody uses it, it's not really very common, is it?

loopback0

@antiquarian said:

I'm surprised no one flagged this for a spellar badge.

Missed that. Flagged accordingly now.

boomzilla

@HardwareGeek said:

But if nobody uses it, it's not really very common, is it?

Maybe I'm using definition #2:

com·mon ˈkämən/Submit adjective 1. occurring, found, or done often; prevalent. "salt and pepper are the two most common seasonings" synonyms: usual, ordinary, familiar, regular, frequent, recurrent, everyday; More antonyms: unusual, rare (of an animal or plant) found or living in relatively large numbers; not rare. ordinary; of ordinary qualities; without special rank or position. "the dwellings of common people" synonyms: ordinary, normal, average, unexceptional; simple "the common folk" (of a quality) of a sort or level to be generally expected. "common decency" of the most familiar type. "the common or vernacular name" denoting the most widespread or typical species of an animal or plant. "the common blue spruce" 2. showing a lack of taste and refinement; vulgar. synonyms: uncouth, vulgar, coarse, rough, boorish, unladylike, ungentlemanly, ill-bred, uncivilized, unrefined, unsophisticated; More antonyms: refined 3. shared by, coming from, or done by more than one. "the two republics' common border" belonging to, open to, or affecting the whole of a community or the public. "common land" synonyms: collective, communal, community, public, popular, general; More MATHEMATICS belonging to two or more quantities. 4. GRAMMAR (in Latin and certain other languages) of or denoting a gender of nouns that are conventionally regarded as masculine or feminine, contrasting with neuter. (in English) denoting a noun that refers to individuals of either sex (e.g., teacher ). 5. PROSODY (of a syllable) able to be either short or long. 6. LAW (of a crime) of relatively minor importance. "common assault"

INB4 STOP CHANGING THE DEFINITION OF COMMON.

Onyx

@boomzilla said:

INB4 STOP CHANGING THE DEFINITION OF COMMON.

Common, there's no need to yell...

Filed under: The Youtube comment section definition

Bort

What about Common?

HardwareGeek

@boomzilla said:

com·mon
ˈkämən/Submit
adjective

...

Flagged for dickweedy pedantry.

PJH

@mott555 said:

only to find that there is no way for an admin to reset a specific user's password which was a problem because the user had forgotten his password! (I should also point out we never got email working.)

There is: http://www.mediawiki.org/wiki/Manual:Resetting_passwords#Use_the_changePassword.php_maintenance_script

Presuming, of course, you have command line access to the server hosting the site....

HardwareGeek

dkf

@Bulb said:

Not needing it is still better

Wrapping something in front so that users don't see it, I can understand why you might do that, but you almost certainly want to have actual markup under the hood (including at the protocol message level). You probably don't want to get too much into sending HTML directly except when people are not editing but rather just reading; defanging that is much harder than anyone sane ought to have to deal with.

As it is, you're already rapidly speeding down the well-worn highway to wikidisaster. Fancy WYSIWYG HTML editor? Check. User-generated content? Check. Focussing on the look and feel of things instead of the content? Check. No thought given to making stuff properly searchable and indexable and curate-able? Check. Yep. It sounds like it'll be a complete WOMBAT and no non-spammer user will ever really be interested.

ben_lubar

@Maciejasjmj said:

@cartman82 said:
a tree-like structure of categories

But... it's there in almost every Wiki imaginable.

MediaWiki has a directed graph as its category structure. Categories can be inside each other.

blakeyrat

I think null_loop gave up on this.

JBert

Rightly so.

Polygeekery

What makes a wiki suck?

Wikis suck because of the assholes that end up setting up shop there and taking over. I would suggest trying to gamify "not being an asshole", but if you were successful @codinghorror would adopt it and then we would all have to go somewhere else.

Onyx

But... if you rewarded not being an asshole, he wouldn't be able to dogfood it properly.

Filed under: I know, kettle, pot..., It was too tempting!

Polygeekery

I think you want the determinism thread and/or the omniscience thread. ;)

tar

One of those threads may imply the other.

null_loop

Oh no - not given up yet - just taking it all in. Didn't realise I'd spawn this much interest - although including markdown was always going to be a red flag (which I've decided to ditch and fuck my life up and write my own goddamn specification - line-down )
A lot of what I'm reading is surprising, the cmd line access to reset a password is just pure skull fuckery. I'm genuinely hopeful of doing better in the tooling / admin / curating respect.
Currently the editor will be a live-preview of a line-down editor to various HTML renders. A secondary aspect may be switching the line-done editor for a simplified WYSIWYG control (at user choice).

blakeyrat

@null_loop said:

Oh no - not given up yet - just taking it all in. Didn't realise I'd spawn this much interest - although including markdown was always going to be a red flag (which I've decided to ditch and fuck my life up and write my own goddamn specification - line-down)

Red flag wasn't big enough, now it's a red tarpaulin, The kind you use to cover football fields. (BTW your tiny spec already contradicts itself--

Processing is conducted on a line-by-line basis
The contents of a line cannot affect the output of any other line

Ok...

Block specs are always the first non-whitespace characters
Block specs can be on their own line - and their corresponding opening element will be output on its own line

Uh, which is it? How can you even have blocks if no line affects any other line?

Well, do what you wanna do. Godspeed I guess.

null_loop

That applies to the output from the parser. Not the rendering. So the using equals / dashes thing on a subsequent line to change the output of the line before (add H1/H2 tags) is out.

blakeyrat

Ok well whatever, I still think you're going exactly 180 degrees from the direction you should be going if you expect this software product to actually improve the world in any small way.

tar

I'm not 100% convinced that you need classSpec and idSpec classifiers, and I'm pretty sure that allowing them in either order is going to bite someone. Given that it's in an embryonic state, I'll withhold judgment. At least you have the freedom to try what works and get rid of stuff that doesn't...

Bort

line-down The world's got thousands of problems. Let's add another one.

I think I see where you're going with this. Here's some more ideas:

have the syntax be xml and there's a tag for each letter
- < a > for 'a', < b > for 'b'
- oh, that will get confused with the html tags
- so better namespace them: < alpha:a>, < alpha:b>
Auto-translating wiki (everything to Latin, it's a better language)
Pictures-only wiki (people only look at the pictures anyway)
emoji-only wiki
Users can only edit while a moderator is logged in
All editors are Anonymous
- or, color-code which paragraphs were edited by who so readers will know the bad parts weren't done by me
Entire wiki is one long page that anyone can edit
Users have to be individually invited to edit (view?) each page
Infiniscroll can follow links to other pages
- Pages can be mutually linked
- Truly infinite scrolling
Somehow break ctrl + V the way Discourse does
Support as many different databases/platforms as possible
Require server to have flux capacitor installed so you'll know what articles people will want to be in the wiki before them come searching for them
Write as a multi-level quine (Ruby -> PHP -> Python -> Java -> Node -> ...) so admin can choose which language to deploy wiki as
Every tenth article is goatse
Require every word to be a link to another page
Words can link to multiple pages (overlapping links)
- hovering on word opens pop-up menu of articles it links to
- every word has its own generated article that is one of the links
citations can only refer to other articles in the same wiki
actually, forget content
- take whatever they search for and use it as the seed for randomly generated text and present that as the article
- No Quack
make whole page Flash
- can be an interactive Adobe Flash app
- or whole page can < blink > constantly
- your choice
set yourself on fire
make @SpectateSwamp your CTO