SharePointでエンタープライズWebサイト/イントラネットを設計するときに知っておくべきUXの影響
現在 SharePoint を使用するか、それともより適切な [〜＃〜] ecms [〜＃〜] を使用するかに関して、現在のところ検討しています。
使いやすさ、アクセシビリティ、ユーザーエクスペリエンス、UIの設計にどのように影響するかに関して、SharePointに対する、またはSharePointに対する説得力のある証拠を収集したいと考えています。
塹壕からの御言葉、あなたが成功して戦ったものを聞きたいのです。エビデンスと統計を使用してストーリーをより適切にバックアップできる場合でも、SharePointを使用して顧客向けのエンタープライズレベルのWebサイトとイントラネットを設計する他のUX担当者から話を聞きたいと思います。
SharePointを使用するときにUXの観点から考慮すべき主なこと：
- SharePointはひどいUXです。
それだけです。それはほとんどのタスクで獣で恐ろしいです。それはdoesいくつかのタスクでExcelですが、コンテンツ管理は間違いなくその1つではなく、より良いUXに対応するカスタムインターフェイスの構築はソフトウェアツールセットの優先事項ではありません。
SharePointをイントラネットフレームワークとして選択する唯一の理由は次のとおりです。
- 主なツールセットは、MS Officeドキュメントの共有と保存を主な目的とするチームサイトです。
- 結局のところ、彼らはライセンスに6桁の数値を支払っただけであり、馬鹿のようになりたくないためです。
SharePointを一般向けWebサイトとして選択する唯一の理由は次のとおりです。
- 私は困惑しています。 SharePointで構築されたサイトを一般の人々（特に顧客）に提供する理由は考えられません。
私のトレンチからの経験：
MS Office SharePoint Server 2007（MOSS）を導入した当時、私は約1年間SharePointサイト/サーバー管理者になりました。私が6年前に構築したCMSは確かに長い間存在していたため、新しいイントラネットプロジェクトにより強力なものを求めていました。そして、ManagementはすでにMOSSを購入していたので、そのままです。それは私たちが使用しなければならないものです。
サーバーファームのセットアップに関しては、シニアオンサイトMSサポートスタッフとの面談の悪夢でした。それだけでも、これまでで最大の赤信号であったはずですが、私たちは耕し続けました。
私の仕事は、サードパーティの広告/デザイン会社が設計した新しいUI /サイトアーキテクチャを使用して、SharePoint内に新しいCMSを構築することでした。
通常、SharePoint内で簡単なことを行うのに6か月かかりました。私たちは私の試みを手にした素晴らしいコンサルティング会社を持ち込みました。この会社とのすべての単一の相互作用は次のようになりました：
私：
[メニューの縦型レイアウトを作成するような簡単なタスクを挿入する]必要があります
コンサルティング会社：
まあ、あなたはできませんthatしかし、これがハック/回避策/ダクトテープソリューションです。
6か月後、私はSharePointを打ち負かして提出したことを誇りに思っており、実際にUIが代理店から提供されたものと同じように見えました。もちろん、それは壊れやすく、基本的にはハックの上にハッキングされたものでした。サイトもめちゃくちゃに肥大化し、ウェブ標準がなく、速度も遅かったが、それは重要なことだった。
その後、トレーニングが来ました。 MOSS CMSワークフローで、コンピューターに習熟しているスタッフのスピードを上げるために2日間費やしました。なぜ2日間だけなのでしょうか。 「使いやすい」ので、6年ほど前に作成したCMSに戻ります。
私はスタッフに同意しなければなりませんでした。
私が学んだ教訓は、大企業のIT部門に参加できるMSの能力により、SharePointは標準であるということです。それはどこにも行きません。 [〜＃〜] if [〜＃〜]使用する必要があります：
- sharePointを知っているUIデザイナーを雇う
- カスタムUIを設計しないでください。既存のSharePointテンプレートを変更します。
- sharePointはその中心にあるもののリストを作成するだけであることを理解してください。すべての機能は、このリストの概念に基づいています。
- ほとんどの機能は名前のみの機能です。 （本当のCMSではありません...そのWikiは本当のWikiではありません...ディスカッショングループは通常のWebフォーラムなどとは異なります。）
- SharePointを真にカスタマイズするには、.net開発者であるだけでなく、.net開発者である必要があります。あなたは本当に.net SharePoint開発者である必要があります。非常に少数のUI/UXの人々は、そのニッチにのみ焦点を当てたいと思っています（たとえそれが需要があり、十分に支払いを行っているとしても）。
優れたUIが必要な場合は、絶対にSharePointから離れてください。私は2番目のSharePointプロジェクト（大企業のIT、7桁のプロジェクト）に参加しています。
会社全体のエンドユーザーは、次の理由でそれを使用することに消極的です。
- ナビゲーションは紛らわしく、ひどく直感的ではありません。すべてが5クリックの深さです。そしてそれはあなたが運が良ければです。
- それは箱から出して非常に醜いです。 SPは'98のように見えますが、それは90年代にとって侮辱になるでしょう。当時のUIはもっと優れていたと思います。
- 非常に厳格であり、高度なカスタマイズはできません。エンドユーザーは "SharePoint Way"のことを学ぶ必要があります。それがすばらしい開発プラットフォームであると言うこれらの嫌いな人に耳を傾けないでください。そうではありません。
- 上記のいずれかを変更したい場合は、少なくとも3つのハックの深さを取得する必要があります。
- どれだけのハードウェアを投入しても、同等のVanilla ASP.NETサイト、RoRサイト、LAMPサイト、または私が考えることができる他のほぼすべてのサイトよりも常に遅くなります。リンクまたはダイアログボックスの[OK]ボタンをクリックすると、ゆったりと数え始めるか、コーヒーを飲みに行きます。
- 「膨らみ」に新しい意味を与えます。 SP 2010の12,000を超えるCSSクラス。当社に来たMS担当者によると。CSSを少し調整することでサイトに新鮮な外観を与えると思うなら、それは間違いです。 .who-knows-where、Webパーツ、Webパーツゾーンからの継承、SharePoint（技術的にはasp.net）がIDに付ける名前にWebコントロール名、guid、および他の意味不明なことはおそらく役に立たないでしょう。
私は、SPのアーキテクチャ上の深い欠陥に陥ることなく、UIの問題に固執しようと試みました。 SharePointチームが優れたソフトウェア設計のすべての基本的なテナントに成功したとしましょう。 SharePointがエンタープライズマーケットシェアで第1位であり、それが良いことを意味すると主張したい人に、マクドナルドとハンバーガーを紹介します。
それは大きな質問です！
SP2010が以前のバージョンより優れたUXを提供していることは間違いありませんが、UXとUIの設計に関しては、SharePointコラボレーションサイトが妥協することになります。
最大の問題は、Webパーツを操作するときに直面する制限と、コントロールの焼き付けです。これは常に、デザインで達成できることを制限することになります...これらは生成するコードを編集することはできませんが、jQueryは最近、css参照を追加するためのより多くの可能性を提供します。
次に、SharePointワークフロー内で作業する必要があります。開発者だけでなく、ユーザーにも特定のパターンと実践があります。私がSharePointで経験した最大の問題の1つは、人々にSharePointを使用させ、その（巨大な）機能を利用させることです。
最大のセールスポイントは、他のマイクロソフト製品との統合であり、これからもそうです。開発するプラットフォームとして-それは可能性の世界を提供しますが、それを中途半端に行うと、適切なユーザーエンゲージメントがなければ、おそらく横ばいになります。
MSソフトウェアおよびサービスとシームレスに統合できるコラボレーションスペースを提供したくない場合は、より良いソリューションがそこにあるかもしれません。
それは私の意識の流れの意見です、しかし、他の人が賛否両論でより良いケースを作ることができると私は確信しています！
SharePointのカスタマイズの開始点は、常にHeather Solomonのブログとカスタムマスターページです。 SharePoint Designerは必須であると言う人もいますが、私は常にVisual StudioでCSS/HTMLを手動でハックすることを好んでいました（私はしっかりと3日間かけてコアを分解しました.CSSとレイアウト/フォント/色に分割しています...回:)
SharePointのアクセシビリティ（具体的には第508条への準拠）は非常に欠けています。ボルトオンアクセシビリティ（たとえば、Accessibility Kit for SharePoint（AKS）での以前の取り組み）と「よりアクセシブルなモード」への多くの指針がありますが、システムアーキテクチャからは、単一サーバーのスモールオフィス実装以外では機能しません。
デフォルトのスタイルとテンプレートにはアクセスできません。基本の痛みを伴うリマインダは、すべてのすぐに使えるエクスペリエンスにあります。テンプレートの写真に代替テキストはありません。多くのWebパーツにはアクセスできず、一部はあまり使用できません。残念ながら、サードパーティのアドオンにも通常はあまりアクセスできません。
最善の解決策は、独自のWebパーツを作成する可能性のある問題を認識している人です。しかし、カスタム開発する必要がある場合、それはSharePointを使用するという意図されたビジネス上の利点を打ち負かします。
SharePoint 2010は実際には悪くありません。少なくとも以前のバージョンと比較して。私はSharePoint MCPと.Netの開発者です。そのため、少し偏見があるかもしれませんが、SharePointを使用する準備ができていれば、SharePointで多くの優れた機能を実行できます。
実際の問題は、非常に優れたSharePoint Webサイトの構築とサポートに関する専門知識を簡単に入手できないことです。それは可能です（FerarriのパブリックサイトはSharePointで構築されているようです）。ただし、SharePointが提供するすぐに使用できる機能が、それを価値あるものにするかどうかをさらに深く検討する必要があります。そして、その決定を下すのに役立つSharePointエキスパートが必要です。
これらすべてにより、選択肢を選択できるようになる可能性があり、回答を得やすくなります。