Nominierte Kommentare der zweiten Spielrunde

Tobias Meyer zum Artikel Checkins bei Facebook, Gowalla, Foursquare und Qype: Toll oder sinnlos?

Privatsphäre hin oder her… Aus unternehmerischer Sicht ist diesen Plattformen nur Positives zu entnehmen! Nie zuvor war es so einfach und unkompliziert, Informationen über das Kundenverhalten zu generieren und intelligente Aktionen ins Leben zu rufen. Solange die Menschen bereit sind, diese Informationen kostenlos und freiwillig zur Verfügung zu stellen, sollte man sich dem Geo-Dienst als Marketinginstrument nicht versperren!

Betrachtet man die Verwendungszwecke, ist meiner Meinung nach jedoch zwischen kleinen und großen Unternehmen zu unterscheiden. Für große Unternehmen, die national oder global agieren, ist es weniger interessant, wie oft Herr Müller seinen Kaffee in einer bestimmten Filiale schlürft. Sie betreiben ohnehin weiterreichende und professionellere Marktforschungen, deren Auswertungen qualitativ nicht mit den Ergebnissen aus Geo-Diensten vergleichbar sind. Hierbei steht nicht das Individuum, sondern eine größere Gruppe von Menschen im Mittelpunkt der Untersuchungen. Es ist also davon auszugehen, dass es auch in Zukunft für diese Unternehmen nur schwer möglich sein wird, der Anonymität zu entfliehen und einen „User-generated-Service” zu entwickeln. Dennoch können die Unternehmen sehr gut von den Plattformen profitieren, indem sie diese für attraktive Coupons-Aktionen nutzen.

Bei kleinen lokalen Unternehmen hingegen steht der Aufwand für die Entwicklung und Promotion solcher Aktionen nicht im Verhältnis zu dem Nutzen, der daraus gewonnen werden kann. Hier sehe ich den Nutzen, insbesondere vor dem Hintergrund, dass sich diese Unternehmen größtenteils keine Marktuntersuchungen leisten können, vielmehr darin, kostenlose Informationen über das Kundenverhalten zu erhalten. "Wer ist, wie oft und wie lange, zu welchen Zeitpunkten anwesend?" reicht aus, um gezielt auf Kunden zuzugehen und eine persönliche Beziehung aufzubauen.

Soviel zum jetzigen Zeitpunkt. Perspektivisch gesehen werden diese Plattformen jedoch nicht für sich alleine bestehen können. Gut zu beobachten ist das in meinem Studiengang "Medien- und Kommunikationswirtschaft/Digitale Medien". Meine Kommilitonen sind zu 99% Digital Natives und zu 99% Early Adopters. Viele von Ihnen verwendeten Twitter und testeten sich bei Foursquare aus. Mittlerweile werden die Mitteilungen fast ausschließlich über Facebook versendet und der Aufenthaltsort über Facebook-Places angegeben. In Zukunft wird sich die Nutzung also meiner Meinung nach entweder auf die großen Player wie Google oder Facebook beschränken, die bereits jetzt die parallele Verwendung mehrerer intelligenter Funktionen ermöglichen, oder es werden sich Plattformen durchsetzen, die durch die Vereinigung von Social-Networks, Geo-Diensten und Microblogging-Anbieter Synergieeffekte schaffen!

Richie zum Artikel Texte sollten im Wiki und nicht in Word oder in E-Mails erstellt, geteilt und bearbeitet werden

Die Argumentationsführung in diesem Artikel ist messerscharf, aber:

Menschliches Kommunikationsverhalten ist nicht einfach eine dumme Gewohnheit oder Unachtsamkeit, der mit Belehrungen beizukommen ist.
Kommunikation ist eines der ersten Dinge, die der Mensch als Säugling lernt. Derart tief verwurzeltes Verhalten lässt sich nicht einfach durch Aufklärung oder Argumentation korrigieren.

Eine der wichtigsten Naturkonstanten in der Kommunikation ist die Adressierung. Natürlicherweise hängen Form und Inhalt einer Äußerung davon ab, an wen sie gerichtet ist. Die Kommunikation mit einer anonymen “Cloud” ist eine Errungenschaft der IT-Technik. Sie widerstrebt dem natürlichen Kommunikationsverhalten, weshalb sie den meisten Menschen anfangs unangenehm ist. Daher wird sie, wenn möglich, zugunsten einer adressierten Kommunikation vermieden.

Obwohl ich nun die Abneigung vieler Kollegen gegenüber offenen Kommunikationsplattformen verstehe, ist nicht wegzudiskutieren, dass wir im heutigen Wirtschaftsleben an unserer Kommunikationseffizienz arbeiten müssen. Nur geht das – wie gesagt – nicht per Order Mufti, sondern per “Mitarbeiterentwicklung”, also: Berücksichtigung der menschlichen Faktoren und Einbeziehung der Menschen selbst in den Verbesserungsprozess.

Am konkreten Beispiel:

• Die Menschen einladen, ihr Kommunikationsrepertoire zu erweitern (contra sie umerziehen zu wollen).
• In kleinen Schritten voran gehen.

Z.B.: Die Wiki-Nutzung im kleinen Kreis einführen (kleines Team oder Projektgruppe). Einen geschützen Team-Bereich einrichten, der nur von Team-Mitgliedern eingesehen werden kann. Das Team in einem kurzen Workshop in die neue Technik einführen und in der Folge regelmäßig darüber sprechen (z.B. im wöchentlichen Team-Meeting).

Während die Menschen anfangs das neue Medium im vertrauten Kollegenkreis erproben, können sie sich nach ein paar Monaten gar nicht mehr vorstellen, ohne ein Wiki auszukommen, und verlassen “das Nest” freiwillig .

Cedric Weber zum Artikel Texte sollten im Wiki und nicht in Word oder in E-Mails erstellt, geteilt und bearbeitet werden

Ich würde gerne im Wiki noch einen Schritt weitergehen und wünsche mir sogar die Option zur Live-Kollaboration, wie es Google Wave oder Editoren wie Etherpad vormachen. An vielen Stellen ist diese Ad-Hoc-Möglichkeit zum gemeinsamen Entwickeln von Texten sehr hilfreich.

@Richie: Das ist sicherlich richtig, allerdings ermöglicht ein modernes Wiki auch genau diese direkte Kommunikation, es ist IMHO eher die Wiki-Ideologie der Evangelisten, welche diese Option “Verbietet”. Richtig ist aber auch, dass nach einiger Zeit umgekehrt diese Art der Kommunikationsverhalten fast als selbstverständlich vorausgesetzt wird…

Thorsten Brüggemann (//SEIBERT/MEDIA-Mitarbeiter) zum Artikel Kurz-URL-Dienst bit.ly: Libysche URLs und moralische Bedenken

Sehr spannend: Rund 9 Monate nach diesem Artikel hat Lybien einen Kurz-URL-Dienst “zensiert”, der wie Twitter (bit.ly) auf die Endung .ly gesetzt hatte. In diesem Blogartikel http://seibert.biz/ly beschreibt der erotische Kurz-URL-Dienst vb.ly von “Violet Blue” den gesamten Vorgang. Gerade auf diesen Aspekt des gesamten Datenverlustes hatte bereits Herr Schestag in seinem Kommentar vom Januar aufmerksam gemacht. -> Hellseher. 

Tanja zum Artikel SharePoint und Confluence: Vergleich, Test, Review

Als wir seinerzeit eine Software für unser Wiki suchten, prüften wir zuerst natürlich auch SharePoint und waren eigentlich ganz angetan von den Möglichkeiten. Bis wir im Rahmen der Tests das Wiki mit einigen Inhalten füllten und feststellten, dass die Darstellung der Suchergebnisse so schlecht ist, dass eine schnelle Auswahl des passenden Eintrags faktisch nicht möglich ist. Zumindest war es in der damaligen Sharepoint-Version so. Das war auch in der Tat einer der Hauptgründe, warum wir recht schnell von Sharepoint zu Confluence übergegangen sind.

E. Deichmann zum Artikel Checkins bei Facebook, Gowalla, Foursquare und Qype: Toll oder sinnlos?

Endlich stellt sich auch mal jemand diese Frage. Ich habe mich am Anfang immer bei Twitter gewundert, was für komische Tweets der eine oder andere von sich gibt. “Mayor” ... “foursquare”. Nachdem ich dann herausgefunden hatte, was es damit auf sich hat, stellte sich mir die nächste Frage: WARUM? Was interessiert es mich, wo sich gerade ein mir unbekannter Mensch, dem ich auf Twitter folge, aufhält oder in welcherm Zug er fährt.

Ich persönliche sehe keinen Nutzen für die private Nutzung. Ich finde es eher viel erschreckender, wie transparent sich die Leute machen und nun JEDER das Aufenthaltsprofil einer Person nachvollziehen kann. Und ich dachte schon, dass dies nur Payback&Co zusteht. Ich kann es als Marketing-Idee für Unternehmen nachvollziehen, um wie erwähnt die Aufmerksamkeit auf sich zu ziehen. Natürlich braucht man dafür auch die willigen privaten “Einchecker”; aber nur aus Spaß an der Ortung kann ich es nicht nachvollziehen.

Seouxindianer zum Artikel Checkins bei Facebook, Gowalla, Foursquare und Qype: Toll oder sinnlos?

Ein weiterer positiver Aspekt der Checkins ist die Möglichkeit zur Kontaktaufnahme mit Gleichgesinnten. Wenn ich an einem Ort einchecke und mir den Mayor ansehe, entdecke ich womöglich eine lokale Person, mit der ich mal über Twitter oder Facebook Kontakt aufnehmen könnte. Auch anhand seines Mayorprofils oder seiner Tipps kann ich Gemeinsamkeiten feststellen und Gesprächsstoff finden. Da man sich ja im gleichen Stadtteil aufhält, ist ein Real Life Treffen nicht unmöglich. Zur Zeit “trifft” man aber leider nur Webworker an.

Persönlich war ich vor wenigen Wochen überrascht, an einem BurgerKing zu sehen, dass vor einer Stunde ein Bekannter aus einem anderen Bundesland eingecheckt hat. Kurz darauf konnte ich ihn anrufen und zur Rede stellen, warum er mir nicht Bescheid gegeben hätte, dass er in der Stadt ist. ^^

Alex zum Artikel Checkins bei Facebook, Gowalla, Foursquare und Qype: Toll oder sinnlos?

Es gibt für mich einen großen Unterschied zwischen Plattformen wie Facebook oder Twitter im Vergleich zu Diensten wie Foursquare oder Gowalla. Habt Ihr Euch schon einmal gefragt, warum sich Unternehmen mit Twitter theoretisch befassen, aber trotzdem nicht aktiv werden? Ein Account muss selber angelegt, gepflegt und auf Dauer betreut werden. Dafür braucht man einen fähigen und handlungsberechtigten Mitarbeiter. Und der kostet schlicht Geld, von dem der Unternehmer nicht konkret weiß, ob sich die Investition lohnen wird.

Bei Location Based Services ist das ein anderes Spiel. Das Unternehmen muss nicht von Anfang an aktiv werden und ständige Pflege betreiben. Jeder Nutzer von z.B. Foursquare kann einen Check-In einrichten. Das heißt ein Unternehmensaccount wird (threoretisch) irgendwann so oder so angelegt.

Daher gibt es für mich drei Stufen bei der Nutzung von LBS (im speziellen Foursquare) im unternehmerischen Bereich.

1. Passiv: Ich beobachte hin und wieder was passiert. Lerne darüber vielleicht sogar Stammkunden kennen.
2. Aktiv: Ich lege einmalig einen Check-In an und hinterlege mit Tipps wertvolle Infos über mein Unternehmen.
3. Interaktiv: Ich kommuniziere mit Nutzern, biete z.B. Bonus-Deals an und stelle durch mein Bemühen eine persönliche Bindung zu Kunden her.

Jedes Unternehmen – egal ob B2B, B2C oder welche Branche – kann sich in einem dieser Punkte wiederfinden. Wenn es ein Beispiel gibt, bei dem das gar nicht zutrifft, freue ich mich auf Feedback.

Armin Dittrich zum Artikel TaskDock für Confluence: Schlankes Aufgabenmanagement und professionelle Wiki-Redaktion

Ein sehr interessanter Ansatz, den das TaskDok-Plugin ermöglicht. Die Ausführungen im Video scheinen mir sehr plausibel und nachvollziehbar. Häufig ist es ja so, dass Mitarbeiter am Anfang hoch motiviert sind, Wiki-Bereiche neu zu erzeugen und sich als Bereichsmoderator zu bekennen.

Nach meiner Erfahrung werden aber auch hoch motivierte Mitarbeiter schnell vom Alltag eingeholt – und ihr Ziel, mithilfe von Wikis eine Verbesserung ihres Informations- und Wissensmanagements zu erreichen, gerät langsam ins Hintertreffen. Die “Wiki-Gärtner” können in einem solchen Fall aber derzeit nur per E-Mail oder in persönlichen Gesprächen Anregungen für die Weiterentwicklung geben. Dies erzeugt aber oft zusätzlichen Zeitstress bei dem betroffenen Mitarbeiter …

Wir haben in unserem Firmenwiki zwei Feedbackfunktionen zusätzlich etabliert. Die eine bietet die Möglichkeit, eine Seite an den Bereichsadmistrator zu “melden” bzw. zum Löschen vorzuschlagen. Beides versendet E-Mails.

Mit TaskDok könnte dies auf eine höhere Stufe gehoben werden und, insbesondere arbeitserleichternd, weil es asynchrone Kommunikation mit Bezug zu konkreten Inhalten ermöglicht. Das macht sicherlich nicht im gesamten Firmenwiki Sinn, aber in einzelnen Bereichen z.B. für geschützte Wikibereiche, die vom Wiki-Gedanken abweichend nicht mit freier Kollaboration erarbeitet werden sollen.

… ich werde das Plugin weiter verfolgen.

Stefan Beitz zum Artikel Warum Projektmanagement und Qualitätssicherung werthaltige Leistungen sind

Sie haben Recht – neben den oben genannten Aufgaben, die erfahrende Projektmanager hervorragend wahrnehmen, ist ein Projektmanager für den Kunden eine absolute Vertrauensperson. Nur wenn ich den Eindruck habe, dass es dem Projektmanager ums Projekt geht und darum, die Kundenwünsche 120% zu erfüllen, bin ich bereit Geld in die Hand zu nehmen und gleichzeitig einen Großteil der Kontrolle (an den Projektmanager und sein Team) abzugeben. Denn manchmal braucht es dieses Vertrauensverhältnis, um schnelle Entscheidungen zu treffen, die – aus welchen Gründen auch immer – nicht mit dem Kunden abgesprochen werden können.

All dies erfüllen die Projektmanager bei //Seibert/Media in außerordentlichem Maße – und zwar so gut, dass bisherige Projekte von deren Ideen, Anmerkungen, Hinweisen und Lösungsvorschlägen absolut profitiert haben.

Von daher: Projektmanagement ist eine werthaltige Dienstleistung die bezahlt werden muss – wie dies dann auf Rechnungen (auf Kundenwunsch) ausgewiesen wird, ist dabei natürlich zweitrangig.

Nominierte Kommentare der ersten Spielrunde

S. Geiger zum Artikel Wann sind Akkordeon-Effekte auf Websites sinnvoll?

Akkordeon – oder doch lieber klassisches Vinyl? Nun, diese Frage beschäftigt nicht nur die Designer – sondern auch diejenigen, die sich mit der strategischen Planung von Websites beschäftigen (hoffentlich zumindest). Mein persönliches Fazit fällt da recht klar aus: Das Akkordeon mach nur dort Sinn, wo ich viel Content habe, der nicht essentiell wichtig für den (Geschäfts-)Erfolg der Website ist. Was ich damit meine? Werfen wir einen Blick auf die gezeigten Beispiele:

Variante 1 – Shirts: Meiner Meinung nach macht der Einsatz dieser graphischen Darstellungsform hier final keinen Sinn. Ein (offensichtlich dahinter verborgenes) Shop-System so darzustellen halte ich für gefährlich. Auch vor dem Hintergrund der erwähnten SEO-Schwierigkeiten. Ein Produkt sollte zwingend seine eigene Site haben, auf der auch alle weiteren Möglichkeiten (verschieden Ansichten, Warenkorbfunktionalität etc pp) vorhanden sein sollten (Single Point of Information). Die Stärke des Akkordeon Effektes, viele Informationen auf kleinem Raum darzustellen, wird spätestens hier zur Schwäche. Außerdem halte ich sechs Reiter (mit elementaren Inhalten wie Produktansicht, Bestellung und Kontakt) für fragwürdig, da der User nicht alle Reiter sofort erfassen (und bei dem verwendeten Wording) auch nicht unmittelbar verstehen kann.

Variante 2 – News: Die “klassische” Form des Stilmittels. Und hier auch sinnvoll. Vor allem wenn der Inhalt dynamisch ist und immer die neuesten, meist geklickten Inhalte offen angezeigt werden.

Variante 3 – Produktdarstellung: Wie erwähnt – auch hier gilt: Produktdarstellung auf kleinstem Raum … mit den erwähnten SEO-Problemen … würde ich so wohl niemanden empfehlen.Fazit: Nicht jedes sexy & stylisch daherkommende Designelement macht auch tatsächlich auf jeder Site Sinn. Neben dem “klassischen Einsatz” bieten sich diese Elemente auch bei “Bühnen” auf der Starsteite an. Sei es um die jeweiligen Zielgruppen auf der Homepage in die für sie vorgesehenen Kanäle zu leiten, oder um wichtigen Dinge gleichberechtigt Raum zu verschaffen. Im Web gibt es leider viel zu viele schlechte Beispiele. Sites, bei denen die Akkordeons derart schmal, klein und an den Rand gequetscht wurden, dass man erst handgestoppte Stunden später auf sie stößt. Insofern: Augen auf bei der Hausmusik.

Tobias Helgor zum Artikel MS SharePoint als Wiki: Wenig Funktionen, nicht kompatibel:

Sehr geehrter Herr Seibert, wow, hier fliegen die Fetzen. Allerdings finde ich Ihren letzten Kommentar widersprüchlich. Sie schreiben zuerst von einem sachlichen Vergleich und danach emotional unsachlich Ihre eigene Meinung.Bei genauerem Betrachten durchzieht sich dies durch die Kommentare. Ich kenne den ursprünglichen Text nicht, aber anscheinend mussten Sie bezüglich anderen Techniken wie SQL einiges revidieren. Auch schreiben Sie, dass Sie im Prinzip keine Ahnung von SP haben und jetzt wieder, dass Ihre Tests ernüchternd sind. Was haben Sie getestet? Empirisch ist das nicht. Vor allem: Was haben Sie verglichen? Ob Sharepoint ein Wiki ist? Wird es niemals sein, denn das ist nicht der Anspruch von Sharepoint.

Wir haben ein Netzwerk mit knapp 500 Mitarbeitern und hatten anfänglich auch zuerst Confluence. Danach wechselten wir zu einer weiteren Wiki-Lösung und setzen seit Anfang letzten Jahres Sharepoint ein. Seit einem Monat Sharepoint 2010. So ist mir auch an dieser Stelle nicht ganz klar, wie Sie auf Oktober kommen. Für Firmenkunden ist Sharepoint 2010 in allen Editionen seit Juni verfügbar.

Jetzt stellen Sie sich zwei Kinder vor. Eines der beiden Kinder kauft einen Legokasten. Das andere Kind kauft etwas von Playmobil. Sicherlich kann ich zu Playmobil einiges dazu kaufen, aber es wird in seinem Manifest immer das selbe bleiben. Mit Lego habe ich am Anfang viele Bausteine bekommen und habe zunächst nichts. Ob ich jetzt daraus eine Playmobilburg baue oder ein Auto bleibt mir überlassen.Sharepoint ist nichts anderes als Lego. Es ist kein Wiki. Es ist ein riesengroßer Baukausten. Confluence mag sicherlich seine Stärke darin haben, wenn ich etwas out of the Box möchte und nur meine Wikifunktion und Plugins nutzen möchte, für einige das Richtige zu sein. So haben wir auch angefangen. Doch spätestens wenn man mehr haben möchte wird es schwierig. Das hängt von jedem Unternehmen ab.

Aber selbst wenn man den unmöglichen Vergleich 1:1 ziehen wollen würde, so wäre das mühselig. Das ist wie der Vergleich MS Office und Open Office. Ja – zugegeben, einige mögen das einsetzen, aber selbst einige Behörden, mit denen wir zusammenarbeiten, rudern davon weg, weil es nicht darum geht, was das bessere Produkt ist.Ich möchte an dieser Stelle nicht den Anschein erwecken, dass Open Office besser wäre, sicherlich hat beides seine Stärken, doch letztendlich landet jeder an dem selben Punkt. Die große Zahl der Software mit Schnittstellen wird an MS Office ausgelegt. ERP, CRM und wie sie alle heißen. Microsoft ist, vielleicht Ansatzweise von IBM abgesehen, der einzige Hersteller, der übergreifend auch in seiner eigenen Welt, sicherlich auch durch das Geld und die Monopolstellung, die hohe Verzahnung bietet.

So kann ich in Sharepoint direkt mit Office arbeiten, innerhalb des Webs und brauche keine Software auf dem Rechner dafür. Terminal Services ebenso und die Auswertungen aus Reporting-Services können ebenfalls direkt abgebildet und manipuliert werden. Egal welches Produkt, Sie haben nicht nur eine Schnittstelle, sondern auch direkte Einbindung und Interaktion.So ist es nicht verwunderlich, trotz Apple und Android Hype, dass Microsoft die besten Quartalszahlen im letzten Quartal aller Zeiten hingelegt hat durch W7, Office und Sharepoint. Entsprechend diesem Kreislauf orientieren sich auch die Hersteller. Nehmen Sie die großen Scannerhersteller, die bieten alle Connectoren zu Office und zu Sharepoint. Nehmen Sie Archivierungssoftware. Connector Windows, Sharepoint und Office. Scanner/Archivierung direkte Anbindung Confluence – großes Fragezeichen?

Ich bin kein Fan von Microsoft, aber so sieht die Realität nun mal aus. Das mag sich in vielen Jahren durch mehr Web, Cloud usw. ändern, aber der Kampf und somit der Vergleich heißt hier sicherlich nicht Sharepoint vs. Confluence. Confluence ist nun mal ein Nieschenprodukt, das seinen ganz speziellen Einsatzbereich hat. Das mag man gut oder schlecht finden. Aber so ist es nun mal.Ein letzter Satz. Implizieren Sie bitte nicht Ihre Sicht dem Anwender. Ich habe hier selbst – wie erwähnt – 500 Anwender. Denen ist das in der Regel herzlich egal. Von 500 Anwender haben aktiv tatsächlich 30 Artikel in Confluence verfasst. Wenn es hoch kam – einige mehr kommentiert. Ein weiterer kleinerer Teil hat gezwungenermaßen irgendwie mitgemacht. Natürlich wäre es toll, wenn sich jeder beteiligt und sein Wissen schreiben würde. Doch in der Realität ist oft keine große Zeit dafür oder auch kein Interesse dafür da. Andere Dinge sind wichtiger oder müssen erledigt werden.

In dem Punkt gebe ich den Wikiverfechtern recht, dass es schön wäre, wenn mehr dokumentiert werden würde, aber nicht ohne Grund ist Dokumentation in fast jedem Unternehmen ein Fremdwort. Es wird nur dokumentiert, was dokumentiert werden muß, sei es wegen eines Prozesses oder einer gesetzlichen Vorgabe. So wehrte sich am Anfang jeder gegen Confluence, danach gegen die andere Lösung und jetzt gegen Sharepoint. Nach einiger Zeit kamen die Anwender selbst und fragten, kann man das nicht in Sharepoint abbilden, da geht doch auch sonst alles. Aber auch dort gibt es Grenzen. Die mögen weiter sein durch das Legosystem als an einer anderen Stelle, aber es gibt diese auch dort.Aber eines haben die Anwender nach kürzester Zeit schnell gemerkt: Es geht nicht nur um Texte und Kommentare. Es geht um Business. Und hier gibt es Funktionen, wie Inhaltstypen, Ableitungen der Inhaltstypen, Verbundsysteme wie Metadaten, die automatisch in die Officedokumente gesetzt und entnommen werden (nicht Indizierung des kompletten Dokuments wie bei Confluence, das geht auch, sondern Qualifizierung) und Vernetzung der Information. Zugegeben, das geht nicht out of the box, aber die Techniken stecken alle drin und müssen auf das Unternehmen angepaßt werden. Aber dann ist Ihr Legohaus fertig und man möchte es nicht mehr missen.

Stefan Beitz zum Artikel Google Suggest: Manipulationsmöglichkeiten der Vorschlagslisten:

Meiner Meinung nach gibt es noch einen weiteren Grund für den Wunsch von Unternehmen, die Google-Suggest-Funktion zu beeinflussen, den ich absolut nachvollziehen kann: Da Google bei den Vorschlägen nicht zwischen generischen Suchen und “Brand”-Suchen (also Suchen nach dem Firmennamen) unterscheidet, führt das bei einigen Unternehmen dazu, dass diese durchaus wirtschaftlich bedeutende Probleme bekommen, da der Traffic quasi auf einen anderen Bieter umverteilt wird. Dadurch werden starke Marken zusätzlich gestärkt und die Konkurrenz weiter geschwächt. Ich als User bin da eher für Konkurrenz in Markt, da ich der Meinung bin, dass dadurch alle Anbieter gezwungen sind, noch besser und kundenorientierter zu arbeiten. Google scheint dies allerdings anders zu sehen: Gerade die Änderungen am Algorithmus, die in jüngerer Zeit durchgeführt wurden und wichtige Brands in den Suchergebnissen weiter stärken sollen, finde ich nur bedingt “userfreundlich”.

Diese Art des Eingreifens nimmt die Vielfalt und mir als User die freie Entscheidungsmöglichkeit.Genauso sinnlos finde ich es, dass bei Suchen wie z.B. “Apple iPod” die ersten 5, 6 Suchergebnisse nur dieselbe Domain ausspucken. Soweit ich mich erinnere war das in der Vergangenheit anders geregelt, auch hier fehlt mir dann wieder die Vielfalt an Suchergebnissen und kritisiere ich das zu starke Pushen von Marken durch Google.

Sven Heß (//SEIBERT/MEDIA-Mitarbeiter) zum Artikel Dynamische Internet-Anwendungen: GWT aus Entwicklerperspektive:

Interessanter Artikel. Ergänzend sollte man aber noch erwähnen, dass das Einbinden von externen JavaScript-Snippets häufig weit aufwändiger ist als bei der herkömmlichen HTML-Entwicklung. Wo man bei der traditionellen Entwicklung einfach nur den JS-Knoten einbindet, muss in GWT das externe JS-Snippet oft aufwändig via JSNI implementiert oder umständlich per iFrame ins Seitenlayout integriert werden. Bei der Entscheidung für GWT sollte man daher im Hinterkopf behalten, dass externe Snippets des öfteren eine Herausforderung darstellen können.

Henning Hucke zum Artikel 111 Gründe für ein Firmenwiki:

Das ist nicht gegen euch gerichtet! Geil! Etwas, das ich schon vor zehn Jahren gepredigt habe. Und damals war es eine ebenso gute Idee wie heute.Es frustriert, wenn offensichtlich vorausschauende Sachen nicht umgesetzt werden, weil Sie ein eigener Mitarbeiter vorschlägt, die zehn Jahre später mit brennender Unterstützung des Managements umgesetzt werden, weil eine externe Beratungsfirma diese Möglichkeiten anregt.

Armin Dittrich zum Artikel Die Rolle des Wikis im Unternehmen: Sie müssen Ihr Intranet nicht über Bord werfen:

Die Metapher mit einem Eimer und Steinen darin und ein Wiki als Lückenfüller ist ziemlich anschaulich. Ich habe die Erfahrung gemacht, dass es Unternehmen gibt, in denen diese Metapher hilfreich wäre um das Bewusstsein für die “Freiheit der Ergänzung vorhandener interner Informationssysteme” auf allen Ebenen zu stärken.Sogar wenn das oberste Management eine Richtung im Sinne der Metapher vorgibt, kommt es vor, dass auf anderen Managementebenen bzw. den operativen Ebenen, die Zielsetzung des Firmen-Wikis nicht in diesem Sinne interpretiert wird. Dann “driftet” ein Firmenwiki langsam ab, die Klarheit und das Verständnis zur Frage “Warum haben wir ein Wiki, was nutzt es uns?” löst sich langsam auf.Hier kann aus meiner Sicht nur eine “Instanz” eingreifen, die “korrigierende Gewalt” hat.

Eine Gruppe der Wiki-Gärtner ist da das Beste, was ich selbst erfahren habe. Denn wenigstens diese Wiki-Gärtner sollten ein gemeinsames Verständnis haben und im Sinne des Ganzen für alle Benutzer nachvollziehbar handeln können.Die “stetige Ausübung von richtungsweisenden Entscheidungen zum Wiki” ist eine der Herausforderungen im betrieblichen Alltag. Ganz nach dem Motto: “Viele Köche verderben den Brei, aber viele Köche kochen die Sachen, die wir haben wollen”. Was hilft uns, um in der Küche kein Chaos zu bekommen? Jeder denkt mit und manche helfen den Denkern!

Thomas Mahlig zum Artikel 111 Reasons why you need an Enterprise Wiki:

Als ein Kunde von mir sagte, dass er gerade keine Zeit für die Einführung eines Wikis habe, zitierte ich einen Satz von Herrn Seibert: “Ich gab Holzfällern, die Bäume mit stumpfen Sägen fällten, den Tipp, ihre Sägen zu schärfen, weil sie damit viel schneller arbeiten könnten. Aber sie sagten, dass sie dazu keine Zeit hätten, da sie ja Bäume fällen müssten …” Ein grandioser Vergleich und Grund 112.

Pipe zum Artikel Sichtweisen auf Tag-Clouds (Teil 2): Usability-Probleme und Lösungsversuche:

Habe selber verschiedene Ansätze ausprobiert, auf meiner Modellauto-Datenbank eine geordnete Wortwolke in einem sonst chaotischen Datenbanksystem nur verlinkt. Dagegen reizt die ungeordnete Tagcloud zum Ausprobieren und Spielen.

Im Feld Webseite habe ich eine URL zur Standalone-Wortwolke angegeben, die erstaunlich gut ankommt, sofern sie überhaupt gefunden wird. Letzteres ist der Haken der benutzerfreundlichen Lösung. Mittels Ajax-Frameworks und ASP/PHP kann man doch heutzutage verschiedene Modi zur Verfügung stellen und neben der Tagcloud noch ein Link zu einer Hilfeseite. Oder einfach nur ein tooltipp über der Wortwolke “vorgeschlagene Suchbegriffe” und anzeigen der Wolke durch CSS:hover, meist als CSS-tooltip bezeichnet.Wortwolke sollte immer eine Hilfe sein für Leute die nicht wissen, nach was sie suchen sollen oder die den Suchbegriff nicht kennen.

Eselsbrücke! Ob die Zielgruppe einer Website die Wortwolke annimmt oder nicht, kann man einfach testen, indem man ein Formularfeld mit “Tag vorschlagen” einbaut. Es kommt auf die Zielgruppe an … Hilfeseiten und -funktionen sind sicher nie verkehrt.

David zum Artikel Manchmal entwickelt man Software doch für sich selbst:

Software für das eigene Unternehmen zu erstellen ist oft keine schlechte Lösung: Erstmal entwickelt man hier eine Lösung, die wirklich passgenau auf die Verwendung zugeschnitten ist. Die Software ist nicht durch Features, die nicht gebraucht werden, aufgeblasen und man kann sich bei der Entwicklung auf die eigenen Abläufe und Prozesse beschränken. Vorteilhaft ist sicherlich auch der Aspekt des Kostenmanagements. Wer eine eigene Software entwickelt, entwickelt nur so viel/so weit, dass sie möglichst wenig kostet. Das ist aus unternehmerischer Sicht sinnvoll …

… aber führt dazu – und das konnte ich in einigen Unternehmen “am eigenen Leib” erfahren, dass Usability-Einbußen hingenommen werden. Gerade für Einsteiger (oder Auszubildene, Praktikanten) ist die Einarbeitung damit teilweise sehr langwierig. Selbstentwickelte Software orientiert sich selten an Nutzungsgewohnheiten, die über Windows/Mac-Software erlernt wurde, sondern geht ganz eigene Wege. Folge sind hunderte Seiten lange Manuals … wenn es sie überhaupt gibt.

Ein Nachteil kann auch sein, dass Funktionen vergessen werden. Ein konkretes Beispiel: Ich habe mal bei einer Werbeagentur gearbeitet, die mittels einer (selbstentwickelten!) Software Werbeumsätze auf Basis von AC Nielsen verwaltet hat. Mit ihr war es möglich, gewisse Daten unter bestimmten Voraussetzungen darzustellen. Soweit, so gut. Allerdings fehlte eine Funktion, um die Zusammenstellung der Merkmale nachträglich zu ändern. Es konnte sehr mühsam sein, duzende Merkmale neu anzulegen, bevor man weiterarbeiten kann.So einfach selbst programmierte Software das Leben oft macht, es gibt auch viele Nachteile. Wenn man die Software versteht, dann funktioniert sie gut und meistens auch besser, als Standardlösungen vom Markt. Aber bis dahin ist es ein langer Weg …

Niklas Becker zum Artikel Wikipedia in Unternehmen: Ja, aber nicht mit MediaWiki:

Tatsächlich haben wir Mediawiki gewählt, weil es Open Source, stabil und verbreitet ist und die Weiterentwicklung der Software langfristig gesichert scheint. Das Look-and-Feel ist dank Wikipedia allen Mitarbeitern vertraut, was Einstiegshürden womöglich senkt. Dank hoher Verbreitung ließ sich auch bei personellen Veränderungen schnell ein Admin finden, der sich mit Mediawiki auskennt.Nach einem Jahr Erprobung und Betrieb erweist sich jedoch die fehlende Rechteverwaltung als großer Nachteil. Das hat sogar dazu geführt, dass das Wiki nur für einen Teil der Organisation geöffnet wurde anstatt für alle. So kann es sein Potenzial leider nicht voll entfalten. Hat jemand Erfahrung mit der Migration von Mediawiki zu Foswiki? Ein Tool ist ja immerhin vorhanden (http://foswiki.org/Extensions/MediaWikiToFoswikiContrib).

Karl Maria Aufrath zum Artikel Dynamische Internet-Anwendungen: GWT aus Entwicklerperspektive:

Ich finde es ehrlich gesagt problematisch, wenn ein ausgereifter Java-Programmierer notwendig ist, um Frontends in HTML und JavaScript zu entwickeln. Schon für einfache Änderungen in der Oberfläche muss ein komplexes System bemüht werden (ich kenne GWT nicht, von daher kann ich über die Komplexität nur spekulieren).

Gute IDE-Unterstützung gibt es übrigens auch für HTML und Javascript, so dass die oben genannten Vorteile in dieser Richtung nicht wirklich welche sind. Auch die strikte Objektorientierung muss meines Erachtens kein Vorteil sein und schon gar kein Grund, GWT einzusetzen. Hier wird ja eine ganze Abstraktionsschicht eingeschoben, die in meinen Augen nicht immer notwendig ist. Daher sollte der Einsatz von GWT gut überlegt sein, denn man kann sich damit schnell einen Vorschlaghammer ins Haus holen, wenn ein einfacher Hammer aus der Werkzeugkiste genügen würde.

GWT-Anwendungen können nichts, was HTML und Javascript nicht auch können, nichts anderes kommt ja hinten raus. Ob sich die andere Art zu entwickeln wirklich lohnt, sollte man individuell entscheiden und sich wirklich von den Anforderungen und weniger von dem state-of-the-art leiten lassen.Dass die Barrierearmut auf der Strecke bleibt, ist übrigens schade. Oder kann man mit GWT auch zugängliche Alternativen zur reinen Javascript-Anwendung erstellen? P.S.: Der Link auf “contactoffice” funktioniert übrigens nicht: Das “beta” aus der URL kann raus.

Armin D. zum Artikel Wikipedia in Unternehmen: Ja, aber nicht mit MediaWiki:

Wir haben direkt mit Confluence begonnen. Das war allerdings eine architekturgetriebene Entscheidung, weniger eine aus dem Bewusstsein, welche Anforderungen funktionaler Art zu erfüllen sind. Natürlich haben wir gesehen, dass es als “Enterprise-Wiki” vertrieben wird und im professionellen Einsatz bei anderen Unternehmen (Referenzliste bei Atlassian) ist.

Heute, nach ca. 3 Jahren Betrieb unseres Firmen-Wikis, stellt sich heraus, dass es auch funktional die richtige Entwscheidung war. Sowohl das Berechtigungskonzept als auch die Möglichkeiten, Confluence an Unternehmensanforderungen bzgl. Layout und Sicherheitsfunktionen mit relativ geringem Programmieraufwand anzupassen, haben uns sehr geholfen, jetzt das Firmen-Wiki in den unternehmensweiten Rollout zu geben – das wird bedeuten, dass wir von derzeit ca. 2000 potenziellen Usern perspektivisch ca. 20.000 User erreichen können.

Natürlich gibt es auch negative Stimmen: z.B. ist die Usability des Rich-Text-Editors immer noch nicht wirklich gut – insbesondere mit dem bei uns noch eingesetzten IE-6 … der ist zwar von Atlassian für unsere Confluenceversion 3.0.1 supportet – weist aber trotzdem einige Bugs auf. Weiteres Problem bei der Einführung von Confluence als Firmen-Wiki ist, dass die User das Grund-Verständnis vom Wikipedia im Internet mitbringen und dies auf das Firmen-Wiki transponieren.Sie davon zu überzeugen, dass im Firmen-Wiki eine Struktur aus Bereichen und einer Hierarchie von Seiten, beides ggf. mit verschiedenartiger Berechtigung, besteht, verstehen viele zuerst nicht. Der Grund ist, dass damit die funktionale Nähe zum Intranet zu groß ist. Daraus wird beim Mitarbeiter ein Unverständnis dafür, was dann noch der Vorteil und Nutzen des Firmen-Wikis sein soll. Diesem Problem versuchen wir mit Aufklärungsarbeit zu begegnen, was jedoch viele Personalressourcen kostet …

Die nächsten Schritte für uns werden wohl sein, möglichst bald, wenn das technische Umfeld es zulässt (IE-8), auf eine höhere Version von Confluence zu wechseln. Insbesondere die Benutzerführung beim Erstellen von neuen Seiten ist in der Version 3.3 wesentlich verständlicher (Dialog mit Hinweis auf Vorlagen und der Auswahl von Bereichen, in der die Seite erstellt werden soll).