OldType.開発の経緯 / 下記のような問題点を解決できれば使いやすいWikiができると考えた。

下記のような問題点を解決できれば使いやすいWikiができると考えた。

とにかく、これからのWikiは文書の更新時の手間を減らすことが重要と考えた。

既存CMSの問題点と解決策

Wiki記法が初心者には取っつきにくい。特に、文書構造を表現する構文ルールが多すぎる。

覚えればすむことだが、20から30のルールがあり、全て覚えて使いこなす人は少数。ルールの数を減らすべきだと思う。

結果がすぐにフィードバックされれば改善される可能性があるが、そのようなWikiエンジンは少数である。

そこで、Wikiの編集単位を行指向にして、1行の編集結果のフィードバックを細切れにすれば改善できると考えた。

もうひとつの問題は、WebベースのWikiエンジンでは大量の文章を編集するのには向かないというのがある。

ブラウザのWebフォームで済ませられる編集量には限界がある。

そこで、Subversion、CVSなどのリビジョン管理サーバーでコンテンツを管理し、Web以外の編集手段も用意したり、

Web APIを用意して、Webブラウザ以外のクライアントからでも編集する手段を用意する。

blogでは時系列に生みだされるフロー型のコンテンツを扱う。

フロー型のコンテンツでは時間が経ったコンテンツにはコメントがつけにくく、内容のブラッシュアップが止まる。よって、情報蓄積に向かないと考える。

そこで、次の様にWikiのシステムの範囲内でフロー型のコンテンツも扱いやすくすればWikiとblog双方のメリットが融合できるのではないかと考えた。

blogに書いた記事をWikiのような情報集約的なコンテンツに移したい場合を考える。

例えば、blogエントリを全てWikiページで作成し、ページのネーミングによってフロー型のページか蓄積型のページかを管理する。

2008_01_01といった日付形式のWikiページをフロー型コンテンツと定義し、blogエントリとする。

日付形式のページは自動的にblogページとして再構築するような手段で従来のblogページと同様の購読スタイルも可能なようにする。

日付形式以外のページを蓄積型コンテンツと定義し、通常のWikiコンテンツとして扱う。

日付形式のページを意味のある名前にリネームすることによって、フロー型から蓄積型コンテンツへ移管することも可能。

また、Wikiの全ての記事にコメントを付けれるようにすれば、blogで一般的なコメント機能も実現できる。

まずはプロトタイプを作ってみて運用してみることでアイデアを検証していく。

システムが用意したAPIの範囲でしか拡張できないため、応用範囲が狭い。

システムが記述された言語と同じ言語で拡張するしかないため、外部のツールとの接続性が低い。

そこで、Subversionの情報を改変してコミットするプログラムを追加するようなシンプルな拡張方法を提供すれば手軽に機能拡張できると考えた。

機能拡張の例

最近の人気記事リスト ( アクセス数順、コメント数順、ソーシャルブックマーク数順 )

携帯メールによる写真付き記事の投稿

外のblogやnewsサイトからの記事の取りこみ (Plaggerなどアグリゲーターを使うことを想定)