調理場端末のUI（案，相談）

[tenk-9]

• created: 3/28 19:30
• mod: 3/28 19:50, add 相談内容

概要

調理場端末のUIを考えています．いくつか案を画像で示すので，意見を伺いたいです．
作業の流れ的には，画像で簡易的にUIを設計→フィードバック反映（REPL）→Reactで実装と考えています．

端末の存在意味と操作方法

調理場端末について

• 調理場に置かれる端末です
• iPadを想定しています
• 調理係は，調理端末に表示される丼の情報を参照し，調理を行います
• 調理が完了したら，端末を操作し，調理状態(dons.status)を変更します

操作方法

• 調理の合間に端末を操作するので，単純な操作で完結するようにします
• 具体的には，タップのみで操作をします

相談内容

• 一度に参照できる丼の数はどれくらいがいいですか？
  • 案1だとMax8個，案2だとFixed5個です
  • 個人的には5個は少ないかもしれないな，と思います
• 案1では実装が少し重くて表示件数が多い，案2では実装が簡単だけど表示件数が少ないです．
  • こうしたらいいのではないか，等の意見を聞きたいです．特に現場で調理を担当していた人．

UI案

• 丼の情報（注文番号，オプション，トッピング）を1つのカードに格納します
• 注文と丼の親子関係が分かるようにします
  • 同じ注文番号の同士は同じ注文であることが一目でわかる（同じ色）ようにします
  • 異なる注文の丼は，異なる注文であることが一目でわかるようにします
• 調理が終了したら，その丼のカードをタップし表示から消去します
  • タップした丼の調理状態を変更し，調理状態==調理中の丼を取得し，画面の要素を更新します
  • 結果的にタップで消去されたように見えます

案1

案2

[tenk-9]

オプション等の情報が多くなったときでも一枚のカード内に収めるようにするが、カード1つの最大heightを設けるとよさそう。
このとき、情報量の多いカードは横に大きくなり、カード内のオプション表示が2列になる（幅はカード2つ分になる）。
こうすることで、最大8個のカードが表示でき、調理負荷がカードの大きさで可視化され、実装も比較的楽そう。

[tamaki12345]

一つ確認なんですが、

オプション等が多いとカードを拡張する
↑
これは最初のUI案のように複数並べるがオプションだけ拡張するという認識でOKですか？
それとも1人で複数注文した人のカードも拡張ということ？

[tenk-9]

オプション等が多いとカードを拡張する ↑ これは最初のUI案のように複数並べるがオプションだけ拡張するという認識でOKですか？ それとも1人で複数注文した人のカードも拡張ということ？

オプション等が多いとカードを拡張するというのは，ある丼に付随するオプションとトッピングの情報を表示しようとしたとき，カードの最大height*を超えないと表示できない場合は，横方向にカードの幅を広げて，表示可能なオプションとトッピングの件数を増やすということです．具体的には，この画像の番号2番のカードが最小の大きさで，4番がカスタム内容があるもの，5,6番が拡幅しない最大の情報量のもの，25番が拡幅した場合のカードです．
1人で複数個の丼を注文した場合，丼ごとにカードが生成され，丼に指定されたオプションとトッピングの多寡によってカードを拡幅するか否かが決まります．

*:案2では最大heightが画面の縦pxと同じだったが，案3では画面内に2行でカードを配置できる最大の縦幅（だいたい画面の縦px/2）にする．

[4416kidr]

カードを横に拡張するのならば、カードの区別がすぐに着くようにするのが最も重要だと思います。その場合番号のボックスをカードの横幅いっぱいに拡張すると良いと思いました。

[woodnx]

訂正案について，少々実装が面倒な気がしますが，運用の面からはそこまでややこしくならないと思います．

[tenk-9]

カードを横に拡張するのならば、カードの区別がすぐに着くようにするのが最も重要だと思います。その場合番号のボックスをカードの横幅いっぱいに拡張すると良いと思いました。

これは確かにそうなので、横幅を拡張する場合、ヘッダーの色がついた部分も拡幅するようにします。

[4416kidr]

案2と1で表示できる数にそこまで大きな違いがないので、よりシンプリでわかりやすい案2が良いと思います。
もし、調理場で6個以上を同時に作ることが多いのであれば、案1のようにカードの表示区画を複数行にする方が良いと思います。

[tenk-9]

そうですね、一旦案2(and 上方向スワイプでカード消去)で作ってみましょう

[4416kidr]

わかりました

[4416kidr]

あと誤タップで注文が見れなくなってしまう場合が少し怖いです。
運用を気をつければ問題ないと思いますが…

[woodnx]

@4416kidr @tenk-9
その場合は，消去実行までラグを設けるか，アンドゥ機能が必要になると思います．

[4416kidr]

そうですね。
アンドゥ機能はあった方が良さそうですね。

[woodnx]

ただ，アンドゥを実装する場合，DBへいつリクエストを送るのかという問題があります．
工夫すれば行けそうですが，フロント側の実装が大変になりそうです．

[tenk-9]

誤タップが怖い

その通りで、少し悩んでいました。現場の慌ただしさを鑑みると、タップでは操作負荷が軽すぎる気もします。
ですが、undoは、少し操作と実装がめんどくさそうなので、カードを消す操作の負荷を少しだけ増やす（e.g. カードを上方向にスワイプ）ことで解決できると思います。
@4416kidr @Woodnext cc:@tamaki12345 はどう思いますか？（undoの方がいいですか？）

[woodnx]

上方向へのスワイプでよい思います．