You are currently browsing the category archive for the 'Web関連' category.
さてー!
Podcast始めました。
始めましたってほど、始めていませんが。
つまりPodcast用ブログを作って、1年前にとった音声をアップしてみました。
友人であり仕事仲間の緑川(withoutsugar)さんとのふたりPodcastです。
よし、やるぞ! という感じです。
喋りがうまくなれるように頑張ろうの一環でもあり、今後に期待ということで。
ターゲットもテーマも考えず、ただ会話している段階でございますが。
よろしければ、お暇なときにでも。
(むしろ、お暇なときしか、聴いてはいけないくらいの)
購買意欲を刺激する行動ターゲティングLPO という記事に、ネットユーザの行動特性として以下があげられていた。
1 ネットユーザは、1回のサイト訪問では意思決定を行わない。常に、サイトへの再訪問を繰り返す過程で購入決定を行います。
2 ネットユーザが購入するまでに繰り返すサイトへの再訪問の期間は、購入対象となる商品・サービスにより、1ヶ月未満や3ヶ月など様々です。
(後略)
確かによく言われることだ。
「1回では買わない」
だからこそ、メルマガやfeedを購読してもらって再訪問を促したり、再訪問時に行動や属性からターゲティング広告を表示させたり、ショッピングカートには以前追加したものが長く保存されていたりする。
ところでわたしは、かなりなネットショッピンガー(造語)である。オンラインで何かを買ったり申し込みをすることが非常に多い。回数も種類もかなりのものだ。ただ金額だけは、たいしたものじゃないかもしれない(そこは意志ではどうしようもないからだ)。
さてそんなハードショッパー(造語)なわたしは、
「たいてい1回で買う」
あるいは、
「たいてい1回でカートには入れておき、たまったら購入する」(小さいものが何度も届くのが面倒なので)
もちろんほしいものであり、財政状況が許したときだけだが。
パソコンやら高価なものを買うときは、何回か見積もりをしてみてドキドキしていることも多いが、それは財政的なものを吟味しているからであり、通常のリアル店舗であってもそれは変わらない。
ネットだから……ということではなく、商品の値段や特性(実物を見て触ってから決めたいとか)によると思うのである。
思うに、一回では買わない理由としては、最たるものはこれだろう。
「他店を回って価格やサービスを比較するのが、リアルに比べれば楽」
検索して出てきたサイトを通常巡るだろう。
で、比較してみて気付くはずだ。
なんかどれもそう変わらない。
そして一番きちんと作られたふうな綺麗なサイトで買おう、と思う。差別化ポイントがうまく表現されてないから、見た目で信頼性を決める(そして、1回買って問題なければ、2回目からはたいていそこで買う)。
「他店を回って価格やサービスを比較するのが、リアルに比べれば楽」だとしても、比較するのはやはり重労働なのである。特に、何かひとつの比較ポイント(高くても絶対に明日送付してくれる店、とか)がある場合は比較も楽だが、たいていは総合的に比較したい。そうするととたんに面倒になる。比較事項がリアルより多いし、それぞれ記載の仕方やユーザビリティがまちまちだから。
そんなわけで、そういう経験を繰り返していくと、こうなる。
「比較するのも大変なので、労力考えると1回で買ったほうがお得じゃない?」
オンラインでものを買うのになれた人間は、ネット怖いものだという幻想を捨て(リアルと同じくらいには怖いですが)、ショッピングスキルもあがるのである。より短い時間で、手間をかけず納得できるものを手に入れる。
それから、他店と比較するときも、タブは開いたままというのが多いのでそれは1回の訪問と考えてもいいのではなかろうか。
このあたりも、スキル的な問題であり、人々がタブブラウジングに慣れてくれば解決すること。
人間は成長するのだ。
一見さんも成長しているし、リピーターも成長している。
サイト構築・改善過程で言えば、ペルソナも成長していかなきゃいけないし、いつまでも「ネットユーザは1回じゃ買わない」と言い続けることもできなくなるはず。こういうのは、標語みたいにずっと言い伝えられてしまうから気をつけようと思う。
携帯を使い慣れた人が主要顧客になった場合の行動特性はどんなだろうとかー。
結局は、そのWebを使うのは主に誰なのか、ということを考えるしかない。
わたしはひとりのペルソナのために作るサイトが好きだ。
本だってそうだ。誰のために書かれた本かがわかるほうが読みやすい。たとえターゲットに自分が含まれていなくても。
(12月から書こうと思っていた話題をここでひとつ)
日本ウェブ協会主催の「アックゼロヨン・アワード2007」、Web制作業界の人ならご存知と思われますが、優れたコミュニケーションを実現するウェブサイトを表彰するアワードであります。
で・・・
審査員の面々もさすがにすごい方々だなー、と見ていくと、

なぜかわたしの名前があったりします。
我ながら、すごく、違和感を感じるわけですが(笑)
そんなわけで、ありがたいことに、一次審査員をやらせていただくことになりました。
12月には決まっていたことなので、早く書こうとおもいつつ、こんな時期になりました。
こんな時期って、応募期間終了間際という意味でございます(わー)。
応募期間は、2008年1月31日(木)まで!
あと一週間をきりました。
募集部門は、5つあり、「コーポレートコミュニケーション部門」「セールスプロモーション部門」「エレクトロニックコマース部門」「アカデミック・エデュケーション部門」「公共・地域振興・その他のコミュニケーション部門」という感じです。
アワードというと、敷居高い感じがするが、わたしが審査員でいるということは中小規模のサイトでも全然いけるのだという証明でもあると思うのです。
わたしは、「優れたコミュニケーションを実現するウェブサイト」は、必ずしも完璧である必要はないと思う。
新しい試みであったり、視点の違うものであったり、地道なものであったり、変なものだったり、人が集まるものだったり、何かぐっとくるもの、誇れるものがあれば。
過去のアワードを見ると、やはり誰もが知っている系のサイトが多いなあと。
今回は、もっと知らないところとか、変なところ(?)が受賞してほしいと思ったりしています。個人的に。
応募サイトを見るのが楽しみです。
Lifehacking.jpで書かれているライフハックの記事は、小手先でない感じだから好きだ。feedを購読して、よく読んでいる。
年始の「1日ずつ人生を積み上げてゆく、Project 365」というエントリーが気になっていた。
Project 365は、「毎日、1枚写真を撮影する」という、それだけのプロジェクトなのだけど、毎日何かを続けることをあまりしてこなかったわたしには、その手軽さや楽しそうな感じは、とても魅力的なものだ。
もちろん、写真を撮り続けることによってメリットもある。上記ブログから引用。
そこまで苦労する Project 365 のメリットは、いうまでもなく振り返りが一目瞭然となるところです。今年一年何があったのだろうかと思うときに、百聞は一見に如かずで出来事を写真から思い出せます。
そんなわけで、始めることにした。
このblogか、Voxで写真日記のようにするかどうかは迷っているが、とりあえずFlickrにアップしていくことに致しました。
さらに、 [cipher] さんが作られていた「Project 365+1 JAPAN -2008-」というFlickrのグループにも参加。
既に、一日撮り忘れがありますが(笑)、気合いれすぎない感じで続けていこうかと思います。
ちなみに、Project 365だけでなく、Project 100 とかにして、年間100冊本を読むとか、そのような感じで自分なりのプロジェクトを作るのも良いわけで、そっちもやりたくなったり。
本読むのが好きとは言え、時間は有限だ。年間100冊って、意識してないと達成できない量だろうと思うのです。挑戦しようかなー。
reaさんという 神戸 加古川在住のWebの人(職業をなんと表していいのかわからない)のpodcastにおよばれいたしまして、対談のようなことをさせていただきました。
それが本日公開!
しかし、エントリーに不可解な一文が・・・
堀内さんは話し方がとてもうまく、自分のほうがリードされてしまいました…。しゃべりのスキルがまだまだ未熟だと痛感しました (汗)
たぶん、わたしの喋りをうまいというのは、世界中でreaさんだけだと思います。
わたしのことを知っている人は皆そう断言することでしょう・・・。
普段から、片言とか、イントネーションおかしいとか、どこの人間ですかとか、言われ続けております。
このPodcastも、どうやら恥ずかしすぎて、もう二度と聴けない気がします。
いや、10年くらいたったら聴けるのだろうか。
まだ、外でたくさんの人に対して喋っているときのほうが、恥ずかしくない気がする。不思議なものだなあ。
そんなことより、内容の話をしよう。
法人化したときのこととか、そのあたりのことを喋りました。
それでひとつ、大事なことを言い忘れたなと。
法人化して何が変わったか、のあたり。
スタッフができ、一緒に仕事をしているときに、彼女がふと言ったひとこと。
「うちの会社」
うちの会社! このひとことは、驚くほど、わたしを喜ばせました。
自分の会社のことを「うちの会社」と呼んでくれて、一緒に何かに立ち向かってくれて、一緒に大きくしましょうねと言ってくれる、大切なスタッフ。かなりキュンと来ますし、守りたい、と思います。
外注さんたちと仕事してたり、プロジェクトでチーム組んだりというのとは、全然違った感触です。
そんなこんなで、つたない喋りで申し訳なかったですが、楽しかった。
reaさん、ありがとうございました!
realog casting 、わたしのはさておき、他に対談されている方は、有名な方が多くおられますので、聴いてみると面白いと思います。ぜひ。
「あれをそれするいくつの方法」というようなタイトルのブログ記事や書籍に食傷気味なのはわたしだけだろうか。
タイトルに数字をいれると、読者をひきつけやすいと言われだして何年なのかな。けっこう長い気がする。
はてなブックマークを見ると、「なんとかする方法」「なんとかする理由」「いくつのなんとか」、などのタイトルが幅をきかせているのがわかる。
今も、はてなブックマークのホットエントリ1位は、「モチベーションは楽しさ創造から - なぜ、あの人には教えたくなるのか? 教わり上手な人の8つのTIPS」というタイトルである。
いやしかし、それでも一時期よりは減ったのかな。
執筆者も読者も、そういったテクニック的SMOに飽きてきたのだろうか。
「あれをそれするいくつの方法」と題してリスト形式で書かれた記事は、確かに読みやすいと思う。
拾い読みしやすいし、まとまっている感じがある。論理的に見えるのも良いのかもしれない。
たとえば便利サイトのリンクを一覧にしたり、難しいことを簡単に見せるために箇条書きにしたりといった、意味のあるリスト形式は素敵だと思う。
しかし、リスト形式では逆に伝わりにくい場合があることを、心に留めておいたほうがいいと思う。
リスト形式でまとめられた記事は、その見出しを広い読みして、ふーん、と思って終わることが少なくない。「ふーん、なんか、当たり前のことばかりだな」という印象を持ってしまう。
良いことが書かれていたとしても、それを簡潔にまとめた見出し的な一文は、ごく一般論的な文章になりやすい。
よっぽど興味がないと、詳しい内容部分は読まない。もったいないし、それでは執筆者の本当に伝えたいことが伝わらない。
たとえばこの記事の場合は、「『あれをそれするいくつの方法』では心を掴めない7つの理由」というタイトルをつけたとしよう。
記事の中身はこんなふう。
- 理由その1 タイトルにそろそろ食傷気味
- 理由その2 SMOのにおいがしすぎ
- 理由その3 リスト形式の記事は拾い読みしかされない
- 理由その4 ・・・・
- ・・・
といった感じで、それぞれの理由をリスト化し、それにやや詳しい内容の段落を付ければOK。
記事を書く前にプロット出しをしてそれに軽く肉付けする、という行為だな、と今やっていて気付いた。型が決まっている分、書きやすいし、頭も整理される。キャッチーに見える。読者にしてみれば、自分の興味のあるとこだけ拾い読みできる。
でも、何か魅力が失われた。その人らしさというか。
これでは誰が書いてもそう変わらない気がしてくる。これらの箇条書きは並列でいいうのかという疑問も残る。
理由は7つあったとしても、伝えるために3つに絞ることも必要じゃないのとか。
思うのは、何かが伝わるのは、文章や理屈がストーリーや背景を持ったときだということだ。
それは、大勢の人の前で話をしたときにも痛感したし、日ごろ読書していても感じる。
何回かこのブログでも触れたかもしれないが、「正論」や「一般論」は耳を素通りするのだ(正論に萌える思春期もあったような気がするけど)。
読みにくくても、味のある文章が好きだー、という、これは個人的な嗜好なのだろうか。
ところで、「なんとかする方法まとめ」という、タイトルも人気だ。
CDのベスト版に対して受ける印象と同じで、便利だけど……という。
# 夜中にふと起きたので、ブログした。
# 朝だけどもう一回寝る。
# あっ。このくらいの長さの記事になる場合は、見出しを途中で入れたほうがいいと思う。と、自分にダメ出し。
# おやすみなさい。
今まで「普通って何だろう」という問いかけに何度か接することがあった。
辞書で調べると、一般的なこと、他と変わらないこと、めずらしくないこと、などと書いてある。
自分では、「普通イコール平均的ということかな」と答えることが多い。
先日、F-shinさんのブログでこんなエントリーがあった。
システム仕様の話でなく、施策レベルでの仕様を検討するときに「普通はこうなってるからこうした方が良い」と言われるのは勘弁して欲しい。
あるある、とうなずける話である。
人からそんな言葉を聞くこともあれば、実はわたしも、「普通はこうなんですよ」と押し切ってしまうこともある。デザインの話をしていても、戦略の話をしていても。
ただ、それはたいてい説明を省略しているときだ。付き合いが長く、リテラシーが高いクライアントの場合は、「普通」を読み取って変換してくれるので、単純にそう言って話を進めてしまったりするのだ。
その場合の「普通」とは、前例があること、平均的であることであり、つまり「ユーザが慣れている」ということだ。
だから、それを踏襲することが、今現在の使いやすさを追求する一番早い方法である場合がある。
新しい動線、新しい使い勝手、新しい何かを求めて、考えて、それを実現したり普及させていくのは大切。だが、今まで慣れた方法をやめて、それを一度にやるのはリスクが大きすぎるのである。
人が新しいことに慣れるには、ストレスがかかる。新しい職場、新しい環境、新しい人間関係、新しいパソコン、新しいソフトウェア、新しい手順、新しい……。
たとえば、先日わたしは、マシンをmacに変え、使うアプリケーションを変え、キーボードを日本語キーボードから英語キーボードに変えた。それによる、ものすごいストレスと、生産性のものすごい低下は、覚悟していた自分でも驚くほどであった。
「新しいもの」で成功した例として今よくあげられているのは、iPhoneだろう。
今までの携帯電話とはあまりに違うインターフェイスだ。
だけど、たとえば写真を見るとき「普通はこうする」だろう動作を、指で行えばページがめくれるし、拡大もできる。
これはちょっと余談なんだけど、思うのは、まったく新しいインターフェイスだからこそ、アナログ的な指でめくるという動作に慣れるのも早いのだろうということ。脳にもカラダにも心にも何らかスイッチが存在すると思うので(たとえば、わたしは黒いキーボードだとwindows的ショートカットを、白いキーボードだとmac的ショートカットを無意識に使ってしまう。色がスイッチになっている)。
さて、iPhone、Appleではないところが出したら、どうなってただろうか。
Appleが今まで作ってきたブランドやファンがなかったら、成功の可能性はぐっと減っただろうと思いませんか。
普通でないことをするには、それなりの覚悟とか相応の準備が必要なのだ。
単に普通を嫌って新しいものを求め、失敗したことは何度もある。
新しい造語を使ってみただけで、ユーザに全然理解されなくなっちゃったWebサービスに関わったこともある。
特に小規模案件では新しいものを取り入れすぎると、初速が出なくて失敗するケースが多いという印象がある。
普通って思ったより大切ってことだ。
とは言え「どうして普通が良いのか」を説明しなければ、単なる手抜きや妥協案だと思われるので、言葉には気をつけたほうが良い。
新しいものを取り入れるときは、ひとつずつ。多くてもふたつ。
ユーザに「新しいものを理解する」というストレスを与えるのならば、必ずそれ以上の何か(楽しさや気持ち良さや……)を提供することを忘れてはならないと思う。
と、書いてみましたが、やっぱりわたしは技術者でも芸術家でも発明家でもなくて、商人とかそっちのあたりですね。
普通を嫌ってメチャクチャやってくれる会社も見てる分には好きだ。
ギャンブラーというかチャレンジャーというか。
イノベーターってそういう人たちなのか知らないけど、憧れる。
余談:
「普通」と「普通でないこと」のバランスが大切だねって話になっているような気もするけど、「バランス」という言葉もサラリと使うとただの便利な言葉になってしまうので注意したい。
「大事なのは結局コンテンツだよね」というのと同じで、そこで話題が止まってしまう危険がある。
こんなタスク管理ソフトがほしいという妄想の話。
左右のペインに分かれている。
左は1日のスケジュール、右はto doリストだ。
1日のスケジュールにはマスタがあり、それに1日の基本を(たとえば曜日ごとに)入れておける。たとえば何時に起きて、何時に移動し、何時にご飯を食べるなど。それらはドラッグドロップでもちろん移動や修正が可能だ。
そこへ、右のto doリストから、to doをドラッグドロップで配置できる。もちろんチェックボックスもついてくる。
そのタスクを終了したら、チェックを入れる。ほわーんとAjax的にフェードするが、消えるわけではなくてグレーで終わったタスクも見えている。
1日のスケジュールは、手帳におさまるサイズに印刷できる。手帳の基本的ないくつかのパターンのサイズは選べる。一日だけじゃなく、一週間を印刷することもできる。
1日のスケジュールは、人と共有することができる(その中でプライベート設定されたtodoは共有した人から見えない。代わりのダミータスクを見せることもできる)。
一日が終わると、終わったタスクが書き出されて、日報ができあがっている。そこへメモを書いて、送信ボタンを押すと日報提出ができる。日報は、週次、月次でまとめることもでき、振り返りに使用できる。
終わらなかったタスクは、明日の予定として書き出される。それに他のtodoも加えて、翌日のタスクリストとして、モーニングメールを自分に送ることも可能だ。
終わらなかったタスクは優先度の高い色がついて、また右のtodoリストの一番上へ戻り、翌日また配置されるのを待っている。
ひとつひとつのto doは、それぞれプロジェクト(またはカテゴリやグループ)みたいなものに属したり、属さなかったりできる。
プロジェクトに属する場合は、to do横のプロジェクト名にマウスオーバーするとそのプロジェクトのto doが一覧できる。クリックすると、プロジェクトのページへ飛び詳細も設定できる。
右ペインのto doリストは簡単にいうとrememberthemilkをもうちょっと簡易にしたもの。優先順位とか期限ももちろん決めることができるし、ノートも書ける。タブも作れて、たとえば仕事のtodo一覧と、プライベートのtodo一覧と、将来のためのtodo一覧とかに大別することができる。
あと見た目がシンプルで美しく、使ってて気持ちが良いもの。毎日使い続けるものにはこれが一番重要。
こういう妄想は止まらないのでここらへんでストップ。
現実化できそうな気がするんだけど、こういった話を人としてたら、自分で作るしかないよねという話になった。必要としてるものは、人それぞれ違うから、完璧にフィットするものなどないのだ。ろう。か。
今使っているのは、todo管理にはrememberthemilk、プロジェクト管理や、日報など勤務関連の管理にBacklogです。
どちらも素敵だが、スケジュール帳のような見方ができないので、こんなことを妄想した。
GTDについては2冊本を読み(3冊だったかな)、Web上の情報もけっこう追ったものだけど、見事に挫折していた。
(※GTDとは、「Getting Things Done」の略で、頭の中のごちゃごやを全部書き出して、スマートに管理して能率アップというようなもの)
どこで挫折していたか。
GTDには主要ステップが「収集」「処理」「整理」「レビュー」「実行」というふうに5つあるのだが、はや2つ目での挫折である。本当に早い挫折である。
ステップ1「収集」で、頭の中の気になっていることをすべて書き出す。これは出来た。ただ、A4用紙に何枚だったか、おびただしい量になった。唖然とした。
ステップ2「処理」で、書き出した事柄をルールにそって分類する。分類……途中で飽きてしまいました。すみません。目の前の仕事を優先してしまった。GTDを優先させることが急がば回れになるのだと頭ではわかりつつ。
ステップ3「整理」は、処理と同時にやっていました。つまり、処理しながらRemember the milkに書き込んでいたんですね。RTM はGTDに合っていると思う。一度挫折したわたしが言うのもなんだが。
ステップ4「レビュー」随時または週時で自分のリストをレビューし、ステップ5は「実行」。できていないので何とも感想はかけません。
さて、そんなふうに挫折したGTDだが、なぜまたブログしているのかというと再挑戦中だからである。
「どのようにしてGTDを実践するか?」という記事を見て、すべてのステップを完璧にやるという呪縛から解放され、じゃあどう簡略化するかという方法も学んだのだ。
GTDを一度にすべて実践するのではなく,簡単なことから少しずつ習慣づけてゆこうという試みも生まれました。それがZen HabitsのLeoが提唱しているZen to Done(ZTD)です。
第1回 どのようにしてGTDを実践するか?
全部で10の習慣から構成されているということで、それを聞くと「ステップ増えてるよ!」と思うが、全部やらなければならないということではないようで。
わたしが挫折したステップ2「処理」も、簡単なルールで行えば良い模様。
第2の習慣,インボックスの処理を高速化
ちゃんとGTDをしている場合には,「2分以下のタスクは実行」「それ以外はレファレンス,あるいはプロジェクトリスト,あるいは他人に回送する」といった複雑なステップが入ってきます。しかしZTDではまず,インボックスから取り出したタスクについて「これについて何をするつもり?」という質問だけに答えるように習慣を作ります。
第1回 どのようにしてGTDを実践するか?
さー、できる気がしてきましたよ。
ちなみに、わたしがこういった新しく学んだ方法/ツールを取り入れるときは、まず一回はできるだけ本来のやり方で進め、その経験をもとに自分でカスタマイズしていくことが多い。
どこが「抜けてはならない大切なこと」なのかは、やらずにわかることではないからだ。それは方法論を見つけた当人すらわかっていない場合もあるわけで。千差万別なわけで。基本は大切なのです。
でも挫折した身は軽い。
「基本に忠実にやる>簡易バージョンだけどやる>全くやらない」
というわけで、GTD再開である。挫折しなかったらまた報告する。
2007年7月15日(日)、16日(月)の2日間で
The Days of Web Standards 2007[Web標準の日々]
が開催されます。
昨年は1日で、「Web標準の日」だったわけですが、懐かしいですねー。
レポート書こうとして途中で挫折した記憶ももうどこか彼方へ・・・。
さて、今回の[Web標準の日々]は、1日4セッション同時進行で、多セッション行われるので、興味があるものを選んで受けることができます。
下記の各テーマごとにトラックに分かれて同時進行していきます。
- アクセシビリティ/ユーザビリティ
- XHTML+CSS、SEO/SEM、アクセス解析
- リッチメディア
- ECMA
- Webマーケティング
- Webディレクション
- ビジュアルデザイン
全部で何セッションあるのかは、わたしも把握していませんが、面子すごいです。選べないほどすごい。驚く。詳しくは開催概要をどうぞ。
そしてその中に、わたしが紛れ込んでいることに、自分でも動揺してしまいます。
Webディレクションのトラックで、お話をさせていただくことになりました。
ありがたいことです。
わたしが普段やっている、結果を出すためのWebディレクションのあたりにフォーカス当てて行こうと考えているところです。
エヴァンジェリストなタイプの人間ではないので、ワークも取り入れて、実践で使え、かつ何か新しくわくわくするものを! とか。
先日、ディレクショントラックのモデレーターの名村さんと打ち合わせをしてまいりました。
打ち合わせというか、自分の伝えたいことを聞いてもらい、「何を話してもOK!」とお墨付きをもらってきました。名村さん流の人の動かし方を垣間見た気が致しました。
あー。プレッシャーだけど、こんなすごいメンバーの中で話すのは逆に面白いのかもしれない。わたしのセッションを選んでくれる稀有な人がいたら、一緒に楽しみましょう。
このあたりが聞きたい、など要望がありましたら、コメントかメールいただければ嬉しいです。
追記:
チケットも6/1より発売開始されてます。良かったらぜひ。
「Webデザイナー募集」としたまま、長らく放置していた本サイトをようやく、ちょっとだけ更新。
相変わらず、自社サイトに関しては適当なのである。
とりあえず、lastRSSを使って、このブログの更新履歴を載せてみた。
lastRSSは、PHPで使えるRSSのパーサー(指定したRSSから内容拾って表示するもの)です。
検索してみると、MagpieRSSのほうが有名なのかな(解説ページがあるので使いやすそう)。
とりあえず以前にも使ったことがあるlastRSSを今回は使った。
設置は簡単
1. ダウンロードして解凍したものをサーバにアップ
2. キャッシュを保存するディレクトリを作ってパーミッションを777とかにする
3. RSSを表示させたい場所にちょろっとPHPを書く。
書き方は、公式サイトのサンプルをどうぞ。
と、手抜きの説明で終わる。でも簡単なのでぜひ。
PHPじゃない人は、JavascriptでRSS埋め込むのもある。
昔使ったことがあるのは、大黒屋本舗さんの jsRSS。便利でござった。
ヌ社の橋本社長の仕事がひと段落した頃を見計らって、ファイルの管理の仕方について質問をしてみた。
そのあたりで、いろんな苦労があるのでそれを人がどう解決しているのか知りたかったのだ。
なるほどと話を聞き、さらに質問したりしていたら、ガッっと振り返って睨んだ人がいた。
ヌ社のA氏(※)である。
(※ オンとオフの差が激しい、優秀だったり子どもだったりするところがナイスなシステム屋さん)
ピンと来た! とA氏は言った。
困っていることがあったら、それを解決するシステム作りが開発屋さんにはできる。
ちょうど考えていた何かと合致するところがあったらしい。A氏はどう実現するかについて語り始めた。うなったり笑ったりしながら、他の人も巻き込んで喋っていた。
面白そう! 売れる! と、誰もが叫んだ(主にわたし)。
どんなものかはこうご期待。こういったものを制作中です、と公開して情報を集めるのも面白いと思うので、許可が出たら書く。
ともかくも、些細な質問、些細な悩みから、新しいサービスを発案するそのアンテナの張り具合が素晴らしい。
忙しいと忘れがちな部分である。アンテナをもう一度伸ばしなおそう。
先日、銀座アップルストアで行われたCSS Niteの後の飲み会での話題。
何の話からそうなったのかは知らないけれども、ヘッダーのあたりのCSSでpositionを使うかどうかという話をしていた。見ていると、コーディングをやっている4人中、3人がfloatのみ使う派、1人がfloatとpositionの組み合わせ派であるようだった。面白かったので参戦することにした。わたしはpositionも使う派です。
基本的には、どっち使おうが、見た目や使い勝手に問題が無ければOKだと思うけど、floatのみでできるのはスゴイなーと思っていろいろ聞いてみた(わたしはCSSが好きだしやっているけど、マニアックなほどにできるわけではないので)。
たとえばヘッダー内に、下記のようなものがあった場合。
・ページタイトル
・キャッチコピー
・グローバルナビゲーション
・ユーティリティナビゲーション(サイトマップとかの小さなやつ。なんて呼ぶのが正式?)
この順番でhtmlには書きたいけど、デザイン上は順番を崩したいときが、けっこうあると思う。
たとえば、ユーティリティナビは一番上の右側が良いとか、ページタイトルが製品名などならキャッチコピーはその上に置きたいとか。
その場合はどうするのか聞いてみたら、デザイン上の順番でhtmlも書く、ということだった。
わたしにはそれがとっても意外だった。
急いでいるときや、必要があるときに、そうすることはあるけれど、できれば順序よく書かないと気持ち悪いような気がするのだ。それを伝えようとしたが、うまく説明できなかった。
「それは本当に必要なの? 誰のためにそうするの?」とfloatの方々に聞かれ、
「え、なんでそうしないの? 使い勝手っていうか、気持ちの問題っていうかモゴモゴとにかくモゴモゴ」と答える堀内。
モゴモゴ・・・
今思えばこういうことかもしれない。
わたしはデザインとhtmlを同時進行することが多い。
デザインで煮詰まっているときやデザインカンプをクライアントに確認してもらっているときに、素のhtml書いてプロトタイプ作るとか、むしろデザインより先にhtmlと簡易的なCSSで作ったプロトタイプで動作確認とか。
そうすると、htmlは、デザイン上の制約を考えずに書くことになる。だからわたしはhtmlだけ見ても意味が伝わりやすいと思える順番で書くのだろう。
だから疑問に思っちゃったんだろう。
基本的にはどっちでも良いです。
そのときも、どっちが正しいかという議論をしていたわけではない。
結果が同じなら、人それぞれ、生産性が高いほうが良いと思う。慣れた方法が一番早いし、勝手なこだわりで工数が増えるのは誰にとってもよろしくない。
ユーザ層や戦略によって、優先順位も変わってくるわけでー。
面白かった。仕事人間としては、飲みの席での仕事の話、好きです。
追記:
float と position の戦いって、実際あると思うが、あまり興味はない。
興味はないけど、必要だとは思う。こだわる人がいないと進化しない。
そのあたりについては、別のエピソードがあるのでまた今度。
昨日は、2月から3月にかけてやっていた某Webサイトリニュアルプロジェクトの、ラップアップミーティングおよび打ち上げであった。
このプロジェクトは、プロジェクトメンバー(クライアント、システム開発会社、Web制作会社、フリーの方々など)が一体となれたプロジェクトで、それぞれが熱意を持ち、それぞれのパワーがいかんなく発揮されていた。
ラップアップミーティングは、AI(アプリシエイティブ・インクワイアリー:Appreciative Inquiry)の手法にのっとったポジティブアプローチで行われた。
それぞれがこのプロジェクトにどう貢献したか、どんな強みがあったかなどを評価していく方法である。
自分がどう貢献したかを述べたり、プロジェクトメンバーにそれを評価してもらうのは、こそばゆいような感触もあるが、自分の立ち位置や期待されていることが再確認(あるいは発見)できる。
問題点や弱点に注目していくやり方も、ナシだとは思わないし、何が何でもポジティブでなければならないというような、偏った見方をしているわけもない。だが、基本的にわたしは、「本人が気づいて反省している場合は、その問題点を指摘しない」という考え方をしていることもあり、人の良い点や強みに注目していくやり方には大賛成である。
わたし自身はダメ出しも指摘も嫌いではなく、一旦落ち込んでも、すぐに何くそと立ち上がる負けず嫌いタイプだが、凹んだら立ち直りにくく、モチベーションを落としてしまう人もたくさんいるだろう。
Web制作というような仕事は、モチベーションに左右されることが大きいと思う。
もちろん納品物に一定以上のレベルは保つが、さらなるパワーが出るかどうかは、関係性や熱意のような目に見えない部分であることが多い。
自分の価値が認められることが、モチベーションにつながらない人はいないのではないだろうか。
今回のプロジェクト自体は終了しても、今後、効果検証や新しいプロジェクトの発足などがあるわけで、チームが解散ということではない。もちろんWeb制作的人生も続く。
情熱と言ったら暑苦しいと思うかもしれないが、好き、楽しい、喜んでもらいたい、一緒に喜びたいという気持ちで仕事をしていける状態を保っていきたい。
ラップアップミーティングは、こういった評価の時間だけでなく、KPT法(Keep/Problem/Tryを洗い出す)にのっとった振り返りや、具体的な積み残しの整理などを行い、5時間の長丁場で終了。
長時間のMTGは疲れるが、脳みそが活性化される有意義なものは大好きである。
その後、その場にお寿司やビールが持ち込まれ、打ち上げ5時間、移動してカラオケ朝までと続いたわけだ。
全力で仕事をし、全力で楽しみました。
(弊社のWebデザイナーである竹田も一緒に朝までコースだったのですが、笑顔がとっても良かった。彼女が2月に正式にうちに入ってから初の本格的なプロジェクトだった。一緒にやれて本当に良かったと思った。今後ともよろしく!)
こういった形でチームになることが、当たり前になれるといい。
クライアントと単に発注者・受注者というだけの関係になってしまうのは、もったいないのだ。
互いに成長していこうとしてくれるプロジェクトメンバーの方々にあらためて感謝なのである。
タスク管理には、現在 Remember the Milk を愛用しているのだが、ここ最近、Firefoxで表示できなくなっていた。
rtm.preloadが失敗していますとか、なんとか、エラーが出て、タスクが表示されないのだ。
同じページをIEで開くと問題なく表示できるし、他のマシンのFirefoxなら大丈夫だったので、何かこのFirefox特有の問題であるということだー。
というわけで、最近入れた拡張機能をはずしてみたら無事治った。
「WebCards」と相性がよくなかったらしい。
わたしだけの問題かもしれないが、似た症状の人がいるかもしれないので一応書いておいた。
ちなみに、わたしのFirefoxでは、「FireBug」を有効にすると、mixi見るたびブラウザが落ちます。
これは・・・仕事中はmixiを見るなとの天のお告げだろうか。
ブロガー向けプロフィールページASP「iddy」、各所で話題になっておりますね。
ということで、わたしもさっそくプロフィールページを作ってみました。
相変わらずのハードな日々を送っていますが、数分でサクっと作れたのが素晴らしい。
作るのも設定も、迷うとこ無く、さくさくでございました。
素晴らしい。
あ、でも、del.icio.us のRSSが読み込まれて無いのは謎だった。
「My del.icio.us」という見出しのところからは、ちゃんとリンクされているので、アカウントは間違っていないと思うのだけどな。
8日にリリースされたばかりのようなので、今後もっと便利になっていくのだろう。
デザインテンプレートも今はすごく少ないが、どんどん増えることを願う。
ていうか、ユーザが作れるようになるといいな。
ブロガーがターゲットということなので、カスタマイズ好きのブロガーたちの欲求を満たしてほしいです。
そして、一番右のカラムは、WebサービスのRSSを読み込んで表示させる領域なのですが、現在対応しているのが、Flickr、Last.fm、del.icio.us、hatena、YouTube、Amazon リストマニアIDの6つなのです。
これはおそらく、どれもやってない人もけっこういるのではないかなーと思うので、どうなんだろと思ったり。だが、初期の想定ユーザがそれだけ濃い人であるというのは、うまい方法かもしれません。
あと、このプロフィールページを全部まとめたRSSが出せると良いなー、とか。
余談:
このようなプロフィールページにおいて、Adsense広告で収入を得るのって現実的なのかな。もちろんゼロじゃないだろうけど、バランスとして。
わたしならどうやるかな、って考えるのは楽しいですね。
CSS Niteの出張版である、CSS Nite in Osaka および、CSS Nite in Nagoyaが、3月にあるようです。
(※CSS Nite:CSSを中心としたWeb制作にまつわる諸々が語られるイベント)
名古屋が2007年3月10日(土)、大阪が2007年3月24日(土)ですね。
出張版は昨年もあって、行きたいなあと思いつつ見送ったのですが、今回はさらにパワーアップしているようなので、わたしの「行きたい度」もかなりアップなのです。
困った。
さて、充実の講演者さんの中で、わたしの一番注目している人は誰でしょう。
そーれーはー、名村 晋治さんです!(Webディレクションやってますblog)
以前、某セミナーときに名村さんの話を聞いて、大共感してしまったので、もっと話しが聞きたくてたまらんのですね。考えている方向性が近いというか、それが言語化されているというか。いやはや。
内容はこんな感じということで、うちの目指す「結果の出るWeb」に直結する部分です。
名村さんのお話が聞けるのは、3月24日(土)の大阪のほうです。
名村さん著の本(「Webブランディングの入門教科書」2月発売?)が出た後なので、本のフォローやさらにスゴイことも聞けたりするのでしょうか。本の内容についての質問とかもしたい。はー。行きたい。
名村さん以外も、そうそうたる顔ぶれです。
(連載の監修をしていただいている益子さんも)
3月といえば、年度末! しかも大阪のほうは月末! さてどうでしょう。行けるのでしょうか。行けると決めれば行けるのですが。
大阪で何か仕事があれば、それを大義名分として行けるので、3月あたりの大阪仕事募集中です。
あるいは、一緒に大阪旅行に行く人、募集中です。
上記、ふたつのイベントは2/5から一般申し込み開始なのです。
わたしが迷っているうちに申し込み締め切りになりませんようにと祈りつつ。
・ CSS Nite in Osaka
・ CSS Nite in Nagoya
【追記:2007年2月11日】
CSS Nite in Osaka で少し話させてもらうことになりました。
なんと!!! ですね。
世の中何が起こるかわかりません。
詳細はまた後日ブログいたします!
RSSリーダーに何を選択するのかは、人それぞれで使い方も様々なので、一概にどれが最高とはいえない。
わたしの場合を書いておく。
はじめは手軽に、Firefoxの拡張であるsageを使った。シンプルだし、ブラウザで手軽に操作できるので当初は申し分なかったが、RSSの購読数が増えると飽和……。読みたいRSSをクリックしていかなければならないので、ざざっと斜め読みができないのである。
独立系のアプリに変えようとしたが「高機能なのはいいんだけど、やはりブラウザで見たい。アプリを立ち上げるのは面倒」と思い、ではどこかのWebサービスを利用するかと思ったが重いので早々に退会。
そんなふうにして、たどりついたのがフレッシュリーダーである。
良い評判はずっと聞いていたので、ずっと使ってみたかったのだ。PHPでできているサーバインストール型のRSSリーダー。自分とこのサーバが軽ければ動作は軽いし、ブラウザで観れる。
お試し期間があったので、インストールして試してみたら、サクサク動くし、使い勝手も悪くない。フィードの登録もブックマークレットで一発。ふうむ。
お試し期間の30日をフルで使って納得である。RSSリーダーはしばらくこれメインで行こう。問題点があるとしたら、デザインくらいか。また雑感でてきたら詳しくレビューします。
個人使用かつブログでレビューをかける人は、ブロガーライセンスというのがあって無料で使えます(こういったマーケティング方法は素敵ですよね)。
2006年、ふと気が付くと、たくさんのWebサービスを使うようになっていた。
そんな中、信頼できると思っていたサービスにおいて、情報流出やデータ消失が起きたりする。
ちょっと驚いたのはやはりこれ。
Gmailの大惨事: メール大量消失の報告
オンラインにあるデータは、どうやって誰のせいで消えたとしても、手が出せない。
責任転嫁できるので気が楽と言えるかもしれないが、やはり自分でコントロールできないのは、もどかしい。
たとえば、自分のHDDがクラッシュして取り戻せないデータがあったとしても、「バックアップをとって置かなかった自分の責任だ」とあきらめが付く。そして改善できる。バックアップをとるのも、復旧するのも比較的容易だし情報もあふれている。
2005年までは、ローカルマシンのことだけ考えれば良かったのだが、2006年、たくさんのWebサービスを試し、本格的に使うようにもなった。メール、to DO、スケジュール、ブックマーク、写真、日記、人間関係……、いろんなデータをWebに置いている。2007年はそれをどう管理していくかだなあ。
個々にバックアップを取ったりするのは、面倒だし、非現実的というか。バックアップに対応しているサービスならちょっと良いけど、何曜日の何時に自動でバックアップみたいな設定ができるところなんてない。
「割り切る」というのもひとつの手だ。
確実に手元に残したいものだけ、自分の責任で確実にバックアップしておけばいい。他の例えば「日記」などは、絶対に必要なものでも宝物でもないから、消えてもOKというスタンス。
ただ、誰が何を「宝物」だと思っているかはそれぞれなので、自分がWebサービスを始めるときには、できるだけバックアップが簡単にとれるようにしたいと思う。バックアップあるいは同期。
バックアップの話しとはちょっと違うけど、たくさんのWebサービスを管理するため情報を一元化みたいな話も気になるところです。
ひとつのIDで全部管理というのは、合理的だけどリスクも大きいというか、感覚的に怖い。一歩ひいてしまう。
日本のオープンソース事情について、多くを知らないが、本日その一端にちょっと触れてきたのでブログしておこう。
日本では、Seasar というオープンソース界の大御所的プロジェクト(コミュニティ)があり、いくつものプロダクトが開発されているらしいのですね。
よくわからないけども、主に開発者のための様々なプロダクトが開発されているのかな?
その中に、ちょっと異色の「Tuigwaa (とぅいがー) 」 というプロダクトがある。
HTML タグを知らない人が、専門知識や特別な環境なしに ブラウザだけでデータベースと連動する Web アプリケーションを作るツール
と、書かれているように、開発者ではなく、一般の人のほうを向いたプロダクトなのだ。
会社の総務・事務の人や、秘書さん、自営業者さんとかのほう。
彼ら彼女らが、DBと連動するWebアプリを作れるとかって、なかなか素敵な話ではないか。
それに、Tuigwaa という名前が、馴染みなくて、何だろーと思ったら、どうも、かわいいのである。
Tuigwaa 名前の由来
Tuigwaa は沖縄の言葉で「小鳥」の意味で、「ユーザにとって幸せを運ぶ小鳥」であって欲しいとの思いで名づけられました。もちろん、小鳥は狛犬の上に乗っています。
小鳥!
かわいいー。
Tuigwaa だけでなく、それと連動できる周辺プロダクトも続々開発されているらしく、なんだか熱いのである。
関わっている人々の楽しそうな様子も良かった。
そんな具合に、面白そうな動きをしていて興味津々です。
いろいろと関わっていく予定。よろしくです。
