Art-Break .log : Taichi Nakamura

SharePoint ：サイトの開発・カスタマイズ用ファイルを「サイトのリソースファイル」ライブラリに保管するのは微妙かも

開発・カスタマイズに利用する画像・CSS・JSファイルなどの格納先を「サイトのリソースファイル」ライブラリに指定される事がよくあります。このライブラリはサイトを作成すると自動で作成されているのですが、「リソース」とは日本語で「資源・資産」なんて訳せると思うので、サイトのカスタマイズに利用する資源の格納先に選んでしまいがちでしょうか。

しかし、過去にも少し取り上げましたが、「サイトのリソースファイル」ライブラリのそもそもの利用方法があり、それを考えるとカスタマイズファイルの格納先には向いていないのでは？と思います。

SharePoint 複数行テキスト列で画像・ビデオ・ファイルを挿入する際の「宛先ライブラリ」の初期値変更

「サイトのリソースファイル」ライブラリとは、概ねページやアイテムに画像などを表示させる際のアップロード先と思って頂いて良いと思います。

SharePoint 2007 の頃はアイテムの複数行テキスト列に画像を表示したい場合は、先にどこかのライブラリに画像をアップロードし、URLを控えて、それを複数行テキスト列に指定して表示させていました。SharePoint 2010 からこの手間が楽になり、複数行テキスト列のリッチテキストエディタ内で、画像をアップロードしつつ表示させる事ができるようになりました。このアップロード先はサイト内のライブラリを指定できるのですが、その初期値で指定されているライブラリが「サイトのリソースファイル」です。同じくビデオを表示させる際のアップロード先もそうです。

▼複数行テキスト列でコンピューターから画像を挿入すると

▼宛先ライブラリの初期値が「サイトのリソースファイル」になっています。

▼新しい表示（モダンUI）のニュースページのヘッダー画像の追加も

▼アップロードする先は「サイトのリソースファイル」になっています。

※しかも、新しい表示（モダンUI）のニュースページでは、宛先ライブラリの指定はできず「サイトのリソースファイル」で固定のようです。

つまり、ここに開発・カスタマイズファイルを格納してしまうと、サイト運営開始してから上述のような方法で利用される画像・ビデオファイルと混在してしまいます。

「別に混在してもいいよ」って場合も、更に注意点としてアクセス権限があります。「サイトのリソースファイル」ライブラリはデフォルトでは親となるサイトの権限を継承しています。つまりサイトに投稿権限以上あれば、ライブラリ内のフォルダーやファイルは編集・削除も可能です。それがなぜ注意点かというと…サイトの開発・カスタマイズに利用しているファイルを、特定多数の人達が編集・削除できてしまうという事です。

もちろんアクセス権限はフォルダー単位でも独立させて設定できますが、そこまでしてもサイトの開発・カスタマイズに利用しているファイルを「サイトのリソースファイル」ライブラリに格納しなければいけない理由って逆にないと思います。

だとしたら、ゴチャゴチャしていなく権限も安全なライブラリに格納した方が良いのかなと思います。

専用のライブラリを作成する
マスターページギャラリーやスタイルライブラリに格納する
専用のサイト（コレクション）を作成する
別のサーバーに格納する

などなど。それぞれの環境に合わせたやり方は色々ありますね。

もちろん、その上で「サイトのリソースファイル」ライブラリを利用したい場合は、それもまた不正解ではなく正解なんだと思います。

SharePoint ：複数行テキスト列（拡張リッチテキスト）の「XHTML に変換」ってなんだろう？

拡張リッチテキストにした複数行テキスト列の編集画面には、リボンに様々な機能があります。Word などに似たUIではありますが、意味のわからない機能もあると思います。個人的には利用頻度ワースト3に入る機能なのであまり気にしていなかったのですが、「XHTML に変換」ってなんだろう？と思ったので調べてみました。

マウスホバー時に出てくるメッセージは

XHTML に変換
基礎となるページを HTML から XHTML 準拠に自動的に変更します。

と書いてあります。複数行テキスト列に入力する作業が多いのは SharePoint 開発者でもなくサイト管理者でもなく、通常の投稿者が大多数でしょうが「なんのこっちゃ？」となるでしょうね。HTMLという言葉くらいは知っていてもXHTMLは知らなかったり、仮に知っていてもHTMLとXHTMLの違いなんて世の中では知らない人が大多数かと思います。

現時点での SharePoint Online ではページのソースを見ると、DOCTYPE宣言には XHTML 1.0 Strict となっています。

なので、HTMLで記述されたソースであれば、 XHTML 準拠のソースに自動変更する便利機能なんだろうと思いますが、正直、投稿者からすれば自分が思ったように表示されていれば裏側のソースがどうのこうのは関係なく、やはり「XHTML に変換」機能自体はマニアックなのかなとは思います。そもそも SharePoint のソース自体が XHTML 1.0 Strict に準拠…！？という話でもありますが。

実際にHTMLで記述したソースが「XHTML に変換」でどうなるかを検証してみる前に、このリッチテキストで「ソースの編集」からソースを入力すると SharePoint 側が勝手に色々ソースを変えるので、その挙動から検証をしてみます。

検証する材料としてのソースですが、HTMLとXHTMLの違いとしては細かいのが色々あるのですが、大きく以下の点を考慮します。

HTMLでは大文字小文字どちらもOKだけど、XHTMLでは小文字のみ。
XHTMLでは終了タグは省略できない。
XHTMLは整形式で記述しなければいけない。
×例→text
○例→text
空要素の場合は/を入れる。

▼これらを全て盛り込んだ検証用HTML

<P>あいうえお
<HR>
<P><SPAN>かきくけこ</P></SPAN>

▼XHTMLに準拠した場合

<p>あいうえお</p>
<hr />
<p><span>かきくけこ</span></p>

▼では、検証用HTMLのソースを「ソースの編集」から貼り付けてみます。

▼表示のされ方はこのようになります。

この状態で「XHTML に変換」もせずに、もう一度「ソースの編集」を開きます。

▼やはり！（若干違うけど）この時点ですでにXHTMLに変換されてる。

つまり、ソースの編集でHTMLを記述すると、OKを押した時点でXHTMLに変換されるので、なおさら「XHTML に変換」の存在意義がわかりません。

結局、よくわからないので検索してみました。「SharePoint XHTML に変換」で検索しても日本語では有用な情報がなかったんです。仕方ないので英語サイトの情報を検索します。「XHTML に変換」は英語では「Convert to XHTML」です。しかしそれで検索しても情報がうまく見つけることができませんでした。つまり世界的にあまり利用もされていなく気にもされていない機能なのでしょうか。ただ、正解はわからないけど若干情報が出てきました。

それによると、「XHTML に変換」の用途は、例えばExcelからコピペしたあとに、そのソースをXHTMLに準拠したソースに変換しましょう！という事のようです。なるほど。実際にやってみます。

▼Excelの表部分をコピーします。

▼複数行テキスト列内にペーストすると見た目はしっかり再現されています。

▼ソースを見てみるとこんな感じで非常に汚いソースです。

ここで目立つのはfontタグがある事です。すっかり前段で検証し忘れていたけど、XHTMLの中でもStrictではfontタグは使用できません。つまりこのソースはXHTML 1.0 Strictには準拠していないという事になります。

では、この状態で「XHTML に変換」をしてみます。

▼fontタグが全てdivに変換されました！（汚いソースには変わりはありませんが…。）

その後、前段で検証し忘れていた「XHTML に変換」をしなくてもソースの編集でHTMLを入力したら SharePoint が勝手にソースを変えるという点ですが、fontタグはfontタグのままでした。

つまり、fontタグ以外のXHTML準拠の部分に関しては、「XHTML に変換」をせずとも変換してくれ、今のところ「XHTML に変換」はfontタグをdivタグに変換するだけの機能という感じ。

他にもあるのかもしれませんが、結局はHTMLをXHTMLにしますよという言葉以上の事はしないだろうし、「XHTML に変換」をしなくても、XHTMLの中にHTMLが入っていても、文法上は間違っていてもブラウザエラーになることもなく見た目は同じなので、投稿者目線では別にやらなくても良い行為で…やはりこの機能は利用頻度ワースト3不動かなと思います。

SharePoint ：スクリプトエディター Webパーツの空白の幅を詰めたい

スクリプトエディター Webパーツは閲覧モード時には非表示とする使い方も多いかと思います。例えばJavaScriptやCSSを直接記述したり、各種ファイルのリンクを埋め込んだり。

しかし、非表示のWebパーツでも縦幅はしっかり取られているので、デザイン・レイアウト的に邪魔な場合があるかと思います。（上の画像のように）

スクリプトエディター Webパーツを最下部に配置すれば解決しますが、中には最下部には置けない場合もあるのかなぁと思います。

■現象の確認

テキストのレイアウトを「2段組」にして左右にWebパーツを配置してみます。

▼当然ですが左右のWebパーツの高さは同じです。

▼左にスクリプトエディター Webパーツを配置します。

▼すると左のWebパーツはスクリプトエディター Webパーツの影響で落ちてしまいます。（段差がわかるように赤い線を引いています。）

これがスクリプトエディター Webパーツが空白でも縦幅をとるという事です。デザイン・レイアウトをあまり気にしないチームサイトなどは良いですが、社内ポータルサイトなどでは気になる場合もあるかと思います。

■解決策検討

単純にdisplay:none;でスクリプトエディター Webパーツを消してみます。

▼ソースでスクリプトエディター Webパーツの外枠に固有のclassを振ります。

【参考】
SharePoint のページにオリジナルのCSSを適用させる方法について

※ちなみにWebパーツのソース自体のdivのclassに固有のclassを追加せずに、わざわざ外枠にdivを追加しているのは、単に僕の好みです。

▼次に、以下のCSSを記述します。（適用のさせ方も上述の【参考】を）

.HideWebParts { display:none; }

▼無事解決。左右で高さが一緒になりました。（わかりやすいように赤い線を引いています。）

■しかし…

これで解決したかと思ったのですが、よく考えればわかることですが、このままだと編集モードにしてもスクリプトエディター Webパーツは表示されません。

隠してしまったスクリプトエディター Webパーツが一度設定したら二度と編集する事がない場合は問題ないですが、あまり管理面でもよくないのかなと思います。また、編集したくなったらCSSを解除すれば良いのですが、解除をしたらその間はユーザーがページを表示すると高さがおかしくなるので厳密には良くないです。

理想は閲覧モードの際にはスクリプトエディター Webパーツ分の高さは消え、編集モードの際にはスクリプトエディター Webパーツが表示されたら良いです。

■解決

これも解決できます。編集モードの際のソースを調べると、編集モード時に固有のclassがあります。

▼閲覧モード時の該当箇所

▼編集モード時の該当箇所

編集モード時の該当箇所のclassで、編集モード固有のクラスは、
.ms-rte-layoutszone-inner-editable
.ms-rtestate-write
の2つあり、editableとかwriteとか、いかにも編集っぽいワードで、どちらでも良いと思います。

▼これを利用します。（今回は.ms-rte-layoutszone-inner-editableを利用）

.HideWebParts { display:none; }
.ms-rte-layoutszone-inner-editable .HideWebParts { display:block; }

これで閲覧モード時ではスクリプトエディター Webパーツの縦幅が消えて左右のWebパーツの高さは一緒になり、編集モード時にはスクリプトエディター Webパーツは表示されます。

▼閲覧モード

▼編集モード

超小ネタ： Excel で複数セルの中身を一挙に削除できない！と思ったら…

【結論】

backspaceキーではなくdeleteキーで削除

困って検索してこのページにたどり着いた人がすぐ結論を得られるように、先に結論を書いておきました。

「複数セルの値を削除したいんだけど…」という問い合わせは、過去に社内ITなんでも屋をやっていた時代に結構ありました。

実際どういう事かというと…

▼複数セルを選択します。

▼backspaceキーを押すと、選択した際の基点（この例だと左上）のセルのみ削除されます。

じゃ、選択したセルの値を一挙に削除するには？というので結構困っているユーザーがいたということです。

▼deleteキーを押すと、選択したセル全て削除されました。

厳密にはbackspaceキーは「アクティブセル」なるセルだけを削除するようです。アクティブセルとは選択をしても背景色が反転しないセルのようです。

そもそもdeleteキーとbackspaceキーの違いってカーソルの後ろの文字を消すか前の文字を消すかの違い程度にしか思っておらず、僕自身もPC初心者の頃からややこしいなぁと思い、なんとなく指を置く位置から近いところにあるbackspaceキーばかりを使っていました。っていうか未だにdeleteキーでしかできない操作の時しかdeleteキーは使っていないかもしれないです。

これを知らずに一挙に削除できず、1セルごとにbackspaceキーで地道に削除されている方が過去に多くいたので、なんとなく記事にしてみました。

よくあるプレゼン時の失敗： Outlook などのデスクトップ通知

プレゼンや会議でPCをプロジェクターや大画面テレビに映す事があると思いますが、参加者全員が注目している最中に Outlook のデスクトップ通知が右下に表示され、しかもメールの内容がゴルフ用品店のメルマガだったり、キャバ嬢からの同伴の催促のメールだったり、上司の悪口メールだったり…。
Outlook だけじゃなく、 Skype で突然話しかけられる事もありますね。

マジメな PowerPoint の資料とこれらのデスクトップ通知の内容のギャップが、なかなか笑えてきますが、当の本人は冷や汗モノですよね。

大事なプレゼンや会議の前には慎重に準備をする時間をとり、これらデスクトップ通知のあるアプリはしっかり終了させた方が良いですね。結構ある話なので注意しましょう。何度も見かけたことがあります。

その前に、会社のメールでプライベートのメルマガ登録したり、キャバ嬢とやりとりしている時点でNGですが…。

また、そう考えるとメールや会話を送信する側も気をつけないといけない？。例えば上述の「上司の悪口メール」であれば、これは送信した人も被害を受ける可能性もありますね。なので、メールを送信する前にSkype のプレゼンスなどで送信先の人が会議中かをチェックしな…ん？そんなメールを送信するのって面倒なの？いやいや、そもそも上司の悪口をメールしちゃいけないって事ですよね（笑）受信先で大画面にデスクトップ通知が表示されても、業務に関するメールだったら問題ないので。

つまり、デスクトップ通知が晒される可能性という視点からも、メールは業務以外の用途での利用はやめましょう！という事ですかね。

とにかくどんどん便利になる世の中ですが、色々とお気をつけ下さい。

SharePoint：「注目リンク」リストは新しい表示（モダンUI）ではエラーになる

[2018/02/21]追記

現在は注目リンクリストもモダンUIに対応され、エラーになっていません。

SharePoint ：いつの間に注目リンクリストがモダンUIに対応していたので色々試してみる

新しい表示が出てきてから結構経つと思いますが、仕事でモダンUIを利用する事はほとんどなく、だいたいクラシック表示で開発をしています。なので新しい表示は自分のテナントで趣味で遊ぶくらいしか触っていなく、イマイチ慣れないのですが…。

SharePoint 「注目リンク」リストをCSSでイイカンジにカスタマイズ

先日CSSでカスタマイズを紹介した「注目リンク」リストですが、作られた時からクラシック表示になっているという事にふと気がついて、新しい表示だとどうなるのかな？と切り替えてみました。

▼最初はクラシック表示。何もカスタマイズもしていない注目リンクです。

▼新しい表示に変更！エラーになります！

タイルビューがダメなのかな？と思ってビューを切り替えました。

▼それでもエラーです。

つまり注目リンクは新しい表示には対応していないようですね。

新しい表示のページには Hero というWebパーツがあるので、そもそも注目リンクは不要になるということでしょうか。

注目リンクのようにページには表示させたいけど、管理はリストで行いたいというニーズもあると思うんですけどね。

ちなみに新しい表示のページにリストWebパーツを表示させられるようになりましたが、Webパーツの設定で選択するリストの一覧の中に注目リンクはなかったので、注目リンクはリストだけど新しい表示のページには表示できないようです。

なので、現時点では注目リンクリストはクラシック表示での利用となるようです。

現時点で新しい表示だけで運営をしようとしている企業っているのでしょうか。まだまだ慎重になっているのかなぁと思います。コミュニケーションサイトなんかも出てきて、モバイル対応重視なら新しい表示にするべきでしょうけど、なんとなく不安感ありますよね。今後に期待です。

Outlook のデスクトップ通知は「alt＋PrintScreen」でアクティブウィンドウのスクショを撮っても写りこんでしまう

タイトルが全てですが。

スクショを撮る作業をしていまして、アクティブウィンドウのみを撮るのに「alt＋PrintScreen」を使うのですが、撮ったスクショをフォトショ上に貼り付けていたら、1枚に Outlook のデスクトップ通知が写りこんでいました。そういえばスクショを撮っている最中にデスクトップ通知があったかも。

「alt＋PrintScreen」はアクティブウィンドウのみだと思っていましたが、デスクトップ通知は例外なようです。Outlook 以外のアプリのデスクトップ通知がどうなるかはわかりませんが、スクショを撮る際には気をつけましょう。

お客様に納品する資料作成で膨大なスクショを撮るなど、単純作業でだんだんボーっとしてくる最中にデスクトップ通知が写りこんでしまうかもしれないですね。色々見落として納品してしまったら印象悪いですもんねぇ。

Office 365 の使用状況の「 Office 365 の導入（プレビュー）」ってなんだろう（無事導入編）

Office 365 の使用状況の「 Office 365 の導入（プレビュー）」ってなんだろう（導入挫折編）

前回、とにかく導入までの道のりが長くて挫折したのですが、再チャレンジしてみてなんとか導入できました。

前回の操作のおさらい

使用状況からPower BIに移動
Power BI の左下の「データを取得」をクリック
「サービス」の「取得」をクリック

ここまでです。

▼で、取得できるサービスがたくさんあって挫折しました。

とりあえずその中から発行元をMicrosoftに絞って探してみると…

▼すると「Office 365 Adoption Preview」なるものが！

Analyze usage とか書かれているからこれかな？「Adoption」って単語は知らないから調べたら「採用・採択・養子縁組」など…う～ん、わけわからない。隣に同じくPreviewという文字のあるものもあるけど、なんか違いそう。ダメ元で「Office 365 Adoption Preview」を入手してみる。

▼Tenant Id？？

▼あ、使用状況画面の方に「次のテナント IDを使います」って文字列があった事を思い出す。

で、このテナント IDをコピろうとするけど、ボックス全体がクリック範囲だからコピーしづらい！で、その苦労のマウス操作の最中、隠された文が表示された！どうやらaltに文章が入っているようです。

▼隠された文が表示される

とりあえず無視してテナントIDをコピって、Tenant Idを入力しました。

▼次の画面。認証方法？OAuth2？なにそれ？？

あ…そういえば、さっきの隠された文に認証方法って書いてあった。

▼oAuth2でOKだそうな。

しっかし「重要：」なのに、このように隠して記載って…使わせる気あるのかな？

▼サインインしてしばらく待つとなんか完了しました。できたダッシュボードを表示します。

▼おぉ！おぉ…おぉ？…英語かい！！

そして、冒頭の通り、僕しか使っていないテナントなので、実際に表示されたデータは寂しい限り。

とりあえずプレビューとはいえ、表示までの敷居が高いと感じました。使ってもらう気なさそうな導入までのUI。ただ、難儀した部分はこの記事を見ればクリアされるので、導入までの敷居は低くなったハズ。

Office 365 を利活用されている企業がこれを見たら、楽しい分析と調査ができるのかな？このブログのアクセス解析にGoogleアナリティクスを見ても結構楽しいので、 Office 365 の使用状況って眺めるだけでも楽しいのでしょうか。

Office 365 の使用状況の「 Office 365 の導入（プレビュー）」ってなんだろう（導入挫折編）

Office 365 の Admin center のレポートの使用状況ですが、自分のテナントは僕しか利用しないのであまり見る事のない画面です。たまたま見たら右下に Power BI のアイコンとともに「Office 365 の導入（プレビュー）」というのがありました。すでに数ヶ月も前からあるようです。

▼Office 365 の導入（プレビュー）

スクショを撮る前に有効化をしてしまったため、有効化する前はこの表示ではないです。

とにかくここから有効化ができます。準備に時間がかかるようなので1日置いたのですが、その後の状態が上のスクショです。

勝手な想像として、ここで「 Power BI に移動」をクリックすると、Office 365 の使用状況が自動で Power BI で表示されると思っていましたが、ここのリンクは単に Power BI アプリへのリンクだったので、ここから更に設定をしなければいけなく、すでになんとなく面倒だなという印象です。（だって、そんな事しなくても使用状況画面でチェックできるし。）

さっきの部分をよく見ると Power BI に移動した後に、初めての場合は、コンテンツパックの接続を始めろ、との事。コンテンツパック？なんだろ？「コンテンツパックの使用方法」なんてリンクがあるけど、この先は小さいウィンドウが表示され、長い説明文が表示され、なんとも読む気が失せる感じで…。プレビューとはいえ、なかなか準備で諦めてしまいそうです。

とりあえず Power BI に移動してみました。久しぶりに触るのでよくわからず、5分ほど色々触った末に左下に「データを取得」というリンクがある事を発見。

▼「データを取得」をクリック。

▼おっ！「自分の所属組織」の中に「コンテンツパック」の文字を発見！

▼う～ん、この先が何もできない…

▼一度戻って…あっ！「サービス」にも「コンテンツパック」の文字があった！

▼多い！わけわからん！え～い！やめだ！やめ！（スクロールバーを見れば量の多さがわかります…）

という事で挫折しましたとさ。なんかスミマセン…。（その後、苦労の末、導入できたので、次回記事にします。今日はここまで。）

Microsoft Bookings をちょっと触ってみる（初回アクセス編）

読み方がイマイチわからないシリーズなので、「ブッキング」なのか「ブッキングズ」なのかわかりませんが…

Office 365 ：読み方がイマイチわからないサービス（現状わからないままです）

僕の個人のテナントは Office 365 Business Premium サブスクリプションなので、 Microsoft Bookings が利用できます。これは中小企業向けにお客様の予約を管理するサービスのようです。実際に僕が何か予約が必要なビジネスをしているわけではないので実用はしませんが、とりあえず興味本位で触ってみます。

▼アプリのタイルをクリックすると初期画面が表示されます。

美容院を連想させるイメージ画像です。

まずここで気になった点ですが、ナビゲーションバーにピン留めしていない　Skype for Business のアイコンが表示されています。（個人的な設定で SharePoint はピン留めしているます。）設定はしていないので他のアプリでは表示されていません。つまり Microsoft Bookings では設定関係なく Skype for Business のアイコンが表示されるようです。予約だからすぐ電話対応できるように？ですかね？とりえあず今はよくわからないままで次に行きます。

さて、次に「今すぐ入手する」をクリックします。入手？アプリでもダウンロードされるのかな？

▼翻訳が微妙だったのかな？何かダウンロードされるわけでもなく、普通にセットアップが始まります。