タッチスクリーンで、UIの精度を上げるメモ
・タッチダウンからタッチアップが0.03秒以内の場合、ドラッグではなくタップと判断し値の移動を無視。
・タッチアップの瞬間から過去0.03秒内のスライダーの移動は、リリース時の誤差とみなして無視する。
・タッチアップの瞬間から過去0.3秒以内に、スライダーが0.1秒以上停止していた場合、その停止中の値を採用する。
・横スライド時に、横の移動量の30%以上縦に移動していた場合、スライド量の補正を考える。
多分、ここら辺のアルゴリズムを入れれば、スライダーの精度をもっとよくできるんじゃないかと思う。メンドイけどこういうところが重要なはず。
タッチスクリーンと、スライダーの相性はすこぶる悪いという印象がある。
第一の原因は、指がスライダーのサムを隠してしまう為正確な値が見えないこと。第二の原因は、指をリリースするタイミングでタッチスクリーンが反応してしまい、値がずれてしまう為だ。
この為、iPhoneのタッチスクリーンでの値の操作には、Picker系のコントローラーかNumericStepperを使うのが王道だと思う。ならばスライダーは訳に立たないのだろうか？と悩む。
確かに、正確な値が重要でないファジーなパラメータの指定では、スライダーは大丈夫かもしれない。 TiltShift Generatorの場合は、スライダーにポップアップをつけることで値の現在位置を表示している点、またパラメーターの細かい数字がそれほど重要じゃない点から、スライダーを採用した。じゃあ、一定レンジの値を正確に入力するのにスライダーは本当に不向きなのか。
個人的にはスライダーをドラッグ中の指の位置をトラックし、リリースの瞬間２フレーム以内の値を無視したり、スライダーの位置が１フレーム以上滞在した時点で値を確定する、というようにすることでもうちょっと精度があがりそうな気もする。 過去Xフレームの位置の移動平均的なものを、スライダーの値として採用してもいいかもしれない。
とにかくもうちょっと、なんか工夫してスライダーの精度がでないかな？？と悩んでる感じです。
イラレの体操に、サイコガンダムMk-2。 作業に煮詰まったときの気分転換に気軽にはじめたのだけど、腐ってもガンダム、途中から気分転換が苦行に変化し、ハンパなく大変で死に掛けました。後頭部のトサカのあたりのカーブがお気に入り。
デカイ版はpixivに置いてみた。 大分、感覚がもどってきたので、そろそろ車や飛行機に挑戦できそうな気がしてきた。
EEDARのアナリストJesse Divnich、ゲームの売り上げはその品質ではなく広告費によって決定される、というリポートを発表した。
Jesseによれば、広告費と売り上げの相関関係は、metacritic.com (大手ゲームスコアサイト) の評価と相関性と比べ、三倍の違いがあるという。 彼はこの統計とリポートの結論として、「何かを犠牲にするなばら、まずクオリティを犠牲にすべきだ」と結んでいる。
ちょっと記事を読んだ限りでは、広告費が多いことが売り上げの必須条件なのか、単に市場全体で広告費5%以上のプレイヤーが大半を占めてたので相関性がでたのか、判別はできないが、示唆するところはそれなりに面白い。 広告と売り上げの相関関係はわからないけど、品質と売り上げの相関関係が薄いのは、残念ながら厳然たる事実であるように思える。
なんというか自分達モノづくりする人間の生き様を全否定するようなリポートではあるけれど、あながち間違いでもないのが悔しいところ。 いいモノ作るだけで勝手に売れるようならば、誰もウェブキャンペーンなんかにお金を割かないわけで。 たとえ、どんなにいい商品を作っても、商品の品質が影響するのは露出～購入の段階に入ってからであり、露出をする部分においては品質はそれほど寄与しない、というのは事実だと思う。
結局のところ、「高品質であるということ」を広告しなければ、購買は発生しないということなのだと思う。
反論として、広告で無理矢理売っても２作目以降の信用が落ちる・・・という話もあるけど、そもそも超大作を広告かけないでコカした場合、２作目は作ることすら適わないため、この指摘はちょっと正しくないような気もする。
記事がセンセーショナルなので極論っぽくとられているけれど、素直に読む限り、「クオリティと広告費のどちらかを削らなければならない場合、相関性の高い広告費を守るべき」というコスト配分の意味であって、クオリティに意味がないというわけではないと思う。
記事の統計が信用に足ると仮定するなら、価格帯や市場の平均にクオリティが達した場合、それ以後の予算は広告費が5%に達するまで、広告と品質アップに例えば３：１の割合で投入すべき、と見るのが正しいのではないだろうか。
というわけで、自分ももっとイイモン作って、この相関関係を壊せるようにガンバロっと。
iPhone用のUIコンポーネントを先行開発しようとしてて、思ったんだけど。 UIコンポーネントのViewとControllerは完全に分離して、コンポーネントはControllerのみに専念すべきじゃないだろうか。
Flashでコンポーネントを使うときの最大の問題点はいつもビューのカスタマイズで、コンポーネントの構造そのものに手をいれることはまずない。ならばそこだけ分離して、ユーザーが自由にviewを作れるほうがいいんじゃないかと。
で、ビューをコントローラから分離すると、多分UIコンポーネントはこんなにシンプルになる。
・ActionController
アクションのトリガーとなる何かの為のControlelrクラス。 サブクラスはButtonController、 KeyboardController、MicrophoneController、MouseClickControlelr、ScrollBar等。
・ValueInputController
文字、数値を入力する為のController。 サブクラスは、InputField、 NumericStepper、 Slider、 CheckBox等。
・ValueSelector
複数の値から１つを選択する為のController。 サブクラスはRadioButton、ListBox、 TabBar、SegmentedControl等。
というように、たった３つのクラスで大半のUIをサポートできる。 あとはTableViewControlelrとScrolViewControlelrぐらいがあれば、ほぼ大丈夫。
Flash Player 10.1が出ましたね。 最近iPhoneしかやってないようにみせて、もちろんちゃんとキャッチアップしてます。以下それぞれのキーフィーチャーについて雑感めも。こう列挙すると10.1はモバイルとメディア配信に特化したアップデートのようですね。
(more…)
ジオタギングなんかより、現実拡張はコッチの方向に進むべきだと思うんだ。 いやマジで。
Flash for iPhone のパブリックベータは、年内リリースの予定。 なので、そろそろ先行してiPhoneで動きそうなコンテンツを作り始めてもいい時期。
もっともFlash for iPhoneの詳細な仕様はまだ謎のままなので、ある程度アタリをつけながらコンテンツを作ることになる。 下手をしたらせっかく作ったのに速度がでないとか、動かないとかは十分にありえる。以下は、iPhoneの仕様と、Flash Liteの仕様をベースにした、これは鉄板と思われるチェックポイント。
- ボタンのサイズは 48 ピクセル以上にする。
- ロールオーバーは存在しない。
- LoadMovie系は使わない
- ボタン等は、アップのタイミングでアクションを行う、ダウンではない。
- Blend Mode と Alpha は使わない
- 背景は全部まとめて、１枚pngにする。 Flash lite でコンテンツを作ってるつもりで。
こんなところかなと。
日経bpさんから、『Twitterの衝撃 140文字がビジネスからメディアまで変える
僕は執筆にはコミットしていませんが、第８章が 「仕事にTwitterを駆使するiPhoneアプリ開発者」 ということで、 一冊いただきました。
10ページぐらいのですが、僕が発起人となった @iphone_dev_jp によるiPhoneアプリ開発者の情報共有や 森さんと一緒に作った TiltShift Generator などが扱われています。多分、ソースの半分ぐらいが僕。
ざっと読んだ感想としては、Twitterを理解するに入門本としてはいい感じかと思います。 ただ一点だけ、ちょっとTwitterのダークサイドというか、リスク管理的な側面があまり扱われておらず、Twitter賛歌っぽくなっちゃってるのが気になるところ。
この内容を100%鵜呑みにして、自分でアカウント作らずに、広告プロモーションで行きなり導入とかいうのはちょっと危険かと思います。逆に読書後に、自分でアカウント作って試す、というスタイルならばとてもよい指針になるかと。
ちなみに iphone_dev_jpをクロールする、Twicco のボットが馬鹿になって、１日数回まとめて配信になってから、iPhone_dev_jp はちょっと使いにくくなって、パワーダウンしちゃいました。 ボットを引っ越そうか、自力でボットを作ろうかちょっと悩み中。誰かサーバーサイド書ける人、パパッとボット作れないでしょうか。
