NTTデータグループウェブサイトのマルチデバイス対応
14 likes2,919 views
CSS Nite LP, Disk 27「スマートフォン対応サイト制作（3）」にて。一部増補改訂。
NTTデータグループウェブサイトのマルチデバイス対応
- 3. 自己紹介 • 伊原力也 – ビジネス・アーキテクツ • シニアインフォメーションアーキテクト – mokuva – Twitter: magi1125 – Facebook: Rikiya Ihara
- 6. 本題に入る、その前に
- 8. NTTデータとは？ • 人々の暮らしをITで支える会社 – 銀行振込の仕組み – 飛行機の経路設計システム – 税金の電子申告システム – 救急車と病院の連携システム • 続きはWebで！
- 13. プロジェクトの位置づけ • 世界規模のリブランディング • ウェブサイトは 新たなコミュニケーション構築の 中核的な役割を果たす – 世界にNTTデータブランドを伝える – 各国のビジネスを後押しする
- 14. 目的を実現する手段 1. グローバル共通テンプレートを ガイドラインで提供 2. 各国の手でサイトリニューアル Global Site Brazil Japan China North America Denmark Switzerland EMEA Turkey Germany United Kingdom Italy
- 15. 各国ヒアリング・調査・分析 • コンテンツ目録 • 各国の想定ユーザーとニーズ • コンテンツ同士の関係性 • ユーザーテストやインタビュー結果 • コンテンツの役割や目的 • 問い合わせフォームの内容 • 更新頻度や季節性 • 現状のアクセスログ • リニューアル時の追加・削除 Content • 各国の会社のビジネス要件 • ウェブサイトのKPI • 各国の競合他社のサイト • CMSの導入状況、運用フロー • 各種ウェブサイト評価ランキング • その国での利用端末の状況 User Context
- 16. プロジェクト期間：約半年 戦略 2011年 8月～10月 設計、デザイン 2011年 11月～12月 実装、ガイドライン 2012年 1月～2月 NTTデータ本社ビル http://www.flickr.com/photos/peta_peta/350630421/ Photo by Hiroyuki-H
- 17. 本題その１
- 19. それは
- 20. 流行りだったから
- 21. 要件に沿っていたから プロジェクト要件： 1. マルチデバイスに対応 2. 同一性の保持 3. ワンソースで対応 4. 耐用期間を長く 5. アクセシビリティの確保
- 23. 2. 同一性の保持 • URLに対するリソースの同一性 • デバイス横断時のブランドの同一性
- 26. 3. ワンソース（HTML） • 各国ごとに独自のCMSで運用 • モバイル版を別HTMLで出すには 大規模な改修が必要なケースも • 優先は「NTT DATAブランド」の統一 Japan CMS North America CMS China CMS EMEA CMS Global CMS Germany CMS
- 28. 4. 耐用期間を長く http://bradfrostweb.com/blog/web/responsive-web-design-missing-the-point/
- 29. 5. アクセシビリティ • 「社会の公器」として、 世界のシステムを作る会社 • その存在を各地域の人に受け入れてもらう • そのためのサイトは 多様な言語・文化・状況で使用される 「多様な人・多様な環境に対応できる」 アクセシビリティ
- 30. The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. Tim Berners-Lee Webのもつ力とはその普遍性にあり、 障害の有無にかかわらずアクセスできることは、 Webの本質的な側面のひとつである ティム・バーナーズ＝リー http://www.w3.org/WAI/ http://www.mitsue.co.jp/help/accessibility.html
- 31. data for : the people 「NTTデータは世界中で、人を支える ソリューションをつくっています。」 http://www.nttdata.com/jp/ja/corporate/profile/pr/ad/pdf/ad_toyosu_01.pdf
- 32. NTTデータとアクセシビリティ • 「人を支える仕組みを作る」 という点で、ウェブの思想と重なる • 「NTT DATAの顔」である ウェブサイトの「根幹」は アクセシビリティ
- 33. プロジェクト要件とRWD 1. マルチデバイスに対応 2. 同一性の保持 3. ワンソースで対応 RWDの根本 RWDの特色 4. 耐用期間を長く 5. アクセシビリティの確保 WDの基盤 RWDに一部関連
- 34. 結論 • プロジェクト要件とRWDに親和性あり • RWDを採用したうえで 「要件を満たすように」 設計・デザイン・実装する • しかしRWDにすれば 自動的に満たせるわけではない 例えば、アクセシビリティ
- 36. BAD!! 構造と表現の不一致 • デバイスごとにバラバラのものを 無理やり合体する考え方だと 「ほころび」が出る – table要素を列ごとに切ってfloatで並べる – 似た要素を複数仕込んで、幅によって表示・非表示 – box-ordinal-groupの使いすぎ →スクリーンリーダー利用時や ブラウザとスクリーンリーダー併用時に 問題発生（見た目とHTML構造が乖離）
- 37. 1.3.2 意味のある順序
- 38. RWDにする意味 ＝ 同一性 • デバイスごとにバラバラの構成なら 無理にRWDにせず、専用サイトを • RWDなら、画面幅に由来する部分を ちょびっと調整するぐらいの気持ちで
- 41. アクセシビリティと ユーザビリティとの交点 • 使いにくいけど使える → 状況によっては使えない • 使えなかったものが使える → 大勢の使いやすさもだいたい向上する アクセシビリティ ユーザビリティ
- 42. まとめ • 要件に沿って実装方法を選ぶ – ワンソース＝RWDではない – 運用性とデバイス特化のバランス – ハイブリッドもあり得る • 「要件を満たすように」作る – 実装方法を決めても自動では満たされない – 方針をきちんと立てることが必要
- 43. それでは、次のお題
- 44. 本題その２
- 48. RWD向けワークフロー • デザインカンプをやめよう – デザイン時点では分からない 実装上の不都合があるかも – カンプを何枚も作っても それは結局捨てるもの – ピクセルパーフェクトに こだわりがち → デザイニングインブラウザで アジャイルしよう
- 49. デザイニングインブラウザ
- 50. しかし！ • このときはデザインカン プを作った • 代表ページいくつか＋ モジュールリスト • 広幅と狭幅の 2パターン
- 51. なぜ？ • 多くのプロジェクトメンバーや関係者 – 国内だけでなく、海外にも多数 • 一丸となって目指す「旗」が必要 • でもタイトなスケジュール → デザイナーがPhotoshopで バッとキメの絵を作るのが 合意形成への一番の近道だった
- 52. ざっくり比較 デザイニング インブラウザ 遅い ↓ Photoshopで デザインカンプ 早い ↑ 自由度 低い ↓ 高い ↑ 忠実度 高い ↑ 低い ↓ 効率 良い ↑ 悪い ↓ 作業速度
- 53. カンプで作ったけど • 以下は全て回避できた – すべて実装してから問題がわかると、 アタマまで戻ることがある – デザイン時点では分からない 実装上の不都合があるかも – カンプを何枚も作っても それは結局捨てるもの – ピクセルパーフェクトにこだわりがち
- 56. 対策2：後半は実装ベースに移行 • パーツの展開的なものは、アートディレクターと実装 者がペアデザイニング（？） • 新しいパーツはPhotoshopでデザイン Photo by Esti Alvarez http://www.flickr.com/photos/esti/4638056301/
- 57. デザイニングインブラウザの真の利点 • それは「巻き込み力」なのでは – 画面設計後に、すぐ本物っぽく動く – プロジェクトメンバーの視線が集中 – みんなが巻き込まれる – スペシャリストのコメントが集まる – 叩き上げられていく
- 58. カンプでも巻き込みは起こせる • つまり、役割と作業物は分離できる – 設計・デザイン・実装のメンバーが デザインカンプに「巻き込まれ」て ツッコミをきちんと入れればよい – これだけで、前提の勘違いや、 実装後の手戻りは回避可能
- 59. では、本当に必要なのは？ • メンバー間の“のりしろ” – プロジェクトの戦略 と要件の理解 – ユーザーの理解 – デバイスの理解 デザ ナー イ ディ レク ター – ウェブデザインの理解 – ウェブの仕様と トレンドの理解 • 作っているものを 自分以外のメンバーも 説明できるレベルでの理解 エンジニア
- 60. のりしろが無いと…… • デザイニングインブラウザも難しい – 誤った設計やデザインの考え方を 押し付けられて実装者の負担が増える – プロジェクト全体で見たときの 手数が減らず、効率的にはならない 実装者が頑張る だけでOK？
- 61. のりしろがあれば…… • キャンバスは状況によって自由に選べる – 手書きのワイヤーフレーム – デザインカンプ – 紙芝居プロトタイプ – Flashで作ったプロトタイプ – デザイニングインブラウザ
- 62. のりしろをつなげるのは？ • チームとしての雰囲気 – ツッコミを入れやすい雰囲気 – ツッコミを受けやすい雰囲気 – 他のメンバーを信頼する雰囲気 – クライアントと一緒に作っていく雰囲気 ッ ツ ミ コ ツッ コ ツッ ミ コミ 修正 納得 議論 反論
- 64. このセッションのまとめ
- 67. ありがとうございました