どのようなサイト構成にすれば使いやすいか、というのを考えることはウェブアプリケーションを作るうえでは当たり前のことである。
しかしながら、ちょっとした使い勝手の改良は一朝一夕では出来ない場合も多い。システムがそこそこ大きくなっているならはなおさらだ。ちょっとした使い勝手の改良のために見た目は変わらずとも裏側では別物アプリケーションが出来上がってしまうことは往々にしてある。
ビジネスの世界ではこのような場面に直面した場合は客を説得して改良を諦めさせるか、さらに金を出させて次回開発へとしゃれ込むか、技術者を鞭打って無料の大工事を行なうかになる。ちなみに、大抵は鞭が取られる。
で、ハルヒＡＡ保管庫の場合はどうなるか。ハルヒＡＡ保管庫はビジネスのためのサイトではない。あくまで一個人の趣味により作られているサイトである。話を聞いてくれる客もいなければ金を出してくれる客もおらず、かと言って自分で自分に鞭打つ自傷癖野郎がいるわけでもない。今この場で開発を全部放り出したっていいわけである。困る人、文句を言う人はいるだろうが、実際問題として生活上の利益のやり取りがあるわけでもなく、そのうちに別サイトへと移っていくであろう。
と、いうことを頭の片隅で考えながら、改良を加えるべきプログラムの量を考えているわけであるが、本当、かなりの量になりそうで参っちゃうね。
参っちゃうような改良の内容を以下に述べる。
・空の幹、もしくは枝を作成できるようにしたい。
現在のハルヒＡＡ保管庫では「ＡＡが絶対に一個以上ある」ことが前提になっている。これはデータの記録方法がテキストであり、ＡＡデータファイルを主軸にして森、林、木、幹、枝のそれぞれのマスタデータファイルは単なる名称保存をになっているためだ。
ＡＡ１ － 森名称Ａの林名称Ａの木名称Ａの幹名称Ａの枝名称Ａ
ＡＡ２ － 森名称Ａの林名称Ａの木名称Ａの幹名称Ａの枝名称Ａ
ＡＡ３ － 森名称Ａの林名称Ｂの木名称Ａの幹名称Ａの枝名称Ａ
ＡＡ４ － 森名称Ａの林名称Ｂの木名称Ａの幹名称Ａの枝名称Ｂ
ＡＡ５ － 森名称Ｃの林名称Ａの木名称Ａの幹名称Ａの枝名称Ａ
さて、上記五つのパターンを見た場合、一つ思うことがある。森名称Ｂのデータは無いのか、ということだ。現在の造りの場合、森名称Ｂは存在できない。森名称ＢのＡＡデータが無いからである。
無いならば作ればよい。しかし、上記のような問題をサイトに当てはめてみた場合、どうやって森名称Ｂのデータを作るのか、という問題に当たる。作るための方法が用意されていないのである。
ハルヒＡＡ保管庫ではこの問題を森名称から木名称までを固定で、幹名称、森名称、もしてＡＡデータをセットで入力させることで強引に解決している。ＡＡデータが用意されていることを前提で作っているわけである。
今回の改良ではこれを以下のようにする。
サイト
├森名称Ａ
│├林名称Ａ
││├木名称Ａ
│││├幹名称Ａ
││││├枝名称Ａ
│││││├●ＡＡ１
│││││├●ＡＡ２
│││││└新規ＡＡ追加
││││└新規枝追加
│││└新規幹追加
││└新規木追加
││
│├林名称Ｂ
│││├木名称Ａ
││││├幹名称Ａ
││││├枝名称Ａ
│││││├●ＡＡ３
│││││└新規ＡＡ追加
│││││
││││└枝名称Ａ
││││ ├●ＡＡ４
││││ └新規ＡＡ追加
│││└新規幹追加
││└新規木追加
│└新規林追加
│
├森名称Ｂ
│└新規林追加
│
├森名称Ｃ
│├林名称Ａ
││├木名称Ａ
│││├幹名称Ａ
││││├枝名称Ａ
│││││├●ＡＡ５
│││││└新規ＡＡ追加
││││└新規枝追加
│││└新規幹追加
││└新規木追加
│└新規林追加
│
└新規森追加
分かりにくいが、図にするとこうなる。ポイントは「ＡＡを持っていない森がある」というのがひとつ。そして、目に付くだろうが「新規追加の選択肢が宙ぶらりんになっている」ことである。つまり、「森や林の分岐を作る人が必ずしもＡＡデータを持ってこなくてはならないわけではない」ということ。仕切りだけ作って後は別の人がＡＡを放り込めばいい、という構図が出来上がる。整理整頓をする上では欠かせないことである。
パソコンを使う際に空のフォルダの存在は許されないか？ という風に考えてもらうといいかもしれない。フォルダ一つ作るのに必ずファイル一つ必要です、なんて言われたら相当使い勝手は悪くなるだろう。
だらだら書いたが、使い勝手一つ改良するだけでどれだけ手間がかかるか感じてもらえたのではないかと思う。
やる、やらないは僕の自由。やらなかったとしても物理的に責める人はいないだろう。
さて、がんばろう。