“Gut kommentiert”: Wählen Sie jetzt den besten Leserbeitrag im //SEIBERT/MEDIA-Blog!

Abstimmung auf der Facebook-Seite von //SEIBERT/MEDIA

Das erste Kommentargewinnspiel Gut kommentiert! im //SEIBERT/MEDIA-Blog geht in die entscheidende Phase. Wir finden es toll, dass viele wirklich hochwertige und hochinteressante Kommentare zu den unterschiedlichsten Fachartikeln bei uns eingegangen sind, die inhaltlich und in Sachen Umfang teilweise ganz eigene Fachartikel sind. Nochmals herzlichen Dank für Ihre Beteiligung bislang! Weiter so! 🙂

Und jetzt ist es an Ihnen: Wählen Sie den besten Beitrag und damit den Gewinner eines Original-iPad 16GB, WiFi von Apple!

Das funktioniert ganz einfach: Klicken Sie sich auf das Status-Update auf unserer Facebook-Fanpage und stimmen Sie mit Ihrem Kommentar ab, welcher Autor für seinen Beitrag das iPad gewinnen soll. Natürlich können Sie gerne mehrere Kommentare bewerten und Ihre Anmerkungen hinterlassen. In die Bewertung fließt Ihre zuletzt abgegebene Stimme ein.

Die zwölf Nominierten

Wir haben nun eine qualitative Vorauswahl getroffen, die uns beileibe nicht leicht gefallen ist. Dies sind die zwölf Nominierungen in der Reihenfolge des Eingangs seit Beginn unseres Gewinnspiels:

1. 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. 🙂

2. 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.

3. 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.

4. 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.

5. 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.

6. 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!

7. 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. :-)

8. 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.

9. 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 …

10. 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).

11. 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.

12. 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).

Wie mögen Sie es lieber? Kurz und bündig auf den Punkt gebracht oder ausführlich und umfassend? Anschaulich oder nüchtern? Praxisnah oder eher theoretisch? Jetzt haben Sie auf unserer Facebook-Fanpage die Wahl. Wir freuen uns auf Ihre hoffentlich rege Teilnahme! Den Gewinner des iPad geben wir am 15. Oktober 2010 via Facebook und im //SEIBERT/MEDIA-Microblog bekannt.

Übrigens: Das Gewinnspiel wird fortgesetzt. Aktuelle Infos, die Nominierungen jeden Monats und die zu vergebenden Preise sowie die Teilnahmebedingungen finden Sie auf unserer laufend aktualisierten Seite im öffentlichen //SEIBERT/MEDIA-Wiki. Also: Weiter fleißig kommentieren und mit fachlichem Know-how und etwas Glück gewinnen! 🙂

Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis Kompetenter und schneller User-Support für eure Atlassian-Tools zum monatlichen Festpreis
ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

5 thoughts on ““Gut kommentiert”: Wählen Sie jetzt den besten Leserbeitrag im //SEIBERT/MEDIA-Blog!”

  1. Nur um sicher zu gehen – einfach das Voting für den entsprechenden Kommentar als Text unter dem Link auf der Facebook-Seite verfassen?

    Von meiner Seite auch ein großes Lob für alle Kommentare – so macht es Lust einen Blog zu lesen!

  2. David: Danke für das Lob, das wir vollständig teilen. Wir freuen uns, dass die Aktion so gut funktioniert hat und hoffen, dass sich dieser Trend auch in den nächsten Monaten fortsetzen wird.

    Deine Beschreibung der “Abstimmung” ist vollkommen korrekt. 🙂

    Wir freuen uns auf möglichst viele Stimmen.

  3. Wow, hier lohnt es sich ja wirklich Kommentare zu schreiben =)
    Dem 9. Kommentar kann ich nur zustimmen. Selbst entwickelte Software mag ja finanzielle Vorteile mit sich bringen, aber die Benutzerfreundlichkeit könnte definitiv besser sein. Z. B. gibts an meiner Uni Programme, bei denen man sich fragt, aus welchem Jahrhundert sie stammen. Keine Frage, sie funktionieren und erfüllen ihren Zweck, aber das allein macht sie nicht zu guten Programmen. Man nutzt sie täglich und jedes Mal mit unverständlicher Bedienung konfrontiert zu sein, ist nicht sonderlich motivierend… das mag an der Uni keine nennenswerten Auswirkungen haben, aber Unternehmen, in denen Effizienz zum Programm gehört, tun sich mit solcher Software bestimmt keinen Gefallen.
    Daher stimme für Kommentar 9 von David. Viel Erfolg!!

  4. Ich glaube hier im Blogartikel hat sich ein Fehler eingeschlichen: In der Mail mit der Info, das mein Kommentar nominiert ist, ist der 20. Oktober als Enddatum genannt – hier ist es der 15. Oktober.

    Herzliche Grüße,
    David

Schreibe einen Kommentar