Titanium Desktopでアプリ開発

Titanium Desktopを使った業務アプリの開発で、設計方針を決める話の第４話です。設計方針の話としては、今回が最後となります。

今回は、HTMLとCSSを取り上げます。昔に比べるとCSSも機能が増え、実現できる範囲が広がりました。それでもなお、自由なレイアウトが簡単に作れるわけではありません。私個人としては、HTMLとCSSの組み合わせは、未だに不良品だと思っています。レイアウトを作ることに関して、根本的に設計が悪すぎるからです。

最近は大きな画面のモニタが増えました。画面を有効に使うためには、3段組とか4段組だけでなく、もっと自由な画面分割でレイアウトしたくなります。ところが、HTMLとCSSの組み合わせでは、非常に苦労します。もちろん皆さんも、ご存じのことでしょう。

HTMLからデザイン要素を取り除くため、できる限りCSSでデザインするという流れがあります。この考え方自体は非常に共感できるのですが、現実は辛いことばかり。納得のいかないことばかり。

代表的な例を１つ取り上げましょう。CSSで２段組や３段組を実現するとき、大きな違和感を感じます。２段組では、CSSのfloat指定でブロックを左右に分けます。３段組になると、２段組を二重に組合わせて実現するという情けなさです。HTML側は、divタグで何重にも囲む醜さが目立ちます。HTML側を汚さずにレイアウトを決めるはずのCSSなのに、多重divタグでHTML側を汚してしまってます。また、変な技を使わないと段組を作れないのは、根本的な問題です。すべてCSSの仕様の悪いのが原因でしょう。

もっと理想的な形は、レイアウトを自由に作れる機能をCSS側に用意することです。まるでtableタグで画面を区切るような形で、レイアウトを設計する機能をです。もちろんHTML側を汚さないのが大原則ですから、レイアウト用のタグは用意しません。すべてCSS側で指定する形にすべきです。書籍の２段組や３段組では、複数の段に１つの本文が流れます。HTML側にある連続したpタグが、CSS側で用意した複数段へと、文章が続くように挿入されていく機能も必要でしょう。このような発想でのCSSレイアウト機能だと思います。

実際には使えない話を語っているだけでは、ソフトウェアが完成しません。現実にどうするか、どの機能を使って実現するかを選択しなければなりません。過去にHTMLやCSSを使ってきた経験から、次のように決めました。全体の大まかなレイアウトに限り、複数段の実現では関しては、CSSを使わずに、tableタグを使います。

tableタグによるレイアウトは、HTMLやCSSの機能が貧弱だったときに多用された、古典的なレイアウト実現方法でした。それだけに、ほとんどのブラウザで安定した動きをします。期待を裏切られることは、めったにありません。逆にCSSは、細かな部分でブラウザがサポートしていないとか、困った状況が発生しやすい欠点があります。

実は、もっとも決め手となったのは、ウィンドウを画面いっぱいに広げたときの動きです。業務アプリの場合、そのウィンドウだけを画面いっぱいに広げて使うことが多くあります。そのとき大事なのが、コンテンツが中央に寄るかどうかです。HTMLでは左に寄ることが多く、非常に格好が悪く見えます。当然、アプリの信頼性も低そうに見えます。中央に寄せるのを実現する方法として、CSSを使うと、多くのブラウザで実現するのが難しいのです。tableタグなら、全体の大きさをCSSのwideで指定し、tableタグにalign="center"と指定するだけです。

tableタグでレイアウトといっても、細かな部分にまで使うわけではありません。画面のヘッダー部分、コンテンツの中身となる中央部分、中央分の下部の操作系、一番下の操作系となるフッター部分とい具合に、画面全体を４つに区切り、それぞれtableタグで囲むだけです。操作系は、tableタグ内を左右に分割します。コンテンツ部分は、必要に応じて多段組や上下複数段に分割します。こうした全体のレイアウトにだけ、tableタグを使うというわけです。

レイアウト用のtableタグ以外は、できるだけCSS側で属性を指定し、HTML側に細かな設定を持たないように作ります。CSSの設定も、ヘッダー用、フッター用、コンテンツの中身用、コンテンツ内の操作系用と、完全に４つに分けます。同じ設定なら一箇所で変更可能にとは作らず、使用場所ごとに設定を別にする作りとします。こうするとヘッダーだけ変えたいときに、変更の影響がヘッダー以内には及ばないと予測できます。そうではなく、同じ設定値だから一箇所にと設定値を無理矢理に１つにまとめると、影響の及ぶ範囲が把握しにくくなり、変更の際、困った状況に陥りやすいのです。

さて、ここまでの４回で、Titanium Desktopを使った業務アプリの設計指針がまとまりました。この方針に沿って、あとは実際の設計に進むだけです。といっても、HTMLによる画面の種類で区分けされる構造なので、必要な画面をHTMLで用意して、相互に接続するという形にしかなりませんが。

実際、アプリ自体は一旦完成して、依頼主が試用し始めました。その後、試しにiPad版をTitanium mobileで移植し始めたら、構造が違うので大枠を変えてしまったものの、意外に素早く移植できてしまいました。こちらも依頼主が試用し始めてます。当然ながら、機能はほとんど同じです。もともとiPad版で動かしたいという要望だっただけに、やはりiPad版を気に入ってしまいました。とりあえずiPad版を本番で使い始める準備中で、デスクトップ版は予備として残すという形だそうです。

デスクトップ版もタブレット版も、Titanium Studioで作れるのは非常に便利です。JavaScriptで統一できるのも素晴らしいです。ここではTitanium Desktopとして話を始めてしまったので、当分はデスクトップ版アプリ作りの話を続けたいと思います。

Titanium Desktopを使った業務アプリの開発で、設計方針を決める話の第３話です。

今回は、画面設計の方針を決めます。実現する技術に関してではなく、画面内に入れる情報レイアウトなどの標準化ですね。とくに目新しいことはなく、非常に一般的な方針を「おさらい」する感じです。

画面を上中下の３層に分けて、上部層がタイトル、下部層には画面移動などの、画面内容と関係の薄い操作系ボタンを入れます。下部層のボタンは左側と右側に分けて、画面切り替えボタンを左側に、その他のボタンを右側に並べましょう。

画面の中央層には、各画面の中心となる情報表示、情報操作のフィールドやボタンなどを並べます。ボタンについては、個別の情報に関係するものは情報表示の隣に、「登録」などの情報全体に関わるものは下側に並べます。

上中下の３層の区切りが明確になるように、区切り部分にBRタグを入れて境界を目立たせます。業務アプリですから、見栄えよりも分かりやすさを重視しているわけです。全体としての下部層にボタンが並び、中央層の下部にもボタンが並びますから、その区切りを伝える意味もあります。

続いて操作性に関してです。以前のシステムを設計したときから、マウスだけで（つまりキーボードを使わずに）操作できるようにとの強い要望が依頼主ありました。もちろん全部の操作が対象ではなく、日常業務で操作する画面に関してだけです。値の増減は、できる限り「＋」や「−」ボタンなどで行い、キーボードなしで使えるように配慮します。

エラーなどのメッセージを出す場所も決めます。下部層では、左右両端のボタンの間に、メッセージ用のラベルを用意します。中央層でも、一番下に付けた左右両端ボタンの間に、メッセージ用のラベルを作ります。

２つメッセージ用ラベルの使い分けは、非常に簡単です。個々の画面の内容に関するメッセージは、中央層のラベルに表示します。システム全体に関わるエラーなどは、下部層のラベルに表示するという具合です。たとえば、アプリの環境設定ファイルが読めない場合、システム全体でのエラーですから、下部層のエラーに表示することになります。ほとんどの機能はボタンで開始しますから、ボタンが付いている側のラベルを使うことになり、迷うことはありません。

画面に出すエラーメッセージも重要度で色分けします。重大なエラーは赤色で、注意点なら青色で、処理が成功したのを知らせるなら緑色などです。この辺の簡単な実現方法は、また別の機会に取り上げましょう。

残りはHTMLとCSSについてですが、これは次回に。