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
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.
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.