2010年03月の日記です
おゆうぎかい 2010-03-02 22:19:24 FAMILY
２月２７日（先週土曜日）は、子供の保育園の「ひなまつりおゆうぎかい」でした。
今年は、長女（２歳１０ヶ月）も上手に踊れました。
去年は、ステージに立ったらキョトンとして踊れなかったのだけどね。
でも、今年も踊っていたのは、１５人くらいの１歳児クラスで、長女を含めて３人だけ。
---
長男（５歳８ヶ月）は、真剣な…ある意味、余裕のない顔で踊っていました。
でも、真剣なだけあって、他の子よりもリズムに合っている。
…まぁ、保育園のおゆうぎかいなので、楽しそうに踊っているのと正確に踊っているのの、どちらがよいのかは良くわかりません。
長男はもう一演目。舞踊劇がありました。
「僕、王子様の役だよ」と事前に言われていたのですが、王子様がどんな役どころかわからないので期待せずに聞いていたのですが…
王子様、と言うだけあって、準主役でした。
もっとも、主役（女の子）も３人、準主役の王子様（男の子）も３人いるのだけどね。
先に書いたように、踊る時はかなり正しいリズムで踊れるので、「リズム役」で選ばれたみたい。
あとの二人は、長い台詞回しでも覚えられる子と、体が大きくて見栄えのする子。
気になる演目は「魔法使い見習い中！」という劇。
…えーと、僕も一応魔法使い見習いを名乗っていますが、何の因果でしょうか。
---
今年のおゆうぎかいには、子供たちのおばあちゃん（僕の母）が見に来てくれました。
子供たちは結構喜んでくれたみたい。
次女が泣いているときにあやしてくれたりしていたし、いろいろとありがとうございます。＞母
今年は、長女（２歳１０ヶ月）も上手に踊れました。
去年は、ステージに立ったらキョトンとして踊れなかったのだけどね。
でも、今年も踊っていたのは、１５人くらいの１歳児クラスで、長女を含めて３人だけ。
---
長男（５歳８ヶ月）は、真剣な…ある意味、余裕のない顔で踊っていました。
でも、真剣なだけあって、他の子よりもリズムに合っている。
…まぁ、保育園のおゆうぎかいなので、楽しそうに踊っているのと正確に踊っているのの、どちらがよいのかは良くわかりません。
長男はもう一演目。舞踊劇がありました。
「僕、王子様の役だよ」と事前に言われていたのですが、王子様がどんな役どころかわからないので期待せずに聞いていたのですが…
王子様、と言うだけあって、準主役でした。
もっとも、主役（女の子）も３人、準主役の王子様（男の子）も３人いるのだけどね。
先に書いたように、踊る時はかなり正しいリズムで踊れるので、「リズム役」で選ばれたみたい。
あとの二人は、長い台詞回しでも覚えられる子と、体が大きくて見栄えのする子。
気になる演目は「魔法使い見習い中！」という劇。
…えーと、僕も一応魔法使い見習いを名乗っていますが、何の因果でしょうか。
---
今年のおゆうぎかいには、子供たちのおばあちゃん（僕の母）が見に来てくれました。
子供たちは結構喜んでくれたみたい。
次女が泣いているときにあやしてくれたりしていたし、いろいろとありがとうございます。＞母
SH-03B…将来のために 2010-03-08 16:07:40 COMP
将来のために、って、発売間もない SH-03B を「次はこうして欲しい」という要望ですよ。
自分の日記に書いて SHARP の人の目に留まるとは思えないけど、不満がたまっているのでどこかに書き出さないと気がすまないだけです。
まず、しばらく使ってみて、SH-03B は非常に良い端末だ、と、先に書いておきます。
テンキーでメールなんて書けるか！ とお困りで、でも i-mode を始めとする、いわゆる「普通の携帯」でないと受けられないサービスが多くて困る、という人には、他に選択肢はないと言って良いでしょう。
待ち受け画面から最初に表示されるメニューは、自由に組み替え可能です。
なので、良く使う機能をすぐに呼び出せます。
でも、組み替えなくても、本当によく使われる機能は最初からすぐ呼び出せるの。
日付をタッチすればスケジューラーが、時刻をタッチすればアラーム設定が呼び出されます。
だから、そういう点に不満はない。
不満は、タッチパネルを使用したユーザーインターフェイスに集中しているのです。
---
まず、タッチパネルは「本体内蔵メニュー」及び「Java 以外の内蔵アプリ」でしか効きません。
i-mode のトップメニューは、Flash 内蔵端末ではデフォルトで Flash で表示されますが、操作できません。
タッチパネル上にバーチャルキーボードを表示して、そこで操作するの。
この操作が最悪。
i-mode のトップメニューに関しては、設定すれば通常の HTML 表示にもできますが、そういう設定に対応していないサイトや、最初から Flash が前提のゲームなどはあきらめたほうが良い。
Java も、タッチパネルに対応した API は DoCoMo 標準で定められているようですが、プリインストールのアプリですらほとんど使っていませんので諦めるしかないです。
とはいえ、ここら辺は Flash や Java という「個々のアプリ」の問題でもあるので、仕方なく許容範囲。
技術がわかっていない人なら十分文句が出るような部分だけど、僕はプログラマーだから、ここら辺が仕方ないことは理解できる。
というわけで、問題はどんどん切り分けられて、いよいよ「インターフェイス」の詳細に入ります。
-=-=-=-=-=-=-=-=
まず、メニュー上位階層での操作方法。
SH-03B では、メニューはアイコンが３×４に並ぶことで表示されます。
これを指でタッチしてやればよい。
非常に直感的で、問題なし。
---
下位の階層（設定メニューなど、階層が深くなる場合）では、メニューが文字で書かれたリストになります。
動作が明らかに違うのであればアイコンで示しやすいけど、微妙な差をアイコンで示すことは難しいため、文字が中心になることは理解できます。
ここでは、指でタッチすると「選択」、選択されたものを続けてタッチすると「決定」になります。
つまり、アイコンはシングルタッチで開くが、文字リストはダブルタッチしないと開かない。
…なんか、操作が変わって気持ち悪いけど、まぁ許しましょう。
文字はアイコンより密集した表示になっているので、シングルタッチで起動してしまうと、間違えて押す場合もありますから。
一度選択して、正しいことを確認してから決定、という作法は、それなりに理にかなっている。
また、書かれていることが長くなる場合、選択されたところで横スクロール表示となります。
（いわゆる Ticker 表示）
この意味で、「選択」という動作が挟まることには一定の意味があります。
---
設定メニューの一番下の階層などでは、ダイアログが開いて、設定を選ばせる場合があります。
ここも文字リストになるわけですが、シングルタッチで決定です。
ダイアログは、画面の中にウィンドウを描くことで実現しているため、通常に画面に描くより表示領域が狭いです。
当然、文字が全部表示されないことは増えますし、文字リストですから選択すると横スクロール表示が始まります。
（キーボードを引き出して操作する場合には、「選択」した状態が存在する）
でも、シングルタッチで決定です。
類似内容の長い文字列で、先頭だけで区別できなかったとしても、シングルタッチで決定です。
ダイアログ、というものの性質上、意思確認すればすぐに消えるのが望ましいので、ダブルタッチは面倒くさい、と言う気持ちはわかります。
でも、先に書いたように文字リストによるメニューの操作が「文字で書かれていると誤操作しやすい」「選択しないと最後まで読めない」ためにダブルタッチで決定だった、と考えると、インターフェイスとして破綻していないか？
-=-=-=
メニューが一画面に収まらない時は、「次ページ」が存在します。
そう、画面に収まりきらない時のメニューは、ページ送りインターフェイスなのですね。
ページ送りは、タッチしたまま指を左右に滑らせる（スライド、と呼びます）ことで行います。
…基本はね。
アイコン表示のメニュー画面では、次ページが存在していることを、画面右上に三角形を表示することで示します。
でも、文字リストのメニュー画面では、画面左下に、ページ送りのボタンを表示することで示します。
前者では三角形を押すことで、後者ではボタンを使って、ページ送りすることもできます。
メニューの階層によって、作法が統一されていない。
メニューから、各種の「設定確認」等を選んだ場合、画面に収まらないほどの設定状況を表示します。
この場合も、ページ送りが発生しますが、状況によって作法が異なります。
「メール設定確認」では、文字リストによるメニュー画面と同じ作法です。
でも、一般設定の「設定状況確認」では、文字リストによるメニューとも、アイコンによるメニューとも異なる別の作法です。
画面左上には三角形は表示されず、左下のボタン表示もないため、「タッチ」でページを送ることはできません。
その代わり、左右スライドに加え、上下スライドでもページ送りできます。
iモード設定確認にいたっては、「ページ送り」ではなく、上下スクロールで内容が確認できます。
この際、右端に「スクロールバー」が存在し、背景は黒です。
カメラ画像などの詳細確認でも、上下スクロールで確認です。
しかし、この際にスクロールバーのように「上下スクロールである」ことを示すものは表示されず、背景にも普通に壁紙として設定された画像が表示されています。
（後で触れますが、実際スクロールを行っている間の背景は黒です。）
極めて混乱しています。
おそらくは、メニューから選択される「設定確認」などはアプリケーション扱いで、各アプリの制作者が異なるのでしょう。
でも、そんな「プログラマー側」の都合でユーザーが混乱するインターフェイスを作ってはいけません。
やむを得ない理由がある場合を除いて、混乱が無いように機能を作らなくては。
---
場合によっては、メニュー上でサブメニューを開いて操作する場合があります。
サブメニューは、画面下に「サブメニュー」と書いたボタンがあるのでそれをタッチしてもよいのですが、小さなボタンを押すよりも、「上から斜め下にスライド」させることで表示することもできます。
サブメニューは、先ほども書いた「ダイアログ」で表示されます。
ダイアログに内容が収まりきらない時は、上下にスライドすることで、縦スクロールできます。
メニューは収まらないとページ送りですが、サブメニューは縦スクロールなのです。
どうやら、メニューのような「全画面表示」を滑らかにスクロールさせるには、処理能力が足りないようです。
（iモード設定確認はスクロールしているが、背景を真っ黒にしている。写真などの詳細表示も、スクロールしていない時には背景に設定した画像が表示されるのに、スクロール開始したとたんに真っ黒になる。）
…話は脱線しますが、ここら辺に技術者の苦悩と、統一性の取れなさが垣間見えます。
iPhone のようにスムーズにスクロールするには処理能力が足りず、ページ送りインターフェイスを選んだのでしょうが、一部の技術者が「俺ならできる」と、自分の担当アプリケーション内で、勝手に技術を競い合ったようです。
あぁ、君らの技術の高さは認めるよ。でも、それで製品全体としてはちぐはぐな部品の寄せ集めになって、完成度が下っているよ！
＃処理能力について弁護：iPhone の画面は 320x480、SH-03Bは 480x854。
2.6倍ほど画面の広さが違うため、全画面での重ね合わせ付きスムーススクロールが難しいことは、SH-03B の処理能力が低いことを意味しない。
実際、全画面ではなく、ダイアログのような小さな領域では、重ねあわせ付のスクロールをやっている。
…脱線終わり。
ところで、基本的には、「文字リストによるメニュー」ではサブメニューは使われません。
文字リストによるメニューでは「タッチ」によって選択が行われるため、その後のスライドによってサブメニューを開く、という操作と相性が悪いのです。
例外が、受信メールボックス一覧の画面や、iモードブラウザのURL履歴一覧画面です。
受信メールボックス一覧では、選択中のメールボックスに対する操作を、サブメニューで行えます。
URL履歴でも、選択中の URL に対する操作を行えます。
そしてまた、この２つでの操作方法が混乱しています。
URL 履歴では、タッチした瞬間に選択が行われ、そこから斜め下スライドでサブメニューが表示されます。
画面最下部に表示された URL は、そこから下にスライドを行うことができないため、この方法でサブメニューを表示することはできません。
受信メールボックス一覧では、リストの一番上に「受信トレイ」があり、その下に振分け用のフォルダが並びます。
サブメニューを開くためには、必ず「受信トレイ」よりも画面上の領域から、斜め下にスライドしなくてはなりません。
振り分け用フォルダへのタッチは、必ず選択になります。そこから斜め下スライドでサブメニューを呼び出すことはできません。
逆に、受信メールボックスへのタッチは、即選択にはなりません。
タッチしてすぐに離す、という操作をしたときのみ、選択扱いになります。
-=-=-=
SH-03B を買いたくて情報を探している方、ご愁傷様。
でも、最初に書いたように、普通の携帯でQWERTYキーボードが欲しいなら、他に選択肢はありませんよ。
SH-03B が良い機種だ、と言うのは紛れもない事実で、だからこそ僕は不満点を率直、かつ論理的にさらし挙げているのです。次の機種では改善されることを願って。
読んでいる人もそろそろうんざりしてきた事と思いますが、最後にさらに酷い話を。
i-mode での操作は更に厄介。
ここまでは「携帯内部に作りこまれた」メニューやアプリの話でしたから、これでも「タッチパネルでの使いやすさ」を考慮した作りにはなっているのです。
i-mode では、そんな考慮はありません。
小さな文字でリンクテキストが密集している中から、シングルタッチで選択して、さらにダブルタッチでリンク先へ進む。
ドコモ公式の料金確認ページなんて、１文字だけへのリンクなどが散在します。
（セキュリティのため、POST QUERY を使うために、リンクテキストではなく form ボタンになっているが、
違和感を感じさせないために、ボタンに対応する枠付数字のように偽装してある）
これをダブルクリックすることのもどかしさ。
諦めてキーボードを引き出すと、画面は横画面になり、縦画面しか想定していない i-mode ブラウザは、画面の半分しか使用しなくなります。広い画面があるのに無駄遣い！
「前画面に戻る」時には、左スライドで数ページ前までの履歴を呼び出せたり、ブラウザとしてはなかなか頑張っているのですが…
表示文字をある程度大きくして我慢していますが、根本解決ではありません。
通常の機種では、上下ボタンでフォーカスが移動します。
だから、上下にスライドしたら同じようにフォーカス移動してくれれば…と思うのですが、無常にも画面がスクロールするだけです。
-=-=-=
…と、不満点を挙げましたが、不満を言うだけで終わるのは無責任と言うもの。
自分もプログラマーだから、「メニューと各アプリは違うプログラムになっている」ことは理解できるのです。
そして、各アプリが作法を統一しないまま作りこまれてしまった。
もしくは、プログラマーの人数が足りなくて、十分作りこめなかったのかも。
でも、それは作る側の都合。使う側には関係ない話です。
まず、最大の問題は、作法が破綻していること。
シングルタッチで決定か、ダブルタッチで決定かは統一していただきたい。
おそらく、問題の根本は、「タッチ時に選択・決定」が行われていることです。
離した時に行われるのが正しい。マウスなんかの動作だってそうなっています。
「離したら決定」を導入するだけで、問題の半分以上が解決するはず。
アイコンは今と変わらずシングルタッチで起動しますし、文字リストによるメニューでも、押した時点で選択、スライドすると選択位置変更、離したら実行、であれば、シングルタッチと同じ感覚で使ってもいいし、間違えた場合のリカバーも効く。
i-mode ブラウザも、スライドしている間「選択位置変更」と考えてもらえれば、フォーカス移動が簡単にできるわけです。
＃細かな話だが、form のセレクトボックスは、一度目の「選択」で開いて、２度目はセレクトボックスから離れた場所をタッチしても、選択動作に入って欲しい。セレクトボックスの項目が狭いことがあるため。
この場合、スライドが「選択」動作に割り当てられるため、そのままではページ送りやスクロールがなくなってしまいます。
そこは、マルチタッチ可能なタッチパネルを使っているのですから、２本指タッチで。
ページ送りやスクロールは、スライドの「開始位置」などに意味はないので、２本指でもポイントしにくい、などの問題は出ません。
サブメニューを開く場合も、１本指でセレクトしてから、２本指で斜め下にスライド。これで問題なし。
＃マルチタッチ操作には特許とかの問題もあるとは思うが、画像ビュワーでは２本指での拡大縮小やっているのだから…
操作作法に混乱がなくなれば、あとはアプリごとの微妙な動作の差異だけが問題ですが…
これは、プログラマーさんに頑張って、と言うより他になし (^^;;
実際、ここが一番大変だとは思いますが、今の統一感のなさは酷すぎる。
と言うわけで、愚痴は終了。
いいたいこと言って、これでやっとスッキリと携帯を使うことができます。
繰り返しになりますが、悪い携帯ではないので、次の機種に期待しています。＞SHARPの方々
自分の日記に書いて SHARP の人の目に留まるとは思えないけど、不満がたまっているのでどこかに書き出さないと気がすまないだけです。
まず、しばらく使ってみて、SH-03B は非常に良い端末だ、と、先に書いておきます。
テンキーでメールなんて書けるか！ とお困りで、でも i-mode を始めとする、いわゆる「普通の携帯」でないと受けられないサービスが多くて困る、という人には、他に選択肢はないと言って良いでしょう。
待ち受け画面から最初に表示されるメニューは、自由に組み替え可能です。
なので、良く使う機能をすぐに呼び出せます。
でも、組み替えなくても、本当によく使われる機能は最初からすぐ呼び出せるの。
日付をタッチすればスケジューラーが、時刻をタッチすればアラーム設定が呼び出されます。
だから、そういう点に不満はない。
不満は、タッチパネルを使用したユーザーインターフェイスに集中しているのです。
---
まず、タッチパネルは「本体内蔵メニュー」及び「Java 以外の内蔵アプリ」でしか効きません。
i-mode のトップメニューは、Flash 内蔵端末ではデフォルトで Flash で表示されますが、操作できません。
タッチパネル上にバーチャルキーボードを表示して、そこで操作するの。
この操作が最悪。
i-mode のトップメニューに関しては、設定すれば通常の HTML 表示にもできますが、そういう設定に対応していないサイトや、最初から Flash が前提のゲームなどはあきらめたほうが良い。
Java も、タッチパネルに対応した API は DoCoMo 標準で定められているようですが、プリインストールのアプリですらほとんど使っていませんので諦めるしかないです。
とはいえ、ここら辺は Flash や Java という「個々のアプリ」の問題でもあるので、仕方なく許容範囲。
技術がわかっていない人なら十分文句が出るような部分だけど、僕はプログラマーだから、ここら辺が仕方ないことは理解できる。
というわけで、問題はどんどん切り分けられて、いよいよ「インターフェイス」の詳細に入ります。
-=-=-=-=-=-=-=-=
まず、メニュー上位階層での操作方法。
SH-03B では、メニューはアイコンが３×４に並ぶことで表示されます。
これを指でタッチしてやればよい。
非常に直感的で、問題なし。
---
下位の階層（設定メニューなど、階層が深くなる場合）では、メニューが文字で書かれたリストになります。
動作が明らかに違うのであればアイコンで示しやすいけど、微妙な差をアイコンで示すことは難しいため、文字が中心になることは理解できます。
ここでは、指でタッチすると「選択」、選択されたものを続けてタッチすると「決定」になります。
つまり、アイコンはシングルタッチで開くが、文字リストはダブルタッチしないと開かない。
…なんか、操作が変わって気持ち悪いけど、まぁ許しましょう。
文字はアイコンより密集した表示になっているので、シングルタッチで起動してしまうと、間違えて押す場合もありますから。
一度選択して、正しいことを確認してから決定、という作法は、それなりに理にかなっている。
また、書かれていることが長くなる場合、選択されたところで横スクロール表示となります。
（いわゆる Ticker 表示）
この意味で、「選択」という動作が挟まることには一定の意味があります。
---
設定メニューの一番下の階層などでは、ダイアログが開いて、設定を選ばせる場合があります。
ここも文字リストになるわけですが、シングルタッチで決定です。
ダイアログは、画面の中にウィンドウを描くことで実現しているため、通常に画面に描くより表示領域が狭いです。
当然、文字が全部表示されないことは増えますし、文字リストですから選択すると横スクロール表示が始まります。
（キーボードを引き出して操作する場合には、「選択」した状態が存在する）
でも、シングルタッチで決定です。
類似内容の長い文字列で、先頭だけで区別できなかったとしても、シングルタッチで決定です。
ダイアログ、というものの性質上、意思確認すればすぐに消えるのが望ましいので、ダブルタッチは面倒くさい、と言う気持ちはわかります。
でも、先に書いたように文字リストによるメニューの操作が「文字で書かれていると誤操作しやすい」「選択しないと最後まで読めない」ためにダブルタッチで決定だった、と考えると、インターフェイスとして破綻していないか？
-=-=-=
メニューが一画面に収まらない時は、「次ページ」が存在します。
そう、画面に収まりきらない時のメニューは、ページ送りインターフェイスなのですね。
ページ送りは、タッチしたまま指を左右に滑らせる（スライド、と呼びます）ことで行います。
…基本はね。
アイコン表示のメニュー画面では、次ページが存在していることを、画面右上に三角形を表示することで示します。
でも、文字リストのメニュー画面では、画面左下に、ページ送りのボタンを表示することで示します。
前者では三角形を押すことで、後者ではボタンを使って、ページ送りすることもできます。
メニューの階層によって、作法が統一されていない。
メニューから、各種の「設定確認」等を選んだ場合、画面に収まらないほどの設定状況を表示します。
この場合も、ページ送りが発生しますが、状況によって作法が異なります。
「メール設定確認」では、文字リストによるメニュー画面と同じ作法です。
でも、一般設定の「設定状況確認」では、文字リストによるメニューとも、アイコンによるメニューとも異なる別の作法です。
画面左上には三角形は表示されず、左下のボタン表示もないため、「タッチ」でページを送ることはできません。
その代わり、左右スライドに加え、上下スライドでもページ送りできます。
iモード設定確認にいたっては、「ページ送り」ではなく、上下スクロールで内容が確認できます。
この際、右端に「スクロールバー」が存在し、背景は黒です。
カメラ画像などの詳細確認でも、上下スクロールで確認です。
しかし、この際にスクロールバーのように「上下スクロールである」ことを示すものは表示されず、背景にも普通に壁紙として設定された画像が表示されています。
（後で触れますが、実際スクロールを行っている間の背景は黒です。）
極めて混乱しています。
おそらくは、メニューから選択される「設定確認」などはアプリケーション扱いで、各アプリの制作者が異なるのでしょう。
でも、そんな「プログラマー側」の都合でユーザーが混乱するインターフェイスを作ってはいけません。
やむを得ない理由がある場合を除いて、混乱が無いように機能を作らなくては。
---
場合によっては、メニュー上でサブメニューを開いて操作する場合があります。
サブメニューは、画面下に「サブメニュー」と書いたボタンがあるのでそれをタッチしてもよいのですが、小さなボタンを押すよりも、「上から斜め下にスライド」させることで表示することもできます。
サブメニューは、先ほども書いた「ダイアログ」で表示されます。
ダイアログに内容が収まりきらない時は、上下にスライドすることで、縦スクロールできます。
メニューは収まらないとページ送りですが、サブメニューは縦スクロールなのです。
どうやら、メニューのような「全画面表示」を滑らかにスクロールさせるには、処理能力が足りないようです。
（iモード設定確認はスクロールしているが、背景を真っ黒にしている。写真などの詳細表示も、スクロールしていない時には背景に設定した画像が表示されるのに、スクロール開始したとたんに真っ黒になる。）
…話は脱線しますが、ここら辺に技術者の苦悩と、統一性の取れなさが垣間見えます。
iPhone のようにスムーズにスクロールするには処理能力が足りず、ページ送りインターフェイスを選んだのでしょうが、一部の技術者が「俺ならできる」と、自分の担当アプリケーション内で、勝手に技術を競い合ったようです。
あぁ、君らの技術の高さは認めるよ。でも、それで製品全体としてはちぐはぐな部品の寄せ集めになって、完成度が下っているよ！
＃処理能力について弁護：iPhone の画面は 320x480、SH-03Bは 480x854。
2.6倍ほど画面の広さが違うため、全画面での重ね合わせ付きスムーススクロールが難しいことは、SH-03B の処理能力が低いことを意味しない。
実際、全画面ではなく、ダイアログのような小さな領域では、重ねあわせ付のスクロールをやっている。
…脱線終わり。
ところで、基本的には、「文字リストによるメニュー」ではサブメニューは使われません。
文字リストによるメニューでは「タッチ」によって選択が行われるため、その後のスライドによってサブメニューを開く、という操作と相性が悪いのです。
例外が、受信メールボックス一覧の画面や、iモードブラウザのURL履歴一覧画面です。
受信メールボックス一覧では、選択中のメールボックスに対する操作を、サブメニューで行えます。
URL履歴でも、選択中の URL に対する操作を行えます。
そしてまた、この２つでの操作方法が混乱しています。
URL 履歴では、タッチした瞬間に選択が行われ、そこから斜め下スライドでサブメニューが表示されます。
画面最下部に表示された URL は、そこから下にスライドを行うことができないため、この方法でサブメニューを表示することはできません。
受信メールボックス一覧では、リストの一番上に「受信トレイ」があり、その下に振分け用のフォルダが並びます。
サブメニューを開くためには、必ず「受信トレイ」よりも画面上の領域から、斜め下にスライドしなくてはなりません。
振り分け用フォルダへのタッチは、必ず選択になります。そこから斜め下スライドでサブメニューを呼び出すことはできません。
逆に、受信メールボックスへのタッチは、即選択にはなりません。
タッチしてすぐに離す、という操作をしたときのみ、選択扱いになります。
-=-=-=
SH-03B を買いたくて情報を探している方、ご愁傷様。
でも、最初に書いたように、普通の携帯でQWERTYキーボードが欲しいなら、他に選択肢はありませんよ。
SH-03B が良い機種だ、と言うのは紛れもない事実で、だからこそ僕は不満点を率直、かつ論理的にさらし挙げているのです。次の機種では改善されることを願って。
読んでいる人もそろそろうんざりしてきた事と思いますが、最後にさらに酷い話を。
i-mode での操作は更に厄介。
ここまでは「携帯内部に作りこまれた」メニューやアプリの話でしたから、これでも「タッチパネルでの使いやすさ」を考慮した作りにはなっているのです。
i-mode では、そんな考慮はありません。
小さな文字でリンクテキストが密集している中から、シングルタッチで選択して、さらにダブルタッチでリンク先へ進む。
ドコモ公式の料金確認ページなんて、１文字だけへのリンクなどが散在します。
（セキュリティのため、POST QUERY を使うために、リンクテキストではなく form ボタンになっているが、
違和感を感じさせないために、ボタンに対応する枠付数字のように偽装してある）
これをダブルクリックすることのもどかしさ。
諦めてキーボードを引き出すと、画面は横画面になり、縦画面しか想定していない i-mode ブラウザは、画面の半分しか使用しなくなります。広い画面があるのに無駄遣い！
「前画面に戻る」時には、左スライドで数ページ前までの履歴を呼び出せたり、ブラウザとしてはなかなか頑張っているのですが…
表示文字をある程度大きくして我慢していますが、根本解決ではありません。
通常の機種では、上下ボタンでフォーカスが移動します。
だから、上下にスライドしたら同じようにフォーカス移動してくれれば…と思うのですが、無常にも画面がスクロールするだけです。
-=-=-=
…と、不満点を挙げましたが、不満を言うだけで終わるのは無責任と言うもの。
自分もプログラマーだから、「メニューと各アプリは違うプログラムになっている」ことは理解できるのです。
そして、各アプリが作法を統一しないまま作りこまれてしまった。
もしくは、プログラマーの人数が足りなくて、十分作りこめなかったのかも。
でも、それは作る側の都合。使う側には関係ない話です。
まず、最大の問題は、作法が破綻していること。
シングルタッチで決定か、ダブルタッチで決定かは統一していただきたい。
おそらく、問題の根本は、「タッチ時に選択・決定」が行われていることです。
離した時に行われるのが正しい。マウスなんかの動作だってそうなっています。
「離したら決定」を導入するだけで、問題の半分以上が解決するはず。
アイコンは今と変わらずシングルタッチで起動しますし、文字リストによるメニューでも、押した時点で選択、スライドすると選択位置変更、離したら実行、であれば、シングルタッチと同じ感覚で使ってもいいし、間違えた場合のリカバーも効く。
i-mode ブラウザも、スライドしている間「選択位置変更」と考えてもらえれば、フォーカス移動が簡単にできるわけです。
＃細かな話だが、form のセレクトボックスは、一度目の「選択」で開いて、２度目はセレクトボックスから離れた場所をタッチしても、選択動作に入って欲しい。セレクトボックスの項目が狭いことがあるため。
この場合、スライドが「選択」動作に割り当てられるため、そのままではページ送りやスクロールがなくなってしまいます。
そこは、マルチタッチ可能なタッチパネルを使っているのですから、２本指タッチで。
ページ送りやスクロールは、スライドの「開始位置」などに意味はないので、２本指でもポイントしにくい、などの問題は出ません。
サブメニューを開く場合も、１本指でセレクトしてから、２本指で斜め下にスライド。これで問題なし。
＃マルチタッチ操作には特許とかの問題もあるとは思うが、画像ビュワーでは２本指での拡大縮小やっているのだから…
操作作法に混乱がなくなれば、あとはアプリごとの微妙な動作の差異だけが問題ですが…
これは、プログラマーさんに頑張って、と言うより他になし (^^;;
実際、ここが一番大変だとは思いますが、今の統一感のなさは酷すぎる。
と言うわけで、愚痴は終了。
いいたいこと言って、これでやっとスッキリと携帯を使うことができます。
繰り返しになりますが、悪い携帯ではないので、次の機種に期待しています。＞SHARPの方々
V60 設計者にお会いした。 2010-03-15 09:58:44 COMP
V60 、と言って何人の人が理解してくれるだろう？
NEC が過去に作った CPU で、非常に直行性が高いのが特徴である。
…直行性、自体が現在では死語だな。
その昔、CPU の使いやすさとは、アセンブラの使いやすさであった時代がある。
アセンブラでは、命令に対して「ソース」（元データ）と「デストネーション」（演算対象）を指定するが、CPU の設計上の都合で、ソースとデストネーションの組み合わせには制限がある。
例えば、演算対象は、そのまま演算結果の保存に使用されることが多い。
このため、デストネーションに「即値」（数値そのもの）を指定することはできない。
インテル系の CPU であれば、演算は常に「Aレジスタ」を対象に行われた。
B レジスタと A レジスタを足す、とか、メモリ内容と A レジスタを足す、と言うことはできても、メモリ内容とメモリ内容を足す、はできなかった。
直行性、というのは、このような制限がほとんどないことを意味する。
メモリ内容とメモリ内容を足すなんて当たり前だし、「A レジスタの示すメモリに格納されたデータをアドレスとみなし、そのアドレスに示したデータ」同士を足したりもできる。
これ、CPU を設計する上では、結構面倒なことなのだ。
現代の CPU は、アセンブラを直接扱うことなど考えず、「C 言語でプログラムが組めれば十分」と考えるため、直行性など考慮されない。
つまり、V60 が直行性が高い、と書いた冒頭の話は、現代においてはあまり意味を持たない。
でも、当時としては非常に画期的で高性能だったのだ。
日本の会社が作った、世界に誇れる CPU 。それが V60 だった。
---
いきなり話が脱線しているが、脱線ついでにもう少し。
NEC は、V30 という CPU も作っていた。こちらのほうが有名。
8086 互換で性能が上だったので、NEC は「国民機」とまで言われた PC-9801 に採用していた。
でも、8086 互換ではあるが、80286 互換ではない。そして、80286 は V30 より性能が上だ。
そのため、PC-9801 では、互換性のためにインテル CPU と V30 を同時に搭載し続けた。
で、V60 は、 V30 互換モードを持ちながら、CPU としては１から独自設計をした CPU だった。
Pentium と PowerPC くらい違うと思いねぇ。でも、互換モードを持っているのだ。
僕は今でこそフリープログラマをしているが、会社員時代に V60 で作られた基盤のプログラムをしたことがある。
その際に、V60 のコアをアクリルに封入した文鎮(?)を頂いていた。
今回、偶然から V60 の設計者の一人にお会いできることになったので、その文鎮を持ってお伺いした。
---
…と、前振り長すぎる上に、実際に会いに行ったのは大学時代の恩師です。
卒業以来１５年、１度も連絡を取っていなかったのですが、このたび定年退職なさるということでパーティに誘われました。
NEC を退職後、大学で自然言語処理の研究をしており、１５年ぶりにその後の研究成果などの講義も受けました。
先生に V60 の文鎮を見せたところ、「うわぁ…懐かしいねぇ。…ここがキャッシュで、ここらへんがパイプライン。ちゃんと見えるねぇ」などと感慨深げ。
ついでに「V60 は、PDP-11 を参考に設計しているんだよ」なんて、知らなかった話も教えてくれます。
近年卒業の方も先生に渡されてしばらく見た後、「すみません、これが何なのか良くわからないです」と僕のところに返却に来ました。
ちなみに、先生は V60 以前に NEC でスーパーコンピューターの設計にも携わっていました。
当時はスーパーコンピューターといえばアメリカ製で、他のどの国も速度を超えられなかった時代。
「世界一の速度を実現する」ために、まずクロック周波数が決められ、そのクロック以内に電気信号が到達できる電線の長さが定められ、全ての場所において、配線がその長さを超えないように注意しながら設計されたそうです。
配線長さを規定する長さの棒を作り、「５ナノ棒」と呼んでいた、という話を大学時代に聞き、非常に面白く思ったものです。
この結果、日本は始めて演算速度世界一のコンピューターを作り、その後しばらくはアメリカと日本が追いつ追われつの速度レースを展開したのだとか。
やはり大学時代に聞いた「人月の神話」の話は…
ずっと心のどこかに引っかかっていましたが、ちゃんと書籍を読んだのは１年位前の話。
「遅れているプロジェクトに人員を投入すると、余計に遅れる」は有名な話なのですが、それ以外の細かな部分が、現在フリーのプログラマをやっている自分には勉強になりました。
特に、必要な人月を見積もる方法については納得。
フリーでやっていると、見積もり・値段交渉がしんどいのだけど、この本で後ろ盾を得て楽になりました。
NEC が過去に作った CPU で、非常に直行性が高いのが特徴である。
…直行性、自体が現在では死語だな。
その昔、CPU の使いやすさとは、アセンブラの使いやすさであった時代がある。
アセンブラでは、命令に対して「ソース」（元データ）と「デストネーション」（演算対象）を指定するが、CPU の設計上の都合で、ソースとデストネーションの組み合わせには制限がある。
例えば、演算対象は、そのまま演算結果の保存に使用されることが多い。
このため、デストネーションに「即値」（数値そのもの）を指定することはできない。
インテル系の CPU であれば、演算は常に「Aレジスタ」を対象に行われた。
B レジスタと A レジスタを足す、とか、メモリ内容と A レジスタを足す、と言うことはできても、メモリ内容とメモリ内容を足す、はできなかった。
直行性、というのは、このような制限がほとんどないことを意味する。
メモリ内容とメモリ内容を足すなんて当たり前だし、「A レジスタの示すメモリに格納されたデータをアドレスとみなし、そのアドレスに示したデータ」同士を足したりもできる。
これ、CPU を設計する上では、結構面倒なことなのだ。
現代の CPU は、アセンブラを直接扱うことなど考えず、「C 言語でプログラムが組めれば十分」と考えるため、直行性など考慮されない。
つまり、V60 が直行性が高い、と書いた冒頭の話は、現代においてはあまり意味を持たない。
でも、当時としては非常に画期的で高性能だったのだ。
日本の会社が作った、世界に誇れる CPU 。それが V60 だった。
---
いきなり話が脱線しているが、脱線ついでにもう少し。
NEC は、V30 という CPU も作っていた。こちらのほうが有名。
8086 互換で性能が上だったので、NEC は「国民機」とまで言われた PC-9801 に採用していた。
でも、8086 互換ではあるが、80286 互換ではない。そして、80286 は V30 より性能が上だ。
そのため、PC-9801 では、互換性のためにインテル CPU と V30 を同時に搭載し続けた。
で、V60 は、 V30 互換モードを持ちながら、CPU としては１から独自設計をした CPU だった。
Pentium と PowerPC くらい違うと思いねぇ。でも、互換モードを持っているのだ。
僕は今でこそフリープログラマをしているが、会社員時代に V60 で作られた基盤のプログラムをしたことがある。
その際に、V60 のコアをアクリルに封入した文鎮(?)を頂いていた。
今回、偶然から V60 の設計者の一人にお会いできることになったので、その文鎮を持ってお伺いした。
---
…と、前振り長すぎる上に、実際に会いに行ったのは大学時代の恩師です。
卒業以来１５年、１度も連絡を取っていなかったのですが、このたび定年退職なさるということでパーティに誘われました。
NEC を退職後、大学で自然言語処理の研究をしており、１５年ぶりにその後の研究成果などの講義も受けました。
先生に V60 の文鎮を見せたところ、「うわぁ…懐かしいねぇ。…ここがキャッシュで、ここらへんがパイプライン。ちゃんと見えるねぇ」などと感慨深げ。
ついでに「V60 は、PDP-11 を参考に設計しているんだよ」なんて、知らなかった話も教えてくれます。
近年卒業の方も先生に渡されてしばらく見た後、「すみません、これが何なのか良くわからないです」と僕のところに返却に来ました。
ちなみに、先生は V60 以前に NEC でスーパーコンピューターの設計にも携わっていました。
当時はスーパーコンピューターといえばアメリカ製で、他のどの国も速度を超えられなかった時代。
「世界一の速度を実現する」ために、まずクロック周波数が決められ、そのクロック以内に電気信号が到達できる電線の長さが定められ、全ての場所において、配線がその長さを超えないように注意しながら設計されたそうです。
配線長さを規定する長さの棒を作り、「５ナノ棒」と呼んでいた、という話を大学時代に聞き、非常に面白く思ったものです。
この結果、日本は始めて演算速度世界一のコンピューターを作り、その後しばらくはアメリカと日本が追いつ追われつの速度レースを展開したのだとか。
やはり大学時代に聞いた「人月の神話」の話は…
ずっと心のどこかに引っかかっていましたが、ちゃんと書籍を読んだのは１年位前の話。
「遅れているプロジェクトに人員を投入すると、余計に遅れる」は有名な話なのですが、それ以外の細かな部分が、現在フリーのプログラマをやっている自分には勉強になりました。
特に、必要な人月を見積もる方法については納得。
フリーでやっていると、見積もり・値段交渉がしんどいのだけど、この本で後ろ盾を得て楽になりました。