サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ノーベル賞
ishibashi.tumblr.com
“中級者に合わせてデザインせよ(About Face 3) 1. 初心者が苦痛を感じることなくすみやかに中級者になれるようにすること。 2. 上級者になりたいと思っている中級者の前に障害物を置かないこと。 3. 何よりもまず、永遠の中級者がその位置に留まる限り幸せでいられるようにすること。” アップルの技術文書 « ツール工房 覚書 (via ishibashi) Tumblrでこの「中級者のためにデザインせよ」というquoteが大人気。実際いいスローガン。 クーパーは「永遠に初心者のままでいたいユーザーはいない」とも言ってる。「初心者のため」と称したヌルいデザインに平手打ち。 こうも言ってる。イカす: Design principle: Imagine users as very intelligent but very busy. ユーザーを啓発・教育するようなデザインを心がけず、ユー
中小規模のECサイトについて言えば、個別のECサイトでID管理する(簡単に言えば「メールアドレスやパスワードを管理する」)のが当たり前だという時代は終わるかもしれません。 これから個人情報保護法制が強化されていけば、中小企業にはIDシステムの保有コストが重い負担になっていきます。もしそのコストを払わなければ、潜在的な事業リスクを抱え込むことになりますし。 中小ECサイトには自前でIDシステムを保有するかわりに大手ECサイトの決済プラットフォーム(Amazonログイン&ペイメント、楽天らくらく決済、ヤフー簡単決済など)に乗っかるという手があります。 (※ちなみにモールへの出店とは異なる仕組みなので誤解なきよう。ざっくり言えば「アドレス帳つきのペイパル」みたいなものです。ペイパル決済みたいな画面フローで決済と配送先の指定ができる。つまり決済や配送先の情報をキーボード入力する必要はなく、何度かク
マルクスって残念な男。デザイン論的にいえば、問題設定(哲学)はよかったのに、設計(経済学)がダメだった。 「もしマルクスがデザイン思考を知っていたら」20世紀の歴史も、現代も、様変わりしていただろうな。いい方向に、という意味ですよ、念のため。 理論上の「社会構想」なんてどれも妄想。実践的に仮説検証しながら実現化するのが大事。その過程で理論の修正も必要。 それをしなかったのがマルクスの失敗。じっさいに失敗したのはフォロアーたちだが、上述の理由、つまり「仮説検証的な実践のなかで構想のフィージビリティを実証することなく、単なる空想のままデザインされたプロダクトをリリースしてしまった」というデザイン上の失敗をおかした。 そして、そのプロダクトを運用した(ロシアとか中国とかの)人びとによって、大規模な「事故」が起こってしまった。 もはや実践前の(アプリオリな)理論の「正しさ」なんて、議論するだけ時間
むかし「ユーザビリティ」という概念が普及したことがあった。「ユーザビリティ工学的なことをやらなければUIデザインではない」という理解が共有されていた時代があった。 そのころ、工学に関心のないUIデザイナたちは、肩身の狭い思いをしていたことだろう。たんに「かっこいい絵」を描いただけでは「UIデザイン」したことにならない、と言われていたのだから。 その後、「ユーザーエクスペリエンス」という概念が普及してきた。それによって、「UIデザインには、工学的な機能性だけでなく、見た目の印象も大事」ということが言いやすくなった。 これは工学に無関心なUIデザイナにとって「朗報」となっただろう。ユーザビリティ工学そっちのけでUIデザインできる状況をつくるのに、「ユーザーエクスペリエンス」という言葉は便利だっただろう。 「使いやすさだけじゃダメなんですよ。使い始めてもらえる魅力的なデザインじゃないと」と主張す
(「ぼくの見た限りでは」という前提での話になります) 「よいユーザーエクスペリエンス(UX)」という言葉は危険。素人にはオススメできない。 「よいユーザーエクスペリエンス」という言葉を使うなら、「よい」という言葉の意味する価値を、具体的に定義しなければなりませんよ。 価値の具体的定義なしに「よいユーザーエクスペリエンス」という言葉を使うと、やはり具体的内容なき「顧客満足」と同じような、無内容な概念になりますよ。 「この設計案は、よいユーザーエクスペリエンスを与えるか」という問いに意味があるためには、「よい」の定義が必要ですよ。その「よい」が、「誰にとってよいのか」もね。 「誰にとってもよい経験」などという発想は危険。「誰にとっても」という変数xで、ユーザーについて考えることを放棄してるだけですよ。 ユーザーエクスペリエンス論をきちんと考えているのでなければ、実務上は「ユーザビリティ」という
(実践者向け) ある分野の本がスラスラ読めるようになってしまったら、それはもはやあなたがその分野の本から学ぶことが終わりに近づいてきているということ。もっと負荷のかかる読書に切り替えるべき時期を知らせるサインかもしれない。コンフォートゾーン(快適な領域)に留まっていると、成長が鈍化する。
「アプリかウェブか」といった議論は不毛です。とくに「ウェブは死んだ」という極論はナンセンスです。 アプリとウェブの両方を作って連携させるのが合理的です。その意図は、ユーザーエクスペリエンスとアクセシビリティの両立です。 数年後には「車の両輪」のように「両方作るのが当たり前」と思われているだろうと予測します。 さて、本題に入る前に、デジタルエコシステムの現状をおさらいしておきます: Open vs Closed Web in mobile travel - two sides of the same coin アプリはユーザーエクスペリエンス面で有利。スマホ利用時間の86%がアプリ。ウェブは利便性や発見性で有利。トラフィック3倍。 さて、Google I/O 2014で面白かったのが「アプリと検索の未来」 (The future of Apps and Search) というセッションです:
「アクセシビリティがないコンテンツ」=「アクセスできないコンテンツ」です。ビジネスチャンスを最大化するためには、コンテンツのアクセシビリティを確保しなければなりません。政府・自治体のウェブサイトならば、人々の「知る権利」のためにアクセシビリティの確保は必須です。 とはいえ、もちろん「どの程度やればよいか」は、ケースバイケースです。そこで Web Content Accessibility Guidelines などの公的なガイドラインを参考にすればよいのですが、アクセシビリティ初心者にはとっつきづらい文書でもあります。最初のうちは、植木真氏による下記の実践的なチェックリストを参考にするのがよいと思います。 植木真氏による15項目の「アクセシビリティ・ガイドライン・セルフチェック」開始タグと終了タグがある(終了タグを省略しない) ただし、仕様で認められている場合を除く要素を仕様に準じて入れ子
私には、ウェブ記事を読むときに、まず日付を確認する習慣があります。このことは私にとっては「最低限の情報リテラシー」に思えます。なぜならば、その情報が「いつ書かれたものであるか」は、非常に重要なコンテキストあるいはメタ情報だからです。なぜ日付が重要かというと、「書かれたあとに知られた情報は、反映されていない」ことを意味しているからです。 現代の情報は評価が変遷しがちです。数年前の記事に書かれたことが、現在の「常識」から見ておかしいことなど日常茶飯事です。代表的な例としては、遠隔操作ウイルス事件やSTAP事件などがあります。それまで「事実」として語られていた内容が、ある時点を境に「誤り」になることは日常茶飯事です。したがって、記事の内容を解釈するにあたっては、記事の日付を考慮しなければなりません。さもなくば、私たちは誤った結論に達してしまう恐れもあります。 この点について人々がどうしているか想
私がスタートアップの少人数チームを相手にするとき、どのように「カスタマージャーニーマップ」を使っているか。(※この議論の有効範囲) 私は「カスタマージャーニーマップ」を作ることがあります。しかし「カスタマージャーニーマップを作ろう」とはしません。言い換えると、「カスタマージャーニーマップのテンプレートを埋める」ような作り方をしない、ということです。さらに言い換えれば、「作ってみる前から、出来上がりの形を想定しない」ということです。ある意味、「行き当たりばったり」というか。 ではどうやっているかというと、「その場でKJ法的に情報を構造化した結果としてカスタマージャーニーマップが出現する」ような作り方をしています。ですから、毎回違う形になります。 (「議論の可視化」という手法は、ひょっとして「グラフィック・ファシリテーション」と呼ばれる手法と同じかもしれませんが、関連書を読んだことがないので、
日本では、あまり「JavaScriptソースコードの自動生成」って流行ってませんよね。みんなJSを手で書くか、またはCoffeeScriptなどのalternative JS (altJS)を書いている。一方、欧米ではGoogle Web Toolkitという「JavaからJavaScriptソースコードを自動生成するフレームワーク」が使われていて、毎年GWT.createというイベントもすごい規模で開催されるほどコミュニティが出来上がっています。 日本と欧米における「JavaScriptソースコードの自動生成」に対するこの温度差はなんでしょうか。ここで一説。やはり日本人には「真心を込めてJSのソースコードを書く職人気質」があって、欧米人(とくに米国人)は「動けば一緒」という感じなのかもしれません。 ぼくはGWTベースのVaadinに興味があります。日本ではまったく注目されていませんが。
もし将来ウェブブラウザーが使われなくなり、ほとんどのウェブ サービスがネイティブアプリと非 HTTP のプロトコルで通信し、非 HTML の構造化データをやりとりするようになっても、インターネット上のリソースを特定するために、URL は使われ続けるのだろう。 そのような未来をティム・バーナーズ・リーらは “Web of Data” と呼んでいますね。それを可能にする技術の総称が “Linked Open Data“ であり、例えばURI、RDF、SPARQLなどが含まれます。 こういった「来るべき未来」を先取りして現に見せてくれるアプリが Google Now です。ウェブを作る仕事をしている人には、ぜひ Google Now を触ってみてほしいです。とくに遠出するときや、観光のときに。 さて、Google Nowを可能にしている技術が schema.org + microdata です。
“事業に成功するコツといった言葉はよくありますが… ある地方の食堂のトイレに『事業に失敗するコツ』というのがありました。 これが示唆に富む内容なんで、ご紹介しましょう。 1.旧来の方法が一番良いと信じていること 2.もちはもち屋だとうぬぼれていること 3.ひまがないといって本を読まぬこと 4.どうにかなると考えていること 5.稼ぐに追いつく貧乏なしとむやみやたらに骨を折ること 6.良いものはだまっていても売れると安心していること 7.高い給料は出せないといって人を安く使うこと 8.支払いは延ばす方が得だとなるべく支払わぬ工夫をすること 9.機械は高いと云って人を使うこと 10.お客はわがまま過ぎると考えること 11.商売人に人情は禁物だと考えること 12.そんなことは出来ないと改善でせぬこと どうですか? ドキっとすること、ありませんか? そして、手書きで13番目が書き足されています。 1
“――最後にもうひとつ。最新アルバム『SOFTLY』を聞いて思ったのが、2013年に亡くなられた大瀧詠一さんへのトリビュート的なお気持ちがあったのかな、ということなんです。「REBORN」のように、別れを経た後の“再会”を歌いこんだ曲も収録されていましたし。 「ここ10年で親しかった方たちが両手の指の数くらい亡くなりましたからね。大瀧さんもそうだし、筒美さんもしかり。編曲家として僕も大変お世話になった服部克久さんしかり」 ――中でも大瀧さんに関して、達郎さんがあえてコメントを控え、語らずにいたという印象があります。 「亡くなって、来年で10年になるんですよね。僕の周りでの、直後のあの異常な追悼ブームって、一体なんだったんだろう。なら、ご本人が生きているうちにもっと評価してあげたらと思う。同じようなことは、著名人が亡くなるたびに感じる。人の生き死にって、言葉は悪いけど“デス・ビジネス”とは違
このページを最初にブックマークしてみませんか?
『Random Thoughts』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く