SharePointのデザイン開発でやってはいけない10のルール+1

海外のSharePointブログ SharePoint Muse に投稿されたエントリ「Top 10 Mistakes in SharePoint 2010 Branding and UI Design」がとても興味深いものでしたでご紹介。これは数々のSharePointデザイン案件に関わってきた Marcy Kellar が自身の経験から「失敗プロジェクトに共通しがちな要素」をまとめたものです。日本とはやや事情が異なる部分もありますが、私自身の経験に照らしても、とても頷けます。

以下はその趣旨抜粋&私のコメントを含めた超適当意訳です。興味を持たれた方はぜひ原文(英語)をあたられることをお勧めします。
Top 10 Mistakes in SharePoint 2010 Branding and UI Design

それでは。「10のルール+1」です:

10. Using Inline Styles(スタイルをインライン指定している)

ソースに直接スタイルを記述(インライン指定)する必要がある=SharePoint標準のCSS構造をきちんと把握できてない、という訳です。確かにその場しのぎのインライン指定は、後から問題になりがち。きちんと一箇所で管理されるべき、という指摘には同感。ただ、SharePointのCSSは迷路じみている上に、更にSharePoint自身がインライン指定を頻用しているので(苦笑)あまりこだわると逆に効率が悪い場合もあるかと。上記を前提に、ケースバイケースでしょうか。

9. Applying a Fixed Width To a Collaboration Site(コラボレーション用途のサイトに固定レイアウトを適用する)

横幅を固定するとデザイン整備が容易になります。「情報発信(見てもらうことが主目的)」のサイトはそれがむしろ良いのですが、社員同士の共同作業(コラボレーション)目的のサイトならば、効率を重視して画面幅を最大に使える可変デザイン(標準)を採用すべき、という指摘。

これは日米の違いでしょうか?私が知る限り、多くのSharePoint環境ではあまりこの辺りの「役割」が峻別されていない気がします。すべてのサイトがそれぞれ「情報発信 兼 コラボレーション」用途のような。とはいえ、デザインは「見目の美しさ」ではなく「目的」にこそ準ずるべき、という点は全く同感です。

8. Not Designing Around Real Content(実際のコンテンツで作業していない)

lorem ipsum(ダミーコンテンツ)は何処までも「仮」なので、実コンテンツを入れると想定外の問題が発生することもある。デザイン開発はできる限りリアルなコンテンツを利用してを行うべき、という指摘。これは確か(反省気味に)。ただ、デザインを依頼する顧客側問題というか、協力がないとどうにもならない部分ではあります。でもまず要請はすべきですかね。

7. Using Too Many Master Pages(マスターページが多すぎる)

サイトコレクションに四以上のマスターベージがある=「何か失敗している」と考えるべき。理想はデザイン毎に単一のマスターページで、細かなバリエーションは、マスターページではなくスタイルシートで工夫するべきだ、という指摘。運用が始まると、アップデートの都度、マスターページ間の一貫性・整合性を保つことが困難になりますからね。ちなみに Marcy 自身の経験では最大「30」あった案件(いちサイトコレクション内で!)があるそうですが…どんなサイトだったのか見てみたい気もします。

6. Removing the Quick Launch ContentPlaceholder from the Master Page(サイドナビゲーションをマスターページレベルで削除)

いろいろと不評なサイドナビゲーションですが、標準機能の一部のはこれと依存関係にあります(カレンダーリストやブログサイトなど)。また、後から部分的に「やはり必要」となる場合も案外あるため、マスターページから根こそぎ削除してしまうことは止めた方が良い、という指摘。CSSで簡単に隠せますからね。

5. Fixing the Width of the Ribbon(リボンの横幅固定)

ページに固定レイアウトを採用している場合ですが、その横幅にあわせてリボンメニュー幅まで固定してしまうと、大抵、右端にある管理者ツールが見えなくなります。そもそも「リボンメニュー」という標準GUIの一貫性を保つことが出来なくなるので、UX(ユーザエクスペリエンス)という観点からも、良いアプローチとは言えません。固定レイアウトはあくまでコンテンツ領域のみに留めるべき、という指摘です。これは当然ながら SharePoint2010 の話。やはりデザインの「目的」を熟慮するべき、ということかと思います。

4. Using Content Editor Web Parts instead of Field Controls for Web Content(列でなくコンテンツエディタWebパーツにコンテンツを入れてしまう)

なにかと便利な「コンテンツエディタWebパーツ」ですが、そこにページの内容(コンテンツ)そのものを入れるべきではありません。もしユーザが誤操作でWebパーツを削除したら、コンテンツがすべて完全に消えてしまいます。またWebパーツは発行ページのバージョン管理範囲外。そのため、コンテンツはWebパーツではなく、きちんと列の値としてフィールドコントロールに格納すべき、という指摘。

成程。誤操作による削除については外部テキストの読み込みなら問題無い気がしますが、しかし、バージョン管理を一元化できない、という点は考慮されるべきですね。とくにポータルのトップページや、外向きの公開Webサイトで重要ポイントになりそうです。

3. Using Dreamweaver Directly with SharePoint(Dreamweaverを直接繋ぐ)

Dreamweaver(AdobeのWebデザインツール)で SharePoint サイトを開いて編集しないこと。発行ページとぺージレイウトの関連性が破壊されてしまう(不可逆的に)ので、素直に SharePoint Designer で作業すべき。ただ、Dreamweaver を HTML デザインツールとして活用するのは問題ない。くれぐれもオフラインで。…自身が利用していないのでピンときませんが、どちらかというとTIPSでしょうか。あるデザーナさんは、ページも含めてソース編集は全てローカルで行い、SharePoint Designerはアップロードのためのツールとしてだけ利用している、と言われていました。

2. Modifying Default Files(標準ファイルを編集する)

Webフロントの所謂「SharePointハイフ」配下にあるCSSやJSなどを直接編集しては駄目です。即座にファーム全体に影響しますし、CUやSPの適応時に上書きされて変更を失う可能性もあります。どうしても必要なら、これらファイルのコピーを編集してフィーチャー化の上、ソリューションとして展開すべき、とうい指摘。

これは多くのSierさんが「やってしまっている」のではないでしょうか。私自身もやりたくなる時が多々あります(汗)しかし Marcy の指摘通りですね。顧客がこうしたハイフの性質について100%理解しており、変更が失われた場合でも自身で対応可能なら別だと思いますが、顧客担当者も異動で変わるのが常ですし。とはいえ、ソリューション化までするのはあまり聞きません。出来ても「あえてやらない」のがプロの妙かもしれません。

1. Focusing on the Styling, Not the User’s Experience (ユーザ体験でなく見目のスタイリッシュさに拘る)

デザインは、デザイナーや顧客担当の自己満足ではなく、顧客ビジネスの為にあります。実際にコンテンツを運用し更新してゆくのはあくまで(Webデザインに精通していない)一般エンドユーザである訳で。デザインはそうしたユーザがきちんと無理なく運用できるものになっているでしょうか?見栄えのために運用を犠牲にして居ませんか?という指摘。異論の余地がありません。「見栄えするデザイン」と「運用」をバランスすることこそデザインの妙だと思うのですが、まあ、現実問題として、ついついその秤が「見栄え」に倒れてしまうのは良くある話です。このデザインは本当にユーザ(のビジネス)に価値をもたらしているのか?つねに自問する必要がありますね。

如何でしたか?
最後に、私個人の経験からこの10のルールに+1したいと思います。

番外+1:Too many ‘KeyPerson’ (キーパーソンが多過ぎる)

デザインは本質的に「皆の意見を集約すれば良くなる」というものではありません。デザイン思想の一貫性と、ある程度の「割り切り」が重要になります。限られた予算の中で、いかに目的を達するかの勝負ですからね。こうした条件下において、意思決定者(キーパーソン)が複数存在してしまうと正に「船頭多くして船山」です。一見一人でも、その一人が周囲の雑音に影響されて右往左往してしまえば同じこと。手戻りの連続で一貫性が失われ、使いにくい上に見目も悪い、という(大抵デザイナーの意地が見目だけはなんとかします)最悪の結果になりがちです。

とはいえ、これは顧客(ユーザ企業)側の問題ですので、デザイナーにはいかんともし難いのですが…。こうした問題が予想されるケースでは、予めデザイン思想や方針(ポリシー)、判断基準、そして意思決定ルールなどの明文化をお勧めすると良いかもしれませんね。


Author

中村 和彦(シンプレッソ・コンサルティング株式会社 代表)が「ユーザ視点の SharePoint 情報」を発信します。元大手製造業 SharePoint 運用担当。現SharePoint コンサルタント。お仕事のお問い合わせはこちらまでお願いします。当ブログにおける発信内容は個人に帰属し所属組織の公式発信/見解ではありません。
FB : 中村 和彦
blog: Be・Better!
MS MVP SharePoint 2009/10-2011/9
MS MVP Office 365 2012/10-2014/9