15.9.2009

Netzwerkprodukte (25) - Userinterfaces

(Themenanfang)

Seit Anfang dieses Jahres gibt es Cubase 5 - die zweite „5”, nachdem bereits vor knapp 10 Jahren das letzte, fünfte Update von Cubase VST herauskam, und Steinberg mit einem kompletten Rewrite der Code-Basis endlich soweit war, daß man den mittlerweile arg in die Jahre gekommenen Vorläufer ersetzen konnte. Übrig blieb nur der Name und der (grobe) Funktionsumfang einer Software, die erstmals 1989 erschienenen war.

Eine Softwarefirma kann letztlich nur Geld verdienen, wenn sie neue Features entwickelt - entweder in Updates eines bereits existierenden Programms, oder indem sie mit einem komplett neuen Programm heraus kommt, das eine Marktlücke schließt. Letzteres ist in den letzten zehn Jahren kaum jemandem gelungen. Geschäfte macht man heutzutage nahezu ausschließlich mit Updates.

Die Erweiterungen und Verbesserungen von Cubase in mittlerweile zwanzig Jahren verdanken sich Einfällen aus Steinbergs Entwicklungsabteilung, aber auch Ideen von außen. Solche äußeren Einflüsse bestanden zu einem guten Teil aus den Vorgaben der Konkurrenz, die im Lauf der Jahre immer wieder Features erfunden hatte, die wir nachlegen mußten (wobei es über viele Jahre in den allermeisten Fällen andersherum lief - das komplette Konzept von Cubase ist ja mittlerweile Standard für sämtliche Software-Sequenzer, und wurde, nun: flächendeckend geklaut). Mindestens ebenso oft gab es aber Vorgaben, Wünsche und Ideen unserer User.

Das Verhältnis zwischen Programmierern und Usern ist dabei durchaus problematisch. Manche Wünsche, die von außen, aus der Sicht der Anwender betrachtet, auf der Hand liegen und vermeintlich mit wenig Aufwand zu implementieren sind, erweisen sich regelmäßig als unvereinbar mit dem technischen Design. Gelegentlich müßte man einen größeren Codebereich komplett neu implementieren, nur um einer trivialen Anforderung gerecht zu werden. Umgekehrt gibt es aber auch Anwendungen, die im Grunde eher simpel zu implementieren wären, wenn die User nur mitteilen würden, was sie mit der Software erreichen wollen, statt sich ein konkretes Userinterface auszudenken und Dinge umständlich zu beschreiben, die sich dann letztlich nicht in das bestehende Programmdesign integrieren lassen.

Dann gibt es die Prioritäten, die die Kunden setzen: das Programm soll stabil laufen - an neuen Features habe man kein Interesse, zumindest solange die Bugs nicht beseitigt sind. Das ist ein Lied, das man über die Jahre wieder und wieder im Support zu hören bekommt. Dabei ist es aber ebenso allgemeiner Konsens, daß Maintenance-Updates kostenlos erhältlich sein müssen. Erst für neue Features ist man bereit, auch zu zahlen[1] - und selbst, wenn es sie dann gibt, wird oft noch ausgiebig darüber diskutiert, ob sie den Upgradepreis von bspw. €199,- wert sind, oder ob nicht eher €99,- angemessen wären.

  1. [1] Dieser Widerspruch läßt sich m.E. nicht einmal mit kostenloser (Open-Source- oder Freeware-) Software auflösen, denn dort gibt es allenfalls eine moralische Verantwortung der Entwickler, auftretende Bugs zu beseitigen, nicht aber einen ernsthaften Anspruch von Seiten der User - erst recht nicht, die Bugfixes in einem angemessenen Zeitrahmen nachzureichen.

[Wird fortgesetzt.]

(Kommentarfunktion z.Zt. deaktiviert.)