Mozilla Re-Mix: FirefoxでGUIを使ったプロトタイプを作成できるアドオン「Pencil Project」
Webサイト製作時や、製作依頼時、イメージを伝えるのは基本的なことです。 このような表現は、手書きでもいいのですが、より実物に近いイメージで表現するためには雛形となるサンプルHTMLを書いたり、その他のローカルツールなどを使うほうがいいですね。 いわゆるモックアップや、プロトタイプというようなものですが、この作業をFirefoxで行うことができるおもしろいアドオンがあります。 「Pencil Project」は、通常、ローカルの各種ドローツールなどで製作することが多いモックアップ作成作業を、Firefoxから起動して製作・イメージ保存をすることができるアドオンです。 インストール後、ツール→[Pencil Sketching]を選択すると、別ウィンドウにてツールが起動します。 画面は、左側にパーツ群、右側にキャンバスが表示され、左の各GUIパーツをキャンバスにドラッグすることで配置し、それ
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
ヒューマンエラーじゃなくてデザインが悪いんです: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 そうそう。ヒューマンエラーじゃなくてデザインが悪いんですよ。 だんだんと真実は明らかになってきた。私は、ヒューマンエラーや産業事故の研究をするようになった。そしてわかったのは、人がいつでも不器用に行動するとは限らないということだった。いつでもエラーをするわけではない。エラーをするのは、その物がよく考えられていなかったり、デザインが悪かったりするときなのである。それなのに、いまだにこの世の中で起こったことはみなヒューマンエラーのせいであるとされているようだ。 ユーザビリティについて考える際、何より大事なのはデザインに関わる人が、デザインの良し悪しによっては使い人がエラーを起こすことがある、使う人の行動が不器用な感じになってしまうことがあるってことをどれだけ自身の問題として意識
隠れていた事実が出てくる質問の仕方
「業務理解」というと，システムの設計者やベンダーの業務理解のことを思い浮かべがちであるが，私は何よりもユーザー自身の業務理解に問題があると思っている。ユーザーたちは，日々，自分たちが行っている業務をどこまで理解しているか，あるいは共通認識を持っているか，という問題である。 要求定義プロセスで十分なヒアリングができる相手というのは決して多くない。場合によってはたった一人の現場担当者からすべてを聞き出さなければならないこともある。現場は多忙だというので，もっぱら部署長がヒアリングに応じてくれることもある。 ある部品メーカーの調達システムを見直すというので，購買部長の指名でHさんが要求定義に付き合ってくれることになった。私は，別にHさんを疑っていたわけではないが，隣の部署にいるTさんにこんな質問をしてみた。 「Hさんは，購買業務全体について何％くらい把握されてますかね」 Tさんの返答はこうだった
要求仕様戦争（その1）
■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体
わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Presentations Adds Shapes
higaさんによるダイコン時代の設計方法 - tpircs