Archive for the ‘未分類’ Category

Google、新しいAjax APIを披露

金曜日, 5月 30th, 2008

記事によると「デベロッパーはPrototype、Script.aculo.us、jQuery、Dojo、MooToolsといった人気フレームワークを使ったAjaxアプリケーションを手早く簡単に作成できるようになる」と書かれている。 別のフレームワークを試したいときやバージョンを更新する際にダウンロードしなおす必要がなくなる(今後新たに優れたフレームワークが発表された場合もGoogleがサポート追加すれば使用可能)が、Googleのアカウントを使用するため、Googleのサービスに依存することになる(フリーなのでいつか使用できなくなった場合でも文句は言えない)。jsapi のロードと jQuery のロードの2回リクエストが発生するので、本格的な開発には向いてないかな。

テキストを読み上げてくれるサービス「Read The Words」を使ってみました。

金曜日, 3月 21st, 2008

http://readthewords.com/ サイトによると以下のファイルを読みとって、それを読み上げる音声が入ったMP3ファイル化してくれるそうな。 直接テキスト内容をコピペ Word、PDFファイル Web上のサイト(URL) RSS で、一番難しそうなWebサイトで試してみようと思って適当なURLを選択。 ちなみにこのサービスは英語、スペイン語、フランス語までサポートしているようなので英語のサイトをチョイス。 事前に会員登録をする必要があるので、それを済ませて早速試してみました。 ファイルを生成するときのオプションとして話す時の人と音声スピードが選べるみたいなのですが、とりあえずデフォルトのままでやってみたら音声が早すぎて聞き取れず。。 選択したサイトのHTMLをうまく解析してくれなかったのかなと思って今度はテキストを貼り付けて、かつスピードも一番遅いのを選択してもまだ早すぎて聞き取れず。なんだか2~3倍速したような感じなのでリスニング力云々以前の問題。 というわけで結局使えるものではなかったですが、技術としてはかなり高度なことをしているはず。日本語をサポートして使えるものがAPIサービスとして提供されるようになれば何かしらの利用価値が出てくるかもしれませんね。 ↑元となるファイルや音声スピードとかを選択し、Submitすると音声ファイルの生成がスタートします ↑生成したMP3ファイルをその場で聞いたりローカルに落としたりできるみたいです。

Paper Prototyping検証 まとめ

金曜日, 3月 14th, 2008

長い間、検証を進めてきたが、ここで、おれ等流PPのためのツール、および、PPを利用したユーザビリティ調査の手順をまとめておく。 おれ等流 ツール類 for PP 画用紙(八つ切り以上のサイズ) マジック(黒×人数分、赤、青) はがせるテープ(検索窓に書き込んでもらって、それを結果画面に利用などの用途) テープ(修正用) はさみ 蛍光ペン ダンボールか新聞紙(背景用) 未使用コピー用紙(下書き、トグルのヒンジ、その他応用可能) おれ等流 PPを利用した・・・(中略)・・・手順 キックオフミーティング コアチームを組む 目標、リスク、考慮事項などについて話し合う ユーザーのプロフィールを想定する。 スケジュールを立てる ユーザーの募集(今回は社内人員なので略) 新規の成果物であれば、ここで、おおよそのイメージを共有して確認しておく。 課題設計 ユーザビリティテストに利用する課題の内容を決める。手順1で話し合った目標、リスク、考慮点などを参考にすること。 プロトタイプの作成 ここに一番時間がかかる。 画面遷移図のまとめ 作業分担を決める。 コピー用紙で下書き&文字サイズのサンプルを作成しておく インターフェース動作をインデックスカードにまとめて、分類しておく ウォークスルーテストを行う。 改善しておく点が一致したら、改善を行う。 心の準備 ユーザビリティテスト テストの実行 テストの振り返り 次のテストの前に改善点があればPPを修正する。 問題点のまとめ テストで挙がった問題点を分類・整理する。 問題点の対応方法・(問題点が多ければ)順位付け 改善の実行 ウォークスルーテスト (※)必要と余力があれば、7番から6番に戻ってもいいかも この最終成果物は、インターフェース仕様書とインターフェース動作仕様書である。 使ったフォーマット 課題シート フォーマット化したいもの インタビューシート インターフェース動作仕様シート、もしくは、インデックスカードの内容

Paper Prototyping検証 第5週目

金曜日, 3月 14th, 2008

今日は、いよいよ被験者にPPを使ってサイトを使ってみてもらうことになった。 被験者 ()内は想定しているユーザープロファイル -- A氏(業務でWeb開発を行っている:jQueryで製品を作る:Javascriptは上級:jQueryを既に利用している) B氏(趣味でWeb開発を行ったことがある:jQueryには興味がある:Javascriptは初心者:jQueryは初めて) C氏(業務でWeb開発を行っている:jQueryで製品を作る:Javascriptは中級:他のライブラリを利用している) D氏(業務でWeb開発を行っている:jQueryに興味がある:Javascriptは初心者:jQueryは初めて) 4名の方は、ユーザープロファイルにもっともマッチしてそうな社内の人に時間をもらった。 課題に関しては事前に準備したシートをプリントアウトして、各被験者に実行してもらいたいテーマをそれぞれ提示して、テストを行った。また、テスト実施側3名の役割分担は、1名は、記録係固定(経験があるので、比較的、経験をつまないとならない他の役を2名にゆずる)、他2名はコンピュータ役、進行役を被験者ごとに変えて実施することにした。 さて、テスト本番。一人ずつ被験者に来てもらい、今回の目的、テストされるのは、プロトタイプであって、被験者でないことを一通り説明し、課題説明に移る。 第一の被験者に対しては、社内の人相手ということもあり、フランクすぎる雰囲気になってしまった。リラックスしてやってもらうつもりで語りかけていたが、逆にぐだぐだな感じに・・・なかなかもって進行役は難しい。 人の話、感情を引き出すということがこんなにも難しいことだとは思わなかった。職歴上、こういうことに長けている、記録係固定のメンバーに助けてもらう場面も多々あった。あとで聞くと、被験者に対して、「弟子入りするような気分で」接していないとのことだった。被験者の声に真摯に耳を傾け、想定していたユーザープロファイルと異なっていれば、それに応じた課題に変更するなどして、テストを行う。最初から決め付け、こうだろうという気持ちがあると、それが態度に表れて、被験者に伝わってしまい、最悪、被験者側が、そのイメージに合わせた形で、テストが行われてしまいかねない。相手のことを知りたいんだよという態度でなければ、コミュニケーションは失敗する。 今回の進行役を務めた中で、本当に最悪だと思ったのは、あまりに予想外だった被験者の反応に対して、意外だという感情をストレートに顔に出してしまったことだ。テストされているのはプロトタイプなのに・・・。 さて、課題そのものの内容に関しては、簡単な課題なので、あっという間に終わってしまうんではないかと思っていたが、やってみると、案外と、人それぞれ、いろいろな方法でサイト操作を行っていることが確認できた。そのときの気持ちも言葉にしてもらうことで、どういう部分で悩むのかがよりわかりやすくなった。 このあとの見直し作業に関しては、記録係が記録した被験者インタビューの内容から浮かんだ問題点を、PPのインターフェースに関するものと、テストに関するものに分割し、後者は今後の反省点として生かし、前者は、さらに分類していく。このようにKJ法を用いて、問題を分類、整理し、すぐ対応したほうがいい問題点を選別して、PPに反映する。PPの修正は慣れたもので、ピックアップした2つの改善点を20~30分ほどで行った。PDCAをきっちり回す。 この後、ウォークスルーテストを行い、思ったとおりの改善が行えたか確認し、一旦PPによる開発の実験を終了した。 さて、この見直し作業で、課題図書を読んで手順を確認してみたが、この見直しの部分で、面白い記述があった。 インターフェース仕様書=PPとして利用できる。確かにPPの目的のひとつではあった。 インターフェース動作の文書化。PPはインターフェースの要素を示すもの。それらがどのように相互作用するかといった情報、カーソルのようにプロトタイプ化が難しい要素の動作に関する情報はコンピュータ役の頭にあったりする。これらの情報をインデックスカード化する。でも、これはテストの前に作っておくべきものではないか・・・早く言ってよ・・・ <今週の成果>  インタビューは相手のことを知りたいという気持ちで臨む。いいたいことを言ってこうでしょ、ではまったく意味をなさない。 こうすべきというイメージを持って臨むのはNG。 PDCAをしっかり回して、どんどんとPPを改善することに意義がある。インターフェース仕様書をブラッシュアップしていこう。 PPの修正は、手馴れてくると、どんどん早くなっていく。修正を恐れずに、修正すべき点の検討に時間をかけよう。 インターフェース動作を文書化しよう。学生時代に使った英単語・熟語を覚えるための、リングつきインデックスカードでもいい。そして、これは、テストの前に一度整頓しておいたほうがよいだろう。

Thebigwordproject.com - ことばを再定義しよう

水曜日, 3月 12th, 2008

先月末にアイルランドの学生がRubyOnRailsを使って開発したサービス「The Big Word Project」。 The Big Word Project is redefining words. You pick a word and link it to your website. Your website is then the new definition. 要は単語を買って、自分のサイトにリンクさせよう、というサービスのようです。 サービス提供者にとってはサイト内にたくさん外部リンクできるし、 ワード買った人は自分のサイトの被リンクが増えてラッキー、といった感じでしょうか。 金額は、1文字$1。支払いはPaypalです。 ちょっと面白いのがFAQのページ。 What if I don't have a website? Why not link the word to your Bebo, Myspace, Facebook or Flickr account? Or even buy a word ...

Gmailをバックアップするツール - 危険なのと、(多分)安全なの -

火曜日, 3月 11th, 2008

Gmailをローカルにバックアップするツール、G-Archiverについての危険な話が出回ったのは、先週末のことでした。 バックアップのためにツールに登録したID/PWDが全てツールの作者の元に送られていくという恐ろしい仕様で、このツールを使った全ての人のメールは筒抜けだったそうです。これを$29.95取って代行もしていたというのだから、大したものです。 そこですかさず、と言いましょうか。Googleの伝道師 Matt Cutts氏が自身のblogで、彼が使っているGmailのバックアップツールを紹介しています。 こちらのgetmailも当然ながらID/PWDを要求しますが、怪しい罠がハードコーディングしてあるようなことは無いのでしょう。多分。 バックアップツールに限らず、最近はSocial系のサービスを利用していると、友人リストを取得するためにGmailなどのID/PWDを求められることは、よくありますよね。 確かに便利ですが、安易にばら撒きすぎないよう自己防衛が肝要かと。 # 筒抜けで良いようなアカウントを持っておくのも手ですが。 記事では他にも、getmailにprocmailを組み合わせて更に強力な振り分け機能を実現している記事へのリンクなど、Gmailを便利にバックアップするための方法が色々と紹介されています。 便利だけど、たまにデータLostしたりしているGmail。自分のLinuxでバックアップしておきたい/好きなエディタで編集したい/もっと融通の利く振り分けや転送をしたいと思っている人は、挑戦してみては。

CAPTCHAによるSpam防御は崩壊寸前?!

火曜日, 3月 11th, 2008

少し前ですが、Virtual BlightでCAPTCHAについての記事がありました。 Coming Captcha Crisis CAPTCHAとは、会員登録などで近年よく見る、わざと読みにくい字を書いて「アンタ、人間だったら読めるよね?」と訊いてくる失敬なアレです。 # HOME'S会員登録でも使ってます しかしコイツがなかなか役立つもので、これが無いとSpamの群れにたちまち溺れてしまうワケです。 いまやe-mailもblogのコメントも、9割以上がSpam達。 こんな非生産的なことに心血を注ぐ不毛な業者がいなくなれば、Webライフもかなり快適になるのにと臍を噛む思いでいっぱいですが、害虫と同じで撲滅されることは無いんでしょうね。 そんな頼れるCAPTCHAですが、ロシアの研究チームによると既に30~35%はロボットで解読できてしまうそうな。 ただでさえ「読みにくい」文字列ですが、防御のためにますます歪みの度合いは増していきます。 実際、リンク先の記事にあるスナップの下段のものは、自分は読めません。 スパムロボットでの解読精度が上がってくれば、ますます読みにくくなっていき、やがては「人間では寧ろ読めない」になってしまうのではないかと心配になってきます。 非常に本質的で無いですね。 そこで、ひとつアイディア。 CAPTCHAで読めた内容を、単に「文字列」として書き写すのではなく、更に意味を理解して答えを出す形にしてはどうでしょ。 例えばCAPTCHAで表示される文字列に「昨日の曜日」とか「人偏に主」とか。 複数のエンジンが必要になるというのは、単に2種類の鍵をかけるって程度の意味しかないかもしれませんが、同じ種類の鍵でなくて錠前とダイアルなら少しは効果があるはず。 ...作ってみようかな。

最新ブラウザ界を席巻する「ロボット」ブーム

日曜日, 3月 9th, 2008

IE8について近年稀に見る好意的な評価が相次ぎ、Silverlightへの期待感も相まって、久しぶりに熱いブラウザ事情ですが。 一定の地位を確立した(かに見える)Firefoxのバージョン3が衝撃的なウェルカム画面を表示したのに続き、OperaもSXSWで真っ向から対抗する構えの様子。 最新ブラウザ界は俄かに巨大ロボット旋風が吹き荒れていますが、時代が今更先行者に追いついたとでも言うのでしょうか、今ひとつ理解できない今日この頃です。 しかし「理解できん」と投げてしまえばそこで終わり。 ひとつ、Firefox3のロボットにまつわるストーリーを読んで(※)みましょう。 ※今年の頭に公募されたロボットストーリーコンテスト。かなり意訳してます。 よく解析したで賞 このロボットは悪者には見えないよね。きっといいヤツさ!まるで映画バットマンみたいに、ビームで空中にFirefoxのロゴを映し出しているしさ! きっとコイツは、そのパワフルなボクシンググローブで全ての悪者と戦い、Flashのように高速に移動するよ!(耳のあたりにFlashの印が見えるだろ?) そして、バグやビルを攻撃している悪いUFOなどの、どんな攻撃だって跳ね返すように造られているね。 世界はFirefox3を必要としてるのさ! 頭についているアンテナは、世界中に情報を発信するよ。 世界は暗黒に包まれてきているけど(陽が沈んでいく背景が見えるだろ?)、彼は休みなくいつだって、最後まで戦い抜いてくれるさ! Firefox最高! Matrixの続きで賞 この写真は2011年に"マイティー・Firefox"の撮影が終了した時に撮られたものです。 巨大ロボットは、ライバル企業によりMozillaの本社を破壊するために造られました。しかしもちろん、ロボットは彼らのプログラムの持つ力を発見し、虚空にFirefoxとThunderbirdのロゴを浮かび上がらせるのです!それは、世界を変えるために。 抽象芸術賞 そう、私が思うに...あのロボットはFirefox3だね!そして、あのビル群はInternetExplorerさ - 見たまえ、あの3つのビルの突き出た様を - 横たわる"E"、そして"I"は既に逃げ出してしまったようだよ。あのUFO - IE導師による非標準HTMLにより、君を手酷く打ち据えるバグ共 - を恐れてね。 ...やっぱり、理解できません。

Paper Prototyping検証 第4週目

金曜日, 3月 7th, 2008

さて、今週はユーザビリティテストまでいければいいなと予定を立て、作業を開始した。 まず、先週の後半の進歩 <図1:修正前(周辺にあるもの)と修正後(中央にあるもの)-- 必要以上に字が大きかった・・・> そして、次に ウォークスルーテスト(チーム内でのテスト) <図2:ウォークスルーテスト中の風景。決して取調べではない> という感じでプロトタイピングの作成、ウォークスルーテストまで完了して先週は終わった。 このウォークスルーテストで、ここはこうしたほうがいいんじゃないか、これはまずいよね、足りないページや機能があるじゃん、ということがわかった。 このように、次のステップのユーザビリティテスト本番の前に、チーム内で一度テストしてみることは、とても有用である。作成中でもあるが、実際に、ユーザーになってみることで、こうしたほうがいいかもとか、ここはユーザーがどうするか見てみたいだとか新たな課題も見つかることがある。 この中でチームで同意ができた改善点について、修正を行い今週の午前中は終了した。 念のためウォークスルーテストの第2弾を行った。PP自体の課題は解決したようだったが、一点だけ気になったことがあり、検討。 <気になったこと> 被験者が平らな机の上のプロトタイプを座って見ると、実際のHPとは違う視線の移動になってしまうのではないか? PC上での視線:上から下 上記のテストの状況での視線:下から上 <テストでは> 今回は一回目は立ってやってもらう <他の案> ホワイトボード上で行う。被験者の背格好に合わせた高さにあわせるようにする。落下しないように、協力な磁石が必要となる。 紙芝居屋(古い)みたいな仕掛けを作る。 机の上で斜めになるような仕掛け 次にテストの場所となる会議室の準備だ。 保管していたPPを机の上に展開。テストを始めるまでは、裏返しておく。これは、テストを始める前の説明時に、PPが見えてると、その時点で、被験者がテストを開始してしまうことを防止するためである。また、机が白かったため、白い画用紙で作ったPPが溶け込んでしまうように見えたため、背景として、新聞紙か、ダンボールの裏を利用することとした。新聞紙をメンバーが持っていたので、それを試す。新聞紙は、文字があるので、テスト中そちらに気がいってしまいそうに思えたが、今回は、ちょうど新聞紙の記事の部分のサイズとPPが同じぐらいのサイズだったために、背景としては、抜群だった。 と、準備ができたところで、会議室の予約時間が過ぎたこと、本業のトラブルなどが重なり、ユーザビリティテストは次の週に持ち越しになった。 第4週目の成果 上記の気が付いたこと テスト場所の下見

YouTubeを超高画質にするFirefox Extension

木曜日, 3月 6th, 2008

先週来「YouTubeをハイビジョン画質にするHack」がblog上を駆け巡っていますが、Firefoxの拡張機能であるBetter YouTubeを使えば、パラメータをいじったりしなくても同様のことが出来ちゃいます。 それだけ。