UX MILKWelcome to UX MILK UX MILKはより良いサービスやプロダクトを作りたい人のためのメディアです。 このサイトについて
エンジニアがデザインに取り組んでわかったこと
最近、いくつかのデザインに取り組んでわかったことがあるので、書いておこうと思う。 ぼくは2,3年前にこの業界に入ってからずーっとフロントの実装畑でやってきた。 それは自分の意図していたものではなかったけど、前職のまぼろしという会社は実装が強みの会社だったので、デザインに触れることはほぼほぼなかった。 それもあってか、ぼくは「もうちょっとコストを考慮してほしい」「このあしらいが一体ユーザーにいくらのお金を落とさせるんだろう」とか、あげくの果てには「実装のことを考えたデザインをすべき」とまで考えていた。これらの考え方はぼくだけでなく、コーダーからよく同様の声が上がっている。 だけどデザイナーさんと接する機会が増えるごとに、デザインができるようになったら今までイラついていたことがどんな風に見えるのか確かめたいな、という気持ちになった。 それ以外にも「なにか作るとデザイナーばかり褒められて厳しい」
技術的負債について - 表道具
2015-03-19 技術的負債について スタートアップや新規事業に限った技術的負債の考え方f-shin.net ちょっとこの記事は酷い．品質と開発スピードを兼ね備えたコードは，そもそも致命的な技術的負債ではないだろう． 現代的なスタートアップのプロダクトでは，シンプルなものを作って世に出すというのはあまり起こらない．いわゆる「仕組み作り」と言われるものをやらなければならず，そのために何を作るかを練った場合，凄まじい天才で無い限り，様々な概念をつなげた複雑なシステムを作ることを考えてしまう．アイデアもガンガン出てくるし，その優先度もつけられずただデカくなっていく．その意味で，スタートアップ段階で必要になるコードの規模は思っていたより大きいことが多い．それを事前にうまく落とそうという試みがリーン・スタートアップであるとも言える． 例えば現在のマーケットで「猫の鳴き声を共有するサービス」があっ
Yahoo!メールが崩壊しつつある件
Yahoo!メールのサービス劣化が著しい。 失敗した新UIへの移行Yahoo!メールはサービス開始当初からある古めかしいHTMLバージョンと、なかなか正規版に移行しないベータ版の新UIが何年も共存していたのだが、新UIはモバイル版での不具合が多く、なかなか移行がすすまないようだった。実際、私もベータ版は信頼度が低すぎて、一度使い始めたがすぐに旧UIに戻した。 つい最近になって、このベータ版を切り捨てて、別のバージョンの新UIへ全員強制的に移行したのだが、このバージョンも読み込みが非常に遅く、使い勝手が悪い。 古めかしい広告中心のビジネスモデルYahoo!メールのwebメールには広告がでかでかと表示される。有料版であるYahoo!プレミアムに加入しても、非表示になることはない。 GmailやOutlookは無料で広告が非表示になっている時代に、なぜ毎月金を払って広告を見せられ続けなくてはなら
エンジニアはもっとクリエイティブな環境で働くべき - トランスリミット創業記.author = 高場大樹
トランスリミットを創業してから1年2ヶ月が経ちました。 4月には、トランスリミット史上初となる新卒社員（エンジニア）が2名、そして同じく当社史上初となるビジネスサイド（広報兼人事担当）のメンバーを1名迎え入れることになっており、総勢14名ほどの組織となる予定です。 トランスリミットは、現在エンジニアとデザイナーを中心に構成（エンジニア11名、デザイナー2名）されており「開発者集団」という言葉がよく似合う会社となりました。若く優秀なエンジニアが集まり、社内にはエンジニア独特のハッカー文化が根付きつつあります。 エンジニアはクリエイティブなお仕事 当社が運営している対戦型脳トレアプリ「BrainWars」は、世界で1000万ダウンロードを突破、海外ユーザが比率95%を占めます。そんなBrainWarsは正にクリエイティビティな発想の賜物。これまでにないジャンルで切り込み、新しい価値を生んでいま
デザインワークをGitに含めるべき? 含めないべき? - Qiita
「プログラマ業界」であればコンパイラの多くがオープンソース化されていますが、デザインツールはAdobeを筆頭に今もほとんどがプロプライエタリなツールです。そのことが、原理原則に沿うのを難しくしています。 複製不可能な部分に価値を置くという文化的な面 ツール開発にコストがかかるという金銭的な面 もあって、ツールがオープンに向かうことは当面なさそうです。Blenderという例外はありますが、GimpやInkscapeは実質プログラマだけのためのツールになっています。そういえば、Fireworksのオープンソース化嘆願はどうなったんだろう...? ツールが有料 デザインツールはときに高額です。また、セットアップに割く時間も「見えない」コストです。残念なことにインストールも自動化されていません。caskも使えません。$ npm installでは片付かないのです。また、アップグレードの問題もありま
多くの若きプログラマたちが学ぶべきこと | POSTD
私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン
使いやすいアプリを作る簡単な方法
使いやすいアプリを作るための、とても簡単で、確実な方法があります。 それは、ユーザの問い合わせに対応することです。具体的に言うと、問い合わせが気軽にできるようなUIにして、そこで得た情報源を元にUIを分かりやすく改良していく。(機能追加とはまた別の話) ただ、直感的に感じるように、これは手間がかかるのでたくさんの人は逆のことをしようとする。つまり、ユーザヘルプを設置して、問い合わせ先は出来るだけ発見しにくい洞窟の奥深くに設置する。 でも、問い合わせには、アプリの利便性向上につながるヒントが豊富に隠されています。ユーザがどんな問題やニーズを持っているかのヒントもザックザック出て来ます。ザックザックです。 アプリ開発にとって、やったことがいい事は星の数ほどあって、そのどれもをやろうとすると時間やお金がいくらあっても足りません。だから、”やったほうがいい事”の優先順位は常に意識して、メリットとそ
Javaでいかにifやfor文を使わないでコードを書くか考えてみよう : IT速報
1: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:23:22.49 ID:aDj/zqBFNIKU.net if文for文使いまくってるのってキモいよな 2: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:24:15.50 ID:/y8HWckGNIKU.net じゃあ代わりにswitchとwhile使う 3: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:24:18.06 ID:afkjonbrNIKU.net switch 6: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:25:46.44 ID:5e4wCC7eNIKU.net ３重switchできたった 4: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:25:07.80
エンジニアと非エンジニアの境界 - ワザノバ | wazanova
http://techcrunch.com/2015/01/01/everyone-in-management-is-a-programmer/ 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 この先、ソフトウェアの力でビジネスの競争力に格段の差がついてくる産業がどんどん増えてくることに備えて、プログラミング教育の必須化の議論も盛んですが、その必須化の是非はさておき、将来的には社会人になるうえで、ある程度コードを理解できる素養があることがもっと当然のことになってくるのではないかと期待してます。 そうなると、今の世の中の人が漠然と持っている、「エンジニア」と「非エンジニア」という言葉から連想してしまう偏見、両極端なイメージは、いずれの側に属する人々にとっても将来はもっと不利益になるかと。相互理解が必要です
コードレビューさせないようにコミット - Qiita
対象 開発フローの中でコードレビューを実施しているひと git add -p や git rebase -i でコミットの分割や統合ができるひと レビュー無しにマージしてもらうために同僚をいかに抱き込むか。 という話ではなく、レビュワーの コードレビューの負荷を下げる ことを意図しています。 無視できるコミットを増やす どうすればレビュワーがより短時間で自分の書いたコードをレビューできるか。この問に対して、レビューの妨げとなるものを排除する、というアプローチがあると思っています。そのための良い方針だと考えている 無視できるコミットを増やすこと について書きます。 前提 コミット どのコミットにおいてもテストが通るようにする コミットメッセージ ちゃんと Git のスタイルで記述する (Gitのコミットメッセージの書き方 の原則を守る) Git の操作 雑にコミットしても、後できれいにコミッ
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
Xcodeコメントの基本 - Toyship.org
これはiOS Advent Calendar 2014の12日目の記事です。 年の瀬もだんだん押しせまってきました。 年末年始のお休みの後に、「あれ、このメソッドどんな目的で作ったんだっけ？こっちのメソッドとの関係はどうだったんだっけ……」など無駄に悩まないために、このあたりでソースコードのコメントを見直してみましょう。 Xcodeでのコメント そもそもソースコードにコメントを書いた方がいいかどうかは長い議論がありまして……。 コメントによりコードの理解は深まるので、あったほうがいいという意見もありますが、コメントを書いたあとにコードを変更してしまうと、コメントとコードの内容が違ってしまい、かえってバグを生んでしまうためコメントを強制するのは害悪だ、という考え方もあります。 また、適切な命名規則を守ればソースコードを読むだけで理解できるという考え方もあります。 実際には、プロジェクトのライ
アプリのUI設計は「紙でやる」のが早い！ - Qiita
はじめに こんにちはー！！ UI設計やってますか？ 今回は「ペーパープロトタイピング」の話。 アプリでは主流になってる現場も少なくないですよね！ 今までのやり方とペーパープロトタイピングの違いや、 プロトタイピングツール「POP」と「Prott」の比較の話なんかをしようと思います！ 今までのアプリUI設計 Webデザインと同じ方法でアプリ設計を行っている場合、手順は ●ワイヤフレーム→モックアップ→実装 厳密に言うと ●①ヒアリング→②ワイヤフレーム→③レビュー→④モックアップ→⑤レビュー→⑥実装→⑦レビュー デザイナーがいないと ●①ヒアリング→②ExcelでUI設計→③レビュー→④実装→⑤レビュー って場合も結構多いと思います。 これ結構時間かかりますよね～。 しかも！ 大抵の場合、実装後のレビューの段階（つまり最終段階）で 「やっぱここ動きおかしいよね！直せる？」 「・・・。（えー！
「個」から「集」のデザイン
「emosi」の開発フローを通して、チームでデザインすることの重要性や仕組みづくりのポイントについてお話します。Read less
デザインのためのデザイン
1. DESIGNING FOR DESIGN デザインのためのデザイン Masayuki Uetani / 2014.11.11 / #nanapi_study
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログイン - はてな
https://jp.techcrunch.com/2015/02/10/20150209ios-9-stability-improvements/
digihows.com -
デザイナーとエンジニアの良い関係
