What makes a wiki suck?
-
What makes a wiki suck?
I know this is bad, but the first answer I though of when I saw this question was, "Users."
-
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?
-
I'd still, given the choice, prefer a dedicated 'Preview' button; no need to spam the server more than absolutely necessary
-
Could be a user setting, though I think it would be desirable to have an admin be able to force preview-before-save.
-
-
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.
-
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).
-
force preview-before-save
Or just dunk the whole preview button/timer discussion and use a set of buttons to control basic markup?
-
-
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.)
-
Keep in mind the typical authoring pattern for wikis:
- Brain dump
- Clean up
- Goto 1
- Profit
-
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.
-
I think tables are disabled in Discourse markdown.
On purpose, or just as a result of developer incompetence?
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
-
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.
@PleegWat said:
force preview-before-save
For a wiki, that's a damn good ideaNo, 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.
focus on keeping the markup simple
Not needing it is still better ;-).
-
@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 ;)
-
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.
-
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?
-
-
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...
-
-
There's a Common one, though.
Hehe, the Gruber/Attwood fracas. That was mildly entertaining, back in the day...
-
I'd rather dunk the doughnut; holes are rather insubstantial.
I'm surprised no one flagged this for a spellar badge.
-
I'm surprised no one flagged this for a spellar badge.
Nobody is stopping you from doing so.
-
There's a Common one, though.
But if nobody uses it, it's not really very common, is it?
-
I'm surprised no one flagged this for a spellar badge.
Missed that. Flagged accordingly now.
-
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.
-
INB4 STOP CHANGING THE DEFINITION OF COMMON.
Common, there's no need to yell...
Filed under: The Youtube comment section definition
-
What about Common?
-
-
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_scriptPresuming, of course, you have command line access to the server hosting the site....
-
-
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.
-
@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.
-
I think null_loop gave up on this.
-
Rightly so.
-
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.
-
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!
-
I think you want the determinism thread and/or the omniscience thread. ;)
-
One of those threads may imply the other.
-
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).
-
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 lineOk...
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 lineUh, 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.
-
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.
-
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.
-
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...
-
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
- have the syntax be xml and there's a tag for each letter
-
Write as a multi-level quine (Ruby -> PHP -> Python -> Java -> Node -> ...) so admin can choose which language to deploy wiki as
That's wonderful!
or whole page can < blink > constantly
One word: <marquee>
-
-
Auto-translating wiki (everything to
LatinEsperanto, it's a better language)FTFY
Pictures-only wiki (people only look at the pictures anyway)
That's what Reddit and Imgur are for already: posting screenshots of text from 4chan.
Entire wiki is one long page that anyone can edit
No fair stealing from Discourse!
Infiniscroll can follow links to other pages
You mean they just get injected? If so, ++!
make whole page Flash
Objection! We need a way to embed Java applets too!
-
Objection! We need a way to embed Java applets too!
Get the Flash to update the containing webpage to inject the instructions to load the Java applet. Job done.
-
Actually, I think you're right - I'll reword it as "The contents of a line cannot affect the output of any preceding line"