Schlagwort-Archive: Usability

Confluence setzt neue Standards beim Editieren von Wiki-Seiten

Verwundert habe ich gerade bemerkt, dass ich schon 2005 einen kurzen Artikel zum Confluence Wiki geschrieben habe. Erst seit 2010 beschäftige ich mich aktiv mit dem Confluence Enterprise Wiki von Atlassian. Confluence hat die Stärken von damals konsequent ausgebaut und ist inzwischen eines der besten Wikis die ich bisher verwendet habe. Seit der Version 4.0 setzt der WYSIWYG Editor mE den absoluten Standard beim Editieren von Wiki-Seiten.

Es war mal Wikitext…

Wer klassische Wikis kennt verbindet damit immer Wikitext (oder auch Wiki-Code wiki markup, Wiki-Syntax) – eine simple Auszeichnungssprache um die Inhalte zu formatieren. Selbst Wikis mit integriertem Richtext-Editor (WYSIWYG-Editor), wie z.B. Foswiki oder Confluence bis Version 3.5, boten diesen nur als zusätzliche Option zur Wiki-Syntax an. Häufig kam es dabei vor, dass sich der Editor beim Formatieren „verheddert“ hat und dies dann im Wikitext korrigiert werden musste.
Wiki Befürworter betonen gewöhnlich die einfache Wiki-Syntax mit der schnell Inhalte von jedem erstellt und bearbeitet werden können. Viele Anwender (die „Wiki-Gegner“) weigern sich (oder tun sich zumindest sehr schwer) Wiki-Syntax zu verwenden und bezeichnen sie als kompliziert und vorsintflutlich. Der große Gewinn durch das Wiki-Prinzip – die Art und Weise wie Zusammenarbeit offen, transparent und versioniert umgesetzt wird – wird dadurch nicht erkannt. Wer jedoch einmal ernsthaft gemeinsam zentral Dokumente erstellt und weiterentwickelt hat, möchte diese Art der Zusammenarbeit im Team i.d.R nicht mehr missen. Damit es dazu kommt, muss man sich, wie bei vielem, erstmal darauf einlassen und es ausprobieren. Und gerade dabei spielt die „geringe“ Hürde des Editors eine oft unterschätze Rolle bei der Wiki-Adoption.

Neue Funktionen im Richtext-Editor

Atlassian hat in den letzten sehr viel in die Entwicklung eines neuen Editors gesteckt und diesen perfektioniert. Zur Version 4.0 von Confluence wurde außerdem auf einen reinen Richtext-Editor umgestellt. Das umschalten auf Wiki-Markup ist damit nicht mehr möglich, was viele Wiki-Geeks anfangs in Angst und Schrecken versetzt hat. Dies war ein  überfälliger Entwicklungsschritt, der z.B. auch schon lange in der Entwickler-Community des TWiki/Foswiki diskutiert wurde. Natürlich verläuft eine solch gravierende Änderung nicht ganz problemfrei ab, aber ich war erstaunt, wie gut der Editor von Anfang an war. Mit dem Verzicht auf Wiki-Markup wurde es einfacher möglich komplexe Wiki-Funktionen anwenderfreundlicher zu integrieren. An Stellen an denen bisher für den Anwender kryptische Makros standen, können nun über Konfigurationsmenüs die Sonderfunktionen eingefügt und mit einem Platzhalter visualisiert werden.
Meine Top-Features des neuen Editors sind u.a.

  • Automatische Konvertierung von Wiki-Syntax während der Eingabe
  • Automatische Vervollständigung bei der Verlinkung von Seiten, Benutzern, Anhängen und Makros
  • Drag & Drop von Anhängen
  • Copy & Paste von Grafiken im Editor
  • Viele Tastaturkürzel für sehr schnelles Arbeiten
Hier eines der Videos welches ein paar der Funktionen zeigt:
[youtube]http://www.youtube.com/watch?v=dzbm4rma904[/youtube]
Nachdem ich viele Jahre Wiki fast ausschliesslich in Wiki-Syntax editiert habe, vermisse ich dies mit dem Confluence 4.x Editor kein Stück. Durch die Konvertierung von Wiki-Syntax bei der Eingabe war zudem keine Umstellung der „alten Gewohnheiten“ nötig und gerade durch Kenntnis der Wiki-Syntax kann sehr schnell formatiert werden.
Natürlich gibt es bei jedem Wiki stärken und schwächen – auch Confluence hat Punkte die verbessert werden sollten. In einem weiteren Artikel werde ich einige Stärken und Schwächen aufzeigen.

Schöne Fonts fürs Web


Bislang war es nicht ohne weiteres möglich auf Webseiten eigene Fonts zu verwenden. Webbrowser verwenden lediglich die auf dem System installieren Fonts zum Anzeigen von Webseiten. Damit war es, außer über den eher aufwendigen Umweg einer Grafik, oder dem kaum praktizierten bereitstellen eines eigenen Fonts auf dem Server, nicht möglich spezielle Schriftarten zu verwenden.
Auf der diesjährigen Google I/O Konferenz hat Google ihre Google font api vorgestellt. Darüber werden Schriftarten bereitgestellt und können ganz einfach im HTML-Header einer Website eingebunden werden. Die Schrift kann dann einfach per CSS eingebunden und formatiert werden. Aktuelle Browser unterstützen eingebundene Fonts. Google stellt einige Lizenzfreie Fonts zur Verfügung, z.B. Lobster (siehe Screenshot rock ’n roll!). Eine Übersicht gibt es im Google font directory. Es können auch weitere Fonts anderer Web-Font Provider eingebunden werden. Derzeit wir nur der kostenpflichtige Provider Typekit genannt.
Folgende Code-Schnipsel werden zum Einbinden des Lobster Fonts benötigt. Im HTML-Header:

<link href='http://fonts.googleapis.com/css?family=Lobster'  rel='stylesheet' type='text/css'>

Die Formatierung der Schrift mit CSS:

<span style="font-family: 'Lobster', arial, serif; font-size: 30px;">rock 'n roll!</span>

Vor allem im Bezug auf Überschriften und Teaser finde ich die Fonts eine schöne Option. Ich bin gespannt ob diese Möglichkeit angenommen wird und sich etabliert. Die Designer dürften sich jedenfalls freuen.

Instant Messaging – immer online und doch abwesend

Instant Messaging wird immer mehr verwendet und ist für viele in der täglichen Kommunikation nicht mehr wegzudenken. Inzwischen läuft sogar ein kleines Jabber-Pilotprojekt bei Eberspächer und begeistert immer mehr. Mit Instant-Messaging verschmilzt jedoch Freizeit und Arbeitszeit immer mehr. Wer nicht konsequent verschiedene Accounts für verschiedene Gruppen (z.B. geschäftlich & privat) führt ist quasi für alle „immer verfügbar“. Für mich ist die Lösung mit verschiedenen Accounts nicht praktikabel, da natürlich auf die Übergänge verschiedener Kontaktgruppen fließend sind (Die Idee von zwei paralellen Skypeaccounts habe ich nicht weiter angewandt).
In der Praxis setzen viele meiner Kontakte daher ihren Status auf „Abwesend“ oder „Nicht Verfügbar“. Dadurch wird gerade eine der guten Eigenschaften des Instant Messaging aufgehoben. Aus meiner Sicht liegt dies an der schlechten Usability aller Messenger Clients und Protokolle die ich kenne. Also egal ob Jabber / XMPP, ICQ, Skype, MSN usw., es ist derzeit nicht möglich die Privatsphäre gruppenbasiert einzustellen. Ich bin mir dabei nicht sicher, ob dies evtl. schon durch das Protokoll verhindert wird.

Gruppenbasierter Status im Instant Messenger

Wünschenswert wäre, den persönlichen Status im Client (Online / Verfügbar, Abwesend, Nicht Stören, Unsichtbar, Offline) für Benutzer und Gruppen individuell einstellen zu können. Dadurch könnte man gezielt für bestimmte Kontaktgruppen verfügbar sein, beispielsweise tagsüber für Geschäftskontakte und Kollegen „Verfügbar“, dagegen für private Kontakte mit dem Status „Nicht Stören“ aufwarten, zu bestimmten Zeiten Premium-Kunden Online-Support anbieten und am Abend mit Freunden chatten. Denkbar wäre auch direkt an einen Wochenplan und zusätzlich an den eigenen Kalender zu koppeln.Skype Logo Gerade von einem Tool wie Skype, das sehr stark auch im Business Bereich eingesetzt wird, würde ich solche Funktionalität erwarten. Aber scheinbar haben die Entwickler nicht wirklich Anhung von Benutzerfreundlichkeit. Die neue Skype-Version 4 kommt jedenfalls nicht sehr gut an, wie man heute bei Golem lesen konnte:

Das neue Skype 4.0 für Windows soll vieles besser machen. Doch unzufriedene Nutzer wechseln wieder zur Vorgängerversion 3.8. Ihnen fehlen Funktionen oder Softwareprobleme machen ihnen das Leben schwer.

Ich hoffe dass sich an dieser Stelle jedenfalls noch einiges verbessert und gleichzeitig immer mehr Benutzer von proprietären Protokollen auf offene Standards wie XMPP wechseln.
Noch mehr würde ich mich natürlich freuen, wenn ich irgendwo die gewünschten Optionen in meinem Pidgin Messenger übersehen habe und mir jemand erklärt wie ich das jetzt schon umsetzen kann!

Google-Reader vs. Bloglines

Bloglines (ein online Feedreader) hat die neue Betaversion freigegeben. Nachdem ich anfangs Bloglines verwendet habe, verwende Bloglines Beta Logonun seit langem den Google-Reader. Gerade habe ich meine Feeds aus dem Google-Reader in Bloglines importiert, um mir die Beta anzusehen. Einige neue Features gefallen mir dabei sehr gut, andere Funktionen vermisse ich aber immer noch bei beiden Tools.

1. Ordnung per Drag und Drop

Feeds und Ordner kann man ganz einfach mit der Maus per Drag and Drop verschieben. Der Google-Reader lässt nur alphabetische Sortierung zu und die Feeds müssen umständlich über das Dropdown-Menü in andere Ordner verfrachtet werden. Micheal Herrling beschreibt z.B. wie er Bloglines verwendet, um die Ordner für den Google-Reader umzubenennen. In der neuen Beta scheint mir das bislang nicht möglich. Ein Vorteil von Google-Reader: Die Ordner sind in Wirklichkeit Tags. Dadurch kann man einen Feed mehreren Ordnern (bzw. Tags) zuordnen was bei Bloglines nicht möglich ist. Ob man das jedoch benötigt?

Bloglines Beta: Drag and Drop

2. Lesemodus bleibt für jeden Feed erhalten

Im Google-Reader kann man zwischen List view und Expanded view umschalten. Ich verwende List view gerne für hochfrequentierte Feeds wie z.B. IT-Nachrichten von Heise oder Golem, um die Nachrichten schnell zu scannen. Dafür reicht mir meist der Titel um zu entscheiden ob etwas für mich interessant ist. Bloglines Beta unterscheidet im Lesemodus zwischen Quick view (was List view entspricht), Full view (entspricht Expanded view) und bietet dazu noch den 3-pane view. Das geniale – Bloglines merkt sich die zuletzt gewählte Einstellung für jeden Feed.

Bloglines Beta: View umschalten

3. Startseite: Intelligent vs. Konfigurierbar

Ein scheinbar tolles neues Feature ist die Startseite welche man per Drag and Drop mit eigenen Highlights füllen kann. Mir gefällt die Startseite des Google-Reader trotz weniger Flexibilität besser. Es werden mir automatisch „irgendwelche“ Updates angezeigt (keine Ahnung wie diese priorisiert werden – muss wohl irgendwie auf meinem Leseverhalten beruhen?)

4. Feed-Out mit shared items

Schmerzlich vermisse ich bei Bloglines Beta die einfache Möglichkeit interessante Artikel in einem externen Feed zu vereinen wie es mit dem Google-Shared-Feed möglich ist. Durch einen Klick auf Share werden von mir gelesene Artikel in einem öffentlichen Feed vereint. Diesen veröffentliche ich z.B. hier in meinem Blog (Aus dem Feedreader) und lasse damit meine Blogleser an interessanten Artikeln teilhaben.

5. Archivierung und Retrieval

Eine schnelle Möglichkeit um im Google-Reader Artikel zu merken ist sie mit einem Stern zu markieren. Alle markierten Artikel kann man später unter Starred items einsehen.
Ich vermisse bei beiden Readern eine erweiterte Archivierungsfunktion. Statt einem einfachen Sternchen wäre mir lieber die Artikel mit Schlagwörtern zu versehen und sie dadurch im Archiv über eine Tagcloud wiederfinden zu können.
Weiter fehlt eine gute Suchfunktion über die abonnierten Feeds, über gelesene und ungelesene Artikel und über archivierte Artikel. Verwunderlich das dies gerade beim Google-Reader trotz Googles Such-Expertise nicht verfügbar ist. Die Suche in Bloglines Beta scheint auch nicht die abonnierten Feeds zu durchsuchen sondern sucht allgemein nach Feeds.
Um Artikel zu Archivieren und wiederzufinden lege ich deshalb häufig direkt aus dem Google-Reader die Artikel in meinem Delicious-Account ab.

6. Usability: Bedienung per Tastatur

Bei Bloglines habe ich die Taststur-Shortcuts bisher nicht gefunden. Google-Reader lässt sich sehr komfortabel und schnell mit der Tastatur bedienen. Die Tastatur-Shortcuts findet man übrigens in den FAQs. Bei Bloglines gefällt mir die Möglichkeit die Breite der Spalten anzupassen.

Fazit

Wie so oft haben beide Tools einige Vorteile. Bloglines hat einige gute Ansätze und verspricht laut noch einige wichtige Funktionen nachzulegen:

Options for saving, sending and sharing stories, tools for building link blogs, managing blog rolls, etc. are all on the way.

Beim derzeitigen Funktionsumfang liegt der Google-Reader für mich aber immernoch weit vorn. Sicherlich wird Google in nächster Zeit verstärkt am Feintuning des Google-Reader feilen müssen, um nicht viele Leser an Bloglines zu verlieren.
Weitere Artikel zur Bloglines Beta bei Basic Thinking, Blogging Tom oder Techcrunch

Viel hilft viel – zwei Displays

Seit einigen Monaten arbeite ich mit zwei Displays. Es ist natürlich sehr angenehm und ich kann dadurch bestimmte Tätigkeiten viel effektiver ohne ständiges Hin- und Herklicken erledigen. Oft wird bei der Arbeit eine Dokumentationsseite oder Anleitung in Form einer Website oder PDF-Dokuments benötigt, die man parallel auf dem zweiten Monitor legen kann. Eigenschaften von AnzeigeDie eigene Dokumentation kann zudem viel schneller im eigenen Wiki erstellt werden. Gerade wenn viel am PC programmiert und entwickelt wird, ist es sinnvoll einen zweiten Monitor anzuschaffen. Aufgaben die zwischendurch schnell erledigt werden müssen können außerdem viel schneller abgehakt werden.
Ich arbeite an meinem Dell Notebook und habe eine externe Tastatur und einen ViewSonic TFT angeschlossen. Wenn man somit eh zwei Displays zur Verfügung hat macht es Sinn den Desktop auf das Display des Notebooks zu erweitern.
Eine Studie von Microsoft hat ergeben, dass durch ein weiteres Display die Produktivität im Durchschnitt um 8-50% erhöht. Mit diesem Argument und gleichzeitig sinkenden Preisen der TFT-Displays sollte auch die Argumentation im Unternehmen erleichtert sein.
Wer an seinem Notebook zwei externe TFT-Monitore verwenden möchte kann z.B. den DualHead2Go Adapter von Matrox verwenden. An einem PC ist es günstiger eine zweite Grafikkarte einzubauen, sofern die vorhanden Grafikkarte nicht schon zwei Ausgänge hat. Wer zuviel Geld hat kann sich auch ein Seamless Display vorbestellen:
Seamless Display
Laut einem Artikel bei Golem soll es Anfang 2007 für schlappe 16.000 USD zu kaufen sein…

modernes Webdesign?

Anfang des Jahres ging www.eberspaecher.com online. Der Auftritt wurde vom „lange bewährten“ Partner für Printmedien designt und von der Netpioneer GmbH umgesetzt. Als Content Management System kommt pirobase CMS® der Pironet NDH AG zum Einsatz. Näturlich liegt es nahe für das Intranet dasselbe CMS zu verwenden. In den letzten Wochen habe ich dafür an den Intranet-Einsatz angepasste Designvorlagen in XHTML und CSS erstellt und daraus in Zusammenarbeit mit unserem Partner die benötigten Templates erstellt. Ein Schwerpunkt war dabei die Usability der Seiten zu verbessern, ohne die pixelgenauen Designvorgaben zu missachten. Bei normaler Schriftgröße im Browser, sehen die internen Seiten daher wie vorgegeben aus. Mitarbeiter mit hochauflösenden Displays, Sehschwächen oder müden Augen können die Seiten problemlos im Browser re-sizen (vergrößern). Dazu kann man z.B. im Firefox ‚STRG +‘ drücken oder den Internet-Explorer auf große Schriften einstellen. Zum Vergleich hier je ein Screenshot der Internet- und Intranet-Seite bei einer Monitorauflösung von ca. 3200x1200px und entsprechend starker Vergrößerung der Schriften.

Internet SeiteIntranet Seite

…soviel zu modernem Webdesign.
Hinweis: Um die Seiten inklusive aller Elemente im Browser vergrößern zu können, wurden alle Layout-Elemente und Schriften statt absolut in Pixel relativ in Prozent oder em bemaßt. Um dies möglichst einfach umzusetzen, wurde die Standard-Schriftgröße auf 62,5% gesetzt, was i.d.R. 10px entspricht. Dadurch entspricht 1em 10 Pixel und kann sehr einfach zur Bemaßung des Layouts verwendet werden.

Usability oder viel Text für nichts?

Via Yigg.de bin ich heute im webdesignblog gelandet, das ich auch manchmal lese.
„100 Usability Tipps“ – so die vielversprechende Überschrift. Die ersten drei Tipps sind jedenfalls nicht wirklich ergiebig:

  1. Man soll Texte im Web ohne Brille lesen können?
  2. Die Textgröße soll so klein sein damit man sie Scannen kann?
  3. Schriften sollen niemals fixiert werden damit man mit „STRG +“ die Schriftgröße anpassen kann?

Usability oder viel Text für nichts? weiterlesen

wetpaint: wiki wiki noch schneller?

wetpaint wikiBei wetpaint wird an noch schnelleren wikis gebaut! Als Ward Cunningham damals (1995) sein wikiwikiweb startete, wollte er nichts weiter, als mit anderen Entwicklern schnell und einfach online dokumentieren. Heute revolutionieren Wikis kollaboratives Arbeiten in Unternehmen und sind aus dem Web nicht mehr wegzudenken. 2005 galt u.a. als „Jahr des Wikis“, insbesondere durch den Boom der Wikipedia. Klar, ein Wiki ist eine Webseite, die es jedem Besucher ermöglicht, ihren Inhalt zu bearbeiten. Wirklich jedem? wetpaint: wiki wiki noch schneller? weiterlesen

Rallypoint – die bessere Kollaboration im Web?

RallypointDurch HASH wurde ich kürzlich auf eine neue Kollaborationsplattform „Rallypoint“ aufmerksam. Anfangs dachte ich es wäre ein „vollwertiges“ Wiki im Stil von Jotspot oder Confluence. Fünf Benutzer, 25 MB Speicher in der kostenlosen Betaversion, dazu eine hübsche Oberfläche, ein WYSIWYG Editor und ein paar Ajax Features sind aber schon fast alles was man bekommt. Unter der Haube steckt dann doch mehr Wiki als man denkt. Rallypoint – die bessere Kollaboration im Web? weiterlesen