ローディング時のズルい進捗表示
今開発中のPlayer!のログイン・登録画面で、こんな進捗表示をしていますが、これ実はフェイクだったりします( ´･‿･｀) (Qiitaの画像サイズ制限が厳しくて粗いです。キレイなものは実際にアプリダウンロードしてご覧下さい。) 経緯 元々、この画面はこういう進捗表示では無く、単にインジケーターがクルクルするだけで、進捗状態が分からないものでした。 特にネットワークが悪いところだと、バグって固まってしまったのでは？とユーザーを不安にさせるようで、たまにそういう声を聞くことがありました。 登録フローは大事なところなので、そういうところでこれが原因で離脱してしまうと残念なので、改善が必要でした。 そこで、ネットワーク処理にもたつきつつもちゃんと正常に処理をしているということを示すために、進捗を表示することにしました。 ただ、例えば大きな画像などメディアファイルダウンロードなどならともかく、こ
転職は@type - あなたにおすすめの求人情報とスキルマッチ率がわかる転職サイト
ご利用の皆様にはご迷惑をお掛けして、大変申し訳ございません。 メンテナンス終了まで今しばらくお待ちください。
ひどいダッシュボードの法則 | POSTD
白状しますが、私にはひどいダッシュボードを構築してきた責任があります。個人的に、この記事に書いた間違いのほとんどを犯してしまいました。ユーザに謝罪するとともに、同じ過ちを繰り返さないことを誓います。これらの過ちが悪い見本として、プロジェクトマネージャやデザイナ、エンジニアがひどいダッシュボードを構築したり確認したりする無駄な時間を少し減らすのに役立つことを願います。 法則1：ほとんどのソフトウェアのダッシュボードはひどい ひどいと言うのは このGoogle画像検索 のようなひどさ（まだ吐いていませんよね？）のことではありません。退屈で、設計が不十分で、有用性も一切ないという意味です。 信じられませんか？ では、今すぐ優れたダッシュボードのソフトウェア名を3つ挙げてみてください。 見つかりましたか？ ええ、そうだと思いました。しかし、ダッシュボードはどこにでもあります。あなたが使っているSa
高齢者へのiPad導入を阻んだiOSのUI/UXの話
高齢者へのiPad導入を阻んだiOSのUI/UXの話 先月（2013年11月）、徳島県南部局と美波町が共催する「ITふるさと村」の講座で、iPadを使ったタブレット講座を開催しました。その成功と失敗の体験について書こうと思います。 Facetimeビデオ通話のデモで会場を一気に盛り上げたものの、参加者に実際に体験してもらう段階で「大失敗」。AppleIDの取得とそのためのiCloudメールの登録をしてもらってから、と進めたのですが、30名ほどの参加者のうち時間内にゴール出来たのは、たったの１名。好きなアプリをダウンロードしてもらい、タブレットの楽しさを感じてもらう目標が、そのスタート地点にも立てず(;_;) 企画や運営、インストラクターとしては完全に落第点でした。それを棚に上げると、高齢者とITに関する課題が大量に見えたという点では、ある意味「大成功」だったとも言えるでしょう。 【講座内容
ベンチマーク・スコアを偽ったスマートフォン・メーカー達が勘違いしていたこと | readwrite.jp
「この新しいガジェットはこれまでで最速のパフォーマンスを誇る」と、コマーシャルは華々しく宣伝する。見ている者は圧倒されるに違いない。この製品はなんて速いんだろう！メーカーが提示している大量のベンチマーク・スコアもそのスピードを証明している！ しかし、このスコアが実はほぼデタラメであったことが判明した。 Lumia 1020、Samsung Galaxy S4、Motorola Moto X主要なスマートフォンのコンピューター・プロセッサ速度をリサーチした結果、ほとんどの大手ガジェット・メーカーがベンチマークテストを操作していたことが明るみに出たのだ。分かりやすく言うと、各メーカーはインチキをしており、デバイスは宣伝されているほど早くなかったのである。 Ars TechnicaとAnandTechが行ったリサーチによると、大手スマートフォン・メーカーのほとんどが自社のスマートフォンを実際より
世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
UIの改悪がUXを改善させる場合 - A Successful Failure
2013年01月20日 UIの改悪がUXを改善させる場合 Tweet Good UI≠Good UX UIとUXについてはその理解について多くの議論がなされてきた。たとえば、Googleの及川氏は「写真が語るUXとUIの違い」というエントリにおいてコーンフレークの例を元にUIとUXについて説明したが、その後、ERATOの渡邊氏が「1分でわかるUIとUXをわかりやすく説明する写真とお話」というエントリにおいて、ATMを例によりわかりやすい説明を挙げている（次の写真は当該エントリからの引用）。 この例ではたとえUIが素晴らしくても、そのATMは時間がかかるため、長い待ち時間ができ、結果としてUXが損なわれる場合を示している。 しかしながら、実際にはATMの劣悪なUIが悪いUXの原因となっている可能性があり、本当にこのATMのUIは素晴らしいのかという疑問が残る。つまり「Good UI ≠ Go
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Android 4.4 KitKatの目玉はおそらく「Google Experience」 | readwrite.jp
http://agilecatcloud.com/2011/08/10/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%81%B8%E8%A1%8C%E3%81%A3%E3%81%9F%E3%82%89%E3%80%81%E3%82%82%E3%81%86-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AA%E3%82%93%E3%81%8B%E8%A7%A6%E3%82%89%E3%81%AA/