番外編。今度はWeb制作。
管理者紹介ページ
このページは割と「なんでもあり・実験場・サンドボックス」なページにしようと思った。
コンセプトは「層構造・テーブル（タブ）レイアウトからの脱却」。そしてたどり着いたのがこのグリッドレイアウト。漫画のコマ割りのように「組まれた」レイアウト。近年のWindowsのスタートメニューのようなものを目指した。まあWindowsもう年単位で触ってないけど……
確かに層構造やテーブルレイアウトは広く採用されているし、それに見合うだけの長所がある。そのすべてを語るには余白が足りないため割愛するが。
ただ、現時点での構想として「オブジェクト的なUI/UX」であることを目指したいと考えている。
「オブジェクト的な」とはどういうことか？
今の当サイトは「世界観、カルテ、プレイリスト」と左メニューがある。例えば「カルテ」でキャラを見ていて、誰か1人を気に入ったとしよう。このキャラについて言及したコンテンツが他にもないか探そうとした時、現状のUIのままだと「プレイリスト＞組織＞所属キャラクター（未実装）……」と「層構造」を潜っていく＝クリックを重ねる必要がある。これは不親切なように思われる。初見のユーザーはそもそも、プレイリスト配下にキャラ関連のコンテンツがあるかすら知らない状態だから尚更「探す」コストは重い。
そこで、カルテのキャラ紹介ページの中に当該キャラのプレイリストへのリンクを載せ、直接そこに遷移できるようにするのが（このケースにおける）「オブジェクト的な」UI/UX。「プレイリストへのリンク情報」を「キャラの属性（年齢・性別など）」と同様に扱い、直感的に「モノ」として認知でき、可用性を高めることが狙う。ただしこれは「属性」が増えすぎると、結局はユーザーが欲しい情報を「探す」コストが上がるので、取捨選択や見せ方の工夫に気をつける必要がある。また、データの構造も複雑になる。
プレイリスト以外のアイデア
「ストーリー」や「カルテ内のキャラ紹介文」の中にキャラ名・組織名・用語が登場した場合、その内容を参照できるようなリンク・モーダルを表示
SoundQuest「自由派音楽理論」や「クライマキナ」のサイトがちょうどこんなUI/UXになっている。用語へのアクセスが容易で親切。
層構造の選択に慎重な理由のもう一つに、この創作サイトは世界観やキャラついて知ってもらうのを目的としていることだ。つまり属性に焦点を当てた断片的な情報としてではなく、属性と振る舞いのまとまった「存在」としてユーザーに印象づけたい。「没入感」と言ってもいい。もっとも、極端な言い方をすれば「属性」も層構造の一種だと捉えられはするのだが、表現と解釈次第か。
なんか層構造を操作するモーションって「機械を操作している感」みたいな、事務的で無機的な感じがする。もっと「キャラに話しかけた」や「本のページをめくる」といったような、情緒的・有機的なモーションを連想させる方が「没入感」の演出に良いのではないか……と。ただ、オブジェクト感を優先しマテリアルデザインを採用すると、なんだか世界観（SF）に対して野暮ったい見た目になってしまうなあという迷いもある。フラットだけど没入できるとは。その点、漫画のコマ割りは最低限の情報（線）で没入感のある時間・空間の表現をしていると言えるかもしれない。
……ということで、層構造ではないレイアウトの試みとしてグリッドレイアウト。コンテンツのサイズ・配置をバラけさせつつ、タップ遷移時の視線の方向には統一感を持たせる動きを設計した。割と気に入っているというか、ポテンシャルを感じる。今後の課題としてはアニメーションだろうか。雑に検索した感じ、参考資料があまり見当たらない印象がある。
「手続き的な」インターフェースとオブジェクトの関係
ユーザーが何をしたいかという「目的」「手続き」に焦点を当てて設計する。なぜなら目的から逆算して手順を考えさせるという行為はコストが大きく、オブジェクト的なデータモデリングはユーザーが手順を逆算せざるをえない状況に陥りやすい。
ゲームなんかは目的意識を持って操作するから分かりやすいかもしれない。「チームを編成する」「リズムゲームで遊ぶ」といったボタンから機能にアクセスし、「どの曲で？」「どの難易度で？」と手続き時の対話のように選択しながら使う機能だ。必要な属性情報を揃えていく、層を深めていく手順。
対して、曲オブジェクトに「購入する」「リズムゲームで遊ぶ」といった振る舞いを定義し、曲アイコンリストを並べるようなUIはオブジェクト的であり、動作の順番が「曲の選択（対象）→リズムゲーム（目的）」となり逆転するので「リズムゲームをプレイする」というユースケースにおいては直感的ではない。日本語だとピンとこないが、英語の文法をイメージするといい。ユーザーが（主語）→リズムゲームする（動作・目的）→この曲を（対象）。そしてまた、オブジェクト的な表現は情報量が増えすぎてノイズになりがちというのがある。ユーザーに複雑なことを考えさせない。
というか、曲オブジェクトにとっては「（自身がユーザーに）プレイされる」「購入される」（受け身）だからこういった定義がそもそも正確ではない。もちろん状況によっては許される場面もあるだろうけれど。
逆にプロセカでは「育成する」機能があったのだが廃止され、キャラカードの振る舞いの中に再定義されていた。プロセカのプレイのフローの中では「使いたいカードがある→育成する」というプロセスが発生するため、カードを最初に選ぶ方が直感的であるのは確かにそうだ。あるいは「キャラカードが育つ（自動詞：ユーザーがそのトリガーを引く）」と捉えたほうがオブジェクトの関係として正確なのだろう。植物に水をやるイメージ。
身近でゲーム以外の手続きシステムだと、自販機。自販機は販売しかしないので、オブジェクト的な構造・手順にするメリットがなかったというのが根底にある。お金を払って→商品を選ぶ。が、「モノ→動作」の手順になる場合もある。それが自販機で電子マネー支払いをした時。電子マネーのシステム上、そして既存の自販機をカスタムする構造上そうせねばならないのは分かるが、最初は困惑した。慣れればそういうもんかというところもある。現金とは異なり、電子マネーには「残高：状態」と「支払う：振る舞い（要引数）」を有している「オブジェクト」であるため、手順がオブジェクト的にならざるをえない。
コンビニにせよAmazon・楽天にせよ「商品をカートに入れる」「カートの中に入っている商品を購入する」という手順もオブジェクト的だ。特に「商品がカートの中に入っている」という「状態」を保持する点がそう。「やっぱりコレ買わないな」と思った時に「モノの移動」をするのか「店員に働きかけるか」は、モノ同士の関連で表現が異なる。
最初に言った「カルテの中にプレイリストへの導線をつくる」は、情報同士の関係を伝え、没入感を高めるのにはいいかもしれないが、最初から目的があって「この情報にアクセスしたい」と考えているユーザーにとっては余計な操作をさせる・操作の手順を組み立てさせることになりうる。なので、オブジェクト的なUI/UXは目指しつつも「手続き的なインターフェース」のメリットを生かし、可用性を高めたい。
ユースケースとドメインの分析を適切に行い、データとロジックを設計し、包括的に考えることで保守・運用コストを下げる。ここなんだよな。保守・運用への考慮がな……割と最近は「保守できなくなったら作り直す」というソフトウェア寿命の短い・量産の方向性に舵を切っているところも少なくないだろうし。「保守コストを考慮するコスト」を放棄する。まあ相当フットワークが軽くて火力の出る人材が揃ってなきゃできないし、そういう人材の採用コスト・人件費は高くつくだろうから（有事の際に人員の代替が利きづらいというリスクもある）、トータルの経営的なコストについてはケースバイケースだと思う。結局、データベースまわりの設計・移植はコストの大きい部分だし、規模感による。ユーザーがいちいち登録し直すのかとか。今回は個人の趣味の開発だから直接の関係はないけど。
創作サイトにおけるユーザーの「目的」と手順、サイトのオーナーの「目的」、プロダクトとしてのコンセプト。ここを考え直す必要がある……
覚え書き
「植物の世話をする当番」といったタスクなら「ジョウロに水を汲む（動作）→どこの花壇に行くか決める（対象）」といった設計になるだろうし。自動詞・他動詞の観点は持っておいたほうがいいな……日本語だとそのあたりがふんわりする。
オブジェクト的な設計が常に最適とは限らないのだが「再利用しやすい」というメリットもある。一方で状態や関係の管理を適切にしないといけない。
手続き型とオブジェクト型を折衷したような設計・データモデリングの思想もある。継承ではなく包含を使え、という原則の究極系みたいなやつ。
内部的にオブジェクト型だけど手続き型の手順でUIを設計することは全然あるし、そもそもついさっき「オブジェクトも解釈によっちゃ層だよね」みたいな話をしたばっかりだ。自己言及のパラドックスか？
1つの情報に対して複数の導線を用意するの、親切ではあるだろうけどユーザーが混乱するのではないかという心配もある。優先順位の観点をもって整理が必要