「ボタンと、そのボタンが担う機能の対応関係」です。

ボタンと機能の対応関係パターン

僕の浅はかな経験と知識からだと、下の3つのパターンがあると思います。

ボタン：機能の対応が、

• 1:1　
• 1:多　
• 多：1

ひとつずつ、具体例を上げてみます。

1つのボタンが1つの機能しか持たない場合

ボタン：機能　＝　1 : 1 の場合ですね。

世の中の「ボタン」と呼ばれるものの大半がコレに当たると思います。
メールソフトで考えると、「送信ボタン」というのは、「メールを送信する」という機能のみを提供する、と行った具合です。

この対応関係は、そのボタンのアイコン（一般的にはビジュアルサインとでも言うんでしょうかね）と機能がよほどかけ離れていなければ、
ユーザーに取っては解りやすい、というか、間違用のないユーザーインターフェイスになるかと思います。

1つのボタンが、状況によって機能を切り替える場合

ボタン：機能　＝　1 : 多　の場合。

これも、かなり存在するパターンだと思います。

皆さんがいま、このブログを見ているブラウザ。　そのブラウザのスクロールバーの上向きボタンは、
1回クリックすれば、一回分ページが上方に移動します。

しかし、ボタンを押し下げっぱなしにすると、押し下げている間、上方にスクロールし続けますよね。

これは、1つのボタンで、2つの機能を提供していると言えるかと思います。

上記の例は、「ボタンの押し方」というパラメーターで、機能を切り替えているわけですが、
それ以外にも、「現在の状況」で切り替えるパターンもあります。

iPod等の音楽プレイヤーの「再生/一時停止」ボタンなんかがそれにあたりますね。

再生中に、「再生/一時停止」ボタンを1回押すと、一時停止します。
一時低中に「再生/一時停止」ボタンを1回押すと、再生を再開します。

同じ操作でも、今がどういう状況かによって機能が切り替わる例として身近なものなのではないでしょうか。

この「1:多」の場合、ユーザーに対して混乱を与えないようにするためにはいくつかの注意点があるかと思います。

1つのボタンが提供機能する機能を2つ以上にする場合の注意点

「再生/一時停止」ボタンが一般的であるのは、提供する機能が2つで、その各々が対になるペア的な機能である事が要因であると、個人的には考えています。

僕は日頃、「人間は、2つの事なら同時に理解できるような作りになっている」と感じてます。

高校の数学でも、2次元の事は一気に計算する方法を教わりましたけど、3次元に関しては一旦、1つの次元を無視した上で計算し、その後に無視した1つを復帰させて考えるという方法だったと思います。（ex : 二次関数と三次関数の解放手順とか・・・）

なので、2つまでは「できて当然」と思っていても、バチは当たらないのかな、と。

あとは、提供する機能が「真反対の機能」であれば、もう間違いなく理解してもらえるんじゃないでしょうか。
例えば、「再生/一時停止」ボタンではなく、「再生/次のチャプターへ」ボタンだったら、なんか直感に反して気持ち悪いボタンになってしまう気がします。

（あ、「なんか気持ち悪いボタン」っていうシリーズで作ってみるとオモロイかもしれないですね・・・）

複数のボタンが、同じ機能を提供する場合

ボタン：機能　＝　多：1　の場合ですね。

これは、具体例を探すのが結構大変なので、あまり一般的ではないようです。

僕が見つけたのは、

• 携帯の「十字キー」の代わりに、数字ボタンの2,4,6,8 で代替する
• キーボードのShift, Control Alt ボタン（Macは、、、殆ど使わないのでわかりません）

くらいですかね。

この場合に共通して言えるのは、
なんか、使いにくかったらもう一方のボタンを使ってねという作り手の心遣いだという気がします。

携帯の十字キーって、端末のデザインによってはスゴイ押しづらい場合があります。シューティングゲーとかをやってる日にゃあ、押しづらかったらクレームものでしょう。

そういう、物理的にそのボタンを押すのが困難な状況が考えられる場合に、押しやすい方で操作できるようにする。
これが、この「多：1」というパターンの使い時なわけですね。

それ以外に、この「多：1」を使う必要のある状況は・・・ちょっと僕は思いつきません。

むしろ、この「多：1」パターンは、やたらと使いまくるとただの解りにくいインターフェイスになってしまう危険性があると思います。

どこを押せばページが遷移するのか、不必要に選択肢が多い場合、使っている側で「ボタン：機能」の対応を理解していくのが困難になると予想しています。

例えば、
再生ボタンと停止ボタンと取り出しボタンが、各2個ずつ、見た目もそれぞれバラバラで、いろんな箇所に配置されてるDVDプレイヤー。

どこを押したらどうなるのかを理解するのがまず大変そうです・・・。

で、何が言いたいかというと

Webコンテンツのユーザーインターフェイスの使いやすさを考える時には、身近なもののインターフェイスがどういう思想で設計されているのか、
もしくは、定番のUIデザインの根底にある狙いや、なぜ定番となっているのかまでを考えてみないとイケナイなー、という事です。

実際の案件で、個人的な意見として「これは使いにくいでしょう・・・」というデザインのモノがあったのですが、
それがなぜ、使い辛いのかを説明することができず、議論にすら挙げられなかった事があります。

そういう時に、なぜ自分が使い辛いと感じたのかの理由が把握出来ていれば、解決策も提案できますし、
そうなれば皆で再度検討しなおす事もできますよね。

こういう、コミュニケーション能力を上げるための視点って、大事だなと痛感しました。

今日はお仕事で活用したWebサイトやブログにつぶやきを表示する【twitter ウィジェット】について書いていこうと思います。

【1 】まずはWebサイトにアクセス
Twitterにログインしている状態で、ウィジェットを配布しているページへ移動。

Twitter / ウィジェット

↑ここから各種設定を行いウィジェットを作成。
MySpaceやFacebookに表示するためのウィジェットも紹介されていますが、
ここでは汎用的に使える「自分のサイト」をクリックします。

【2 】プロフィールウィジェットをクリック。

【3 】プロフィールウィジェットをカスタマイズする。
ここでウィジェットの設定を行います。
（1 ）Twitterユーザー名を入力
ここでは、前から気になってはいるけどなかなか勇気をだしてお店に入ることができずにいる会社一階にあるアクセサリーショップ『DAgDART』さんのつぶやきを設定してみたいと思います！

気になった人は足を運んでみてください☆.。.:*・゜☆.。.:*・゜

アクセサリーショップ『DAgDART』

（2 ）カスタマイズ
■カスタマイズ
●最新データを取得?
つぶやきを自動読み込みさせたい場合は「はい」をチェック。
●スクロールバーを表示?
表示が一定数を超えた際、スクロールバーを表示させたい場合は「はい」をチェック
●ツイートの表示方法
一定間隔でつぶやきを読み込みたい場合は「Timed Interval」を選択。そこで表示される「Loop results?」ではつぶやきをループして表示させるかどうか、「Tweet Interval?」では読み込みの秒数を指定します。適宜つぶやきを読み込みたい場合は「Load all tweets」を選択しましょう。
●表示するツイート数
つぶやきの表示数が設定できます。
●プロフィール画像を表示？
つぶやきにアイコンを表示させたい場合はチェック。
●投稿時刻を表示?
つぶやきに時間を表示させたい場合はチェック。
●ハッシュタグを表示?
ハッシュタグを表示させたい場合はチェック。
●表示するツイート数
つぶやきの表示数が設定できます。
●プロフィール画像を表示？
つぶやきにアイコンを表示させたい場合はチェック。

■デザイン
●外枠の背景、外枠の文字、ツイート投稿欄の背景、ツイートの文字、リンクの色がカラーコードで指定可能。カラーコードの右側にある四角の枠をクリックして色を選択することもできます。

■サイズ
●ウィジェットの大きさが指定できます。自動で幅を調整したい場合は「auto width」をチェックしましょう。
※ただし入力したサイズはウィジェットサイズはサイトに設置するまでプレビューされません。

設定を変更したら下段の［Test settings］ボタンを押せば右側にプレビューが表示されます。設定が完了したら［完了＆コード取得］ボタンをクリックしてください。

（3 ）コードを取得して張り付ける
画面にコードが表示されるので、コピーしてHTMLに貼り付ければ完了です。

やってみれば以外に簡単！興味を持たれた方は自分のブログにツイッターのつぶやきを表示してみてはいかがでしょう？アクセス数がぐっとあがるかも？？

サンプルは下記を参照ください。

はじめてのブログということで今後やろうと思っていることを書きます。

cakephpの理解をもっと深め業務で使用できるようになりたいと思ってます。

cakephpとは
PHPで記述されたwebアプリケーションフレームワークです。

cakephpを使うメリット
1.コードを繰り返し書くことを極力避けることができる
2.MVCアーキテクチャによる、機能の分離
3.将来的な拡張、変更に対応しやすい
4.チーム作業を効率的に分担できる
5.Ajax、その他の最新技術を反映させやすい

業務で使用するにあたって最も重要な3,4の部分をあまり理解できていないので今後重点的に勉強しようと思っています。

cakephp
http://cakephp.jp/

最近サイトデザイン集を見ていたら、
ページが存在しない時に表示される「404」ページだけ集めたものがありました。
たしかに載せる内容もないので、
ここぞとばかりにグラフィックに凝っていたり、
他ページにリンクを張ってこのページ自体も利用したりとサイト色の凝縮した自由な空間になっていました。

とくに珍しいことではないのですが、
作っているもののなかに、ごく自然な形で遊びの部分を入れる方法はどのようなものがあるのか、と
ふと思うきっかけになりました。

当然モノにもよりますし、読み物として考えたら、やりすぎたものはいらない要素なのかもしれません。

でも、人が考えたあとというか、そのようなところから人間味のような部分が伝わってくるようにも思います。
サイトを閲覧していて面白みを感じる部分です。

見ていて何か上手だなとか、やり方がかっこいいとか、
丸々は真似できないにしろ、考え方などを小さなところでもいいので活かすことが出来たらいいと思いました。

さて。今回は、heightLine.jsに次ぐ便利jsを見つけたので紹介します。

複数のブロック要素の高さを揃えてくれるJavaScriptライブラリ「fixHeight.js」

このｊｓでは私がほしくてたまらなかった機能がついてます。

「指定した個数ごとにブロック要素の高さを同じにする」

要はこんな感じの不満があったわけで。

heightLine.jsは高さを揃えたいボックスの親要素に「heightLineParent」というクラス名を付けると、全部ごそっと最大値の高さに揃えてくれる機能がついています。

ところが、ボックス内の内容量に大幅なバラつき（画像があったりなかったりなど）がある場合、
内容が少量のボックスでも最大値の高さにされるとこれまた不自然です。

そこで、heightLine.jsは揃えたい要素をグループにする機能が付いています。
（グループにしたいボックスに「heightLine-ほにゃほにゃ」とクラス名を付ける）

と・こ・ろ・が デザインの段階でボックス個数が決めうちであればこれで問題ないのですが、
更新作業でこのボックスが増減する場合、いちいちクラスを付けて付け直してって相当めんどうです・・・

そーこーでー このfixHeight.js

ボックス群の親要素に「fixHeightN○」（○には数字が入ります）というクラス名を付けると、
何個ごとにボックスを揃えるかが指定できます。

例の図のように2カラムずつ揃える場合は、「fixHeightN2」となります。

<div class="fixHeightN2">
    <div class="childbox">
    	内容内容内容内容内容内容
    </div>
    <div class="childbox">
    	内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容
    </div>
    <div class="childbox">
    	内容内容内容内容内容内容内容内容内容内容内容内容
    </div>
    <div class="childbox">
    	内容内容内容
    </div>
</div>

他にも、親の直属の子ボックスでなくても、その子ボックスの中の要素（孫？）同士を揃えることが出来る機能も付いているようなのでこれは便利です！！

複数のブロック要素の高さを揃えてくれるJavaScriptライブラリ「fixHeight.js」

最近写真が楽しくて、よくパチパチ撮ってるんですけど、やはりいかんせん構図とか色々とセンスが無いわけで。ゆえにトレンド礼讃主義音楽家的なノリで素材は悪くともプロダクションでごまかしてしまえな感じで色々加工したりして遊んでる今日この頃です。

トイカメラ風がやはりかわいくてよいので
Photoshopチュートリアル ミニチュア模型を撮影したような写真に加工する
このへん参考にしながら。

↑一昨日天橋立行った時の写真、どうでしょ？

以上、「へなちょこフラッシャーPSD職人化計画。」でした。

CSS３を使ったらマリオがとんでもないことになってしまってた。

WEBクリエイターボックスにこんなサイトが紹介されてました。（Pure CSS animated 3D Super Mario Icon）

HTMLとCSSだけでマリオを描いてクルクル回してしまっています。CSS３の「-webkit-transition」などを使って表現しています。回るだけならよくあるのですが、Safari５で是非マリオを見て、ロールオーバーして下さい。すごいから。HTML５も少しずつその存在が身近になりつつある気配を感じ、CSS３と合わせて実装できれば、WEB表現の幅はグンと広がりを見せる可能性を感じます。マリオの例は極端ですが、ソースコードを見ると空DIVの集合体なのでWEB標準からすると逆行してますね（笑）。意味のあるコーディングと効果的な表現のバランスも必要かなと。

ただ、一般的に対応ブラウザが普及するのがいつになることやら。このマリオもSafari５でないと完全な状態が見れませんし。JSでブラウザ対応するなども考えられますが、どこまでフォローの対象とするか、クライアントのご予算、クライアントへの説明などいろいろ検討しないといけなくなりそうです。

いずれにしろ制作現場は大変だ。。。

やっとの思いで手に入れたiPhone4！
快適です！

この2年間使い続けたiPhone3Gがただの文鎮に見えます。
一番のポイントはスピードが圧倒的に速いです。

昔NECのキャッチコピーに「速さは力」とありましたが、
このiPhone4さえあれば、怖いもんなしです。

最近は、iPhone4が大活躍なので、iPadがYoutube専用マシンとなってしまいました。
これでは、モッタイナイのでなんとかiPadにも活躍場を用意しなくてはと考え
メモを取るメモを見る専用マシンにするため不要なアプリを削除してスッキリさせました。

主力で使うアプリは「エバーノート」で、
クラウド上にテキスト・ウェブページ・写真などを保存するサービスです。

エバーノートが便利なのはデータがクラウド上にあるので、
会社PC・家Mac・iPhone・iPadで確認ができて、
自動でインデックスもされるので検索も可能です。

昔からメモを取るのが下手くそで、あとから読んで意味が分からないことが多々・・・
iPhone・iPadで、常にメモを取ることを習慣づけようと思います。

ようやく納品ラッシュが収束して、やっとブログ書ける精神的余裕が出てきた所のtak-tです。
いやー、大変だった。

そんな納品ラッシュの中でも、一応色々とニュースを拾い読みはしていたのですが、ボチボチ、次のネットの方向性を表すキーワードが出揃って来ているような気がしているので、個人的にまとめてみます。

HTML5

ま、これはもう何も言わなくてもいいと思いますが、HTML5の実験的サイトも色々と立ち上がってますし、策定も進んで来ては居るようですが、同時に不穏な情報も色々と出てきていますね。

Google のビデオフォーマットとか、
Web SQL の策定停止とか、

制作サイドとしては、HTML5でユーザーエクスペリエンスの向上が見込めるのは確かだと思うので、後はどれだけ制作スピードを稼げるのかが気になります。できるだけ、ブラウザ毎に挙動違うとか、止めて頂きたい・・・。

ビデオフォーマットに関しては、H264押しのappleに対する嫌がらせにも見えますが、利権周りがクリアなwebM規格に流れて行きそうな気がしています。圧縮的には、H264の方が優秀な気がするのですが、どうなるんでしょうか。

タブレットデバイス

日本では今週金曜日に発売のiPadをはじめ、DELLもHPも出すらしい、タブレット型デバイス。これがホントに一般層にも受け入れられるのかどうかはちょっと懐疑的なんですが、PC操作がキーボードとマウスで定着してから何十年、ようやくマウスから解放されるPC的なモノが出てきますね。

このデバイスだと、従来のマウスをウロつかせながら閲覧するスタイルのコンテンツが成り立たなくなるので、Flasherとしては今後もしこのデバイスが広まっていった時を考えて、今からどう作るべきか（ユーザーの操作をどう誘導するか）を想像して置かなければならないなー、と思っています。

Google TV

前の記事でも書きましたが、どうやら話は本格化しているらしいですね、Google TV。

しかも、メーカーとしてソニーとLogitechが協力関係にある、と。

紹介ビデオを見る限り、ユーザーが見ているコンテンツがテレビコンテンツなのか、ウェブコンテンツなのか、意識できないくらいにシームレスに視聴体験を提供できるシカケを作っているみたいですね。
既存の「ウェブも見れますテレビ」とは違う、と、自ら公言していますし。

もしこれが本当なら、ユーザー体験としては新しいものを提供できるのではないのかな、と思ってます。

リアルタイム

これも今更な感じですが、twitterに始まり、今ではwoopraというサービスが始まっています。

woopraは、簡単に言えば「リアルタイムのGoogle Analytics」で、テレビの視聴率の如く、今、そのサイトを見ているユーザーの数と地域と、その他情報がリアルタイムに観測できるというサービスです。

5年前くらいまでは、ウェブとテレビは全く違うメディアだ、という見解がほとんどだったと思うのですが、今やリアルタイムメディアとしてテレビに近づいていくという側面も無視できない状況なのかもしれませんね。。。

woopraに関しては、使い方や新たなサービスの形を自分が想像出来ていないのですが、「リアルタイムメディアとしてのウェブ」については、色々と思考を巡らせておく必要があると思っています。

クラウド特区

4月の日経新聞のトップに、総務省が日本に「クラウド特区」なるものを、北海道か青森に作るとありました。

海外では、データセンターを増築する時は貨物コンテナのようなものを新たに設置してその中にサーバを置くらしいのですが（温度調節設備アリで）、日本でこの手法を行うと、建築法的に色々と余計なお金が掛かるそうで、それを緩和した、特別区域を作りましょう、と。

「別に海外のデータサーバを使ったらいいじゃない」、とも思うのですが、例えば日本が今後クラウドコンピューティングを利用して国民のデータを管理するような事を考えると、大事なデータが外国任せになってしまうと、一体何をやられるのか解ったもんじゃないですよね。
実際、アメリカでは犯罪抑止のためなら個人データを見れるとか見れないとか（情報不確ですが）。

日本はクラウド技術に関しては出遅れているらしいんですが、一体どこまで巻き返しできるのか。　気になります。

まとまらないけど、まとめ

と、色々と気になってるキーワードを書き連ねてみました。

まだ上手く説明できないのですが、これらのキーワードは、どれも単独で存在しているものではなく、お互いがお互いを助長しあったり、抑制しあったりしながら、今後のウェブの方向性を決めて行くんではないのかな、と、勝手に妄想しています。

クラウド特区に関しては日本としては切羽詰った問題ですが、それ以外は、個人的には非常にワクワクしています。
あらたな体験を提供できる可能性があるということは、なんと楽しみな事でしょうか！

個人的には、AS3以外の言語をちゃんと勉強しようとしているので、何の言語を選ぼうか悩み中です。

HTML5でJSかなぁ、、、
それとも、Google App Engine でJavaかPythonかなぁ、、、
はたまた、iPadでObjective-Cか、もしくはAndroidでJavaかなぁ、、、

どれを選べば勝ち組に近づけるのやら。

こんばんは、shinです。

言葉から連想する。
作業のやり取りなどでちょっと貧困かなと思う時があります。
形にするのはこちらなので、なかなかつかみきれないととても苦しい思いをします。
そんな時ほど間違わないようにとか、聴いた言葉を強調しすぎたりと、
またそうならないようにと、作るものが消極的になってしまったり、
思い返せば、見当違いなことをしていたなと、反省は多々です。

テーマは、ほぼ毎回自分にとって近いものではないので、
いろんなところから検索しては、イメージをかき集めて膨らませていくことがだいたいなのですが、
ほかの人が何をどのように見ているのかが見えてきたり、
作業を始める前とは違うものの捉え方をしているのに気づきます。

どうしても、完全に以心伝心とはいかないものなので、
言葉自体に引っ張られすぎぬよう要望を何度も自分の中でかみくだいては、
理解する能力、またその速度、多を吸収する能力も磨いていかなければなと。
いつでも相手の想うそれ以上のことは作れていたいとつくづく思います。