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

Alle Funken für das Thema webdesign:

Template-Wettbewerbe sind quatsch

Gerade schaue ich mir die Ergebnisse des WordPress2.0-Theme-Competition an.

Zusammengefasst: 13 Template, alle samt gerade mal Standard-Qualität oder schlechter. Nix neues, nix frisches.

Ähnliches bewerte ich die Ergebnisse des Shopify-Template-Wettbewerbs (eine Rails-Webshop-Lösung).

Dort gewinne ich den Eindruck, die Designer Gewinner haben einen Tag vor nach Abgabe mal ein paar Stunden investiert um Hintergrundbild und Schriftfarbe auszutauschen…

Woran könnte das liegen?

Sowohl bei WordPress gab es iPods zu gewinnen als auch bei bei Shopify. Beide haben recht gute Weblog-Presse über ihren Wettbewerb gehabt. Shopify hat zusätzlich sogar ein sehr interessantes Template-Hilfswerkzeug veröffentlicht und einige Anreize für Folgeaufträge gegeben.

Der CSS-Zengarden zeigt, dass sich grundsätzlich hervorragende Designer im Web tummeln die auch bereit sind, an derartigen Dingen zu arbeiten…

Vielleicht ist ja das Tempalte-Design inzwischen out und alle haben sich schon im Zengarden ausgetobt?
Oder aber die Preise sind einfach falsch. Schließlich hat jeder Designer einen iPod oder aber sich bewusst dagegen entschieden?
Vielleicht hat unser Berufsstand auch einfach zu viel zu tun, all die neuen Web2.0-Interfaces zu gestalten und keinen Lust auf mäßig vergütete Template-Frickeleien?

Selbst wenn man im Vorhinein eine ordentliche Presse bekommt und eine Aussage transportieren will, wie es bei Shopify der Fall war („Tempaltdesign kann bei uns jeder, darum ist unser Shop cool") würde ich zur Zeit davon abraten. Das Geld für X iPods ist besser in ein/zwei Designer gesteckt, die dafür ein sehenswertes Ergebnis produzieren…

[tag]template, wordpress, design, webdesign, wettbewerb[/tag]

flying sparks (circa) 3.0

Eine kurze Notiz, insbesondere für RSS-Leser: Das Layout hat sich verändert.
Zur Zeit nur im Firefox getestet… Darstellungsfehler dürft ihr daher gerne melden :-).

Einige Gestaltungs-Muster (Design Pattern) werde ich noch optimieren und auch für ScoutPress dokumentieren. Am wichtigsten ist mir jedoch, dass der Umstieg auf Tags jetzt konsequent vollzogen ist und die Links in der Kopfgrafik endlich alle funktionieren.

Non-Design

Drei interessante Artikel die ich später noch einmal aufmerksam lesen will um vielleicht im ScoutPress-Blog darüber zu schreiben:

Update 06-04-13: Interessant, dass gerade der bekannte und gute Designer Douglas Bowman an der Entwicklung des Google-Kalenders mitgewirkt hat.

Update 06-05-16: Und noch ein Artikel zum Google-Design: Derek Powazek (er hat Technorati redesigned) hält es für falsch, das Google-Layout zu kopieren. Es sei zu unpersönlich und ließe den Benutzer ein ganz spezielles Suchverahlten erwarten.

Update 06-05-27: Bei 37signals wird über Don Normans Aussagen über das Google-Design diskutiert. Eine Zusammenfassung einiger der Kommentare.

Pixoh-Online-Bildbearbeitung

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.

Pixoh-Edit-Screen mit Cut-Funktion und File-Save-Dialog

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]

Podcast-Tipp

Ich glaube, diese Podcasts sind wert gehört zu werden: Carson Workshops Summit – The Future of Web Apps

Relevanz Relevanz Relevanz

Would these things be nice to have? Sure. Would they be great to have? Sure. Would they be cool to have? You bet. But do they really matter? Nope. And that’s why we left them out.

Ein weiteres Zitat, das in die „Getting-Real"-Liste von 37signals passt, über die ich schon früher schrieb.

„It just doesn’t matter" ist ein interessanter Beitrag.

Aber wie findet man die wirklich relevanten Funktionen eines Services?
37Signals ist dabei ziemlich erfolgreich. All ihre fünf Produkte zeichnen sich dadurch aus, dass sie sich auf das absolut notwendigste beschränken. Und das funktioniert.

In den Kommentaren der Seite geht die Diskussion genau dieser Frage nach.
Die These von Nathan Rutman: Nicht die Firma, sondern die Kunden/Zielgruppe bestimmt die Funktionalität.
Jason Fried hält dagegen: Wir sind die Zielgruppe. Wir bauen Software, die uns gefällt und unseren Bedürfnissen entspricht. Und wir finden Menschen, die die gleichen Lösungswege suchen wie wir.

Oder um es mit „Anonymous Coward" zu sagen: When the end user calls the shots we get nasty bloated software (See MS products). When companies with taste call the shots we get the iPod.

Wie gesagt: ein interessanter Artikel

Zum gleichen Thema: Essential vs. Non-Essential

Shopify Template-Pitch

Kurz eine Einleitung aus der Liste begeisterter Zitate: Was ist Shopify?

“Shopify is a new e-commerce framework that, I believe, will put all the others to shame immediately after it’s launched — it’s that amazing. Shopify is based on Ruby on Rails and has the most extensible theming system I’ve ever seen on any web application before, I can’t tell you how easy it will be to make a totally new user interface for your company’s e-commerce store.”

Die Begründer von Shopify haben einen Template-Contest ausgerufen.

Zwei Dinge gehören hervorgehoben:

1. Die Methode des Online-Pitches
…hat natürlich eine Reihe Vorteile für Shopify: Eine große Bandbreite an Entwürfen, überschaubare Kosten (10 iPod Nanos) und — am wichtigsten — eine Dynamik, die nur solch ein Wettbewerb erzeugen kann. Schon jetzt bloggen viele darüber, wie toll und einfach das „Vision"-Templatesystem ist (siehe 2), wie gut Shopify funktionieren wird … und so fort.
Genau das soll schließlich kommuniziert werden: Shopify ist so einfach zu individualisieren, dass „jeder" Webdesigner es kann. Das wird sehr anschaulich, wenn man sich das Template-Toolkit anguckt:

2. Das Vision-„theme design toolkit"
Die Idee ist hervorragend: Statt sich mit der fehleranfälligen Online-Bearbeitung der Templates herumzuärger, bietet Shopify eine lokale Instanz zum Templatedesign als Download an. Das Video (MOV) gibt einen guten Überblick, wie einfach das geht.

Es wurde einiges getan, um die Templateentwicklung unkompliziert zu machen. Da sich dadurch der Spaßfaktor erhöt und das Flow-Potential steigt, bin ich sicher, es werden einige gute Ergebnisse dabei heraus kommen.

Fazit: Wer Zeit hat, mitmachen. Für alle anderen: Beobachten (RSS).