Nintex Workflow でワークフロー全体のスクリーンショットを撮るコツ

SharePoint では構造上、縦スクロールが発生するページ全体のスクリーンショット(以下、スクショ)を撮る事がアドオンやツールを用いても不可能で、以前、色々試行錯誤した記事を書きました。

SharePoint で縦長ページのページ全体スクリーンショットが撮れない!→解決!

今回は更にマニアックですが、Nintex Workflow でワークフローが横長の場合の全体のスクショを撮る際に若干面倒だったので、自分への備忘録を兼ねて記事にします。

まず、前提として SharePoint でページ全体のスクショを撮るには、自分の調査不足(する気がない!?)でもあるのですが、IE ではアドオンで試してもうまく全体が撮れず、今回も Firefox を使用し、アドオンは「 Firebug 」と「 Pearl Crescent Page Saver 」を使用します。

困った事に、Nintex Workflow では、Firefox だと完全動作せず、編集画面ではアクションを追加したりアクションを設定・アクションセットを展開するなどのメニューがクリックしても動作しないので、全てのアクションを展開できません。ただし、編集画面の前の表示画面では展開させるメニューが動作するので、なんとかスクショが撮れそうです。

サンプルで作成したワークフローなので非常にシンプルですが、冒頭で紹介した記事のように Firebug で #s4-workspace のスタイルをイジって、Pearl Crescent Page Saver でページ全体のスクショを撮ります。

スイッチで分岐が20個あるように作っています。一見問題なくページ全体のスクショが撮れたように思えますが、よく見るとダメなんです。ワークフローの中心の本線は本当ならワークフロー全体のド真ん中を貫かなければいけないのですが、これだと分岐の左から4番目あたりでかなり左に寄っています。構造上、ページの中心ではなく、ブラウザの横幅に対して中心になっているんです。

↑正しくはこのように中心の本線はド真ん中なんです。

このように横幅が広い(分岐が多い)場合、表示画面では正しいスクショは撮れません。これは Firefox だけじゃなくて IE でも chrome でもそうですが、分岐が多い場合は、表示画面ではレイアウトが崩れてしまうんです。(編集画面ではこの現象は起きません。)

さて、どうしたものか?これも Firebug 内で CSS をイジれば修正できます。

▼Firebugを起動し、まずは一番横幅の広い箇所を選択。Firebugのレイアウトタブで横幅を確認(ここでは3120px)

▼Firebugの検索ボックスから「BlueCenterLine」で検索

▼.BlueCenterLineに「width:3120px;」を追加

これでスクショを撮ると中心線がド真ん中に来ます。

部分部分のスクショを撮って結合してしまえば良いですが、ワークフローの規模が大きいほど、結合作業も気が遠くなるかと思うので、この方法を使った方がマシだったりします。もっと良い方法があるのかもしれないけど、とりあえずこの方法であればそこまで無駄な工数かからないです。

Nintex Workflowのスクショを撮らなければいけない事なんてなかなかないとは思いますが、提出を求められる事もあるかと思います。というか自分にその必要があったので備忘録でした。

SharePoint お知らせリストの有効期限列をビューのフィルターで活用する際の落とし穴

以前、お知らせリストの有効期限列について以下の記事を書きました。

SharePointの「お知らせ」リストの「有効期限」列の利用および非表示方法

この記事で、利用方法の一例として、ビューのフィルターを活用して有効期限切れのアイテムをビュー上に表示させない方法も紹介しました。この方法は参考書などにも紹介されている方法なのでメジャーな使い方かと思います。ただし、この活用方法には落とし穴があり、実際にSharePoint運営に携わっていた頃にもトラブルがありました。以下、架空の設定ですが実際起きうるトラブルとして紹介いたします。

【トラブル】

閲覧ユーザーが、お知らせリストに掲載されていた情報を元にお客様用に資料を作成し提出したが、その情報が古かったらしく怒られてしまった。その掲載物の投稿者に問い合わせてみたところ、古い情報は有効期限が切れており、新しい情報は別途掲載して表示した、とのこと。

【原因】

ビューのフィルターをかけるだけでは有効期限切れのアイテムはビュー上から非表示になるだけで、実際に削除されたわけではありません。すべてのアイテムを表示させるビューがなかったとしても、検索すれば検索結果に表示されてしまいます。このトラブルも検索結果から古いアイテムを表示した事が原因でした。

お知らせリストの利用用途として検索対象外にする事はあまり好ましくありません。この方法を継続していれば同じトラブルは起きる可能性は高いです。このようなリスクを考慮して有効期限にどの機能を加えて活用するかを検討しないといけないです。

【解決方法】

あくまでも参考としてください。
まずトラブルを避けるには有効期限切れのアイテムは表示されないように配慮する必要があります。やはり情報管理ポリシーの保持を利用し、有効期限が切れたらアイテムを削除するのも一つの手です。ただし、この方法はこのトラブルが解決できても別のトラブルが出る場合があります。これも運営に携わっていた頃によくあった問い合わせなのですが、「過去に投稿したアイテムを再利用したいけど有効期限が切れたらしく見当たらないので復活してほしい。」という問い合わせ。運営側からすると「いやいやあなた…自分で設定した有効期限が切れたならあきらめなさいよ…」と思うでしょうが、実際この手の問い合わせは結構多かったんです。で、ごみ箱から復元できる場合は復元してあげるのですが、ごみ箱からも削除されていたらもうあきらめてもらうわけです。この場合は、運営上そういうものだとユーザーに啓蒙していくしかありませんが、別の方法としては、有効期限が切れたら別のリストに移動するように設定し、移動先のリストのアクセス権限をサイト管理者以外閲覧できないように設定すれば、検索でも古い情報がひっかからず、復元の依頼があっても対応できるのかなと思います。また、SharePoint Designerなどのワークフローを利用して、有効期限の直前に投稿者にメールで通知してから有効期限で移動や削除なんて事も可能かと思います。
そこまでしてフロー情報をストックしておく必要があるかどうかは別として。

そうなんです。そもそも運営の仕方(サイト作成の仕方)がユーザーのニーズと乖離しているところも検討するところです。色々な角度から検討する必要がありますが、例えば、そこで発信する情報の種類が最低限フロー情報なのかストック情報なのかを考えて、サイト作成をしていく必要があります。
極端に言えば、例えば規程集のようなストック情報に有効期限を付ける必要はありませんよね。例えば鮮度が命の情報のようなフロー情報を半永久的に保存しておく必要はありませんよね。これらフロー情報とストック情報は性質が全く異なるので、それを同じ管理方法で運営している事自体を再検討しないといけない、などです。
運営部門の会議などで「有効期限列を活用する方法があります。」と言って説明をすると、すぐに「じゃ、全てに実装しよう!」なんて考えも出てきます。気をつけたいところですね。

SharePoint 投稿者向け:カラフルにすれば良いってもんじゃない

SharePointに限らずですが、社内の情報共有の場で情報発信をする立場の人は、自分が発信した情報が受信者に読まれ、理解され、活用されているかは気になるところですよね。その中から今回「読みやすさ」について考えたいと思います。まずは今まで自分が投稿してきた投稿物を思い出してみてください。以下のような事をしていませんですか?

  • ページスクロールを抑えたいために文字サイズを小さくした。
  • 文章内に太字・斜体・下線などの装飾をふんだんにしていた。
  • 文字色をカラフルにした。

これらは一例ですが、心当たりがある場合は、以下を読んで何かしら気付きになっていただければ幸いです。(一概に悪い例という事ではありません。)

人に読んでもらえる記事を書くヒントはネット上にたくさんあります。大手ニュースサイトを「読みやすさ」という観点で読み漁ってみてください。概ねこういう傾向がある事に気がつくと思います。

  • 文字サイズは実は大きめ。
  • 行間や段落間が結構広い。
  • テキストエリアの横幅はそんなに広くない。
  • 文字に装飾(太字、斜体、下線、など)がない。
  • 文字色はほぼ1色。
  • 背景色と文字色のコントラストがとれている。(だいたい白背景に黒字)
  • 文章中のテキストリンクはリンクだと視認できる。または文章中にはテキストリンクを配置せず、文章下にリンクがある。

今までご自身が投稿してきたアイテムの内容と比べてみてどうでしょうか?結構、間逆な事をしているのではと思います。

以下は、この記事の文章に超テキトーに色々装飾を施してみたアイテムのスクリーンショットです。

黄色や薄い水色などの文字は読みづらいですね。緑のマーカーに赤字の部分はチカチカしますよね。重要な箇所に色々な装飾を施したとしても、結局重要箇所が多すぎて読む際に散漫になってしまいます。これは、以前テレビ番組でやっていたのですが、東大生が受験勉強をしていた頃の勉強方法の中で、「ノートの板書はカラフルにしない」「参考書にマーカーは引かない」などがありましたが、その理由と似ているのではと思います。また、Webの世界では未だに「下線の青文字はリンク」という印象があるので、リンクでないテキストに青文字で下線を装飾にすると、閲覧者がクリックしようとしてしまい「リンクじゃないんかい!」と心の中で突っ込みを入れつつストレスフルな文章になってしまいます。また、逆にこんなにカラフルにしていると、中にテキストリンクをつけても、ほとんどの閲覧者はそのリンクの存在に気がつきません。実はこの中で一箇所テキストリンクがあるんですが、視認できますでしょうか?SharePointのテキストリンクは、リンク色はサイトのテーマによって変わりますし、マウスホバー時に下線が現れますが、文章を読んでいるときに全文をマウスのカーソルを当てながら読む閲覧者はあまりいません。つまりテキストリンクが視認できない場合、リンク先のコンテンツはほとんど閲覧されない事になってしまいます。リッチテキストエディタ内に他コンテンツにリンクをつける場合は、リンクと視認できるかどうかを特に意識した方が良いです。

と、ツラツラと書いてみましたがいかがでしょうか?ちなみに過去の経験上、結構こういうコンテンツはありました。

大手ニュースサイトに共通している特徴はそれなりに根拠があっての特徴なので、自分なりに昇華してみて、ぜひ今後作成するコンテンツに試みてはいかがでしょうか。また、SharePoint運営者やサイト管理者の立場の場合は、読まれるコンテンツ作りの重要性とそのコツなどを投稿者向けに教育をしてみる事を検討してみてはいかがでしょうか。

SharePoint 「お知らせ」リストの「有効期限」列の利用および非表示方法

SharePoint2007で運営に携わっていた頃はリストと言えばお知らせリストを使っていました。(カスタムリストはほとんど利用していませんでした。)リストを通達・連絡用として利用するケースが多く、パッと作成してすぐ使うにはお知らせリストが最適で、またSharePoint2007の頃は、リストで設定したメールアドレスにメールを送信すると、そのままリストに投稿される受信メール機能があり、これはお知らせリスト固有の機能で重宝していたからです。

ただし、お知らせリストには一点邪魔な存在がありました。それが「有効期限」列です。

こんな列があれば、普通は有効期限列に日付を入れたら、その日が過ぎるとアイテムは削除されると思いますよね。それが何も起きないんですよね。ただ日付の列があるだけで、有効期限列単体では何の機能もないんです。SharePointを運営していると、「有効期限が動作しません」という問い合わせを多く受けました。説明をすると「え?あるのに何も機能しない?なにそれ…」的な腑に落ちない感じに返されてしまいますが、腑に落ちないのもごもっともだと思います。

▼有効期限列を利用する場合の一例ですが、有効期限列を利用して情報管理ポリシーの保持を設定したり、

▼有効期限列を利用してビューのフィルターを利用するなど、

有効期限列+他の機能の組み合わせで利用できます。

※ちなみにビューのフィルターを利用する方法に関しては落とし穴がありますが、話しが長くなってしまうので、それは別の機会にトラブル事例として紹介できればと思います。

一例として有効期限列を活用する方法を紹介しましたが、お知らせリストを運営する際に有効期限なんて不要な場合もあり、ではこの思わせぶりなこの列を削除してしまいたいですよね。でも…この列、削除できないんですよね。これ本当に厄介です。

▼よく見ると「OK」「キャンセル」はあっても、他の列設定のように「削除」ボタンがないんです。

 

ただ、ちょっと設定をする事で、削除ではないのですが非表示にする事は可能です。普段あまり使わないコンテンツタイプを利用します。

▼お知らせリストの詳細設定でコンテンツタイプの管理を「はい」

お知らせリストの設定の全般設定の下にコンテンツ タイプというセクションが表示されるので、「お知らせ」コンテンツ タイプをクリック。リスト コンテンツ タイプの設定の列セクションの「有効期限」をクリック。

▼列設定で「非表示」を選択。

▼これでお知らせリストで有効期限列を非表示にできます。

最初からカスタムリストを使って通達・連絡用リストを作成すれば良いのですが、ワケあって有効期限は不要だがお知らせリストを使いたかったり、すでにお知らせリストで運営されていて有効期限列が邪魔だなぁと考えていた場合などは、この方法を検討してみてはいかがでしょうか。

SharePoint ページ右上の歯車メニューが権限レベルに応じて表示・非表示をCSSで実現する方法

SharePoint2007からよくあるサイト管理者からの要望に、「『サイト コンテンツ』を閲覧者や投稿者に見られたくない。」があります。

SharePoint2013ではサイドリンクバーの「サイト コンテンツ」へのリンクは削除できるようになりました。ただし、ページ右上の歯車アイコンをクリックすると、権限がフルコントロールだろうが閲覧だろうが表示されるメニュー内には依然として「サイト コンテンツ」は表示されています。

ここを非表示にするためだけに、マスターページをカスタマイズするのは嫌ですよね。僕は嫌です。そこでCSSを用いて非表示にします。SharePointをCSSでカスタマイズする際におそらく最も利用されるであろうdisplay:none;の登場です。

.ms-siteactions-normal { display:none; }

これをCSSファイルにして、対象ページにスクリプトエディターWebパーツなどを配置してCSSファイルのリンクを記述するか、対象がサイトであれば代替CSSで設定すればOKです。(発行機能が非アクティブ状態で代替CSSファイルを設定したい場合は、ググると情報が出てきます。)

これでサイト コンテンツへのリンクは非表示になったので、直接URLを叩かない限りは見られる事はなくなります。

と、ここまでは他にも紹介しているブログなどはあります。しかし、この方法には弱点があります。閲覧者や投稿者だけでなく、フルコントロール権限であっても非表示になってしまうので、サイト管理者がサイトの設定を行う導線まで奪ってしまうのです。

では、閲覧者や投稿者は非表示にし、フルコントロールは表示させる方法が、CSSと標準機能のみで実現できるでしょうか?
答えは「できます!」
ヒントは「全員非表示、フルコン復活」です。

■方法

CSSファイルを置くライブラリの権限を設定すれば可能です。

【1】まずは全員非表示
これはすでに上で紹介した方法で非表示にします。ここまでは同じです。

【2】フルコンのみ表示復活
・新規に表示復活用ライブラリを作成
・権限の継承を中止
・フルコン以外の権限設定を削除
・ライブラリに以下の内容のCSSファイルをアップ。

.ms-siteactions-normal { display:inline-block; }

【3-1】適用(対象がページの場合)
対象ページにスクリプトエディターWebパーツなどを追加し、2個のCSSファイルのリンクを記述。
※この場合、【2】でアップしたCSSファイルのリンクを必ず【1】のCSSファイルのリンクよりも下に記述してください。(!importantでもOKですが、ムダに使いたくないので。)

【3-2】適用(対象がサイトの場合)
代替CSSの設定は1ファイルのみなので@importを使い2個のCSSファイルのインポートを記述した3個目のCSSファイルを作成し、【1】の時にアップしたライブラリにアップし、代替CSSの設定で適用。
※同じく、@importの記述では記述の順番に気をつけてください。

以上です。
若干複雑ですが、マスターページをイジるよりはマシかと思います。また、この方法を使えば、歯車メニューのみならず、様々な場所で「閲覧・投稿ユーザーのみ表示させたくない」が実現できます。もちろん「閲覧のみ表示させたくない」などのバリエーションも可能ですね。

このようにSharePointを利活用する場合、基本機能ではかゆいところに手が届かない場面が多々ありますが、その際に難しい開発やカスタマイズを行いリスクが伴うよりは、このように基本機能とリスクや難易度が低い方法の組み合わせをパズルのように考える事で、実現できてしまうケースもあり、ここがまたSharePointの楽しいところでもあるのかなと思います。

SharePoint サイトのホームページ(トップページ)をサイト管理者以外に触られたくない

SharePointを運営していると、サイト管理者からよくある問い合わせがあります。「トップページがサイト管理者以外の人にチェックアウトされる事がよくある。」アクセス権限設定は問題なく、チェックアウトした本人に確認すると身に覚えがないとの事。
この場合、「チェックアウトしている人はそのサイトに対して投稿権限が付与されていませんか?」と聞き返せばほぼ100%「そうです。」と返答が来ます。つまり、ページも(チームサイトの場合)「サイトのページ」というライブラリの1アイテムなので、サイトに対して投稿権限があれば編集ができてしまう事。

一般的な考えとしては、サイトのトップページはサイト管理者しかイジれないと思ってしまいがちです。サイト管理者も投稿者もその仕組みを知らずに、投稿者が興味本位または操作ミスでページを編集モードにしてしまい、自然とチェックアウトされたままになっている状態。

さて、この場合、そういうものだと説明すると必ず「なんとかなりませんか?」と言われます。この場合も対応は以下の通りです。

【1】サイト内でホームページ以外でページの利用をしない場合
●「サイトのページ」ライブラリの権限設定を変更
・権限の継承を中止
・サイト管理者以外のSharePointグループおよびユーザーを閲覧権限に変更

【2】サイト内でホームページ以外でページの利用がされている場合
●「サイトのページ」ライブラリ内の「ホーム」ページの権限設定を変更
・権限の継承を中止
・サイト管理者以外のSharePointグループおよびユーザーを閲覧権限に変更

これで投稿権限ユーザーもホームページに対しては閲覧権限になるので、チェックアウトをされてしまう事がなくなります。

ただし、権限の継承を中止した事の注意点としては、サイトの権限を変更した場合は、忘れずに継承を中止した箇所も同じ設定にしましょう。意外とこれを失念して、サイトに新規ユーザーに権限を付与したのに、ホームページに権限を付与し忘れているからアクセスできないなんてトラブルもあります。

ちなみに問い合わせが来てから解決するまで、これを説明するのも相手次第では結構対応が大変になります。説明を求められたり、打ち合わせの席を設けられたり。

SharePointを導入する(している)企業のIT部門や運営部門は、やはり利用者への教育は必要だと思います。

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

※画像もビデオもファイルも全て同じなので、以下の例は画像にします。

SharePoint2007ではリストのアイテムの本文内に画像を表示したい場合、ちょっと面倒でした。通常のブログサービスのようにリッチテキストエディタからファイルをアップロードすればOKというわけではなく、一旦ライブラリに画像をアップし、そのURLをコピーして、リストのアイテムの複数行テキスト列内に貼り付けるような、投稿者に操作をお願いするにはちょっと酷な感じでした。

時を経て、SharePoint2010からはリストのアイテムの(拡張リッチテキストの)複数行テキスト列の場合、リボンタブ「挿入」→「画像」→「コンピューターから」で行う事ができます。これで通常のブログサービスのような操作感に近づいたのかなと思い、喜ばしい機能でした。

この機能はSharePoint2007の頃のような一旦ライブラリに画像をアップするという操作を、リストのアイテム投稿ページから移動せずにダイアログ内で行えるという機能で、結局、任意のサイト内のライブラリに画像ファイルをアップロードするという事には変わりありません。アップされると同時に本文内に表示されます。(実際にダイアログ内に表示されているコンテンツを調べると、宛先ライブラリに指定してあるライブラリのUpload.aspxをiframeで表示しているんですよね。)

アップロードする際に表示されるダイアログ内ですが、「宛先ライブラリ」という項目があります。つまりアップロード先のライブラリを指定する項目です。ドロップダウンの中にはサイト内のライブラリが一覧で表示されます。

ここは初期値で「サイトのリソース ファイル」ライブラリが選択されています。でも、中にはこのライブラリは利用されたくない場合もあると思います。ただ、初期値として設定されてしまっているので、「宛先ライブラリでは○○ライブラリを指定してください」と投稿者に指導をしたところで、操作ミスや失念でアップロードされてしまう可能性もあり、できれば初期値を別のライブラリに変更したいですよね。しかし、ここの初期値を変更できる設定はリスト内には存在しません。

標準機能では宛先ライブラリの初期値を変更できないのかと思ったら、ちょっと分かりづらい場所にあったので紹介します。

各ライブラリの詳細設定の中に設定項目があるんです。「サイトのリソース ファイル」ライブラリの詳細設定を見てみると、「サイト リソース ライブラリ」という項目が「はい」になっています。(サイトのリソース ファイルライブラリ内のサイト リソース ライブラリ…ややこしいですね。)この説明だけ読んでも宛先ライブラリの初期値に関わってくる項目とはわかりませんね。

「サイトのリソース ファイル」ライブラリのこの項目を「いいえ」に変更した後に、その後作成した宛先ライブラリで初期値にしたい「画像用ライブラリ」のこの項目を「はい」にすると、宛先ライブラリの初期値が「画像用ライブラリ」になりました。

ちなみにこの設定項目はサイト作成時に「サイトのリソース ファイル」ライブラリのみ「はい」になっており、その後作成するライブラリでは既定では「いいえ」で作成されます。

また、この設定での「はい」「いいえ」は上述の通り、宛先ライブラリの初期値の設定のようで、宛先ライブラリのドロップダウンに表示・非表示の設定ではないようです。「いいえ」にしても初期値にならないだけでドロップダウン内には選択肢の値として存在します。ここに表示・非表示という設定があれば良いのですが、今のところ見当たりません。例えば投稿者には選択肢の値として表示されたくない場合は、該当ライブラリのアクセス権限を外すなどの対応になるのかなと思います。

複数ライブラリでこの項目を「はい」にした場合の挙動はどうなるのか?を検証したところ、またまた興味深い結果になりましたので、それは日を改めて記事にしたいと思います。

SharePoint の左上の製品テキストをCSSで変更する

SharePointの画面左上にオンプレなら「SharePoint」、SharePoint Onlineなら「Office 365」というテキストが表示されていると思います。ここを変更する方法としてPowerShellを使う方法がありますが、PowerShellを使いたくない、使えないという環境だったりする場合は、CSSで変更できます。CSSでも色々なアプローチがありますが、今回はcontentプロパティを使います。代替CSSに設定したCSSファイルに記述するなり、マスターページに記述するなり、ページ内にWebパーツとして記述するなり、ニーズや環境に合った方法で適用してください。

■追加する場合

変更ではなく、今の製品テキストを残したまま追加する場合

SharePoint2013

.ms-core-brandingText:after { content:”(しぇあぽいんと)”; }

SharePoint Online

.o365cs-nav-brandingText:after { content:”(おふぃす さんろくご)”; }

■変更する場合

厳密には追加した後に、オリジナルの方に消えていただく方法です。

SharePoint2013

.ms-core-brandingText:after { content:”残業なんてしたくない!”; padding-left:10px; } .ms-core-brandingText { text-indent:-102px; }

SharePoint Online

.o365cs-nav-brandingText:after { content:”残業なんてしたくない!”; padding-left:10px; } .o365cs-nav-brandingText { text-indent:-116px; }

リンクにしたり、SPOの場合はリンクを変更したりという事はさすがにできませんが、文言を変更する程度ならお手軽かなと思います。

また、この方法を使えば左上の製品テキストだけでなく、SharePointの標準機能では変更できない文言の変更など、色々な場所で使えるのではと思います。例えばリボン内のテキストとか、ダイアログのタイトルとか。
ただし、今回の上述のソースもそうですが、個人発信のブログなので検証に費やす時間もほとんどないので、動作を保証するものではありません。ソース丸々コピペすれば使える!というよりは、考え方のヒントにしていただければと思いますので、例えばセレクタの指定がシンプルだと他に影響が出る事も考えたり、色々と工夫してみてください。

Web制作をしていた頃はcontentプロパティなんてclearfixくらいでしか見なかったのですが、SharePointを扱うようになってからは使うようになりました。

SharePoint では0バイトのファイルをアップロードできない

人によっては今更のネタですみません。

0バイトのファイルをアップロード。まぁ通常運営していてなかなかありえない利用シーンですよね。なので僕も今まで知りませんでした。

先日、限られた環境で検証しようとした時に若干焦った事です。カスタムを施したカスタムリストの投稿を検証した際に、添付ファイルにファイルを添付するテスト事項もあり、いつもならExcelなどでテスト用ファイルを作るのですが、限られた環境という事でテキストファイルでテスト用ファイルを作成しました。いつもの自分の操作ならテキストエディタを開いて、適当に文字を入れてから保存をするのですが、なぜかこの時は無意識にデスクトップで右クリック→新規作成→テキスト ドキュメントという手順で、テキストファイルを作成しました。この場合、ファイルサイズは0バイトなんですね。ということで、偶然0バイトのファイルを作成したんです。これを利用してテスト投稿をしてみたのですが、SharePointのエラーページが出て投稿できませんでした。
エラー内容を見ても意味がわからず、原因不明で困っていた時に、色々やってみるとファイルを添付しない時には問題なく投稿される法則がわかり、その後、一緒にテストした人に「ファイル、0バイトじゃないですか?」と言われ、ようやく原因がわかった感じです。

で、検証してみました。

■ライブラリ
ライブラリに0バイトのファイルのアップロードを試みようとすると、丁寧に理由が記載されるのですぐにわかります。やはり通常の利用では0バイトのファイルを扱わないので、この表示は初めて見ました。

■リスト
添付ファイルの0バイトのファイルを添付しようとすると、添付ファイルを指定する操作は特に問題ないのですが、投稿をしようとするとSharePointのエラーページが表示されます。添付ファイルを指定する操作の段階でエラーになってほしいところです。また、これで投稿がエラーになってブラウザの戻るボタンをクリックしても、入力した情報は消えてしまいます。つまり苦労して入力した内容がパァになってしまうんです。

このエラーページには理由が記載されているので原因がわかりますね。ただ、この環境では理由が記載されていましたが、冒頭で同様のエラーページが出て焦った話の際の環境では、この理由が記載されていなかったんです。なので原因がわからずに焦った感じです。おそらくSharePointのバージョンの違いなのかと思いますが、詳しいことはわかりません。

ということで、冒頭の通り、通常運営していて0バイトのファイルを扱うことはないとは思いますが、こういう事があったぞという備忘録でした。

Nintex Formsの表示速度

Nintex FormsはSharePointの標準では実現できないフォーム画面のカスタマイズを比較的容易に実現できる便利なツールですが、過去にも色々クセがある事を紹介いたしました。

Formsでフォーム画面をカスタマイズする再に重要な点として、表示速度の問題は外せません。いくらUIが優れてフォーム入力が便利になっても、表示するのに時間がかかってしまってはUXとしては台無しです。

僕自身がFormsを使用した制作経験が少ないのですが、その少ない経験やググった結果から、Formsで表示速度に影響を及ぼすであろう原因を以下に挙げます。

・コントロール数
・ルール数
・カスタムしたJavaScript・CSS

もちろんサーバーやクライアントPCやブラウザ(得にIEは遅い…)などもありますが、同一環境での影響という意味では、大きくは上の3項目が挙げられます。カスタムしたJavaScript・CSSに関しては内容によって左右されますので、そういう意味でも表示速度に問題が出た場合の対応策として挙げやすいのが、単純にコントロール数やルール数をダイエットさせる方法かと思います。

デザインのみで利用しているパネルを妥協できる範囲内で削除してみたり、一つにまとめられるであろう列はまとめたり、表示・非表示で利用しているルールを本当に必要かどうか精査してみたり、バリデーションで利用しているルールを本当に必要かどうか精査してみたり。表示速度と言う観点に重点を置き、真剣に検討をすると意外とコントロール数もルール数も減らす事ができます。軽く検証したところ、20コントロールを削除するとIEでおよそ1秒~1.5秒早く表示される感じです。小手先の工夫でも十分に体感できる可能性があります。

コントロール数と単純に言ってもそのコントロールの種類でも左右されるのかもしれませんが、そこまでは把握できていません。ただ、軽く検証してみたところでは、コントロールの種類で大きく表示速度に左右される事はなさそうです。(ただし、別の場所からデータを引っ張ってくるようなコントロールは影響大きそうですが、そこまでは調べきれていません。)
おそらくですが、コントロール数が増えるほど表示時間が遅くなる原因は、コントロールを適切に配置するのに、CSSで大枠のdivにインラインで[top][left][height][width]といった位置情報が記述されていて、それらを表示の際に全てのコントロールで計算しているので時間がかかっているのではと思っています。(あくまでも予想なので違っていたらゴメンナサイ。)
また、例えばパネル内に非表示にした隠し項目や、タブのように開閉させてコントロール数を表示上で制御している場合でも、CSSでdisplay:none;で非表示にしているだけで、ソースを見るとHTML上では記述があり、上述の位置情報も計算されていたので、表示上のコントロール数ではなく、デザイン画面で実配置したコントロール数が影響範囲です。実際に表示速度が遅い状態でコントロールを非表示にしても遅いままです。

そういう意味でも、もし表示速度でお悩みの場合は、やはりコントロール数を減らしていく方向が一番考えずに表示速度を速くさせる方法なのかもしれないです。