アカウント名:
パスワード:
タブレットマシンの、一種のシンボルとして定着した感もありますが、画像上のキーボードって、実際どうなんでしょうね?最初から使いこなせる人も居るだろうし、修練すれば使えるようになるのかもしれませんが。
例えて言えば、ダン・タイ・ソンの紙鍵盤みたいな。彼は、紙鍵盤でトレーニングし、ピアノのスキルを向上させたけど、多分私が同じ事をしても、ピアノが弾けるようにはならないでしょう。物理的なリアクションが期待できない、ディスプレイ上のキーボードからは、いまいち、凡人には使い難そうなオーラを感じます。
>モバイル機器などで手書き入力エリアを取ることが難しい場合は仕方がない
Palmのグラフィティはスゴク良かったと思うんだ。日本語についてもPalm用POBoxを組み合わせればすごく快適だった。
>入力エリアを取る
最近のiPhoneとかのUIを見てて、「エリアをとる」という発想はもう古いのでは?と思うようになった。
古典的な仕組みのGUIで「任意の部分を」クリック&Dragした場合、何が起きるかはその場所に存在するGUI部品次第だ。ボタンならクリックされてしまう(まあDragした時点でキャンセルだが)し、Text入力欄なら選択されるだろうし、Linkなら画面遷移しちまうだろう。
しかしiPhoneだと、「すばやくなでた」のであれば、そこがどのGUI部品であるかは「無視」してコンテナのスクロールとみなす、という仕組みになっている。
(技術的には単に「そういう風にイベント解釈層が設計されている)というだけのことだが、ここでは発想の転換が重要なポイントだ)
となると、手書き文字入力にも同じことが出来るのではないか?と期待しても良いんじゃないかと思う。そこに何があるかはイベント解釈層が適切に無視してくれて文字入力とみなす、というような。
最近のiPhoneとかのUIを見てて、「エリアをとる」という発想はもう古いのでは?と思うようになった。古典的な仕組みのGUIで「任意の部分を」クリック&Dragした場合、何が起きるかはその場所に存在するGUI部品次第だ。ボタンならクリックされてしまう(まあDragした時点でキャンセルだが)し、Text入力欄なら選択されるだろうし、Linkなら画面遷移しちまうだろう。しかしiPhoneだと、「すばやくなでた」のであれば、そこがどのGUI部品であるかは「無視」してコンテナのスクロールとみなす、という仕組みになっている。
これ、逆に覚えるべき約束事が増えたっていう意味でもあるわけで。iPhoneなんか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
タブレット上に表示されたキーボード (スコア:3, 興味深い)
タブレットマシンの、一種のシンボルとして
定着した感もありますが、画像上のキーボードって、
実際どうなんでしょうね?
最初から使いこなせる人も居るだろうし、
修練すれば使えるようになるのかもしれませんが。
例えて言えば、ダン・タイ・ソンの紙鍵盤みたいな。
彼は、紙鍵盤でトレーニングし、ピアノのスキルを向上させたけど、
多分私が同じ事をしても、ピアノが弾けるようにはならないでしょう。
物理的なリアクションが期待できない、ディスプレイ上のキーボードからは、
いまいち、凡人には使い難そうなオーラを感じます。
Re:タブレット上に表示されたキーボード (スコア:5, 参考になる)
ソフトウェアキーボードよりも手書き文字入力の方が遙かに便利かつ高速に入力できます
(有る程度の解像度と画面サイズがあること前提ですが)
ソフトウェアキーボードだと物理的な境界が無いため他のキーを押さないよう割と集中して入力する必要が有りますし
なにより各社工夫はしているものの入力時のフィードバックが悪いのも問題です
一方手書き入力だと技術の進歩により独自のなんちゃって草書体でも認識してくれ、一度に認識できる文字は少ない物の
紙に書くのに近いスピードで入力することができます(変換作業が無いのが大きい)
個人的な意見としてはモバイル機器などで手書き入力エリアを取ることが難しい場合は仕方がないですが
日本語入力をする時は補助的な目的以外でソフトウェアキーボードを使う気にはなれません
Re:タブレット上に表示されたキーボード (スコア:1, 興味深い)
>モバイル機器などで手書き入力エリアを取ることが難しい場合は仕方がない
Palmのグラフィティはスゴク良かったと思うんだ。
日本語についてもPalm用POBoxを組み合わせればすごく快適だった。
>入力エリアを取る
最近のiPhoneとかのUIを見てて、「エリアをとる」という発想はもう古いのでは?と思うようになった。
古典的な仕組みのGUIで「任意の部分を」クリック&Dragした場合、
何が起きるかはその場所に存在するGUI部品次第だ。
ボタンならクリックされてしまう(まあDragした時点でキャンセルだが)し、
Text入力欄なら選択されるだろうし、Linkなら画面遷移しちまうだろう。
しかしiPhoneだと、「すばやくなでた」のであれば、
そこがどのGUI部品であるかは「無視」してコンテナのスクロールとみなす、
という仕組みになっている。
(技術的には単に「そういう風にイベント解釈層が設計されている)というだけのことだが、
ここでは発想の転換が重要なポイントだ)
となると、手書き文字入力にも同じことが出来るのではないか?と期待しても良いんじゃないかと思う。
そこに何があるかはイベント解釈層が適切に無視してくれて文字入力とみなす、というような。
Re: (スコア:0)
これ、逆に覚えるべき約束事が増えたっていう意味でもあるわけで。
iPhoneなんか
Re:タブレット上に表示されたキーボード(オフトピかつフレームの元?) (スコア:0)
>>モバイル機器などで手書き入力エリアを取ることが難しい場合は仕方がない
>Palmのグラフィティはスゴク良かったと思うんだ。
>日本語についてもPalm用POBoxを組み合わせればすごく快適だった。
個人的にPalmは素晴らしいと思いますし複数使い今でもClieを使用している私ですが
私を初め多くの人に評価されたグラフティは今では害だったのでは?と感じます
せっかくペンデバイスで紙との境界を低くしたのにグラフティという日常では使用しない
新たなる境界を作ってしまったためマニアのデバイスで終わってしまいました
当時はCPUやメモリも非力だったため認識率を高