Art-Break .log : Taichi Nakamura
Microsoft 365 ( Office 365 ) ・ Power Platform ・その他の情報発信ブログ
小ネタです。
Wikiページ ライブラリのアイコンに花があるけどなぜだか知っていますか？いや、作った人に聞いたわけじゃないので僕もMicorosoft社の正式な回答として知っているわけじゃないけど、調べれば推測できます。
Wikiの語源はハワイ語の「Wiki（ウィキ）」もしくは「WikiWiki（ウィキウィキ）」とされています。
そしてハワイ州の州花は「イエローハイビスカス」です。アロハシャツにはハイビスカス柄が多いですよね。
つまりあのお花はハイビスカスなんですね。
ビジネス色の強い SharePoint の中で一輪の花。和み…ますかどうかは人それぞれですが…。
以上、小ネタでした。
先日、 iOS で SharePoint アプリのアップデートがありました。アップデート内容を見るとコミュニケーション サイトに完全にアクセスできるとの事。早速チェックしてみます。
その前に、SharePoint アプリをインストールしてはいるけど、ほとんど利用した事がないので通常のサイトがどう表示されているかもよくわからないのでチェックしました。
▼アプリでサイトを表示するとホームページではなくこんな感じでサイト内のアクティビティが表示されます。
▼バーガーメニューのアイコンをタップすると左からナビゲーションがスライドします。
▼ホームを表示するとクラシック表示だとPC表示のまんま表示されます。
スマホからの利用ではやはり使いづらいですね。
▼モダンUIのサイトでもやはりアクティビティが表示されます。
▼バーガーメニューからホームをタップすると新しい表示なのでレスポンシブ。
スマホからの利用でもクラシック表示よりは遥かに利用しやすいですね。ただこのホーム画面からは閲覧はできても投稿はできなさそうです。ホーム画面は閲覧するもので、投稿したい場合はバーガーメニューから各アプリにアクセスして、そこで投稿する流れでしょうか。
では、本題のコミュニケーション サイトをアプリから表示してみます！
と…、その前にジラしてしまいますが、念のためPCブラウザでスマホサイズにした際の挙動も比較のためにチェックしてみます。（コミュニケーション サイトは作成されたテンプレートのまま）
▼このようにレスポンシブなのでスマホサイズでもタイル部分がカルーセルUIで表示など対応。
▼少し下に行くとニュースページのサムネイルなどもスマホサイズで表示。
▼更に少し下に行くとドキュメントが表示。
こんな感じです。とはいえ、PCブラウザをスマホサイズで利用することはあまり想定されないので、肝心なのはスマホからのアクセス。 ようやく本題です。ジラしてすみません。
▼サイトにアクセスしたらアクティビティではなくホームが表示されます。この方が個人的に好き。 「コサ」がどうしても気になります。
▼少し下に行くと同じくニュースページのサムネイルやらイベントが表示。
ただ、PCブラウザをスマホサイズで表示と違う点があるんです。それは、ここもホームから投稿できない点です。
その上で使ってみるとわかるのですが、例えばニュースを新しく投稿をするのがちょっと面倒だったりします。数アクション必要になります。つまりそこを克服しないと現時点ではアプリからの利用は閲覧用途がメインとなってしまいそうだなぁという印象です。
そしてちょっと困った点を数点発見しました。
ニュースページのサムネイルをタップしてニュースを表示した際なのですが…
▼戻るボタンがないんです。
左上に「←」があるじゃん？と思うでしょうが、これをタップするとホームに戻るのではなく、サイト一覧画面に戻ってしまうのです。
▼通常サイトを表示すると下部に「＜」「＞」などのボタンがあるバーが表示されるんですけどね。
話を戻して…
▼この状態でバーガーメニューをタップするとなぜか「ホーム」がハイライトされたままです。
▼ニュースページを開いた状態で右上の「…」をタップし、「更新」をタップすると…
▼なぜかこの操作でホームに戻れるんです。
ニュースページに遷移しても「ホーム」がハイライトされている、つまり現在地がホームであると示し、更新をタップするとホームが表示されるという事は…、ニュースページもホームであるという事でしょうか。感覚としてはURLの遷移はなくモーダルウィンドウっぽい挙動のような。SharePoint 的に言うとダイアログボックス表示のような振る舞いのような。とにかくホームに戻るのもわかりにくい感じです。
【追記】
戻るボタンはないけど、画面左端（画面外）から右にスワイプすると戻る事がわかりました。
バーガーメニューから「ドキュメント」をタップすると、 OneDrive アプリが起動するのですが、今のところ100%の確率でアプリが落ちます。これは僕のiPhoneだからなのかはわかりませんが。
【追記】
実は僕のiPhoneは容量不足でExcelやWordやPowerPointのアプリを入れていませんでした。機種変してこれらのアプリを入れた後に「ドキュメント」をタップすると、OneDrive アプリではなく、それぞれのアプリが立ち上がり、無事に内容が表示されることがわかりました。
という事でツラツラと書いてきましたが、結局のところ個人的にはアプリを使ってスマホからバリバリ使用するにはまだちょっと早いのかなといった印象です。まだまだはじまったばかりなので今後に期待ですね。僕の方も正直アプリは全然ノータッチだったのでもう少し使ってみようかと思っています。
SharePoint だけでも色々奥が深いのに、日々進化していくので付いていくのが大変っすね。楽しくもあるのですが。
前回の記事では、新しい表示のライブラリでは、[ 新規 ]→[ リンク ]から作成したリンクのリンク先URLは、作成後に変更する事ができなかった件を紹介しました。
SharePoint 新しい表示（モダンUI）のライブラリの「リンク」で作成したリンクのリンク先URLは変更できない
このライブラリにリンクを作成する機能は新しい表示から実装された機能ではなく、古くから「ドキュメントへのリンク」コンテンツ タイプを利用すれば実装できる機能でした。そちらで前回の記事と同じ検証をしたところ、「ドキュメントへのリンク」コンテンツタイプではリンク先URLの変更は可能な事が判明したのと、副産物としてドキュメントへのリンクと新しい表示のリンクでは、同じリンクでも実装方法が違う事がわかったので紹介します。
まずは「ドキュメントへのリンク」コンテンツ タイプを追加する方法から念のため紹介します。
▼リストを作成し、詳細設定の「コンテンツ タイプの管理を許可する」を「はい」
▼詳細設定のコンテンツ タイプセクション下部の[ 既存のサイト コンテンツ タイプから追加 ]をクリック
▼「ドキュメントへのリンク」を追加しOK
これで完了です。次に検証へ。
▼[ 新しい ドキュメント ]→[ ドキュメントへのリンク ]
▼新しい表示の時と同じくYahoo!へのリンクを作成
▼リンクもドキュメントなので、新しい表示の際にはなかったけど、ドキュメントのプロパティの編集画面が。特に何もないのでこのまま保存。
▼新しい表示と同じく、ドキュメントとしてリンクが表示され、クリックするとYahoo!が表示されます。
ここまでは新しい表示とほぼ同じなのですが、新しい表示の方のリンクのファイルはショートカットリンクであり、「.url」がついていました。
一方、ドキュメントへのリンクで作られたリンクのファイルは「.aspx」でした。
同じリンクだけど実装方法が違いますね。さて、検証に戻ります。
▼該当ドキュメントを選択し、リボンの「プロパティの編集」をクリック
▼URLが変更できそうです
▼Googleに変更します
▼Googleに変更され、クリックするとGoogleが表示されます。
前回の記事と2回でライブラリにリンクをつける方法を新しい表示の「リンク」と「ドキュメントへのリンク」コンテンツ タイプで2種類紹介してきましたが、他ライブラリのドキュメントのリンクでもWebサイトへのリンクでも、後々になって修正が必要になる場合は、新しい表示の「リンク」より、「ドキュメントへのリンク」コンテンツ タイプを追加した方が良さそうですね。
ちなみに新しい表示に「ドキュメントへのリンク」コンテンツ タイプを追加してみました。
▼このように「リンク」と「ドキュメントへのリンク」が共存していますね。（これはこれでややこしい）
▼2種類の方法で投稿したらこうなりました。
など、色々な呼び方がありますが、 SharePoint 内では「新しい表示」と記載されているので、ここではそう呼びます。
では、まずはライブラリのリンクとは？
▼この「新しい表示」でライブラリを利用していると、 [＋新規] の中に [リンク] というのがあります。
▼クリックしてみると右にパネルが出現します。
▼ [最近更新されたファイル] のファイルをクリックすると、即リンクアイテムが作成されます。
▼このようにライブラリ内にショートカットリンクを作成する事ができ、ライブラリ外のファイルにリンクができます。もちろんクリックするとリンク先のファイルが開きます。（新しいタブで表示されます。）
このリンクはファイルだけではなく、Webサイトへのリンクも可能です。
▼試しにYahoo!のURLを入力して作成します。
▼このようにリンクが作成され、クリックすると新しいタブでリンク先が表示されます。
これは「新しい表示」から備わった新機能かと思ったのですが、そもそも昔から「ドキュメントへのリンク」というコンテンツタイプを使えば使えていましたね。
このように作成されたリンクですが、後々リンク先URLを変更したい事もあると思いますが、それがなかなかできないんです。以下、例として上述で作成済のYahoo!へのリンクを、Googleに変更しようと試みます。
▼該当アイテムを選択してとりあえずコマンドバー内に「名前の変更」があるのでクリックしてみます。
▼このようなダイアログが出現し、なんか変更できそうなので、試しにGoogleのURLに変更して保存してみます。
▼あれ？なんか怒られてしまいました。つまり「://」が禁則文字のようです。
▼ではhttps://を外して保存をします。変更されました。
しかし！クリックするとYahoo!が開くんですよね。つまり「名前の変更」の言葉の通り名前だけ変更されてリンク先URLは変更されなかったんです。
じゃ、URLはどうやって変更するんだろう？他にUI上にある操作を試します。
▼ […] → [詳細] はどうでしょう？
▼パネル内に [名前] [タイトル] が編集できそうなところですが、つまりここも同じく名前の変更だけでURLの変更はできません。
では上図のプロパティの右にある [すべての編集] というリンクがあるのでクリック。
▼ドキュメントのプロパティ編集画面になりましたが、ここも同じ構成。つまりURLの変更はできません。
※ […] → [その他] → [プロパティ] も結局はプロパティ編集画面へのリンクです。
あれ？UI上でリンク先のURLを変更するのは手詰まりになりました。
仕方ないので、次に着目する点としてこのリンクはショートカットリンクというファイルなので、それを修正してみようかと思います。
▼とりあえずこのリンクをダウンロードしてみます。
▼www.google.co.jpと書かれているのにYahoo!のロゴという悲しいショートカットリンクがダウンロードされました。
▼URL部分をGoogleのURLに変更します。
▼念のため、テキストエディタでショートカットリンクを開くとこんな感じで変更されています。
▼変更したショートカットリンクをライブラリに上書きアップロードしたのですが、相変わらず変更されていません。
ファイルを変更すればリンク先URLも変更されると思ったんですけどね。不思議なのは、この状態で再度ショートカットリンクをダウンロードしてテキストエディタで中身を見ると、googleのURLになっているんですよね。なぜかライブラリのアイテム上では変更されない不思議現象です。もちろんブラウザのキャッシュをクリアするなども試みました。
仕方ないので、一度該当ファイルを削除し、上書きしてもダメだったファイルを再アップロードしました。
▼すると不思議な事にリンク先URLがGoogleに変更されました。同じファイルなのに…。
つまり、原因はわからないけど上書き保存ではリンク先URLは変更されないようです。
結果として、一度作成したショートカットリンクのリンク先URLを変更する手順は、
ん？いやいや、こんな事をするならリンクを作り直した方がまだ早い！つまり、結果的にリンクのリンク先URLは変更できないという事ですね。
ライブラリ内にWebサイトのリンクをアイテムとして作成するニーズがどれだけあるかはわかりませんが、リンクのリンク先URLはUI上では変更できない点と、UI上じゃなければ変更できるけど若干面倒である点を頭の片隅に置いといていただければと思います。
※変更できる方法がある！という場合は、ご連絡ください。
↑このくらいならCSSできる人なら30分～1時間程度でCSSのみでカスタマイズできます。
※サイト全体に適用するのではなく、ページに適用させる方法。
※クラシックUIの場合。
※発行機能が非アクティブの場合。
基本的にはCSSはCSSファイルに記述し、HTMLにはhead内にCSSファイルのリンクを記述します。もちろん SharePoint もそういう仕組みになっていますが、それは SharePoint 側が持っている既定のCSSファイルです。
CSSでオリジナルのカスタマイズを加える際に、マスターページを加工するなどすればhead内にオリジナルのCSSファイルのリンクを加える事は可能かもしれませんが、やはり極力マスターページに手を加えたくはありません。（そもそもマスターページに手を加えるとサイト全体に適用されます。）
では気軽にCSSファイルのリンクを追加する方法は？というと、 SharePoint では昔から「コンテンツ エディター Webパーツ」を利用する方法があります。これは簡単に言えばHTMLを埋め込めるWebパーツです。今なら「スクリプト エディター Webパーツ」の方が主流なのかな。どちらにでもCSSファイルのリンクを記述すれば適用されます。
▼コンテンツ エディターWebパーツとスクリプト エディターWebパーツを挿入したところ
（もちろん実際はどちらか1つでOKです。）
▼コンテンツ エディターWebパーツのソースを記述するダイアログ
▼スクリプト エディターWebパーツのソースを記述するダイアログ
ただ、これは非常に気持ち悪い方法なんですよね。本来はhead内に記述すべき内容をbody内に記述する事になるので。
▼body内にlinkタグが入る感じになります。
しかし、気軽に適用させる方法としてはこれしかありません。そもそも SharePoint がValidなHTMLから程遠い（それでも SharePoint 2007 に比べれば遥かに良くなったけど。）ので、この際無視してください。本職のコーダーさんあたりは非常に気持ち悪いとは思いますが我慢です。
基本的には SharePoint が既定で持っているCSSを上書きする記述となります。なので!importantは結構使う機会があると思います。そしてHTMLはさわれないと思ってください。なので、まずは SharePoint の標準機能の範囲内でアプリ・Webパーツをページに適切に配置します。その状態で開発者ツールなどでソースを確認し、適用させたい要素・またはその周辺にユニークなidやclassがあるかどうかを調査し、そこに対して適用させるCSSを記述する感じです。
しかし、そのidやclassがどこでどのくらい利用されているかを把握する事はなかなか難しく、実際に適用させて（開発者ツール上でもOKですね。）目視で確認し、試行錯誤していく感じになります。また、ユニークなidやclassがない場合はセレクタを駆使してなんとかなる場合もありますし、諦めるのも大事な選択肢です。無茶して適用したところで管理面で難があったりすると良くないですからね。
Webパーツの構造は全てほぼ一緒なので、Webパーツ内のスタイルを変更した場合は基本的にはページ内の全てのWebパーツで適用されると大げさに思って良いかと思います（厳密には違いますが）。ただ、中には指定したWebパーツのみスタイルを適用させたい場合もあると思います。
調べてみるとわかりますが、ページ内でWebパーツごとにユニークなidが存在します。例えば「WebPartWPQ6」。この数字部分（←の場合は6）に関しては、Webパーツが増えていくごとに数字が増えていきます。つまりWebパーツごとにあるユニークなidなのですが、ただこのidの使用はあまりオススメできないんです。
というのも、Webパーツが今後増減しない確約がある場合は良いのですが、特にWebパーツを削除する事がある場合は、削除するとページ内の全てのWebパーツのidの数字がゴソッと入れ替わってしまうので、このidを利用したCSSの全て数字を変更しなければいけないからです。
▼このように番号が若いパーツほど削除すると影響度が高いです
ではどうしたら良いか？というと、ページの作り込みで工夫が必要です。ページではWebパーツ領域内にHTMLを記述する事が可能です。それを利用して、例えばユニークなidかclassでdivを記述し、そのdiv内にWebパーツを配置します。囲んでしまえばユニークなidかclassを利用してそのWebパーツのみ適用させる事が可能となります。
▼Webパーツ領域にカーソルを置き、ソースの編集を
▼例えばユニークなclassをつけたdivを2個ほど置きます
▼それぞれのdiv内にWebパーツを追加します
（この操作もコツがいたりします。）
▼再度ソースの編集を見ると、このようになります。
（思い通りのソースになっていない場合はここで修正）
▼ここまでできれば、指定のパーツのみにスタイルを適用させられます。
（例：list001のみ枠線を付けました。）
あまり気にしなくても良いのかもしれませんが…。CSSファイルのリンクを記述したコンテンツ エディター Webパーツやスクリプト エディター Webパーツは、隠しWebパーツである事からも表示上は見えないので気にしなくても良く、ただページを編集モードにした際には邪魔なので、極力ページ下部に配置したいところです。
しかし、以前この方法をとったところ、表示に重いWebパーツがあると、カスタマイズしたスタイルが当たるのにタイムラグが発生しました。つまり例えば1秒程度、標準状態のデザインになった後にカスタマイズされた状態になる感じです。これは、HTMLが上から読み込む構造上、CSSファイルのリンクの記述が読み込まれる前に、表示が重い部分があるのが原因と推測し、CSSファイルのリンクが記述されたWebパーツを極力上部に配置すると、この問題が解消されました。
つまり、HTML的には極力ソースの上部にCSSファイルのリンクを記述された方がよく、SharePoint 的には極力CSSファイルのリンクを記述したWebパーツを、コンテンツ領域の左上に配置するのが良いかと思います。ただ、通常は後ろの方にあってもタイムラグが発生するケースはあまりないので、あまり気にしなくても良いのかなと思います。
どこでも良いっちゃ良いんですけどね。極端な話、リンクができれば良いので、 SharePoint じゃなくてもどこかのWebサーバーに置いても良いくらいです。とはいえ、まぁ SharePoint のライブラリ内に保管するのが良いとは思いますが、ここで気をつけるべきはアクセス権限です。
サイトのアクセス権限よりも権限を絞ったライブラリに保管をすれば、もしかしたら中にはライブラリには閲覧権限がないけどページには閲覧権限がある可能性もあり、この場合はそのユーザーはCSSファイルに権限がないので、結果としてカスタマイズが適用されない状態でページが表示されます。逆に管理者以外に多くのユーザーが投稿権限以上が付与されているライブラリに保管をすれば、勝手にCSSファイルを編集したり削除する事も可能になってしまうので良くないですね。このような点に気をつけたライブラリであるならどこでも良いかと思います。スタイルだからスタイルライブラリに保管しなければいけないというわけでもないと思っています。
以上です。
他にも語ることは色々あるかもしれませんが思いついた時にまた記事にします。また、あくまでも僕の自己流なので参考程度にしてください。他にもっと良い方法があればむしろ教えてください。
悲しいことに「 SharePoint はデザイン的に微妙。使いにくいから使ってもらえない。」って良く聞きますが、僕は必ずしもそうは思っていません。（もちろん、非の打ち所もないくらい素晴らしいとも思っていないし、不満も多々ありますが。）
少しトゲのある言い方ですが、良く学ばずにうまく構築できない・うまく利活用してもらえない人の責任転嫁だと思っています。
例えば、SharePoint の利用用途の大きな一つに「社内ポータルサイト」が挙げられると思います。 SharePoint を全社的に導入して社内ポータルサイトがない企業はなかなかないのではとも思っています。いわゆるイントラサイトという性質上、通常のWebサイトのように公開されておらず、多くの企業の担当者は「他社はどんな使い方をしているのだろうか…どんなトップページだろうか…」などモンモンとしているのではと思います。
SIerなどは業務の性質上、様々な企業の社内ポータルサイトを構築しているとは思いますが、 SharePoint 技術者がWebデザインにまで精通していない場合も少なくはなく、おのずと説得力のある提案ができずに、お客様の要件に従うだけの場合も少なくはなく、結果的に社内ポータルサイトという観点では SharePoint の成長は鈍化しているかもしれないです。
僕も長くユーザー企業側の人間だったのでモンモン組でしたが、過去に貴重な経験が数回あり、他社の社内ポータルサイトを拝見できる機会もありました。もちろん中には素晴らしいと思えるサイトもありましたが、多くは…悪口に捉えられるといけないのであまり語りませんが、…なサイトが多かったです。
通常のWebサイトとは目的が異なるのですが、やはり特に社内ポータルサイトであればIA・UXに（精通していなくとも）ある程度知識や意欲のあるメンバーが一人でも必要だと考えます。
一般的な人が「Webデザイン」って言うと勘違いしがちなのが、Webデザイナーのセンスに依存するものだと思うこと。たしかにデザインと聞けば100%アーティスティックなイメージがありますが、特に企業サイトなどでは、Webデザイナーのセンスというよりは、デザインの一つ一つは非常にロジカルなんですよね。つまり、どこにどのようなコンテンツを配置したり、余白だったり、配色なども、全てデザイン・レイアウトは論理的に説明できるというわけです。逆を言うと説明できないといけないと思っています。そういう意味でもIA・UXの観点は大事で、だいたいそこを担当する人が不在な事が多く、社内ポータルの構築メンバー視点だけで構築を開始し、言い方悪いですが構築メンバーの独りよがりなサイトになってしまいます。
しかし、あくまでも利用するのは利用者です。UXが大事というのはそういう事です。（構築メンバーの思いと利用者の感想は往々にして剥離しているケースが多いと経験則から感じます。
通常のWebサイトはターゲットが大げさに言えばネットができる世界中の人々なのに対し、社内ポータルのターゲットはいくら広くしても全従業員、とかなり絞れるのでむしろ考えやすいと思っています。つまり、しっかり考慮して構築すれば効果は高いのではと思っています。
IA・UXを本業にしている人を導入するとなると敷居が高いですが、勉強して少しでも知識をつけるだけでも違うと思いますし、そういうのが楽しいと思える人がメンバーにいるだけでも違うと思います。また、SIerに依頼する際にはそういう観点からもSIerを選定する事も大事であると思うし、SIerも SharePoint の技術者やプログラミングだけでなく、IA・UXに明るい人材をもっと増やすべきだと思っています。
これ昔から思っているのですが、 SharePoint に限らず様々な業務システムが存在しますが、UXを全く考慮されていない使い勝手の悪いシステムが多いように思います。もっともっとIA・UXを重視しお金をかけるべきかと思います。それが結果として良い製品となり、品質も高くなるのではと思います。
例えば勤怠管理システムのようにそれを導入すれば即利用できるものと違い、 SharePoint はそれ単体だけでは何もできなく、そこから「勤怠管理用に」構築を経て始めて利用が開始できる製品なので、その構築の仕方で使いやすさも左右されるのは当然で、構築が未成熟なのに SharePoint がダメだとレッテルを貼るのは、まだ早いのかなと思います。
※長文の文章のみとなります…。
「部門ポータルの掲示板（リスト）に掲載したアノ情報だけど、全従業員にも見てもらいたいから社内ポータルの掲示板にも掲載しておいて！」
上司からそう命じられて、部門ポータルのリストに投稿したアイテムと全く同じ情報を、コピペで社内ポータルのリストにも投稿しました。
よくある話だと思いますが、実際にトラブルにつながる可能性があります。
「掲示板に掲載されていた自社製品情報をお客様にお伝えしたところ、後日、それが古い情報で損害が出たとのクレームを受けた。」
信頼に関わるトラブルですね。調べてみると、部門ポータルと社内ポータルに両方に同一タイトルのアイテムが投稿され、その後情報が変更された際に、部門ポータルのアイテムは更新されていたが、社内ポータルは更新されていなかった。投稿者に話を聞くと、両方に掲載した事を失念しており、部門ポータルのみを更新したとの話。
十分ありえる話ですよね。
ここでの問題は社内ポータルの更新を失念した更新者…もありますが、投稿を多数行っている人にその問題を押し付けるのはかわいそうですね。運営面から考えると、同一情報を複数個所に掲載しているという点です。これはメンテナンスが大変だし、トラブル事例のようにヒューマンエラーの可能性が上がります。特に、投稿者が退職などすると余計ありえますね。
※以下は、あくまでも解決のための一例です。
ここでタイトルの通り、情報の一元管理が大事です。ただし、部門ポータルに掲示した情報を社内ポータルにも掲示するな！という事は言いません。
まず考えるべきはその情報をどこに保管するのが一番ふさわしいか？です。
今回はまず部門ポータルに掲載されたことからも、またその部門発信という事からも、またその部門がサイトを所有しているということからも、部門ポータル内に情報を掲載する事で良いと思います。
次に一元管理しつつ全従業員にも見てもらうには？
社内ポータルの掲示板を利用しても良いと思いますが、大事なのは掲載方法です。ここでコピペで同じ情報を掲載すると二重になってしまいます。ただ、Webの醍醐味は「リンク」なので有意義に使いましょう。つまり、社内ポータルに掲示する本文には詳細内容を記載せず、概要のみと部門ポータルに掲示したアイテムのURLのリンクを起きましょう。そうすれば、リンク先の部門ポータルの掲示したアイテムのみをメンテナンスすればOKなので、更新し忘れはなくなります。
例で考えると、社内ポータルの掲示板のアイテムにアクセスしたユーザーには、更にワンクリックを強要してしまう事になります。Webサイトの場合、ユーザーアクションをいかに減らす事を考慮しますが、ただし SharePoint に関してはWebサイトの考えがそのまま当てはまるわけではありません。つまりユーザーにとって本当に重要な情報であれば、離脱せずにワンクリックするからです。クリックされないならそのユーザーにとってはその程度の情報なのです。そういう意味でも大きなデメリットとは思えません。
次に、情報源であるリンク先のアイテムを移動したり削除されたら？
たしかにリンク元からはデッドリンクになり情報にたどり着きません。ただ、しつこいようですが本当に必要な情報であれば、リンク元アイテムの投稿者に連絡するなりします。更新し忘れて誤情報を元にトラブルになるリスクを考えれば、デッドリンクになった方がまだリスクは低いと考えます。もちろん、ユーザーからデッドリンクになっている連絡が来たら、投稿者がリンク先を更新すれば良いだけですし。
ユーザー目線で考えてみましょう。社内ポータルの掲示板を従業員が読んだとして、その情報が自分にとって必要と判断すれば読むでしょう。そこにリンクがついていればリンク先に行きます。例えばそこで「こんな部門ポータルもあったんだ！」と気づく場合もあります。自分に関連する情報であれば他の情報も気になる可能性もあります。そうすると初めて訪れたその部門ポータルの別のコンテンツも見る可能性もあります。つまり、利用者が増える可能性があがるわけです。
情報の一元管理が適切にでき、本来保管すべき場所に情報が鮮度を保たれて保管され、更に自分のサイトのPRにもなれる。
このような運営方針を投稿者レベルまで落とし込んで啓蒙しクセをつけてもらう事により、より安全な運営ができるのではないでしょうか。投稿者が多ければ多いほど、徹底させるのはなかなか難しいですけどね。
コミュニケーション サイトがようやく利用できるようになったので早速サイトを作ってみました。ワクワク！
色々触っているうちに気になった点があります。レスポンシブ対応だったと思ってブラウザの幅をウネウネと変えてみたんだけど、一般的なレスポンシブのWebサイトとどうも挙動が違うんですね。コミュニケーション サイトは幅を変えてからワンテンポ遅れてレイアウトが変わるんです。
▼幅を縮めるとこのような状態に。一瞬「え？これがレスポンシブ対応？？」と疑ってしまいました。
▼1秒ほど遅れてサイズに合ったレイアウトになります。そりゃそうだよね、安心した！
開発者ツールでウォッチしてみると少しわかりました。定点しか見ていないので全体は把握できていませんが、例えばdivにstyle=”height:300px”など、CSSがインラインで書かれているんだけど、サイズを変えて1秒ほどするとその300pxの数値が変わるんです。 Nintex Forms のパネルの表示・非表示の挙動に類似しています。
Heroと呼ばれる画像がタイル状になっているパーツに関しては、ブラウザが広いとタイルですが、狭いとカルーセルに変わります。その際に隠れるタイルがdisplay:noneで消えるのかと思ったら、どうやらゴソっとHTMLが変化しているようです。
つまり、ブラウザサイズを変更するとHTMLやらCSSやら諸々が再描画される感じでしょうか。ちょっと普通のレスポンシブ対応とは違った感じです。あまり気にしなくても良いとは思うけど、パフォーマンスに影響はないでしょうかね。 Nintex Forms に関してはあまり1ページに多数のコントロールを配置すると一気にページの読み込みが遅くなるので。また一般的なWebのレスポンシブ対応とは異なるので、ここにさらにカスタマイズを加えようとすると、一筋縄ではいかないのかもしれないですね。
とりあえず10分くらい触ってみた時に気が付いた事でした。
リストにアイテムを大量に追加する際に、一つ一つ投稿していたら大変なので、クイック編集で一括コピペしたい場合があります。クイック編集で「管理されたメタデータ」列に追加する場合、すでに投稿済みの他のアイテムの値からコピペする事は可能ですが、Excelなどからコピペができません。これ、あとから出来ない事に気がついて焦るケースもあります。
▼こんな感じで管理されたメタデータを作成します。
▼1件は普通に投稿し、クイック編集に。管理されたメタデータ列の値を選択しコピー。
▼新しいアイテムの行にペーストをすると、問題なくペーストできます。
▼クイック編集を完了しても問題なく投稿されています。
▼同じリストに以下のExcelのデータをコピペします。
▼なんだかビックリマークのエラーが出ています。
▼ビックリマークをクリックするとエラー内容が。
▼もちろんこのままクイック編集を完了しようとしても保存できません。
管理されたメタデータの値と同じ文字列なのになぜExcelからコピペができないのか？作成した管理されたメタデータを見るとわかってきます。
カスケード分類できる事からもフラットではなく階層を持つ事ができ、それぞれの階層には同じ文字列は登録できませんが、別の階層には登録できます。例では「八百屋A店」の中に「キュウリ」を2個登録はできませんが、「八百屋A店」と「八百屋B店」の中に同じ「キュウリ」が存在していることがわかります。つまり、この列に「キュウリ」という文字列を単純に入力したところで、A店のキュウリなのか？B店のキュウリなのか？の判定ができませんよね。なので、登録したままの値では受け付けないんです。
では、どのような構造になっているのか？
▼通常の投稿でA店のキュウリとB店のキュウリを入力しましたが、見た目はわかりません。
▼クイック編集にして二つのキュウリの値をコピーしテキストエディタにペーストしてみます。
キュウリ|2c5d590a-ded0-4477-a93b-095c1c3f5843
キュウリ|ca8e4e7a-b256-4e7c-a302-8b0cffa830c4
このように「表示名|内部名」でペーストされました。（この|以下の文字列が「内部名」という表現で正しいかは不明です。）UI上では見えませんが、このように内部名と紐付いて一意の値になっています。このような仕組みになっているので、Excelからコピーしたデータでは、管理されたメタデータ列ではペーストする事ができません。
ちなみに、
▼「表示名|内部名」でExcelのデータを作成し、
▼クイック編集でコピペをするとペーストできます。
▼しっかり投稿されています。
とはいえ、管理されたメタデータの全ての値の「表示名|内部名」を調べる必要があるし、それを元にExcelデータを作成するのもダルい作業ですよね。
リストを作成する際にニーズとしてExcelでまとめたデータからクイック編集で大量にアイテムを作成する想定がある場合、気をつけなければいけませんね。
いわゆる選択肢を実現したい場合の列の種類は、「選択肢」の他にも「参照」「管理されたメタデータ」と、合計3種類があります。この3種類にはそれぞれ特徴があるのですが、リスト作成時の全体的なニーズに対し、選択肢を追加する際にどの列の種類を利用するのが適切なのか？というのは、それぞれの列の種類の特色を把握していないとなかなか判断できません。
例えば、選択肢列以外の種類ではビューのフィルター条件の一部が利用できなかったり、集計値列で利用できない、など以外と忘れっぽい制限事項などがあり、後々できなくて困る事もあるかと思います。他にも過去の記事にこんな例もあります。
トラブルにならないように3種類をまとめてみたいと思います。
まずは3種類の特徴を大まかに。
では、それぞれの機能を○×で表にしてみました。
※1
参照元リストの別の列をビューに表示させられるのは SharePoint 2010 以降。
※2
クイック編集内で別アイテムの値をコピペする事は可能だが、テキストファイルやExcelファイルなどからコピペはできない。（これは後日、別記事で紹介できればと思います。）
※3
既定で1時間インターバルのタイマージョブで変更されるため、最大で変更に59分かかる。
※4
カスケード分類とは？
「入力フォームでよくある、都道府県で神奈川県を選択すると、市区町村の選択肢は神奈川県内の市しか表示されなくなるアレ。」みたいに例えないと、未だに一発で理解できる用語が出てこない機能。SharePoint 界では「カスケード分類」があえて言うならメジャーな用語なのかもしれないけど、その「カスケード分類」と口にしても、未だに追加で都道府県の例えを話さないと理解してもらえない。
※5
利用できる参照元リストはサイト内のリストのみ。
以上です。
例えば、リストのフルコントロール権限は付与しても、選択肢の値の変更を許したくない場合は、選択肢列以外の利用が好ましいですね。参照を利用すれば、参照元リストの権限を閲覧にすれば解決ですし、管理されたメタデータであれば、用語ストアに登録し、その用語セットの権限でコントロールすれば解決ですし。
例えば、カスケード分類が必須であれば、管理されたメタデータのみですね。
例えば、大量の投稿がある事が予測されていて、かつ値は途中で変更する事があり、投稿済アイテムの値も変更に連動させる必要がある場合は、選択肢列は避けないと危険ですよね。（上述で紹介した記事を参照）
あらかじめそれぞれの特徴を把握していれば判断に怖くはありませんが、結構忘れちゃいがちなのでこのように表にしておくと良いと思います。