ein Weblog von Tobias Jordans zu den Themen software designstudium web2.0 webdesign informationsdesign oekologie werbung usability tj video interfacedesign marketing // alle Themen...

Pixoh: Edit pictures online ist ein (bisher) kleine Webapplikation mit zur Zeit nur vier Kernfeatures.
„Nur" ist dabei ein Qualitätsmerkmal. Denn diese Kernfunktionen sind sauber umgesetzt und einfach zu bedienen.

Wie es sich für eine web2.0-Anwendung gehört, ist Pixoh noch nicht fertig. Zwar verzichtet es (zum Glück) auf den Beta-Flag im Logo aber schreibt an erster Stelle auf der Website:

Pixoh is in active development.
We hope to add features and improve the service at least weekly. Please go vote for what you’d like to see next, and we’ll do our best to add it to Pixoh.

Bisher erinnert mich alles an Getting-Real: Software mit wenig Feature veröffentlichen, schnell zu einer lauffähigen Lösung gelangen, mit persönlicher Stimme sprechen (eMaillink) und so fort…

Doch an einer Stelle weicht das Konzept ab: „Forget feature requests" heißt es im GettingReal-Buch. Den Artikel aus dem Buch kann man übrigens nahezu identisch im svn-Weblog finden.

Das 37-Konzept:
Feature-Requests lesen und dann löschen. Anfragen die häufig kommen, prägen sich ohnehin ein.
Vorteil: Sehr zeitsparend und effizient. Außer 37signals weiß niemand, welche Features wirklich angefragt werden. Die Macht bleibt bei 37signals und es gibt später weniger Diskussion, warum etwas gemacht wurde.
Nachteil: Kunden machen sich Arbeit und bekommen kein Feedback.

Die Pixoh-Methode
Pixoh macht es eher wie klassische Open-Source-Projekte mit ihren Bug-/Feature-Tracking-Tools. Es gibt eine zentrale Website auf der Anfragen eingetragen und bewertet werden.
Vorteil: Sowohl Pixoh als auch Benutzer haben einen direkten Überblick. Die Benutzer übernehmen das Sortieren, Gewichten, Verwalten….
Nachteil: Pixoh ist stärker an das Gebunden, was hoch bewertet wird. Ich bin mir unsicher, ob der Satz „We’ll try to implement them in order, but we’ll toss in a surprise now and then." die meckernden Stimmen später beruhigen kann…

Fazit: Ich sehe Vorteile in beiden Methoden. Spontan gefällt mir der Pixoh-Ansatz besser, da er die Demokratie der Entwicklung betont, die Benutzer stärker einbezieht und die Transparenz erhöt.
Jedoch ist er auch mit Mehraufwand verbunden…

[via Andreas-eMail via Lumma]

Gestern haben wir offiziell das Pfadiblog freigeschaltet.
Pfadiblog, das sind Unterhaltungen am Lagerfeuer.
Gedacht ist es als digitale Anlaufstelle für pfadfindernahe Themen. Wir wollen, frei von Verbandsgrenzen und -politik Websiten, Ideen, Inhalte im Netz vernetzen.
Im Gegensatz zum scout-o-wiki-Projekt, legen wir dabei — wie die Worte Weblog und Magazin schon sugerieren — den Schwerpunkt auf aktuelle Meldungen. Es geht mehr um das „wusstet ihr schon", „kennt ihr schon", als um richtige Anleitungen und Beschreibungen.
Für diese Dinge, werden auch wir das scout-o-wiki nutzen und versuchen, es durch eine starke Verlinkung zu fördern.

Technik

Für technisch interessierte: Unter Pfadiblog.de läuft das aktuelle Wordpres 2 als Weblogssystem.
Wir verzichten komplett auf die Kategorien-Funktion von WordPress und nutzen zur Themen-Sortierung das Plugin „UltimateTagWarrior". Bis auf ein Auto-Complete im Delicious-Stil bei der Tag-Eingabe kann der TagWarrior alles, was ein Tagging-Plugin können sollte. Es gibt Themen-Übersichtsseiten, man kann per AJAX in den Tags suchen und TagClouds ausgeben.
Auch sonst habe ich darauf geachtet, dass alle Gestaltung entweder über die extrem individualisierten Template-Dateien oder über zusätzliche Plugins geregelt wird.
Zwei eigenes (um)geschriebene Plugins werde ich im Zuge von scoutpress (demnächst mehr) dokumentieren und veröffentlichen: Das Paginierungs-Script für die Seitenzahlen und das Bilder-Script, das nach IMG-Tags sucht und ihnen unter anderem CSS-Classen zuweißt.

Soviel fürs Erste.
Fragen beantworten Andreas und ich gerne. Und jetzt wird erst mal gefrühstückt ;-)

„Was ist RSS"-Artikel gibt es einige, auch hier. Und doch wissen noch viel zu viele nicht, was es mit RSS auf sich hat bzw. sehen keinen Vorteil in der Nutzung.

Auf der einen Seite liegt das sicher daran, dass RSS nicht für jedermann nützlich ist. Auf der anderen Seite glaube ich aber, sind die verbreiteten Erklärungsartikel auch einfach nicht intuitiv genug. Sie machen alle den Eindruck, als seien sie von Techies für Techies geschrieben.

Ein kleines Lernvideo würde das Thema schneller und prägnanter anschaulich machen.
In diese Richtung ist mir nur ein Beispiel bekannt. Und das geht eindeutig besser…

In dieses Post habe ich einen ersten Textentwurf für ein solches Video geschrieben.
Ich freue mich über Textkorrekturen und -änderungsvorschläge in den Kommentaren!

Artikel weiterlesen…