2005-05-12

Wiki と tDiary テーマは合わないんじゃないか

tDiary テーマに対する不満

tDiary テーマはたくさんあって便利だけど、扱いにくいなぁと思うことがよくある。いちばん感じるのは短いページの場合、やたらと下に空白ができてかっこ悪いということだけど、それに次ぐのは「tDiary ではユーザーに対するナビゲーションと管理者向けのアクションに区別がない」という点である。これらはすべて adminmenu という HTML class の中に入ってしまう。しかし横一列1にすべてのメニューが並んでいて、果たして使いやすいだろうか?

Wiki で tDiary テーマを採用するとメニューが窮屈では?

まぁ tDiary の場合は編集系のメニューはほとんどなく、全部 adminmenu 扱いでも別にいいかなと思う程度なのだけれど、これが Wiki になると話は別である。圧倒的多数の ROM に対して編集系のメニューを絶えず表示し続けるのはいかがなものか? もちろんフラットに表示することで Wiki のオープンさを表明することはできると思う。メニューを分けないことで誰もがこのコンテンツを編集できるということを明示する効果はひょっとしたらあるかもしれない。しかし使いやすいとは言えないと思う。

例えば閲覧の利便性から言えば検索窓は常に分かりやすい場所にあってほしい。sidebar に plugin などで表示するのもアリっちゃアリだけど、そういうよく使いそうな機能こそ上にきててほしくない? というか tDiary テーマ互換でないサイトの場合は右上の方に検索窓があるのは割とフツーなので、やっぱりその辺に配置したくなる。しかし Wiki の多彩なメニューをひとまとめに表示している場合は、検索窓はでかすぎて扱いにくい。だからかどうかは知らないけど、多くの Wiki では検索するために

  1. 検索のメニューをたどる
  2. 検索窓だけのページを表示してキーワードを入力する

という2アクションを要求する。個人的にはこれはとてもいやだ。

もちろん使い勝手はその Wiki の性格(コンテンツ)にもよるので一概には言えないかもしれない。ならばどれだけカスタマイズしやすいかということもまた重要なのではないだろうか。

tDiary テーマ互換とデザインのカスタマイズ

具体的なカスタマイズの話をすると、PukiWiki はあまり凝った作りをしていなので skin に該当する PHP のファイルを力任せにいじっていけばどんなデザインや機能もまず実現可能である。例えば標準状態では一直線に並んでいるメニューを Firefox まとめサイトのように分離してしまうことも、作業そのものはホネだが、技術的にはそう難しくない話である。(むしろデザインの力と HTML と PHP が複雑な if 文を挟んで混在する skin ファイルをきちんと調整する根性が必要。)

しかし tDiary テーマ互換の場合はそうはいかない。あまり HTML の構造に手を加えてしまうと、200もあるテーマから選べるというメリットが消えてしまう。それに新しい HTML の class を追加して adminmenu と navigation を分離することはできるかもしれないが、アプリの方で adminmenu が一つしかないことを前提に作り込まれていれば、その修正作業量はかなりのものになってしまうだろう。

今まさに FreeStyle Wiki に accesskey を付ける、という作業でメニューのカスタマイズについて考えている。PukiWiki の場合はメニューは全部 skin に集約されているので、skin をどれだけカスタマイズしても本体には影響せず、アップデートへの追従もしやすい。しかし FreeStyle Wiki ではメニューの構成は本体の方に入っているのでカスタマイズしてしまうとアップデートしにくくなる。そこでうまい具合に本家に取り込んでもらおうとしているんだけど、そもそも tDiary テーマ互換の場合はメニューのカスタマイズの自由度ってそんなに高くないんだよなということを改めて思っている次第。

便利なんだけどね、tDiary テーマって。でも Wiki に向いているとは思えないんだよな。HTML 的にも class="day" とか入っておかしなことになっちゃうし。tDiary テーマ互換を謳わずに、ある程度有名で、なおかつ今のうちなら skin のカスタマイズが容易な PukiWiki 当たりで Wiki 向けの共通テンプレートが作れたら面白くなるんじゃないかなぁ。

PukiWiki はなぜ table レイアウトなのか

ただ PukiWiki は標準の skin が table レイアウトだから、その辺で CSS によるデザインがやりにくいと思われているのかもしれない。これは歴史的な経緯によるもので、CSS によるマルチカラムデザインに対応していない Netscape 4 などのブラウザでも MenuBar(tDiary で言う sidebar)がちゃんと表示されるようにという配慮からくるものである。当時 Reimy 氏は苦渋の決断と言っていたように記憶している。なぜ MenuBar にこだわったのかは記憶にないが、Wiki の場合は、特にページ数が増え、内容が多岐に渡った Wiki の場合は MenuBar があった方が確かに便利だなとは思う。そこでマルチカラムデザインを守るために table を採用したというわけだ。これなら w3m でも使い勝手が大きく変わらないし、実際使ってみて便利だなと思う。

しかしそれも含めて再検討してもよいんじゃないかと個人的には思っている。PukiWiki 1.4 以降は UA ごとに skin を細かく切り替えられるので、tty 用ブラウザは table レイアウトで、グラフィカルなブラウザの場合は CSS レイアウト、という具合に分けるのもアリだし、今さら Netscape 4 のことを考える必要は、少なくとも非商用プロダクトの場合はないと思う。2

まぁいちばんの問題は、例によって「じゃあお前が叩き台作れよ」と言われてもちゃんと作り上げる気力が自分にはないってことか。作るだけじゃなくて結構な量の議論をこなさないと標準的なテンプレートに育てることはできないしねぇ。

  1. かどうかは theme の作りによるけど 

  2. ただ難しいのは 1.3 系をどうするかだけど。PukiWiki は未だに 1.4 は開発版という位置づけなんだけど、これってどうなんだろ。そろそろ 1.3 から 1.4 への移行を促してもいいと思うんだけど。1.3 のことを考慮しながらの開発は結構きついんじゃないかなぁ。 

About

例によって個人のなんちゃらです

Recent Posts

Categories

Tool 日々 Web Biz Net Apple MS ことば News Unix howto Food PHP Movie Edu Community Book Security Text TV Perl Ruby Music Pdoc 生き方 RDoc ViewCVS CVS Rsync Disk Mail FreeBSD Cygwin PDF Photo Zebedee Debian OSX Comic Cron Sysadmin Font Analog iCal Sunbird DNS Linux Wiki Emacs Thunderbird Sitecopy Terminal Drawing tDiary AppleScript Life Money Omni PukiWiki Xen XREA Zsh Screen CASL Firefox Fink zsh haXe Ecmascript PATH_INFO SQLite PEAR Lighttpd FastCGI Subversion au prototype.js jsUnit Apache Trac Template Java Rhino Mochikit Feed Bloglines CSS del.icio.us SBS qwikWeb gettext Ajax JSDoc Rails HTML CHM EPWING NDTP EB IE CLI ck ThinkPad Toy WSH RFC readline rlwrap ImageMagick epeg Frenzy sysprep Ubuntu MeCab DTP ERD DBMS eclipse Eclipse Awk RD Diigo XAMPP RubyGems PHPDoc iCab DOM YAML Camino Geekmonkey w3m Scheme Gauche Lisp JSAN Google VMware DSL SLAX Safari Markdown Textile IRC Jabber Fastladder MacPorts LLSpirit CPAN Mozilla Twitter OpenFL Rswatch ITS NTP GUI Pragger Yapra XML Mobile Git Study JSON VirtualBox Samba Pear Growl Mercurial Rack Capistrano Rake Win RSS Mechanize Sitemaps Android JavaScript Python RTM OOo iPod Yahoo Unicode Github iTunes God SBM friendfeed Friendfeed HokuUn Sinatra TDD Test Project Evernote iPad Geohash Location Map Search Simplenote Image WebKit RSpec Phone CSV WiMAX USB Chrome RubyKaigi RubyKaigi2011 Space CoffeeScript Nokogiri Hpricot Rubygems jQuery Node GTD CI UX Design VCS Kanazawa.rb Kindle Amazon Agile Vagrant Chef Windows Composer Dotenv PaaS Itamae SaaS Docker Swagger Grape WebAPI Microservices OmniAuth HTTP 分析基盤 CDN Terraform IaaS HCL Webpack Vue.js BigQuery Middleman CMS AWS PNG Laravel Selenium OAuth OpenAPI GitHub UML GCP TypeScript SQL Hanami Document SVG AsciiDoc Pandoc DocBook Develop Jekyll macOS Node.js Vite Heroku Transformer AI Data Cloud Wasm