Zur Zeit wird gefiltert nach: s12
Filter zurücksetzen
Anwenderhilfe 2.0 mithilfe eines Wikis auf SharePoint-Basis
Grundsätzlich hält die Wiki-Funktionalität von Microsoft SharePoint 2007 oft nicht alles, was man sich von ihr verspricht. Bei der Anwendung im Rahmen eines verteilten Wissensmanagements im Unternehmen stößt man in der Praxis schnell an Grenzen. Microsoft hat dies auch erkannt – die Wiki-Funktionalität der neuen Version von SharePoint 2010 macht einen erwachsenen Eindruck.
Nichtsdestotrotz ist die Wiki-Funktion in SharePoint 2007 eine interessante Option – für einen unseren Kunden sind wir in Sachen Anwenderhilfe neue Wege gegangen und haben das vorhandene Anwenderhandbuch (ein mehr als 150 Seiten langes Dokument) durch ein SharePoint-Wiki abgelöst. Damit ist es möglich die Inhalte im Web darzustellen sowie Aktualisierungen und Ergänzungen (z. B. Best Practices) durch alle Anwender umsetzen zu lassen.
Wie sind wir vorgegangen?
Das umfangreiche Handbuch wurde nach Themengebieten in kleine, handlichere Teile zerlegt. Jedes Thema wurde als einzelner Wiki-Beitrag in einer flachen Liste gesammelt.
Jeder Wiki-Beitrag wird zudem durch spezifische Attribute ergänzt (wie z. B. betroffenes System, relevante Benutzerrolle und Themengebiet).
Über diese Attribute kann der Endanwender alle Wiki-Beiträge filtern, gruppieren bzw. sortieren, um gezielt auf die jeweils relevanten Artikel zugreifen zu können. Zudem können die Wiki-Artikel mit anderen SharePoint-Listen verknüpft werden.
In diesem Fall wird beispielsweise eine kombinierte "Issue and Change Management"-Liste verwendet, in der Issues und Change Requests erstellt und deren Lösung bzw. Umsetzung überwacht werden, sowie eine Q&A-Liste. So kann ein Wiki-Beitrag auf relevante Issues, Change Requests sowie Q&A- Einträge verweisen – und umgekehrt. Mit einem Klick gelangt man so zu den verwandten Einträgen.
Diese einfache Umsetzung eines traditionellen Handbuchs mit modernen Hilfsmitteln schafft Transparenz für den Endanwender und erleichtert die Arbeit eines zentralen Administrators bzw. Redakteurs.
PR-Abteilung von Campana & Schott organisiert sich über SharePoint-Intranetportal neu
Wie kommt man innerhalb von nur einem Jahr von 34 (2009 gesamt) auf bereits 28 Veröffentlichungen im ersten Vierteljahr 2010. Und wie gewährleistet man gleichzeitig Präsenz in einer ausgewogenen Vielfalt an qualitativ hochwertigen Medien?
Mit unserer vergleichsweise schlank aufgestellten PR-Abteilung blicken wir inzwischen auf über 300 Publikationen seit Beginn der Pressearbeit bei C&S zurück. In einem Unternehmen, das sich im Kern um Effizienzsteigerung bei seinen Kunden kümmert, liegt die ständige Selbstreflektion in Sachen Effizienz auf der Hand. Laufend versuchen auch wir unsere eigenen Prozesse zu optimieren. Deshalb wollten wir auch nicht einfach nur weiter darüber berichten, was bei unseren Kunden alles mit der SharePoint-Technologie möglich ist.
Eat-your-own-dogfood – Befolge selbst was du predigst, nutze die Produkte, die du verkaufst
Anfang 2009 suchten wir nach einer Möglichkeit, die Flut der Themen strukturierter bearbeiten zu können, die bei Campana & Schott PR-technisch aufzugreifen und zu bearbeiten sind. - Warum also nicht einfach auch in der PR-Abteilung die Technologie anwenden, die unsere Berater-Kollegen täglich unseren Kunden anpreisen? Tatsächlich entschlossen wir uns nach Gesprächen mit unseren SharePoint-Experten dazu, sämtliche Arbeitsprozesse über unser internes SharePoint-Portal CaeSar abzubilden. Von der ersten Idee für einen Artikel, über Auftragserteilung, Briefings und Review-Schleifen zwischen den fachlich Verantwortlichen und der PR-Abteilung bis hin zum Mailverkehr mit den Redaktionen und zur Veröffentlichung, - alle Schritte laufen nunmehr über SharePoint ab bzw. werden dort zu jedem Artikel dokumentiert.
Aufbauend auf die Erfahrung unserer SharePoint-Experten und nach einer Schulung haben wir ausgewiesene Nicht-Teckies innerhalb von ca. zwei Monaten die Standard-Funktionalität von SharePoint relativ leicht auf unsere PR-Zwecke angepasst. Die Umgewöhnung fiel leicht, denn die Vorteile sind täglich spürbar: Es ist ein Pressebereich entstanden, der über individuelle Rechte interne von Firmenweit öffentlichen Arbeitsbereichen trennt. Kollegen sehen nur, was für sie wichtig ist. Alle an einer Veröffentlichung Beteiligten können auf zentral im Arbeitsbereich abgelegte Briefings, Planungs- und Erstellungsdaten zugreifen und diese bearbeiten – auch von unterwegs aus, das ist ein unschlagbarer Vorteil.
Ab mit alten Zöpfen
Vorbei die Zeiten, in denen ich wöchentliche Archivierungswarnungen meines Outlook-Postfaches erhielt, weil manche Review-Schleife und jeder neu eingereichte Artikel Grafik-Attachments mit mehreren Megabytes bedeutete. Heute versenden wir Links und keine Mail-Anhänge.
Vorbei die Zeiten, in denen sich Mails mit verschiedenen Überarbeitungsständen überkreuzten und mühselig über Dokumentenvergleich der aktuelle Stand rekonstruiert oder zusammengefügt werden musste. Heute arbeitet jeweils nur einer an einem Dokument und währenddessen ist es ausgecheckt. Kein anderer kann dann daran arbeiten und dadurch Verwirrung stiften.
Adieu lokale Dateiablage jedes einzelnen Überarbeitungsstandes in vielfältigen Unterordnern. Die historisierte Ablage auf CaeSar lässt mich heute jeden Überarbeitungsstand nachverfolgen und kommentieren. Zu jeder Zeit ist mit ein paar Mausklicks für die PR-Abteilung klar ersichtlich, wer gerade am Zug ist, welche Artikel aktuell bearbeitet werden, wie viele sich derzeit im Planungsstatus befinden und welche Deadlines näher rücken etc..
Die Public Relations Abteilung von Campana & Schott ist SharePoint-Anwender-Pionier
Inzwischen dürfen wir uns zu den erfolgreichen SharePoint-Anwender-Pionieren von Campana & Schott zählen und können auch der Presse viel besser aus eigener Praxis berichten. Nicht nur darüber, dass unsere Arbeit Dank SharePoint auf ganz neuem technischen Niveau strukturiert ist, und dass die vielen Möglichkeiten Informationen zu vernetzen, zu filtern und auszuwerten sehr verlockend sind. Die Möglichkeiten sind so vielversprechend, dass wir aufpassen müssen, wie detailliert wir den zugegeben deutlich gestiegenen Pflegeaufwand im Detail betreiben.
Umstellung hat sich gelohnt
Bereits im ersten Vierteljahr 2010 konnten wir die Zahl der veröffentlichten Artikel und Newsmeldungen um ein Vielfaches erhöhen. Übrigens, auch das Ergebnis der gemeinsamen Mühen findet sich elektronisch auf dem Firmenportal CaeSar: Excel Adieu! Die stetig wachsende Veröffentlichungsliste heißt bei uns jetzt CaeSar-Publikationsliste und ist damit für alle Mitarbeiter jederzeit zugänglich.
PS: Was machen wir mit dem gewonnenen Freiraum? – Die genannten Zahlen sprechen für sich: Wir arbeiten an noch mehr Veröffentlichungen. Und zusätzlich findet sich dann und wann neuerdings die Kapazität, auch internationale Medien mit interessanten Inhalten zu versorgen. Welche? Das sehen Sie hier.
SharePoint: Wie versteckt man einzelne Views im View Selector?
Eine interessante Herausforderung wurde kürzlich an uns herangetragen: Ein Kunde von uns hat eine SharePoint-Liste mit unterschiedlichen Ansichten erstellt. Die Toolbar soll in jeder Ansicht komplett zur Verfügung stehen, damit jeder Nutzer auch zwischen den einzelnen Ansichten über den View Selector (rechts oben) navigieren kann.
- Abbildung 1: View Selector (Standard)
Nun soll es aber auch Ansichten geben, die nur für Administratoren zu sehen sein sollen. Dafür muss das Auswahlmenü des View Selectors reduziert werden (in unserem Beispiel soll die Ansicht "Testview2" nur für Administratoren angezeigt werden). Dies ist mit Bordmitteln so nicht konfigurierbar.
Folgenden pragmatischen Lösungsweg haben wir vor- und eingeschlagen: Context-Menüs in SharePoint werden über JavaScript angesteuert. Daher kann man sie auch mittels JavaScript anpassen.
Um das zu erreichen ist zunächst auf der SharePoint-Seite, auf der sich das Listen-WebPart befindet, ein Content Editor-WebPart unter(!) der Liste einzufügen. Anschließend editiert man dieses WebPart und fügt den untenstehenden Code in der Source Code-Ansicht (Knopf "Edit Source ...") ein.
Um die gewünschten Ansichten ausblenden zu können ist der eingefügte Code noch etwas zu konkretisieren. Der Code enthält zum Beispiel eine Variable "menuItemNames", die einen Array von Werten umfasst. Am Ende sind im angegebenen Codebeispiel die Werte "aaa","explorer view","testview1","testview2","testview3" ergänzt. An diese Stelle müssen alle Ansichten in der Reihenfolge, in der sie im DropDown-Menü des View Selectors angezeigt werden, eingetragen werden.
Weiterhin enthält der Code eine Variable "menuItems". An deren Ende befinden sich die Einträge "View1" (korreliert mit dem Eintrag "aaa") bis "View5" (korreliert mit dem Eintrag "testview3"). Hier sind gemäß der Anzahl der vorhandenen Ansichten die entsprechenden Werte zu entfernen oder hinzuzufügen. Dabei wird der Nummer entsprechend hochgezählt (bei 5 Einträgen (ohne Default View) also View1 bis View5; bei 7 Einträgen bis View7).
Abschließend muss der Methodenaufruf ganz zu Beginn des Codes angepasst werden. Mittels hideListViewToolbarItems ("[View Name 1]", "[View Name 2]") bestimmt man, welche Einträge nicht mehr angezeigt werden sollen. Im angegebenen Code-Beispiel wird die Ansicht "Testview2" ausgeblendet. Es lassen sich auf diese Art und Weise beliebig viele Ansichten ausblenden.
- Abbildung 2: View Selector (nach der Anpassung)
Wenn der Code gespeichert und alles richtig eingestellt wurde, sind die gewünschten Einträge aus dem View Selector-Menü verschwunden.
Dieser pragmatische Ansatz hat Grenzen: Man sollte beachten, dass auf allen SharePoint-Seiten, auf denen die Liste angezeigt und bei denen die Auswahl an Ansichten reduziert sein soll, ein entsprechendes Content Editor-WebPart mit dem angepassten Code erstellt werden muss. Weiterhin eignet sich dieser Code nur für statische Ansichten. Sobald Nutzer in der Lage sind neue Ansichten (sowohl öffentliche als auch persönliche) zu erstellen, wird der Code so nicht mehr funktionieren. Gleiches gilt wenn die Default View gewechselt wird.
Bei komplexeren Anforderungen setzen wir dynamischere Lösungen für das Ausblenden von Ansichten ein, die jedoch den Rahmen dieses Blogs sprengen würden.
CODE:
<script type="text/javascript" langugage="javascript">
hideListViewToolbarItems("Testview2");
function hideListViewToolbarItems()
{
/// <summary>
/// </summary>
var menuItem;
var menuItemName;
var menuItemIndex=-1;
var menuItemNames=new Array("edit in datasheet",
"open with windows explorer",
"connect to outlook",'export to spreadsheet','view rss feed','alert me'
,"create column","settings:create view","list settings",
"document library settings","all documents",
"all items","modify this view",
"view:create view","new document",
"new item","new folder","upload document",
"upload multiple documents","aaa","explorer view","testview1","testview2","testview3");
var menuItems = new Array("EditInGridButton",
"OpenInExplorer","OfflineButton",
"ExportToSpreadsheet","ViewRSS",
"SubscribeButton","AddColumn",
"AddView","ListSettings","ListSettings","DefaultView",
"DefaultView","ModifyView","CreateView",
"New0","New0",
"NewFolder","Upload","MultipleUpload","View1",
"View2","View3","View4","View5");
var allMenuItems = document.getElementsByTagName('ie:menuitem');
for(var i = 0; i < hideListViewToolbarItems.arguments.length; i++ )
{
menuItemName= hideListViewToolbarItems.arguments[i].toLowerCase();
for (j=0; j < menuItemNames.length; j++)
{
if(menuItemNames[j]==menuItemName)
{
menuItemIndex = j;
break;
}
}
menuItem=menuItems[menuItemIndex];
for (var l = 0; l < allMenuItems.length; l++)
{
if(menuItemName.indexOf(":")!=-1)
{
menuItemName = menuItemName.split(":")[1];
}
if (allMenuItems[l].id.indexOf(menuItem)!=-1
&& allMenuItems[l].text.toLowerCase() == menuItemName)
{
// For FireFox Compatibility
var parentNodeOfMenuItem = allMenuItems[l].parentNode;
parentNodeOfMenuItem.removeChild(allMenuItems[l]);
break;
}
}
}
}
</script>
Der Code stammt ursprünglich von dieser Seite: www.codeproject.com
P.S.: Auf Basis dieses Codes ist es auch möglich die Einträge unter "Actions" und "Settings" in der Toolbar zu verstecken.
Globale und einheitliche Navigation in SharePoint
In SharePoint (hier Version 2007) wird die Navigation innerhalb einer Site Collection definiert. In einem Umfeld mit mehreren Site Collections hat das folgende Nachteile:
- Die Navigation ist inkonsistent (die aktuelle Site Collection wird zum Beispiel immer an erster Stelle angezeigt)
- Der Administrationsaufwand erhöht sich pro zusätzlicher Site Collection
- Der Aufwand um die Navigation über alle Site Collections einheitlich zu pflegen ist immens
Eine schlanke Lösung für diese Problematik besteht in der Ausnutzung des Delegate-Prinzips: Hierbei wird das Objekt, welches die Navigationsdaten liefert, dynamisch überschrieben. Eine Lösung besteht aus den folgenden Bestandteilen:
- Ein Feature auf Web Application-Ebene, welches einen neuen Navigation Provider registriert: Dieser verwendet als Basis für die Navigationsstruktur eine xml-Datei
- Ein Feature auf Web-Ebene, welches für das dynamische Überschreiben des Navigations-Objekts sorgt
Vorteile einer solchen Lösung:
- Die einheitliche Navigation muss nur noch an einer zentralen Stelle (in der xml-Datei) gepflegt werden
- Anpassungen an Masterpages, Themes etc. sind nicht notwendig
- Per Aktivierung/Deaktivierung des Web-Features kann jederzeit von der alten auf die neue Lösung umgeschaltet werden
- Die Lösung kann sowohl im Umfeld WSS 3.0/SharePoint Server 2007, als auch im Umfeld SharePoint Foundation/SharePoint 2010 angewendet werden
