2008-01-17-01-Inside Japonica - 12 - 既読表示機能 - project-enigma

2008-01-17-01-Inside Japonica - 12 - 既読表示機能

>> Site top >> weblog >> 月別アーカイブ >> 2008年01月のlog >> 2008-01-17-01-Inside Japonica - 12 - 既読表示機能

最終更新日付:2013/12/31 07:37:40


Inside Japonica - 12 - 既読表示機能

2008 年 01 月 17 日

抜け殻のようになりながらも機械的に書いています Inside Japonica。第12回は既読表示機能について。なんかスゴいボリュームになっちゃいましたが。

この機能は、開発初期の要件定義段階から存在した機能でした。最初から前提として、「文書を開いたらマークする」というものだったわけですが、陰郎の心の中にはひとつ問題意識がありました。それはなにか。

「既読」とは読み終わったことを意味するのであって、読み始めたことを意味するのではないのでは?

まぁそういうことです。文書を開いただけでマークされるなら、マークの有無によってわかるのは「開いたことがあるかどうか」であって、「読み終わったかどうか」ではないですよね。そこがなんとなく引っかかっていたのです。

しかし、「読み終わったこと」を自動的に検出するのは事実上不可能です。テキストのすべてが一度は画面上に表示されたかどうかを調べる? まさかね。それだって「読んだかどうか」はわかりませんし、逆に「読了しましたよ」という操作をユーザーにさせるってのもおかしい。ひとつの手ではあるものの、そんな煩わしい機能が便利に使えるとは思えません。

まぁそんなわけで、ひとまず以下の仕様で動作するようになっています。

カード上のファイル用の既読情報ファイルは、japonica.readinfo というファイル名になっています。当然ですが、これは Japonica のファイル一覧ビューには出てきません。当初はカード上ファイルの既読情報も本体内データベースに保有する予定だったのですが、複数のカードを入れ替えることができることなどとの関係上、無理と判断しカード側に持たせることになりました。

ちなみに、なぜメモ帳データに関しては既読管理をしないのか。表向きの理由は、「メモ帳データの既読管理は必要ない」というものです。なぜなら、基本的にメモデータというものは「ユーザー本人が作成したデータであり、後から『読み返す』ために保存してあるもの」だからです。もちろんこれは陰郎の主観ですし、そうは思わない方もいると思いますが。

しかし、陰郎の信条は「止むを得ない事情がない限り特別な制限を設けず可能な限り統一を維持する」です。それに従えばメモ帳データも既読管理をすることになったでしょう。実は、裏にはそれなりの理由があったのです。それは、「カテゴリ別表示の関係で孤立既読情報の自動削除が困難」というものです。どういうことか。せっかくですしオチもあるので説明しましょう。

基本的にメモ帳データというのは1つの集合ですから、Doc データと同じように「メモ帳データ用の既読情報データベース」を1つ作っておく、という方法が考えられます。それによって一覧に表示するメモが既読情報データベースに含まれていれば既読、そうでなければ未読‥‥‥ここまでは問題ありません。そして、文書一覧を作成する際、既読情報データベースにあるが実在しない文書は削除されたものと見なして既読情報データベースからも削除します。これも問題ないように見えますが、ちょっと問題があります。それは、カテゴリ指定で一覧を表示している場合、削除されていなくても一覧には表示されない、ということです。そのような既読情報を削除してしまうと、ユーザーがクリア操作をしていないのに既読情報が失われてしまうというバグになります(この時点ですでにオチは見えつつありますね)。では、カテゴリ別に既読情報データを管理するというのはどうか。これは2つの点から困難があります。メモ帳データはカテゴリの変更が容易であること、および、「すべて表示」が可能であることです。つまり、カテゴリ変更をしただけで既読が未読に戻るのはマズいし、「すべて表示」の場合にはカテゴリ別既読情報データベースを全部みなきゃならないわけです。これもマズい。

そうなると、残る手は既読情報はメモ帳データ全体で1つの管理とし、「すべて表示」を選択したときだけ孤立既読情報の自動クリアを行う‥‥‥ということになるわけです。しかし、メモ帳データをカテゴリ指定せずに全部表示することをユーザーに期待して良いものか? それには少々無理があります。少なくとも陰郎はまずやりません。では「既読情報のクリア操作」をユーザーがしてくれることに期待する? いやいや、それがそもそも定期的に確実に実行される保証がないから自動削除を検討しているわけです。そこに依存するのは本末転倒でしょう。ユーザーがその操作をしてくれない限り、長期的には既読管理データベースがどんどん肥大化していく‥‥‥これは潜在的にリスクですよね、ということからメモ帳データについては既読管理をしない、という仕様にしたのでした。

さて、3段落前の最後の文で「オチがある」と書きましたが、一体なにか。それは、「上記の議論はフィルタリングについても言える」ということなんですね。Version 1.30 でフィルタリング使用時に既読情報が不正に削除されるというバグを直していますが、これはまさに上で書いたことと同じような条件下で既読情報を誤って削除してしまっているというものなわけです。で、修正方法は「フィルタリングがかかっていない場合のみ自動削除をする」というもの。ありゃりゃ、これではフィルタかけっぱなしの人は既読情報が肥っていくことになりますね。つまりオチというのは次のとおり。1.メモ帳データを対象外にした時点で上記の問題点はわかっていたにも関わらずフィルタリングに絡んでバグのある実装をしてしまっていたこと。2.そしてそのバグを直したにもかかわらず仕様上の(上に書いたような)問題点を解決できていないこと。3.最後に、そんなオチにこのエントリの原稿を書きながら気づいていること。 ─── 陰郎はソフトウェアデザイナとしてはもう寿命なのでは‥‥‥と真剣に思いました。今。

続く

 

コメント

このページにコメントする

 

このページのタグ

Page tag : Palm

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.