Win 8 Customer Preview und wo ist das Startmenü?

[cookie22]

Zitat von jaenicke:

Zitat von cookie22:

Wo ist denn der Workflow schneller?

Durch die großen Kacheln und Icons auf einer größeren Fläche statt dem ziemlich gedrängten Startmenü hat man eine bessere Übersicht. Allerdings gibt es meistens nach ein paar Buchstaben auch nicht mehr viele Ergebnisse, insofern ist das vielleicht auch nicht so entscheidend.

Für meine Eltern ist es jedenfalls sehr viel besser, da diese mit der Maus leichte Schwierigkeiten haben kleinere Ziele zu treffen. Die Metrokacheln sind da ideal. Bei ihnen geht es da deutlich schneller. (Sie haben an meinem Testrechner ein wenig herumprobiert.)

Bei dem Publikum hier im Forum, auch bei mir, ist das natürlich in der Regel anders, falls denn überhaupt dort die Maus zum Einsatz kommt. Aber ich denke immer eher an den normalen Benutzer.

Gerade für Maus User ist das ganze nicht wirklich schneller. Um das Menü mit der Maus aufzurufen brauchst du in Win8 schon eine Bewegung mehr, nämlich erst unten in die Ecke dann wieder hoch. Wenn du nun viele Kacheln hast und eine kleine Auflösung hast, scrollst du dich blöde bis du was gefunden hast.

Versuch mal ein Windows eigenes Programm wie Paint aufzurufen, wenn du nur die Maus benutzt und auf suchen klickst, wird bei kleinen Auflösungen das halbe Menü erstmal verdeckt, auch das ist suboptimal. Auf einige wichtige Systemprogramme wie die Wiederherstellung hat MS aufgrund des Platzbedarfs wohl komplett verzichtet.

Viel Unterschied ist da nicht, letztendlich werden es alle benutzen müssen und sich damit arangieren. Aber Toll muss man das nun nicht gerade finden.

Ich streite nicht ab, dass das Ganze für Touchscreens und Tablet PCs einen Mehrwert hat. Aber für Desktop User kann ich das nicht erkennen.

Da finde ich solche Sachen wie die HUD Menüs in Ubuntu 12.04 wesentlich innovativer und produktiver. Das steigert wirklich den Workflow.

Ich denke, dass es ein Fehler ist ein Tablet OS mit einem Desktop OS zu verschmelzen.

[Morphie]

Habe gestern auf der CeBit das Windows 8 Developer Seminar besucht... Wirklich gut gewesen, kann ich also weiterempfehlen.

Ein paar nützliche Infos:
Das alte Startmenü bleibt definitiv weg, soviel sei gesagt. (wurde mir gesagt)

Das Design von Metro bleibt auch so, es wurde von den Schildern der New Yorker U-Bahn "abgeguckt", daher auch der Name.

Unter der Haube werkelt bei Windows 8 ein neuer Kernel, der für die ganzen Metro-Apps zuständig ist. Metro-Apps laufen nämlich komplett getrennt vom normalen Desktop.
Es ist auch nicht möglich, auf irgendwelche lokalen Daten über Metro zuzugreifen. Es wird also empfohlen, die Daten irgendwie in eine Cloud oder ins -für die App- reservierte Verzeichnis zu speichern.

Eigentlich ist das ganze App-Prinzip für Windows komplett anders. Eine App "Bildbearbeitung" melden sich z.B. im System an und sagen "Ich kann mit Bildern umgehen". Die Kamera-Anwendung meldet sich an mit "Ich kann Bilder ausgeben". Windows 8 weiß jetzt also, dass die Kamera z.B. ein Bild an das Bildbearbeitungsprogramm senden kann. Beide Apps wissen nichts voneinander, werden aber automatisch miteinander verknüpft (im rechten Bildschirmrand gibt es sogenannte "Charms", mit der man die Verknüpfung dann ansprechen kann)

Alle Apps arbeiten ausschließlich asynchron. Das war wohl der wichtigste Punkt überhaupt. Es wird also alles asynchron ausgeführt und wenn eine Operation fertig ist, bekommt es die App über ein Event mitgeteilt. Da muss sich der App-Entwickler also zum bisherigen Programmieren ziemlich umgewöhnen.

Nur die momentan aktive App, bekommt 100% Rechenzeit (ausgenommen ist der Desktop, der läuft immer)
Alle anderen Apps bekommen 5 Sekunden Zeit, ihre Daten zu speichern und werden dann "schlafen gelegt".



Allerdings sei auch gesagt, dass sich Microsoft bewusst ist, dass Apps nicht überall sinn machen und auch nie machen werden. Daher wird der Desktop wohl immer da bleiben.

Kritik sehe ich im Shopsystem. Das, was ich bei Apple so sehr verteufele, macht MS jetzt nach...
Jeder, der dort eine App hosten möchte, muss 99$ im Jahr zahlen.
Die Apps können bis jetzt wirklich nur über das Shopsystem installiert werden, das ist meiner Meinung nach ziemlicher mist. Bei Enterprise-Lösungen wusste die bei MS auch nicht wirklich bescheid, die meinten das steht noch nicht fest.

Lustig war, dass die Vorführkiste mitten in der Vorführung abgeschmiert ist und zuerst nur noch mit Bluescreen starten wollte

[mquadrat]

Also ich glaube, wenn man sich mal dran gewöhnt hat funktioniert Metro auch mit Tastatur und Maus. Scrollen über Mausrad ist man ja schon gewöhnt. Und mit Windows + tippen hat sich wohl auch jeder angefreundet (mein Lieblingsfeature seit Vista). Sofern ist das jetzt bildschirmfüllende Startmenü eigentlich kein Problem und man arbeitet genauso wie vorher auch. Anwendungswechsel über Tastatur sind wir als Programmierer doch auch gewöhnt

[RWarnecke]

Hallo Morphie,

danke für Deine ausführlichen Infos.

Zitat von Morphie:

Das alte Startmenü bleibt definitiv weg, soviel sei gesagt. (wurde mir gesagt)

Das Design von Metro bleibt auch so, es wurde von den Schildern der New Yorker U-Bahn "abgeguckt", daher auch der Name.

Hier werden aber einige ganz schön fluchen.

Zitat von Morphie:

Unter der Haube werkelt bei Windows 8 ein neuer Kernel, der für die ganzen Metro-Apps zuständig ist. Metro-Apps laufen nämlich komplett getrennt vom normalen Desktop.

Das hatte ich schon beim Testen vermutet, wie ich den IE über die Metro aufgerufen hatte.

Zitat von Morphie:

Es ist auch nicht möglich, auf irgendwelche lokalen Daten über Metro zuzugreifen. Es wird also empfohlen, die Daten irgendwie in eine Cloud oder ins -für die App- reservierte Verzeichnis zu speichern.

Welche Daten ? Die Konfigurationsdateien oder die Datenbank der Anwendung ?

Zitat von Morphie:

Alle Apps arbeiten ausschließlich asynchron. Das war wohl der wichtigste Punkt überhaupt. Es wird also alles asynchron ausgeführt und wenn eine Operation fertig ist, bekommt es die App über ein Event mitgeteilt. Da muss sich der App-Entwickler also zum bisherigen Programmieren ziemlich umgewöhnen.

Das finde ich wiederum nicht ganz so gut. Kann aber auch nicht sagen, wie es bei iOS oder Android mit den Apps in der Hinsicht aussieht.

Zitat von Morphie:

Nur die momentan aktive App, bekommt 100% Rechenzeit (ausgenommen ist der Desktop, der läuft immer)
Alle anderen Apps bekommen 5 Sekunden Zeit, ihre Daten zu speichern und werden dann "schlafen gelegt".

Wie ist das hier, wenn eine Anwendung über den Desktop läuft und die andere als Metro-App ?

Gruß
Rolf

[mquadrat]

Als Inspiration für Metro diente nicht nur die U-Bahn, sondern Hinweisschilder im Allgemeinen. Über die sogenannte Design Language von Metro gibt es ein eigenes Dokument, in dem das alles beschrieben ist. Wie es wirken soll, warum es wirken soll und was zu beachten ist etc.

Die Metro-Apps verwenden WinRT. Der Kernel ist der gleiche. Siehe http://i.zdnet.com/blogs/davidburela...;siu-container

Doch, es ist möglich auf lokale Daten zuzugreifen. Der neue "Öffnen-Dialog" vereint allerdings sämtliche Quellen (man kann auch selber Quelle spielen). Im gleichen Dialog kann man also Dateien von der lokalen Platte öffnen oder auch aus Cloud-Diensten wie SkyDrive bis hin zu Facebook. Für den Entwickler der konsumierenden Anwendung ist das Interface jeweils gleich, der Remote-Zugriff auf Dateien also völlig transparent. Kann man sich beispielsweise im Video zur SkyDrive Anwendung in Windows 8 anschauen.

Die Asynchronität wurde aus Silverlight übernommen. So soll vermieden werden, dass der UI Thread einfriert. Wenn ich nicht irre, ist es sogar verboten den UI Thread zu blockieren. Wer das macht, darf nicht in den Store. Und der Store ist die einzige Möglichkeit - Unternehmensanwendungen ausgenommen - wie man Metro-Apps installieren kann. Ist allerdings alles nicht so schlimm, da gleichzeitig neue Sprachkonstrukte für die Asynchronität eingeführt wurden. Man kann nun einen eigentlich asynchronen Aufruf so programmieren als wäre er synchron.

Es ist eher so, dass die inaktiven Apps (also die bei denen die 5 Sekunden abgelaufen sind) keine Prozessorzeit mehr kriegen. Die aktive Anwendung teilt sich die Prozessorzeit natürlich mit Hintergrundanwendungen (Dienste, Webradio, etc.). Das gilt natürlich nur wieder für Metro-Apps. Ich schätze bei Desktop-Anwendungen wird es beim alten bleiben. Müsste ich aber nochmal probieren.

[himitsu]

Man kann also nicht ein Programm (MApp) nebenher laufen lassen, während man was Anderes macht?
Wozu ist dann eine multithreadfähiges OS überhaupt mal eingeführt wurden? Das erinnert einen eher an das gute alte DOS. (es kann nur Einen geben)

Gut, da alles nur noch Vollbild ist, könnte ich also keine TV-App in einer Ecke laufen lassen, oder eine Radio-App im Hintergrund, wärend ich ansonsten in einem anderem Programm arbeite.
Wenn ich das Metro-Prinzip richtig durchziehen würde, gäbe es dann auch keine Services und sonstige Backgroundprogramme mehr.
OK, auch keine Viren, denn wärend ich mit Wörd, Broswer und Co. arbeite, muß der Virus/Trojaner/Kaylogger ja schlafen (man muß nur 5 Sekunden lang warten, um ein Passort sicher einzugeben ).
Und ich hab auch gerne mal ein Programm links und eines rechts, so zum Vergleich (gibt ja so coole und bald sinnlose Win7-Tastenkombis).

[Phoenix]

Zitat von himitsu:

Gut, da alles nur noch Vollbild ist, könnte ich also keine TV-App in einer Ecke laufen lassen,

Nicht in einer Ecke, aber in einem Streifen rechts oder Links von der Hauptanwendung. Du kannst auch jederzeit den Streifen von links nach rechts schieben oder etwas größer machen (damit geht dann die andere offene Anwendung in den Streifen-Modus). Oder du machst eine der beiden zum richtigen Vollbild, dann verschwindet der streifen im Hintergrundmodus.

[Morphie]

Zitat von RWarnecke:

Zitat von Morphie:

Es ist auch nicht möglich, auf irgendwelche lokalen Daten über Metro zuzugreifen. Es wird also empfohlen, die Daten irgendwie in eine Cloud oder ins -für die App- reservierte Verzeichnis zu speichern.

Welche Daten ? Die Konfigurationsdateien oder die Datenbank der Anwendung ?

Die Frage kam gestern auch. Es ist so, dass es keine direkten Datenbankzugriffe geben soll. Man soll sich einen Webservice schreiben mit dem man kommuniziert. Dann kam die Frage, ob man ein Workaround machen kann und einen Webserivce als localhost starten kann, der dann mit der Datenbank kommuniziert. Antwort: localhost / 127.0.0.1 ist verboten. =/
Ob das alles so 100%ig stimmt, was die sagten, weiß ich nicht... Teilweise kamen die bei den Fragen ziemlich ins schwitzen...

Zitat von RWarnecke:

Zitat von Morphie:

Nur die momentan aktive App, bekommt 100% Rechenzeit (ausgenommen ist der Desktop, der läuft immer)
Alle anderen Apps bekommen 5 Sekunden Zeit, ihre Daten zu speichern und werden dann "schlafen gelegt".

Wie ist das hier, wenn eine Anwendung über den Desktop läuft und die andere als Metro-App ?

Naja, wie gesagt, der Desktop läuft wie bisher. Läuft ein ziemlich ressourcenfressendes Programm auf dem Desktop, leidet die Metro-App natürlich auch... Auf dem Desktop lassen sich natürlich wie bisher mehrere Programme nebeneinander ausführen.
Ob die Metro-App in dem Moment, in dem ich den Desktop als Oberfläche habe, im Hintergrund weiterläuft, weiß ich nicht...
Achja, wie Phoenix schon sagte, gibt es auch ausnahmen. Man kann zwei (oder mehr) Apps auch gleichzeitig laufen lassen, wenn man eine App in einen Rand "snapt"...

Zitat von mquadrat:

Die Metro-Apps verwenden WinRT. Der Kernel ist der gleiche. Siehe http://i.zdnet.com/blogs/davidburela...;siu-container

Ich meinte damit, dass der Kernel dafür ziemlich aufgebohrt wurde und deswegen -im Gegensatz zu Windows 7- quasi neu ist. Es gibt weniger Hintergrundprozesse, WinRT wurde eingeführt, ARM-Prozessor Untersützung wurde eingeführt und insgesamt soll der Kernel wohl flotter sein...

[cookie22]

Zitat:

Ob die Metro-App in dem Moment, in dem ich den Desktop als Oberfläche habe, im Hintergrund weiterläuft, weiß ich nicht...

Ja, das sieht man im Task-Manager.

[taveuni]

Für englisch verstehende ein interessanter Artikel einer differenzierten Sichtweise.