There's always a trade-off between optimizing for reading and for writing.
Is this a fundamental difference between the way information is structured as its being entered, and when its read? Or is this just a difficulty in designing an interface that caters to both needs? If the latter, what work has been done/should be done into separating the two? CMS vs Public webpage is the obvious split, but are there better ways to do it that make content editing far easier? How about using XSL/CSS tech to form pages according to desired function?
Can't remember the name of the wiki-style app I played around with.. will look it up later.
I think it's fundamental to the structure. And certainly can't be hidden behind an interface.
I just started this page in response to the Ward quote so that's why it mentions wiki, but you come across it in database design all the time. When you optimize for writing you simply put the data in, when you optimize for reading you add lots of indexes to speed up the queries. In some situations you may need to violate your normalization rules and put data in several times, or in fewer tables with empty fields etc. to make querying faster.
There are other trade-offs being made of course. Between TimeAndSpace, and between different kinds of queries. But the reading vs. writing trade is often there too.
Maybe you can distinguish some sub-classes of this trade off.
- reading speed vs. writing speed
- reading intelligence vs. writing intelligence (compare my discussion on WeblogsAndWiki. Maybe blogs are more optimized for writing than wiki because you don't need to think about context or categorization. But then useful browsing of blogs is harder than wiki without this extra information.)
TudorGirba complains we try to read code in TextEditors (tools optimized for writing) instead of making special tools for reading (including searching / analyzing code). Which is what GlamorousToolkit is about.