Obwohl ich die DiggBar anfangs als äußerst positiv und angenehm empfunden habe, gab es genügend Leute, meist Suchmaschinen-Optimierer, die diese Neuerung alles andere als einfach akzeptieren wollten. Das Problem an Diggs Short-URL-Service war schnell identifiziert: Anstatt wie üblich mit einem 301-Redirect die verkürzte Adresse sofort auf die Ursprungsquelle weiterzuleiten, liefert Digg den HTTP-Statuscode 200 aus und bindet die Quelle in einem Frame ein. Suchmaschinen erkennen dadurch den Zusammenhang zur eigentlichen Seite nicht und werden auch nicht auf diese weitergeleitet. Auf der anderen Seite ist dies die einzig praktikable Möglichkeit die DiggBar zu realisieren. Um eine größeren Aufstand der Webmaster zu vermeiden, hat sich Digg nun dazu entschlossen eine Kompromisslösung einzugehen:
Nicht auf Digg angemeldete User bekommen nach der Änderung keine DiggBar mehr angezeigt und werden direkt (301-Redirect) durch die verkürzte URL weitergeleitet. Für alle Digg-User bleibt alles beim Alten. Sie bekommen weiterhin die DiggBar – immerhin war die DiggBar seit dem Launch für ca. 45 % der abgegebenen Diggs verantwortlich. Ganze 25 % haben neue Inhalte und Seiten entdeckt, die sie anderenfalls nicht bemerkt hätten – so Digg’s John Quinn in einem Beitrag auf dem Digg-Blog. Natürlich gibt es auch weiterhin die Möglichkeit für registrierte User, die DiggBar zu deaktivieren.
Mit diesem Schritt hat der Social-News-Gigant ein weiteres Mal bewiesen, dass User-Feedback auch wirklich bei den Entwickler ankommt. Es ist nahezu eine Win:Win:Win-Situation entstanden: Die Content Provider sollten durch die Änderungen weitgehend zufrieden sein, die User bekommen weiterhin die speziellen Funktionen der DiggBar und Digg profitiert von der gesteigerten User-Interaktivität. Diese Entwicklungs-Weise entspricht ganz klar der Unternehmenskultur des kalifornischen Unternehmens. Wie Kevin Rose, Mitbegründer von Digg, schon öfters durchklingen lassen hat, ist es für ihn persönlich wichtig, ein Produkt sowie die Änderungen in einer schnellen Taktfrequenz zu veröffentlichen, genau auf die Reaktionen bzw. das Feedback zu hören und dann prompt Anpassungen durchzuführen. „Release early, release often and reiterate“. Diese Praktik haben wir damals schon bei den Kommentaren gesehen und sie kommt auch heute wieder bei der DiggBar zum Einsatz. Vielleicht sollten mehr Web-Entwickler diesen Entwicklungsstil adaptieren, um nicht in der Konkurrenz unter zu gehen.