2013年12月6日金曜日

新キーボード プロジェクト? - プロトタイプ1号機

前回からすこし時間があいてしまいました。今回はいきなりですが実際に動く新キーボードのプロトタイプが完成したので、そこに至るまでの経過をまたまたGoogle+への投稿を再編集したりしつつ、まとめていきます。

新キーボードのプロトタイプ

立体配置 第3版


新キーボードのプロトタイプは前回のモックアップではなくて、立体配置第3版を元に作っています。下のモックアップの写真と上のプロトタイプの写真を比べると、 F5からF8キーの位置が変わっているほかはモックアップと同じように仕上がっていることがわかるかと思います。

立体配置 第3版のモックアップ
立体配置 第3版では、中迫勝先生の「キーボードの手前端の高さを低くすることによって机上面との段差をできるだけ小さくすれば、机上面を手・腕の支持台の延長として利用できると考えられる。」という考え方を第2版よりも推し進めて、本体手前端外側の一番低い部分を高さ4mmまで下げました。

ここまで端を下げるとパームレストを別途付けなくても、日本人の標準的な男性の手の大きさであれば特に違和感なく使うことができます(5, 6キーにもこのままで無理なく指が届く人が多いかと思います)。そのかわりに手のひらで押す位置に用意していたCtrlキーは高さを下げるのに障害になる ので親指側に移した他、傾斜を前方向と横方向にそれぞれ10°と第2版の5°よりもきつくしています。(これはどちらもふだんパームレストが不要になるこ とのメリットの方が大きいという想定での変更です。)

また、このモックアップでもう1つ違うのが親指用キーのあたりに配置していたカーソルキーを削除している点です。ひとつには手前端の高さを下げるためでもあるのですが、正直なところ邪魔なのでした。どちらにしてもホームポジションから手を離すなら、やっぱりオーセンティックなIBMのキーボードの位置の方が使いやすいように思います。

ただこのモックアップのまま作るとカーソルキーがまったくないのでどうするかというと、一見SHIFTキーに見えるキーが実はfnキーになっていて、fnキーを押しながらオレンジ色のキーを押すとそれがカーソルになるという具合になっています。この方がホームポジションから手もあまりずれないし、そういう使い方が合わなければ横にカーソルキーのユニットを置けばいいし、ということで結構割り切った作りになっています。

ちなみにSHIFTキーはTRON英語キーボードの流れを組んで、親指用キーのうち内側から3番目のキーがSHIFTキーになっています。もっともPICマイコンで制御しているので、ファームウェアを変更すればどんな配列にもすることができます。TRONかな配列はもちろん、親指シフト(Nicola)を使われている方にも向いているのではないかなぁと思います。

基板設計 ― KiCadとFreeRoutingで自動配線


今回、いきなりプロトタイプまで完成してしまっている一番の理由はKiCadというフリーのEDAソフトウェアの存在です。以前はソフトウェアに費用を掛けずに済まそうとすると、プリント基板の自動配線ができるソフトウェアは基板サイズに制限があったり(キーボードはパターンは単純だけれど基板サイズが大きいので使えなかった)、パターンの配線はすべて手作業だったりと、ちょっと基板を作ってみようという雰囲気ではなかったのです。それがKiCadだとFreeRoutingというソフトウェアと組み合わせて、基板の設計図上に部品の配置だけすれば配線は自動的にできる[1]ということで、試してみました。

自動配線してもらうためには回路図を描いておかないといけないので、回路図エディタでまず作図しておきます。

制御基板の回路図

鍵盤基板(右手側)の回路図

PIC18F4550まわりの回路はICの仕様書に記載があります。PIC18F4550は内蔵されているプルアップ抵抗を使えるのはポートBとポートDだけ、というのがちょっと注意点ですね。左右の鍵盤部分はふつうのキーマトリックスの回路です。回り込みを回避するためのダイオードは全部のキーにつけるのも大変なので、今回は一部のキーに限定して付けてあります。(ジャンパーが回路図にある理由は後述。)

続いて図形エディタで作画したキー配置図を基板エディタに読み込んで(Bitmap2componentを使って配置図を部品化して読み込んでいます)、実際にキーを配置していきます。基板に部品を置くだけなので、スイッチの配置を図形エディタで描いてあれこれ考えるのとそこの手間はほとんど同じです。

プリント基板エディタで部品を配置

配置できたらFreeRoutingに自動配線をさせてみます。両面基板を使える場合だとあっという間に配線が完了します。今回は感光基板を使って作りやすいように片面基板(表がジャンパーで裏が銅パターン)で作るので、配線と配線が交差しそうなところにジャンパー(0Ω抵抗)を回路図に追加して基板上に配置してからFreeRoutingに配線させてみて、うまく行かないようならまたジャンパーを追加して配線させてみて、という手順で作ってみました。

自動配線を終えて外形線とベタを追加したところ

KiCadは、はじめて使ったのでまだベストな使い方をできているかどうかわからないのですが、手作業で配線したりすることを考えると基板作りは相当に楽になりました。KiCadは日本語の情報交換サイト(kicad.jp)もあるので、すこしずつ使いこなせるようになったらいいな、というところです。

今回使ってみたところでは、FreeRoutingは 45°以外の斜めの外形線があると周辺をうまく使って配線できないようなので、まずは外形線を引かずに自動配線を終わらせて、外形線から飛び出しそうな配線があれば、ツールバーからDragを選択して内側に押し込めたい配線の外側から内側へマウスをドラッグして配線をまとめて移動して、後から外形線を引くようにするとうまく行きました。Drag中はネジ穴とか動いてほしくない部品まで動かそうと思えば動かせてしまうようなので、そこはちょっと注意です。

またネジ穴用に用意したNPTHホールにローカルのクリアランスを設定してあったのですが、ローカルのクリアランスの情報が自動的にはFreeRoutingに渡されていないようで、FreeRoutingに.dsnファイルを読み込ませるまえに.dsnファイルを編集して穴径をクリアランスを含めたサイズ(FreeRouting内部では円は正8角形で囲う形で処理しているようです)にテキストエディタで修正したりしています。

兎にも角にも試しでKiCadを使ってみたところ、数時間もあれば写真のような基板パターンを作れてしまうことが判明して、それならということで今回一気にプロトタイプまで作ることにしてしまったのでした。

基板作りと組み立て


ここまでできると、基板を作って組み立ていくことができます。最近は特に小さなサイズの基板は基板メーカーに発注してとてもやすく作ってもらうことができるようになっているようですが、今回は感光基板を使って組みました。

感光基板用フィルム

感光基板を作るときは感光基板用のフィルムがきれいに仕上がっていないときれいな基板が作れません。黒い部分がちゃんとべったり塗られていなかったり、線がかすかにでも途切れていたりするとあとで基板の修正にとても時間がかかったり、最悪フィルムの作成からやり直しということも。すこし高いですがサンハヤトのインクジェットフィルムにエプソンの染料系のプリンタを使って印刷するのが無難そうな感じですね(顔料系のプリンタやレーザープリンタだと、真っ黒に見えている部分も実は点の集まりになっていたり、薄かったり、ということがあるみたいです。ふつうに紙に印刷する分にはまったくわからないのですけれど)。今回はEPSONのEP-705A(年賀状シーズンの所為かネットの最安値よりも近所の電気屋さんの方がさらに安く売っていました)というプリンタで印刷してみました。

フィルムの原稿は、KiCadのプリント基板エディタからSVGファイルを出力するとドリル穴まで空いた原稿を作ることが出来ました。

鍵盤基板(右手側)とその部品
きれいなフィルムができたら、露光、現像、エッチング、外形加工、穴あけという手順で上の写真のような基板ができあがります。ここまでできれば、もう中学校の技術家庭科で習った範囲で作れますね。

基板の組み立て完了
こんな感じで左右の鍵盤と制御基板の計3枚を作ってFFCで繋げたら基板の組み立ては完了です(LEDは別途制御基板から右鍵盤にQIケーブルで接続しています)。そしてこれらの基板をアクリル板に固定してハウジングをかぶせたものが最初に載せたプロトタイプの写真になります。

アクリル板に固定した基板とハウジング

注意: この一連の作業の内、現像とエッチングは薬品を使うので誰にでもお勧めというわけではありません。基板メーカーに発注したり、CNCでプリント基板を作る[2]こともできるようなので、そのへんは使える機材や環境に応じて工夫してみて下さい。ちょこちょこ基板を作るような予定がなければ、必要な機材を揃えるよりも基板メーカーに発注する方が安く済みそうに思います。

ファームウェア


「コンピュータ ソフトなければ ただの箱」という言葉がありますが、PICマイコンを使ったこのキーボードもマイコン用のソフトウェア(ファームウェア)がなければ、ただのおもちゃで、マイコンの中のフラッシュROMの中にファームウェアを書き込んであげる必要があります。

PICマイコンの開発環境はmicrochip社からMPLAB Xという統合開発環境が無償で提供されています(以前のものと違ってWindows以外のOSでも利用できます)。またPICマイコンをUSBキーボード化するファームウェアは、Microchip Libraries for Applicationsをダウンロードすると、Device - HID - Keyboardというデモがあるので、これをベースに作っていくことができます。ボードのコンフィグレーションは、PICDEM_FSUSBがPIC18F4550のものなのでそれをもとに新キーボードの回路に合わせて変更していきます。

ただ肝心のソースコードの内USBのデモが新しいXC8コンパイラに未対応なので、jtemplesさんがmicrochip社のフォーラムに投稿されたものに差し替えるとうまくコンパイルできるようになります。

ファームウェアが出来上がったら、PICKit3などを使ってキーボードのPICマイコンにプログラムして(書き込んで)完成です。

まとめ


今回は新キーボードのプロトタイプができあがりました!、というお話と、どんな風にキーボードを作っているかというお話を簡単にまとめてみました。今回のこのブログも新キーボードで入力しています。自分の手に合うことはちゃんと確認してから作っているのでまあ当然ですが、なかなかいい感じで使えています。 :-)

あとは3Dプリンタでハウジングを作ったりできると楽しい感じですが、今回の新キーボード シリーズはここまでです。ガジェットを作るのもどんどん簡単になってきていますね。

ちなみにこの新キーボードを大量生産するという話はまったくありません(笑)。もし5セット以上需要がありそうであれば基板メーカーにまとめて作ってもらうようにもう少し進めてみますので、基板だけでもほしいという方がいましたらお気軽にご連絡下さい。


[1] http://toragi.cqpub.co.jp/tabid/670/Default.aspx
[2] http://www.fumi2kick.com/komekame/archives/1656

2013年11月2日土曜日

新キーボード プロジェクト? - モックアップの制作と立体配置の検討

今回は新キーボードの立体的な配置とハウジングについて、Google+に書き込んでいたものを整理しておきます。

新キーボードのモックアップ

モックアップ作り


前回までで平面図上では18.8mm改定版でOKな感じになってきたので、モックアップを作りながら、さらに立体的な形状についても確認していきます。


モックアップ作り

上図はプリント基板に見立てたスチレンボードにキーの配置図を貼り付けて、その上にキーキャップを置いてみたところです。(このやり方以外に、MXスイッチも入手済みであればスタイロフォームとかにスイッチごと刺してテストするという手もあります。)

今回、一番気を使っている、手首を固定したまま[6]キーまで指が届くフルピッチ キーボード、という設計意図は無事にクリアできた感じです。逆に発覚した問題点は、
  1. [→]キーがちょっと手のひらに当たってしまう、
  2. 一番外側の親指用のキーは外側に行き過ぎ、
という2点。この部分を先に修正していきます。

補足: ちなみに写真のMXスイッチのキーキャップは、FILCOのオンラインショプで購入したもの。WASD Keyboardsみたいにレーザー刻印までカスタマイズできる日も来たりするといいですね。:-)

キー配置調整


実際にキーキャップを配置してさわってみると、フルピッチではそれぞれの親指が4キーずつ担当するというのはちょっと無理があるということで、平面図を修正しました。

18.8mm(L) 平面図(調整版)

親指については左右3キーずつ担当するように計2キー減らしました。かわりに5段目に薬指用のキーを左右1キーずつ追加しています。また、カーソルキーは1ピッチ内側に寄せて、手のひらに当たることがないようにしました。

補足:  調整版の平面図には、ファンクションキーとPrtScnからNumLockまでの16キーも追加してあります(このへんはエルゴノミックである必要はそれほどないので一例です)。このレイアウトでは感光基板で自作する場合のために150mm×200mmの範囲に左右それぞれ収まるようにしてあります。(サンハヤトの卓上エッチング装置で簡単に作れるのがこの大きさまでなので。)

基板部分のモック

調整版では、手の小さいひとでも、5段目のCtrlキーと薬指用のキー(いわゆるWindowsキー)の間に手のひら側面を入れるような感じで使うと(縦1ピッチ分距離を稼げるので)、[5]や[6]キーまで楽に人差し指が届くようになるひとが多いんじゃないかな、と思います。

CtrlキーとSpaceバーの間の隙間


モックをさわりながら新キーボードのキー配置を直していて気づいたのは、CtrlキーといわゆるWindowsキーの間の隙間が意外と重要だったということ。手の小さい人は、この隙間に手のひら側面が来るようにすると指が届く範囲が縦1ピッチ分広がる感じになります。

この隙間、実はかつてはどのPCのキーボードにもあったものです。そして特に手の小さい人にとって、かつてCtrlキーとSpaceバーの間にあったこの隙間はたぶんすごい意味のあるものだったろうという気がします。

http://en.wikipedia.org/wiki/AT_keyboard より

今Windowキーを間違って押さないように手首を動かして数字キーを押している手の小さな人も、この隙間が残っていればもう少し簡単に押せた筈です。今でもゲーミングキーボードだと誤操作しないようにWindowsキーを無効化できるのがふつうになっていることからも、この位置が微妙な位置だということがうかがえます。

1981年のIBM PCキーボード以来PC/AT、PS/2のEnhancedキーボードまで守られていたこのわずかな隙間がWindows 95と一緒にWindowsキーで潰されてしまったのは、ちょっとした悲劇だったのかもしれません。

場所がなかったわけではなくて、スペースバーを分割しないといけなかった日本語用のAXキーボードでも、106キーボードでも、この隙間だけは残していたのにちょっと不思議な感じさえあります( http://www.pfu.fujitsu.com/hhkeyboard/kb_collection/ )。

もっとも最近のほとんど真っ平らなノートパソコンとかのキーボードでは問題ではなかったりするので、このことは再検証されることはもうないかもしれませんね。

立体配置とパームレストのデザイン ― 逆傾斜版


キー配置に残っていた問題も解消できたので、キーボードの立体的な配置についても、モックアップを作りながら検証していきます。

もともと新キーボードは微妙に前方に逆傾斜をかける方向で考えていたのでパームレストが必須です。前回載せたイメージ図のようにドーンと大きなパームレストをつけてしまうのが楽は楽なのだけれど、それだとあまりエルゴノミック、エルゴノミックさせない、という新キーボードの目標から遠くなってしまうのが難しいところでした。

逆傾斜版のモックアップ

新キーボードではCtrlキーといわゆるWindowsキーの間にスペースがあるので、もともとZキーの下から50mmほどメインパーツ上にもパームレスト に使える部分があります。

そこで上の写真のモックアップでは、必要最小限の大きさのパームレスト パーツを手前につけて、なるべくおとなしめなデザインにすることを目指しました。手前の追加パーツは奥行きが20mmあるので、この状態でパームレストの奥行きは計70mmになります。手の小さい人はこの状態で十分なひともいると思います。

このパームレスト パーツは手前に引き出すことができます。下の写真はパーツを手前に10mm引き出したところ。これで奥行き80mmになるので、ほとんどの人に十分な長さになっていると思います。

パームレスト ユニットを引き出したところ

最初からパーツの奥行きを30mmにしたらいいのに、という声もありそうですが、チルトスタンドとかキーボードにはこういうちょっと動くパーツがあった方が楽しいよね、というだけだったりします(笑)。

『前方向と横方向にそれぞれ10°傾斜』の謎


さて、組み立てたモックアップを見ながら最初の印象は、キーボードに逆傾斜をかけると中央部分がやっぱり高すぎだよなぁ、というものでした。赤い板の頂点の部分で5cm弱あります。ということでちょっと調査してみました。

モックアップは中央方向へは(エルゴノミック キーボードでよく採用されている)10度の傾斜がかかっているのだけれど、その根拠は「キーボードの人間工学的設計」という1986年の中迫勝先生の論文まで戻ることができました。 あらためて読んでみると「支持面を大きくするために前方向と横方向にそれぞれ10°傾斜させ、前腕全体を支持できるようにした」とあって、支持面(アーム レスト)を大きくすることがゴールで、そのためには10°くらいの傾斜が最適ということだったようです。

最近は前方向の傾斜は手首の負担を考えて否定されているけれど、もとの論文はそういったことを言っていたのではなくて、前腕全体を10°くらい傾斜した支持台の上に置けるとよい、と言っているだけだったんですね。実際に作られていたキーボードの支持面とキー部分の前方向の傾斜は0°。なんという。

となると、キーボードをコンパクトにすることの方が優先度が高ければ、論文にも書かれているように「キーボードの手前端の高さを低くすることによって机上面との段差をできるだけ小さくすれば、机上面を手・腕の支持台の延長として利用できると考えられる。」という考え方を優先してキーボードの立体配置を考えた方が良さそうです。

最近の薄いキーボードだと机のわりと奥の方にキーボードをおいて肘から先を全部机の上に置いて使うのは結構あたりまえのように思うけれど、昔のApple IIとかをみると実はキーボードは今では信じられないような高い位置( 机から5cmくらいありそう)にあったのが割とふつうだったという歴史があったみたいですね。

立体配置 第2版


前方向と横方向にそれぞれ10°傾斜、というよく言われている指針は、キーボード ユニット単独の傾斜のことではなくて支持台(アームレスト)に適した傾斜のことだったということがわかったので、新キーボードの設計方針を以下のように変更しました。
  1. メインのキーボードユニットはなるべくコンパクトにする。
  2. 逆傾斜などはもっと広大なアームレスト(≠パームレスト)とセットで考えることにして、メインのユニットとは切り離す。
ということで、傾斜は前方向と横方向にそれぞれ5°と控えな目な立体配置で作ってみたモックアップが下の写真になります。


新キーボードの立体配置

写真のものはMXスイッチを使う想定で組み立てているので、キーキャップの最下面から本体底面まで16mmの厚みがあります。この状態だと手前の段差が大き過ぎるので、実際に使うときには、カーソルキーの外側のラインからさらに手前に40mm位パームレストがないといけません。(逆に薄型のスイッチで組み立てる場合には、上の写真のように奥行き15cmほどで作ることができそうです。)

また自作等ではんだ付けを簡単に済ませたい場合はマイコンはDIP(Dual Inline Package)版を使うことになると思いますが、その場合上の写真のサイズに収めるのはちょっと難しそうです。

下の写真は、DIP版マイコンを使う場合の基板が緑色の板のサイズくらいになるので、これを手前中央に配置することにして、それを覆うような形でパームレスト部分を作ってみたものです。パームレストはZキーの下から手前に8cmとってあります。また全体の奥行きは約20cm、ほぼA4サイズになりました。

パームレスト一体型の新キーボードのモックアップ

まとめ


というわけで、今回はひとまず2つ目のモックアップが出来上がったところまでです。

実際に使用する場合は、机の上に前腕を置いて新キーボードのパームレストの上に手のひらを載せた姿勢で使う感じになります。この立体的な形状が本当に使いやすのか、疲れにくいのか、といったところは多少時間をかけて評価してみないとですね。

2013年10月26日土曜日

新キーボード プロジェクト? - 18.8mm改訂版と評価

今回は新キーボードのキーピッチ18.8mm版(L)の改定と評価について、Google+に書き込んでいたものを整理しておきます。

その前に前回、「(エルゴノミックキーボードと)長方形のキーボードとの比較はあまり意味がない」とあっさり書いてしまったので少し補足。エルゴノミック キーボードと長方形のキーボードの一番の違いは、「長方形のキーボードは手および手首をキーボードから浮かせて使うもの」で「エルゴノミック キーボードは手首をパームレストに置いたまま使えるようにしたもの」ということ。「特にコンピュータを長時間操作するときは、…手および手首をキーボードから浮かせた状態で入力します。…てのひらや手首をパームレストなどに載せた状態で入力しないでください。」[1]というのが長方形のキーボードの正しい使い方ですね。

Escudoウェブブラウザはバージョン0.4.0を今週リリースしました。修正内容については前々回まとめた通りのものになっています。0.4.1の計画についてはまた別にまとめていきます。

コストのお話


キーボード、自作するといくらかかるの?という心配があるようなので参考までにMXスイッチを使って18.8mmのキーピッチで作るとすると、

  • キースイッチ(87個以上)  6,500円位
  • キーキャップ一式 4,000円位
  • 感光基板(2, 3枚) 3,800円位 (基板を自分で作る場合)
  • USBマイコン(PIC18F4550等) 370円
  • コンデンサー, 抵抗, LED, 配線ケーブル等 1,000円位

といった感じになります。18.8mm以外のキーピッチを使う場合は、キーキャップの入手や加工が結構手間になります。MXスイッチのかわりにもっと小さなタクトスイッチとかもあるのですが、それだとキータッチや寿命に不安があったります(4代目が使えなくなった原因)。

というわけで、失敗せずに作れると合計16,000円位といったところでしょうか。ただ感光基板を自分で作る場合、というのがちょっと罠ですね。欲しい人を集められたり、予算に余裕があればP板.comとかで作ってもらう方がいいと思います。あとはパターン設計とかハンダ付けとか根気と時間です(笑)。マイコンはキーボード用のソースコードが配布されているのでそれをちょっとカスタマイズできるくらいのプログラミング(C言語)ができれば大丈夫です。それから本当に最初はハンダごてとかPICライタとか多少出費がかかります。

さらに格好のよいハウジングがほしいときは、3D CADでSTLデータを作って、光造形屋さんに頼むか、流行りの3D プリンタで自作!

4代目TRONキーボード用のハウジングデータ

ここまでやるとキーボード1台には高すぎですね f^_^;;

18.8mm(L)改定版


部材的にはやっぱりフルピッチ版以外はちょっと…、ということで18.8mm版を再調整しました。設計方針は、両端小指部分は手の小さい人は手のひら側面を軸に腕を回転して使ってもらうことにすることで妥協するかわりに、本来17mm版向きの手の大きさのひとも無理なく使えるようにする、というもの。18.8mm版しか作れなくても、手に合う人を最大限増やそう、と。


気をつけたのは、
  1. あまりにエルゴノミック、エルゴノミックしすぎないようにする、
  2. メインの左上1から右下Bまでの5x4キーの範囲では手の小さい人に支障がないように特に5キーが離れすぎないようにする、
といった点。また逆に手の横幅が大きい人のことも考えて、指を開く角度を17mm版よりもすこし小さくしてあります。

17mm版(M)との比較


17mm版(M)との比較

17mm版と比較すると、上端のラインはほぼ一致していることがわかります。今回の18.8mm版は人差し指の2列が1/4ピッチほど上下にずれた形状になっていて、手の小さい人でも5, 6キーに指が届きやすいようになっています。

そのかわり4段目のZXCVBはややキーの上側を押すことになりそうです。これは悪いことばかりではなくて、手の小さい人だとフルピッチの4段目をタイプするとき指先がキーボード面とかなり垂直に近い角度になってしまうので、爪が当たらないようにスイッチの上側を押す方がよいかな、というのがあったりします。(キーキャップの形状もかなり影響しそうですが。)

Microsoft Sculpt Ergonomicとの比較


Microsoft社の公式ブログ[2]の写真を製品の寸法にあわせて加工したものに、18.8mm版の平面図を重ねてみました。

Microsoft Sculpt Ergonomicとの比較

可能な範囲で人差し指のキーを下げている新キーボードの形状が分かるでしょうか。(新キーボード、横幅が広く見えますが、実際にはTRONキーボードのように中央方向に向かって傾斜していくので、実際に上から見たときはもう少し狭く見えると思います。)

キーボードの立体的な形状までMicrosoft Sculpt Ergonomicくらい工夫できていると、このフルピッチならすこし手が小さくても全部のキーにちゃんと指が届きそうです。

Truly Ergonomicとの比較


同じくフルピッチのエルゴノミック キーボード、Truly Ergonomic [3]との比較です。実物を見たことがないので公式サイトの写真を製品の寸法に合わせて加工したものの上に新キーボードの平面図を重ねてみました。

Truly Ergonomicとの比較

人差し指と親指の考え方にちょっと相違があると思うけれど、それ以外はよくにています。実際にTruly Ergonomicを回転させて比較すると、違いはもうミリ単位になってきています。(フルピッチで作ると、もうそんなにデザイン的な余裕がありません。)

Truly Ergonomicを回転させて比較

全体的にハの字形状の角度の違いや、各列の角度の設定が、新キーボードの方がより手の小さい人向けに合わせている感じだと思います。このあたり、mm単位の指の長さ違いで日本人の人口のカバー率が何十%も変わったりする[4]ので手を抜けないところです。

ちなみに人差し指の部分は、新キーボード < Sculpt Ergonomic < Truly Ergonomicの順で数ミリずつ上に上がっていっている感じですね。実におもしろい。 :P

余談: 僕の予想では人差し指が7.8cm以上あるひとならTruly Ergonomicはかなりいいんじゃないかと思います。新キーボードと重ならない上段両端の4キーは小指はムリでも薬指が届くと思うので、そっちはそんなに心配いらないんじゃなかな、と思います。念のため。

手のサイズに合わないエルゴノミック キーボードを使うのはよくない


ここまで手の小さい人、大きい人、何ミリ上とか下とか細かいことを書いているなぁ、という印象のひとも多いと思います。watchmonoのTruly Ergonomicのレビュー[5]でも「特に手が小さい人は、打ちづらいキーがある→手・腕を動してしまう→全然エルゴノミクスじゃないすか!や だー!・・・・って事になりかねない」と書いてあったりします。

ということで手の小さめの人がどんな手の動きをしているか、というのを示してみたの下図です。マゼンダの枠が薬指・小指を使うときの理想的な手の位置で、グリーンの枠が人差し指・中指・親指を使う時の理想的な手の位置です。人差し指を使うときは手首をやや外側にひねって、腕を少し前に出すような動作が必要になります。これをエルゴノミックだからと手首を置いたままやっていたらレビューのような感想そのままになるんじゃないかと思います。(手の大きい人なら、こうはならないと思います。念のため。)

サイズの合わないエルゴノミックキーボードを無理に使おうとすると

なのでオリジナルのTRON キーボードではL・M・Sとか異なるサイズのキーボードを用意したい、ということになっていました(実際には1サイズしか出ていないそうです[6])。現状ではあまり数がでないエルゴノミック キーボードをさらに数サイズ量産するというのは、ビジネスとしては厳しすぎるのでどれか1サイズで、ということになってしまうのは仕方のないところがあるかもしれませんね。そこで最大公約数みたいなのを探さないといけない、というのはなかなか大変です。

コスト的に可能なら機構的に各指のキーのブロックの位置をCyborgマウスのように調整できるといいかもしれませんね。最悪人差し指のブロックだけでも上下方向に10mmぐらい調整できればかなり違うと思います。(これだけでも機構の他に、基板が1〜2枚増えてなかなかチャレンジングです^^; )

ハウジング


今回、考えているハウジングのおおまかな形状は下図のようなイメージです。

ハウジングのイメージ

最近は昔と違ってキーボードは手前がやや高めで奥に行くほど低くなっていく逆傾斜がかかっている方が手首に負担が掛からなくてよいと考えられている様子です(難点はキートップの字が読みにくい、ということなのだけれど、エルゴノミックを使う人はタッチタイプ前提なのでたぶん問題ない筈)。その場合、パームレストが必須になるので図のように左右下に貼り出した感じになって、TRONキーボードと似ているけれど、傾き方が逆という感じです。

これくらいの形状だと、安く作りたければアクリル板と接着剤でだいたいつくれそうですね。凝るのであれば、カウンタックのリアのようなデザインを取り入れると欲しくなりそうです、たぶん :P

まとめ


というわけで、先日購入したSculpt Ergonomicをしばらく使っていたのですが、本当に微妙に自分の手のサイズに合っていない感じで、このまま使い続けていると新キーボードをすぐにでも作りたくなってしまいそうだったので、ひとまずまだ使えそうな3代目の自作TRONキーボードをひっぱりだしてきてしまいました f^_^;;

3代目自作TRONキーボード

これは2005年ごろに マジェスタッチを分解して部品だけ取ってキーピッチ16mmで組み直したもので、それから3年くらい使っていました。MX茶軸スイッチは8年くらいたった今でも劣化している感じはなくてさすがです。TRONキーボードの16mmピッチは小指の部分が自分の手に合っていないのだけれど、しばらくはこれで我慢。

時間があったらkicadをちょっと試してみたかったりするのだけれども(笑)


[1] http://windows.microsoft.com/ja-jp/windows/using-keyboard#using-keyboard=windows-vista
[2] http://blogs.technet.com/b/firehose/archive/2013/08/13/work-a-pain-new-sculpt-ergonomic-desktop-keyboard-combines-looks-and-comfort.aspx
[3] http://www.trulyergonomic.com/
[4] http://riodb.ibase.aist.go.jp/dhbodydb/hand/data/list.html
[5] http://watchmonoblog.blog71.fc2.com/blog-entry-2775.html
[6] http://ja.wikipedia.org/wiki/TRONプロジェクト

2013年10月15日火曜日

新キーボード プロジェクト? - 評価

今回は、前回に引き続き新キーボードのキーピッチ18.8mm版(L)と17mm版(M)がまとまってきたので、そのお披露目と評価です。内容はGoogle+に書き込んでいたものを整理したものです。

18.8mm版(L)


18.8mm版
全幅はA4サイズよりも若干大きい315mm。フルピッチのふつうサイズのキーボードで問題なくキーに指が届く人にはもともとエルゴノミック キーボードの利点を訴求しにくいという課題がありますが、これくらいやるとゲーミング キーボードにどうでしょう(笑)?ハウジングはシボレー・コルベット3代目 C3型のボンネットまわり風にするとよく合うと思います。

とは言っても、キーの物理的な配置は真面目にしているので、意外と手の小さめの人にも合います。

17mm版(M)


17mm版

今回の本命はこちらのキーピッチ17mm版です。前回の今風に作るとしたら…』ということで描いたイメージ図に合わせて、エルゴノミック キーボードにありがちな「何だこりゃ?」感をなるべく抑えてみました。各キーの傾斜は18.8mm版と共通になっています。

全幅は288mmとA4サイズに収まる大きさです。一般的なフルピッチのキーボードの全幅18.8*15=282mmとほとんど同じなので、11インチクラスのノートパソコンから合わせられそうなサイズになっています。

キーピッチを小さくするとデザインの自由度はあがる一方、あんまり指が窮屈にならないように気をつけないといけないのが難しいところです。この17mm版は、同じ指用のキーピッチは17mmですが、異なる指間では一番狭いX - C間で18mmあるので、手の小さい人から平均的な大きさの手の人まで使えるサイズだと思います。

評価


今回は試作前に17mm版を既存のキーボードと比較してみたいと思います。比較対象は、オリジナルのTRONキーボードMicrosoft Sculpt Ergonomicキーボード、μTRONキーボードの3種類です。(以下、比較写真の17mm版は上図の現行案より1つ前のバージョンになっています。)

TRONキーボードとの比較


キーピッチ16mmのTRONキーボード[1]の比較してみます。

TRONキーボードとの比較

まずは、親指、中指、薬指、カーソルについてはほぼ完全に重なります。基本的にTRONキーボードに小指の部分以外まったく不満がなかったのがうなずける結果と言えそうです。(今回TRONキーボードの寸法を計測してこうしたのではなくて、18.8mm版で最適化した角度をそのまま17mmにもってきたらこうなった、というのが興味深いところです。)

人差し指については新キーボードはTRONキーボードよりさらに傾斜がかかっているので完全には重なりません。ただ面白いのは、TRONキーボードのKとXキー(TRONはDvorakが標準)は重なっているというところ。TRONキーボードで一見無駄にJとKキーの間にスペースがあるように見えるのは、中指と人差し指がそこで窮屈にならないように配慮していたからだ、ということが分かります。逆に新キーボードの4と5キーは半ピッチずらしたほうが小さめの手の人には優しくなりそうです。

中央上段のTRONキーボードの×キー(Tabキーの上側)はちょっと指が届きにくい位置にある。比較的初期のTRONキーボードだとこのキーが×キーではなくてTabキーだった時期があります。ひと呼吸おくキーと見るか、打ちやすくあるべきキーと見るか、みたいなちょっとした考え方の違いがありそうに思います。

TRONキーボードの小指部分、僕が前回指が届きにくいと書いていた上段2つのキーは16mmピッチではぎりぎりの位置から若干はみ出していることがわかります(新キーボードは最初は外側は1キーのみにしていたのを2キーにしているので、これで結構ギリギリだという点に注意。僕の手の場合だとTRONキーボードは15mmピッチにしないと小指がつらい理由はここだったわけです)。

それから新キーボードで新設した最下段端のCtrlキーとTRONキーボードの命令キーは割と似た位置づけのキーだということがわかります。このキーは小指ではなくて手のひらでポンと押すようにするとスムーズに使えます。(新キーボードは2キー実は多いのでこのキーはなくてもという説もあります。)

というわけで、新キーボードはTRONキーボードよりも1mm広いキーピッチで同じ指の可動範囲の中に同数のキーをまとめられていることがわかりました。TRONキーボードは小指に多少負担がかかることをたぶん承知の上でどうして1のキーをQWERTYキーボードのQの位置へ持ってきたんだろう?というのがすこし不思議な感じがしますね。

Microsoft Sculpt Ergonomic キーボードとの比較


Microsoft Sculpt Ergonomic キーボードと比較してみます。

Microsoft Sculpt Ergonomic キーボードとの比較

フルピッチだと、「6まで人差し指が届かないです」とか、「1を小指でとかムリ」、みたいな人が多いのがよくわかるんじゃないかと思います。

とは言えSculpt Ergonomicキーボードのキーの並ぶ曲線の描き方はなかなか綺麗です。大きめの手のひとにはまったく問題ない空間的な設計になっていると思います。

それから新キーボードのカーソルとか親指キーとかが実はそんなにスペースをとっているわけではないこともわかるかと思います。パームレストにも写真右下の Altキー以外はあたりません(デザイン的なことがなければ、実際にはAltキー下にまでパームレストはいらないですね)。

立体的な形状はSculpt Ergonomicキーボードは本当によく出来ているので、そのまま新キーボード版を作ってほしいくらいです(笑)。

μTRONキーボードとの比較


長方形のキーボードとの比較はあまり意味がないのですが参考までに、同じキーピッチ17mmのμTRONキーボード[2]と比較してみます。

μTRONキーボードとの比較

単にキーピッチを19mmから17mmに小さくする、というだけでは、オリジナルのTRONキーボードが解決したような1や6に指が届くキーボードにはならないことがわかります。1や6キーのカバー率はキーピッチ19mmのMicrosoft Sculpt Ergonomicキーボードの方がむしろ少し優れていそうです。キーピッチよりもキーの物理的な配置を見なおした方が人の手には優しいということが言えそうです。

なおμTRONキーボードは『コンパクトにして持ち運べるように』[3]という狙いがあったようなので、こういう長方形の配置を選択したのではないかな、と思います。Microsoft Sculpt Ergonomicキーボードはエルゴノミック キーボードの中では小さい方ですが、持ち運ぶにはちょっと大きいかもしれないですね。

でもμTRONキーボード、縦に1段分大きくなってもいいからもっとオリジナルのTRONキーボードに近いものにしてほしかったな、と思うのでありました(笑)。

微調整


以上の評価から、新キーボードは数字の4, 5キーの位置がまだ指が届きにくい人がいる可能性がありそうなことがわかりました。また、カーソルキーの横のキーピッチが17mmだとやや指が窮屈で、ゲームのようなずっとカーソルキーに指を置いたままの使い方には不向きです。

そこでこの2点を調整したものが最初に紹介した17mmの現行版になります。現行版とTRONキーボードとを比較したのが下図です。4, 5キーについてより良好に指の可動範囲をカバーできていることがわかります。またカーソルキーについては、横のキーピッチを19mmに拡げてあります。

17mm現行版とTRONキーボードの比較

キーアサイン


今回キー数は101キーボードにWindowsキー2個とメニューキーを追加した104キーボードを念頭にしています。WindowsキーはUbuntuとかを使っている時も実は便利だったりしますね(個人的にはWindows 8よりもうまく使っていると思うくらいです)。テンキー、ファンクションキー、PrtScn, ScrLk, Pauseはどこでも好きなところに置いて下さい。ただテンキーはともかく他は取られると困ります。

QWERTYの場合、キーアサインの1案としては以下のような案が考えられます。`, [, ], \の4キーをどうするかが悩むところです。

キーアサイン案(QWERTY)

TRON配列の場合はそのまま使ってください!TRONキーボードとキー数を同一にするために当初案より実はキーを2つ増やしてあります(Ins, Delはなかったのでした) 。指を広い範囲に動かさずにカナを直接1文字ずつ入力できるのは意外と気持ちがいいものですよ(ただし、親指のShiftキーは必須)。

余談:  JIS配列は僕が日頃一切使っていないのでよくわかりませんが、増えた[ム]と[ロ]は[Ins], [Del]の部分を使うといいと思います。変換、無変換、ひらがな、については「漢字変換なんて変換キーじゃなくって、スペース・キーでいいじゃん」という意見が昔からありますけれど、どうでしょうね。

まとめ


というわけで連休中の息抜きの筈が思った以上にはまってしまったのでした。本当はひとつ試作してみたいのだけれど、それよりもキーボード メーカーさんに安く大量に作ってもらえるのが一番ですよね。どうでしょうか?


参考文献

[1] TRONキーボード・トレーナー, TRONWARE VOL.8, パーソナルメディア, 1991.
[2] http://www.personal-media.co.jp/utronkb/keylayout.html
[3] TRONキーボード再び, 坂村健, TRONWARE Vol. 100, パーソナルメディア, p.128, 2006.


2013年10月13日日曜日

新キーボード プロジェクト?

今回はキーボードのお話。僕はμではなくてオリジナルのTRONキーボードが好きで、でももう売っていないので仕方なくこれまで4台くらい自作して使っていたりします。



自作tron風キーボード(4代目)

ただこの4代目もスイッチがだいぶ劣化してきてしまって、先日Microsoft社のSculpt Ergonomic Keyboardに置き換えました(基板からになるので自作には結構時間がかかるのです)。そうすると気になる箇所が色々出てきてしまって、またキーボード熱が出てきてしまいました。そんなときにKeyboard.IOというプロジェクトがあるのを知って、改めてちょっとキーボードどうしよう、というお話をFacebookの方に書いていたのですが、長くなってしまったのでこちらにまとめておくことにしました。

エルゴノミック キーボード


ふつうのただの長方形のなかにキーを敷き詰めたキーボードと違って、人の手の形などを考慮したキーボードはエルゴノミック キーボードと呼ばれています。日本ではもう30年くらい前からM式とかTRONキーボードとかがある(あった)のだけれど、残念ながらほとんど普及していなくて、海外のKinesisやMicrosoft社のNatural keyboardなどが入手しやすいタイプのものになります。

キーボードにこだわる人には、キーボードのスイッチ自体の良し悪しを大切にする人と、キーの配置を気にする人と、キーへの文字の割り当てにこだわる人の3種類がある感じです。REALFORCEとか茶軸とかいう単語が聞こえたら前者の人たち、エルゴノミックとか人間工学とかいう単語が聞こえたら真ん中の人たち、DvorakとかNicolaとかいった単語が聞こえたら後者の人たちです。Kinesisは茶軸でエルゴノミックで、場合によってはDvorakだったりするので王様みたいな(価格も)ものですね。

そんな中でエルゴノミック キーボードは大抵変てこな形状をしていますが、それはパームレストに手を置いたまま指が届く範囲になるべくキーを置こうとしているからです。

キーの基本配置

TRONキーボード的な発想でふつうに指の届く範囲に主要なキーを置くと上図みたいになります(英語Qwerty配列で)。M式やKeyboard.IOプロジェクトの写真がだいたいこんな雰囲気ですね。キーが縦一列に並んでいたり、文字以外のキーを親指や人差し指に持ってきている時点でもうだいぶ吹っ飛んでますね。

ただPC用のちゃんとしたキーボードとして利用するには、ここからさらにあと4つほど記号キーをどこかに置かないといけないのですが、そこからが難しいところです。大抵のキーボードは余ったキーは右手の小指の外側に置いあります。まぁ、あんまりふだん使わないキーならそれでもいいか、というところしょう。

ただ急進的なエルゴノミック系のキーボードだと、そこを妥協しないでがんばりだすことになります。デザインを左右対称にするのは基本中の基本です(笑)。Truly-Ergonomicキーボードは左側にキーを増やして左右対称にすることでうまく記号キー配置していますね。Kinesisは横を1段増やして5行目に4つの記号キーを持ってきたりしています。ただ中央から遠くにあるキーにはやっぱり小指はなかなか届きません。

とどけ小指!


問題は他の指よりも短い小指です。ふだん1と0は何指でタイプしていますか?教科書的な正解は小指です。でも小指が届かなくて薬指でタイプしている人が結構といると思います。そこで積極的に1と0は簡単に指が届く薬指でタイプしてもらうことにして、小指をより自然な位置で使えるようにキーを配置しなおしたのが下図です(これで4キー届く範囲で増やせます)。


小指のキーを独立させて記号キーを配置
どっかで見たような?TRONキーボードほぼそのまんまになりましたね(笑) TRONキーボードもこのあたり、1と0は薬指でタイプするのを正解にしていそうです。

TRON配列(http://www.um.u-tokyo.ac.jp/DM_CD/DM_TECH/BTRON/PROJ/BTRON.HTM から)

30年ほど前のデザインなのに、TRONキーボード本当に良く出来ていますよね。ただ前の図よりもTRONキーボードはさらに4キー多い所為で小指周りが実はちょっと窮屈になってしまっています(僕の手だとキーピッチを15mmまで小さくしないと、小指の上段の4キーには小指が届きません。これは、TRONキーボードが日本語キーボードとして設計されたので変換、逆変換、英語、日本語と余分にキーを付けないといけなかった所為かなと思います)。それから一番外側のキーをタイプするときは、かなり小指を広げないといけないのもすこしきついところかもしれません。

以上のような点を踏まえて、今風に作るとしたらこんな感じかなー、ということで描いてみたのが下図です。1と0に1段上に上がってもらって、4キー少ない小指のブロックを詰めてみました。こんな感じでコスト度外視でキートップまで扇型でデザインしたバージョンも見てみたい気がします。


もし今風に作るとしたら (左小指の`と\はひっくり返したほうが良さそうです)

清書


落書きだけだと実際の所よくわからない、ということでざっくりと清書してみました。

キーピッチ 17.5mm版

僕の手に合うキーピッチ17.5mmだとだいたいA4横いっぱいの大きさになります。カーソルを除いてすべてのキーにパームレストに手を置いたまま指が届けばOKですがどうでしょう。手の小さな人用にやっぱり15mm版もあった方がいい予感はしています。(逆にこういう手の形に合わせて開いたキーボードは標準的な19mmのキーピッチは相当手が大きい人じゃないと合わないように思います。)

まとめ


なんだかもう5代目をかなり作りたくなってるんですが、まだ時間的にしばらくはSculpt Ergonomic Keyboardを使っていそうな感じです。もし作ってみたい、もう作る、みたいな人がいましたらご一報くださるとかなり嬉しいです。そのときは僕の分も◯△※# :P

# ESウェブブラウザの話題はまた次回に。:-) 

2013.10.14 18.8mm版と17mm版について追記しました。

2013年9月22日日曜日

ESウェブブラウザ通信 - escudo 0.4シリーズ

ESウェブブラウザは先週CSS メディアクエリ レベル3に対応したescudo 0.3.3をリリースしたところ(*)ですが、今回はGitHubのescudoのレポジトリで開発中のescudo 0.4シリーズのお話です。

(*) メディアクエリの実装のお話はGoogle+のESウェブブラウザのコミュニティに載せてあるのでそちらも参照して下さい。

0.4シリーズはshared_ptrベースのpimplへ


今回マイナーバージョンをひとつ上げることになったのは、escudo内部のC++のObjectクラスの実装を変更したためです。このObjectクラスは、DOMのNodeをはじめWeb IDLのインターフェイスで定義されているすべてのインターフェイスのC++側の実装クラスの基底クラスになっているものです。

Objectとクラス階層

escudo 0.3シリーズの実装では、pimplイディオムを使って、オブジェクトの実体はObjectImpクラスを基底にした別クラスで実装するようになっています。またオブジェクトの寿命は、その中のcountという参照カウンタで管理しています。参照数の管理自体はObjectクラスがスマートポインタのようになっていて、なるべく自動で管理できるようにしていました。

escudo 0.3の実装
上図の説明: JS(SpiderMonkey)やV8がブリッジ経由でアクセスするのが外側のクラスで、その.cppや.hファイルはWebIDLの定義からesidlコンパイラがすべて自動で生成しています。実装側もそのスケルトンとなる.cppや.hはesidlで生成することができるので、『pimplイディオムって、地味に面倒』、"More work for the implementor. "と言われているpimplイディオムを適用するのがescudoではかなり簡単だったりしています。idlコンパイラを作ったり、WebIDLを書いたりするのが面倒なんじゃ…という説もありますが(笑)。(単純に外側が.hで実装側が.cppではない理由は以前にこのブログでまとめてあります。)

ただこの実装では、
  • 参照カウンタそのもののretain_, release_といったメンバ関数はObjectImp内に独自に記述している(マルチスレッドとかを考えると意外と大変)、
  • Object経由のアクセスは必ずしも速くないのでObjectImpの生ポインタを使っている箇所がかなりある(いまのC++で生ポインタはそんなに使うものではない)、
といった具合で安全に作っていくことが難しい面がありました。

そこでescudo 0.4シリーズでは実装側のオブジェクトの寿命をstd::shared_ptrで管理するようにObjectクラスを設計し直しました(shared_ptrを応用する方法の概略はboostのページで説明されています。)。shared_ptr以外の手法もあると思いますが、もし今後shared_ptr以外の手法を使いたくなったとしても、0.3シリーズのように実装側内部で参照カウンタを持っていてはやっぱり大変、ということもありました。

shared_ptrベースのpimpl (escudo 0.4)
この変更で0.4シリーズのソースコードは、
  • 参照数の管理はshared_ptrに任せる、
  • 生ポインタのかわりに関数の引数などは const shared_ptr<T>& を使う、
  • newのかわりに make_shared<T> を使う、
  • etc.、
といった具合に変わっています。0.3から0.4への修正は単純な置換で対応できる部分も少なくなかったのですが、その分量が、
299 files changed, 4073 insertions(+), 3577 deletions(-)
と結構な分量で、C++側のコードの互換性もなくなっていることからマイナー番号をひとつ上げることにしました。

この変更にあたっては、shared_ptrベースになったことで、実装側のクラスのコンストラクタ内部ではshared_from_this関数 (Impクラスのselfメンバ関数)が使えないといった制限が入り、コンストラクタ内部で従来のコードをそのまま実行することができない場面がありました。コンストラクタ本体が単純になること自体は悪いことではないので、これは結果オーライな感じもありますが注意点のひとつです(これにはまると、bad_weak_ptr例外と格闘することになります)。

まとめ


今回は1つの大きなチェンジリストでいきなりescudo(とesidl)のマイナーバージョンが上がっているので、その内容についてまとめました。GitHubのレポジトリの0.4は現状でもひとまず動作していますが、ここからリグレッションや循環参照の問題などを修正しつつ、0.4.0としてリリースする予定です。

2013年7月2日火曜日

ESウェブブラウザ通信 - escudo バージョン 0.3.2 公開

エスリルも昨日で3周年ということで、Escudoウェブブラウザ0.3.2をリリースしました。このバージョンからタブブラウザになっています。

escudo 0.3.2

0.3.2から名前を今までのコードネームescortからescudoに変えています。esのロゴマークを盾の形にデザインしたときは知らなかったのですが、エスクードはポルトガル語で『盾』という意味だそうで、今回はぴったりな感じがしています(相談にのってくれたポルトガルの友人に多謝)。User-Agent文字列もEscudo/0.3.2に変わっています。

いままでにGitHubからescortのレポジトリをcloneしてくださっていた方は、
$ git remote set-url origin git@github.com:esrille/escudo.git
で新しいレポジトリに移行できます。バイナリはFedora 18, 19とUbuntu 12.10, 13.04用をこちらから配布しています:
http://download.esrille.org/
Escudoでは、タブの処理もJavaScriptで行なっているのですが、そのあたりの話題はまた別の機会に。

4年目もよろしくお願いします!

2013年6月1日土曜日

ESウェブブラウザ通信 - CSSの実装のバグを見つけてから直すまでの手順

前回はescort 0.3.1の話とW3Cでのテストスイートの開発の話をまとめました。ESウェブブラウザは次のバージョン0.3.2では、escortがタブ ブラウザになる予定です。現状でも、GitHubのリポジトリから最新のソースを直接ビルトしてescortを実行すると既にタブが使えるようになっています。

タブブラウザ化したescort 0.3.2 (開発中のもの)

今回は久しぶりにCSSモジュールの開発・改善についての話題をまとめたいと思います。

CSSモジュールの実装の改善手順


ESウェブブラウザは、W3CのCSS 2.1テストスイートに関しては約92%のテストにパスするようになっていて、単純に数字の上ではメジャーなブラウザ並みの準拠率になっています。しかし、実際にインターネット上のサイトを表示させてみると、表示が崩れていたり、ブラウザごとクラッシュする場面がまだまだ多いのが現状です。

その理由として、ひとつには、CSS 2.1テストスイートでは個々のCSSのプロパティーについてそれが想定通りに動いているかどうか、という最低限のテストにとどまっているものがほとんどだということが挙げられると思います。

また仕様書通りの実装になっているかどうかという点のテストにウェイトが置かれているので、実際のウェブサイトではまったく使われないようなレイアウトを施したドキュメントのテストが結構ある一方で、実際のウェブサイトでよく使われるレイアウトを重点的にテストすることによってブラウザの実用性を向上させよう、というような種類のテストはあまりない、ということもあるように思います。

たとえば、GitHubの6800297の段階で、人力検索はてなのページを表示しようとすると、下のような画面のところまで進んだ段階でStackingContext::addFloatの中のassertで必ず落ちてしまっていました。

人力検索はてなのページの処理中にクラッシュしたところ (6800297)

assertで停止してくれるバグは、バグの中ではまだ対処しやすい方なのですが(コーディング中に想定していたことと違うことが何かの原因で発生しているので、それを突き止めれば良い)、それでも700行以上のhtmlファイルを相手にソースコードとにらめっこというのは簡単ではありません。

ですので、こういったバグが見つかったら、続いてバグを再現させることができる、できるだけ小さなhtmlドキュメントを作って、それでテストする、ということになります。

補足: ESウェブブラウザに限らず、一般的にソフトウェアのバグを報告するときは、できればここまで(バグを再現する最小手順を見つけるところまで)はバグの発見者側で行なって、バグを報告してあげるようにすると、開発サイドの人たちにはとても喜ばれることになります :-)

で、今回見つかったバグを再現するために用意したhtmlファイルが、26行のcss-004.htmlになります。その中身は、

・ フロート
    ・ 相対位置指定された、overflow: hiddenのインライン ブロック
        ・ インラインブロック
            ・ フロート

という構造になっています。イレギュラーな処理が入るフロートやインライン ブロック、スタッキング コンテキストを作る相対位置指定、特にWebKitの製作者から仕様上の問題点を指摘されていたoverflow: hidden (できればこれもスタッキングコンテキストを作りたかった)、とこれだけ集まれば、未テストであればいかにも問題が起きそうな感じがします。(逆に言うと問題の起きたページから、問題の発生した要素からルートに向かって、通常の処理だけで済む要素を取り除いていくと、上記のような4要素だけが残るわけです。)

assertで落ちた原因は内側のフロートを2回描画しようとしている、というものでしたので、css-003.htmlというもうひとつ小さなドキュメントを用意して、その問題を修正したのがb860795になります。このバグの原因は、ESウェブブラウザ内部では、インラインブロックは、インラインボックスとブロックボックスを2つ組み合わせて表現しているのですが、これが位置指定されていると、スタッキングコンテキストで処理するボックスとして2つとも登録されてしまっていて、子孫のフロートも2重に処理しようとしてしまっていた、というものでした。これは以前、インラインブロックはブロックボックス1つだけで表現するように修正するかもしれない、と書いていたようにもともとESウェブブラウザの設計上に問題があった部分ということになりそうです。

で、この段階でcss-004.htmlはどうなったかというと、assertで落ちることはなくなったのですが、PASSというテキストが表示されないままでした。これはoverflowの処理にバグが残っていたもので(子孫の中で作られたフロートを処理できていなかった)、2fae4b2で修正しました。

ここまで来ると人力検索はてなのページもだいぶ表示できるようになってきて、下の画面のような表示をして、そのままイベントループに入れるようになりました。

人力検索はてなのページを表示したところ (2fae4b2)

まだ崩れているところが残っていますが、修正前の状況からはかなり改善することができました。

まとめ


CSSモジュールの実装では、ちょっとしたバグでも最終的に表示される画面に対する影響はとても大きかったりすることがわかります。今回のようにイレギュラーなレイアウト要素が複合的に絡んだ場合のテストについ ては、W3CのCSS 2.1テストスイートだけでは不十分なので、どう対処していくか、というのはESウェブブラウザに残っている課題のひとつです。

最近のメジャーなサイトはHTML5などのAPIの実装も進んでいないと対応できない場合もあるので、単純にCSSの実装を進めていくだけではテストできなかったりするのも大変なところだったりします。建前としては、CSSとHTML/DOMは別モジュールなので(Selectors APIとか、もはやどっちなのかよくわからないのもありますが)、こつこつどちらも優先度をその都度設定しながら進めていく、という感じで今のところ進めています。

というわけで今回はここまでです。次回は0.3.2のリリースに合わせて報告するような予定でいます。

2013年4月24日水曜日

ESウェブブラウザ通信 - escort バージョン 0.3.1 公開

前回から2ヶ月空いてしまいましたが、今日はEscortとEsidlのバージョン0.3.1をリリースしたので0.3.1の話題と、今年1月の0.3.0リリースのときはブログの更新をスキップしてしまったので0.3.0の話題も合わせてまとめておきます。

ESウェブブラウザ 0.3シリーズ


0.3シリーズは2014年に予定されているHTML5の勧告に向けて、それまでにHTML5の仕様を実装していく、ということを目標にしています。最終的に0.3.10になるのか0.3.20になるのか今のところ未定ですが、流れとしてはそういう流れです。

0.3.0では、しばらく更新していなかったWeb IDLの定義ファイルを最新のHTML5の仕様に更新しておく、というのがゴールでした。 ですのでユーザー視点だとほとんど何も変わっていませんでした。

escort 0.3.1

0.3.1では、HTMLの実装を仕様通りに実装していくための基礎的な部分の見直しと修正が主な変更になっています。これまでESウェブブラウザは、CSSモジュールのテストに最低限必要な機能だけを簡易的に実装している、という面があったので、そういった部分を仕様通りの実装にしていくための準備といった工程でした。

それから0.3.1では、この2月にW3Cの勧告になったSelectors API Level 1や一昨年勧告になったCSS3 Colorの対応が入っています。0.3シリーズはHTML5の仕様の実装が主目的ではあるのですが、勧告になっていたり、もうなりそうなW3Cの仕様は今後も並行して順次実装していく予定です。

さらに0.3.1は、Mac OS Xでビルドできるようになっています。これはConstellationさんがパッチを送ってくれたものです。ふだんはOS Xを使っているけど、ESウェブブラウザにも興味を持ってくださっている、という方はぜひ試してみてください。OS Xでのビルド手順についてはこちらのWikiページで説明してあります。

OS X版について補足: 以前ならMacでもWindowsでもVirtualBox等でとりあえずFedoraやUbuntuもインストールしておいて、というのは割と簡単だったと思うのですが、SSDが主流になってきてちょっと容量的にきつい、みたいな感じがあります。そういう方はOS Xでも、というニュアンスだったり、最悪動かなくてもClangでもビルドをチェックしておきたい、といった意味合いが今のところは強いので、お勧めはFedoraやUbuntuだったりというのはこれまで通りです。


HTMLのテストスイート — Save the Web, Write Some Tests!


CSSモジュールの開発中からこのブログを読んでくださっている方には、公式なテストスイートの重要性は伝わっているんじゃないかな、と思ったりするのですが、HTML5に代表されるウェブ プラットフォームのテストスイートをこれからはGitHub上で開発していくよ!というアナウンスがこの2月にTobie LangelさんからW3Cを通じてありました:
we’re going to move all tests to a central repository on GitHub.  (snip)
If you or your organization want to help us in any way, please contact me either directly or through the mailing list.
  (snip)
This journey 1% finished.

ということで、W3CのHTMLのテストスイートの開発がGitHubこちらのページ、
https://github.com/w3c/web-platform-tests
で進んでいます。

エスリルからもまだたった2つだけですが、テストを提出してマージしてもらいました。そのときの手順を参考までに紹介しておきます(W3Cの会員組織に所属している方は手続きが違う筈なので会社や組織の人に確認してください)。

1) テストを作る
  上記のGitHubページでは、"No test is too small or too simple, especially if it corresponds to something for which you've noted an interoperability bug in a browser."と非常に緩く募集しているように読めますが、なるべくこのこのWikiページで説明されている3つの形式のどれかで作っておくと、W3Cの 方にあまりお手間を取らさずに済むのじゃないかなぁ、と思います。
2) W3Cのアカウントを作る(まだなければ)
  https://www.w3.org/accounts/request
3) 提出するテストについて使用許諾をする
  上記のGitHubページの "fill out this form" という箇所からジャンプできます。このとき個人で提出するか組織で提出するか選択できるようになっていました。
4) テストが完成したらGitHubからPull Requestを出す
  ここまでできれば、コメントをいただけたらそれに対応したりと、通常のGitHubの利用方法と同じです。

注意: これからもいろんな情報が公式に出てくると思うので、このブログだけでなくW3Cからの最新の情報もフォローしておいてください。

ちなみにエスリルから提出したのは、
https://github.com/w3c/web-platform-tests/tree/master/html/semantics/grouping-content/the-ol-element
の中の2つです。ol.start-reflection-2.htmlが今のところFirefoxでfailになってしまうのでした。こういう場合、これまでならブラウザ ベンダーにバグを報告したり、パッチを送ったり、ということになったと思います。でもこれからは同時に、何かinteroperability (相互運用性)の問題で気づいたことがあれば、みんなで共有できるテストを作って "Save the Web!" (今後もすべてのウェブ ブラウザで問題が起きないように目が届くようにしよう!)で頑張っていこう、という流れになったらいいな、と思ったりしています。

個人的には、web-platform-testsは、日々ウェブに関わっていれば、ウェブ ブラウザのソースコードに直接タッチするような時間のない人でも参加できるプロジェクトじゃないかな、と思います。


まとめ


この数カ月はESウェブブラウザの外でもいろんな出来事がありました。2月には、
"we now have one of the three viable browser engines, instead of one of the four, and engine diversity is already critically endangered"

と少し寂しいOperaのニュースが流れましたが、4月には、
"we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem"

と明るいBlinkのニュースが流れてきたりしました。ESウェブ ブラウザも4番目か5番目に数えてもらえるようにがんばって行きますので、ご支援・ご声援 :-) お願いします。

ちなみにESウェブブラウザ 0.3.1のW3Cのテストスイート達成率は下記の通りです:
[CSS 2.1] 91.7%
[CSS 3 Color] 91.5%

というわけで、今回はここまでです。細かい進捗はGoogle+で報告することが多くなっているので、ぜひそちらもご覧ください。

2013年2月16日土曜日

XPS12にUbuntuをいれました。

今日はESウェブブラウザ通信ではなくて、最近世界中で流行の兆し(ホントかw)のあるデルのXPS 12Ubuntuを入れました、というお話。

 # ちなみにescortは先月0.3.0をリリースしています。

なんでXPSに人気があるかというと、株式非公開になるからではなくて、
とかの所為だと思います。販売直後は納期が通常+6週間とかすごいことになっていた記憶がありますが、最近は落ち着いて来たみたいですね。

こんな感じで届きました(発注から2週間ほど)
で、以下手順をザーッと。

注意: 大事なことをひとつ。DellのプロジェクトSputnikで扱っているのはXPS 12ではなくてXPS 13です。XPS 12の方はよく似たハードだし、Atmelのタッチスクリーン ドライバもあるし、動くかも的なノリだと思うので、実際にやってみようという方は自己責任でお願いします f^_^;;

1. Windowsのバックアップメディアを作る

(Windowsとかいらない、というひとはここは省略。)

別途オーダーできるリカバリディスクを購入しても『デルのドライバおよびアプリケーションは含まれません』だそうなので作っておいたほうが良さそうです。手順は、

[Start] - [My Dell Support Center] - [バックアップ] - [システム リカバリ メディア]

の順番です。

2. Ubuntu 12.10 64bit をダウンロードしてDVDに焼いておく


このページから64ビット版をダウンロードしてきます。Windows 8が入っている最近のPCにインストールするときは、

Please use a 64-bit flavour of Ubuntu desktop.

という注意が書かれている通りです。DVDのかわりにUSBメモリも使えるはずです。

注意: タッチスクリーンに対応しているのは12.10以降のようなので、12.04は選択しない方がよさそうです。

3. Windowsのパーティションを縮小する


出荷状態だとSSDは全部Windows用に使われてしまっているので、Windowsのパーティションを小さくして、Ubuntuをインストールするための空き領域を作ります。手順は、

[コントロール パネル] - [コンピューターの管理] - [記憶域/ディスクの管理]

と選択して、ボリューム名『OS(C:)』のパーティションを選択して、右クリックで[ボリュームの縮小]を選びます。『縮小する領域のサイズ(MB)』にUbuntuに割り当てる領域の大きさを入れます。ESウェブブラウザの開発用なら30GB(30,720)もあれば大丈夫だと思います。

次の手順からUbuntuのサイトで説明されている手順のXPS 12版になります。Ubuntuの公式な説明はこちらにあります。

4. BIOSの設定を変更する


注意: 初期にXPS 12を入手された方は最新のBIOSになっているかどうか確認しておいた方がいいかもしれません。

キーボードのF2キーを押しながらXPS 12の電源を入れて、BIOSのセットアップ画面を表示します。

[Boot] - [Windows 8 Fast Boot]

を選択して、<disabled>にします。

5. UbuntuのLiveDVDを使って起動する


LiveDVDの入ったDVDドライブをUSBポートにつなげてから、キーボードのF12キーを押しながらXPS 12の電源を入れて、ブート オプション画面を表示します。

接続したDVDドライブなどを選択して、起動したら"Try Ubuntu"を選択します(ここでInstallの方を選んでしまうと、うまくインストールされないそうです)。

6. Ubuntuをインストールする


Ubuntuが起動したら"Install Ubuntu 12.10"を選択して、Ubuntuのインストールを開始します。

Ubuntu用の空き領域は確保してある筈なので、XPS 12を電源に接続して、Wi-Fiを有効にしてインターネットに接続した状態にして、インストールを続けます。

インストーラーがWindows 8の存在を見つけないようで怖いのですが、インストールする場所の選択で『それ以外』を選択します。続いてSSDの中で3.の手順で作った空き領域になっている部分を選択して[+]ボタンを押してパーティションを作ります。

メインメモリが8GBあって、特にこだわりがなければ、パーティションは1つだけ、フォーマットにext4を選択してマウントに/を選択して作っておけばいいと思います(swapなど他のパーティションはとりあえずなくてもいいかなと。あとで必要ならdphys-swapfileを使うとか)。ブートローダーは/dev/sdaにしておきました。

後は地域とかキーボードの種類とかを選択するくらいでどんどんインストールが進んで行くと思います。

インストールが終わったらディスクを取り出して再起動するとUbuntuが立ち上がるはずです(

この手順だとなんかデフォルトがUbuntuになるんですね。Windowsを起動するときはF12を押しながら電源を入れて、Windows Boot Managerを選択すれば大丈夫でした。

7. Sputnik Kernel PPAを導入する


冒頭に書いたDellのUbuntuノートPC開発プロジェクトSputnikの成果物を取り込めるようにします(公式ページはこちら)。

注:  Ubuntu Raring Ringtail (13.04)からはSputnikの成果物がデフォルトでUbuntuに取り込まれているそうなので、この手順がいるのは12.10まで、ということのようです。

Ubuntuでターミナルを開いて、

$ sudo add-apt-repository ppa:canonical-hwe-team/sputnik-kernel
$ sudo apt-get update
$ sudo apt-get upgrade

の順に実行して再起動すれば大丈夫です。

これでWindows 8とUbuntu 12.10がXPS 12で使えるようになっている筈です。

Ubuntu 12.10/XPS 12でescortを実行しているところ
escortもタッチパネルを使って画面をスクロールしたり、リンクをタップしたりできます。

Ubuntu 12.10でXPS 12でまだ不完全なところ


Wi-Fiもタッチパネルも、もうちゃんと動いている感じなのですが、タッチパッドのマルチタッチがXPS 12は未対応のようです。

参考: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1103594

これはマウスがないと結構厳しいものがあるかもですね。最悪、WindowsのVirtualboxからインストールしたUbuntuを起動させるというものありかも(やってみてないですが)。

2/28追記: 上述のbugsページにも報告されている通り、早くもXPS 12でもタッチパッドのマルチタッチがUbuntuで使えるようになっていました!

$ xinput list
⎡ Virtual core pointer                     id=2 [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer               id=4 [slave  pointer  (2)]
⎜   ↳ Atmel Atmel maXTouch Digitizer           id=9 [slave  pointer  (2)]
⎜   ↳ CyPS/2 Cypress Trackpad                  id=12 [slave  pointer  (2)]

System Settingsを開いてMouse and Touchpadを選択すると、以前はなかったTouchpadタブが追加されているので、そこでTwo-finger scrollingなどを有効にできます。

まとめ


今回はほとんど雑談でした。でもこんな感じでUbuntu Smartphoneも出てきたらちょっとワクワクしますね。

次回はちゃんとESウェブブラウザ通信を書く予定です!