エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。
悩み多きディレクターの皆様。 こんにちは。Tokyo Otaku Mode (以下TOM)ディレクターの青芝です。 Webサービスを考えるうえで、誰もが一度は頭を悩ませる UI (User Interface)。 User Interface(ユーザーインターフェイス)とは、ユーザーがWebサービスを利用するうえで直接操作する画面のことを指しますが、ひと言で「UI」と言っても、そこには文字や画像の見せ方、マウスのクリックや指のタッチに反応したときの動き、画面全体のレイアウトなど、さまざまな構成要素がかかわってきます。 それら一つひとつの性格や特徴を考慮し、しっかりと設計しておかなければ、使いやすいWebサービスを作ることはできません。今回は、WebサービスのUIを考える際に知っていると役立つ知識のなかから、基礎的な5つの要素を紹介していきます。 正しい文章構造について 人の感情を動かす色に
9. ● 常に文書による指示を要求せよ。 ● 準備を十分行い完全に準備ができているまで実行に移すな。 ● 些細なことにも高い完成度を要求せよ。わずかな間違いも繰り返し修正させ小さな 間違いも見つけ出せ。 ● 重要な決定を行う際には会議を開け。 ● もっともらしくペーパーワークを増大させよ。 ● すべての規則を隅々まで厳格に適用せよ。 ● 何事をするにも「通常のルート」を通して行うように主張せよ。決断を早めるため のショートカットを認めるな。 ● 可能な限りの事象を委員会に持ち込み「さらなる調査と熟考」を求めよ。委員会の メンバーはできるだけ多く(少なくとも5人以上)すること。 ● 議事録や連絡用文書、決議書などにおいて細かい言葉遣いについて議論せよ。 ● 以前の会議で決まったことを再び持ち出し、その妥当性について改めて問い直せ。 10. ● 常に文書による指示を要求せよ。 ● 準備を十分行
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself(DRY)に従えば、バグも
http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem(個人批判をしない建設的な障害の振返りミーティング)というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが
技術部の松尾(@Kazu_cocoa)です。 iOSアプリデザインリニューアルの舞台裏でも書かれていた、" 修正期間中は毎日夜間にアプリケーションの全画面のスクリーンショットを記録するスクリプトを実行し、画面崩れが起きてないか、新デザイン未反映の画面はないか、進捗状況の確認に利用していました。"の舞台裏を少し書いてみようと思います。 はじめに モバイルアプリケーションのテスト環境はまだまだ成長中で、様々なツールが飛び交っていることかと思います。ここでは、E2Eテストに対しての話題に絞り、使っているツール、シナリオの書き方、クックパッドでは、という話しをします。この記事におけるE2Eテストは、UIからの操作によりユーザの操作を模倣して実施するテスト、という意味合いです。 ツール E2Eテストを自動化する為のツールの選定には以下を気にしていました。 OSの更新に追従できそうなもの 特別なテスト
今年の5月くらいの話なのですが、ユビレジのiPadアプリケーションのプロジェクトで使っているStoryboardを基本的に1画面(≒1 View Controller)の単位に分割するということをしました。 1画面1Storyboardメソッドについてはnakiwoさんが書かれた記事も参考になります。 1画面から始めるStoryboard - Cocoaメモ ↑ 上記の資料はどちらかというとStoryboardを使い始めるにあたって、1画面単位で少しずつ使っていこうという感じですが、ユビレジではもともとほぼ全部の画面がStoryboardになっていました。 ただ複数人で共同作業をするにあたっては、1画面単位を1ファイルにしておくくらいがメンテナンスしやすいんじゃないかなあという結論になったのでしばらくそういうふうに運用することにしました。 また、XIBと違ってStoryboardは単純にコ
今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度(少なくともほとんどの場合)私は反省し、それまでにも増して退屈なくら
結論: Javascriptの乱用をやめるのが一番。 はじめに書いておきますがしょうもない話です。 結論、開発者としてはどのような方向性でやるべきか、を書いています。 JS多い時代でのフレームワークの根本的な問題云々のことは書いてません。 さて、現状、モバイルにおいて、Javascriptでまともに動くものを作ることは難しいです。 Twitterから引き抜いた超優秀なWebエンジニアを多数抱えるMediumですら、未だにモバイルで多数のバグを抱えています。 超優秀なエンジニアを世界一抱えているであろうGoogleのGmailですら、モバイル版のWebはすぐクラッシュします。また、自前スクロールに致命的なバグも抱えています。 正確には「UIが不審な挙動をする」ですが、エンドユーザにとっては同じことで、「バグ」です。 サーバサイドで起こるバグと同じ程度、いやそれ以上に、サービスに影響を与えます
15. • Click • Double click • Triple click • Hover • Press and hold • Drag / Drop 15 マウスを動かす クリックする/離す キーを押す/離す 画面を押す/離す 画面上で指を滑らす 複数の指で押す/滑らす ユーザーの操作 コマンド • Press • Long press • multiple press (ショートカット キー操作など) • Tap • Double tap • Press and hold • Flick • Swipe / Pan • Drag / Drop • Pinch in / Out どう操作するか - ユーザーの操作 (入力) マウス キー タッチパネル
t.hondaです。現在はスマホ関連の作業のお手伝いをしております。 スマホ関連のお話として、今回はXamarinについてと特徴、インストール手順 サンプルアプリケーションの実行と構成について書きたいと思います。 Xamarinについてと特徴 Xamarinとは、iOSとAndroid向けにクロスプラットフォームの ネイティブアプリを開発できる開発環境で、以下のような特徴を持ちます。 1.C#で記述。 2.UIやデバイス周り等はiOS、Androidでソースを分ける。 ビジネスロジックは共通。 3.ネイティブアプリを作成できる。 4.「Mono」という.Netランタイム上で動く。 このため、メモリ管理などが楽。 これらについて、少し説明していきます。 1.C#で記述。 C#については、興味ある方はMicrosoftのページなどを参考にしてください。 C#という言語の仕様と、後述する「Mon
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
いま『ビッグオー駆動型開発』とよばれる開発手法が、業界の一部で注目を集めている。 その理由は非常にシンプルだ。『ビッグオー』は非常に安価で簡単な手法でありながら、従来の開発手法に比べ劇的にUIやUXを改善できるためである。 製品コンセプトのような上流から、ボタンのレイアウトといった下流工程、さらにはグロースハックやプロモといったリリース後のフェイズまで一つの手法でユーザビリティを評価できる。この汎用性がビッグオー駆動開発の大きな特徴であり、導入時の利点となる。 今回はこのビッグオー、の概要と具体的なやり方について論じたい。TwitterのUI拡張予言以来、久しぶりのUI系エントリである。 ビッグオー駆動開発とは何か? ビッグオー駆動開発は、正式には『OKAN Driven Development(オカン駆動型開発)』とよばれる開発手法である。 これは自分のオカンを指標とすることで、低コスト
「プレビュー至上主義」 プログラマが「テストファースト」を唱えるなら、デザイナが主張すべきは何? それが「プレビュー至上主義」。書くより先に見る、書きながら見る、しかもほぼ最終成果物に近い形で。 河村 奨 (かわむらつとむ) これはCreators MeetUpで話したスライドです。ライブプレビューしながら、jade + Gruntで作っています。興味あるかたはこちらのGitHubも合わせてどうぞ。 iPhoneや大きめの画面でも見られるよう調整しました。(2014/1/19) 好きなことはなしていいらしい。なにはなそう? レスポンシブ、インブラウザデザイン、脱Photoshopの波など、ここ数年、色々ありました。それをふまえて... ライブプレビュー 少なくとも、ライブリロード ロジックレステンプレート (たぶん時間ないので、よかったら後で〜) GUIツール不在のWEBデザイン業界 今年
プレゼンや打ち合わせで参加者の心を掴むのって重要ですよね。 制作工程の初期段階で時間短縮することでUI/UXの開発にじっくりと時間をかけたい、という思いもあり色々なアプリや手法を導入しています。 弊社で現在ハードに活用している便利なアプリを2つご紹介します。 Riflectorを使ってアプリ&スマホサイトのプロトタイプをその場で共有 Reflector これをインストールすれば写真のようにiPhone/iPadのAirplayを通して現在使っているスマホの画面をPCにダイレクトに写すことができます。ページ遷移やジェスチャーもこれがあれば容易にクライアントに伝えることができますし知らない人からしたらこれ自体のパフォーマンスでグッと引き込まれることでしょう。 インストールしたらiPhone/iPadのホームタスクバーからAirPlayを選択すればあっという間にミラーリングが開始されます。あとは
【DevLOVE甲子園2013】UIと画面遷移を設計するときに 破綻しないようにするための、 ひと手間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く