このエントリーは「404ページのデザイン提案【前編】」の続きにあたります。 なぜ 404 ページが表示されたのか、そして利用者が出来る次のアクションが何かがみえてきました。これからいよいよ大まかなレイアウトのスケッチに入るわけですが、もうひとつ考えておきたいことがあります。ページに表示させたい項目だけでなく、必要でないと考えられる要素も洗い出しておくと、スケッチが最初の段階からある程度洗練されたものになります。 通常のページでは必須項目でも目的が絞られてるページだとそうではない場合があります。「あっても良い」「もしかすると誰か必要になるから」くらいの要素は目的が絞られているページでは省いてしまっても良いと思います。要素を最小限に絞り込むことで、ページで伝えたい目的がより明確になるでしょう。サイト内のリンクからで 404 が表示される割合より、サイト外からのアクセスで 404 が多く表示されています。そこで、サイト内でいろいろ読みたいけど行き詰まった人というよりかは、読みたい情報へ辿り着かなかったけどどうするかと考えている人が多いと判断。カテゴリリストのようなメニュー要素は省き、誘導の仕方も 404 に対する解決に絞ることにしました。 イメージが結構膨らんできたので、具体的にページ構成を考えてみました。資料として誰かに見せなければならないというわけではありませんし、思い立ったときにすぐに描けるということで、ノートにスケッチ。右図が最初に描いたスケッチになります。こうしたステップをふめば必ず探している情報に辿り着きますよ、というストーリー仕立ての構成。ちょっとしたアイコンも添えて少しやわらかい雰囲気が特徴です。 この時点で、サイトにある記事数を表示するアイデアが生まれました。利用者が探している情報へ行き着くためのヒントとは言いきれませんが、ここをキッカケに「なんならいろいろ見てみるか」と思ってもらえると良いなと考えました。人気記事などをリストアップすることも考えましたが、そこまでやると読ませてしまうので、ザッとみて雰囲気が分かる数字やキーワードだけにしました。 最初のバージョンでも悪くなかったのですが、ひとつひとつ要素を囲うのは少々息苦しく感じたので、ステップごとにコンテンツを分けるものの開放感のある見せ方が良いと思いました。左図のスケッチが次の描いたものです。線をウィンドウの幅全体に広げるだけでも少しダイナミックな雰囲気になります。一応、ステップはあるものの、この順番でしなければならないわけでもないので、特徴的だった矢印もここでは目立たなくなっています。また、マークアップをし始めた際に決めましたが、同じ理由で番号も完成版ではなくなっています。 ページのテンプレート化や要素のコンポーネント化は、サイトの拡張性を考える上で必須になります。しかし、目的が絞られているページであれば、「こうしなければならない」というルールから少し外れて目的に合わせたカスタマイズをするといいでしょう。そうすることでサイドバーやページの片隅ではなくコンテンツエリアに検索フィールドを入れた方が良いというアイデアも自然に出てきます。

このエントリーは「質問: ウェブサイトの見た目は同じにしなければならないか？」の続きにあたります。 もう１ヶ月前になってしまいましたが、ついに結果を発表出来るようになりました。有効回答数は 134 とサンプルとしては良い数になりました。ひとつの調査結果として捉えるには十分な数ですが、私のサイトと Twitter で告知したということもあり、若干偏っている可能性があるのでご了承ください。前回のTwitter経由でいただいた回答も一緒にご覧になるとおもしろいかと思います。 回答に参加していただいた皆様、本当にありがとうございました。 回答された方の役職はコーダーとデザイナーが半数を占めるものの、様々な役職の方が均等にいるという印象があります。今回は複数回答をアリにしましたし、特にこれといった定義付けもしなかったので、立ち位置を自分なりに考えてもらった結果が反映されています。ブロガーと名乗る方も 9% いらっしゃるので自分のサイトで何か情報発信をしつつウェブサイトの仕事に携わっている方が少なくとも 12,13 はいるというのが分かります。 いろいろな役職をこなしている方が大多数なのかと思いきや、役職を１つだけ選択した方が4割以上いました。しかし、2,3チェックしている方が半数いらっしゃるので、肩書き、仕事内容、回答者の考えるイメージというのは必ずしも一致していないのかもしれません。定義することも難しいわけですから、こうした結果になるのは予想出来ますね。何でもやるのは大変ではありますが、おもしろい部分でもあります。 Progressive Enhancement の認知度は「聞いたことある程度」も含めると半数以上にのぼりました。認知度は役職ごとにどう違うのか調べてみると、コーダーの 2/3 の方が知っているのに対し、デザイナーやディレクターは半数の方が知っているという回答をされていました。コーディング、特に CSS や JavaScript に触れる機会が多い方になればなるほど Progressive Enhancement への理解があるのかもしれません。ただこうして文章を書くと感じることですが、毎回英単語でこの言葉を表現しなければならないのは少し厳しいですね。プログレッシブ・エンハンスメントとカタカナ表記も長過ぎて分かり難いですし。困ったものです。 半数の方が Progressive Enhancement の考えを肯定的に捉えているものの、やはり現実は厳しいのではないかと考える方が大半を占めています。出来る度合いは様々ですし、こうしなければならないルールもありませんから、Progressive Enhancement の意味の理解も含めてノウハウが共有されることによって徐々に解決される課題だと思います。 私のサイトの読者中心だからなのかもしれませんが、すべてのブラウザで同じ見た目にする必要はないと考える方が大半のようですね。こうして多くの方が考えているものの、仕事でそういった考えを反映させて形作れる機会が少ないというのが現状なのでしょうか。 特定の役職の方だけが同じ見た目にする必要はないと考えているのかと思いきや、若干コーダーの支持率が高いものの、ほぼ同じという結果になりました。仕事に携わっている方にとってはひとつの共通認識であるわけですから、ウェブの特性であり特徴をクライアントにどう伝えるのかが課題でしょう。 少数とはいえ、やはり見た目は同じにしたいと考える方はいらっしゃいますし、「同じ見た目にする必要はない／出来ない」と考えている方でも、仕事では同じ見た目になるように努力されている方もいます。結果を見ると「同じ見た目にする＝品質」と関連付けられているという印象があります。確かに品質と捉えることは出来るのですが、ウェブにおいてそれが本当に品質として成り立つのかどうか・・・考える余地はあると思います。 この記事とは別に調査結果を１枚の PDF にまとめたものを作りました。とりあえず保存してとっておくのも良いですし、同僚や知り合いに見せるのにも使えるかと思います。ご自由にお使いください。 Progressive Enhancement とウェブサイトの見た目に関する意識調査１枚シート (PDF) のダウンロード （表示-非営利-継承 2.1 日本）

このエントリーは「質問: ウェブサイトの見た目は同じにしなければならないか？」の続きにあたります。 やっと明日に結果レポートを出せる状態になったので、まずは Twitter 経由でいただいたウェブサイトの見た目や Progressive Enhancement に関する意見をまとめて紹介します。アンケートだけでなく、こうして意見まで送っていただき感謝しています。140文字内でこれだけの情報を詰め込めるのかと関心してしまう意見も多数です。 Progressive Enhancement を簡単に説明すると「ブラウザに応じて最適だと考えられるインタラクションと見た目を提供する」になるかと思います。ただ、この説明文だけ読むとブラウザによって異なるデザイン／レイアウトを作らなければならないという印象を与えかねません。実際はそうではなく、新しいブラウザで見ると text-shadow を利用して可読性を少し上げているといった小さなことでも Progressive Enhancement に該当します。もちろん、その『小さな違い』を小さいと見なすかどうかは個人によって判断基準が異なりますが、CSS と Progressive Enhancement は相性が良いですし、元々それが CSS を使うメリットだと思います。実は CSS を利用してレイアウトをし、デザインをしているということは、Progressive Enhancement なんですけどね。度合いにもよりますが。 今回いただいたメッセージを基に議論してみたいものです。とりあえずポッドキャストあたりかな。 likealunatic 以前yhassyさんがエントリーでおっしゃっていたことに概ね同意しており、全ての環境で同じ見た目にすることは不可能であり、妥協点を探す作業が必要だと常々感じています。 d4r 「どこまでを同じ見た目と考えるか？」を議論してみたいです。例えばユーザーテストして、違いに気付かない範囲がある程度定量化できるなら、クライアントの説得にも有効な気が。 d4r そもそも、みんなどのレベルでチェックしてるんですかね？各ブラウザでキャプチャ取って重ね合わせて差分取るくらいまでしないと「同じ見た目」って言えないのでは？（屁理屈） likealunatic 不可能とか無理とか言ってしまうとネガティブですねｗ でも逆に、環境や設定によって違う見た目にできることは利点でもあると思ったり aratakojima Webサイトの見た目の話で疑問なのは、1.その実装コストを誰が負担するのか、2.あらゆるサイトに当てはまるか、3.ブラウザによってデザイン変えることによるユザビテストなどのコストが余計にかからないか、などを疑問に思っています。 tinybeans ユーザーが使用しているディスプレイも違うし、ユーザーがブラウザごとに見比べる可能性はゼロに近いと思うので、全く同じ見た目になる必要はないと思います。要素の位置関係さえほぼ同じになれば良いかと。 commonstyle 「見た目を同じにできます」をセールスポイントにしている業者さんもいますし、クライアントの態度変容を何度も目撃していますが、新しい技術を取り入れていこうという現場では「見た目統一」はあまり問題になりません。最初からProgressive Enhancementです tomix 理想の見せ方があるのなら、まだそれを追求すべき時期だから。しかし、見せ方もコンテンツの一部だということをわすれちゃだめだ。コンテンツと見せ方がそんなに簡単に分離できるものじゃないはず。見せ方が変わればコンテクストが変わるから koba CSS3を利用して見た目をリッチにすることは、より多くのユーザーをゴールに繋げたり、リッチな体験を提供するためだと思います。であれば、IE6ユーザーなんかにもその見た目を提供した方が、サイト的にグッドな気がします。 ism01saka 学術調査のためのアンケートサイトをよく作るのですが、そういう時は見た目の違いが回答に影響を与えることがあるり、見た目や機能が一緒になるようにします。そういう特殊な目的がなければ、ユーザーさんの使用するそれぞれの環境の中で最高の体験ができるように配慮したいです。 gaku 印刷業界からが色濃くでてしまった過去の背景が、日本の場合悪い影響として現在も引き継がれちゃってますよね。私は賛成派です。 necoze 個人的な経験からだと、企業の利益やコスト削減に結びつくか、同業種の他サイトでやっているかどうか、…がポイントかなと。 saburicom IE6だけ「For #$%^&'s sake, Upgrade man!!」って変化させたいけど、クライアント的には同じ内容をIE6だと載せないと今は説得できないね。無理。 kamiokan_de 既にコーダーも多大なコストを払っているのですが、PEではより多くの職域の人間のリソースを必要とするので、理想だけど難しいのでは、というのが現時点の解答です。ちなみにアンケートも回答させてもらいました。 kamiokan_de それに対してクライアントが目くじら立てることもそれほどない。どちらかと言えばクライアントの要件よりも、社内的な要件としてのリソースが問題になると思ってます。数パターンのUI管理、分析、検証の無限サイクル。 Takazudo Progressive Enhancementを積極的に仕事で取り入れたことはないのですが、JavaScriptでアニメーションをつける時など、複雑になると、IEでのみ動作が重くなる場合があったので、その場合は分岐してアニメーション無しにするなどはありました Takazudo Progressive Enhancementというわけではないのですが、管理画面などでは、一般的に言うブラウザシェアは無視できるケースが多いので、そういった場所でどんどん新しいことはできるのかなぁと思ってます taz8 数年前ぐらいまでは、Webサイトの見た目はできるだけ同じであるべきだと考えていましたが、最近は、そうでもなくなっています。主観的で微妙な言い方で恐縮ですが、コンテンツ自体がぶれないレベルで近似値的に近い印象があれば、OKという認識でおります。 thayashi Progressive Enhancementはローンチ直後はいいのですが、やりすぎるとその後の運用のメンテが煩雑になるのではという懸念がありますね。

この記事は「ブラウザって何ですか？」の続きにあたります。 @zerobase「誰がインタビューを実施し、結果を公表したか（その意図は何か）」への批判的な考察も書かれたほうがよいかも > "回答者の多くの方が「ブラウザ＝検索」という認識を持っているみたいですね" ぜひ石橋さんの意見を伺いたいところですが、私もほうも肯定的に「ブラウザは見えない存在になっているのね。良かったね！」と考えているわけではありません。 利用者がウェブから取得したデータをどのようにブラウザで表示されるかどうかといった仕組みは知る必要はありません。ただし、ブラウザが分からないとなると、セキュリティへの理解も低いのではないかという懸念もあります。特別な知識やセキュリティソフトがなくても、ブラウザという窓口を利用しているのだと理解しているだけで予防出来ることは少なくありません。例えば、アドレスバーの URL を見るとことを意識するだけでも違うでしょう。SSLのサインが表示されているか確認することも重要です。 また、アクセシビリティやユーザビリティの側面からも、ブラウザという存在を知るか知らないかで違いが出てきます。今は随分少なくなってきましたが、サイト内に文字サイズを変更出来る UI が一時期流行したことがありました。文字の大きさを変える機能がブラウザに実装されているにも関わらず、こうした UI が流行したのは、サイトの制作の方針やブラウザのサポート状況による結果だとは思いますが、それでも既にあるものをわざわざサイトのほうでも作るのは非効率でしょう。他にもブラウザがもつちょっとした機能を理解することでサイトのナビゲートが簡単に行えることもあります。利用者の「使い難い」はブラウザの機能を利用することで補助出来ることは少なくありません。 最近のブラウザはセキュリティ面に関しては分かりやすい UI を採用することによって、様々な情報を視覚的に示すようになってきています。例えばフィッシングサイトであれば、警告サインが表示されますし、安全なサイトかどうかもアドレスバーの色が変わるといった見せ方もあります。今後、様々な工夫がブラウザのインターフェイスになされるとは思いますが、すべての機能や可能性を表に出せるわけではありません。 車を運転している人は、メーカーは知っているかもしれませんが、何年のどのモデルなのか覚えている人は少ないですし、カスタマイズしている方はごくわずかです。しかし、どの車に乗っていても、快適に運転が出来ます。なぜなら車を運転するための基本的な知識があるからです。ただ、アクセルを踏めばスピードが上がり、ギアを変えれば後ろに進むといった操縦法ではなく、とっさな状況判断や視野の確認が良い運転に必要とされます。 ブラウザも、車と同様「戻る」「進む」といった基本操作以上のことを知ることで、安全かつ快適にインターネットを楽しむことが出来る思います。IEでもFirefoxでも好きなものを使えば良いと思いますが、ブラウザというソフトウェアを使っているという意識は多少なりとも必要だと思います。

前回に引き続き、いろいろな方が使っているサイト制作ソフトの紹介です。 以前、制作ソフトに関して神森さんと話したことがあります。制作ソフトそのものの使い方を習得することも重要ですが、実は OS の特徴をいかに把握して活用するかが制作ソフトの使い勝手に大きな影響を及ぼします。テキストをダブルクリック、トリプルクリックしたときにどのような挙動が起こるのか、コピーしたデータがどのようにクリップボードに保管されるのか、他のアプリとの組み合わせで相乗効果があるのか・・・といったことを知っていると知っていないとでは大きな違いです。 自分が使っているソフトを支えている技術や別のソフトを改めて見つめ直すことで、自分の『武器』がさらに手に馴染むと思いますよ。 ブックマークに使用している制作ソフトを書いている方もいらっしゃいますね。他にもあればぜひ @yhassy でコメントよろしくお願いします。 wooyan Crescent Eveというエディタを使っています。軽さと程よい補完機能が便利ですね。それと編集中のファイル内を調べて入力支援してくれるところが最高です！ Kazabana やっぱりDWが多いですね。WPテンプレート編集するのに使ってますが、WPタグを扱うのがちょっとアレです。 floral DreamWeaver,CSSSEdit,SKEdit,Jedi X。JChecker Xは、コードや全角・半角チェックをしてくれるので重宝するっす versionfive Mac買ってからずっとskEditです．軽い上にローカルとリモートの同期も簡単にできるとこがいいっす hatto 最近はほとんどEmEditorかな。昔はDreamweaverだったけど今の環境に合わないのとCSSはじめたあたりから。 thayashi DWとEmEditorです。DWはコード補完があるので使っている感じです。JSもいっしょに書くときはAptanaでやることも増えてきました。Aptanaのコード補完もなかなかよく出来ています。 trico_lour 僕はWinではDreamweaver、家のMacではCodaですね。某所でとある外国の方が使いこなしていたTextMateもちょこっと気になってます。 hiloki Eclipse+AptanaStudio です。社内のphp開発でEclipseが使われているので業務の連携上。AptanaもそれなりにDW的な機能も備えてますし、リソースの検索が便利なので起動時の重さ以外は特に不満無しです。 aknk DWCS3+CSSEdit。DWは挟み込スニペットを設定し、主要タグ・スニペットにキーボードショートカットを割当て、コード画面で作業。width,height,alt,th等はコード画面を見つつビジュアルUI側から作業。書く手間をとにかく減らしたいので。