You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
第1回 いよいよWPFの時代。WPFの習得を始めよう（2010/05/14）1．WPFの特徴と利点 2．プログラミング・モデル 3．UI要素の例 第2回 WPFとXAMLの関係とは？ XAMLの基礎を学ぶ（2010/06/22） 1．WPFとXAMLの関係 2．XAMLの基礎 3．XAML構文のまとめ 第3回 XAMLコードから生成されるプログラム・コードを理解する（2010/08/03） 1．MainWindow.xamlファイルから生成されるプログラム・コード 2．App.xamlファイルから生成されるプログラム・コード 3．依存関係プロパティ 4．ルーティング・イベント 第4回 WPFの「リソース、スタイル、テンプレート」を習得しよう（2010/09/07）1．リソース 2．スタイル 3．コントロール・テンプレート 第5回 WPFの「データ・バインディング」を理解する（2010/10
いかんせんスケジュールがギリギリだったので、個別にエントリ書くのは無理でした TableView TableViewの各Rowの高さを指定したい tableView.rowHeight swiftでtableViewの高さを変更する - Qiita TableViewのボーダーを消したい tableView.separatorStyle = UITableViewCellSeparatorStyle.None UITableViewの区切り線（separator）を個別に非表示にする - Qiita TableViewCellのUIButtonが反応しない cell.contentView.userInteractionEnabledがtrueだと、そっちに奪われるとか 直上のUIViewのuserInteractionEnabledがfalseになっちゃってるとか その他もろもろ 戦車や
Cygamesは、「アイドルマスターシンデレラガールズ スターライトステージ 制作事例・アート編 － 総勢60名のアイドルを最大限魅力的に表現し、ライブに集中する手法（モデリングとUI/UXデザイン）」と題するセッションを8月26日開催の「CEDEC2016」で開催した。モデリングパートとUI/UXデザインのパートに分かれており、今回はモデリングパートの模様をレポートする。 モデリングパートでは、Cygamesデザイナー部3DCGアーティストチームマネージャーの谷本裕馬氏（写真）が登壇した。『アイドルマスターシンデレラガールズ スターライトステージ（以下、デレステ）』は、「Mobage」で配信されている『アイドルマスターシンデレラガールズ』から派生したリズムゲームで、App StoreとGoogle Playの売上ランキングで首位を獲得した実績もあるなど、人気タイトルの一つとして定着してい
背景 React+Redux使ってみていろいろ悩み事が出てきたので書き連ねる。 選定理由 react良さそう 画面変更の度にDOMをごりごりいじるのはやめよう。 あるべきUIを定義しておけばよいという世界はわかりやすい。 でもアプリ全体としての動きのフレームワークにはなり得ない。 Flux良さそう データフローが一方向なのは回りくどい感もあるが、処理の流れとしては追いやすそう。 Flux実装どんなのあるかな？と探してみたら例のごとく群雄割拠 flummoxの作者曰く、"4.0 will likely be the last major release. Use Redux instead. It's really great." なんとなく自分の観測範囲でもreduxが良さそうな雰囲気 開発ペースも良いし、ドキュメントも最初からかなり気合い入っているので期待できそう 全部英語だけと だいた
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
僕がWeb業界に飛び込んでから一年が経つ。 フロントエンドの端くれとして、今年はデザインについても勉強したい。 あいにく僕は美的センスが完全に破綻している。 せめてUXに関する力を付けるべく、最近それらしい本を読み漁ってる。 そのうち一冊が「さよなら、インターフェース」だった。 さよなら、インタフェース -脱「画面」の思考法 作者: ゴールデン・クリシュナ,武舎るみ,武舎広幸出版社/メーカー: ビー・エヌ・エヌ新社発売日: 2015/09/17メディア: 単行本（ソフトカバー）この商品を含むブログ (5件) を見る 概要 The best interface is no interface | Cooper Journal 去年9月発売の本書は、↑のブログ記事に加筆修正を加えたものだ。 元のタイトルは "The best interface is no interface" 。 タイトルの
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 XcodeにはInterface Builderと呼ばれる、リッチなGUIを持ったデザインツールが付属しており、これを用いて画面のレイアウトを構成することが主流となっています。弊社ブログでも、iOS開発でstoryboardとxibをうまく使い分けるプラクティス等の記事で、GUIベースのレイアウトについて触れています。しかし、現在私が担当しているプロジェクトでは、Interface Builderを用いずに、レイアウトの大半をコードで記述しています。 今回は、コードベースのレイアウトを実装していく中で得た知見を、以下の3つの部分に分けて共有したいと思います。 Interface Builderを用いたレイアウトとコードベースの
非エンジニアリング脳なデザイナーが新規アプリ開発の現場でXcodeを使用することがどのような影響を与えたか。について、自身の経験を元にまとめました。Read less
最近KAOSS DJで遊んでて，きのうMIDIイベントを受け取るところまでできたので，もうちょっと知的なことをやってみる． フェーダーに応じて姉を出す クロスフェーダーの値に応じて文字を出してみる．UniMIDIでイベントを受け取って，182番のときだけ値を見てなんかする．182番はクロスフェーダの操作で，3番目にフェーダーの位置が入ってる． require 'bundler' Bundler.require input = UniMIDI::Input.first.open loop { events = input.gets events.each{|event| data = event[:data] next unless data[0] == 182 size = data[2] / 127.0 * 30 puts '姉' * size } } sketch-midi/ane.r
単一のStoryboardでうまく画面遷移を表現できない Storyboardを使ってアプリを作成していると、画面遷移の定義が楽な反面、巨大なStoryboardが生まれてしまったり、うまくSegueで表現できずに同じような画面遷移を２度定義してしまったりすることがあります。このため、Storyboardの使用をあきらめようとする事もあるかと思いますが、Storyboardを分割するとうまい具合に実装できることもあります。 そこで今回は、複数のStoryboardを利用して画面遷移を作成する方法をご紹介したいと思います。 開発環境 今回の開発環境は下記の通りです。 OSX 10.8 Xcode 4.6.1 iOS SDK 6.1 ソースコードはGitHubで公開しています。 共通の画面遷移を別のStoryboardに切り出す 共通の画面遷移部分を再利用したい NavigationContr
スマートフォンの利用者が年々増加するなか、フォームのスマートフォン対策はもはや必須のものとなりつつあります。 このとき、ただスマートフォン向けにデザインを最適化するだけではなく、スマートフォン特有の制約や特徴をおさえたうえで改善することが大切です。 本日はスマートフォンの特徴をふまえながら、スマートフォン向けエントリーフォーム最適化（EFO）のポイントを「15カ条」にまとめてご紹介したいと思います。 スマートフォンEFO15カ条！ 本日ご紹介する「スマートフォンEFO 15カ条」は以下のとおりです！ 第1条: 表組みにするべからず 第2条: 拡大はオフにするべし 第3条: 項目は大きくするべし 第4条: 余白を充分に保たせるべし 第5条: リンクは極力配置するべからず 第6条: タップエリアとわかりやすくするべし 第7条: 項目数は極力減らすべし 第8条: 負担の少ない入力形式を使うべし
この写真は、アーミーナイフの名門ウェンガー社のジャイアントナイフという最高級ナイフである。141の機能を持つ、ギネス認定もされた厚さ24cm、重量1.3kgの世界で最も高機能なナイフだ。トップメーカーが自社製品の全機能を１つに集約したこの製品こそが、機能拡張の行き着く先を指し示している。 なぜ適切な機能追加であっても、機能を追加しつづけることで破綻をするのか？本エントリは、「スマホUI考（番外編） 顧客やユーザーの要望に全て対応すると、アプリは99%破綻する」の続きになる。 本エントリでは以下の４つの側面から、機能を追加するリスクを考える。まず第一に「選択肢の数が必ずしも善ではないこと」。次に「人間の判断力は使うほど消耗すること」。そして「画面スペースが有限のリソースであること」。最後に「どんなに機能を増やしても、一画面で強調できるものは限られていること」。これらの４つは全て、機能追加が最
顧客や上司、ユーザーの場当たりな要望に対応しつづけると、どんなアプリもゴミアプリになる。たとえそれが理にかなった要望であっても。 なぜなら面積の限られたスマホでは「一画面の機能数とボタン数」が、使い易さと品質に深くリンクしているからです。 ということを、エラい人にプレゼンするのがお仕事の今日この頃。でも毎回毎回、同じことを説明するのがシンドイので資料をブログにまとめたいなぁと思うなど。 思考実験として、ここでは架空事例としてTwitterアプリを例に考えてみる。 何かの間違いで、日本の大手メーカーがTwitterを買収すると・・・UIデザイナーが体を張らないと99%ぐらいの確率でこうなるのです。 ここがオリジナル Request1: ダイレクトメッセージをトップ階層に ユーザーからの真っ当な要望。実際にはサービスの本質ではないのですが、要望はかなり多いはず。 ただTwitter社的にはme
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
