Art-Break .log : Taichi Nakamura
Microsoft 365 ( Office 365 ) ・ Power Platform ・その他の情報発信ブログ
「その他の色」から戻せる
例えばExcelでセルに色を塗った後に、元の透明に戻したい場合、「塗りつぶしなし」を選択すれば元の透明に戻せますよね。（白を選択しても見た目では元に戻るけど、厳密には上述の方法が元に戻す方法）
Formsでパネルなどのコントロールに色を塗る際に、「背景塗りつぶし色」で色を選択します。（「背景塗りつぶし色」ってネーミングがもうね…）
問題は塗った後に元の透明に戻したい場合。
Excelなどのような「塗りつぶしなし」的な解除ボタンはどこにもありません。操作の直後に戻すなら「元に戻す」ボタンで戻すことは可能ですが、他に色々な操作をした後に戻したい場合には、使えませんよね。
不可能かと思いましたが、分かりづらいところで透明に戻す方法があったので紹介します。
同じく「背景塗りつぶし色」で、一番下の「その他の色…」を選択します。
背景色ダイアログの「新しい色：」の下あたりにRGBの数値があって、そこを空欄にしてOKを押します。
透明に戻りました。
ちょっとわかりづらいですよね。数分悩んだので紹介してみました。
ちょっと細工をすれば撮れます。
たま～にですが、ページのスクリーンショットを撮りたい時があります。（今の会社に入社してから頻度が増えました。）
SharePoint に限らずスクショを撮るには「PrtScn」キーを押せば良いのですが、それだとブラウザで開いたまましか撮る事ができません。（アクティブなウィンドウだけをスクショするなら「Alt」を押しながら「PrtScn」ですよね。）
縦長ページのページ全体のスクショを作るには、ペイントなどで切った貼ったを繰り返し…なんて面倒な作業も考えられますが、ダルいので便利なブラウザのアドオンやソフトを使いますよね。
アドオンを入れてまずは手始めにYahoo!トップページを撮るとこんな感じで縦長ページでもページ全体のスクリーンショットが撮れます。
この勢いでSharePoint のページでページ全体スクショを撮ったら…
ん？？？開いた領域しか撮れてない！！Yahoo!のトップページなどは普通に撮れたのでアドオンのせいではありませんでした。
これはSharePoint の作りの問題で、SharePoint のページはスクロールさせてもスイートバーやリボンは固定され、コンテンツエリアのみスクロールしますよね。ここが影響しているっぽいんです。
アドオン次第で成功したりしなかったりしたので、僕が成功した条件で紹介します。
おしまい。↓これで撮れたスクリーンショットです。ちゃんとページ全体が撮れています。
環境をFireFoxに限定したのは理由があり、IE11にスクショ用アドオンを追加して同じ方法で試したらバグっぽい感じでうまく撮れませんでした。ブラウザやアドインなど、環境によって成功しない場合もあり、ただそれを色々と検証するのが個人的にダルいので、成功した環境で紹介しました。IEじゃなきゃダメだという場合は、IEのアドオンを色々試してみてください。IEでも作業工程は上述の方法とほぼ同じです。
企業でSharePoint （に限らず）を導入すると、少なからずIT部門に使い方や操作トラブルの問い合わせが入ると思います。利活用促進の一歩だと思えば問い合わせが入る事は喜ばしいこととは思いますが、多くの企業ではサポート業務専任スタッフはおろか、SharePoint 専任スタッフもおらず、だいたい他業務と兼任していることが多く、これらのサポート業務に忙殺され、他業務に影響が出ててしまう事もあります。
IT部門がサポート業務を担う、いや、渋々担わされている企業にありがちなのが、以下の状況。
つまり、悪い言い方をすれば「行き当たりばったり」。問い合わせが電話で、それを保存していない場合、実は過去に何度も同じ内容で問い合わせが来ているのに、受けたIT部門のメンバーが違う事で、各自毎回調査をして回答をするという、かなり非効率な状況になっていたりするんですよね。
以前にも書いたとは思いますが、IT部門はサーバー管理など運用面には関心があっても、運営面では無関心な事が意外と多いんです。また、ありがちなのがIT部門自体がSharePoint をあまり活用していないケースもあります。IT部門が主導で各種グループウェアなどを比較検討した結果選んだ製品を導入し、技術面でも詳しいのであれば、その段階では一番積極的に有効活用できる部門だと思うんです。でもそのIT部門が相変わらずメールやファイルサーバーを使っていて、導入したSharePoint を利活用していない。これじゃ社内展開がうまくいかないですよね。
そこでIT部門が積極的にSharePoint を利活用しつつ、社内サポート業務の効率化を図る、一石二鳥な方法があるんですよね。それが社内向けにSharePoint に関する情報発信をすることです。
別に目新しいことではないんです。これだけでも十分なんです。
先にブログなどでTipsなどを発信する事で利用者のSharePoint スキルの底上げを図れます（読まれているかどうかは置いといてですよ）。
ユーザーからの問い合わせをIT部門内で共有する事で、チームメンバーのスキル底上げにもつながるし、同類の問い合わせに関しての調査・回答工程を省けます。
FAQとして公開する事により、ブログと同じくユーザーが自発的に問い合わせる前に自己解決できる可能性が出てきます。また、既出で解決済みの問い合わせを新規で受けたとして、該当するブログ記事やFAQを参照してもらうだけで済むので対応の時間効率化にもなります。これが1年2年…とコツコツ増える事によりナレッジは蓄積されます。
これもありがちですが、中小企業でIT部門のメンバーも少なく、SharePoint 担当者が一人で対応していた場合、この方が急に退職されたりして残されたIT部門のメンバーが途方に暮れる…みたいな。属人化させないためにも、日々ナレッジは蓄積し、できる限り共有されている仕組みは大事ですよね。
私は実際に運営で問い合わせを受けるサポート業務も兼任していたのですが、まぁ問い合わせ内容もピンキリで、時にはマイクロソフト社に助けを求める事もありますが、多くの場合は簡単な説明で解決できる内容でした。
このように実際にSharePoint を有効活用している事例を自然と見せる事により、少なからず社内全体の利活用促進に貢献できるのではと考えます。
一石二鳥どころかそれ以上だとは思いませんか？
このような提案を上長や組織内にする際に、自ら情報発信をするのに抵抗を感じる人がいたり、そもそも業務を増やしたくないと思われたり、抵抗勢力があるので厳しかったりもしますが、大事な事だと思うんですよね。もう一度言いますが、別に画期的な方法でもなく、誰でも思いつく事。だけどそれを実現できていない企業も少なくはないはず。
これまた、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 に詳しい人には常識的な操作であっても、利活用の主役である閲覧・投稿者にとっては直感的に操作をするには厳しい部分もあります。
運営に長年携わっていて多かったユーザーに知られにくい機能の一例
これを教えるだけでもSharePoint の印象が大きく変わるであろう機能も、意外と教えないと存在すら気がつかないまま何年もSharePoint を利用しているユーザーは少なくはありません。
ただ、これらSharePoint の機能紹介的な教育よりも大事であると思う事があります。
情報共有とは情報発信だけでは意味がなく、発信された情報が受信され活用されて意味を成します。つまり、発信した情報が読まれなければ意味がありません。言い換えると、投稿者は可読性を意識する事がポイントかと思います。
サーバー管理者やサイト管理者がいくらUIを気にしてデザインのカスタマイズをしたところでそれはあくまでも枠の部分。そこより大事なのは枠の中身です。その中身を作るのは投稿者。その教育が必要だとは思いませんか？
軽く例を挙げると…
などなど。実際アイテムの中身を見ると、受験生のようにテキストをカラフルにして、白背景に黄色文字を使ってチカチカしたり、リンク色と同じ色をつけているテキストがあって、クリックできるのかと思ったらクリックできなかったりイラっとするものもあったりします。思ってもいないような使い方をするんですよね。これはSharePoint に限らずプレゼン資料など人に見せる資料を作成する人全員に必要な教育でもあるんですけどね。
また、Webのマナーなども重要です。
例を挙げると…
こういう部分も閉ざされた空間だからといって自由であるわけではなく、社内のモラル・マナー向上においても教育は大事だと思います。
ちなみにこの記事を読んでこれらを常識だと思われている人は、すでに自身のスキルや知識に悪い意味で侵されています。非IT企業はもちろん、IT企業であっても必ずしも全従業員がITリテラシーやモラルが高いとは断定できません（従業員を信じたいですけどね。）。
また、なんでも「○○は禁止」といったネガティブな教育をすると利活用促進とは間逆の結果になりがちです。「○○はこうした方が良いですよ」的なポジティブな教育が必要ですね。利用したい・便利だと思わせる事が重要なので。
「教育」というと大きな話に聞こえてきますが、それこそSharePoint のブログ機能やSNS機能を利用して発信しても良いかなと思います。ディスカッション掲示板を利用してユーザー間で解決させる仕組みを作るのもアリかと思います。
サイトコレクションおよびサイトを管理者に渡して「はい、ご自由に」というやり方で運営をしていて、利活用されなくて困っている企業のIT管理者がいらしたら、運営・教育の重要性を少しでも感じていただければと思います。
「名前付きコントロール」：フォーム上でリアルタイムに反映される。
「アイテムのプロパティ」：保存して列に値が落ちた後に反映される。
※今後はなるべく結論を先に書く構成で記事を書きたいと思います。
条件を記述する時などに表示される「数式パレット」ダイアログ内のタブには、「ランタイム関数」「共通」「アイテムのプロパティ」「名前付きコントロール」があります。
その中の「アイテムのプロパティ」「名前付きコントロール」について。
「アイテムのプロパティ」は実際の列名が表示されています。
「名前付きコントロール」は「名前」欄に入力してあるコントロール名が表示されます。
ただし、名前欄を埋めていれば全てのコントロールが表示されるわけではなく、ラベルに名前を入力してもここには表示されません。しっかり検証したわけではないのですが（無責任！）、SharePoint側に列として存在するコントロールであり、名前が入力されているコントロールが条件のようです。
ここで疑問点。
列名が選べる「アイテムのプロパティ」と、列として存在し名前を入力したコントロールが選べる「名前付きコントロール」。結局、同じモノじゃないですか。
でも大きな相違点が2点ほどありました。
両者は同じモノのようで厳密には違います。
「アイテムのプロパティ」は列の値を参照します。つまり、一度保存をしてSharePoint的に列に値が落ちないと反映されません。
「名前付きコントロール」はコントロールの値を参照します。つまり、保存をしなくてもForms上に入力もしくは選択された値がリアルタイムに反映されます。
このリアルタイム性の違いで使い分けるようですね。検証してみます。
select列の値を選択するとパネルが表示される仕組みを作りました。もちろん「名前付きコントロール」と「アイテムのプロパティ」両方。
selectでAを選択すると、「名前付きコントロール – A」パネルのみ表示されます。リアルタイムに反映されるからです。値に落ちないと反映されないアイテムのプロパティの方は、この時点では表示されません。
この状態で保存をし、アイテムを開いてみます。そうすると、「アイテムのプロパティ – A」も表示されました。値が落ちないと反映されないからです。
どちらも数式パレットで選択して張り付けると、数式欄には赤字で下線が引かれた状態で表示されます。
▼名前付きコントロールの「Select」を選択
▼アイテムのプロパティの「select」を選択
単なるテキストではないので手入力はできず、かならず上の列名・コントロール名をダブルクリックして式に挿入します。この式はコピーをして別のルールなどにペーストしても、赤字下線でペーストされ、しっかり列名・コントロール名として認識されます。ここまでは問題ありません。
しかし、例えばこの式をテキストエディタなどにペーストして加工した場合、更にテキストエディタからコピーして数式パレットにペーストすると、赤字下線ではなく単なるテキストとしてペーストされるだけで、列名・コントロール名を指定した事にならず、式としては無効です。
つまり式はテキストエディタなどを経由するとコピペができないんです。これ地味に厄介です。（できる方法があったら教えてください！）
ただ、「アイテムのプロパティ」を選択して作った式は、数式パレット上では同じく赤字下線ですが、その後ルールを再度見るとなんか変わっています。
{ItemProperty:select}
selectという列なので列名と内部名がイコールになっているので例としては良くなかったのですが、「テスト」という列名だと「{ItemProperty:_x30c6__x30b9__x30c8_}」となるので、やはり「{ItemProperty:列の内部名}」です。
さて、この{}で表示された「アイテムのプロパティ」は赤字下線ではないです。なので手入力もできるしテキストエディタ経由でコピペもできるんです。
以前「Nintex FormsでDropbox？？」という記事を書いて、Forms内のある場所で「Dropbox 削除」という表記があり、Dropboxと連携するのかと思ったらそういうわけでもなく、英語版の表記は「Delete」だったので日本語訳した際になんでDropboxが紛れ込んだのか意味不明と書きました。
同様の事が他にもあったので紹介します。
Formsでコントロールを必須項目にしたく、ルールの種類で「検証」を選択すると…
「Yammer メッセージ」？？
Yammerはマイクロソフトの製品なので、Dropboxよりも連携しそうな雰囲気を醸し出しています。ただ、検証とYammerはどう連携するんだろう？Yammerに投稿される？う～む…
結論はやはり別にここでは連携しないようです。
英語版を見てみると…
「Message」
でた！Yammerなんて記載はないじゃない。またまた日本語訳した際に紛れ込んだようですね。しっかしDropboxといいYammerといい不思議ですね。
という事で、はじめてこれを見た時に混乱しますが、これは条件が合わなかった際（必須項目を設定したなら未記入だった場合）、コンテンツエリア上部に赤文字で出すテキスト文です。
こちらも、もしYammerに意味があるなどご存知の方はご一報いただければと思います。
SharePointの標準ではできないFormsの様々な機能の中のよく使われそうな機能が、表示・非表示のルールかと思います。別の選択肢でAを選択するとAパネルが表示され、Bを選択するとAパネルは消えてBパネルが表示されるみたいな。非常に便利な機能ですが、クセがあります。
サンプルとしてこのようなフォームを作りました。
上部操作エリア内にある選択肢でそれぞれのパネルの表示・非表示を制御します。
このように、Formsで配置した上からABCの順番は崩れずに、表示・非表示で自在に制御できるようにしたい。
えっ？？ABじゃなくてBA？？？つまり、Forms上で正しく上からABCとパネルを並べても、表示させるラジオボタンをクリックするパターン次第で、配置順がABCにならなくなる。
これは例えば業務フロー順にパネルを表示・非表示させるとして、その順番が入れ替わってしまったら困りますよね。これ、半日ほど試行錯誤して原因と解決方法がわかりました。
といっても明確に原因がわかったわけではなく、想定外な挙動をするパターンが判明しただけです…。
隙間なくキレイにパネルを配置した際に起きる現象でした（なんてこった）。
パネルを1マスずつ空けて配置しなおします。
先ほどの想定外な挙動と同じ動作をしますと…
BAではなく、ちゃんとABになりました。他にも色々なパターンで表示・非表示を繰り返しましたが、上からABCが崩れることはありませんでした。
表示・非表示の際にはパネルが重なってしまっても思った挙動になりませんが、まさかキレイに配置してもこのような挙動になるとは思いませんでした。
通常はパネルとパネル、コントロールとコントロールをキレイに配置しても問題ありませんが、もしこのような挙動になる、もしくはしようとしている場合は、1マス空けて配置すると良いです。
コントロールを作っているとたまにコントロール内にスクロールが発生する事があるかと思います。この状態でコントロールを移動させたい時に気をつけたい点があります。
スクロール部分をドラッグしてしまうと、ドロップしてもコントロールは離れません。接着剤でくっついてしまったかのごとく離れません。これ結構焦ります。
何度左クリックしても離れません（たまに離れる事もありますが…）。
右クリックをすると離れますが、掴んだコントロールや入れ子にしているパネルが瞬間移動で意図しない場所に動いたりします。
また、くっついてしまった状態で、画面外でクリックすると、コントロールが消えてしまいます。しかも高確率で元に戻すボタンを押しても戻ってきません。
つまり、コントロールの瞬間移動か失踪事件です。このようにNintex Formsは結構動作が不安定だったりします。複雑に作れば作るほど、ドキドキします。
【対策】