Summer KMSF Mtg. ORFスケジュール ● ● システム設計 どこで推論させるか (端末上・リモート) アルゴリズム (Dynamic Bayeis / HMM) 全体設計 (データをどう送信するか、取得するか) インタラクション設計 振る動作の設計 (ボタンを押しながら、押さずにふ るか) コード表記の設計 評価項目の設計 ポスターについて ● ● 4回の組み合わせの4という数はなぜ? 4という理由が薄い。 最大の数を何通りにしたいから何回必要。 4つまで情報を含んでいて、5からは行動など。 規定が規定ではなくなっている。 4つまで情報を含んでいて、5からは行動など。 コードの表記の指定の問題 システム設計議論 ● 推論させる場所 携帯端末上 ● フィードバックが必要。携帯端末上で実装する必要があ る。 リモートサーバ上 ● どちらにしても、データ取得でサーバが必要。 システム設計議論 ● エリアの線引き システム設計議論 ● アルゴリズム Dynamic Bayeis Hidden Marcov Model システム設計 ● 全体設計 完全なシステムの形で実装する。 詳細は後に考えて、APIをきって、担当を決める。 インタラクション設計 ● 振る動作の設計 ● ● 音によるフィードバックがあるとよい。 ボタンを押している間、認識する。 インタラクション設計 ● コードの設計 組み合わせに関して ● ● 必要ベース(想定環境で数えて評価) 制約ベース(短期記憶・チャンクにおける評価) 空間的な制約 論文で短期記憶についての学術的な根拠 今回の場合による実験による具体的な定量的なデータ 何秒で覚えられるか・何秒覚えていられるか コードの組み合わせを1チャンクとして3つ使うか コード設計 ● コードの設計 意味を持たせるか ● ● ソニー=S、東京メトロ=メなど。意味を持たせる。 コードに自由度を持たせる。 方向の数 ● ● ● 4方向だと、人間が考えるのに簡単だけれど数が少ない 8方向だと、人間が考えるのが難しいが、数は多い 4方向+コードに意味 太い矢印は早く振る コードの上に2と書いてあったら往復 コード設計 ● コードの設計 そもそも問題 ● ● ● ● コードを設計する上で何が問題だったのか。 QRコードの弱点、URLの弱点を補う。 コードを設計する上での指針。 覚えやすさなど、何がほしいのか。意味の持たせやすさ 。 設計指針 ● ● ● ● 情報密度、注目ひきつけ度合い、表現の自由度など。 瞬間的に人が実行できること。 瞬時に理解して覚えることができる。←大前提 数字とくらべた優位性の意味づけ インタラクション設計 ● 評価項目の設計
© Copyright 2024 ExpyDoc