定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)
いやー、この問題は本当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの？老害なの？」 とか言わないで欲しい。この問題、本当に難しいんだよ！ ■ １度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり
Retinaよりも大切なもの - ザリガニが見ていた...。
その後の関連日記あり Retina＋Mountain Lionのスクロール - ザリガニが見ていた...。 Retinaのほんとうの力 - ザリガニが見ていた...。 Retinaなら3840x2400の超広大なデスクトップを体感できる！ - ザリガニが見ていた...。 MacBookのRetinaディスプレイを縦2880pxにした壮観な眺め - ザリガニが見ていた...。 発注 WWDCの翌日、MacBook Pro Retinaモデルを発注してしまった。2880×1800の魅力にとり憑かれてしまったのだ。発注したモデルは... 2.6GHzクアッドコアIntel Core i7プロセッサ メモリ16GB フラッシュストレージ512GB 値段は今まで使っていたMacBook2台分以上だが、このスペックなら今後5年以上はそのまま使い続けられるのではないか、と考えての発注であった。 実際過去
何故、エンジニアはUIのセンスがないか。
何故、エンジニアはUIのセンスがないのか、という自分にも当てはまるようなことについて書いてみる。 まずエンジニアがダメなUIを作ってしまう理由について、いくつかの仮説を立ててみる。 1.その画面を作るエンジニアは全てを知りすぎていて、もはやわからない人の気持ちがわからない説 2.エンジニアはITリテラシーは高いけど、自分ができることを人に理解できるように説明するのは下手説 3.技術的に実現する方に興味が偏って、ハナからUIの使い勝手に興味が無い説 4.国語力がない、自分が実現する文脈を表現するのはできるが、ユーザーの文脈に配慮した言葉を想像する力が無い説 5.仕様書を読まない、人の言う事を聞かない説。例えばOSが定めているユーザーインターフェースガイドラインに従わないので、UIパーツが意図した使い方をしておらず統一性に欠ける。 6.わかりやすい色や文字、レイアウトに関する知識が無い。センス
僕がユーザビリティに興味を持ったのは色弱だからだろうという話。 - 日々、とんは語る。
僕がWebに触れたのは主に2003年からで、すぐにWeb制作に興味を持ち、今日まで勉強し続けてきたのですが、多くのWeb技術の分野の中でも、特にユーザビリティに興味を持ったのはなぜなのだろうか。 そんなことを、最近ぼんやり考えていたのですが、最近になって僕がユーザビリティに興味を持ったのは、自身が色弱だからだろうという単純な結論に至りました。 ユーザビリティはデザインの一種で、これが正解という答えがない分野です。配慮に配慮を重ねても、なかなかユニバーサルデザインの実現は難しいものです。 UD を実現するには、バリアに気付く必要がある。 『障害・バリア』と呼ばれるものは、目には見えづらいものです。バリアに気付くためには、障害者の目線になるのが最も確実な方法だと言われています。 中学生の時に、ペアを組み、片方が目隠しをして目的地まで案内してもらったり、車椅子に乗って学校の中を移動してみたりする
「マニュアル」をデザインする際に参考になる書籍、サイト、WEB記事などを教えてください。…
「マニュアル」をデザインする際に参考になる書籍、サイト、WEB記事などを教えてください。 特に書籍が知りたいです。 Webサービスの操作マニュアルなどをつくる機会がちょくちょくあるのですが、そもそもマニュアルを作成したことがあまりなく、内容をディレクションしてくれる人もいません。 そこで、マニュアルのレイアウトなどのビジュアル面だけでなく、構成・アプローチなどのディレクション的な部分も勉強できる書籍などをご存知の方がおられましたら教えていただきたいと思います。 Webサイトや記事でも結構です。 ただし、以下のサイトは何度か拝見しているので除外とさせていただきます。 http://www.laplace-lab.org/
良いプロトタイプ、悪いプロトタイプ - Feel Like A Fallinstar
特にネット系のマーケティングを行うにあたっては避けて通れないプロトタイピングや仮設検証のプロセス。 Amazon、Microsoft、Googleと言った企業も、大々的に取り入れている手法です。 ただ、このプロトタイプ手法も、やり方をちょっと勘違いすると、単にゴミを作るプロセスで時間を無駄にしただけに終わってしまいます。 （というか、そういうのを何度も見てきました・汗） 今日は、そんな「悪いプロトタイプ」と「良いプロトタイプ」の違いなどを少しばかり。 悪いプロトタイプを作ってしまう人は、こんな罠に落ちている まず、悪いプロトタイプについて。 もう負けパターンに陥っている人やプロジェクトの最大の特徴は、この1点に集約されます。 思い切った早期調査ができず、無駄に凝ったものを作ることに時間をかけてしまう あらゆる開発・リリースにはスケジュールがあり、マイルストーンがあり、リソースは有限です。
Webカメラを使った視線プロット - ならば
ウェブサイトのユーザビリティテストの方法にはユーザの視線を可視化するものがある。gaze plotと呼ばれる方法はユーザの視線の軌跡を記録し、注視した部分に円を描画する。円内の番号は注視した順番を表し、円の大きさは注視時間の長さを表す。この結果から、ウェブサイトのどの部分がどの順番でどのくらい注目されるのかを知ることができる。 面白そうだったからウェブカメラとオープンソースの視線追跡ソフトで簡易なgaze plot環境を作って遊んだ。対象をウェブサイトに限らずに、いろいろ試した結果一覧。 はてなトップページ（はてな） Google Chromeテーマ選択画面（https://tools.google.com/chrome/intl/ja/themes/google.html） 英文（Eye movement in music readingの冒頭を真面目に読む） 楽譜（ラフマニノフ「ピアノ
全てのIT・Web関係者に見つめなおして欲しい「Don’t Make Me Think」 - Feel Like A Fallinstar
”Don't Make Me Think” 訳すと、「いちいち私に考えさせるな！ボケ！」といったところでしょうか。 これは、2001年にSteve Krugが出した書籍の名前なのですが、この「ユーザにいちいち考えさせない」ことを忘れているか、いないかがソフトウェア・Webサイトの勝負を分ける最も大きな分岐点の1つです。 人間は日々の生活の中で、いちいち物を操作したり情報を見るたびにあれこれ考えたくなんてありません。 ユーザをつまらない操作やナビゲーションで考えされればさせるほどストレスは増大し、企業への信用は急激に失われます。 今日は、この”Don't Make Me Think”について、 如何にユーザが考えることを嫌うか 「考えさせない」とはどういうことか を、これまで見てきたユーザ検証の結果なども交えて、少しばかり書いてみようと思います。 あらゆる「無駄な」思考が、ユーザを苛立たせ、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA