WikisAreUgly

There’s no point in denying it: There is a perception amongst non-users that WikisAreUgly. Perhaps this is a misperception- perhaps this is a valid call-to-arms. This perception is slowing WikiAdoption.

Some wiki proponents argue for ContentOverForm. Yet, aesthetics, properly practiced and tested, could increase the usability of wikis (without affecting accessibility). Increasing the usability, hence the usefulness, would augment the content. It seems that the wiki community are merely on the verge of catching up with the design revolution that occured since 2001: web-standards compliant accessible design that does not sacrifice ContentOverForm.

  1. Why are wikis ugly?
  2. Discussions about wiki beauty
  3. Role of aesthetics in wiki design and web design in general
  4. List of pretty wikis, dispelling the myth
  5. List of wiki software that offers good suport for XHTML and CSS

(refactored from a blog postHeatherJames)

Why Are Wikis Ugly?

Is there a historical reason?

Perhaps it is because too few wiki software supports XHTML and CSS, as discovered on the Roadmap for future wikis 10 Sep 03:

“My first problem was finding any package that could output good html. Only a handful (maybe 3-4) could pass the HTML validator for anything beyond HTML 4.01, but all but one still output terrible markup. They either use line breaks instead of paragraph elements, or they forget to use closing paragraphs. Some packages output html in CAPS so you’ll never get xhtml out of them without doing modifications.”

See below for wiki software that support XHTML/CSS. Note that some wiki developers don’t see the point of outputting XHTML when their HTML is valid, unaware that the W3C is promoting XHTML as next generation of HTML and proper doc type declarations can ensure the quality and clarity of a page across a variety of visual display, printing, projecting and audible reading devices; combined with the judicious use of CSS.

The designers with design skills, on the other hand, don’t have the programming skills to hack wiki software. It has been suggested that the nature of wiki- by putting the creation of pages in the hands of the user- undermines the designer role. Designers may see themselves as GateKeeper?s and hence designers may feel threatened by a tool that subverts this control. But designers of community spaces want to provide useful tools for communication. Also, many designers are glad to find any kind of CMS or tool that can keep them from the tedium of editing HTML. It’s unclear if these threatened designers exist- but they’re not going to come over to wiki anytime soon.

That said, wiki technology and wiki culture has not really worked hard at giving a channel for those who express themselves through VisualLanguage. Most WikiEngines get to the point where one can upload and embed images into a wiki page, and settle back on their laurels. CollaborativeGraphicDesign using wiki is minimal, limited to a few experiments with WikiWhiteboard?s and the like.

The problems is that implementing an application that can easily download and upload files is difficult, since you can no longer rely on pure HTML and CSS – you need Javascript to run code on the clients. Which gets you into browser compatibility issues.

OnlineCommunitiesAreCityStates

Perhaps it is simply because wikis have not yet attracted those concerned with aesthetics, as Sunir illustrates on MeatBall:ContentOverForm.

Discussions about wiki beauty

From: Brent’s Law of Wikis

“I want to like wikis. But for some reason every wiki I’ve ever seen is, well, ugly.”

The comments on the initially superficial blog post above offer a good discussion about aesthetics and wikis, the comments offer more in-depth discussion, especially about the problems of the textual layout, and legibility.

Conversly, this article at Corante praises the simplicity and lack of visual context, and the un-designing of wikis: Wikis Are Beautiful

“Context is gained from the page’s revisions, links and how it is referenced by and navigated from other pages. Wikis excel at logical context whereas blog excel at temporal context.”

The writer above was responding to this article: Why I Don't Like Wikis by Elizabeth Lane Lawley

“I’ve tried. I really have. I installed phpWiki on my own server, and used it for a curriculum development project that it was well suited to. I’ve participated in the wiki-based development of content hosted at Socialtext for the emergent democracy and social software groups… I love their functionality. I really do. It’s very very cool to be able to do “ridiculously easy” collaborative document editing… But… let’s face it. They’re ugly.”

In The Ugly Wiki 01 May 03 and The Ugly Wiki (Part Two) 21 Aug 03, the designer Tom Coates sees this is merely a design problem. In the first post he chided Liz Lawley for being overly contentious. In the second he discusses how he tackled this for a BBC wiki, with technical info.

Clay Shirky feels that making wikis less ugly could potentially undermine their usefulness

“There are things wiki designers can do (better default style-sheets, experiments with two-column layout and “edit this column” buttons, Textpattern-style input areas), but the risk is that by making wikis less ugly, they will also be making them less conversational and therefore less useful.”

Joi Ito’s wiki has a discussion about 7 Are Wikis Ugly?

Well I think with the use of CSS wikis don’t have to be uglier than other sites. There’s nevertheless the tendency towards simplier designs. I don’t like Flash or huge image-constructions. – Tim

Role of Aesthetics in Design

Aesthetics in wikis for better InterWiki usability?

Does McLuhan explain why some people think Wikis are beautiful and some people think they're ugly? 29 Apr 03

“When I am on a Wiki, the way it looks really doesn’t concern me as much as trying imagine and understand all of the context that is captured in the web of pages linking to and from the page. I imaging all of the people from all kinds of places and what they must be thinking. It’s less about user interface and more about code.”

I disagree! I am completely confused between 4-5 wikis right now that i’ve been reading, and I think this is exacerbated by the fact that they all look exactly the same, minus the corner icons. For example, I may remember something interesting I read, but did not think to bookmark or subscribe to. I can even remember where on the page it was (top or bottom) but sometimes I can’t remember which wiki it was on.

I was wondering if anyone else thought that considering aesthetics in the design of wikis could increase usability? Or is the purity and simplicity of wikis better? Is my confusion a good thing? Maybe it is?

There would be other issues to bring up with aesthetics, but in terms of at least differentiating between wikis, and giving each a kind of visual identity- considering aesthetics could create better InterWiki usability.

HeatherJames

Exactly, Heather. I don’t see any particular reason to throw out all design experience because gosh, woo, wikis are something new and pure. And while nobody might have done any research yet, my anecdotal evidence concurs with yours; i find distinguishing between different wikis based on the same engine extremely hard if people haven’t even changed the colours, colours and layouts are memory aids for me. And good design definitely aids my willingness to contribute (showing the formatting rules when editing, for example). As regards preserving how conversational wikis are, in my experience with a wide variety of online fora, wikis don’t stand out as a positive example. While I recognize the danger of making things too pretty (which might well keep people from jumping in and contributing), there’s undoubtedly a comfortable middle ground to be had, and I’m in favour of heading towards it. Content and form, please. – piranha

Agreed. While I certainly agree that web designers often deliberately create truly obtuse markup, stylesheets and scripting in order to tweak a page into form, there’s no reason why the relatively simple markup of a wiki page can’t look attractive, unique, and easier to read by simply providing a reasonable stylesheet. Long before the web existed it was known that long line lengths are very difficult to parse. That’s easy to fix in a stylesheet. Long before the Web there’ve been known good principles of design. Good design is good design, it doesn’t need 1 pixel GIFs.

Secondly, there seems to be some misconception about the complexity of XHTML. XHTML is essentially identical to HTML 4 except for lowercasing the tag names, properly quoting attributes, and requiring end tags where they were optional. In this sense XHTML is quite a bit simpler than HTML 4 because it is more consistent. The kinds of tweaks necessary to wiki engines to make them produce valid XHTML or at least “well-formed XHTML” should be relatively minimal. If wiki software doesn’t produce XHTML markup now, it certainly could. – MurrayAltheim

That’s all fair enough. But I think there’s two distinct issues here: one is user interface design – that is, making something that people can use well. And the other is graphic design – making something that looks pretty. I’m not sure they’re the same thing. I’d say text line length would be a UI problem; being ugly is a graphic design problem. Maybe WikisAreHard? would be a place to deal with the UI issue.

I also think that XHTML is a red herring here. HTML + CSS makes making nice pages easier, but it’s not 100% necessary to make nice pages. It’s like someone saying that wiki isn’t any good because most wiki have poor or non-existent three-tier architecture and woefully inadequate object frameworks. It’d make programming under the covers easier, but most users never know, or care, that it’s there.

Wiki is the macrame of Web development. Anybody can do it. It’s not artsy; it’s craftsy. Wikis won’t win design awards. But they give creative outlet to people who don’t or can’t do HTML. The people who care about pixel-twiddling don’t need wiki. We should worry more about the people who do. --EvanProdromou

But Evan, if anything, being ugly is a red herring. It sounds akin to promoting low art over high art. In this sense it may be a legitimate philosophical stance, but it’s not a technical one. Let’s separate out three groups:

  1. wiki programmers. Unless most wiki sites are written from scratch, my guess is that most use a relatively small number of engines, written by programmers. Someone proficient enough to write wiki software is certainly proficient enough to create a CSS stylesheet or write software that can generate reasonable markup. Wiki pages generally use pretty simple markup, a lot simpler than any programming language. And XHTML is not more complicated than HTML, it’s actually simpler, as the rules are more regular.
  2. wiki administrators & designers. These are people who download and install wiki software on a server, then run the wiki. They can customize the page templates and CSS stylesheets to make the pages look better. As Heather has noted, many don’t. It’s the responsibility of both the wiki programmers and the site administrators to create the “look & feel” of the site. From the administrator’s perspective, this means having enough sense to choose wiki software that generates reasonably-attractive pages, and/or the knowledge to alter the provided stylesheets to do so. Very few of the wiki pages I’ve seen have complicated markup or stylesheets, even the good looking ones.
  3. wiki users. Most people never come near HTML or CSS. They just edit in wiki text as I’m doing now. They are not affected by the complexity or the simplicity of the markup or CSS because they never see it. They only have to live with the ugliness, they have no control whatsoever over the “look & feel” of the site.

None of these three groups need do any pixel-twiddling to create a better page. I could create a CSS stylesheet for this site without requiring any modification of the site’s markup at all (I’ve done it here), that would improve the site both from a graphic design and usability standpoint. I’m not a CSS expert. The wiki can still be macrame, but it can be attractive and usable macrame. People do hang truly ugly macrame on their walls, but they don’t need to. And no, XHTML is not a requirement. But having reasonably well-formed markup means that the pages render correctly across all browsers, browser versions, and operating systems. It means that stylesheets can be written to reliably work with that markup. Bad markup is just laziness on the part of a programmer, just as is bad writing on the part of a writer. There’s no good excuse. Generating good wiki markup is not rocket science, it’s quite simple (compared to other things wiki software does). Wiki pages themselves can be quite simple. Good design is often simple. There’s no need for any greater complexity. Honestly, all that’s needed is a better stylesheet. – MurrayAltheim

When I look at pages that people find non-ugly, the 2 attributes I find most often are (a) lots of side-bar schmutz to make the page feel less monolithic, and (b) tiny fonts (I may be biased - WebSeitzWiki:MiddleAgeMan) so that there’s actually some room for content in between the schmutzBitz. In all 3 contexts that I uses wiki (my WikiLog, my closed TeamWiki?, and reading other personal/public wiki) I find that I like to open lots of windows (even if they’re grouped via Mozilla tabs), so I like the liquidity of a relatively monolithic text block (e.g. a small window is quite readable, the content doesn’t become 3-letters wide to make room for a calendar). (Disclaimer: I never complained about the web being ugly in 1998.)

The Elftown artist community has a wiki (I don’t even know if you can access it without logging in). Now, Elftown is supposedly full of artists (it’s the “community portal” of Elfwood, a great fantasy art site). However, it’s wiki is arguably the most ugly and unwieldy I have never seen (I think it’s home grown).

So it’s probably not just about “attracting those concerned with aesthetics”. (Or, different tastes. Maybe the Elftown people find their wiki beautiful)


Pretty Wikis

Got a pretty wiki? Know of one? Add it here. If it’s not white background and black text spread wide across the browser- it is dispelling the myth!

A commercial wiki makes bad Zauber in wikilandia which is a free and open world. See? You are already in a more or less subtile way spamming here and that poisons a page. [[confluence?]] we can discuss it here, if you feel like. But don’t rely on this turning into a commercially very helpful page. Best would be you make a homepage, maybe even UseRealNames, then the welcome and bonobo stuff as usual. I think confluene is ok as far as beauty is concerned, what makes it ugly, a candidate for UglyWiki?, is that it’s commercial. Yakk! And stop spamming, got me? – MattisManzel

List Wiki Software with XHTML/CSS Support


CategoryWikiAgenda

Discussion

I have a co-worker who’s a designer. He wanted to use a wiki, and I pointed him to the OddWiki.

He loved it!

At any rate, in one day, he made this.

I said: “Wow! That’s really good!”

“I mean.., that even makes wiki look good,” I continued. I remembered this page.

He said, “I can’t help it; I’m a designer!”

AlexSchroeder, he said he appreciated the Oddmuse documentation and stuff, as well. He said it was a big help.

He was fascinated with how easy it was to make new pages. I think that was his favorite thing.

But anyways: With even meager tools, (WikisAreUgly,) a good designer can go a long ways.

Sometimes people think that products (eg. software) should be both customizable and look good, even if they are not designers. In my experience, that is plain wrong. All the good designs I’ve seen where there product of long hard nitty-gritty work deep withing the entrails of HTML and CSS. Since a lot of non-designers are writing wiki software, and they can’t just steal good design, the net result is that most wikis are in fact ugly. But they are not ugly because they are wikis. They are ugly because not many designers have chosen to work with wikis.

I’m glad your friend liked the documentation. To me, the documentation is even more important than the code. Without docs, nobody will use the code. So docs should come first, always. As more and more extensions are written, I look less often at the documentation for the very basics. I forget whether they are good or not because I don’t read them. This disconnection from the work gives me an uneasy feeling. There are no unit tests for documentation I can run to feel better. :)

In fact, I think the Oddmuse:SiteMap could use some reorganizing.

I don’t believe there is any technical requirement that wikis dooms wikis to be ‘ugly’, especially since most of them support CSS at least at the site level, if not the page level. I was enthralled by the apparent beauty of this site which presents exactly the same page, modified only by changes to its CSS file(s)… http://www.csszengarden.com/

By the way, should we try a taking a postive view such as WikisCanBeAttractive? ?

A new entry of mine.

What do you think about this?

I like it. Lemme guess, the second from the left is Chaplin, the second from the right is Marx? ;)

btw: All my respect for going open source, Helmut. Well done!

Define external redirect: WikiPass MySQL UglyWiki WikisAreHard confluence WikisCanBeAttractive WikiWhiteboard TeamWiki GateKeeper

EditNearLinks: MediaWiki CollaborativeGraphicDesign WikiLog WikiEngine

Languages: