分類存檔: SharePoint 解決方案的設計

跟蹤實踐活動 – 部分 1

3 回复

大約一年前, 我加入了 激流迴旋諮詢 在紐約作為我們稱之為實踐區領導在這裡。  (作為對這個博客的點輕微一邊開機自檢, 這種改變在工作中我總落在博客中的帳目。  在每天的"東西"是大改變角色和一個大變化，但我已經有點適應自己給它，看看轉發到再創作 微笑 ).

在這個 PAL 角色, 我負責保存公司和周圍的 21 西二十一街從週期性災難。  這是壓力的很大 (所有的孩子都比你可能會認為 — — 想想!). 

在對這種必要性的服務, 我需要去幫售前, 創建和更新轉到市場產品和服務, 雇幫好人, 訓練的人來做得更好 (但真正, 若要使我的工作更容易) 和偶爾做些計費在用戶端。  我有很多的"輸入"— — 來自用戶端的問題, 銷售機會, 我自己又迂腐的思想等等。  一些它的真的很好 (像熱銷售 oppty) 雖然很多都是不太好。  關鍵是要最初跟蹤, 確定優先次序和管理每個這些想法 (大和小) 圓滿結束。 

不是新的這種任務管理, 權利?  我們有很多工的工具來説明我們與此。  Outlook 具有任務。  你可以在一起打一個試算表很好和快速。  我第一次的任務管理工具在法律的記事本回我在 GAF 的日子作為 IT 部門中的開發人員。  (問我那些美好的舊時光下次你見到我如果你感興趣的事, 或也許不…).

正在一個 SharePoint 傢伙 (名義上, 至少), 我一直以為要使用 SharePoint。  但由於某種原因, 泛型的工作清單永遠都不是為我。  幾個月前的一群, 我決定治癒自己，只是創建一個基於 SharePoint 的解決方案。  它如此困窘創建非常容易，我以為在這裡寫關於它.

所以, 我的目標是很簡單:

  • 超級簡單和快速的資料輸入
  • 確定活動的優先次序
  • 對活動進行分類
  • "下一步"驅動 — — 這些活動往往將跨越周 (也許甚至幾個月).  他們幾乎從來沒有"結束"後一個特定的更新程式.

這些位借自己很好的內容類型, 這就是創造的東西:

image

你能看到我有一種銷售的偏見與此在第一次, 因為我也有"客戶"欄位。  很多我的實踐活動都基於用戶端 (實際或潛在).  但其中許多人還注重內部的。  我在那裡打"激流迴旋"創建它們時, 但它總是感覺有點奇怪。  我應命名它更一般的東西。  也許"目標群組織"之類.

下面是幾個雜項筆記上的內容類型:

  • 活動影響已下放到測量的優先。  我不知道我為什麼不是"優先"與"影響"天零, 但這是自己做了什麼。 
  • 下一步和下一步驟日期 — — 一個儀表板，按下一次活動日期驅動了  此儀表板有點已成為周天我進軍的命令。  我只是去到儀表板和首先側重于高優先順序的東西，從那裡去。  (有的概念是"無標籤"
  • 主要擁有者 — — 唯一值得注意的是 — — 是不是真棒，你可以進行排序和篩選對 SP 中的多項選擇列 2010! 我其實不完全是買納入這一概念在第一次.
  • 活動狀態 — — 真的只是"打開"或"關閉"。 
  • 初步實踐 — — 之後我開始使用此, 在我的小組的另一個朋友想試試這個, 所以陷入這樣的組合來區分我的東西 (入口網站 & 合作) 和她的東西 (Azure).

這裡是我的儀表板:

image

(所有的模糊出位 — — 很抱歉，我不想這麼創造了大量的測試資料，我不想給任何人心臟病發作了共用關鍵的詳細資訊 [請參閱重新介紹中的位: 拯救世界, 等。, 等。, 等。]).

我有在此清單中的幾個其他意見, 其中包括一個資料表視圖，可以讓我做大規模的更新。  我這樣做最常時較低的優先順序，按計劃行事從來沒有相當的專案做了，需要出去一周推一群.

每天, 我拉起我的活動日誌，剛剛開始工作關閉清單的頂部.

在部分 2, 我會解釋如何我做的這個更有用的加好已啟用電子郵件的文件庫和 SPD 工作流.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

讓閃亮的例子鉛 SharePoint 採取更多的途徑

發表評論

今日刊登了我的第一個"純"BrightStarr 的博客條目。  這裡是個難題:

有很多相關的互聯網絡晚對 SharePoint 收養的主題，並尤其是缺乏對話. 沒有人想要去設計一個農場和安全基礎架構的所有麻煩, 參加講習班, 放在一起時髦的外觀和感覺, 工作出一個岩石固體的資訊體系結構可以承受公司再公司法的變遷，最後, 低調填充的推出，只是為了發現三個月後投入，小於 50% 該公司的雇員在使用 SharePoint 和大多數人都用它來替換舊的網路檔案伺服器 ("S:\ 磁碟機").

沒有銀彈 (或單個博客張貼內容) 要解決這一問題. 不過, 有很多事情你可以減少貧血的 SharePoint 門戶的風險. 這樣一種技術是"閃光的示例模式。"

我很想知道你關心分享其他 SharePoint 通過戰略。  如果您不要共用, 請在 BrightStarr 博客上留下作為注釋.

閱讀整件事情在這裡: http://www.brightstarr.com/US/Pages/blog-view.aspx?BlogID=52

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

創建印表機友好的頁面，甚至將其列印出來

1 答覆

我寫了一篇文章 SharePoint 簡報 一周或前和它已張貼。  這裡是開放位:

image

您可以閱讀整件事情在這裡: http://sharepointbriefing.com/features/article.php/3904906/Create-a-Printer-Friendly-Page-in-Your-SharePoint-Sites.htm

我希望這可以説明別人。  享受!

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

"能做” 與"應做比較” 在 SharePoint 專案

8 回复

我認為我們很多人偶爾提出了與, 沒有一個更好的短語, 幼兒的要求。  最終使用者真的, 非常迫切希望某些特定外觀和感覺, 或一個非常具體的分類結構或要剪出一個按一下或功能表選項，以紓緩導航或 [插入充滿激情地舉行碰巧是錯誤的信仰].  作為 SharePoint pro 的, 我們通常可以滿足幾乎任何類型的與平臺的要求, 但對其中一些, 我們知道在我們的心中，:

  • 他們打算採取過多的時間來執行 (因此更多的成本和)
  • 他們要將高度自訂，因此難以維護和疑難排解
  • 是有一些簡單的 SharePoint 方法，可以滿足 80% 或更多的要求 (e 小節. 符合要求的精神, 但不是要求的信件)

底線, 我們知道"規定"是真的只是很高興了，甚至在某種意義上合法, 但事情的人應該住在一起而不是花很多時間試圖"解決"。

因為之前有許多次看到這種模式，我認為這些作為"年輕的孩子"的要求。  孩子們將走松和嘮叨你為一些新玩具為周的時間。  你把他們的玩具, 他們和它一起玩的幾個小時或幾天，然後把它放下, 從來沒有把它再撿起來。  或, 不是你的玩具, 愛嘮叨的停止和孩子上將移動，成為自由世界的總統。   我見過這種事發生在 SharePoint 專案中。  決策者也可以得到他們想要什麼和它成為未使用或未充分利用的功能或他們不得到他們想要和該專案仍然成功反正.

我想起了今天在一個論壇中張貼和我喜歡如何 克萊頓 · 科布 試著讓論壇海報推回對這些類型的要求之一: http://social.msdn.microsoft.com/Forums/en-US/sharepointinfopath/thread/af8a1941-92ad-4f1a-b1bf-875e28ea79b7/

我真的很好奇的人如何查看本主題和你是如何處理它。  我錯過點嗎?  引導從在瑣碎的要求恰恰給決策者的戰略嗎?  請留下評論.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

使用工作流來類比內容類型安全

3 回复

另一天, 另一種 MSDN 論壇啟發開機自檢.

有人問是否他們能安全的內容類型，這樣當使用者按一下自訂清單中的"新"按鈕上, 僅指該人被授予存取權限的內容類型將會出現在下拉清單中。  正如我們所知, 這並不是開箱即用支援.

這個問題總是會現在然後和這次, 我有一個新的想法。  讓我們假設我們有這樣的方案:

  • 我們有售票系統服務支援.
  • 説明台售票系統允許使用者輸入經常説明台票務資訊, 如問題區域, 問題狀態, 等.
  • 我們想要讓"超級"使用者指定的"緊急"欄位.
  • 其他使用者不能訪問該欄位。  系統將總是將"中等"級優先分配給他們的請求.

我們能做的就是創建兩個單獨的 SharePoint 清單和兩個不同的內容類型, 一個"超級"使用者和其他為別人.

每個清單的工作流將資料複製到主清單 (實際説明台機票清單) 和這一進程從那裡所得.

這種方法可能工作流列級安全性，以及一種。 

我沒試過, 但它認為合理，並給出一個相當簡單, 如果很粗糙，, 實現一種內容類型和列級別的安全選項.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

內容查詢 Web 組件: SharePoint 的瑞士軍刀

發表評論

我最新的文章是在 www.sharepointbriefing.com. 這裡是個難題:

image

閱讀整件事情在這裡: http://sharepointbriefing.com/features/article.php/3874226/Content-Query-Web-Part-SharePoints-Swiss-Army-Knife.htm

看到它在使用真正的公共 web 網站在這裡按照下面的步驟:

  1. 轉到此 web 頁: http://cdi-its.com/Pages/Customer_Support.aspx (這是為 CDI 的客戶支援頁面).
  2. 在左側的導航中按一下"案例研究".

它會跳轉到"客戶支援"部分列出的個案研究.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

預先存在的條件: 拯救 SharePoint 警報範本 (?)

發表評論

我的一個客戶共事前的承建商，打造出了企業小但有用 HR 應用程式. 那個承包商 SharePoint 設計器用於實現該解決方案的工作流部分. 它是有點亂. 例如, 有九個 SPD 工作流支援單個邏輯工作流進程和達五人可能在任何給定的時間，給出了正確的條件同時開槍. 調試起來並不容易 🙂

我的客戶擁有一些仍然懸而未決的要求, 其中之一是通常提供更多的上下文時，系統會發送電子郵件通知 — — 無論是在電子郵件本身以及相關聯的任務形式. 作為 SPD 工作流執行者知道, "從使用者收集資料"SPD 行動實際上與自訂內容類型創建一個任務. 當我們使用該操作, 我們不去指定很多. 我們可以提示輸入一些值 (例如：. "批准"或者"拒絕") 我們可以指定一個硬式編碼值中的標題和說明. 這大概就是.

我的客戶的要求是兩折:

  1. 當 SharePoint 發送郵件任務分配, 電子郵件正文中包含大量的有關任務的資訊.
  2. 更重要的是, 到目前為止 – 當使用者按一下電子郵件中的任務連結, 工作表單應該有核准者使其批准或拒絕的決定所需的所有資訊. 馬上, 經理需要點擊專案連結本身向下切入到底層的細節，沒人喜歡，. 您必須按一下電子郵件中. 然後您需要按一下任務專案上有點晦澀的連結. 然後你可以看看基礎資料 (在這種情況下形成的 InfoPath). 然後你點擊後面或後面, 等. 每個人都討厭它.

我繼承了這個有點淩亂的技術解決方案和我想要盡可能的少侵入性的方式進行更改.

馬上帶的方法是創建一個自訂的警報範本. 這裡你可以閱讀有關的. 像這樣工作流程:

  • SPD 工作流運行.
  • 在一些點, 它將任務分配給經理.
  • SharePoint 系統會自動發出警報，對那位經理. 這不是一部分的 SPD 工作流，而是"什麼 SharePoint?" (SharePoint 定時服務, 我相信).
  • 支援標準的警報進程調用自訂報警處理 (下面魔法規則如上文所述參考文章).
  • 我自訂的警報處理常式運行時, 它生成一個漂亮的電子郵件. 更重要的是, 因為它有任務在手, 它還裝飾具有滿足業務要求所必需的所有上下文資訊的實際任務.
  • 獲取使用者的電子郵件，它是有用的上下文資訊的完整.
  • 使用者點選連結任務的任務本身是完整的有用的上下文資訊，.
  • 每個人都回家來了西瓜和霜淇淋.

我做快速的 POC 和它的作品在實驗室環境中. 我得到我的自訂電子郵件警報按預期. 我也要更新的任務說明和標題本身.

唯一麻煩的地方, 到目前為止, 是為了避免地方警報更新專案情況, 觸發另一個警報. 這並不讓我擔心.

到目前為止似乎有希望...

偉大的事情是，我不需要再亂動任何現有的 SPD 工作流. 他們是無所不知的警報處理常式是"IIZ 狂奔在 DA BAKGROUND, 天藝 TEH 工作清單火爆莫瓦爾上下文”.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

Technorati 標籤: ,

SharePoint 示範: 利用 SharePoint 打造一個垂直的商務應用程式

發表評論

[請注意: 我想要馬上說我覺得這次示威的預期成果的金融興趣, 我提及完全資訊公開, 等. 這是實際上第一次我曾經博客事件位置要以這種方式個人得益。]

此 web 演示發生 （星期四）, 06/04 在 12:30 美國東部時間, 在結束 1:30路透社.

在我的優秀商業夥伴的合作, 集成的系統及服務集團 (ISSG), 我一直在努力開發使用 SharePoint 作為平臺的垂直商務應用程式. 在此情況下, 我們正在構建的應用程式服務的需要，讓他們的客戶定制的產品的製造商. 在這些情況下, 大量的協作需要客戶與製造商之間的地方. 此外，還有大量的製造商中不同群體之間所需的協作, 包括銷售, 工程, 研究與開發, 法律和其他群體.

該演示要展示應用程式，方便了協作的那種, 所有這些協作位需要討論如何與後端 ERP 系統集成.

最後, 這不一個 SharePoint 演示. 這是解決方案的一個演示碰巧使用 SharePoint 作為平臺特定的細分問題.

所以, 為什麼你會費心去註冊，看看這個演示? 我希望博客的讀者不會對按訂單製造商的解決方案感興趣的所有內容take您的收穫將是概念本身–僅使用SharePoint來提供業務解決方案而無需考慮SharePoint本身.

如果你有興趣, 請在這裡報名(https://www323.livemeeting.com/lrs/8000043750/Registration.aspx?pageName=skmqfwbr5smmlx20).

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

你就能撬動我的感冒從 SharePoint 設計器, 死人的手

發表評論

我的最新文章 在 www.EndUserSharePoint.com. 我寫了關於 SharePoint 設計師, 最終使用者和最終使用者可能嘗試的戰略和按照大綱，以顯示能力和建立信任圍繞此工具.

評論都比文章本身更有趣.

將其簽出.

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin

MOSS 使用者設定檔為使用者的語言首選項的監督

4 回复

我當前的專案上, 有些使用者將前往世界各地和當他們到達不同的目的地, 使用任何機器時派上用場. 那些客人機器將運行 Windows 安裝和配置為本地語言環境. (我剛發現的客人機器可能沒有正確的語言包… 可能不會, 事實上… 我停車現在一個人).

SharePoint 需要提供一種機制，藉以使用者能夠選擇他們的首選的語言，然後榮譽那語言無論使用者如何訪問苔蘚青苔. 換句話說, 無視無論瀏覽器會告訴 IIS/苔蘚和相反查找該首選語言和使用它.

我們要去調查兩種方法:

  1. HTTP 處理常式: 在 IIS 上安裝一個自訂 HTTP 處理常式將查找使用者的苔蘚設定檔, 弄的首選語言，然後在將控制傳遞給苔蘚之前切換周圍所需的 HTTP 標頭.
  2. global.asax: 修改 global.asax 來做同樣的事情. 我們可能會修改別的東西, 但這個想法是，我們找到一些我們可以在其中插入我們地區設定開關的邏輯的地方.

其他複雜的因素是我們需要支援 60 k 使用者, 關於 1,000 這可能會同時訪問 MOSS 在高峰負荷.

HTTP 處理常式似乎相當激烈, 但可能是最好的地方，要放入的代碼，因為它是在 IIS 級別和全知. 它是工作的好的單點.

我們傾向于一種 global.asax 類型的方法, 主要是因為我們相信我們會有更多選擇，此時，緩存資料.

我會更多關於這個主題的博客，因為我瞭解更多.

如果你有知道關於這件事, 請發表評論🙂

</結束>

訂閱我的博客.

跟我在 Twitter 上 http://www.twitter.com/pagalvin