Facebook Nachrichten: Neues Design & neue Features im weltweiten Roll-Out!

Nachdem im Juli der Facebook Kalender komplett überarbeitet wurde sind nun die Facebook Nachrichten an der Reihe und erhalten ein komplett neues Design. Dabei erinnert das neue Design nun viel mehr an ein E-Mail-Postfach als zuvor. Folgende Neuerungen sind auf den ersten Blick erkennbar:

  • Einzelne Nachrichten werden mit Name, Profilbild und den ersten Buchstaben auf der linken Seiten angezeigt
  • Die Nachrichten-Suche wird auch in diese Seitenleiste verschoben
  • Ebenso ist in der Seitenleiste der Wechsel zwischen den verschiedenen ‘Posteingängen’ möglich, also der zwischen den normalen Nachrichten “Sonstiges”, “Archiviert” und “Spam”
  • Wird eine Nachricht angeklickt so wird diese direkt auf der rechten Seite angezeigt und die Seite wird nicht (wie aktuell) neu geladen
  • Das Textfeld wird deutlich größer und erhält wie auch der Chat den Button um Emoticons einzufügen
  • Innerhalb der Nachrichten werden Inhalte deutlich besser dargestellt, so werden Dateien besser hervorgehoben und Bilder auch schöner dargestellt
  • Verschiedene Tage werden innerhalb der Nachrichten durch Trennstriche optisch abgehoben
Auf den ersten Blick geht Facebook damit also wirklich in Richtung E-Mail-Postfach, was auch gar nicht schlecht ist denn das Design sieht sehr ansprechend aus. Laut Facebook befinden sich alle Features gerade im weltweiten Roll-out. In nächster Zeit erhält also jeder diese neue Ansicht, wie immer kann sich dies von Nutzer zu Nutzer sehr unterscheiden und es gibt keine Möglichkeit den Prozess zu beschleunigen. Beim letzten Update der Facebook Messages vergingen leider Monate bis jeder die neuen Funktionen hatte.
Spannend ist hier natürlich die Frage wie genau Facebook hier wirklich in die Richtung E-Mailpostfach geht, denn jeder Nutzer hat ja auch eine …@facebook.com Adresse erhalten.
Das neue Design wurde bei Facebook unter dem Namen “mercury project” entwickelt. Facebook Entwickler Adam Wolff schreibt zu den Änderungen: 

Starting today, we’re rolling out improved features and a new look for messages. Behind the scenes, we’ve also been improving the reliability of messages across the site. To address issues with disconnection, incorrect message counts, and missed and duplicated messages, we recently undertook an effort we called the “mercury project.”

 

The mercury project

We knew the mercury project would be a significant effort because Facebook messages, and especially its chat interface, is embedded in a web browsing experience. As such, it poses some novel challenges as a browser application: it must be highly reliable, yet still be able to load and initialize quickly and incrementally.

 

A small team set out to tackle these problems, which required some changes not just to Facebook messages, but also to the way that we develop and deliver our software. Eventually, we reached the first milestone for the mercury project: replacing the chat and messages jewel implementations with a more reliable version. With other teams such as the real time infrastructure and messaging infrastructure teams also contributing substantial improvements, we were able to improve reliability and grow usage.

 

We didn’t set out to build or adopt a framework; the mercury project has always been about product. But we did have some guiding principles that informed our approach. The chief among these were: modular design, test-oriented development, and functional programming style.

 

Modularity

Before we started the mercury project, we would often accidentally introduce regressions into messages while trying to make improvements. These regressions would usually track back to the way that we were managing JavaScript dependencies. At this time, Facebook had a very simple system for managing JavaScript dependencies: you would say that a given file provides a component and then say that another file requires that component.

 

Now, the meaning of “requires” in this system was not inituitive. It did not mean that the required file would load before your file. It just meant that your file and the other file would both be loaded by the time time the document was ready. There was not even a guarantee that a given  file would run only once. Moreover, everything was bound together in the global scope.

 

The worst thing about this system was that developers would make mistakes because it was easy to write code that would sometimes work if dependent files happened to be evaluated in the assumed order. In fact, because of the way we package script resources, it was especially likely to work on a developer’s machine and break when it hit production! This made it difficult to find these bugs before they were already in front of people on Facebook.

 

So the first step for the mercury project was to adopt a system similar to CommonJS, where every file is a module, and where modules are not evaluated until their dependent modules have been defined. We had to port a bunch of code to the new module system for mercury, but this was well worth it, and proved to be a game-changer.

(…)

 

 

Über den Autor:

Phlow-Autor Philipp Roth

Philipp Roth: Philipp ist Gründer von allfacebook.de und beschäftigt sich seit langem auch beruflich mit Facebook, organisiert Workshops, hält Vorträge und gibt konzeptionellen Input. Er realisiert viele der heute sehr erfolgreichen Auftritte und Applikationen auf Facebook und setzt seinen Fokus auf die Strategie von Unternehmen im Social Web. - Philipproth.com - Über AllFacebook.de

Kommentare


Nichts verpassen! Täglichen allfacebook.de Newsletter abonnieren:





Fan werden


WebMediaBrands
Mediabistro | SemanticWeb | Inside Network
Jobs | Education | Research | Events | News
Advertise | Terms of Use | Privacy Policy
Copyright 2012 WebMediaBrands Inc. All rights reserved.