タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

UIとprogrammingとDevelopmentに関するHeavyFeatherのブックマーク (5)

  • Metro UIは「UXアプリ養成ギプス」 : 小野和俊のブログ

    昨日、今日とWindows Developer Days(WDD)に参加してきた。二日間セッションに参加して感じたのは、「Metro UIは『UXアプリ養成ギプス』だ」ということである。 デザインの原則がある。 例えば原則のひとつに、”Content before Chrome”というものがある。これは、「コンテンツを主役にし、ツールバーやメニュー等のコンテンツへの没入を妨げるものは最小限にする」というものだ。 こうしたデザインの原則やガイドラインがきちんと決められている、ということは重要なことではあるが、それ自体はさほど驚くべきことでもない。先日ブログに書いたように、最近の主要なプラットフォームには、大抵UX/UIのデザインガイドラインが定められているからだ。 では私が何に驚いたかというと、Metro UIではこのデザインガイドラインが「半強制」されていることだ。 UX/UIに意識の高い

    Metro UIは「UXアプリ養成ギプス」 : 小野和俊のブログ
  • 続・Android開発のちょっとしたお話 - mixi engineer blog

    こんにちは。横幕です。 今回もAndroid(TM)開発についてお話をしたいと思います。 設定画面の作り込み 今回のトピックは、設定画面のちょっとした工夫の仕方についてです。 Androidでは、PreferenceActivityという設定画面を作るためのActivityが用意されています。 個々の設定項目はXMLで記述し、それをPreferenceActivityがコントローラとして画面を制御するような形になります。 設定画面の大まかな作り方 まずは、どんな設定項目を準備するのかを、res/xml/pref.xmlに定義します。 Androidには予め幾つかの設定方法を用意してあり、例えば項目の一覧の中から1つ選択するListPreferenceや、チェックボックスの状態で設定を変更するCheckBoxPreferenceなどがあります。 また、設定項目のまとまりごとにカテゴライズする

    続・Android開発のちょっとしたお話 - mixi engineer blog
  • ところでiPadアプリってどうやって作るの?てなったときに読む記事

    こんにちわ。4-ROOMSが終了なんてショック過ぎ!やしこです。 最近iPadのデザインに関わる機会がありまして、情報がまだまだ少なかったのでまとめてみました これからiPadのデザインをする方のお役に立てばうれしいです 今回はTwitterクライアントやリーダーで主流な2カラム型のアプリデザインです ePub(電子書籍)の作り方は先月のMDNで特集されていました iPadにしか見られない(WEBにない)仕様 縦横で画面構成が変わる iPadiPhoneと同じく持ち方によって画面レイアウトが変形します。 縦横2パターンデザインする必要があります 意外とデザインをモニタの中だけで詰めていくと忘れる動きなので はじめにワイヤーに盛り込まれているか確認した方が良いと思います。 PopOver 項目の詳細を見たいときは画面遷移ではなくてPopOverとよばれる吹き出しのようなものがオーバーレイし

  • JavaScript の不思議な面白さ

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog JavaScript と言うと普段自信をもって膨大なプログラムと格闘している諸氏もコード断片のはり付けに終始してしまうことも多いのではないでしょうか。かくいう私も検索エンジン(を使ってコードを書く)プログラマになっていることが多々あります。 JavaScript にあるこのプログラムの自作を妨げるのは、ブラウザごとに仕様が違ったりとか、正しいはずのコードが動作しなかったりと、プログラミング言語としての特殊性が挙げられると思います。特に目的実現の為に必要となる発想は他の言語と一線を画します。 今回は、 題材は、これです。 誰でも一度は使ったことがあるだろう灰色の説明文付きの入力欄ですね。 簡単な例 さて、作ってみましょう、ということ

    JavaScript の不思議な面白さ
  • 画面設計とか外部設計とか、もうやめようよ - masayang's diary

    昨日は特徴(Feature)、粗筋(Story)、脚(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう? 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え

    画面設計とか外部設計とか、もうやめようよ - masayang's diary
  • 1