カテゴリー: サイト方針

アビリティの再使用間隔の表示を、どのページにどういう風に表示させようか悩んでいる。今日までで、結果表示画面は「アビリティ」と「キャラクター」という２種類にわけて表示するようにした。キャラクター画面には各アビリティの名称や効果(説明)などが表示されているのだが、その細かいデータをそこに全部盛り込むのは微妙に思っている。

では、アビリティ画面に持たせるのか？というとどこまで持たせるのが良いのか悩む。

この機能を使う人は、まずアビリティの種別からアビリティの一覧を見て、そこから自分の目的にあったアビリティなのかどうかを知りたいはずだ。そこで、アビリティを選択しアビリティの情報を表示させたなら、アビリティ名や説明だけでなく、どのような効果か、何ターン持続するか、再使用間隔はどれくらいなのか、レベルで変化するのか、などが知りたいはずだ。

そうか…。一覧でアビリティ名とそのレベルがわかるとしても、アビリティ画面で再度レベルによるバリエーションがあるのであれば、それを表示できるようにすれば利便性が高いかもしれない。つまり、変化するレベルの同一アビリティへの遷移ができればそれでいいのでは無いだろうか。

それなら、一覧ではレベルによるバリエーションを表示させる意味がどれくらいあるのだろう？以前考えたように、同一キャラでも最終解放まで終わっている場合、複数のアビリティが表示されてしまう。そうするとあっと言う間に表示上限に達してしまうのではないだろうか。だったら、検索画面では同一アビは１行に表示させ、アビリティ画面で別レベルの表示が選択できれば良いのではないだろうか。

振り出しに戻ってしまった感じがするｗ

画面がある程度できたら、色々と思い悩み始めてしまった。

本当に使えるものにしたいので、少々手戻りがあってもここはちゃんとしたい。

元々、アビリティ検索というのが主目的だけど、変に欲張って機能を増やすのは実力に見合わない、高望みになって完了しないという最悪な事も考えられる。そこで、アビリティ検索というので、利用者がどういう事を求めているかを考えたい。

とはいえ、まず自分のやりたい事を形にするのが先決。その為にアビリティを検索した後、簡易表示と詳細表示に分けるようにしていたが、簡易表示画面に自分が見たいと思う情報を集約させる事にした。本当に細かいデータ(効果量など)を表示させるとしたら、従来は詳細画面へ…と思ったのだが、実際に表示するとしたら(データが用意できるかどうか次第だが)どこに表示される方が嬉しいか？となると、やはり簡易画面側だろうと思う。

複数結果を選択して表示するならなおさら。比較したいのは効果量とかであり、名前比較してもしょうがないでしょうw詳細画面をキャラ情報(簡易情報)とするのなら、渡すべきはアビリティ情報ではなく、キャラIDのみで良いはず。ただ、どのアビを選択したのかってのがわかった方がいいのだろうか？

いずれにせよ、ちょっと手戻りも考え直しも入っているけど、ここをキッチリやって次にいきたいと思う。でも中々すすまんのｗ

まず、タスク管理(プロジェクト管理)は、UpStreamというプラグインで管理する事にした。チャート表示とかカレンダー表示とかは、どうやら有料のようだけど、タスクの管理だけなら無料で使えるし、これでひとまずやっていこう。

CollabPressは古いせいか、使うとTwenty-SeventeenのCSSへ干渉を起こしてしまうようだったので使うのをやめた。まぁ６年も更新してない奴を使う事はないよね。

さて、タスクの管理ができたところで簡易画面の作成に取り掛かった。前回までで、流れとしては確認できていたので、データの受け渡しや表示内容について再検討を行った感じになる。

データの持ち回り方法は、暫定ながらメモリ上で行う事にした。検索結果が増えたりした場合、DOMがどれくらい消費されるのか…などは、注意が必要だろう。

また、表示項目に関しては極力ショートコードを使って、画面表示段階で終らせるようにしている。現状表示に関して簡易表示画面でJavaScriptを使っての実装は無い。ショートコードの範囲指定や、ショートコードの入れ子などをうまく使って、検索結果などの条件で表示したいエリアの切り替えなどもできているし、方針としてはこれでOKだろうと思う。

細かいデザインは後回しにして、取りあえず必要な情報が全て表示できるか(「簡易」の名に相応しい程度で)については、もう少し詰める必要があるだろう。

このまま詳細表示画面も進めていきたい所。簡易表示の状態でも、テーブルのデータの持ち方などは結構考慮が必要だったし、カラムの使途なども見直しがでてきた。詳細表示になればそのあたりも増えそうだし、やはりデータ入力よりも優先して行わないといけないだろう。

現状は、プログラムで頑張るより、テーブル上のデータを増やすという方針になっているが、これでいいのかはまた考えなくてはならないだろう。ともあれ、今日はそこそこ順調だった。

昨日ブログで一覧にした、やり残し項目を、CollabPressを導入して、タスクとして入力完了した。今後はCollabPressを使って完成までを管理していきたいと思う。

ただ、ガントチャート的なものもないし、優先度や期限などは後から修正できないなど、色々と不便な部分もあるので、その辺りは臨機応変に運用していこう。まぁ備忘録程度と思っておけばいいかな。

やりたいと思った事をブログに書いても忘れてしまう可能性もあるので、思いついた事はCollabPressにタスクとして何でも登録し、後から分類してやらなくていいものはやめるなどの判断をすればいい。

今日はプログラムは何も進まずに終わってしまったな…。明日はもうちょっと手を動かしたいね。

結構色々とやってきているのだが、やり残している事も多い。忘れないよう、今のうちに列挙しておいた方がいいかもしれない。

• トップ画面に表示している画像の変更
• そもそもtwenty-seventeenでいいのか？
• Google Adsenseの自動広告が大きすぎる
• functions.phpの処理の絞込み(page.phpへ移動)
• 各固定ページに直接記述しているJSの外部ファイル化
• サニタイジングなどの処理
• PHPと画面側でシェイクハンド(認証？)の必要性
• 一覧画面(テーブル)のスクロール処理
• 一覧画面の表示方法(一行おきに色を変える等)
• ポップアップウィンドウの「×」ボタンがスマホで表示されない
• ボタンを<button>にするのか<input type=”button”>にするのか
• 検索画面の英語化(そもそもローカライズってどうするの？)
• 管理用項目(最大検索数など)の検討
• 管理用項目の保持方法(DB？ファイル？)
• 選択行をJSのグローバル変数で保持している事の妥当性
• 英語データが無い(所持してないキャラ)場合の処理
• 限定公開する場合、ユーザー登録させるか否か
• キャラの対象範囲をどこまでにするのか(SSR,SR,R)
• 召喚石を含めるかどうか
• ジョブの表示方法の検討
• キャラ等の画像の利用について
• データ入力どこまで頑張れるかw

ざっと考えてみただけでまだまだこんなにやる事積み上がってしまった。やっぱり全部一人でやろうとすると、それだけ時間もかかるよね。でも一つずつやらないとな。進捗管理用のツールみたいなもの、インストールしたりできないのかな。既にあるのかな？WordPress使ってそういう事できたりするのかな？又調べてみよう。

検索結果から遷移する画面を、又固定ページで作ろうとしたのだけど、固定ページ個別に読み込まれるpage.phpというものが作れるという事を知った。具体的には「page-スラッグ.php」を、子テーマのフォルダ内に作って入れておくだけ。元になるpage.phpは、親テーマフォルダ直下にあるので、そこからダウンロードし、名前を変更して子テーマのフォルダへアップロードすればいい。

page-スラッグ.phpは、page.phpより優先して呼ばれるようなので、今回簡易表示、詳細表示の二つの画面を作ろうと思っていたけれど、それぞれ別のphpを用意すれば良さそうだ。

今回の画面作成にあたり、functions.phpに検索用のあらゆる記述を仕込んでしまっているのだけれど、本来ならこれはこのpage-スラッグ.phpに記述すべきものなのではないだろうか。子テーマ全体で使う処理はfunctions.phpで、固定ページ個別で使う処理はpage-スラッグ.phpに記述するのが素直な気がする。

詳細(簡易)表示ページでも、SELECT文使ってDBにアクセスしなくてはならないし、詳細表示ページの処理はpage-スラッグ.phpの方に実装していってみよう。functions.php、header.php、footer.php、page-スラッグ.phpの呼び出し関係などがどうなっているのかは、出力された画面のソースとかである程度認識できそうだし。

そして、画面遷移時に色々と情報を受け渡そうと思っていたのだけれど、ひょっとして、「カスタムフィールド」とか使えないだろうか。複数の固定ページで同じ名前のカスタムフィールドを設定したらどうなってしまうのかまだ不明だけど、プログラム側からアクセスできるフィールドのようだし、必要な情報をここに格納するようにすればページ間でデータを受け渡せるかもしれない。こちらも調べてみよう。

だが取りあえずは、GETでID受け渡す形式で一連の流れを作ってみよう。

マウス操作ではなく、リンク(アンカー)による操作に切り替えてみた。まず検索結果の第一要素(１列目)を単なる文字列ではなく、AタグをcreateElementして、それをTDタグにアペンド、そしてそれをTRへ追加…という手順を踏む事にした。具体的にはこんな感じ。

// １カラム目の処理
var new_tr = document.createElement( 'tr' ) ;
var new_td = document.createElement( 'td' ) ;
var new_a = document.createElement( 'a' ) ;
a.id = row_identifier ;
a.innerHTML = 1st_column_string ;
jQuery( new_a ).on( 'click', my_click_process ) ;
new_td.appendChild( new_a ) ;
new_tr.appendChild( new_td ) ;
// ２カラム目の処理
new_td = ...

この処理を、行数分繰り返す事でアンカー(Aタグ)つきの表形式結果一覧が完成する。アンカーをクリックして、単にどこかへ飛ばすわけではないので、href属性は設定せずに、onClickで処理を挟むようにした。処理としては何かしらのポップアップウィンドウを表示する事を想定した。

そして次に取り掛かったのが、ポップアップの表示なのだが、ポップアップ表示と言ってもいろいろな種類がある。いわゆるalertではダイアログ内のレイアウトも限定されてしまうので、できればもう少しレイアウトが自由なのがいいなぁと色々調べてみると、HTML+CSSで作るポップアップや、jQuery UIのダイアログなど、結構候補が色々あった。とりあえず手っ取り早そうなjQuery UIのダイアログを試してみようと思って作ってみたのだが…。

$("#test_dialog").dialog( "open" ) ;

みたいに書いても、「dialogが関数として定義されていない」とエラーになる。jQueryの記述に慣れていないのもあるのかと思い、色々と書き方とか触ってみたのだが結果は変わらない。そしてこれは、必要なライブラリが足りてないとかではないのか？と思って調べてみたら、やっぱりデフォルトではjQuery UIは読み込まれていなさそう。という事で、早速jQuery UIを読み込んでみた。functions.phpに次のように書き加えてみた。

add_action( 'wp_enqueue_scripts', 'additional_scripts_enqueue' );
function additional_scripts_enqueue() {
     wp_enqueue_script( 'jquery-ui-dialog' );
     wp_enqueue_style( 'jquery-ui-dialog-min-css', includes_url().'css/jquery-ui-dialog.min.css' );
}

そして試してみると…、できた！！！想定通りのダイアログが画面にでてきた。PCの場合、ダイアログの位置や大きさも、表示した後に自由に変更できるようだけれど、スマホ(Chrome)では動かせなかった。まぁ動かす必要も無いので構わないのだが。その辺り、色々とデザイン等を見て考えるとしよう。今回は「OK」ボタンを配置したけれど、「×」ボタンはデフォルトでつくようだし、「簡易表示」「詳細表示」の２ボタンを配置すれば、「OK」ボタンは無くても良さそうに思う。

後、表示させるダイアログはHTML(今回の場合はWordPressの固定ページ)上にdivで囲った要素として、あらかじめ記述しておく必要がある。しかし処理が遅かったりするのか、余計な処理が多くて手間取っているのかまだ不明だが、表示させたくないのに画面上に一瞬表示されてしまう事がある。取りあえず以下のように非表示のスタイルを設定してみたが、これでも問題なくダイアログは表示されるようだし、しばらくこのままでいこうかな。

<div id="test_dialog" style="display: none ;">
<p>test dialog</p>
<button>簡易表示</button>
<input type="button" value="詳細表示" />
</div>

このjQuerty UIのダイアログで全て目的が達成されるようなら、次は実際の簡易表示、詳細表示の処理へと進む事になるが、どうやってやるのかは全く不明。雛形HTMLを用意して…でも、固定ページへ埋め込んで…でもダメだと思うからどうしようね。まぁそれはダイアログが完成した後に考えよう。取りあえずは固定ページを作って、そこへ別タブ(target=”_blank”)で表示するような流れまでできれば、ダイアログ関連も完了にできるから頑張りたい。

検索系が結構できあがったので、テスト用のデータを増やして色々な精度を高めて行こうと思っていたのだけど、データ入力している最中に色々とこのままの構造でいいのか？という疑問がわいてきてしまった。

検索して、一覧表示まではOKだったけど、さらにそこから行を選んで詳細表示という流れになった際、詳細データの持ち方や、そもそもどうやって詳細表示させるのか？というのがまだ未解決だった事に気づいた。これを放置してデータを増やしても、後からテーブルの見直しなどをするのは大変な事になる。

という事で、データ入力はひとまずおいて、検索結果一覧から、詳細画面への遷移の流れを作っていく事にした。

検索したデータは従来はHTML形式のTRタグをPHP側で生成し、その文字列をJS側でinnerHTMLとして渡すというやり方で結果一覧をTABLE形式で表示させていた。しかし、検索結果一覧で行を選択し、詳細画面を表示させるには、その行を一意に表す必要がある。タグで文字列を返していたので、TRタグにid属性を指定し、そこへその一意の値を設定すれば、JavaScript側でidを取得できるのでは？という目論みだった。

しかしながら、結果としては失敗だった。というのもidを取り出しても空白(未設定)状態のままだった。色々試行錯誤もしてみたけれど、うまくいかずもう一度良く考えてみた。

PHP側で以下のような文字列を１行のデータとして返している。

<tr id="id001"><td>data1></td><td>data2</td><td>data3</td></tr>

これをJavaScript側で受け取った際(実際はJSONへencodeした後に、Parseしているが)、次のような処理で１行のデータを作成していた。

var newtr = document.createElement( 'tr' ) ;
newtr.innerHTML( row_data ) ; // <tr id="..."><td>...
var id = newtr.id ; // idを取得したつもりだったが…

今まで、これでちゃんとテーブル形式でデータが表示されていたので、問題ないと思っていたのだが、よーく考えてみると、TRの要素にTRタグを入れているという解釈になってはいないか？と気付いた。もしそうなら、HTMLの構文上TRの子要素にTRはありえないため、DOM側で無視していたのではないだろうか。無視されているなら、いくらid属性に値を入れた所で無視されるのは当然の事だった。

では、createElementせず別の方法で文字列を評価し、それをTRオブジェクトとして処理をすれば良いのでは…と思ったのだが、どうにもそれはおかしな考えなのでは？と思い始めた。また、タグを含めた文字列が検索結果として返ってくると、検索結果の行数が増えれば増えただけタグ部分のデータ量が増えてしまう。検索件数に上限を設ける予定とは言え、無駄な通信料を増やすのは良く無いだろう。

という事で、タグの文字列を返していた部分を全面的に作り変え、検索結果の多次元配列(JSON化したもの)を返却するようにした。あわせて、検索件数とデータのみを返していた部分を、検索件数とエラーコード、検索結果という３構成にして返す事にした。エラー種別でJavaScript側の対応を分けられるようにしたのだが、現状は正常時とそうでない時(検索件数０はエラーでは無いが処理上は異常時と同じ表示で済ませるため)で分けているだけにしてある。この部分は今後エラーが増えた場合には相応の対応が必要になるだろう。

検索結果には、日本語文字列を含むが、データベース上は数値で格納しているものもある。PHPから返却する際、検索結果の数値部分を文字列に置き換えて返却しているが、エラーメッセージなども全てPHP側で文字列を作って返却し、ブラウザ側ではそれがそのまま表示されるようにしようと思う。

これは、将来英語化を視野に入れた対応で、多国語化対応をJavaScriptでガリガリやるわけにもいかないだろうと考えたためだ。実際日本語データと英語データは別フィールドに格納するようにしているので、画面の言語情報をPHP側で受け取って生成するSELECT文を変えたりする必要もある。上述の数値を置き換えた文字列も当然切り替える必要もあるので、表示される文字列に関しては全てPHP側で生成して返却しようと思っている。

実際には、日本語ページと英語ページで別URLになるのだろうから、HTML上の文字列はともかく、JavaScriptで扱う文字列なども別々のJSファイルで持つなどすればいいのかもしれないが、その辺りどっちがいいのか？というのはイマイチ経験不足で判断がつかないというのが正直な所。ただ、ローカライズに関する部分はできる限り少なくしたいとは思うので、前述のようにSELECT文が言語で対象フィールドが変わり、その部分の実装が必要なのであれば、ローカライズに関する部分(プログラム的な部分)は全てPHP側に集約する方が良いんじゃないかな？と考えた次第。これは今後変わるかもしれないし、そもそも英語化はハードルも高いのでやらない可能性も十分あるw

とりあえず従来からこのような変更をした上で、検索結果の各行にマウスクリックのイベントハンドラを登録する所までは完成した。というより、イベント部分はさっさと完了していたのだが、そこで取得する「行を識別するID」をどうするか…の部分(上記のあれこれ)に時間を取られてしまっていたのが実状だったりする。

次はマウスやタップの処理をどうするのかを考える必要がある。想定では行の長押しで一定時間経過後にポップアップ表示がでて、そこで概要か詳細かを選ばせて別タブ(target=”_blank”)で画面遷移するという事を目論んでいる。しかし、ぱっと見でそんなイベントハンドラは用意されている感じでは無いので(ダブルクリックとかはあるが)、タイマーとか使って自分で処理しなくてはならないのだろうなぁ…。

また、PCとスマホでどちらも長押しでいいのか、PCの場合は別方法にすべきかというのも考える必要がありそう。一番簡単なのは、表示名をリンクにしてリンククリック(タップ)でポップアップ表示という流れなのだが、日和ってそちらに落ち着く可能性も大w

でも、とりあえずやるだけやってみよう。この辺りの使い勝手が良く無いと余り意味が無いものになってしまうかもしれないし。イベント系は色々難しい(発火や消費、二重発火の抑止など)と思うのだが、最近はその辺りも緩和されていたりするのかな？逆に難しくなっていたりして…。まぁやるだけやるしかないかな…。

昨夜考えたけれど、データ件数を増やした場合、表示上のスクロールがーとか、凄く安易に考えてたけど、そうでは無いと気付いた。

原稿のXRESの規約では、応答3秒越えるプロセスは強制終了とかはあるにせよ、SQL素人の自分が組んだプログラムで、CPU負荷増大なんて真似を引き起こしてはたまらない。良く考えると「通常ダメージ」とか「奥義ダメージ」とか、全キャラ共通で該当しちゃう条件含んでる時点で「絞込み」をちゃんと考えないといけない事に思い当たった。

絞込みは、条件の追加のところで考えていたにせよ、それでも結果が相当数になる可能性まで考えが及んでいなかった。数が多ければスクロール、あるいは次ページで…とか考えていたけれど、PCならいざ知らずスマホで次ページ繰りながら参照なんてナンセンスな気がする。

という事で、当然絞込み用の条件を設けるのは勿論の事、事前に検索結果件数の制限を設けようかと思う。検索結果が100件もあったら、恐らく検索としては失敗だろう。10件では少なすぎるかもしれない。実際の件数については検索性能など色々勘案して可変にできるようにするとして、上限を越えた検索結果になる場合はメッセージを出して検索しないなどの処理を盛り込む。

具体的にはまずSELECT COUNT(だっけ)して、規定数を超えたらその場で復帰。制限以内なら実際にSELECT＆結果の処理を実施するという形だろう。

SELECT COUNTと実SELECTが同等のCPU消費になるという可能性もあるので、その辺りも注意しないといけないはず。その為にもテスト用データを増やす必要があるので、一通りの実装が終わったらデータ入力をしようかな…。

データ入力の事も考えたら、現状表示は日本語のみを対象にしているが、使うかどうかは別にして英語表記も含めるべきではないかしらん。当然フィールドに英語表記も追加しないとならないのでテーブル自体も変更が必要になる。でも、使うかどうかはさておき、フィールドだけは追加しようかな。ただ、日本語表記はデータ集める手段はあるけれど、英語表記に関しては所持しているキャラクター以外は確認ができない。(海外向けサイトにならあるかもしれないが)

従って、フィールドは設けるけど、データは無しで、データが無い部分は日本語のまま表示するなどの考慮が必要になりそう。

欲をかいて実装頓挫という事にならないよう、色々見極めも必要になるだろう。まず着実に進めていく事を第一にしよう。

まず、今後やりたい事を列挙していこう。

• 検索結果の充実
  • レアリティ、属性、取得レベルなど表示項目の追加
  • 複数件表示時のボディ部のみスクロール
  • 複数件表示時の１行おきの色変え
  • 一覧からアビリティ/キャラクター詳細への遷移(ポップアップ？)
• 検索条件の追加
  • レアリティ指定
  • 同一アビリティのLv差分表示抑制
• テスト用データの追加

ひとまずこんなところを目指そうかな。現状１人分しかデータも入ってない(未完了)し、複数行表示とかを確認するためにももっとデータ増やさないといけない。そういえばレアリティ指定したり表示したりするなら、SRやRのキャラクターのデータも入れておきたいな。主人公(ジョブ)もいれないとだけど、召喚石の召喚効果についても入れた方がいいんだ…ろうな…。まぁデータは膨大になるのはわかっていたけれど。

む、そういえば剣神効果については全く考慮してなかったし、武器ごとの奥義効果なんかも考慮してなかった。それは入れるとなると、本当にデータ量が膨大になってしまうし、検索条件とかも無秩序になってしまいかねないな。今回はジョブ、キャラクターのアビリティ(キャラの奥義追加効果)と召喚石の召喚効果に絞ることにしよう。