Among so many publishing platforms (Static Web Page, CMS, Wiki, BBS/Forum, blog, etc.), I chose blog after a lengthy trial-and-error process. Here I share my own considerations behind the choice. It is a bit technical but still highly relevant.
我用過許多出版平台（內容管理系統, 維基, 靜態網頁, 佈告欄, 討論群組, 網誌等）, 最後選擇用網誌來做個人出版. 我在這裡分享我的考量過程. 雖然以下內容稍偏技術性, 但我認為這些考量的確很重要.
(註:中文部份尚未翻譯完畢)
Please note that I write those with my personal need and personalexperience in mind; therefore, if your need and background is differentfrom mine, please be aware that these comments are unavoidly subjective.
以下評論完全是依我個人經驗及所需而發的。若您有意參考以下評論，請記得這些評論難免落於主觀而不具代表性。
Static Web Page 靜態網頁
| Pros 優點 | Easy to setup. 易安裝 Light and fast for server load. 對伺服器負擔小；速度快 Flexible structure and document flow. 網站文件結構具彈性 |
| Cons 缺點 | File upload hassels. 上傳檔案麻煩 Off-line HTML editors are inconvenient. 必須使用不方便的離線HTML編輯器 Searching not provided. 沒有內建的搜尋功能 Directory / file structure may become messy. 檔案目錄結構容易混亂 Unable to auto-date changes 無法自動標上日期 |
The traditional static web page is still the major authoring and publishing way because of its simplicity and flexibility.
One the server side, no database or file system writing permission is needed. A basic web server will handle static pages very well. It is also the fastest way to serve pages, compared to database and script driven systems. Simple HTML files are very easy to archive and backup as well. The idea of "one article, one HTML file" makes it easy to send the articles via email or to print.
However, managing many static HTML articles on one site is not easy at all. Adding, removing, or modifying a new article requires editing of the index file, and there is the file uploading hassle. I used to have a local copy of the website and the HTML editor will upload only the modified files to the website whenever I make some changes. After a while, the requirement of a specific HTML editor became very inconvenient for me. Whenever I see a typo on my page, I'll have to wait until I have access to that specific installation of HTML editor. Although it's possible to create HTML files with simple text editors, saving keystrokes become important after I started to have slight RSI problem.
The organization of directories and files can be hard. Both putting everything under one directory (wide tree) and making a complex tree structure (deep tree) have their problems in searching. A wide tree is bad for the author to quickly locate a specific file; a deep tree is harder for index file creation.
Auto-datingmay sound unimportant; however, I find it very crucial since Iconstantly update the contents but would like to keep track of oldupates for historical references.
Therefore, I know I need a database driven (thus implying script driven) system.
CMS (Content Management System)
| Pros | Rich features. Easy to extend or customize. Modular design makes it easy to manage. |
| Cons | Resource hungry. Potential security holes. |
CMS is a great answer to webmasters who need to provide a community many different services, such as discussion boards (or forums), news, specific content driven pages, messaging system, event calendar, polls, or any other specific services (bug tracking system, auction system, family tree, community dictionary, etc.). A centralized management system makes the webmasters life so much easier.
On the other hand, a generic CMS system is usually resource hungry. The higher level a framework is, the more abstract layers it has, and the slower it runs.
That makes CMS a perfect solution to build sites for small- to mid-sized communities (less than 50 users). I personally have had very nice experience with Xoops and phpBB. Both have great features and I think phpBB's forum is faster than Xoops' newbb 2.0 (as of year 2004). However, probably because of its long history, the code of phpBB was a bit messy in my opinion, so I ended up choosing Xoops to build sites for several communities. I became very familiar with the Xoops framework and was able to write customized modules.
However, for a personal webpage, which consists of mostly static pages (completed articles, in my case), the constant database access becomes a waste. A caching system helps, but then we still have the speed of the content-feeding script to consider. Some accelerating methods do exist and they do achieve reletively good results (by caching the compiled script (e.g. eAccelerator), residing codes in memory (e.g. fast-cgi), or some other optimization). Nevertheless, the resources needed for this purpose in exchange for speed are not completely justified in my case.
Wiki
| Pros | Good for authoring colaboration. Simpler and cleaner than HTML. Article version/history control. |
| Cons | Syntax not totally standardized. Weak in access control. CamelCase compromises appearance and conciseness. |
When I first learned about Wiki, I knew it right away that this is the answer to several of my needs:
- My first webpage back in 1994 already had a "My Dictionary" section, in which I tried to explain terms that were very sub-cultured. That saved me a lot of foot notes. However, creating the same links whenever I encountered those specific terms is very tedious.
- I had several chances to colaborate with several editors/translators and the version control system for codes didn't really turn out to be a good solution for non-technically-oriented writers.
- No matter how fluent one can be with HTML or any marked-up langauge, a clean layout and effective seperation of the content and the tags help the creative process a lot. I have worked in a linguistic project in which I had to be very fast in tagging lots (and I mean lots) of text. Having a quick and simple method to author, edit, and publish contents is very much called for.
While the concept of Wiki really appealed to me, searching for a good implement was harder than I thought.
CMS + Wiki mod
I thought it'd be nice to have both CMS and Wiki, so I tried Tikiwiki and several Xoops Wiki mods.
Tikiwikiis nice and powerful, but it's too slow and the code was too messy formy taste (as of year 2004), although I do like the easiness of writingmy own mods. Another thing I really like Tikiwiki is its great supportin multilingual posting. One can easily add another language for aspecfic article.
The Xoops Wiki mods were not bad in efficiency and tidiness, but most only provide simplified Wiki functions. phpWiki is ported as Xoops mods, but to combine its sign-in function with that of the CMS is a headache. There must be other good Wiki mods but I didn't get a chance to try them all since I alerady have a Wiwi mod (very nice work, by the way) installed on one of my Xoops sites and porting the contents to other systems would be tedious.
Again, CMS + Wiki mod isn't a good solution for simple personal webpage application, mainly because of the CMS part is too heavy.
Standalone Wiki systems
Erfurtwiki is very nice, particularly its flexibility in integration into existing systems. MediaWiki is very attractive in its look right out of the box. I think I would use one of the two, if I ever choose to use Wiki. Unfortunately, I didn't have enough time to try others.
Syntax
One big problems of Wiki systems are that Wiki syntax is not standardized. It means one Wiki article would always need a particular system to look right. Converting one Wiki article to another isn't hard, but converting a set of articles to another system is a pain.
Another thing I don't like is CamelCase. While CamelCase makes it super fast in making links, I think there are at least two drawbacks. First, it doesn't look natural. The problem is not only the lack of space, but also the lack of freedom in using lowercase in a keyword. For example, ThisIsALink is so much less natural than "This is a Link". Second, programming languages use mixed caes in variable names and CamelCase makes it very confusing if the article happens to mention variables in programming langauges.
BBS/Forum
| Pros | Easy for group discussion. Most people are familiar with forum systems. |
| Cons | Slow. Discussion, by nature, is less organized than articles. |
I have written and established several Bullitin Board Systems (ranging from unix BBS (from scratch) to dial-in PC BBS under DOS) and have posted many long articles. However, after a while, it became very difficult to find particular postings because they were buried with casual comments, discussions, and chats. BBS/Forum is for the community to talk to each other; it simply isn't for personal publishment. The other problem is that I often find it necessary to customize the forum systems, but
it's really too demanding for me alone to maintain and development my own system. This became very important when I started to realize my time and energy limitation.
Blog
| Pros | Simple to manage. Easy to add new articles. Easy to find old articles. |
| Cons | Inflexible indexing/structure. |
Blog is by default a convenient substitution for traditional static webpage authoring. The on-line wysiwyg HTML editors make it possible for me to edit my articles any time, any where. Adding a new article is very simple and the indexing is automatically done. With the help of database, one can quickly find specific articles. It is simpler, thus faster, than CMS and BBS/Forum, in most cases.
On the other hand, the automatic indexing does have its drawback. For me, date wouldn't be my first choice of the main index. For my audience, exactly which date I wrote some article isn't all that important. Blog (web log), however, implies things are written daily, like a diary or a journal. The primary logical index is chronological. In that case, one may click on December 1 and find an article on Mozart; December 2, on Jazz; December 5, on Meditation before Improvisation; December 9, on Linux file server optimization; and then December 15, an article comparing Mozart and Jazz. The problem here is we have three articles related to each other on December 1, 2, and 15, but there are two irrelevant ones (December 5, and 9) in between.
Of course blog developers were smart enough to realize the problem and they give each article a category, a tag, or a keyword, or visitors to easily find things. However, again, within one category (tag, keyword), the same problem still exists. The articles are still listed chronologically, instead of logically, or prosodically.
An obvious solution would be adding static page support in the blog system, but that would sort of destroy the overall organization. It's a trade-off problem.
Choosing Blog Systems
I have used and customized several systems for friends and families. Among them, WordPress and pLog remained in action. I chose WordPress for its elegant design and rich module choices, but it was a lot of work for me to add access control into that system. pLog is very nice and it has several very dedicated contributors in Taiwan, but I still had to do a lot just to integrate an wysiwyg HTML editor and an image editor into the system. I think things should be different by now.
However, in looking for my own blogging system, I hoped to find something more ready to use. The fact that Serendipity has an out-of-box Media Management system and an wysiwyg HTML editor was very attractive to me due to my previous experience. I also like the clean code of Serendipity. The cleaner code used to mean the ease of modification for me, but now that I decide to do as little job as possible in modifying the system, what it matters more to me now is actually security. I believe cleaner code suggests the coders are more organized and have better coding habits, thus less likely to leave security bugs.
Onecomplain I have, though, is its awkward multi-lingual support. For theinterface, it's good, but for contents, there hasn't been a satisfyingsolution yet. Now I write different languages into the sameentry; this is not easy for readers. Writing translations intodifferent entries makes management a pain. As mentioned before,one reason I really like about Tikiwiki is its great support in thisissue. Serendipity does have a multi-lingual plugin, but thatplugin stores the additional language into each entry's "additionalfields", thus increasing the searching load. I'd prefer a neatersolution, i.e. different languages of the same 'entry' should bedistinguished by language id and identified by, say, posting id. (Unfortunately we have to use 'entry' instead of 'article' here;otherwise, I think an 'article' can have different 'entries' indifferent languages. Perhaps we can say one 'entry' has several'tongues' in different languages. : ) )
In addition, Serendipity is said to be very slow, especially compared to WordPress + LightPress, which I have very good impression and experience (now that I don't need the user level access control for my blog). It was a bit hard for me to choose. I must admit that my choice of Serenpidity was mainly my hope for an even cleaner code than WordPress, and that, to be fair, is very subjective.
No comments:
Post a Comment