Verbesserte Suchfunktion

Ich habe noch einmal die Suchfunktion überarbeitet. Der Benutzer soll möglichst schnell gesuchte Informationen finden, weshalb die Suchfunktion ein zentraler Bestandteil der Seite werden wird.

serps

Die Suchergebnisse lassen sich nun nach der Anzahl an Testberichten und Fragen, der Produktbewertung (Punktzahl) und der Aktivität (=Anzahl von Aktionen in einem bestimmten Zeitraum) sortieren. Die Suchergebnisse enthalten bewusst keine Paginierung, da erfahrungsgemäß diese von Nutzern prinzipiell nicht genutzt wird. (~98% der Google Nutzer schauen sich nicht die zweite Seite an).

Für eine höhere Benutzerfreundlichkeit wurdne zudem die Suchvorschau bzw. die Suchvorschläge verbessert. Neben dem Produktnamen werden nun ein kleines Produktbild, sowie die Produktkategorie angezeigt. In Zukunft werden hier ggf. auch weitere Informationen z.B. zur Produktbewertung gezeigt.

screendropdownsearch

Kurz vor der Fertigstellung

Die größte Arbeit ist geschafft. WikiTests hat alle grundlegenden Funktionen implementiert. Zuletzt sind folgende Dinge hinzugekommen:

  • Form-Validierung (Überprüfung auf gültige Eingaben)
  • Einbindung von Schema.org Produkt- und Review-Daten
  • hinzufügen neuer Produkte
  • neues Kategoriemenü
  • Inline-Bearbeitung von Fragen, Testberichten und Antworten
  • Admin-Funktionen
  • neue Gestaltung der Mitglieder-Seiten
  • Echtzeit Aktivitäten-Log
  • Behebung diverser Bugs

Ich möchte jetzt so schnell wie möglich an den Start gehen und eine initiale Datenbank aufbauen. Gelplante Dinge wie der Bildupload in Testberichten und die Verwendung von Markup-Editoren sind erst einmal zurückgestellt.

Die Technik hinter WikiTests

Bisher: WordPress, Buddypress, Php

In der ersten Version wurde WikiTests basierend auf WordPress, Buddypress und eigenen in Php und Javascript entwickelten Erweiterungen programmiert. WordPress ermöglicht in Kombination mit Buddypress das schnelle Aufsetzen von Community getriebenen “Social-Network” Seiten. WordPress ist das derzeit am häufigsten verwendete Content Management System und Alternativen zu Buddypress in Form von “vorgefertigten Softwaremodulen” gibt es im Prinzip nicht.
Da sowohl WordPress, als auch Buddypress quelloffen und damit editierbar sind, wurde diese Lösung als optimales Fundament angesehen. Auf diesem sollten die gewünschten Funktionen von Wikitests dann in Php und Javascript programmiert werden.

Dennoch hat sich mit zunehmender Entwicklungszeit gezeigt, dass die in WordPress und Buddypress vorhandene Funktionalität nur zum geringen Anteil die Anforderungen von WikiTests erfüllt. Zu oft musste die “Holzhammer-Methode” angewendet werden um gewünschte Funktionen zu implementieren. Hierdurch wurde der Quellcode zunehmend unstrukturierter und schlechter erweiterbar. Auch mussten immer mehr Kompromisse bezüglich der Ladegeschwindigkeit  der einzelnen Seiten gemacht werden. Auch der Vorteil von Php, schnell Programmierer beispielsweise günstig aus Indien zu zur Unterstützung zu bekommen, konnte nicht überzeugen. Also musste eine neue, saubere Lösung her.

Nun: ASP.NET, Typescript, SignalR

Ein Grundgedanke bei der Entwicklung war von Anfang an die Administration der Datenbank und die Moderation der gesamten Webseite über eine Winforms Anwendung zu realisieren. “Wieso das trotz der vermeintlichen redundanten Oberflächenentwicklung?” wird der eine oder andere fragen.

Große Datenmengen lassen sich nur mit Hilfe von individuell angepasster Software gut managen. Nur durch eine individuelle Entwicklung lässt sich eine  hohe Geschwindigkeit, eine hohe Benutzerfreundlichkeit und optimale Bedienbarkeit durch beispielsweise Multi-Monitor-Betrieb erreichen. Mit Hilfe von OR-Mappern (Entity Framework), .NET und Visual Studio  lassen sich übrigens vergleichsweise schnell und unkompliziert individuelle datenbankbasierte Anwendungen realisieren.

Wenn die Basis auf Seiten der Administration auf .NET aufbaut, warum dann also nicht gleich auch die Webseite in .NET entwickeln? Dann hat man sogar noch einen Teil der (vermeintlichen) Redundanz vermieden, da die jeweiligen Datenmodelle quasi identisch sind. Große Nachteile, bis auf gewisse Halbkentnisse in ASP.NET MVC und Windows-Webserver Administration, konnte ich nicht identifizieren. Außerdem ist meinen Erfahrungen nach Softwareentwicklung in der Microsoft-Welt (.NET, Visual Studio, EF, Nuget…) im Vergleich zur Java-Welt (Eclipse, Netbeans, Hibernate, Maven…) im allgemeinen einfacher und schneller zu realisieren, worüber ich ggf. noch mal einen separaten Blogpost veröffentlichen werde. Nur soviel: Man muss nicht nur einzelne Aspekte wie Nuget und Maven vergleichen sondern den gesamten Prozess und das Zusammenspiel der einzelnen Tools und Bibliotheken vergleichen und da hat IMHO Microsoft die Nase vorne.

Da ich nicht nur die beste technische Basis nutzen wollte, sondern mit jedem Projekt dazulernen möchte, war die Sache also klar: WikiTests wird auf Basis von ASP.NET MVC entwickelt.

Die Basis ASP.NET (mit der Sprache C# natürlich) hat sich dann auch zunehmend als bessere Wahl im Vergleich zu Php (und anderem Skriptsprachen) herausgestellt. Unter anderem existiert hierfür auch eine einfach handzuhabende Bibliothek namens SignalR. Diese ermöglicht es in “Echtzeit”, d.h. ohne neuladen der Html-Seite Updates vom Server aus zu “pushen”. Bei aktuellen Browsern werden dazu Sockets verwendet (hohe Performanz!) und bei älteren Browsern auf alternative Techniken zurückgegriffen.
Eine weitere schöne Technik aus dem Hause Microsoft ist Typescript. Diese Programmiersprache ermöglicht ähnlich wie Googles Dart OOP in Javascript zu übersetzen. Im Gegensatz zu Dart kann Typescript aber auch mit Javascript kombiniert werden. D.h. man kann auch alle bereits vorhandenen Javascript Bibliotheken in Typescript nutzen. MS nennt daher Typescript “Superset of Javascript”.

Zukunft: Node.js?

Eigentlich gefallen mir Skriptsprachen zur Realisierung von größeren Softwareprojekten generell nicht. Man wird einfach viel schneller dazu verleitet unsauberen Code in Skriptsprachen zu produzieren. In Skriptsprachen merkt man Probleme häufig erst zur Laufzeit. Das nervt einfach.
Javascript mag ich als BVB-Fan so viel wie Schalke 04. Aber da es keine Alternative zur clientseitigen Programmierung gibt, bleibt einem nichts anderes übrig, als sich auch mit Javascript zu befassen. Dank immer schneller werdenden Browsern und recht nützlichen Javascript-Bibliotheken wie JQuery sollte man sich Javascript sowieso näher anschauen. Gefühlt verbreitet sich Javascript schneller als alle anderen Programmiersprachen zusammen. Die Leute wollen einfach keine Software mehr installieren. Computer=Internet=Browser: so scheint für viele Anwender die Gleichung auszusehen.

Da nun offenbar der Browser das OS der Zukunft ist (Stichwort “SaaS” für die BWLer und Buzzword-Liebhaber”), wird Javascript deutlich an Bedeutung zuzunehmen. Warum also nicht eigentlich auch auf dem Server Javascript verwenden? Genau das haben sich wohl die Entwickler von Node.JS gedacht und gleich einen Webserver für Javascript programmiert. Der Vorteil liegt auf der Hand: eine Sprache für Server und Client. Keinen redundanten Code mehr, Juhuu!

Mit Typescript ist Javascript gar nicht mehr so grausig, wie man vermuten mag. Im Prinzip kann man damit statisch typisierte OOP clientseitig ohne große Kompromisse realisieren. Die schwerwiegenden Nachteile aus Entwicklersicht sind damit zumindest zum Teil wettgemacht. Die Zukunft von WikiTests könnte daher auch auf Serverseite in Javascript liegen.
Da aber Typescript noch nicht all zu ausgereift ist und ich auf das “MS-Toolset” VS, EF, Winforms verzichten möchte, bleibe ich erstmal auf Serverseite bei ASP.NET.

Was hab ich vergessen?

Bisher hab ich noch nichts zur Datenbank und Webserver gesagt. Um es kurz zu machen: für ASP.NET ist MS SQL obligatorisch. In der Verwendung einer NoSQL-Datenbank  wie CouchDb oder Raven konnte ich keine Vorteile für Wikitests erkennen.
Als Server wird Azure eingesetzt. Ich vermute einfach, dass sich Azure als Cloudlösung besser in die Microsoft-Welt integriert, als Amazons oder Googles Lösungen. Die Administration ist jedenfalls sehr einfach, so dass ich mich nicht näher mit den Alternativen beschäftigt habe. Als Bizspark-Partner bekomme ich dort sowieso eine Grundfunktionalität kostenlos.

Form follows function

Das Design der Seiten von WikiTests soll sich ausschließlich an der Funktionalität, der Usability und an der Ladegeschwindigkeit ausrichten. Zu den jeweiligen Punkten gibt es ganze Bücher und sogar eigene Forschungsbereiche und Lehrstühle an Universitäten. Ich versuche knapp zusammenzufassen, worauf bei der Entwicklung WikiTests am meisten Wert gelegt wird. Hierbei folgt der Gedanke dem Prinzip “form follows function”.

Der Begriff form follows function (auch Form folgt Funktion oder FFF, wörtl. (Die) Form folgt (aus der) Funktion) ist ein Gestaltungsleitsatz aus Design, insbesondere Produktdesign und Architektur. Die Form, die Gestaltung von Dingen soll sich dabei aus ihrer Funktion, ihrem Nutzungszweck ableiten. (Wikipedia)

Gutes Aussehen oder eine grafisch aufwendige Gestaltung von Internetseiten steht ihrer Benutzbarkeit in der Regel im Wege. Der eigentliche Zweck (Abruf von gesuchten Informationen zu Produkten) soll bei WikiTests im Vordergrund stehen. Hieraus ergibt sich dann von selbst die Anordnung und Gestaltung von Seitenelementen. Unnötige Mausklicks und sogar das reine Verschieben des Mauszeigers auf dem Bildschirm, sollen auf ein Minimum reduziert werden.

In der Regel sind die häufig abgerufensten Seiten die eher “langweilig” gestalteten, aber hochinformativen Seiten.

Die erste grobe Gestaltung lehnt sich an den hochfrequentierten, sehr erfolgreichen Frage/Antwort-Seiten von Stackexchange (Thematik überwiegend im technischen Bereich, derzeit rund 3mio aktive Mitglieder)  an. Um die Usability (und User Experience “UX”) weiter zu verbessern werden in Zukunft umfassende Nutzungsstudien angelegt und ausgewertet.

Intention von WikiTests

Hallo Welt, hallo Produkttester und Anwender,

WikiTests soll eine Community getriebene Internetseite rund um Produkttests und Produktfragen sein. Warum noch eine Seite? Ganz einfach: weit verbreitete Seiten wie idealo.de oder guenstiger.de haben in erster Linie das Ziel möglichst viel Geld einzunehmen. In Folge dessen leidet darunter die Unabhängigkeit. Produktbewertungen fallen häufig zu positiv aus und es stehen die Produkte im Mittelpunkt, welche der Internetplatform am meisten Einnahmen bescheren.

WikiTests muss sich zwar auch durch Werbung refinanzieren, doch soll dies nur mit dezenter, nicht im Mittelpunkt stehender Werbung realisiert werden.

Im Mittelpunkt steht in jedem Fall der Nutzer – sowohl was die die Informationsdarstellung, als auch die Benutzerfreundlichkeit der Internetseite betrifft. Nicht der zahlende Werber bestimmt, welche Produkte vorne stehen, sondern der Nutzer!

Um Fake-Bewertungen von Firmen zu verhindern, wird ein spezieller Algorithmus entwickelt, welcher diese nahezu unmöglich macht.
Da die Seite Community getrieben sein wird, werden außerdem durch mit Hilfe der Mitglieder Fakes enttarnt!

Soviel zur ersten Intention….

Gruß

Daniel