RE: どんなことを勉強すればいいですか？ - satococoa's blog
仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか？」です。 それについてちょっとポエムを書いてみようかと思います。 主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。 専門家であるという視点から エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。 僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基本がないと、曖昧な知識の上にさらに曖昧な
アプリのUI設計は「紙でやる」のが早い！ - Qiita
はじめに こんにちはー！！ UI設計やってますか？ 今回は「ペーパープロトタイピング」の話。 アプリでは主流になってる現場も少なくないですよね！ 今までのやり方とペーパープロトタイピングの違いや、 プロトタイピングツール「POP」と「Prott」の比較の話なんかをしようと思います！ 今までのアプリUI設計 Webデザインと同じ方法でアプリ設計を行っている場合、手順は ●ワイヤフレーム→モックアップ→実装 厳密に言うと ●①ヒアリング→②ワイヤフレーム→③レビュー→④モックアップ→⑤レビュー→⑥実装→⑦レビュー デザイナーがいないと ●①ヒアリング→②ExcelでUI設計→③レビュー→④実装→⑤レビュー って場合も結構多いと思います。 これ結構時間かかりますよね～。 しかも！ 大抵の場合、実装後のレビューの段階（つまり最終段階）で 「やっぱここ動きおかしいよね！直せる？」 「・・・。（えー！
Pythonと出会ったデザイナーの話 #PyLadiesTokyo
http://pyladies-tokyo.connpass.com/event/8744/ 「Pythonと私の付き合い方」をテーマという事で。こんな話をしてみました。Read less
UIデザイナー不要説 / LSD LAB
2014/10/26 UIデザイナー不要説 最近UIについてもやもやしていることがあるので書く。間違った知識もあるかもしれない。 先日UI CrunchというUIの勉強会のようなものが開催され、僕はschooの動画配信を見ていたのだが、どうも根底に「UIデザインの重要性が日本では認知されていない」という共通認識が流れているように思える発表が多かった。デザイナー生存戦略やエンジニアとうまく付き合う方法等…。 僕も前のブログ(UID Lab)でそのようなことを訴えてきたので、あぁ、やっぱりみんな不安なんだなあと思ったが、逆説的に「僕らデザイナーが信じているUIデザインの価値なんて、本当は虚像なんじゃないか？」ということを疑ってみたい。 そもそも、なぜみんな「UIデザインが重要視されていない」と感じるのだろう？自分が日頃感じることを列挙してみる。 UIデザインが重要視されていないと思う理由 1.
UIの話は会議室でするな
9. ● 常に文書による指示を要求せよ。 ● 準備を十分行い完全に準備ができているまで実行に移すな。 ● 些細なことにも高い完成度を要求せよ。わずかな間違いも繰り返し修正させ小さな 間違いも見つけ出せ。 ● 重要な決定を行う際には会議を開け。 ● もっともらしくペーパーワークを増大させよ。 ● すべての規則を隅々まで厳格に適用せよ。 ● 何事をするにも「通常のルート」を通して行うように主張せよ。決断を早めるため のショートカットを認めるな。 ● 可能な限りの事象を委員会に持ち込み「さらなる調査と熟考」を求めよ。委員会の メンバーはできるだけ多く（少なくとも5人以上）すること。 ● 議事録や連絡用文書、決議書などにおいて細かい言葉遣いについて議論せよ。 ● 以前の会議で決まったことを再び持ち出し、その妥当性について改めて問い直せ。 10. ● 常に文書による指示を要求せよ。 ● 準備を十分行
リーダブル・コードを書く | POSTD
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself（DRY）に従えば、バグも
コンテンツから先に考えなければデザインすらできない理由 : could
ワイヤーフレームの間違った使い方 たまにリニューアル案件をいただくときがありますが、見た目より先にコンテンツを整理しましょう、一緒に作っていきましょうと説得するようにしています。このサイトでも様々な角度からコンテンツの重要性を語ってきましたが、最もシンプルな方法は「UX を考えていきましょう」「モバイルファーストで戦略を練っていきましょう」といった専門性の高い言葉を使うのではなく、今までのやり方ではうまくいかないということを分かりやすく説明することです。 従来の Web サイト制作でよくあったのが、まずワイヤーフレームをつくって情報の大まかな構成を設計するというやり方。ワイヤーフレームを作ることは間違っていませんが、コンテンツを作る前に始めてしまうと、あとで大きなギャップを埋める作業が発生することがあります。コンテンツなしで構成を作り始めると、例えば以下のような状況に陥ります。 文字が多過
「失敗を活かす」を実現する仕組みづくり - ワザノバ | wazanova
http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem（個人批判をしない建設的な障害の振返りミーティング）というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが
uilang
a minimal, ui-focused programming language for web designers clicking on ".try-it" toggles class "hidden" on ".info-box" Try It Getting Started Insert uilang.js in your page, write some uilang as shown above in a simple <code> element and use CSS to show, hide and animate things. Download 1KB Build Interfaces Create popovers, tabs, galleries, overlays and more using a language specifically designe
モバイル向けUI/UXデザイン10のポイント デザイン会社 ビートラックス: ブログ
日々めまぐるしく変化するモバイルマーケットにおいて、マートフォンアプリやモバイルWebのUIやUXを最適にデザインする事はそのプロダクトがヒットするかの大きな要素となっている。特に最近は見た目が良いだけではなく操作性が非常に高いモバイルサービスが次々とリリースされユーザーが求めるクオリティレベルも上がっている。 小さな画面サイズ、様々な利用シーン、複雑な仕様の機能を実装したモバイルサービスにおいては、高いユーザビリティを実現する事が何よりも重要である。よりユーザーに愛される為もポイントをまとめてみた。 1. レイヤースタイルのUIで奥行きを出す モバイルのインターフェイスに関しては、最近のトレンドを見てみると、フラットなUIがトレンドのように思えるが、実はモバイルの限られたスペースでユーザーに効果的なエクスペリエンスを提供するには、縦と横のスペースに加え、”深さ”を利用したレイヤースタイル
Storyboardを1画面ごとに分割した話 - 24/7 twenty-four seven
今年の5月くらいの話なのですが、ユビレジのiPadアプリケーションのプロジェクトで使っているStoryboardを基本的に1画面（≒1 View Controller)の単位に分割するということをしました。 1画面1Storyboardメソッドについてはnakiwoさんが書かれた記事も参考になります。 1画面から始めるStoryboard - Cocoaメモ ↑ 上記の資料はどちらかというとStoryboardを使い始めるにあたって、１画面単位で少しずつ使っていこうという感じですが、ユビレジではもともとほぼ全部の画面がStoryboardになっていました。 ただ複数人で共同作業をするにあたっては、1画面単位を1ファイルにしておくくらいがメンテナンスしやすいんじゃないかなあという結論になったのでしばらくそういうふうに運用することにしました。 また、XIBと違ってStoryboardは単純にコ
シンプルさが勝つ。人間はシンプルではない。 - mizchi's blog
迷ったらシンプルな方— 片手間以上 (@mizchi) 2014, 7月 19 僕は主にUIを作るエンジニアなのだけど、以下の話題について。 時間をかけて、つまらないものを作りたいか？ - futoase.hatenablog.com ニコニコ動画はSynvieプロジェクトが原型 - はてな村定点観測所 UIの有効性を証明する仮説とその検証において、ほとんどの場合において次の二つが根源的な問題となる。 だいたいのものはシンプルな方が勝つ 人間はシンプルではない 二点間の距離を求める三平方の定理は、(ディスプレイが歪んでいない限り)簡潔でシンプルだが、二点のボタンを順番に押すときのマウスの軌道、そのあいだのユーザーのメンタルモデルの変化は、まったくもってシンプルではない。 人間はシンプルなものの価値を認めたがらない、というバイアスがある。金を産まないといけないソフトウェア開発の現場は、コアフ
DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD
今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度（少なくともほとんどの場合）私は反省し、それまでにも増して退屈なくら
コールバック地獄からの脱却！複雑なiOSアニメーションをPromiseの決定版ライブラリPromiseKitですっきり実装する！！！ - Qiita
dispatch_promise(^{ return md5(email); }).then(^(NSString *md5){ return [NSURLConnection GET:@"http://gravatar.com/%@", md5]; }).then(^(UIImage *gravatarImage){ self.imageView.image = gravatarImage; }); PFQuery *query = [PFQuery queryWithClassName:@"Student"]; [query orderByDescending:@"gpa"]; [[[[[self findAsync:query] continueWithSuccessBlock:^id(BFTask *task) { NSArray *students = task.result;
情報がないことを伝えるUIデザイン | UXデザイン会社Standardのブログ
「Empty Data（またはEmpty Status）」というUIパターンがあります。タイムラインやドロワーなどデザイナーであれば知っているUIパターンの名称に比べると、あまり日本では聞き慣れないのかもしれません。Empty Dataは簡単に言うとデータがない時のUIになります（Webでの404に近いですが、少し違います）。では、Empty Dataを知るためにもう少し詳しく紹介していきたいと思います。 参考：モバイルデザインパターン 第2版 ―ユーザーインタフェースのためのパターン集 Empty DataはUIである Empty Dataはただユーザにデータがないことを示すだけではありません。ユーザにデータが存在しないという情報をフィードバックし、どうしたらここに情報が入るかのアクションに繋げる立派なUIです。もしEmpty DataのUIが存在しなかったらユーザはどのように感じるでし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユーザーインターフェイスのデザインのヒント - Apple Developer
セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
ド・モルガンの法則でunlessのややこしい条件をifに読み替えよう - Qiita
お前自分ちのページャUIが本当に速いと思ってんの？
