そもそもC/SアプリとWebアプリは全く違うものと考えること
新聞・テレビ・ラジオ・雑誌等、メディアはいくつもあるが、それぞれに長所短所があるように、C/SアプリとWebアプリにも長所短所がある。新聞で音声を、ラジオで文字を伝えるのは不適切("みえるラジオ"等の文字多重放送は除く)であるのと同様に、C/Sアプリで簡単に実現できてもWebアプリでは不可能な事がある。
画面レイアウトを厳密に定義しないこと
VBの画面設計はドローアプリケーションのように、オブジェクトを自由に配置できる。しかし、Webの基本は言わばワープロだ。ワープロが入力された文章を順に表示するように、ブラウザはサーバから出力されたデータを順に表示する。CSSで位置やサイズの指定が可能であるが、それでも限界がある。table要素で厳密にレイアウトできなくもないが、昨今のxhtmlへの潮流に逆らうことになる。また、プリントされる事を考えるのなら、なお更tableは使用しない方がよい。
※印刷すると用紙をはみ出してしまうWebサイトは大概tableによるレイアウトを行っているかframeを用いている。
※印刷すると用紙をはみ出してしまうWebサイトは大概tableによるレイアウトを行っているかframeを用いている。
ダイアログに多くを望まないこと
VBアプリの多くはダイアログを多用する。ダイアログだけのVBアプリも存在するように、VBの開発の中心はダイアログだ。しかし、Webアプリはウィンドウ中心である。しかも、それはドキュメントウィンドウである。Webアプリにダイアログと言えるような機能は基本的に「alert」「confirm」「prompt」の3つしかない。これらダイアログにレイアウトの自由はほとんどない。
※複雑なレイアウトが可能な「showModalDialog」「showModelessDialog」があるが、これはIEのみの機能である。
※複雑なレイアウトが可能な「showModalDialog」「showModelessDialog」があるが、これはIEのみの機能である。
別ウィンドウを開こうとしないこと
ダイアログのかわりに別ウィンドウを開こうとしてはならない。VBプログラマには以外に思えるかも知れないが、ブラウザ上のウィンドウの制御は意外と面倒で制限も多い。ポップアップブロック機能がIEにも標準で組み込まれており、Googleツールバー等もこの機能を持っている。これら全てのポップアップブロックを無効にしろとユーザに強要するのは問題だ。最近ではIE7にも実装されたようにタブブラウザも一般的になっており、ますます制御し難くなっている。
ウィンドウのサイズ変更・サイズ固定・位置変更を望まないこと
一応可能であるが望まないこと。Firefoxでは無効化も可能である。タブブラウザが一般化した現在では、ユーザに望まれない挙動であろう。そもそも、ブラウザのウィンドウはユーザのものであり、Webアプリはブラウザの表示領域にお邪魔しているだけのゲストである。
※「タブブラウザを判定し、ブラウザ毎に動作を変更せよ」等とPGに言ってしまったら、その場では何もなくともPGの間では永遠に笑い種となるかもしれない。
※「タブブラウザを判定し、ブラウザ毎に動作を変更せよ」等とPGに言ってしまったら、その場では何もなくともPGの間では永遠に笑い種となるかもしれない。
使用可能なコントロール数が全く違うと理解すること
VBのようにプロプラエタリで至れり尽くせりな環境で、豊富なコントロール群を使用し開発を行ってきたVBプログラマには信じられない程、Webアプリで使用できるコントロール数は少ない。タブや後述するコンボボックス等、基本と思われるようなコントロールでさえないのだ。
コンボボックスはWebアプリでは原則として使用できない
VBプログラマがコンボボックスと言う時は、リストボックスを指す事が多いが、リストボックスとコンボボックスは別物と一刻も早く気付くべきだ。コンボボックスとは「テキストボックス」と「リストボックス」を併せ持ったコントロールを言う。気の弱いPGや新人などはテキストボックスやリストボックスを駆使して何とか実現しようとするが全くの無駄である。
※最近では、AJAXを使用して可能となってきているが、今のところAJAX Libraryには後述するような問題がある。
※最近では、AJAXを使用して可能となってきているが、今のところAJAX Libraryには後述するような問題がある。
戻るボタンの無効化を考えないこと
これも可能であるが、前述の通りブラウザのウィンドウはユーザのものでアプリ側が勝手に制御しても良い類のものではない。設計段階から戻るボタンが押されてもいいように考えておくべきだ。閉じるボタンも同様である。
自動的にプリントさせようと考えないこと
上と同様。Webアプリで(正確にはJavaScriptで)可能なのは印刷ダイアログを表示させるぐらいである(厳密にいうと[@media]によるCSSの変更も可能)。『「ボタン押下」すると一覧を「A4横・2UP・カラー」で印刷』などもっての他である。只、上記機能はActiveXコントロールで可能なのでこの方向に流される事がある。しかし、セキュリティのリスクを多く抱えるActiveXの使用を今更ユーザに許容するのか。
※更にWin+IE限定になってしまう。
※更にWin+IE限定になってしまう。
画面に表示されているままにPDFに出力しようなどと考えないこと
クライアントにPDF作成のアプリケーションがインストールされていようがなかろうが、そもそもWebアプリからはそれらを操作できない。どうしてもPDFが必要なのであればサーバ側の処理となるが、様々な実現方法があるため詳細はここでは割愛する。しかし、どのようにユーザ側で表示されているかサーバ側からは把握できないため、「画面に表示されているままに一覧をPDFに出力」は不可能である。
※Excelを使用するような事も考えられるが複雑な話になるため、これもここでは言及しない。
※Excelを使用するような事も考えられるが複雑な話になるため、これもここでは言及しない。
入力チェックをクライアントだけですまそうとしないこと
これは余りにも当たり前の話であるが、未だに入力チェックをクライアントだけで行おうと考える設計者がいる。余りにも当たり前の話であるためここでは割愛する。
技術者の眼
これらの過ちを犯してしまう設計者は、普段どのようにWebを利用しているのだろうか。少なくとも「技術者の眼」で利用していないと筆者は考えている。目の前で起きていることの裏側を少しも考えていないのではないか。別ウィンドウを開くようなサイトがほとんどない事に気付かないのか。画面内のボタンを押すと自動的に印刷が始まるようなサイトが存在しない事に気付かないのか。こんな過ちの積み重ねが、予算や期間を切り詰め、そして実装者を追い詰めている。技術者は常に「技術者の眼」を持っているべきで、これができないのであればそもそも技術者となのるべきではないと考えるのは言い過ぎだろうか。
AJAXライブラリを多用しないこと
現行のAJAXは他のライブラリと同時に使用することを考えて設計されていないものも多い為、多用してしまうと思わぬバグを埋め込んでしまう。既存システムで利用しているJavaScriptにも影響するため安易に導入すべきではない。例えばPrototype.jsは著名なAJAXライブラリではあるが、JavaScriptのNativeオブジェクトの挙動を変更してしまう。これらの問題を回避する為に「OpenAjax Alliance」で標準化が進められてはいる。
どうしても戻るボタンの無効化をしたい
お勧めはしないが方法としては次の方法で可能である。通常の画面遷移はa要素ではなくJavaScriptのlocation.replaceを用いる。現在のhistoryが上書きされるため、Webアプリ上の別画面に戻れなくなる。
(ブラウザのウィンドウの初期表示が当該Webアプリであれば戻るボタンはアクティブにはならない。ブラウザのウィンドウが当該Webアプリ表示以前に別サイトを表示していたのであればそちらに移動する。)
フォームの場合(特にPOSTの場合)は最小化したiframe要素を配置しターゲットをiframeに設定する。更に、iframeのonload時にparent.location.replaceを用いた再描画処理を行う。frameで可能のように感じるが、これでは戻るボタンが有効化する。画面の再描画処理はDOMでも可能に感じられるが、iframeに対しての履歴が有効になる。「履歴が有効になったiframe」をそれを含むhtml毎replaceしてしまうのが肝である。ただ、このような実装を行うと他に無理が生じてしまうためお勧めはできない。やはり履歴ありの(つまり戻るボタンが押されてもよい)設計をすべきである。
(ブラウザのウィンドウの初期表示が当該Webアプリであれば戻るボタンはアクティブにはならない。ブラウザのウィンドウが当該Webアプリ表示以前に別サイトを表示していたのであればそちらに移動する。)
フォームの場合(特にPOSTの場合)は最小化したiframe要素を配置しターゲットをiframeに設定する。更に、iframeのonload時にparent.location.replaceを用いた再描画処理を行う。frameで可能のように感じるが、これでは戻るボタンが有効化する。画面の再描画処理はDOMでも可能に感じられるが、iframeに対しての履歴が有効になる。「履歴が有効になったiframe」をそれを含むhtml毎replaceしてしまうのが肝である。ただ、このような実装を行うと他に無理が生じてしまうためお勧めはできない。やはり履歴ありの(つまり戻るボタンが押されてもよい)設計をすべきである。