2020年6月
サイトの利用状況と UserAgent
SharePoint のサイトの利用状況のページには「一般的なプラットフォーム」の利用状況の概況が確認できるようになっていますが、ここで気になったのが UserAgent。
ちなみに、サイトの利用状況に関しては、以前、記事にしました。
「[SharePoint Online] サイトの利用状況について」
さて、この「一般的なプラットフォーム」では分析結果から、利用端末が次の5つに分類されるわけです。
- デスクトップ
- モバイルWeb
- モバイル アプリ
- タブレット
- その他のデバイス
この判定は UserAgent を使っているそうですが、具体的にどう判定しているかはドキュメントもなく判然としないところがあります。これから、Microsoft Teams って Webページをタブで追加しているけど、あれはUserAgent はどうなるんだ? といった疑問も。
ということで、判定がどうなっているかは別にして UserAgent がどうなっているかを興味本位で確認したので、せっかくなのでここに記録しておきます。ちなみに、私の利用しているPC環境は Windows 10 であり Edgeは Chromium ベース( 83.0.478.50) です。それと、Google ページで UserAgent は確認できるようになっていたりもしますが、せっかくなので SharePoint 上にWebパーツを作って確認しました。
Edge
Chrome
IE11
私の環境だと、InfoPath.3 が見えているのが面白いですね。InfoPath 、入れてはいるけど、もうずいぶん使っていないなぁ。
Microsoft Teams のデスクトップアプリ
Teams って表示されるのですね。
iPad にインストールしている SharePoint モバイル
SharePoint for iOS。
iPad の Safari
Macintosh となるのか。
Android の SharePoint モバイル
SharePoint for Android。
Android 上の Chrome
特筆すべきところはあまりないかな。
結果
これらをもとに解析しているんだなぁと考えながら、サイトの利用状況を確認するのも面白いですね。
※個人的に気になったところを赤字にしていますが、特に意味はありません。
ブラウザ等 | UserAgent の取得結果の例 (私の環境の場合) |
Edge | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36 Edg/83.0.478.50 |
Chrome | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36 |
IE11 | Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; InfoPath.3; Tablet PC 2.0; rv:11.0) like Gecko |
Firefox | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 |
Teams desktop app | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.13565 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36 |
Safari (iPad) | Mozilla/5.0 (Macintosh: Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15 |
SharePoint App mobile (iPad) | Mozilla/5.0 (iPad; CPU OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) SharePoint for iOS |
SharePoint App mobile (Android) | Mozilla/5.0 (Linux; Android 9; SHV44 Build/S8024; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/83.0.4103.106 Mobile Safari/537.36 SharePoint for Android |
Chrome- Android | Mozilla/5.0 (Linux; Android 9; SHV44) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Mobile Safari/537.36 |
[復刻版] SharePoint ライブラリ内のフォルダーにプロパティを持たせる
もう12年前にもなりますが、過去の以下の記事を書いていました。
フォルダに任意のプロパティを持たせるには (Office SharePoint Server 2007)
この記事に対して、たまたま昨日、コメント欄にご質問頂きました。フォルダーにプロパティを設定してグループ化したいが、記事を見ても設定方法がよく分からないとのことでした。読み返すと、確かにあまり細かい手順まで書いていませんでした。。。たぶん、仕事の合間に書いていたので、力尽きたのでしょう (今も、それは同じですが)。細かいところは研修を受けに来てね! という思惑もあったような気もします。
閑話休題。
頂いたコメントからは 使っているのが SharePoint Online かどうかはわかりませんが、そもそもモダンなライブラリでもちゃんと動いていたかしら? という疑問もあり、SharePoint Online 上のモダンサイトで再現実験をしました。しっかりと動いてはくれているので、撮影したビデオをここでも共有しておきます。
ビデオに音声はありません。ひたすら操作しているだけですので、あらかじめご了承ください。
ちなみにフォルダーにプロパティを持たせることは、状況によっては必ずしも正解ではない可能性もあります。場合によってはドキュメント セットを使うほうが望ましいケースもあるかもしれません。その点も考慮して、こんな方法もあるのか、と参考にしていただけるといいと思っています。
コンテンツ タイプについて知見を深めておこう
実は、最近は「コンテンツ タイプ」について、研修でも説明する機会がぐっと減ってきています。それでも「ひと目でわかる SharePoint Server 2016」などでは、このあたりの高度なドキュメント管理に関してもしっかり説明はしています。しているのですが、直接、話す機会が数年前と比べると極端に少なくなっています。
コンテンツ タイプの概念は、メタデータ管理をする上ではやはり知っておくべき内容ではあるのですが、設定がややこしいので心理的なハードルが高い。この点が一番のネックです。そしてきちんと設計しないと却って使いにくいという面もあります。もちろん SharePoint Designer などでワークフローを組む場合は、この辺を駆使することもありましたが、対応できるのひとは案外限られています。
それに、そもそも「メタデータ」とは? という説明をユーザーの方々にしていかなくてはいけない。安易にフォルダー構造に依存したファイル管理は極力しないように、いつも研修やコンサルティング時にも熱弁しているところでもあります。そうすると、理解者のすそ野を広げるべく、まずは簡単な設定方法をご紹介することでメタデータの利用を広めることが先決です。
と、「設計、設定の小難しさ」から説明を端折り気味ではあった、今日この頃ですが、そうもいっていられません。今後 SharePoint 上にあるコンテンツを AI によって仕分けてナレッジ マネージメントを半オートメーション化しようという「Project Cortex」も登場してきます。こうした仕掛けを利用するには、少し高度なメタデータ管理である「コンテンツ タイプ」や管理メタデータを理解し利用することは避けて通れません。メタデータは検索にも使いますしね。今年も後半の注目は「検索」です! (たぶん)
そんな背景もあり、今回きっかけを頂き作成した「フォルダーへのプロパティ設定」の復刻版は、コンテンツタイプも利用するため、設定手順などを知る上でも、意外とよい題材だなとも思い掲載することにしたわけです。
Microsoft Teams の Wiki の使いどころとその実体は?
Microsoft Teams のチームにはチャンネルごとに Wiki を追加して利用できるようになっています。5月のイベント時もそうでしたが、この Wiki の使いどころに悩んでいる方も少なくないようです。そんな質問をいくつかいただきました。
そこでこの記事では Wikiの使いどころや実体について少し掘り下げてみようと思います。
Wiki の使いどころを考察する
Wiki は「必ずこうして使いましょう」という決まりはありません。ただ、特徴を捉えることができれば、うまく活用できるだろうと思っています。
Teams 内では会話重要な要素の一つです。すなわちリアルタイムコミュニケーションが重視される "会話" では、最後に書かれたメッセージが優先的に表示されます。それは、新しいメッセージだったり、既存のメッセージへの返信だったり。会話だと、表示場所が頻繁に入れ替わるのです。これの利点としては最新の活動状況などが比較的に把握できるわけです。
ですが、最新のやり取りに左右されずに情報をまとめてどこかに固定しておいておきたいという場面も多い。
そんな時に利用できる仕組みの一つが Wiki です。
たとえば、前回ご紹介した Microsoft 365 Virtual Marathon でも Teams を使って関係者との連絡を行っていたのですが、イベントの概要や告知に使うハッシュタグ、イベントのコンセプトなど運営側に伝えたい情報は Wiki 上にまとめていました。これはうまい使い方の一つですね。場所が[Wiki]というタブに固定されているので、検索などしなくてもすぐに探せる。ちなみに類似した使い方として SharePoint ページを[タブ]として追加しておくというのもあります。SharePoint ページは情報をまとめるのは得意とするところで、手軽に見栄えよくページに情報をまとめられます。その点、Wikiは豊富な Webパーツが用意されているわけではないので比較すると表現力は限定的ですが、軽量化されていて手軽に書き込めるというのが何よりも魅力です。
余談ですが、SharePoint も Wiki の機能を持っていて研修や書籍でもたびたび「Wiki」の説明をしてきました。Teams の Wikiとは機能的には異なりますが、コンセプトは類似しています。肝心なのは、そもそも "Wiki" って何? という話です。この言葉の意味をご存知ない方も多いと思いますし、そんなところに注目していなかったという方もいらっしゃるでしょう。 Wikiシステムの代表でもある Wikipedia で調べてみるとわかりますが、言葉の由来はハワイ語で「速い」を意味する wikiwiki (ウィキウィキ) から来ており Webブラウザー上から素早く共同編集できるというのが特徴です。つまりは「専用ツールがなくても、手っ取り早く文書を書いておける」ところが魅力だと言えます。
それでもTeams が登場したばかりのころは、文字を箇条書きするくらいのもので、現在は当初と比べれば格段に表現力は上がっています。しかし、つまるところ、SharePointページの表現力を求めているわけではなく、手軽さ重視という点を考えると現状のシンプルな機能のままで温存されるのではないかとも思います。
とはいえ、Wiki にも難点もあります。次の点を考慮して運用する必要がありますね。
- 新規作成しても、更新しても目立たないので気づいてもらえない
- 書いた内容をチャットで引用するなどしない限り、Wiki単独では検索でヒットしない
Wiki の実体はどこに?
Wiki の実体はどこにあるのか? 気になる方もいらっしゃるでしょう。とはいえ、この辺は管理者の方が知っていればいいことだとは思うので、あくまでご参考まで。
少々、Deep Dive します。
実体は SharePoint で管理されています。あぁ、それなら知っているという方もいるかもしれませんが、それを Team Wiki Data 内のデータだと思っていませんか? 実態はリストであり、これは実は直接は使われていません。調べてみると、結構、奥が深いのです。
その裏付けとして、私の実験結果を共有しておきましょう。ちなみに、調査には SharePoint Designer 2013 をところどころで使っています。
まずは SharePoint サイト側にある Teams Wiki Data という名前のドキュメント ライブラリを確認しましょう。
この中には チーム内のチャネルごとにフォルダーが生成されます。とはいっても、チャネル上で Wikiが一度も使われたことがなければフォルダーは生成されません。またプライベート チャネルを作っている場合も対応するWikiフォルダーは作られません。
実験のために一般チャネルの Wiki に次のようなコンテンツを追加しました。
では、このチャンネルに対応する General フォルダーを開いてみましょう。次のように画像と mht ファイルが作成されています。
mht ファイルをダウンロードして中を開いてみます。すると次のようなHTMLが書かれていることが分かります。通常は、ここまでで Wiki の実体はこれだと思うはずです。
このファイルの中の html タグの属性である "data-list"を覚えておきましょう。19:1c4da~で始まっているIDが指定されています。
さて、このリストですが、SharePoint Designer 2013 からアクセスしてみます。実はこのIDを持つリストが内部的に作成されていることが分かります。このリストは既定ではサイトコンテンツページには表示されないように設定されているので、通常は気づきません。
ではこのリストのプロパティを変更して、サイトコンテンツ ページに表示できるように設定してみましょう。「ブラウザーに表示しない」チェックボックスをオフにして、保存します(余談ですが、このように隠しリストを表示できるように設定変更すると、検索結果にも Wki の内容が表示されるようになります。ただし、SharePoint 上からの検索時の話)。
では Webブラウザーに切り替えて、サイトコンテンツ ページをのぞいてみましょう。すると「19:1c4da~」で始まるリストが表示されるようになったことが分かります。
早速リスト内を確認してみましょう。Wiki, Page, Section の3つのアイテムが作成されています。ちなみに、ページを新規に追加すると Page と Section が追加されていくという挙動になっています。
試しに Page アイテムをクリックしてみると次のような内容が確認できます。Wiki のタイトル、作成者、タイムスタンプが書き込まれています。ちなみに、作成元は Skype Teams となっていますね。
今度は Section アイテムをクリックしてみましょう。本文が書かれています。
ではこの Section アイテムを編集してみましょう (といっても、あくまでも検証目的で自己責任で行っています。Microsoft の動作保証はされないと思いますので、決して運用環境で試してはいけませんし、おすすめもしません)。
wikiContent の本文を編集し、保存すると、すぐに Teams 内のチャネルに反映します。しかし、先ほど説明した mhtファイルはそのまま更新されることはありません。
もちろん、Teams 側から Wikiを編集するとmhtも更新されます。Wikiからページを削除すると、mht も削除されます。しかし、実は先ほどの隠しリスト内のアイテムは自動的に削除されることはないようです。過去の Wiki コンテンツが残っています。Teams 上から Wikiを編集するとリストが更新されると同時に mhtも更新されるが、削除はされない。フラグが立つだけ。そのフラグが、 wikiDeleted 列です。
つまり、過去のコンテンツはリストに残りますが、wikiDeleted 列が "はい" となるので Teams 内からは利用できないようになるということ。
では、この "wikiDeleted" を"いいえ" 変えたら、Wikiコンテンツは復活するのか? 実験です。これも自己責任でやっているので、皆さんは試さないでくださいね。
さて、以上確認してきたように、Web 版、デスクトップ版、モバイル版とすべてで検証してみましたが、mhtは実際には使われておらず、リストが利用されているようです。
結局 mht はWiki内のデータを手軽にダウンロードできるようにしているのかもしれまないというのが、勝手な推測です。
とまぁ、興味本位でいろいろと調べてみたことをついでに書いてみました。
何かの参考になれば幸いです(トラブルシューティングなどには役立つかも?)。
無償セミナー「合わせ技で 3 倍便利に使いこなす! Microsoft Teams & SharePoint」ご参加ありがとうございました
2020年5月29日に AvePoint 社と合同で開催したウェビナー「合わせ技で 3 倍便利に使いこなす! Microsoft Teams & SharePoint」へ非常に多くの方にご参加いただきました。視聴いただいた皆様、本当にありがとうございました。
上司や同僚の方からの口コミでのご参加も非常に多かったようで、多くの方々のおかげで広く周知できたことは、本当にありがたいことです。
さて、実は、このウェビナーは偶然にもMicrosoft 365 Virtual Marathon の日本語トラックの翌日開催となり、実施側としてはなかなかタフな日程ではありました。とはいえ逆に Microsoft 365 Virtual Marathon とセットで聞いてくださる方がいれば、50分×2 となるため、すこし長めのストーリーで一連のお話ができるなぁと想像はしておりました。ある程度、うまく連携できたのではないかと思います。
まだ、ご視聴されていない方はオンデマンド配信をAvePointさんのサイトからお申込みいただけるので、是非ご利用ください。
【ウェブセミナー・オンデマンド配信のお申し込みはこちらから】
またセミナー中にいただいたご質問の一部に対する Q&A は下記のアブポイントジャパン ブログで確認いただけます。
【合わせ技で 3 倍便利に使いこなす! Microsoft Teams & SharePoint Q&A】
Behind the scenes ...
今回、合同セミナーを実施することになったきっかけは中村太一さんからのお声がけでした。太一さんも Microsoft MVPであるため、Office 365 に関していろいろと話をする機会はこれまでもあったのですが、一緒に仕事をするという機会はなかった。そこに、今回は太一さんからのお声がけだったわけです。個人的には「面白そう! 」とすぐに意気投合し、素早く日程を決めてと段取りをしてきました。
もちろん、事前の打ち合わせもするわけですが、互いにオンライン同士でのリモートでの合同開催ということで、どのようにやろうかという話もでる。けれど、せっかく、リアルタイムにしかも合同でやるのであれば、是非「ライブ感」を重視したい! と私の方から申し出てみたのです。有難いことに太一さんもすぐに賛同していただき、スライドは少な目、デモを多め(というか中心)にしようということで方向性は固まりました。また最初から掛け合いの台本もほぼ作らずに挑むことに。
結果、セミナー中は、うまく掛け合いをする場面をお見せできたのではないでしょうか。
今回、アンケートを拝見していると、「デモが分かりやすかった」というご意見をたくさんいただきました! 見事に作戦がうまくいったようです。そして何より「楽しかった! 」というコメントを非常に多くいただきました。こうしたツールの導入には"楽しさ" をエッセンスに製品に対するファンを作っていくことも実は非常に重要です。そのため、こうしたフィートバックを頂けたことは、これは本当にうれしかったです。演者として太一さんとのやり取りを本当に楽しめたので、単にうちわ受けというわけではなく、きちんと視聴者の方に伝わったのだろうと受け止めています。
関係者の方々への謝辞
太一さん! また是非、セミナー等、ご一緒させてくださいね。蓑田さん、いろいろと細やかなフォローをありがとうございました!!
最後に
さて、このセミナーをきっかけに弊社の研修にご参加いただければとも思いますし、デモでもご紹介した住所変更届の仕組みをどう作るのか、知りたい方は弊社までお問合せください!
明日の研修用のデモが完成✨#SharePoint + #PowerApps + #MicrosoftFlow + #Word
— Ai Hirano | Microsoft MVP (@ai_yamasaki) October 17, 2019
住所変更届を PowerApps で入力させて、Flow を使って Word ファイルの自動生成。日本では印刷文化がまだまだ根強いケースも多く。そのためのシナリオ例。 pic.twitter.com/l05SvoJRYw