有効とは？/ マイワン
[ 144] ITmedia ライフスタイル：日本にサマータイムは有効か (1/3)
[引用サイト] http://plusd.itmedia.co.jp/lifestyle/articles/0504/04/news004.html
|
今国会では「サマータイム法案」なるものが提出されようとしている。これまで何度か浮上しては見送られてきた経緯を持つ同制度だが、今回はかなり本気度が高いといえそうだ。果たして日本でサマータイムは有効に機能するのか、筆者なりに考えてみた。 筆者の父は、地方公務員であった。勤務先が自宅から自転車で10分ほどの福祉事務所だったこともあって、夏場は日没までにまだいくらかの時間もあるうちに帰宅したものだ。 毎日時計のような正確さで5時15分に帰宅すると、長いホースを引っ張り出して庭の植木に水をやる。筆者が子供の頃は、夕日に照らされた水しぶきに虹ができるのを眺めるのが大好きで、飽きもせず父親の後をついて回ったものだった。それが終わると、ちょうど大相撲の最後の3取り組みぐらいの時間となる。 テレビの前に寝転がって大鵬が勝つのを確認すると、今度は風呂に入って浴衣に着替える。あとは焼酎をチビチビとなめながら、今朝の読み残しの朝刊を隅々まで読むうちに、夕餉の支度ができあがる。7時ごろには酒屋を営む祖父母も店を閉めて、一家6人そろっての食事となるという日々が、永遠に続くと思われたものである。 大人になれば、そういう生活が待っているものだと思っていた。ところがいざ自分が就職してみると、そんな生活など夢のまた夢であることを思い知らされることになる。特に筆者が就職したのはテレビ業界でもっともキツい職種、ポストプロダクション勤めだったため、朝9時半に出勤すると、翌朝の9時半までノンストップでみっちり働かされる。睡眠は2日に1度という生活が、4年あまりも続いた。 筆者がそんな会社を辞めようと思ったきっかけは、ある日、赤坂溜池のあたりで、赤坂プリンスの向こう側に沈みゆく夕日を見てしまったからである。その日は編集室の改装工事が入っており、いつもよりも早く、というか普通の時間に帰ることになったのだ。 水面に反射する落陽の光に包まれながら、家路へと急ぐ人の群れに混じって歩いていると、ふと父のことが思い出された。筆者の記憶の中では、大人も子供も、夕焼けの黄金色の光の中で、家に帰るというのが常識だったはずなのである。 普通は今頃帰るんだよな、という思いと、このままこの仕事を続けている限りこんな時間には帰れるはずがないな、という思いが交錯し、「こんな生活は人間らしいとは言えないんじゃないか」という怒りにも似た感情がこみ上げてきた。 結局それから会社を辞めるまで、なんだかんだと慰留されて半年もかかってしまった。「精神的な健康」を求めて会社側と話し合っても、「そんなことを考えるのはオマエが弱い人間だからだ」と叱責されたような時代である。だがその後の人生や、人との出会いを考えると、あのとき主張したことは間違っていなかったと思えるし、やっぱり辞めて良かったんだろうな、と思う。 今国会では、「サマータイム法案」なるものが提出されようとしている。日本では数年前から、世論調査などの結果を見ながらサマータイムの導入が検討されているが、今年はその正念場を迎えることになりそうだ。 まずサマータイムの基本的なところからおさらいしてみよう。この制度は、日照時間が長くなる期間に限って時計を一時間早める、つまり働く時間を全体的に「せぇの」で前に一時間ずらすことで、太陽が照っている時間を有効的に使おう、というのが基本的な考え方である。 たとえば朝5時に日が昇っても、ほとんどの人はそこから1〜2時間は寝て過ごしている。その分が無駄というわけである。太陽が出ている時間と人間の起きている時間を極力シンクロさせるわけである。 世界的に見ると、サマータイムを導入している国は、ECとカナダ、米国ほか、それらの国々と関係が深い国、オーストラリアやニュージーランド、メキシコ、キューバなどが実施している。アジアではロシアやモンゴルも導入国である。 導入国を見るとわかるように、比較的緯度が高いため元々日照時間が短い国では、導入のメリットが高いことは想像に難くない。一方、低緯度の近隣国でも導入しているのは、取引国と時間を合わせた方がビジネス面で有利だから、という面が強い。 一見いいことばかりに見えるが、すんなり導入が決まらないわけは、それぞれの要素に対して反論があるからだ。 じめじめする季節。でも夏が近くなり気温は高い、どこへ遊びにいこうか。おススメは水族館である。ということで、水族館で魚を撮ろう、という話をするのである。 ソニーが従来比約2倍の感度や低ノイズ性を実現する裏面照射型CMOSセンサーの試作開発に成功。デジタルカメラやビデオカメラへの採用が期待される。 最近、個人的に注目しているのが20〜16インチ程度の小型液晶テレビだ。以前は小型テレビといえばコスト最優先の製品ばかりで、画質に関してはさほどケアされていないものが多かった。ところが最近は事情が変わっている。 今年はオリンピックイヤー。かつてほど爆発的に売り上げが伸びるわけではないが、それでもやはり通常期よりは市場は盛り上がるため、各社は商機を逃がすまいと、独自の戦略で新製品を投入している。まずは東芝とパナソニックを取り上げ、新製品の傾向を探ってみたい。 ソニーのBRAVIA「M1シリーズ」は、ポップなスタイルと豊富なカラーバリエーションを持つパーソナル液晶テレビ。単に大型テレビをスケールダウンしたような製品が多い中、明らかに小型テレビのために設計されたデザインだ。その外観と機能性をチェックしていこう。 春は、入学や就職のために新しい生活を始める人がもっとも増える季節。部屋のふんいきを決めるテレビの選択には少し気合いを入れたいものだ。そこで今回は、一人暮らしや個室利用に適した20V型前後の液晶テレビを紹介しよう。 |
[ 145] MSゴシックとMS明朝で、ClearTypeを有効にする
[引用サイト] http://tomtia.plala.jp/PC/ttfont/
|
好みの問題はあるだろうが、標準スムージングとClearType処理を施したものでは、曲線部分や斜線の部分がなめらかな感じになっているのがわかると思う。対して、処理を行っていないものでは、特に斜線がガタガタだ。標準スムージングとClearTypeとを比較すると、スムーズ感は同等もしくは標準の方が強いが、文字のエッジがぼんやりとぼやけた感じがする。特にAの文字の横棒や、Bの文字の一番下の部分などに顕著だ。対してClearTypeの方もぼやけた感じはあるが、ぼやけ具合は標準よりはずっと少なく、文字はきれいながらもシャープな印象だ(ただしClearTypeはデジタル接続の液晶専用なので、それ以外の環境で見ている人にはそう見えないはず)。 もちろん、個々のサブピクセルにはRGBの色がついているために、このようにして解像度を上げると、本来表示したい色とは異なる色が発生してしまう。ただ幸いにして人間の目は明るさの変化には敏感だが色の変化には鈍感なため、狭い範囲であれば色変化は感じずらい。この原理を利用したのが、ClearTypeによるアンチエイリアシングの原理である。 この原理は、アンチエイリアス処理が行われている部分を拡大してみるとわかる。以下が「／」の文字の一部を15倍に拡大した画像だ。 標準のアンチエイリアシング処理ではグレーレベルになっている部分のピクセルが、グレー以外の色つきになっていることがわかる。そこで、各ピクセルをそれぞれRGBの要素に分割して、さらにRGBごとの値をグレーレベルに変換して表示してみたのが、以下の図である。 各色をRGBの要素に分解。さらにそれをグレーレベルに変換してサブピクセルの「明るさ」としてマッピングした図。仮に人間の目が「明るさ」しか感じないとすれば、このように見える。 一見してわかるように、これは通常のアンチエイリアシング処理を横方向だけ3倍の解像度で適用したのと同じような効果となっている。逆に縦方向に関しては、通常のアンチエイリアス処理となんら変わりない。原寸大表示の画像で、「Ｃ」の文字の上端や下端部分がちょっとでこぼこした感じにみえるのは、このことが原因だろう。 しかし、設定した経験のある人ならわかると思うが、これを設定すると英文フォントに関してはClearTypeが有効になるものの、日本語フォントについては特に変化が起きない。 これができるとなにがうれしいかというと、一部の漢字やかなの字体だけを変更し、他のすべての文字は同一というフォントを簡単に作ることができるのだ。 たとえばmsgothic.ttcの場合、MSゴシックとMS P ゴシック、MS UIゴシックという3種類のフォントファイルが含まれている。これら3つの書体は、漢字および仮名については、すべて同じ文字が使われているが、英数字や仮名の部分はそれぞれ異なる。MSゴシックは、1バイト文字(いわゆる半角文字)の幅は2バイト系(全角)文字の1/2の幅となる。対してMS Pゴシックは、英文字および数字に関しては、文字の種類に応じて文字幅が異なる「プロポーショナル文字」となっている。MS UIゴシックは、2バイト系のカタカナ文字の幅が通常の漢字よりも狭く、ちょうど「半角カタカナ」くらいの幅で表示されるようになっている。これはメニューバーなどでカタカナ文字を表示する場合に、あまり横幅をとらないようにするためだ。 ttcファイルでは、それに含まれる複数フォントのうち、共通の文字については文字データを共用できるように作られている。このため「一部だけが異なる複数のフォント」を保持するのに都合がよい。 [メトリックファイル]というのが、処理対象となるビットマップデータを格納したファイル名だ。すでに述べたように、sbit32.exeは、既存のフォントファイルにビットマップデータを追加することを目的としたツールであるため、本来であればここに指定するファイルの中に、ビットマップフォントのデータを入れておくのである。しかし今回は、既存のファイルからビットマップフォントのデータを取り去ることが目的なので、ここには、取り去りたいビットマップ情報を示すデータを入れておけばよい。具体的に言えば、このファイルのフォーマットは次の様になる。 ここで[サイズ]とはビットマップデータのピクセル数。この内容をテキストファイルとして保存し、SBIT32.EXEのパラメータとしてやることで、[サイズ]で指定されたピクセルサイズを持つビットマップデータだけが削除される。通常、ひとつのフォントには複数のびくセルサイズを持つビットマップデータが含まれていることが普通なので、取り去りたいサイズすべてについてこのコマンドを実行してやる必要がある。 もちろん、すべて手作業でやっても同じことはできるが、あまりに面倒なので、バッチファイルを作ってみた。 この内容をバッチファイルにセーブして、以下のように、元のフォントファイルと新しいフォントファイルの名前をセットする。これでサイズ7からサイズ22までのEBDTがすべて削除されたものが、出力先に指定されたフォントファイルに収められる。たとえば、バッチファイル名をrmEBDT.batとする場合、 次のステップでは、フォントファイル中に含まれる「フォント名称」を変更する。Windows上のフォントは、フォントフォルダ中で「フォント名」の一覧が表示されることからもわかるように、フォントのファイル名ではなくフォント自身の「名前」で区別される。つまり、データが収められているフォントファイルが異なっていても、内部に記録されたフォント名が同じであれば、同じフォントと見なされるわけだ。 これまでの手順では、フォント名にはまったく変更を加えていないため、フォント名称は「MSゴシック」のままだ。つまりこのままでは、システムに標準で備わっているMSゴシックと名称がバッティングするため、いま新たに作ったフォントをシステムに登録することはできない。(正確にいえば、TTCフォントとTTFフォントに関しては、名前がバッティングした時にはTTFが優先するようになっているようだ。このため、TTFフォントのままであれば名前がバッティングしていても登録は可能で、再起動後は新規に登録したTTFフォントが使われるようになる。ただしこの方法はイレギュラーな方法なので、あまりお勧めしない) ただしこの場合、元々存在するビットマップフォントと、TrueTypeによりレンダリングされる文字とのサイズの微妙な違いなどから、一部画面デザインなどが崩れる可能性もある。少々リスキーな方法だ。どちらにするかは好みの問題で決めればよいと思うが、ここではフォントの名称を変更する方法を紹介する。 どのように名前を変更するかは、利用者の好みでかまわない。私の場合、ビットマップデータを削除したことがわかるように、フォント名の後にすべて(NoBitmap)NBという文字列を付加した。 第一パラメータには、作成されるTTCファイルの名前。第二パラメータ以降が、そのTTCファイルに含まれるTTFフォントのファイル名だ。TTCファイルのファイル名は適当に決めて良いのだが、あとでこのファイルをフォントフォルダにコピーしなければならないので、フォントフォルダに同じ名前のファイルが無いようにしなければいけない。今回は、MSゴシックのビットマップ無し版ということで、nbmsgot.ttcという名前にした。 ただし、元ファイルに対して上書きする際には、Windows上から行うことはできない。なぜならWindowsの起動中は常にMSゴシックがシステムフォントとして利用されているため、それまで使われていたMSゴシックのファイルを削除することができないためだ。このため、この操作を行うには、他のOSでディスクを直接編集したり、回復コンソールからファイルの上書き操作をしなければならなくなる。 今回作成したフォントで、アンチエイリアシングなしに設定。ビットマップフォントが無いので小さな文字でもすべてアウトラインから生成される。きたなくて使い物にならない? |
[ 146] 「OK」と「キャンセル」、どちらが有効か − ＠IT
[引用サイト] http://www.atmarkit.co.jp/fwcr/rensai/usabilitytips04/01.html
|
英語や、日本語の横書きでは、情報は大きく上から下に、左から右に展開していきます。ユーザーは画面（ウィンドウ内）の左上から右下に向かって意識を推移させて、そこで表現されている情報を取得していきます。 実際にはユーザーは、まず画面中央付近に視線をやり、そして全体をざっと見渡してから、重要と思われる個所に注目していくようです。ひとたび内容を読もうとか、入力フィールドを埋めていこうと決めたら、当然、上から下に、左から右に向かって意識を集中させたり、入力作業を進めていくことになります。 そのため、「『戻る』で入力データが消えてしまうフォームはいらない」でも書いたとおり、フォーム要素や各種コントロールは、その意識の流れに合わせて配置しなければなりません。また、次のページに進むための「次へ→」といったナビゲーションは画面の右下に配置するのが自然です（「←前へ」は、それと対になるように、左下に配置するのがよいでしょう）。 多くのフォーム画面や、ダイアログボックスでは、そこで行った入力作業を確定させて次の作業に進むためのアクションとして、画面の最下部（もしくは一連のフォームコントロールの下）に、「OK」と「キャンセル」といったボタンを配置しています。 肯定ボタンはデフォルトボタンとも呼ばれ、（ユーザーが操作ミスをしてその画面にたどり着いたのでない限り）それがユーザーの求めるアクションであると同時に、システムが推奨するアクションであることを意味します。 Macではデフォルトボタンを右に、Windowsではデフォルトボタンを左に配置しています。両方のOSを使うことがある方なら、この違いが思わぬ操作ミスにつながることがあるのを知っているでしょう。デフォルトボタンの位置は習慣として身に付いてしまうため、順序が逆転してしまうと、OKを押そうとしてついキャンセルを押してしまう（あるいはその逆）といったミスが多く発生するのです。 デフォルトボタンは左右のどちらがよいのか、という問題の答えは、おそらく「右の方がよい」でしょう。理由は、その方が情報の流れに合っているからです。ユーザーは左上から右下に向かって情報を取得していきます。 そのため、デフォルトボタンが右側（つまり画面全体における右下）にあると、それは現在の画面における最後の情報であり、すなわち次の画面を呼び出すスイッチであることを示唆するからです。 これは、「次へ→」といったナビゲーションを画面の右下に配置すべきであるのと同じです。「次へ→」というボタンが画面の左側にあったらとても不自然です。2次元上の情報を追うとき、私たちの意識は上から下に、左から右に向いているのです。 また、デフォルトボタンが右側にあると、ユーザーは画面上で最後にその選択肢を目にすることになります。つまり画面上のあらゆる情報や選択肢（キャンセルも含む）をすべて見たうえで、次に進むかどうかを判断できるのです。 もちろん、デフォルトボタンが右下になくても、ユーザーは画面全体を見渡してから次に進むかどうかを判断することができます。しかし、そのためには、一度デフォルトボタンを通り過ぎて最後の選択肢まで見た後、デフォルトボタンに戻ってこなければなりません。 デフォルトボタンが常に右下にあるのであれば、ユーザーは途中を無視していきなりデフォルトボタンに働き掛けることも可能になります。デフォルトボタンを押すべきであるとあらかじめ知っているような場合にこれは合理的です。 デフォルトボタンとキャンセルボタンという2つの選択肢がある場合、重要なのは当然デフォルトボタンの方であり、キャンセルボタンはおまけです。ですから、デフォルトボタンを先に置き、キャンセルボタンを後に置いているのではないでしょうか。 しかしこの考え方は、2次元上にオブジェクトをレイアウトしてランダムアクセスできるようにするという GUI のコンセプトにあまり合致しておらず、多分に手続き的な論理展開です。先述のとおり、ユーザーは画面全体の中で、各コントロールの相対的な位置関係や大きさの対比から、それぞれの意味を把握しようとします。デフォルトボタンが左側にあると、全体の中で埋もれてしまい、目立たなくなってしまいます。 さらに、そもそもダイアログにおいて重要なのは、デフォルトボタンではなく、むしろキャンセルボタンであるといえます。なぜなら、画面下部にあるデフォルトボタンとキャンセルボタンは、ユーザーに対して「先に進む」か「前に戻る」かの意思決定を促す役割を担っていますが、すべてのユーザーが「先に進む」ことが分かっているのなら、キャンセルボタンは必要ないからです。 つまり、もしキャンセルボタンがあるのであれば、「あなたはここでキャンセルすることができますよ」ということをデフォルトボタンの存在よりも先にユーザーに示す必要があるのです。 従来のデスクトップアプリケーションでのGUIやインタラクションの原則から、Webアプリケーションのデザインを考えよう |
マイワンのサイトです。
