Entry

複数のマスタにきれいにデータを収める UI のメモ

2007年07月03日

複数ある既定の候補の中からいくつかを選び出す UI で,いいもんはないかと,なんとなく考えています。言葉で表現してもアレなので,どんな場合なのか,ちょっと図にしてみますね。

book_relation_example.png

例えば,こんな感じのデータがあるとします。やっつけで描いたから汚ないんですけど,大体の雰囲気は分かってもらえるでしょうか。一応説明しておくと

  • 本(Book)とその書き手(Author)の関係を表わす。
  • 本には複数の書き手がいる場合があり,書き手も複数の本を書く。
  • 書き手の関わり方も「著」「編」「訳」「監修」など,複数の関わり方がある。

みたいな感じ。よくあるタイプなので,これ自体は特に説明するほどのことでもありません。

で,このデータモデル──オブジェクトでもテーブルでもなんでもいいんですけど,ここに整合性を保ったまま,効率良くデータを保存する UI を考えているんです。つまり,マスターみたいなもんがいくつかあって,それらの整合性を保ちながら保存する方法です。

「整合性を保ちながら」というのは,「正規形を維持したまま」とほぼ同じような意味です。例えば,「鳥山明」(Author)が描いた「DRAGON BALL」(Book)を登録した場合,別の機会に「Dr.スランプ」を登録するときは,同じ「鳥山明」というレコード(またはオブジェクト)が選ばれる(Author に複数の「鳥山明」レコードは存在しない),ということです。

こういうときになんとなく思い付くのは,入力の対象となるオブジェクトの入力画面(例:本の登録画面)を用意して,もう片方のデータには,あらかじめ入力しておいたマスターの内容を表示する子画面やダイアログを用意することです。片方を選択項目として固定することで,矛盾が発生しづらくなります。del.icio.us のタグ入力なんかは,URL の入力画面に対する子画面(というか子領域)に,使えそうなタグが並ぶけれども,おおむねそんな感じです。

ただ,この方法は,親画面と子画面に多かれ少なかれ,主従の関係がないとなかなか作れません。del.icio.us の場合は,量的にも質的にも明らかに URL の方が主ですから,タグの入力・編集は二の次(子領域または別画面)の扱いになるはずで,現にそうした設計になっているようです。けれど,本とその著者(訳者等)というのは,どちらが主でどちらが従なんでしょう。

一般的に,蔵書の管理みたいな視点で見れば,本(Book)が主になるはずで,著者のデータは子画面の扱いになるはずです。量的にみても,そちらの方が自然かもしれません。けれど,かといって Author の属性が本と比べて元々少ないかというと,そういうわけでもありません。名前や生年月日,学歴・略歴,親交のある人間関係なんかを保存するとすると,本の方はむしろ従になりそうな感じがするわけです。入力項目の数も,本と大して変わらなくなってくるんじゃないでしょうか。

こう考えると,UI を作る際にどちらか一方を固定することがとても難しくなってきます。もちろん,要は「どういう使い方をするのか」がまず問われなくちゃいけないんでしょうけどね。ただ,ここで考えているのは,そういうもん(使い道)を考えなくても,自然に整合性の取れたデータを保存する方法はないもんかということなんです。

ここ数日,Yahoo! UI Library(YUI) あたりを参考にしつつ,よさげな UI はないもんかと考えているんですけれど,なかなかうまいアイデアが見つかりません。総じて Web2.0 な UI は,派手目なものの登録する内容は大して複雑ではないので,ここら辺の話はあまり問題にならないのかもしれません。書籍関係を扱った Web2.0 な UI も,Amazon ECS あたりから引っ張ってきた response を読み替えているだけだったりするみたい。手入力を基本にした場合の UI は,まだまだ発展途上といった感じです。

まとめるために文章にしてみたけれど,うまくまとまっていないのを見ても分かる通り,今だにうまいアイデアは沸いてきません。そういうわけで,今日はここまで。もう寝ます。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN