何故、エンジニアはUIのセンスがないのか、という自分にも当てはまるようなことについて書いてみる。 まずエンジニアがダメなUIを作ってしまう理由について、いくつかの仮説を立ててみる。 1.その画面を作るエンジニアは全てを知りすぎていて、もはやわからない人の気持ちがわからない説 2.エンジニアはITリテラシーは高いけど、自分ができることを人に理解できるように説明するのは下手説 3.技術的に実現する方に興味が偏って、ハナからUIの使い勝手に興味が無い説 4.国語力がない、自分が実現する文脈を表現するのはできるが、ユーザーの文脈に配慮した言葉を想像する力が無い説 5.仕様書を読まない、人の言う事を聞かない説。例えばOSが定めているユーザーインターフェースガイドラインに従わないので、UIパーツが意図した使い方をしておらず統一性に欠ける。 6.わかりやすい色や文字、レイアウトに関する知識が無い。センス

Webのエンジニアにはどういうスキルが一番必要か？という話を考えてみた。 例えば、C言語やUnixの経験が長く、オブジェクト指向も理解していたとしたら、PHPから始まり、Rubyなどの理解は決して難しくないだろう。 では、それだけの経験で一線級のWebエンジニアとしての信頼が置けるかというと、ちょっと違うような気がする。 考え方のベースは、 「Webは、要するにテキスト処理であることが多い。だから難しい」 ほとんどの事がHTTPプロトコルを通じてテキストデータとして情報が、なんのネットワークの制約もなく流通する。つまり、HTTPヘッダを含むテキストの操作でセキュリティホールを作り、それが世界のどこから攻撃されるかわからない。 また、 同様に世界中からアクセスが集まることがありうるので、回りくどいテーブル設計をしてしまうと、あっというまに破綻してしまうこともある。 そして、 基本的にマルチア

受託をメインでやってる人の中には、「お客様から頼まれないと、自分が動く価値はない」と本気で思っている人がいて、そう思うのは自由なので良いんだけど、本人は技術があると思っていて、実際にあるのかもしれないけど、周りからは見えないというのは損だと思うんです。 ある本に、インターネットは自分で立候補することが大事だ、なんてのが書かれていました。立候補しなければ、誰も声をかけてもらえない世界だと。 誰かが何かをやりたいと思って、実現のスピードや実現可能性を考える時に、そのスキルを持っていることが明確になっているところに話が行くのは割とシンプルにある話で、僕も例外ではなく、モバツイをやってる関係上、ツイッターに関する案件のお話をいただいたりしている。 人の余裕があれば是非お手伝いしたい気はあるのだが、ネットサービスは基本、受託案件をやる余裕はないし、そもそもリソースが少ないので、多大な機会損失をしてい

今しか書けない、かつ、書ける人が少ないと思うので、書いておく。 僕のアカウントは、twitterのオススメユーザーというのに登録されている。 オススメユーザーというのは、新規ユーザーが登録した時に表示され、まずとりあえずこれらの人から初めてみてはいかがですか？というリストである。 大変ありがたいことに、このユーザーに登録されたが故に、現在のフォロワーの数は、２０万人を突破していて、ちょっとしたメルマガメディアを個人で持っているような感じとも言えなくもない。 ただ、最近、ツイッターがバブル状態にあるが故に、このオススメユーザーのフォロワ数を、まるでその人の実力が如く、過大評価されている向きがあるので、ちょっとだけ触れておきたい。 例えば、 「あたかも、Ａさんだから２５万人のフォロワーを集めました」 という文章を見かけることがあるのだが、まああっている部分もあり、間違っている部分もある。 何故

モバツイ以外にも実運用で回してるEC2な人たちは結構いると思うのですが、参考までに。 モバツイッターがAmazon EC2の人柱をやってくれている モバツイッターがAmazonEC2に移行しようかなとのこと。 さっそく性能問題にぶち当たったらしいし、ナイス人柱。 前にあるイベントで、EC2を活用されているHeartRailsの方にモバツイの構成をEC2に移転したらどうなるか？みたいな話をお伺いしたら、すぐ8万円/月ぐらいに構成になってしまう、と言われたのですが、大体、どんぴしゃな感じでした。 （追記：なお個人でWebサービスをスモールスタートする場合は、サーバの運用知識がそこそこある前提で、まずは自宅サーバから運用すると良いです。月間600万PVぐらいまでなら、HP ML115G5 + Phenomでこなせるハズなので。その辺についてはまたいずれ書きます。） ■EC2とは？ 既にご存じの方

このblogを始めた時には当然Doblogで書いてる人のblogも見てたけど、いつからかなぁ。ほとんど見なくなったのは。 こんなカタチで、有名blogサービスが一つ消滅してしまうとわ。。。 Doblogのサービス終了のお知らせ | お知らせ | NTTデータ 【故障内容の詳細】 故障内容 （1）データベースサーバーのRAID5構成のハードディスク2本が同時に破損 1本の破損であれば残りの5本から情報を再構成できますが、破損が2本に及んだためデータを読み取ることが出来なくなりました。 （2）更にバックアップ用のサーバでも障害が発生 これによりバックアップのデータにも異常が生じたため、皆様の記事情報を復旧することが困難な状態となりました。 だからRAID5は信用できないと(w F's Garage：RAID5は全然信用できない。 RAID5は、システムの信頼性を上げる技術じゃなくて、「容量を増

FirefoxやSafari,Chromeが出てきた現状、プロのWeb屋の中では、Internet Explorerだけの対応をもとめられて面倒くさい！と思うことは多々あります。 ただ、半分冗談で「IEクソ」と思う人と、本気で「IEクソ」と思ってる人の両方が存在している可能性があるので、IT系特有のネガティブな教育のせいで後者に洗脳されてしまってる人がもしいたら、そういう人に送りたいエントリー。誰向けかというと、主に対象は実装屋さんなのかな。 知っておいて欲しい事は 「IEがあったからこそ、今、僕等はメシを食えているかもしれない」 ということ。 そして、 「僕等の本当のお客様は、IEを使い続けているし、これからも使い続ける可能性が高い人たち。お客様がブラウザの種類などを意識せずともインターネットにアクセスしてもらえる環境を維持することが、プロのWeb屋の使命である。」 ということ。 過去、

先に補足を追記します： 僕のスタンスをはっきりしておかないとFlashという単語などの想定しないところで思考がひっかかる人が出てきそうなので書いておくと、 ・これから以下に書くようなFlashを作っていた人でもあります。 ・FlashやAdobe(Macromedia)プロダクトが大好きです。 ・現状の環境で素晴らしいUIを実現するにはFlashとJavaScript(Ajax）の適材適所での利用は不可欠だと思っています。 以上のことを踏まえた上で読んでいただけるとありがたいです。 こんな記事を見つけた。 次世代画像クルージング技術「ImageCruiser」、楽天市場で実験開始 :: SEM R 色検索とか地図検索とか作っていろいろ思うところが多い者としては、行く末が気になります。 予想を裏切って欲しいという意味で、成果があがることを期待しつつ。 が、どうしても気になっていて、これ画面ね

先生！何故、この構造が悪なのか、どうしても理解できません！ 全てを内製で賄うコストより、トータルのキャッシュフローが高くなれば何も問題ないハズなのだから、別に構造の問題ではないのでは？ 元請けの給料が高すぎて、お金の再配分がうまく回らないというのであれば、内製にしたら余計マズイじゃん。みんなが同じ給与体系で働いてやっていけるの？ 元請けの方が給料高いってのは、単純に儲け杉って話だと思うけど、誰も自分の給料下げようとは思わないよね。 利潤を追及する企業活動としては収入を増やすかコストをさっぴくか・・・。この先、収入が増えるようには思えないので、外部コストにしわ寄せが。あぁｶﾅｼｽ。 もちろん内製で効率化してやっていけるなら良いけど、全部じゃないよね。 自分たちだけがエンジニアリングに特化して、冗長で手間のかかる単調な作業だけをオフショアにする？ 会社が特定の役割に特化していくと、役割外の業務

「ページング」と「写真切り替え」のUIは、もっと良い表現方法があってしかるべきだと思う。 特に、前にミクシィ社の会社訪問の写真でも思ったが、CNET Japanのフォトレポートページはヒドイ。 フォトレポート：来た、見た、開けた--「MacBook Air」開封の儀 MacBook Airやミクシィというネームバリューを生かした、PV稼ぎ商法としか思えない。 まぁ現実には、如何に早く公開するか？ってのと、現状のCMSがそういうことしかできないからってのが正解なんだろうけど。 ページを切り替えるのが面倒すぎて、疲れてしまう。 なんで写真を見るだけなのに、面倒な気持ちにならなきゃいけないんだろう。 写真はサムネイルを並べてクリックするというのも面倒くさい。 現状写真切り替えで、一番楽しいのは、iPod touchや、Macに搭載されているカバーフローでしょう。僕はPicasaのスクロールUIは

mixiのナビゲーションって決して最初からよくできていたものではないと思っていた。 例えば、未だに残っているのが、日記の編集確認画面 １．自分の日記の画面から、この日記を変更するためのリンクが 「編集する」となっている。 ２．次に編集のフォーム画面から、確認画面に行くラベル。 「入力内容を確認する」 ここは問題ない。 ３．しかし、最後の入力確認画面のsubmitのラベルがおかしい 「編集する」　　か、「やめる」 このラベルの機能は以下の通りです。 「編集する」は、「変更を確定させる」 「やめる」は、「前の画面に戻る」 僕はこのラベルに対して思ったのは、 「編集する」は、「前の画面に戻る」 「やめる」は、「変更作業そのものをやめる」（Windowsで言うならダイアログを閉じる） という印象を受けました。 つまりどこにも確定ボタンがないということを、二つのラベルを見比べて知り、より可能性の近い

いや、確かに都合良く使われるのが嫌ってのはわかるんだけど。 hemiolia.comさんの そろそろWeb標準についてひとこと言っておくかより、 >と思ってたらなんかyuuさんの手による素晴らしい記事ｷﾀｰ。 >ウェブ標準、それは状況や環境に左右されない情報伝達を >実現するためのもの | Web担当者Forum >今現在ビジネスとしてWebに関わる立場から認識すべき >「Web標準」についての決定番的な内容と言ってもいいかもしれない。 yuuさんの記事は、誰かがぷくまってたのをmovatwitter経由で、電車の中から読みましたよー。 で、そこに対する反応の話で、 >ちなみにyuuさんの記事に対するはてブコメントをチェックしてみたら >「これはひどい」タグを付きでこんなのがあった。 >「この記事を読むと「Web標準」というフレーズは「Web2.0」と >同様に実像が曖昧なただの宣伝文句の

人は自信を持った人に影響されやすい。その人が必ずしも適切なことを言っていなくても、こちらに不安のかけらがあればあるほど、その自信につられてしまう。 どこかで心に疑問符を持っていたとしても・・・。 矢野勉のはてな日記のJ2EEのこれからは... より。 ～引用～ Ruby on RailsってJ2EEの大部分を必要としない層というスキマをぴったり埋めてくれるものなんですよね。そりゃビューにはRubyで書いたロジックが山盛りてんこ盛りだし（しかも「別に問題じゃない」とか解説書にも書かれてるし）、DBのカラム値がビューと直結してたりする（DBのカラム幅がビューでのバリデーションに使われたりとか）。Javaで発展してきたMVC分離からすれば非常におおざっぱな世界ですよ。 でもとても楽です。この楽しさはプログラムには非常に重要です。目に見える範囲にすべてが収まっている感じというのでしょうか。自分で制

確かに、すごくわかりやすい言語であることは間違いないんですが、とっつきやすいこと＝低レベル、ではないのです。 多分、コーダーなる職業の人本人もすごく勘違いをしているかもしれませんが、HTMLとは、 「文字や画像のオブジェクト配置ルールを記述するブラウザレイヤーで動くプログラム言語」 だと思うのですが、言葉の定義はともかく、それ周辺の基本的なことを認識できてなくて、徹夜しまくっているのがWeb制作業界の実態ではないかと。 （※ただ、やってくれるから黙って甘えてる部分は否定しません（笑）） HTMLがとっつきやすいのは、「価値が低いこと」なのではなく、単純に「素晴らしすぎる言語」だからなだけで、それに甘え、「誰もできるだろう」、とか、「すぐできるだろう」とか言う考えの下に、工程上からむちゃくちゃなスケジュールをしか作れないようなWeb関係者は考え方を変えてください。 紙と鉛筆わたして、画家とか

これまでに書いた、このWeb内の情報設計系エントリをまとめてみました。とりあえず「Web系」カテゴリと「会社活動」カテゴリから抽出しました。 ■概念論 UIに価値を見出せない人は、コンピューター素人 Webの設計は誰がやるの？ Webの設計は誰がやるの？その２ Webの設計は誰がやるの？その３ 古い常識の壁、今の常識 アーキテクトと言う人種 情報デザインって何だろ。 コラボレーション UIはシステムの一部です。 Web制作って大変だよね。 テキストライティングも情報設計のうち。 ■方法論 ベストなWeb画面（アーキテクチャ）の設計ツールは？ インターフェースが使いにくいか調べる方法 ユビキタスID社会への準備、ヒント 使いやすさのためのデザイン デザイナーの作るHTMLを壊したくないWeb開発者のために 何故、サイボウズの画面は情報が目に入ってこないのか？ こういうツールないですか？ ユー

高齢化社会は、高齢者主導の新しい消費の時代とも言われますから、おじいさんが家でじっとしてるから不要だというわけではないと思うのですが、いかんせんITの方が高齢者が使えるほど進歩していないです。 フリーペーパーブームが意味するもの。のkojiro kisiさんのコメントへのレスです。またまた文章が長いのでエントリに起こしました。 障害者や高齢者、いわゆる本当の意味でのアクセシビリティというのは、最も「リッチコンテンツ」である必要があります。 クライアントテクノロジとしてFlash的なものや動画的なもの、XMLという汎用データ流通技術,ユビキタス回線インフラなど、必要な基本要素は、徐々に揃いつつあります。それらを組み合わせ、上質のヒューマンインターフェースが組み合わさった究極形にこそアクセシビリティの実現があるのではないか？と思っています。 分野を変えて考えると、ロボットを機械の側面から見ると

妙なカスタムタグよりも先にHTMLやJavaScriptを書きたくなる人には、Webフレームワークは厳しい？ ASP.NET Webアプリ開発の裏事情 > エピソード9：「モバイル対応」と闘う ある意味、問題点はこのリンクに集約されているかな。Strutsを使ってて感じるのは、 ・今まで当たり前のようにできていたことが、できにくくなった。 （正確に言うと、統一感を得る代わりに、ユーザビリティ主体にできていた個別のメッセージハンドリングやリンク制御とかが、Strutsのアーキテクチャに従った結果、自在に制御するのが「面倒くさい」。設計の問題なのは重々承知で、あえて書くが。） ・タグが覚えられない。HTMLを書いたほうが速いので、もどかしい。 （Strutsのattribute規則は直感的でないと思う。スキーマに機能を無理やりあわせこんだ感じがプンプンする。） ・同様にJavaScriptとH