調べてから表示されるまでの間、開く時のアニメーションがどうにも遅くて
個人的な見解を横から・・・。
アニメーションはそのものは十分に速いと思います確かにもうちょっと速くてもいいかも。
開発環境上で、メニューの開閉アニメーションを無くすテストを始めてみました。
アニメーションを無くしてみたところで効果は微小で
本質的な解決にならないと推測します。(細かいことは折り畳み。)
「とりあえず手っ取り早くできそうなとこに手を入れました!」
とゆーポーズ的・場当たり的な対応になることを危惧します。
■ cocaさんの入力の連打キャンセルが発生するまでのシーケンス(妄想)
「★」マークが付いているところがユーザから見て待ちが発生している部分。
----------------
CL 宝箱や各種ターゲット(???)等を選択
CL ◇キー/ボタン入力制限開始
CL サーバ側に選択情報を送信
↓
↓
↓
★ SV クライアント側から届いたデータを処理
★ SV +-- インスタンス用サーバに問い合わせ
★ SV +-- 関連DBサーバに問い合わせ
★ SV 同期とかの排他とかの整合性処理
★ SV +-- PTメンバー全員にステータス確認
↓
CL ★サーバ側からの応答を受信
CL ★サーバ側にステータスを送信
↓
★ SV サーバ側のステータスを更新・クライアント側に応答を返せる状態になる
★ SV クライアント側に応答(正常レスポンス開始)を返す
★ SV クライアント側に応答(中身~Endまで)を返す
↓
↓
↓
CL ◎ユーザはイライラしながらボタン連打中
CL ★サーバ側からの応答を受信
CL ダイアログの最終サイズを確定・アニメーション位置を計算
CL ▽ ダイアログが開くアニメーション開始~
CL ★表示する内容の構築開始(HDDからデータのロードを開始)
CL ダイアログが開くアニメーション~途中まで~(数フレーム)
CL ★表示する内容の構築を内部的に完了(デフォルト位置はキャンセル)
CL △ ダイアログが開くアニメーション~完了(数フレーム)
CL ◇キー/ボタン入力制限解除
CL ◎ユーザがボタン連打していた入力が反映される
CL (本来なら:展開したダイアログ上に表示内容を配置開始)
CL (本来なら:ダイアログにサーバ側からの応答 - テキスト - を表示完了)
CL (本来なら:ダイアログにサーバ側からの応答 - 画像 - を表示完了)
CL ◎操作はキャンセルされました^^
----------------
実際の処理はまた違うとは思いますがが大筋はこんなもんかなと思います。
この流れの中で、ダイアログの表示アニメーションに費やしている時間は
ほんの僅かなものです。
アニメーションそのものの時間の短さは処理負荷の軽い場所で
メインメニューの表示とかを試してみればすぐにわかる事。
# ボワンとした感じのアニメーションなのでせっかちな人には
# 「膨らみすぎなとことかもっと削れるだろ!」とゆー印象を与えるかな・・・。
でも実際これを削ってみたところで数フレーム分の削減にしかなりません。
(仮に10フレーム削るとすると166ミリ秒程度の削減。)
この問題で対処すべき箇所はたぶんここ↑。
表面的な問題点はサーバ側からの応答の遅さにあって、それに対して開発側ですべきことは次の2点です。
・応答までのボトルネックとなっている箇所の検出
・上記原因への対処。
※補足
開発側ではこんなこと言うまでも無く理解している事と思われます。
でも本当はそうじゃないと思う。
「調べたよ」って情報が受理されているか否かもすぐ分かるといいですね。
これ↑がこのスレッドの問題の本質(その1)なんじゃないのかなと。
スレッドのタイトルはウィンドウの表示に言及してますがそうじゃなくて。
(ついでにこのコメントからは解決方法への糸口も見えてきます。)
本当の問題点は、
・ユーザはサーバ側からの応答をただひたすら待つしかない。
という状況/仕組み。
改善策として、例えば
・BCとかに入るために問い合わせをした際に下記の統計情報が
一次情報としてすぐに返却される。
- 現在のインスタンスの使用状況 15/15 (Full)
- インスタンス内の戦闘の平均所要時間 26分
- 直近10分間の入室数の実績 2PT/10分
- 直近10分間の入室リクエストの受付数 1206回/10分
- このフィールドにいる(=入室待ちと思われる)パーティー数 24PT
としたらユーザ側はその場で続けて待つことにするか
それとも他のコンテンツに移動して
時間を有効に使うかどうかの判断ができます。
(これを境にユーザの待ちの責任の所在がシステム側からユーザ側に移ります。)
同時にこれは「調べたらちゃんと応答したよ」という
フィードバックにもなります。
この一次情報の提供の後で「入室しますか?」とゆー選択ダイアログが
表示される流れにすれば「それでも入室する」ユーザは
待ち時間がかかる事も承知の上で臨む格好になり、
いきなり一方的に待たされる状況からは解放されます。
* * *
このフォーラムでのやり取りにも散見されることですが、
ユーザは結果も大事ですが(結果が得られないのなら)進捗を知りたいと
思うものです。
結果が出るまで応答しないのではなく定期的に何らかの応答を
返すことでユーザには処理が継続されているという安心感を
与えることができます。
また上記の例のような一次情報を提供することができれば
ユーザ側の意思でその次の行動を決めることができるので
現状よくある
「ただ一方的に理不尽に待たされ、著しく不満が募る」
(※一般社会では仕事を切られる直接的な原因になり得る事です。)
という状況が相当に軽減されることが期待できます。
* * *
ウィンドウが遅いタイミングで開く→キャンセルを押す→消える
ここ↑も問題の本質(その2)。
ユーザがイライラしてボタン連打をしてしまうのは止めようがない事なので
システム側でできる事は次の1点しかないと思います。
・「これからダイアログが開きますよ」ということを事前に通知する。
ユーザにそろそろ通信が完了してダイアログが開きそうな事に気付いてもらう。
それをもって、ユーザに自発的にボタン連打を止めてもらうことを期待する。
具体的に言うとダイアログを開く前に「(正弦波)ピピッ!」みたいな
小さな画面演出を入れて、一瞬の間を置いてダイアログを開く。
但しこれは必ず出すんじゃなくてサーバ側への送信完了から
3秒以上経過していた場合に限定、といった対応を入れる。
# クライアント側での入力制限状態(キー/ボタン入力情報の破棄と受付)の
# 管理方法で何とかしようとすると多分新たな問題を発生させることに
# なるような気がします・・・。
※以下は蛇足
(誰も気にしていないと思いますが)FF11の各種ウィンドウ類の
表示・非表示アニメーションは相当練りこまれていると思います。
何も考えない人が設計すると単純にフェードイン・フェードアウトに
してしまいかねないところをわざわざ手の込んだ折り畳み方式にして
プログラム的にも作りこんだ上で組み込んでいます。
フェードイン・フェードアウト方式との比較:
フェードイン・フェードアウト方式:
・アニメーションはもっさり感をもたらす
・表示時、ウィンドウの背面は全体的に認識できなくなる
・非表示時、背面の認識ができるまでにやや時間がかかる
折り畳み方式:
・アニメーションにスピード感・躍動感がある
・展開時、背景の鮮明な画像がギリギリまで見えている
・収縮時、背景の鮮明な画像をイチ早く見れる
旧TV画面(4:3比)でウィンドウ類がプレイ画面を埋め尽くしてしまう状況での弊害を極力軽減しようとか、
通信時の遅延を演出面でできるだけ違和感無く吸収しようとか、
プレイ時に軽快な感じとか躍動感とかをもたらそうといった意図を感じます。
(誉めすぎ?)