Das Jahr, in dem die Musik-Streaming-Dienste im Krieg waren (to be continued)

Google Play Music All Access und Spotify sind im Krieg. Ergänze: Alle Musik-Streaming-Anbieter sind im Krieg. Im Laufe des Jahres wechselten sich die Angebote nur so durch. Als ehemaliger Ampya-Kunde habe ich drei Monate Deezer geschenkt bekommen. (Disclaimer Hinweis: Als Mitarbeiter bei der ProSiebenSat.1 Media AG habe ich auf einer internen Weihnachtsveranstaltung auch noch mal ein Vierteljahr bekommen.)

Käufer eines beliebigen Sonos-Systems bekamen im Sommer quasi 60 Euro geschenkt. Dafür musste ich nur einen neuen Google Account für Google Play Music All Access (oder wie es gerade heißt) anmelden. Das habe ich gemacht, aber den Account kaum genutzt. Meine Zeit ist mir wert, als dem jeweils günstigsten Angebot hinterherzurennen und meine Playlisten und bei Spotify gespeicherten Künstler mitzunehmen (Wer mir folgen will: ich bin grzbielok bei den Schweden).

Continue reading →

Apropos „Damit habe ich schon immer arbeiten wollen“ (#maps #api #google)

Manchmal entdeckt man ein Tool in einer neuen Version, und möchte sofort etwas damit machen. Mir passiert das ab und zu. Auf dem Google Developer Day 2008 in München führte der Softwarekonzern (Suchmaschinenriese ist ein bisschen kurz gegriffen in der Beschreibung) viele seiner Tools vor, und da die Zielgruppe der Konferenz Entwickler sind, natürlich die APIs zu seinen Tools.

Ich meine mich zu erinnern, dass ich bei dieser Veranstaltung einen Vortrag von Chris DiBona über die Google Maps API gehört habe, und seit diesem Kongress wollte ich damit was tun. (Es könnte auch bei der Google I/O 2009 gewesen sein, aber dafür gibt es auch keinen Session-Planer mehr im Netz.)

Continue reading →

Alte Tools, oder: Man muss auch loslassen können (#UXPin #AxureRP)

Vor kurzem habe ich an dieser Stelle geschrieben, wie es ist, dass das alte, erworbene Wissen unnütz ist.  as hat mich an einen Satz erinnert, den der große Essayist (ok, er ist Risikokapitalgeber im Silicon Valley) Paul Graham vor kurzem in einem tollen Aufsatz gesagt hat:

When experts are wrong, it’s often because they’re experts on an earlier version of the world.

Eine frühere Version meiner Selbst hat Prototypen mit Axure RP gemacht. Der Einstieg war nicht leicht. Die Software hat eine relativ hohe Hürde beim Einstieg, wie das viele Softwareprodukte aus dem letzten Jahrzehnt haben. Axure ist ein Box-Produkt, bei dem man merkt, dass jede Iteration noch mehr Features und noch mehr Komplexität gebracht hat. (Auch wenn man es online kauft und es nicht im Regal beim Elektronikmarkt steht, der Begriff Box-Produkt soll aus meiner Sicht sagen, dass es sich um ein riesiges Produkt handelt.) Ihre Schwester im Geiste ist Photoshop oder Word, nichts an der Software fühlt sich leicht an, sondern es ist immer Arbeit.

Mein Lieblingsbeispiel für die Komplexität in der Anwendung Axure RP ist „Wie mache ich einen Kreis?“. Das ist ganz einfach. Man malt ein Rechteck, klickt rechts auf das Objekt und verwandelt es in einen Kreis.

Nicht gerade logisch, oder?

Software installieren? Es gibt doch den Browser

Die neuen Tools sind anders. Sie laufen im Browser. Sie sind auf den ersten Blick viel weniger leistungsfähig. Sie verstecken ihre Komplexität, sodass man ihrer erst beim tieferen Nutzen des Produkts gewahr wird. Beim ersten Besuch bekommt man ein Tutorial-Video zu sehen. Eins, das man auch bei der Recherche für das Produkt auch gesehen haben könnte. Vier, fünf Minuten. YouTube-Player in der Lightbox über dem Web-Produkt. (Wenn du Adobe bist, mutest du uns deinen eigenen Flash-Player zu.)

Dann klickst du ein bisschen im Tool herum, machst deine ersten Schritte. Gehst zurück in die Gesamtübersicht, schaust dir ein einfaches, bereits vom Hersteller vorbereitetes Mini-Produkt an. Und dann vielleicht noch ein etwas komplexeres.

Warum ich das so ausführlich schreibe?

Ich musste mich daran erinnern, dass es einen Grund gibt, warum manche Prozessschritte in Tools nerven. Das Tool, das mich genervt hat, war UX Pin. Da muss man jede einzelne Photoshop- oder Sketch-Datei, die man uploaden will, erst mit einem Plugin in eine geeignete Form konvertieren. Der neue Dateityp ist .uxpin, kann sonst wohl keine andere Software. Noch mal 30x Dateikrempel, der meine Festplatte verstopft. Dann kann man die hochladen, aber nicht im Bulk, sondern nur eine Datei nach der anderen. Immerhin gibt es eine Queue, wenn man mehrere Dateien nacheinander losschickt in die Cloud.

Das wollte ich hier in Bausch und Bogen verdammen. Aber erstens ist das nicht der normale Anwendungsfall (UX Pin eignet sich gut zum Erstellen von responsiven Wireframes), und zweitens kann man mit den Photoshop-Dateien, die durch diesen Prozess hochgeladen wurden, wirklich gut arbeiten.

Also, UXPin, du kriegst noch eine Chance.

Das Jahr im Rückspiegel: Was ich in den letzten drei Jahren gelernt habe

Wenn man ein paar Jahre im gleichen Beruf arbeitet, wird man bequem. Das scheint mir ein Naturgesetz zu sein. Davon möchte ich mich gar nicht ausnehmen. Das Beste ist es, wenn man in einem beruflichen Umfeld arbeitet, das sich schnell verändert. Meins tut es, glücklicherweise. Denn der Wettbewerb schläft nicht. 

Ich bin Product Owner für eine Video-Plattform. Genauer: die Sender-Webseiten der ProSiebenSat.1 Media AG für deren Free-TV-Sender. Die laufen alle auf der gleichen technischen Basis, wie man mit einer schnelle Builtwith-Abfrage auch herausfinden kann. Das Konzept für diese Seiten stammt aus dem Jahr 2011. Im April bin ich damals ins Projekt eingestiegen, und im Januar 2012 haben wir sat1.de gelauncht.

Bald wird es 2015, und damit sind die drei Jahre, die man bei solchen Projekten zur Abschreibung braucht, auch Geschichte. 2011 haben wir an mehrere Breakpoints für die Seite noch gar nicht gedacht. Responsive Webdesign hatten wir schon gehört, aber uns betraf das nicht.

Und so sah das auch aus: Marke über den ganzen Bildschirm, links und rechts vom Content; viel Ball, viel Magenta, viel Lila. Wir haben das Konzept damals von der aus dem Pitch hervorgegangenen Agentur treiben lassen. Design-Driven Development, falls es das gibt. Wir waren ganz glücklich mit dem Ergebnis, haben aber gemerkt: Eigentlich wissen wir in-House mehr über das, was wir eigentlich wollen, als das eine externe Agentur je wissen kann.

Sat 1 home final 01

In 2014 haben wir konsolidiert – unser Begriff dafür, sechs Sender-Webseiten mit dem gleichen CMS zu bespielen (eZ Publish). Das läuft mittlerweile auch robust. Und jetzt ist es eigentlich Zeit, das Ding auf den Mülleimer zu werfen. Denn unsere Nutzer sind mittlerweile mehrheitlich mti dem Smartphone unterwegs. Unsere großen, bildreichen Seiten sind dafür nicht gemacht. Sie führen zu Ladezeiten von mehr als 15 Sekunden auf ganz vielen Seiten. Google Page Speed-Erkenntnisse werden nicht mehr heimlich rumgereicht, sondern hängen im Team-Raum unseres Scrum-Teams.

Im Titel habe ich versprochen zu verraten, was ich gelernt habe. 

  • Selbst wenn Externe versprechen, das richtige Konzept für dich zu machen: Nur wenn sie viele Interviews mit deinen Mitarbeitern führen und Workshops machen, darfst du ihnen glauben. 
  • Wenn die erste Lieferung bereits shiny Designs enthält (Deliverables-driven Design!), such dir jemand Anderen.
  • Nimm die Agentur, die dir erst Skizzen zeigt, und nicht die, die bunte PSD-Dateien auf Austauschservern ablegt.
  • Wenn du es dir leisten kannst, bau internes Know-how für solche Projekt auf.
  • Wenn du es dir nicht leisten kannst, bau erst recht interne Mitarbeiter auf, die auf Augenhöhe mit Dienstleistern diskutieren können.
  • Interne Entwickler reden ehrlich mit dir. Externe haben andere Interessen. Jede Stunde ist abrechenbar (wie die Anwälte bei Grisham-Romanen).
  • Plane genug Zeit ein, das agile Arbeiten allen Beteiligten nahezubringen. Die Entwickler musst du nicht überzeugen. Management ist ein dickeres Brett.
  • Die Entwickler brauchen einen starken Scrum Master. Der muss jeden Tag da sein. Teilzeit geht hier nicht.
  • Der Product Owner braucht auch genug Zeit. (Wenn er wie ich auch Teamleiter ist, reicht seine Zeit für ein gutes Produkt wohl nicht aus. – Mein größtes Versäumnis in diesem Jahr, übrigens.)

2014: Der Sieg der Typographie

A little bit of

Vor ein paar Jahren waren schöne Schriften im Browser noch ein Hack. Heute, im Jahr 2014, sind schön gestaltete Seiten im Netz zwar immer noch in der Minderheit, aber bei den wirklich in meiner Blase rezipierten Seite, scheinen sie in der Mehrheit zu sein.

Da wäre Medium.com, sowohl Plattform fürs Bloggen wie auch selbst Publisher von Kollektionen.

 

 

 

 

 

 

 

 

Continue reading →

Was ich beim Buchen einer Unterkunft mit AirBnB lernte, und was auch du lernen kannst

Im Sommer wollten wir nach Sardinien. Das ist dann leider an den noch etwas zu großen Distanzen für unseren in diesem Jahr geborenen Nachwuchs gescheitert (also vor allem die Distanz zwischen der schönsten Unterkunft und dem nächstgelegenen Strand).

Feature-Requests

  • In meiner Wish List möchte ich auch auch Unterkünfte mit Drag and Drop nach oben oder nach unten schieben können, damit ich meiner Frau besser zeigen kann, wie ich priorisieren würde.
  • Meine Wish List möchte ich auch nach Preis sortieren können, damit ich inkrementell sehe, wie ich mich meinem Budget nähere.
  • Hintergrund: Die Preis-Vorschau ist total kaputt. Da wird eine Wohnung mit 40 Euro angezeigt, auf einmal kostet ein 14-tägiger Aufenthalt dort über 1000 Euro. Weil die Wohnung für vier Personen noch andere Preiskomponenten wie Extra Betten und Extra Personen kennt.
  • Als Nutzer möchte ich wissen, was diese Bewertung durch andere Benutzer bedeutet: 

The reservation was canceled 65 days before arrival. This is an automated posting.

  • Als Nutzer möchte ich verhindern, dass Wohnungen als verfügbar angezeigt werden, obwohl sie schon längst vermietet werden, damit ich mir den Aufwand sparen kann, mehr Vermieter als notwendig anzuschreiben.

Liebes AirBnB, ihr macht zwar immer noch die beste FeWo-Börse im Web. Aber man kann ja immer noch besser werden.