Wandering Thoughts archives

2012-11-24

Simple markup as a style guide and limiter

Beyond perhaps making authoring easier, there is a more subtle reason to use simple markup instead of full HTML, namely that simple markup can be deliberately limited. HTML is a very broad and general formatting language, which means that if you let people write in raw HTML they can do all sorts of odd layout things, things that do not necessarily fit into the style you want. Using a simple markup language limits people's ability to be off-the-rails creative in this way.

(While you can do the same thing by letting people write in HTML and then filtering the HTML, this is more error prone and less user friendly than a simple markup language. It's always better to just not give people a way to do something to start with than than to let them do it and then tell them 'what you did isn't acceptable'.)

In a markup language without escape hatches to HTML, content authors get exactly the style and the options that you put into the markup language and it comes out formatted exactly as you want it to be. If people have escape hatches like doing diagrams in preformatted text they are generally very glaringly obvious and ugly escape hatches, ones that are not very attractive except if people work very hard at it.

(My feeling is that the more you want a very simple and minimal presentation, the more you need a constrained markup language; people seem driven to add formatting to 'pretty things up' if they possibly can. This goes especially so if you have little control over the content authors, for example if they're random outside people who feel like writing stuff for you.)

This still works to some degree even in a good simple markup language with escapes to full HTML. Since people will usually take the easier path if it works, your simple markup becomes a subtle (usually) way of steering people towards doing things the way you want them. Sure, they could go write raw HTML, but as long as your markup works most people will stick to it. Even if people go outside your markup, your markup is still a strong hint as to how you want things to be done; it expresses a style and an approach that people will be drawn to in general.

(A corollary is that this works best for areas that your markup covers. For example, if your markup has no way to do tables at all and everyone has to do them by escaping to raw HTML, people have no guidance for how you want tables to be structured and to look. Expect anarchy and any number of tables that don't really fit in.)

The more complete, flexible, and HTML-capable a simple markup dialect is the less it intends to have this sort of editorial opinion (it may still have some simply by virtue of what it does and doesn't make easy). Conversely, a very small simple markup language is a very strong and hopefully deliberate editorial opinion on what sort of style and presentation is desired.

SimpleMarkupAsStyleGuide written at 02:24:43; Add Comment

2012-11-21

The varying appeal of wikitext and other simple markup

After letting the issue sit for a while, we've recently started thinking about our wiki trap again (partly because the support period for the OS our wiki is running on is rapidly running out). One of the questions for any replacement is whether we'll write the content in straight HTML or in some simple markup scheme. Having this question on my mind has made me think about the varying and relative appeal of wikitext to different people. For this, let's break people up into three different groups, which I will call frequent authors, genuine beginners, and moderate authors.

For frequent authors I continue to believe what I've written before, that simple markup languages reduce the friction of creating raw HTML and enable you to focus your effort on what matters. This is the case I fall into with Wandering Thoughts and using a simple markup language has been extremely useful for me (most of my entries have very little besides plain text). While you do have to learn the potentially special-purpose (simple) markup language, the long term time savings and reduced friction make it worth it in the same way that heavy users of anything should get good interfaces even if they're non-standard.

(In fact optimized simple markup languages are exactly this if you take a somewhat expansive view of 'interface'.)

For genuine beginners with no real experience with HTML, a good simple markup language is probably easier to immediately produce content in without a big hassle and learning experience. This is not necessarily because simple markup is hugely simpler (HTML is pretty simple, really) but because simple markup gives you far fewer ways of blowing your foot off than HTML does. Put a < in, leave a > out, forget an ending element, and all sorts of unpleasant things can happen to your HTML content. A well designed simple markup language does not let you do these things or limits the damage that they do, resulting in a faster and less frustrating authoring experience.

(My feeling is that this is pretty dependent on the markup language being readable and memorable. For all its flaws and irritation, HTML is good this way; you are not going to mistake <b> for <i> in the way that you may confuse, say, `` and ```` (quick, how many `'s is that?).)

For moderate authors, especially people who produce stuff across many sites, your simple markup probably sucks. These people already know HTML and they aren't going to be writing enough for you to make learning your simple markup language a time win, especially if they have to re-learn it almost every time they write more because it's been a relatively long time since they last used it. You can reduce the advantage of HTML by making your simple markup widely used, so learning it once pays off not just on your site but also on other sites (but this only works if your authors also author stuff on those other sites).

(Hence part of the attraction of Markdown (in its small variants). If a bunch of significant sites and software all agree on Markdown, it becomes more of a win for everyone.)

Having written all of this down, I've now come around to the views of my co-workers (they like HTML, I like simple markup). Our situation with our documentation is most like the moderate authors situation; we all already know HTML and we are just not going to be writing documentation all that often. While I reflexively like simple markup it's hard to see how it would be a win for saving time and reducing irritation. The possible way out would be to persuade my co-workers that they're going to want to know Markdown in the future anyways, but I'm not sure that that's true in practice.

(There are other reasons to use simple markup besides the convenience of your authors, but that's another blog entry.)

SimpleMarkupUserLevels written at 01:24:55; Add Comment

2012-11-20

Where my Firefox performance problem seems to be

I've written a fair amount before on how Firefox (doesn't) perform for me, but it's time for what will probably be the final update on this (since I don't expect the Firefox people to fix whatever the core problem is).

The short summary of my problem is garbage collection stalls. I was mostly lead to this by stumbling over the MemChaser addon (via), which shows the amount of time that Firefox pauses for garbage collection. When my Firefox session is new and its memory usage is low, these GC stalls are short, but as memory usage climbs they rapidly lengthen (when I have MemChaser active, I can watch its duration reports turn red over time). This correlates well with my observed symptoms of Firefox stalling on various operations when it gets bogged down. Outside of GC stalls performance is decent, but once the GC duration rises any time a collection happens things lurch to a pause.

(Of the two durations reported by MemChaser, cycle collection is usually significantly longer than garbage collection.)

This still leaves the question of why Firefox's steadily growing resident set size is having such a catastrophic effect on garbage collection times. I don't have an answer to that one. My impression is that Firefox can in general get up to over 1 GB of resident memory without melting down, but I say this mostly because Mozilla people seem more concerned about swapping than usability meltdowns.

(I can speculate about things like memory fragmentation, maybe involving lots of little objects and maybe caused by or increased by one of my addons, but I don't actually know. I'd be interested to know if people can run large Firefox sessions without GC stalls, say with MemChaser showing over a GB resident but with low collection durations.)

All of this has kept happening despite the Firefox 16 switch to incremental GC, and continues to happen both in Firefox 17 and in current nightly builds (which I've started trying out). Things have reached the point where I have to restart Firefox around once a day in order to keep it usable; fortunately I have tools to make that easier (plus Firefox's setting of 'on startup, show the windows from last time'). If I did not, I think I would be really angry at Firefox.

Note that MemChaser can be disabled and enabled on the fly without a Firefox restart. I find this very convenient since it takes up precious bottom status bar space when enabled (and worse, a variable amount of space).

PS: These days I don't seem to have any significant amount of zombie compartments or obvious memory leaks. To the extent that I can spot any significant memory growth in about:memory, it seems to be in compiled JavaScript code.

MyFirefoxPerformanceII written at 00:21:45; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.