Und mit Begeisterung fiel mir gleich Improve display of location bar results ins Auge.
Warum muss man die Icon unbedingt künstlich vergrößern ? Etc., etc.
Man muss doch nicht an allen etablierten und obendrein stabil funktionierenden Einheiten drehen.
Schaut man sich die einzelnen Positionen in dem Wiki-Artikel an, fällt mein Urteil ambivalent aus:
32x32px icons --> find ich gut...optische Bildreize sind aussagekräftiger als Text
Better URL scan-ability
No use of bold, since it shifts the content,
More whitespace
No separator line --> doof, weil damit die Ergebnisse optisch "verwischen"...die Trennlinie hilft ja beim Scannen der Ergebnisse
Ability to delete entry on hover --> ok
Remove scrollbar --> warum? Sollte doch dem Nutzer überlassen sein, ob er mit der Maus scrollt oder den Scrollbalken bedient.
Zitat von deschen2- Schaut man sich die einzelnen [...]an, fällt mein Urteil ambivalent aus
Dito!
Wobei ich zunächst erstmal (ggf. über ein Backout hinaus! :wink: ) alles positiv sehe. Chrome hat wieder Pate gestanden. Was ich aber nicht unbedingt negativ meine!
Durchaus sinnvoll halte ich die Bestrebungen zu dem Feature New Tab Page (Speed Dial). Hier hat sicherlich Opera eine gewichtige Vorreiterrolle. Aber durchaus positiv.
Home Tab.
Da bin ich hier noch nicht sicher, wo dieses Feature endgültig ankommen wird. Es ist nicht provokant, wenn ich sage, dass die Chrome- Lösung nicht die schlechteste (aus meiner Sicht!) ist /wäre.
DLM.
Nun ja. Ein Panel.
Zitat von deschen232x32px icons --> find ich gut...optische Bildreize sind aussagekräftiger als Text
Augenscheinlich erfreue ich mich einer anderen optischen Sensorik.
Bildchen identischer Größe sind ohne Einschaltung der Hirnzellen leicht erkennbar, auch die Zuordnung. Bei verpixelten (16x16 -> 32x32) Grafiken muss das Hirn zu Erkennung wieder zurückrechnen.
Ich finde die Idee, die Symbole zu vergrößern sofern das technisch machbar ist, grundsätzlich gut. Zurzeit ist es doch schon so, dass die Zeilen größere Bildchen zulassen würde, man sie aber kleiner darstellt, weil sie halt in dieser Größe ausgeliefert werden. Außerdem kann ich mir dazu erst ein wirklich abschließendes Urteil erlauben, wenn ich eine fertige Implementation (ggf. im UX-Branch) zu Gesicht bekomme und es mir in Aktion anschaue.
Pause - [1]. Auch wenn das mal etwas anders gerdacht war - [2]. 
[1] http://lawrencemandel.com/2011/11/15/upd…is-development/
[2] https://developer.mozilla.org/en/Plugins/Mul…in_Architecture
Und ?
Es ist immer gut, wenn ein Projekt wieder den Boden der Realität erkennt / erkennen muss.
Eine Struktur von einem einfachen Prozess zu einem multiplen Prozess um zubauen, ist wahrlich kein leichtes Unterfangen. Der Weg ist äußerst steinig, denn kein Mensch / Programmierer erkennt anfänglich alle Seiteneffekte.
Eine Auslagerung der von Dritterstellern erstellten Programme ist auf jeden Fall zu begrüßen.
Hingegen der Ansicht von Mozilla wird eine Notwendigkeit zur Trennung der eigenen Tasks hier noch nicht gesehen.
In der heutigen Nightly-Auslieferung wurde wieder auch am internen (Content-) Inspector geschnitzt!
[Blockierte Grafik: http://www8.pic-upload.de/thumb/18.11.11/qwjvaimup6e.png][Blockierte Grafik: http://www8.pic-upload.de/thumb/18.11.11/cygonc4yvoav.png]
UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111118 Firefox/11.0a1 ID:20111118031005
Pushlog: http://hg.mozilla.org/mozilla-centra…ge=447556784745
Zitat von pcinfarkt- Der Fix des Bug 695977 - Addons shouldn't be compatible by default when their minVersion is greater than the app version erschließt sich mir (mom.) noch nicht.
Langsam rutscht hier der Groschen [1]! :lol:
[Blockierte Grafik: http://www7.pic-upload.de/thumb/19.11.11/8cb2tpjzxsiy.png]
Auch heute wieder Verbesserung des internen (Content-) Inspector..!
[Blockierte Grafik: http://www7.pic-upload.de/thumb/21.11.11/2je72mwfw3gx.png]
UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111121 Firefox/11.0a1 ID:20111121061959
Pushlog: http://hg.mozilla.org/mozilla-centra…ge=2b75bcc4fec5
