情報システム技術論’02 ＃ 1
久野靖∗

2002.5.23

はじめに

1

2.2

初期のインターネットの利用方法…

□ 本科目の主旨→「現在の情報システムにおいてどのよう □ 電子メール→現在でもメインのサービスな技術が使われているか」□ ネットニュース→ Web 掲示板の利用が増えたためマイナー化• このようなテーマで網羅的に喋るのは大変なので、開講 (隔年) ごとにテーマを絞って取り上げるように• メール、ニュースは IP 接続以前から利用できていた

している□ telnet →他のマシンに接続して利用するのは重要な利• 今年度は「Web ユーザビリティ」を中心として Webシステム開発の周辺から話題を選んで行く用形態だった□ 各回の進め方→レクチャー、(必要に応じて) 実習体験、分担しての報告、議論□ FTP → telnet と対にして自分のアカウント間でファイルを転送するのに利用• 匿名 FTP →フリーソフトの配付手段として□ 成績報告→出席、各回での報告の分担、レポート□ スケジュール

□ 情報公開/共有の仕組みとして…

5/23 #1 ユーザビリティとは/Web ページ技術/宿題(5/30 久野出張につき休講)
6/6 #2 ユーザビリティの具体例 (報告)(以下未定)
6/13 #3
6/20 #4(6/27 #5 初回に日時決定)• 匿名 FTP ではファイルの置き場所が分からないと役に立たない• ネットニュースや「匿名 telnet」の利用• goher →メニューベースで情報を次々に見ることができる

2World Wide Web

2.1

インターネットの歴史• WAIS →キーワード検索で問い合わせに適合性の高い文書をリストアップ□ これらはいずれも□ インターネットの起源→ 1969 年 (ARPANET)• 別個のサービスであり、• 個別の特性を知っていて使い分ける必要があり、• 最初は非常に限られた世界• それぞれを活用するためのコマンドも全く別のもの□ インターネットの研究機関への普及→ 1980 年代だった• CFNET(1981)、NSFNET(1987) →研究機関が多くネッ• →インターネットから情報を取り出すのは熟知したトに接続人にしかできなかった• 日本でも 1988 年 WIDE Internet により TCP/IP 接続が開始

2.3□ インターネットの社会への普及→ 1990 年代

World Wide Web のはじまり□ 「World Wide Web とは何か」定義できます?

• IIJ →日本で最初のプロバイダ→ WIDE 関係者が中心□ CERN(欧州粒子物理研究所) の研究者 Tim Berners-Leeとなり 1992 年末設立

が 1991 年に開発

∗ 筑波大学大学院経営システム科学専攻1• PC を出荷しているメーカに圧力を掛けて Netscape• 研究者どうしの情報流通をスムーズにするための手ブラウザを付属させないようにした (→訴訟の対象段として作ったとなっている行為の 1 つ)

• 主要なアイデア→ハイパーテキスト、 URL によるポ• さまざまな「新技術」を取り入れて差別化を計る (どインタ

れくらいそれが「有難い」かどうかは…?)• WWW サーバ→ CERN httpd• 当初は文字のみのブラウザ、NeXT Station (マイ □ Netscape 社はブラウザでは食べて行けなくなり、ブラナーなシステム) で稼働
ウザは無償化 (これまで儲かっていたビジネスが突然なくなるとは…)□ Mosaic --- 最初のグラフィカルブラウザ• Netscape 4.x の次のブラウザはオープンソース開発• イリノイ大 NCSA の学生 Marc Andressen が 1992 年モデルにより開発するとして、1998 年にソースコー末に開発ドを公開→ Mozilla プロジェクト• 1993〜1994 に爆発的に広まる (最初は Unix/X →後に Mac、Windows 版も)• そうしている間にも経営は苦しくなり AOL により買収• Mozilla プロジェクトの成果をもとに Netscape 6を公開 (2000 年末)• 当 然 、最 初 は 英 語 の み → 高 田 敏 弘@NTT が
Mosaic-L10N を開発→日本語も可能に• 現在も Mozilla(フリーソフト) と Netscape 6.x は• 計算機研究者の間で大ブームに (1994 ころ)

並行して開発• NCSA は NCSA httpd も公開□ MSIE →圧倒的シェア、標準への準拠はそこそこ、よく□ イリノイ大の学生グループはその後も Mosaic の開発を分からない独自機能、よくセキュリティ上の問題が発見続けていたが…

される• 大学は Mosaic を自分のところのソフトとして金儲けしようとした□ Mozilla/Netscape 6 →よりよく標準へ準拠、シェアは• 自由にやりたい学生グループとの対立□ Netscape 4 →メンテナンスのみ、企業サイトでは今で□ Sillicon Graphics Inc.

(SGI)の創立者

小さいも使われている

Jim

Clark は WWW が 商 売 に な る と 考 え 、Netscape □ あと、i-mode とか組み込みブラウザも増えている…
Communications 社 を 設 立 し て Marc Andressen □ 結局、ブラウザは「WWW への単なる接続口」「WWW を見るほか学生グループの主要メンバーを引き抜く (1994)道具」という位置付けに…
• Netscape ブラウザ→圧倒的な支持を得てブラウザのシェア No. 1 に• 最初から Unix/X、Windows、Mac で稼働• Netscape 1.1 からは日本語も OK →日本でもインターネットブームに

2.4

3

WWW と標準3.1

WWW と標準の関わり□ WWW が始まった時にまず作られたもの…

• HTML →コンテンツ (Web ページ) のためのマークアッブラウザ戦争プ言語• HTTP → Web サーバからコンテンツを取り寄せるためのプロトコル□ Microsoft 社は当初は MSN(自前のパソコン通信) に顧客を囲いこもうとしてアンチインターネット路線だった□ インターネットがもはや主流だと分かると路線転換→自前 □ 当初は Tim がとりあえず作ったものを皆で改良→協調的のブラウザ Microsoft Internet Explorer(MSIE) を• HTTP 1.0 や HTML 2.0 →改良された標準を RFC 化し普及させて Netscape 支配を止めようとしたて標準化• MSIE を Windows に標準付属 (Win 95〜)、しかも OS□ Netscape 1 あたりから、「独自機能を増やしたものがメ組み込みにして取り外せないように (Win 98〜)シの種になる」状況に→競って新機能を追加

2

• とくに MSIE と Netscape ブラウザの機能は IE 4.x □ この後、Netscape や MSIE によるさざまな「独自拡張」が表れると Netscape 4.x ではかなり相違がある• 標準がなければ「誰でもどこでも見られる」という• <center>...</center>、<blink>...</blink>、肝心なところが保証されなくなってしまう<marqee>...</marquee>• W3C が HTML 規格の取りまとめを試み HTML 3.0 を提案する□ WWW Consortium(W3C) → Web で利用する標準のとりまとめを行なう組織• しかし HTML 3.0 と各ブラウザの仕様が大きく隔たっていてまとまらない• しかし取りまとめも簡単ではない• 各ブラウザベンダーは自社の「独自機能」を「標準」□ HTML 3.2 ←とりえあず普及したテーブル、フレーム機にさせようと運動能などの機能を取り込んで「共通部分」をとりまとめた• まあそれなりに機能

3.2

もの (1997 年)• <font>タグや align 属性など表現に関わる機能も多HTTP

くまざっている□ HTTP/0.9 → Tim がとりあえず作ったバージョン• HTML 3.2 はとりあえずの標準として広く使われた□ HTTP/1.0 → RFC 1945 (1996 年)• W3C としては「構造と表現の分離」をめざしていた→ HTML 3.2 は妥協• 非常に簡単なプロトコル。サーバに接続して、取り□ HTML 4.0 → HTML 3.2 の後継かつ W3C のめざす HTML

寄せたいものを言うと送られて来て接続が切れる。の最終版 (この後は XML ベースの XHTML になる)

• 簡単なのはよいが毎回接続を張り直すのは無駄→
keep-alive 拡張• HTML 3.2 互換の HTML 4.0 Transitional、厳密なHTML 4.0 Strict に分かれている (このほかフレームセット用の DTD もある)

□ HTTP/1.1 → RFC 2068 (1997 年)• プロキシ機能や接続の維持に関する機能の拡張• HTML 3.2 に入っていた表現関係の機能は多くが「非推奨」となった□ HTTP はデータ転送なのであまりもめることはない• その代わりスタイルシートを用いるための仕掛けが用意され、表現はスタイルシートにより指定するこ• HTTP 1.1 のサーバ/クライアントと HTTP 1.0 のサーバ/クライアントでの接続も可能なように配慮ととなった

されている

3.3

3.4

HTML

そのほか…

□ 大量にあるので名前だけ。あとで必要に応じて取り上□ HTML 1.0

げる• Tim がとりあえず作ったバージョン、最小限の記述能力• (see http://www.w3.org/TR/)• CSS(Cascading StyleSheet) →スタイルシート記• SGML(Standard Generalized Markup Language)の標準を参考にしていたが、完全に準拠はしていな

述の標準• XML(eXtensible Markup Language) →タグを必要に応じて定義できるマークアップ言語、以下の多く

かったの言語が XML ベース□ HTML 2.0• XSL(eXtensible Stylesheet Language)、XSLT(XSL Transfromations) → XML に ス タ イ• 上記の問題を改良し、IETF がとりまとめたもの。RFC
1866 (1995 年)

ルをつける、XML を加工• 最初の広く普及したバージョン• RDF (Resource Description Framework) →コン• フォームはあったがフレームやテーブルはなかった

テンツの「内容」を記述する枠組み

3• MathML (Mathematical Markup Language) → 数• しかしそのコストは別建てだと思って開発されてし式記述

まいがち• SVG (Scalable Vector Graphics) →図形記述□ Web ではまったく状況が違う• SMIL (Synchronous Multimedia Integration• Web ではまずユーザビリティに直面→その後で金を出すかどうかが決まるLanguage) →実時間マルチメディアを組み合わせて制御• 膨大な Web サイト群→ちょっでも嫌なら「よそへ行く」• XHTML → XML に基づく HTML
• DOM (Document Object Model) →ドキュメント内容等をオブジェクトとして取り扱う

ユーザビリティと見た目は相反するか?

4.4□ 一般的に言えば「両立は可能」

4

Web 開発とユーザビリティ

4.1

なぜ「Web ユーザビリティ」か?

□ しかし、見た目ばかりにこだわってユーザビリティが犠牲になっている例は多くある (たとえば?)□ WWW が始まったころは「ページがあるだけでよかった」□ 例:• 画像を使うだけでその分だけ確実に重くなる (対策?)• HTML で書くだけでそれなりの技術が必要で価値が• 画像はテキスト検索できない (対策?)あった• 画像はレイアウト (幅など) を固定化する (対策?)• 内容の見せ方より内容が世界中から取れることが重要だった□ 例:

表レイアウト、色やフォントの指定• 表でないものを「配置するためだけに」表としない□ まもなく、みんな「見せ方」を気にするようになった→方がよい

表現指定など• 色やフォントや配置はスタイルシートを使う→それらを解釈しないブラウザでもそれなりに見える• 最初は作る人の「自己満足」だった→今でも個人のページは自己中なものが多い□ で、見た目のよいデザインは重要• 見てもらうことを飯の種にする「プロ」の出現• 見てもらうにはどうしたらいいか→ユーザビリティが重要に4.2画像を使うこと• それはデザインセンスなのでここでは扱わないが…
• ユーザビリティの原則を守った上でデザインしよう、ということユーザビリティとは?

□ 世の中では全然そのことが実践されていない (YN の主張)

□ 「使いやすさ」

4.5• 気分の問題なの?

□ Web は違うということを理解していない□ ある目的に対して、その目的を遂げる「効率」• Web ページはカタログの代わりだと思っている• 効率を何で計測するのか→時間、操作数、疲労、…

4.3

なぜ間違ってしまうのか?

• ちょっと情報を調べようとすると「スキャナでスキャンした PDF」にぶちあたったりする…

Web ユーザビリティの特徴的な部分?

□ プロジェクト管理がされていない□ これまでのハード製品のユーザビリティは「買った後で分かる」• Web 製作は「つぎはぎ」ではなくソフトウェア開発のようにきちんと管理されているべき□ ソフトではユーザビリティが悪いとサポートコストがか• しかしソフトはつぎはぎでは動かないが、Web はとりあえず見えてしまうからなおざりに?

さむ

4• 統一されたユーザビリティのためには統一された開 □ しかし言うのは簡単だけど…
発プロセスが必須□ まずページを開けた時に見える場所→ 1 等地→限られている□ 発信側の都合による構造化をしてしまいがち• ほとんどのユーザはスクロールなんかしない! (ホント?)• 会社の部門ごとに対応してページを分けるとか…
• ユーザは会社の構造に従ってナビゲートしたいわけ
ではない!

• ウィンドウサイズ (←モニタサイズ) によって 1 等地の大きさは変化□ 見た目重視にしてしまう• ではどうすればいい?

• コンペやデモをやると見た目で選んでしまいがち□ 「このページは 1024x768 で見てください」→サイテー• 実際には見た目以外に重要なことが沢山ある□ 画面の大きさに応じてデザインを変更→夢物語?

(今でも少しはできる)□ 長々と文章を書いてしまう• Web 上では長い文章をじっくり読んでもらうことは □ 複数の典型的なモニタサイズでチェックする→○
期待できない• 結局、複数のサイズでうまく扱えるデザインを工夫する• 斜め読みに適したページ構造を設計するべき• 詳しい情報は印刷して読むためのものを別に用意□ 自分のサイトが孤立した/自分が構造化したままの世界5.2だと思ってしまう

プラットフォーム独立□ 従来のデザイン→すべてのピクセルをデザイナが制御可能• Web はどこからどこへでもリンクが張れることが特徴!

• プログラムの動作はプログラマがすべて自由にできる(例: ある質問に回答するまでは先に進めない等)• 検索エンジン等で「途中へ飛び込んで来る」ことも当り前• さらに OS メーカがデザイン指針を提供• よそのサイトで有用なところへもリンクを張るべき• ユーザのナビゲーションのしかたを制約することは □ Web でも同様のことをすればいいのか?
不可能 (ブックマークなど最たるもの)□ そもそも、Web では「どのプラットフォームか」が分からない

5• ユーザによって使っているプラットフォームが違う

ページデザイン← Windows 決め打ちとかはやめて頂きたい□ 実はサイトデザインの方がずっと重要だが…

• ユーザを制御することはやめた方がよい←ユーザにとっては腹立たしいだけ• とりあえず具体的で分かりやすいテーマなので□ Web の難しさ…

5.1

陣取り合戦

• GUI ではそれが一般化する前に研究する時間が十分あった□ ページの中で「本当のコンテンツ」がどれくらいあるか• Web では「いきなり始まってしまった」から…

• 下手なデザインだと肝心のコンテンツが 1〜2 割とか→「めやす」として 50%はコンテンツが占めて欲しい

5.3• うまく空白を取ることも大切ではあるが「利用しそこない」はよくない

ユーザはどこから?

□ 画面の解像度 (VGA、SGVA、XGA、SXGA、…)• 広告スペースなどが頭にあると難しい• 画面サイズは大きくなる傾向• 余分な要素は削ってしまうべき• PDA などだとまた小さいものが増える
5□ 接続速度

5.6

インストールの法則• 8M ADSL から 32kbps Air H"まで (もっと遅いの □ 現在では新しいブラウザへの入れ替わりは活発でないも?)• 新しいマシンを買ってついてくるブラウザを永遠に□ Web デザインに「WYSIWYG」はナイ使う• WYSIWYG 風ツールを使うとそれがアルと誤解してし □ 新しいブラウザでユーザが得る利益は小さい (とユーザまいがちは考えている)• デザイナは「自分がすべて制御可能」に慣れている• そもそもインストールなんてしない???
• ブラウザ決め打ち、画面サイズ決め打ちでデザインしたくなる罠

5.4□ だったらどうするか…

• 新技術→ 1 年は待つべき

解像度独立• 新しい技術でなければできないかどうか? NO なら無理に使わない□ どういうことに注意?
□ なにごとも「固定幅」で指定してはいけない

5.7• 代わりに「画面幅のパーセンテージ」を使う用途と見せ方の区別□ …つまり semantic encoding を使おうということ□ 文字サイズも固定フォントサイズでは絶対指定しない□ スタイルシートを使おう• そうされてしまうと高解像度画面や目の弱い人が困る• 代わりに大/中/小とか「標準サイズの何パーセント」 □ 「データは永久に死なない」を使う• 50 年後にあなたのページがちゃんと見られるかどうか?

□ アイコンも小さくなっても分かるデザインに• アイコンに文字を入れる場合には特に要注意←普通は文字は入れない方がよい

5.8□ 広い画面ならそれが活用できるように応答時間□ クリックして「すぐ反応がある」と思うのはどれくらい?
□ 反応が遅れてもまあ待ってよいと思うのはどれくらいの5.5時間?

あまり使われていない技術…

□ 心理学の成果□ とは、どんなもののこと?

• 即座に反応していると思うのは 1/10 秒が限度。それを越えたら「待たされている」と思う□ たとえば次のものは?

• 表?

• 応答が 1 秒を越えたらユーザはもはや待てない→どっかよそに行かれてしまっても文句は言えない• フレーム?
• レイヤー?

• →ではこれらを越えそうならどうする?

• スタイルシート?

□ 対策…

• JavaScript?
• DOM?

• 「応答を用意している」というふうな応答をまず返す• 「どこまで進んだ」というフィードバックを返す□ 技術の変遷はかなり激しい• 「あとどれくらい掛かる」という情報を返す• あまり狭く考えると可能性が縛られると思う• 常に同じ時間待たせる (予測可能にする)• W3C 標準か、特定ベンダー独自か• 有効でない場合でも害をもたらさない、代替手段が □ 対策はさておき…
あることが目安6• ユーザは「きれい」より「速い」がずっと好き

5.12• 「1 秒以内」にすることでユーザがよそへ行く率を□ 「<a title="説明文" href="...">...</a>」で説明劇的に減らせる文がポップアップするようにできる• 意味のない画像や大きな画像を使うべきではない• 余分な害をもたらすことが小さいと思われる• 小さい画像でも見た目よくするのは難しくない• あまり長くしすぎない方がよい□ 作者が試している分には速い罠• リンクタイトルが表示されないブラウザもあることに配慮しておく□ 「http://w3in/bs」ではなく「http://w3in/bs/」としよう

5.13

一覧性

5.9

リンクタイトル

リンクの色□ 標準では「青で下線」→訪問していないリンク、「紫で□ 出て来たページですぐ欲しい情報が分かることが重要下線」→訪問すみのリンク□ トップページはとくに「画像がなくても分かる」ように• ユーザインタフェース的にいえばこれらの色は必ずしもよくないが、既に定着しすぎているので変更し• ALT 属性を使って画像 OFF の人でも意味があるようにする

ようがない□ 表や画像のようにダウンロードが終わるまでは整形でき □ body タグの指定やスタイルシートでこれらの色を変更ないものは避けるすることができるが…変更するとユーザの困惑を引きおこすので避けるべき5.10□ 関係ないテキストに上記のような表現を持たせることもリンクの使い方

避けるべき□ リンクにはどのような使い方があるか?
□ ナビゲーションリンク→サイトの構造に従った順次移動

5.14□ テキスト内リンク→関連のあるものを指す

リンクのユーザビリティ□ 出発のレトリック→なぜ現在いるページから離れてよそ□ 参照リスト→関連するものとしてこれがありますよ、とへ行くか納得してもらう

いう形• さらに詳しい (〜に関する) 情報があります、という

5.11

形で明示

リンクテキスト□ 「<a href="...">テキスト</a>」の「テキスト」の部分• よそへ行かせたくないと思ってリンクを張らないのはよくない□ 「ここをクリックしてください」で「ここ」をリンクにす• よそのどんなサイトに張るかを厳選して適切に張る→もとのページの価値も高めることになるる…ありがちだけどサイテー。
「here 症候群」→なぜか?
□ here 症候群が悪いわけ□ 到着のレトリック→新たにやってきたこのページはどう• ユーザによってはクリックするとは限らないいう価値を持つかが納得してもらえるようにする• リンク先に何があるかは行ってみないと分からない• このページは何なのか、がはっきりわかるようにする• 印刷したときにわけが分からない□ 新しい窓を勝手に開いたり窓を最大化するようなリンク• じゃあどうするのがいいの?

はサイテー。

□ 「○○の画像も見られます」のように普通の文章にして、「○○の画像」のところをリンクにする• リンクした先になにがあるかを分かるようにするのが重要

7• ユーザは自分で画面の状況を制御したい。それを邪魔するようなサイトは嫌われて当然。

5.15

外部からのリンク

□ CSS を使うことで意味と表現の分離が可能に□ 外からリンクを張ってもらう→自分のサイトのページビューが増えるのでありがたいこと• 1 個所変更するだけで大量のページのスタイルを全部調整できる• じゃあ、どうすればいいのか?
□ 魅力のあるページを作ること!

• 文書の内容に応じて複数スタイルを使い分けてもよい

アタリマエすぎだが…

• これらの利点のためにも、分離型のスタイルシートを使うのがよい□ URL を固定する→途中にリンクされてもその内容がちゃんと生きている□ スタイルシートは分かっている人が設計し適用しないと• 「途中への直リンおことわり」サイトがあるがこれもサイテー

ダメ• 専門家がデザイン・運用するようにして、ページ執筆者は利用するだけにした方がよい• 構造を整理するとき URL を変えないというのは結構
苦しい• その場合、どのように使うかというマニュアルが必要□ 1 つのページが複数の URL を持つこともあり• 例:

スタイルシート

5.18• マニュアルには、さまざまな環境でスタイル指定がどういう働きになるかを例示するべき「最新コラム」と「×年×月のコラム」• 強制的にどっちかの形に揃えてしまうこともできるが…

□ 上記にも関わらず、ページ執筆者が埋め込みスタイルで必要なものを追加することは避けられない• どちらの形でリンクしたい場合も可能になっている□ 重要なスタイルシートの指針
方がよい• フォントは 2 つ以上使うな!

5.16• 固定文字サイズは使うな!

有料 (登録) サイト• 「!important」は使うな!

□ 見る前に金を取るというのは嫌われる→そもそも見ても• 同じコンセプトの要素には class 属性を使って共通化らえない□ 要するに、ユーザがやろうとすることを邪魔してはいけ□ 無料で利用できる価値あるページも必要ない• そこから「もっと見たければ登録を」という形で勧誘できる

5.17

フレーム5.19□ 「使うな!」(ホント?)(どう思います?)

宣伝リンク□ Web ではナビゲーションの単位と情報の単位が一致して□ バナー広告 (valueclick 等) →広告を入れておくとおいる

金をはらってくれる• しかしフレームを使ってしまうとこの一致が崩れて• 入れておくだけでよい場合と、その広告をクリックしてくれた数に応じて払う場合とがあるしまう• たとえばブックマークをつけても再度来たときに同じ状態にならない• どっちにせよ、ユーザにとってはジャマで嫌われもの• クリックしてもすぐ戻られてしまう• URL を記録しておいても役に立たない→そんなのはWeb ではない□ 本当にユーザにとって役に立つ情報を提供するようにしないと…

□ フレームはある程度大きな画面サイズを必要とする• 従って、特定商品の宣伝ならクリックするとその商• 小さい画面では画面領域が貴重なのにフレームは勝手に領域を使ってしまう

品のところへ行くようにしないと…

8• 「ユーザのため」といいつつユーザが本当に何が欲 □ 印刷用に PostScript や PDF を用意するのはよいこと
しいのかは分からないので、それに合わせたフレー• しかし、これらを画面表示用と兼ねては絶対にいけムも作れるわけがないない• ナビゲーションバーを別にするためにフレーム→そんなもののために画面を削らないで欲しいと思って• 印刷サイズ→ A4 でもレターサイズでも印刷できないといけないも避けられない□ まだまだある…

6• まともにプリントできないことが多い。特定フレー
ムだけ印刷?

全部をうまく印刷?

次回までの課題 (2 週間)□ 2 章「コンテンツデザイン」読んでくる

スクロールするとどうなの?

□ 各自が 1 章ないし 2 章のトピックとして興味深いサイトを選び紹介する→それに基づいて議論• HTML ファイルが沢山必要で間違いやすく難しすぎる。
バグのもと□ HTML+CSS が不如意な人は勉強しておいてください (5/24• 検索エンジンにとっても難しすぎてうまく情報が抽計算機科学基礎でも取り上げます)

出できない• 現に「フレーム版」「フレームなし版」を両方用意す
ると…大部分のユーザは「フレームなし版」を選んでいる!
□ だからフレームなし、1 段組の縦スクロールがベスト!
□ フレームを大丈夫にする方法…

• 「target=" top"」を指定しまくる• インラインフレームを使う• しかしどちらもあまり嬉しくないと思うが…

5.20

サイトの信頼性□ きちんとしたページ構成□ 見た目も重要だが重くしない□ プロとしての運用• リンク切れや更新の怠慢がない• 内容が正しい、適切

5.21

プリントの必要性□ ページを印刷しておく人はとても多い• しかし画面で見るのと印刷して読むのではニーズがかなり違う• おすすめ→画面表示用と印刷用と 2 つのバージョンを用意する□ 「<link rel="alternate" media="print" ...>」で印刷ファイルを用意できる

9