iPhone のフリック入力は素晴らしい。ただ一つ、母音を連続入力する時以外は! そう思ってた。
例えば、「ああ(感嘆詞)」、「かかわらず」、「たたる」、「ななめ」、「ははおや」、「ままごと」、「やや(副詞)」、「らら(未来少年コナンのヒロイン)」。こういふのを入力する時、「あ」を入力して、少し時間を置いてからもう一度「あ」を押していた。急いでると「ああ」と入力しやうとして「い」を入力して困った。
甘かった。
フリック入力では「い」を入力するのに、「あ」を押して左(「い」側)に指をずらす。
「あ」の連続入力は同じ要領で「あ」側に指をずらせばいい。もちろん、「あ」から「あ」にずらすことは出来ないので、一旦別の場所に指を持っていって、「あ」に指をずらす。つまり、「あ」を押して左に指をずらした後すぐに「あ」の位置に指を戻す (左でなく上下右でもいい)。すると、「あ」に確定される。
こりゃ便利。ちょっと感動した。
予告通り、昨日一昨日「Touch Diamondで考えるスマートフォンの未来」ブロガーミーティングに参加した。
今回のブロガー・ミーティングは全 2 回構成で、昨日はその第 1 回目に当たる (第 2 回の開催は 12 月)。
第 1 回のアジェンダはこんな感じ。
全体的に、「Touch Diamond」に触れてもらうことに主眼が置かれていた。ブロガー・ミーティングの題名になっている「スマートフォンの未来」を考えるのは、第 2 回でメインに行なうとのこと。
Touch Diamond のタッチパネルは感圧式だった。感圧式は、タッチパネルを押した時の圧力を感知して、どこがタッチされたか判定する。一方、iPhone や iPod Touch が採用しているタッチパネルは静電式 (静電容量式)。静電式は、人が持ってる徴弱電流を感知して、どこがタッチされたか判定する。
(Touch Diamon) 感圧式の長所は次の通り。
逆に、iPhone の静電式の長所 (言い換えれば感圧式の短所) は次の通り。
かうして挙げてみると、感圧式の方が優れているやうに見える。でも、ぼくは、「使いやすいのは圧倒的に静電式」と言いたい。これは、スペック云々といふ話じゃなくて、片方の方式から他の方式へ切り替えた時の、ぼくの経験的な話。特に入力方式を切り替えた時のストレスの違い。
ぼくは感圧式のデバイスとしてソニーのデジカメ DSC-T300 を使っている。この操作感に慣れた所で、iPhone を買った。この時、iPhone を使うのに時にストレスは感じなかった。
逆に、iPhone に慣れた今、DSC-T300 や今回の Touch Diamond に触るとストレスを感じる。タッチパネルに「力を入れない」と操作できない面倒臭さ。これが一番の原因。まず、押す側として「力」が必要。そして、支える側として同じ「力」が必要。だから使いづらい。画面の端を押す時なんか、ちゃんと支えてないといけない。感圧式デバイスだけを触ってた時は気にならなかったけど、iPhone を触った後だとストレスに感じる。だって、iPhone なら軽く触れるだけで良かったから。支えはいらない。ちょっと無理なかっこうでも入力できる。一回り大きな iPhone でも、入力する気になる。
iPhone では、確かに同じボタンを複数回押すのは難しい。携帯電話のように「お」を打つのに「あ」キーを 5 回も押すのは、大変。でも、代わりにフリック入力がある。フリック入力なら「お」はワン・アクションで入力できる (「あ」キーを下にはじく)。とても軽快かつ合理的。
もう一つ、Twitter のクライアント・アプリ Twittelator で入力中に誤って「送信」ボタンを押してしまい、入力途中の文章が Twitter に送られることが良くあった。この問題は、「送信」ボタン押下後、「Send Tweet」という確認ボタンが現れるやうになって解決した。
言いたいことは、静電式の欠点の多くは、UI の工夫でどうとでもなるといふこと。そして一度静電式に慣れると感圧式のストレスは耐えがたいといふこと。
感圧式のタッチパネルを採用していると、従来の UI に満足して新しい UI の模索が進まない気がする。ユーザーも、変化がないから新機種への移行がスムーズに進むでせう。一方、新しい UI を採用すると、初めて使うユーザーはとまどうでせう。でも、ユーザビリティ向上の可能性が生まれる。iPhone にはそれがあると思うし、これからのタッチパネル採用デバイスは静電式を取り入れてくれたらいいな。そう、Touch Diamond を触って思った。
本エントリーはネタです。本エントリーを参考にして、Mighty Mouse が壊れても、当方は一切責任を持ちません。自己責任で作業を行なって下さい。
Mighty Mouse の下スクロールが不良な場合、いくつかやれることがあって、それでもダメならサポート・センターに電話することになる。サポート期間内なら、無料交換が可能。詳細は過去記事に書いた。
昨日、このエントリーにコメントがついた (Thanks: Anonymous さん)。情報によると、保証期間外の場合、新品を買い直す方がお得。というか、それしか方法がないらしい。
「１年間の保証修理期間が過ぎた場合は交換修理となり新品購入と同額の修理費用（8800円？）がかかるため、新品を購入した方が保証もついてお客様にとってメリットがあります」 の一点張りで、交渉にもまったく応じていただけませんでした。
で、
ついにアップルに対する怒りが収まらず、電話を叩ききり、近くにあったソファに、マイティマウスを渾身の力を込めてぶん投げました。
そしたら
直りました。
最終手段。
「ソファー (のやうに柔らかくある程度弾力があって Mouse を壊さないもの） に向かって、Mighty Mouse を渾身の力を込めてぶん投げる」
この時、スクロール・ボールがソファーに当たるやうに投げるとよいのか、それとも逆がいいのかは分からない。
やる時は自己責任で。最後のもう一度。本エントリーはネタです。
Google Reader を見てたら、漢字だらけのエントリーが現れた! スパム・エントリーかと驚いた。最近、はやりの広告フィードというやつかしらん...
違った。
正体はコレだった。
中国向けの Google Developer Blog。こんなのも Google は出してるんだねぇ。
何て書いてあるのか分からないけど、中国好きな方はフィード・リーダーに登録してみてはいかがでしょ。
AMN が主催するブロガー・ミーティング「Touch Diamondで考えるスマートフォンの未来」が明日開催される。
主旨はこんな感じ。
...そこで今回は、マイクロソフトさんの新しいWindows Mobileと、それを搭載した HTCさんによる注目の携帯端末「Touch Diamond」についてそれぞれご紹介頂き、 みなさんと一緒に今後のスマートフォンに必要な機能とは何か？ これからどのような進化をしていくと良いのか？ など、スマートフォンの未来について考えてみたいと思います。
今回のブロガー・ミーティングは本気で、一か月間のモニター商品貸出と一か月後におさらいブロガー・ミーティングを開く。iPhone ユーザーとしては、他社の打ち出す「本気」? のスマート・フォンに興味あり。かなり楽しみ。
抽選がからむブロガー・ミーティングには、ことごとく落選しまくっていたので、今回も期待していなかったのだけど、金曜日の夜に当選のお知らせが届いた。
イベントの前日に、こんなエントリーを書くのは、イベント参加時に一人だと淋しいから。きっと明日は、帽子を被っていくので、気付いたら声をかけて下さい m(_ _)m。
2008-09-29 (Mon) に「Wirefree Network Gadget ブロガー・ミーティング」に参加した。一か月以上も前のイベントだけど、参加レポートを書いてみる。
Wirefree Network Gadget ブロガー・ミーティングは毛色が変わっていた。紹介されたのは、プロトタイプなサービスだった。どれ位いプロトタイプかというと、事業化の目途は立っていない。ビジネス・モデルは模索中。デモ機の一つは、電源を挿し続けると異常発熱するという。そんなレベル。
リリース直後・直前のガジェットやサービスを紹介するブロガー・ミーティングとは一線を画していた。
社内の有志を集めて、隙間時間でサービスを作り上げた。次のステップに進む前に、アーリー・アダプター (新商品にとびつく人達) の声を聞いてみたい。さういふ経緯でブロガー・ミーティングが開かれた、とぼくは理解している。
ネット系ガジェット好きブロガーは、正に恰好の「声」になりそう。目の付け所が鋭いと思った。
Wirefree Network Gadget は、開発プロジェクトで作われている造語。「開発サービス」に繋がるガジェットの総称。「開発サービス」はネットワーク上でガジェット同士を繋ぐ「パイプ」の役割を果たす。
このサービスの入力はメール (SMTP) とブログ投稿機能 (AtomPub)。出力は IM (XMPP) とフィード (Atom)。入力から出力に出す間、データを保管 (ストレージ) するサービスを外部に持つ。
例えば、「写真データ」を「メール」でこのサービスに送り付けると、サービスは「Flickr」などの外部ストレージ・サービスにデータを自動投稿する。その後、適当にタイミングを見はからって、「IM」から (Flickr に保存してあった) 写真を相手側に送り付ける。
サービスの本質は、「パイプ」的な仕組みしか用意しないところ。パイプに入力する機器も、パイプが「保存」で利用する外部サービスも、パイプが出力する機器も (プロトコルに則れば) 何でも OK なのがミソ。サービスに送り付けるデータは「写真」ですらなくてもいい。「音声」でもいいし、「動画」でもいいし、「テキスト」だけでもいい。入力機器も、デジカメ、ボイス・レコーダー、ハンディ・カム、テキスト・メッセージを問わない。出力先も、フォト・ストレージでも、Chumby でも、テレビでも、スピーカーでもいい。要は、入力・出力機器はメーカーさん、頑張ってうちに対応してよ、ってこと。
ユーザーは、「パイプ」と「入力・出力機器と外部保存サービス」の関連付けを設定するだけ。
ちなみに、今回のブロガー・ミーティングでは、カメラで撮った写真を (無線 LAN を使って) すぐに「テレビ」と「Chumby」の 2 ガジェットに送り出すデモを見せてもらった。そう、パイプの出力先は複数も OK なの。ただし、画像以外のデモは出来ないとのこと。「音声」や「ビデオ」については構想中? ここら辺がプロトタイプな発表会と呼ばれるところかな。
課題は、課金の形式をどうするか。このサービスの提供方式をどうするのか。ビジネス・モデルはどうするのか。色々挙がってた。
なので、このサービスが形になるのはもう少し先だし、もしかすると立ち消えになるかもしれない。
思うに、このサービスはガジェット側の対応が不可欠。今なら、各メーカーが企画段階から「対応」することが考えないといけない。これはハードルが高い。でも、もう少し先なら、iPhone や Android や Chumby のやうに「ユーザーが機能を追加できるガジェット」が増えている。時期が合えば、多くの人に受け入れられるんじゃないかしらん。ぼくの期待は大きい。
の続き。
ディレクトリーにだけ実行属性を与える方法として次の方法を紹介した。
$ find foo/ -type d | xargs chmod o+x
このやり方だと、ディレクトリーのパスに「空白」や「改行」を含む場合に失敗する。「空白」を引数の区切り文字として、「改行」をコマンドの終わりとして認識するのが原因。パスに(特に)「空白」を含めること自体、Unix 使いとして終わってる気がするけれど、Samba なんかで Windows ユーザーと共有しているとかういふことになりやすい。
で、xargs の man を読むとこうあった。
Because Unix filenames can contain blanks and newlines, this default behaviour is often problematic; filenames containing blanks and/or newlines are incorrectly processed by xargs. In these situations it is better to use the `-0' option, which prevents such prob- lems. When using this option you will need to ensure that the program which produces the input for xargs also uses a null character as a separator. If that program is GNU find for example, the `-print0' option does this for you.
-0 オプションを使う。更に、find コマンドでは -print0 オプションを併用しないといけない。
つまり、こう書くと問題は解決する。
$ find foo/ -type d -print0 | xargs -0 chmod o+x
@aka のもう一つのブログ life@aka。そっちで「彼女」をブログ内検索してみた。
検索結果のトップは、全部マンガのエントリーだった。
軽く、ちょっぴり、絶望した。
Emacs で M-x compile すると、コンパイル経過が *compilation* バッファーに表示され、エラーの表示された行の上で RET を打つと、そのエラーの場所へジャンプが出来る。
同じことを、テキスト・ファイルに出力したコンパイル・ログからやる方法を紹介しませう。
やり方は簡単。
まず、コンパイル・ログを出力したテキスト・ファイルを開く。そして、ファイルの先頭に次の行を追加する。
-*- mode: compilation; default-directory: "~/program/foo" -*-
default-directory の引数は、コンパイルを行なったディレクトリーのパスを入力すること。
あとは、そのファイルをもう一度開き直すだけ。これで、そのファイルは Emacs の *compilation* バッファーと同じやうに RET エラー行ジャンプできるようになる。
他人のコンパイル・ログをチェックする時とか、Warning 潰しする時に重宝。
2008-11-04 から、iPhone のために BB モバイルの WiFi ポイントが開放される。
ポイントはこちら。
ログイン画面で入力する「ユーザー ID」と「パスワード」は i.softbank.jp のアカウント名とパスワードで良いっぽい。で、BB モバイルポイントの WEP キーって何? 知らないんだけど。。。あれ??
BB モバイル・ポイントの「WEP キー」は、iPhone から調べることができる [Thanks: Going My Way さん]
以上。
iPhone で Google Maps を開いて「bb モバイル」で検索する。これだけ。「bb モバイル」が提供されてるポイントにピンが落ちる。
とりあえず、一回試してみないことにはコメントしやうがないね。
