SharePoint

SharePoint ：新しい表示（モダンUI）の「タイトル」列（「名前」列）の省略部分は列幅を広げると表示されました！

前回の記事で、モダンUIのタイトル列（名前列）の省略されたテキストは、ビュー内で列幅を広げても省略されたままである。と記載しました。

SharePoint ：新しい表示（モダンUI）の「タイトル」列（「名前」列）が長い場合の挙動

しかし、この記事間違いでした。
さっき発見したんです。

その前に前回のおさらい。

▼長いタイトルは296px以上の部分は後ろに「…」が表示され省略されます。

▼モダンUIだとマウスホバーした際にカーソルがこのように変わったところでクリックしたまま左右に動かすと列幅が可変します。

▼しかしタイトル列の列幅を広げても省略されたテキストは現れません。

そして、前回の記事のあとに発見したこと。

▼タイトル列の列幅調整はさっきの場所ではなく、少し左側にあったんです。

▼幅を広げると省略されていたテキストが現れました。

なんだよ～～～～～～。

という事で、前回の記事でウソを書いてしまったのですが、どういう事かというと…

▼両方の位置を並べるとこんな感じです。

じゃ、この右の方のトラップのような位置はなんなんでしょうか。

▼重ね合わせると、なんと！「…」メニュー用の列幅調整位置だったんです。

いやいやいや…列単位で可変できる機能ですけど、そこを列扱いしますかねぇ。百歩譲っても「…」を広げる意味なんて全くないですよねぇ。マウスホバーしないと「…」が表示されなくなったので余計気がつきませんでした。

という事で、タイトル列や名前列のように「…」メニューが付く列に関しては、少し左の位置で列幅を可変しましょう。

SharePoint ：新しい表示（モダンUI）の「タイトル」列（「名前」列）が長い場合の挙動

※この記事は一部ウソを書いています。以下の記事をご覧下さい。

SharePoint ：新しい表示（モダンUI）の「タイトル」列（「名前」列）の省略部分は列幅を広げると表示されました！

リストの場合は「タイトル」列、ライブラリの場合は「名前」列。ここが文字数が多くて長い場合、クラシック表示だと、ブラウザの解釈都合で改行されたり、場合によっては改行されず横スクロールが発生します。

では、レスポンシブ対応されている新しい表示（モダンUI）はどうでしょう。

▼他の列の有無は関係なく、コンパクトになっています。

▼拡大して見ると三点リーダー（…）で省略されています。

▼CSS的にはこんな感じ。

widthはインラインで296pxが指定されていて、僕が操作した限りだとブラウザの幅を可変しても296pxが追従して可変する事はありませんでした。また、classにはtext-overflow: ellipsis;が。これで296px以上の部分は三点リーダーで省略される感じです。

クラシックUIに比べてコンパクトになったモダンUIですが、省略されることは必ずしもメリットだけではなく、デメリットもあります。

タイトルは長くても省略しないで全部表示されて欲しい場合もあります。
▼この場合は、マウスホバーをすると省略されずに表示されます。

ただ、マウスホバーせずに全アイテムのタイトルを省略させないで表示させたい場合もあります。

色々イジってるとクラシックUIにはできなかった機能で、ユーザー側で列幅を調整する事ができるんですよね。

▼このように列名のところをマウスで探ると、列と列の境界あたりに縦線が表示されカーソルが変わります。

この状態でクリックしながら左右にカーソルを動かすと、列幅を変更できるんです。なら、これを右側に移動すればどんどん省略されたテキストが現れるハズ！

▼残念…

列幅を広げることはできても、三点リーダーは追従せず、ただただ余白が広がるだけです。これは残念。

タイトル列の列幅は逆に縮める事もできないので、width=”296px”で固定なのでしょうか。

ただ、色々イジっているうちにおかしな（というか正常な）挙動になる場合を発見しました。

▼ビューの設定で3種類あるタイトル列を全て表示する設定にします。

▼するとなぜか三点リーダー（…）が表示されません。

この状態で列幅を広げてみると…

▼広げると追従してタイトル列の隠れていたテキストが表示されます。この挙動を求めていたんですよね。普段は省略されるけど、ユーザーが列幅を広げるとその分隠れていたテキストが表示される動作。

▼ただし、不思議な事に一つの列幅を広げると、3種のタイトル列が全て連動して一緒に広がりました。

よくわからないけど同じ「タイトル」列と認識するのでしょうか。っていうか、列幅を広げると省略が徐々に表示されたいがために、3種のタイトル列を全て表示させるのも微妙ですよね。

ちなみに追加した2種のタイトルのどちらか片方を表示して、元々のタイトル列とあわせて、2種だけ表示してもダメでした。つまり3種類のタイトル列全て表示させないと思った挙動が出ないという感じ。

という事で、現状では、モダンUIのタイトル列（名前列）の省略されたテキストは、ビュー内ではマウスホバーしないと表示されないようです。今後に期待ですかね。

※現状でも何か方法があるぞ！という場合は、御一報ください。

▼例えば、途中までファイル名が同じ2つのファイルがあるとします。

テキストテキストテキストテキストテキストテキストテキストテキストテキスト_株式会社AAA様向け.xlsx
テキストテキストテキストテキストテキストテキストテキストテキストテキスト_株式会社BBB様向け.xlsx

▼モダンUIで省略されると、全く同じファイルに見えてしまいます。

テキストテキストテキストテキストテキストテキストテキストテキストテ…
テキストテキストテキストテキストテキストテキストテキストテキストテ…

マウスホバーをすれば違いはわかるけど、いちいちホバーさせないとわからないので一覧性に欠けます。現状は仕方ないので、モダンUIを利用する場合は、ユニークな文字列を先頭に配置するようなファイル名の命名規則にした方が良さそうですね。

株式会社AAA様向け＿テキストテキストテキストテキストテキストテキストテキストテキストテキスト.xlsx
株式会社BBB様向け＿テキストテキストテキストテキストテキストテキストテキストテキストテキスト.xlsx

SharePoint ：リッチテキストエディタの「段落の方向」って何？「左・右揃え」との違いは？

リッチテキストエディタには「段落」というセクションがあります。

▼「箇条書き」「段落番号」などはよく利用するのではと思います。

▼「インデント」「インデント解除」に関しても場合によっては利用すると思います。

▼「右揃え」「中央揃え」「左揃え」「両端揃え」も利用頻度は高いかもしれないです。

▼ところで「段落の方向 – 左から右」「段落の方向 – 右から左」は使った事ありますか？

初期状態では「左揃え」と「段落の方向 – 左から右」が選択されている状態になっています。また、「右揃え」も「段落の方向 – 右から左」も、クリックした結果だけを見れば、右に寄せられる事は同じです。では、この「揃え」系と「方向」系の違いはなんでしょうか？

実際にクリックした後のソースを元に考えてみます。

▼「左揃え」

テキスト

※初期状態では選択されている状態ですが、ブラウザの初期状態が左揃えなのでソースにはタグは含まれていません。一度右揃えにした後に再度左揃えになると、上述のようなソースになります。

▼「右揃え」

テキスト

▼「段落の方向 – 左から右」

テキスト

※「左揃え」と同じく、初期状態ではタグはない。

▼「段落の方向 – 右から左」

テキスト

※ここを選択すると「右揃え」も自動で選択される。

「揃え」系は「text-align」を使用し左右に揃えるのでわかりやすいです。
問題は「方向」系です。こちらも「text-align」を使用していますが、大事な部分は「dir=””」の部分です。これはあまりメジャーではないタグかと思いますが、書字方向を指定するタグです。そもそも「書字（しょじ）方向」って何よ？って感じですが、文字を書き進める方向という意味で、縦書き・横書きも該当するそうですが、dir=””を使用する場合は横書きにおいて左から右か右から左を指定します。”ltr”は「left to right」で、”rtl”は「right to left」のようです。

つまり、「段落の方向 – 右から左」の場合は、見た目は右揃えと同じですが、dir=”rtl”があるので中身は全く違う事になります。この指定をすると、読み順としては「トスキテ」と読む事になるのかな。

右から左へ記述するのは例えばアラビア語などなので、そういう言語で文章を書く場合に指定するボタンでしょうね。ワールドワイドな製品なので。

多くの場合はあまり関係のない事かと思いますので、やはり右揃えにしたい場合は、視覚的には同じだとしても、「右揃え」を使い、「段落の方向 – 右から左」は利用しないようにしましょう。

ちなみにCSSカスタマイズで「方向」系ボタンを非表示にしたい場合は、idのRibbon.EditingTools.CPEditTab.Paragraph-Large-0-0-2がオリジナルのidっぽいので消せそうですが、そこまでする必要もないだろうし、検証はしません（笑）

以上、なんか気になるボタンだったので調べてみました。

SharePoint ：新しい表示（モダンUI）の「＋新規」から見る「アプリ」という言葉の定義？

過去にも記事にとりあげましたが、 Office 365 内の「アプリ」という言葉の定義がフワっとしていて、様々な意味に当てはまって意思疎通時にたまにズレが発生する場合があります。

Office 365 内の「アプリ」という言葉の定義がフワッとしている…

今回の記事で言う「アプリ」は SharePoint の世界の中の話に限定しますが、その中でも複数の意味でアプリという言葉が利用されています。

SharePoint 2013 から「アプリ」という言葉が目立ち、現在もクラシック表示のサイトコンテンツページを見ると「アプリの追加」という文言の通り、それまで「リスト・ライブラリ」と呼んでいた集合体を「アプリ」と呼ぶ感じです。

「アプリの追加」をクリックした先のページを見ても、これらを総称して「アプリ」と呼ぶものだと思う作りです。

しかし、新しい表示（モダンUI）のサイトコンテンツページは、なんかちょっと違う感じがします。

「＋新規」をクリックした際のメニューを見ると、「リスト」「ページ」「ドキュメントライブラリ」と同じ並びに「アプリ」が。

ここで「リスト」を選ぶとカスタムリストが作成されます。ここで「ドキュメントライブラリ」を選ぶとドキュメントライブラリが作成されます。

今まではカスタムリストもドキュメントライブラリも「アプリ」という総称の中の一つに過ぎない理解だったが、ここの印象では、カスタムリストとドキュメントライブラリはアプリと並列という事は、アプリという総称の中に内包されていないと思ってしまいます。

ただここで「アプリ」を選ぶと、さっきのクラシック表示の「アプリの追加」をクリックした先のページが表示されます。（ここはまだクラシック表示のまま）

なんだ、つまりモダンUIの「＋新規」からのメニューは、単にアプリからよく利用されるカスタムリストとドキュメントライブラリを作成するリンクをショートカットリンクのようにアプリと並列で表示させてるに過ぎないのか。（まぁ、そう考えると「ページ」「サブサイト」が並列なのも違和感でしたね。）

という事で、結局は今でも「リスト・ライブラリ」を総称して「アプリ」と呼ぶ感じで良さそうですね。

おそらく「そんな深く考えてないよ。別にどうでもイイじゃ～ん！」と言われそうだけど、言葉の定義をしっかりする事はコミュニケーションにおいては大事だと思います。過去でも言葉の定義のズレが起因する齟齬からトラブルに発展するケースも経験してきました。（ちなみに「アプリ」も色々誤解されるので、コミュニケーションの場では未だに「リスト・ライブラリ」と呼びます。）

SharePoint も言葉の定義がフワっとしている部分がある上に、バージョンアップするとシレっと変わっていたりする事もあるので、気にしなければ良いという選択肢もありますが、気にしたいと思っています。

SharePoint ：リッチテキストエディタのフォントサイズは直接入力できます

複数行テキスト列などリッチテキストエディタではフォントサイズを変更できますが、選択肢になっていて、ドロップダウンの中は「9pt、11pt、13pt、18pt、24pt、36pt、48pt、72pt」から選択可能です。

これだけ見るとここから選択するしかないように思えますが、実は直接サイズを入力する事が可能な事を知らない方は経験則では結構多いです。

▼選択肢の部分に直接入力すると好きなフォントサイズに変更できます。

▼ptだけでなくpxやemなどもOKです。

▼必要性やモラルは置いといて、閲覧した人がビックリするくらいのサイズにも…。

同じくフォントファミリーの指定も直接入力できますが、ここはほとんどニーズはないのかなと思います。

選択肢のザックリとしたフォントサイズに納得いかない方は、このように直接入力でフォントサイズを指定してみましょう。

SharePoint ：Webパーツの編集したくてもWebパーツメニューを表示できない

クラシックページに関してですが、ページの編集を頻繁にしている人は変な挙動に気がついているかもしれません。通常、Webパーツの編集をしたい場合は、以下の方法で編集すると思います。

■Webパーツメニューが表示できる例

▼ページを編集モードにします。

▼編集したいWebパーツにマウスホバーすると右上に表示される「▼」をクリック。

▼このようにWebパーツのメニューが展開されます。

ただ、このメニューがどうしても出せない時があるんです。具体的には、スクロールが発生するくらい縦長のWebパーツです。

■Webパーツメニューが表示できない例

▼この「社内行事」というWebパーツの「▼」をクリック。

▼その瞬間、勝手にスクロールされてメニューが展開できない。

これではWebパーツの編集ができません。

■対策

この現象が起きた場合は、ここではなくリボンの操作で代替可能です。

▼編集モードで、該当Webパーツの右上の▼ではなく、その右のチェックボックスをクリック。

▼該当Webパーツがチェックされます。

▼この状態で、リボンタブで「WEB パーツ」をクリックし、「Web パーツのプロパティ」をクリック。

これで代替可能です。また、「削除」などの操作もこの中にあるので代替可能ですね。

個人的にはページ内のWebパーツの操作は、SharePoint 2007 の方が操作しやすかったように思います。また、モダンページの操作性は今のところ良さそうな感じです。 SharePoint 2007 からずっとクラシックページで四苦八苦してきたので、モダンページに置き換わる時が来たら一抹の寂しさもありますが、とりあえずレスポンシブに最低限対応できるし、色々便利になりそうなモダンページに期待です。

Microsoft Teams の添付ファイルのクセのある仕様

これまでいくつかのビジネスチャットを使ってみましたが、ビジネスチャット内でファイルのやりとりをしていくと、やはりメールのように同ファイル名のファイルが貯まります。

▼例えば Slack の場合（スレッド内のスクショ）

このように「sample.xlsx」が2個並びます。

▼例えば社内SNSですが Yammer の場合（ファイル一覧画面のスクショ）

同じく「sample.xlsx」が2個並びます。

では Microsoft Teams はどうでしょう。
Microsoft Teams でチームを作成すると自動で Office 365 グループが作成され、という事はこれまた自動で SharePoint のサイトが作成され、Microsoft Teams でファイルを添付すると、その SharePoint のサイトのライブラリにアップロードされます。では、SharePoint のライブラリなら、同じファイル名のファイルは複数アップロードできないハズ。

試してみます。

▼ Microsoft Teams に「sample.xlsx」というファイルをアップロード。

▼チャネルのファイル一覧画面を見ると、ここは Yammer とあまり変わらず。

さて、この状態で同じ「sample.xlsx」を添付してみます。

▼おっ、やはり同じファイル名でのアップロードはダメでした。

「キャンセル」をクリックすればキャンセルされ、「置換」をクリックすれば上書きアップロードされます。ここらへんは SharePoint のライブラリの挙動と変わりありません。

※▼ちなみに Microsoft Teams 用のライブラリのバージョン設定はメジャーVerで500Verを保存する設定なので、間違えて「置換」しても復元できるので安心です。

では、「両方を保持」をクリックするとどうなるのか？（ SharePoint では別名で保存でファイル名を手動で変更してアップロードすると思います。）

▼「sample (1).xlsx」としてアップロードされました。

自動で連番が振られる挙動は通常のライブラリの挙動とは違く、 SharePoint のリストの添付ファイルに似ていますね。また、「(1)」の前には半角スペースも入るようです。

▼ファイル一覧画面でもこのように同じファイル名にはならずにアップロードされています。

▼もちろんですが SharePoint で開いても同じです。

ちなみに、 Microsoft Teams と SharePoint のサイトの関係は、1チームに1サイトなので、別チャネルで同じファイル名をアップロードした場合はどうなるでしょうか？

▼あれ？同じファイル名のファイルでも普通にアップロードできました。

▼ファイル一覧画面を見ると、こんな感じ。

「一般」チャネルでは「General」というタイトルだったけど、ここでは「テスト001」というチャネル名のタイトルが表示されています。この時点では Teams でチャネルを作ると SharePoint ではライブラリが作成されるのかと思ったけど、 SharePoint 側で確認したら…

▼サイトのライブラリでは、チャネルごとにフォルダーが作成されるんですね。

まとめると…

他のビジネスチャットみたいに同じファイル名でファイルを添付する事はできない。
「両方を保持」をクリックすると拡張子の前に「 (1)」のように自動で連番が振られる。
ただし、チャネルごとにフォルダーを作成するため、別チャネルでは同じファイル名でもアップロード可能。

と、自動で連番が振られる機能は違うけど、大体は SharePoint のライブラリの仕様に準じる感じがわかりました。

同じチャネル内で、すでにアップロード済みのファイルと同じファイル名でアップロードできないのは SharePoint を利用している Microsoft Teams のクセかと思いますが、利用ユーザーにとってはそんな仕組みは知ったことではありません。このクセがメリットに感じることもあるし、デメリットに感じる事もあると思うので、大事なのは、このような仕様も理解した上でツールの選定材料の一つにすると良いかもしれないですね。

SharePoint ：透明人間Webパーツをページ上に復元する方法

ページ内に追加はされ生きてはいるけど表示上では存在しないWebパーツを、勝手に「透明人間Webパーツ」と呼んでいます。

これまで2回ほど類似内容で記事にしました。

SharePoint ：ページにWebパーツを追加すると1つしか表示していないのにWebパーツのタイトルに[1]が表示される

SharePoint ：ページの表示速度が遅い場合に簡単にできる一度疑ってみるとイイ事（透明人間が悪さをしている場合が！）

ところで、この透明人間Webパーツをページ上に復元させたい場合、イマイチ操作方法がわかりづらかったので紹介します。

まず、前回の記事で検証した透明人間Webパーツがいるページを開きます。

▼表示上は空のページです。

▼URLの後ろに「?contents=1」を入れて「Webパーツページの管理」を開きます。

このように空のページだけど4つの透明人間Webパーツが存在します。（ページで開くは4つとも「はい」になっています。）では、これらを復元しページ上に表示させたい場合はどうしたら良いでしょうか。

▼復元したいWebパーツをチェックした後に「閉じる」をクリックします。

▼すると「ページで開く」が「いいえ」になります。

▼ページに戻って編集モードにし、「挿入」タブで「Webパーツ」をクリック。

▼カテゴリの最下部に「閉じられたパーツ」カテゴリがあります。

※この「閉じられたパーツ」カテゴリはWebパーツを閉じると出現するカテゴリです。

ここから該当Webパーツを追加すれば復元完了です。

【1】透明人間Webパーツを管理画面から閉じる
【2】閉じたWebパーツを追加

という2工程が必要になりますが、復元が可能です。

【今更気がついた事】SharePoint の「Web パーツページの管理」は隠しページじゃなかった…

ページのURLの末尾に「?contents=1」を追加すると、「Web パーツページの管理」という管理ページがあるというのは、これまで2回ほど記事で書きましたが、SharePoint を使って約8年、どこからもリンクのない隠しページだと思っていました。

SharePoint ：ページの表示速度が遅い場合に簡単にできる一度疑ってみるとイイ事（透明人間が悪さをしている場合が！）

SharePoint ：ページにWebパーツを追加すると1つしか表示していないのにWebパーツのタイトルに[1]が表示される

しかし、ちゃんとリンクがあった事に SharePoint 触って8年目で気がつきました（笑）

▼ページを編集モードにし、「ページ」タブの「プロパティの編集」をクリック。

▼この「Web パーツページを管理ビューで開く」をクリック。

▼なんと！

う～む、なかなか地味なページに地味にリンクがあったんですね。でも「?contents=1」で8年間やってきましたからね。イチイチ編集モードにしなきゃいけないなら「?contents=1」の方が楽です。

その前に、このクラシックページの寿命もあと何年なんでしょうかね。ここらへんの知識もそのうちゴミになってくるんですかね。ちょっと悲しいですね。

SharePoint ：ページの表示速度が遅い場合に簡単にできる一度疑ってみるとイイ事（透明人間が悪さをしている場合が！）

SharePoint に限らずページの表示速度が遅い事はユーザーの利活用促進を阻みます。オッサンになって更に記憶力が悪くなったので正確な情報ではありませんが、たしか通常のWebサイトではページの表示が2秒だか3秒以上かかると、ユーザーの離脱率がグンと上がるようです。なので、パフォーマンスについての対策は検討すべきかと思います。

パフォーマンスについては様々な原因があるのですが、ここではページを編集できる権限レベルでも調査できる、ページの表示速度が遅い原因を紹介します。

▼対象のページを表示します。（デモでは極端にWebパーツをゼロにしました）