タグ: SharePoint

【結論】

• Enterは段落、改行はShift+Enter

これまた、SharePoint 知っている人にとっては常識なのかもしれないけど、投稿者レベルの利用者は実は結構知らない事だったりします。実際、過去に「行間なんとかならないですか？」というユーザーからの問い合わせが何度かありましたし、教えると初めて知ったというユーザーが多かったです。

先日の記事では投稿者・閲覧者レベルでの教育が必要と書きましたが、例えばこのような小さい事まででも社内ブログなどでTips的に発信すると、良いのではと思います。

本題に入ります。

ページのコンテンツエリアやアイテムの複数行テキスト列のように、Word感覚で文章を装飾できるリッチテキストエディタがあります。

この文章を作成中に改行をしようとEnterキーを押したところ、思った以上に行間が空いてしまって困ったことはありませんか？

改行の操作は「Shift+Enter」なんです。このくらいの行間になります。

じゃ、「Enter」はというと、段落扱いです。比較してみるとこんな感じ。

あれ？行は「改行」なら段落はなんだろう？改段落？？？次段落？？？ま、いっか…。

通常の文章でも改行と段落では段落間の方がスペースは広いですよね。なので改行をする場合はShift+Enter、次の段落にしたい場合はEnterと覚え、意識して使い分けをしましょう。

これ、実はSharePoint のクセじゃなくて、WordもPowerPointも同じなんですよね（ちなみにこのブログで利用しているWordPressも）。そのくらい常識でしょ？と思った方は、その常識は一旦拭った方が良いかもしれません。冒頭の通り、意外と知らない人は多いんです。（正直、僕だって SharePoint で仕事をする前は知りませんでしたもん。）たった少しの説明でコツコツと社内のコンテンツのクオリティが上がるのなら、その手間は「常識だろ…」と惜しまない方がみんなが幸せになります。

さて、ここまでで読み終えても良いですが、ここから先はHTML的な挙動についても書いてみます。

Shift+EnterとEnterはソースコード的にはどのような違いがあるか？リッチテキストエディタ内には「ソースの編集」というボタンからソースを見る事ができます。

1行目のソースはひとつの段落である事を示す<p></p>で囲まれます。つまり1行目でもあり、1段落目でもあります。

Enterを押して2行目を書くと2行目も<p></p>で囲まれます。なので2行目ではなく、2段落目です。

Shift+Enterを押して2行目を書くと改行を示す<br/>が追加され、全体では1段落目のまま、2行目は1段落目の2行目です。

SharePoint2007の頃はリッチテキストエディタで生成されるHTMLは非常に汚く見るに堪えないものでしたが、バージョンアップするごとにだいぶ良くなってきました。

【結論】

• 大文字小文字の違いは違いと認識されず変更されない。
• 法則がわかれば変更可能。

アプリ名やビュー名など表示名は気にするけど、URLまでは気にしない場合はどうでも良い記事です。

列の内部名やアプリのURL（ディレクトリ名？）は作成後に変更はできませんが、ビューに関してはビュー名の他に「このビューのWebアドレス」という欄で、URLの変更が可能です。URLにこだわる場合、大文字小文字も含めて一貫した規則性に従って作成すると思います。複合語の場合は、キャメルケースだの色々な命名規則がありますが、例えば頭文字を小文字で書いていたら、後から大文字に直せと言われた場合。

例として「viewName」を「ViewName」に変更する際に事象が確認できます。

▼「このビューのWebアドレス」が「viewName」になっています。

▼「このビューのWebアドレス」を「ViewName」と先頭を大文字Vに修正します。

▼ところがブラウザのURLを確認すると修正されていません（小文字のまま）。

▼再度ビューの編集ページを開いても「viewName」に戻ってしまっていました。

検証してみた結果なのですが、ビューの編集ページの「このビューのWebアドレス」欄では、大文字から小文字、小文字から大文字の修正は、内部的には大文字小文字の違いは認識されず、変更がない項目としてスルーされてしまうようです。

【対策】

変更されない理由がわかれば対策は簡単です。一旦別の文字列に置き換えて再度変更すれば良いだけです。例の場合だと…

▼「このビューのWebアドレス」からvを削除し「iewName」で修正します。（一旦他の文字列にしたいだけなので、極端な話「a」で修正してもOK）

▼ブラウザのURLを確認すると当然「iewName」に変わっています。

▼再度ビューの編集を開くと「iewName」になっているので、「ViewName」に修正します。

▼ブラウザのURLを確認するとちゃんと大文字に変わっています。

マニアックなところですが、実際に質問されて自分でも知らなかった事象だったので記事にしました。

※今回の記事は長文です。

サーバー管理者レベルでの参考書や無料セミナーなどはよくありますが、閲覧・投稿者レベルでのそれはほとんどないと思います。マイクロソフトからエンドユーザー基本操作マニュアルなるものもダウンロードできますが、あれもサイト管理者レベルなのかなと思います。（探せていないだけ？）

つまり、サーバー構築からアプリ（リスト・ライブラリなど）の作成・設定レベルはすぐに勉強できるけど、投稿方法や閲覧方法などは使いながら覚えて！的な感じです。しかしながら、SharePoint は直感的に全ての操作を把握するにはほど遠いUIでして、SharePoint に詳しい人には常識的な操作であっても、利活用の主役である閲覧・投稿者にとっては直感的に操作をするには厳しい部分もあります。

運営に長年携わっていて多かったユーザーに知られにくい機能の一例

• ビュー内で列でソートやフィルターができる事。
  （例えばマウスオーバーしないと列名の横に「▼」が出ないなど、直感的には機能に気がつかないUI）
• 個人ビューの存在
• 通知機能

これを教えるだけでもSharePoint の印象が大きく変わるであろう機能も、意外と教えないと存在すら気がつかないまま何年もSharePoint を利用しているユーザーは少なくはありません。

ただ、これらSharePoint の機能紹介的な教育よりも大事であると思う事があります。

情報共有とは情報発信だけでは意味がなく、発信された情報が受信され活用されて意味を成します。つまり、発信した情報が読まれなければ意味がありません。言い換えると、投稿者は可読性を意識する事がポイントかと思います。

サーバー管理者やサイト管理者がいくらUIを気にしてデザインのカスタマイズをしたところでそれはあくまでも枠の部分。そこより大事なのは枠の中身です。その中身を作るのは投稿者。その教育が必要だとは思いませんか？
軽く例を挙げると…

• 背景と文字とのコントラスト
• 文章をカラフルにすれば良いというものではない
• フォントサイズと行間の重要性
• テキストリンクが装飾に埋もれてリンクと気づかれずクリックされない

などなど。実際アイテムの中身を見ると、受験生のようにテキストをカラフルにして、白背景に黄色文字を使ってチカチカしたり、リンク色と同じ色をつけているテキストがあって、クリックできるのかと思ったらクリックできなかったりイラっとするものもあったりします。思ってもいないような使い方をするんですよね。これはSharePoint に限らずプレゼン資料など人に見せる資料を作成する人全員に必要な教育でもあるんですけどね。

また、Webのマナーなども重要です。
例を挙げると…

• 引用についてのマナー
• 著作権について

こういう部分も閉ざされた空間だからといって自由であるわけではなく、社内のモラル・マナー向上においても教育は大事だと思います。

ちなみにこの記事を読んでこれらを常識だと思われている人は、すでに自身のスキルや知識に悪い意味で侵されています。非IT企業はもちろん、IT企業であっても必ずしも全従業員がITリテラシーやモラルが高いとは断定できません（従業員を信じたいですけどね。）。

また、なんでも「○○は禁止」といったネガティブな教育をすると利活用促進とは間逆の結果になりがちです。「○○はこうした方が良いですよ」的なポジティブな教育が必要ですね。利用したい・便利だと思わせる事が重要なので。

「教育」というと大きな話に聞こえてきますが、それこそSharePoint のブログ機能やSNS機能を利用して発信しても良いかなと思います。ディスカッション掲示板を利用してユーザー間で解決させる仕組みを作るのもアリかと思います。

サイトコレクションおよびサイトを管理者に渡して「はい、ご自由に」というやり方で運営をしていて、利活用されなくて困っている企業のIT管理者がいらしたら、運営・教育の重要性を少しでも感じていただければと思います。

SharePoint2007時代からSharePointを触っていて、日本語訳に難がある箇所がところどころありました。
例えばアイテムの「閉じる」ボタン。ブラウザ操作で「閉じる」はウインドウもしくはタブが閉じるの意味を連想するので違和感を覚えていました。実際は1つ前のページに戻る、もしくはそのリスト・ライブラリの既定のビューに戻るんですよね。現にユーザーからもウインドウが閉じるかと思って閉じるボタンをクリックした事はなかった、なんて声も出ていました。

話を戻して…
日本語訳が微妙であまり使えなかった機能のひとつに、この記事のタイトルのとおり、選択肢列の「選択肢を追加できるようにする」の機能があります。これはつまりラジオボタンやチェックボックスなどの選択肢で、該当なしの場合に自分で記入できるいわゆる「その他」という選択肢。

これがSharePoint2007だと…

この「選択肢を追加できるようにする」を「はい」にすると…

「値を指定してください」なんて文言なんです。どうも微妙な日本語なのでよろしくないです。特にアンケートリストでアンケートをとる際に利用したいシーンが多いのですが…。

ちなみにこの文言は基本操作では変更できません。仕方ないのでJavascriptを使って変更したり、ユーザーにこういうものだと周知させてこのまま使ったりしていました。

それが！

恥ずかしながらこないだ気がついたのですが、今は文言が変わっていました。

SharePoint2013だと…

「その他 (テキストを入力してください):」
あら、問題ないじゃないですか。

いつから変わったんだろう…

SharePoint2010でも変わっていなかったと思うんだよなぁ。

SharePoint2013に関しては全く記憶がなく…。

これからは気兼ねなく使えそうです。

SharePointでは何をする・させるにしても権限付与の作業が必要ですよね。ユーザーに直接アクセス許可を付与したり、SharePointグループにユーザーを追加したり。ユーザーだけでなくセキュリティグループなどを追加したり。

その中の注意点は色々ありますが、今回注目する点は招待状メールの送信機能です。文字通り、権限が付与されると該当ユーザーに招待状メールが届く機能ですが、権限付与画面で送信するかしないかのチェックボックスがあります。初期値はチェックされた状態、つまり招待状メールが送信される状態です。これがなかなか怖い。

TPOで送信するかしないかをチェックボックスで選べば良いだけなのですが、使い方を間違えるとスパムメール的にもなってしまいますし、管理者に問い合わせが殺到するような事にもなりかねないです。初期値がチェックされた状態なので、ウッカリも多いです。

これ、SharePoint2007では、付与する前に目に見えるところにチェックボックスがあったんですよね（SharePoint2010もそうだったような気がしますが、記憶が…）。試した事がないのでわからないけど、「NT AUTHORITY\Authenticated Users」に権限を付与する際に、このチェックボックスがチェックされた状態で権限を付与したら…いわゆる全従業員にメールが送信されてしまうんでしょうかね。そしたら従業員数が多い会社ほど事故ですよね。怖いんでいつもこの作業をする場合は慎重にチェックが外れている事を確認して付与していました。

で、これは個人的は元に戻してもらいたいと思っているのですが、SharePoint2013ではこのチェックボックスがかなり気がつかないところにあるんですよね。というより隠されているんです。SharePoint2013に触れはじめた時は、メール招待状の機能自体がなくなったのかな？と思うくらい。でも、まだ存在するんですよね。しかもチェックされた状態は変わらず、余計事故が起きやすい状態で。

具体的には左下にひっそりと「オプションの表示」というテキストがあり、これがリンクテキストだという事すらなかなか気がつかず、これをクリックすると展開され、その中にチェックボックスがあるんですよね。

わざわざ、初期値がチェックされた状態で。これはトラップ？？と思うくらい。

さて、それではどうしたら少しでも事故やトラブルが防げるのか？ググると同じように初期値がチェックされた状態を危惧する声もあり、初期値ではチェックが外れているように設定で変更できないか？という問い合わせもあり、サイトコレクションの設定やサーバーの全体管理からは変更できず、サーバー内のとあるファイルをイジる解決方法があるのですが、Microsoftのサポート対象外になってしまうという点からも、ちょっと厳しいのではと思います。

あとは必殺「運用でカバー」ですよね。

まずは、利用者に招待状メールを周知させる方法。つまり、送信されてしまった後を考える事。そうすれば少なくともサーバー管理者への問い合わせは減るのかなと思いますが、若干ネガティブな対策です。

次に、アクセス権限を設定できるサイト管理者などへの教育・周知という方法。つまり、送信される前を考える事。ただし、サイト管理者が多いほど、ヒューマンエラーの確率が増えますね。ホント、ウッカリ失念してしまいがちなので。

次に、アクセス権限の設定はサーバー管理者が掌握する方法。つまり、権限管理自体を特定多数（不特定多数）に管理させない事。実際にアクセス権限の問題はかなり多岐に渡るトラブルや問題にもなるので、サイト管理者にアクセス権限の設定ができないアクセス許可レベルを付与している会社も、少なくはないと思います。これにより一極集中してしまったサーバー管理者の作業は大変になりますが、より把握している者が作業をすることにより、ヒューマンエラーの確率はサイト管理者にアクセス権限管理を委譲するよりは、減ると思います。

Microsoftのサポート対象外になってしまっても構わない場合は、設定レベルでチェックを初期値では外す方法が理想なのかもしれないです。（サーバーの全体管理やサイトコレクションの管理で容易に設定できれば良いのですけどね。）それ以外の場合は、各環境に合わせ、上述のようないわゆる運用でカバーをしていくしかないっぽいです。

ちなみに僕は今までおよそ何千何万回も設定をしてきましたが、一度もこれで事故やクレームはありませんでした。実際運営していると招待状メールが必要な事は全くありませんでした。例えばとある部署が自部署のサイトを公開する際には、だいたいサイト管理者か部署の部長さんあたりが自分から部内や周知したい人たちにメールをしたり、社内ポータルの掲示板に掲載したりする場合がほとんどでしたからね。

なので、とにかくチェックを外すクセを徹底的につけていました。