SharePoint Framework Teil 2: Neue Herangehensweise – Neue Möglichkeiten

Im ersten Teil der Blogreihe zum Thema “SPFX” haben wir uns bereits mit den Neuerungen, die mit dem SharePoint Framework Einzug halten, befasst. In diesem Artikel möchte ich Ihnen die daraus resultierenden neuen Möglichkeiten vorstellen.

Prototyping in SharePoint

Ja, Sie haben richtig gelesen. Prototyping, und das direkt in SharePoint – in vorherigen Versionen undenkbar! Der Aufwand wäre in keinster Weise in Proportion zum Nutzen gestanden. Was hat sich geändert?

Durch den Einsatz der Modern Themes, Modern WebParts und den UI-Fabric React-Components haben wir ab sofort eine Möglichkeit, um Prototypen direkt in SharePoint zu bauen. Das bedeutet, dass wir beispielsweise eine Portalseite mit angemessenem Aufwand direkt in SharePoint umsetzen und als high fidelity Prototyp verwenden können. So ein Prototyp kann sich im Laufe der Umsetzung dann auch zum Endprodukt entwickeln.

Wäre da ein Klickdummy oder Screendesign nicht besser geeignet?

Jede Methode hat ihre Vor- und Nachteile. Welche am besten geeignet ist, unterscheidet sich auch ganz nach Projekt. Das Prototyping direkt in SharePoint ist nur ein Weg um ans Ziel zu gelangen. Jedoch ist es ein Weg, den man sich mit Einzug des neuen SharePoint Frameworks unbedingt anschauen sollte. Die Vorteile dieser Vorgehensweise liegen auf der Hand. Um nur einige davon zu nennen:

• Prototyp kann sich zum Endprodukt entwickeln
• Frühes Einbinden von Nutzergruppen (Usability-Tests, evtl. verbesserte User-Experience)
• Kommt dem Endprodukt am nächsten
• Besonders gut für ein iteratives Vorgehen (z. B. Scrum), da sich Bestandteile von Modulen über die Zeit ändern können
• Konzentration auf die Anforderung: Man beginnt mit den Mindestanforderungen und kann diese weiter ausbauen

Qualität vs. Quantität

Was meine ich damit? Während der Umsetzungsphase bis hin zu einer Lösung spielt das Verhältnis von Qualität zu Quantität immer eine sehr große Rolle. Bei hohem Zeitdruck und entsprechend großen Ambitionen leidet oftmals der hohe Standard, den man sich vorher gesetzt hat. Damit meine ich nicht die Qualität der Umsetzung! Gemeint ist die Qualität im Sinne der Anforderungserfüllung der jeweiligen Lösung. Man muss hier in vielen Fällen den einfachen, schnellen Weg gehen – obwohl der längere, aufwendigere Weg die Bedürfnisse viel besser bedienen würde.

Wie kann uns das SharePoint Framework dabei helfen?

Wie bereits mehrfach erwähnt bekommen wir mit der neuen Entwickler-Spielzeugkiste jede Menge Tools an die Hand, um User-Interfaces schneller zu realisieren. Die Umsetzungszeit einzelner Module verringert sich, da es für die meisten Anwendungsfälle bereits fertige Komponenten gibt. Denken Sie beispielsweise an ein einfaches Tab-Menü. Sie verschwenden keine Zeit die Grund-Funktionen des Menüs zu entwickeln. Die Komponente kann diese bereits erfüllen.

Würde das nicht bedeuten, dass wir weniger Zeit und somit auch weniger Geld für eine Intranet-Lösung benötigen?

Das stimmt nur zum Teil. Natürlich kommt die Nutzung der fertigen Komponenten der Zeit und somit evtl. auch dem Budget zu Gute. Damit laufen Sie aber früher oder später wieder in das eigentliche Dilemma: Qualität vs. Quantität. Denn obwohl Sie weniger Zeit in die einzelnen Elemente investieren müssen und somit wahrscheinlich auch an Budget sparen, haben Sie noch nicht an der Schraube „Qualität“ gedreht. Was jedoch jetzt zur Verfügung steht ist eine Zeitspanne, um sich umfassend mit der Qualität auseinanderzusetzen.

Denken Sie also nicht in einfachen Dimensionen wie Zeitersparnis = kostengünstig. Die richtige Denke ist meiner Meinung nach Zeitersparnis = mehr Zeit für bessere Qualität. Was ist damit konkret gemeint? Wenn Sie die Möglichkeit haben, eine Anforderung in Ihren Grundbedürfnissen schneller/einfacher zu erfüllen, können Sie sich tiefergehende Gedanken um das jeweilige Modul machen. Erfüllt das, was ich gerade gebaut habe, wirklich meine Nutzeranforderung?

Holen Sie sich Nutzerfeedback während der Umsetzung

Fragen Sie Ihre Nutzer. Wenn die Grundanforderungen des Moduls bereits in kurzer Zeit umgesetzt wurden, nutzen Sie die Zeitersparnis um sich die Rückmeldung Ihrer Anwender einzuholen. Lassen Sie das Feedback in die Weiter- bzw. Neuentwicklung des Moduls einfließen. Arbeiten Sie Ihre Lösung in Iterationen zum Endprodukt aus, um ein Modul zu erhalten, dass von Ihren Nutzern verstanden und verwendet wird.

Denn nichts wäre frustrierender als ein Endprodukt, dass zwar eine Menge Geld gekostet hat, die Nutzer aber nicht zufrieden stellt. Oder noch schlimmer – es wird aus diversen Gründen gar nicht erst verwendet.

Nutzen Sie die gewonnene Zeit um Methoden wie den User Centered Design Process anzuwenden, um die Usability des Produktes, und somit hoffentlich auch die User Experience zu verbessern.

Ich hoffe, ich konnte Ihnen mit diesen Einblicken in die Entwicklung des SharePoint Frameworks die vorhandenen neuen Möglichkeiten etwas näherbringen. Durch die ständige Weiterentwicklung werden wir hier in Zukunft noch mehr Möglichkeiten haben, effektive Intranets für Sie umzusetzen. Wenn Sie Fragen zu SPFX haben, sind wir natürlich gerne für Sie zu erreichen.