lohnt es sich, das Betriebssystem so aussehen zu lassen?

Ich denke, dass, wenn Ihr Programm nicht zu einem sehr großen Teil des Benutzerlebens wird, Sie danach streben sollten, "Überraschungen" zu minimieren und die Wiedererkennbarkeit zu maximieren (ist das überhaupt ein Wort?).

Also, wenn Sie etwas machen, das von 1.000 Menschen 10 Minuten pro Tag benutzt wird, gehen Sie mit System-Looks und Mechanismen.

Wenn Sie auf der anderen Seite etwas machen, dass 100 Personen 6 Stunden am Tag nutzen, würde ich beginnen, welche UI-Verbesserungen und Shortcuts ich einbauen könnte, um diese 6 Stunden leichter zu bewältigen.

Beachten Sie jedoch, dass UI-Fixes nicht zu Lasten der Performance gehen dürfen. Dies ist fast immer am Anfang der Fall, wenn jemand denkt, dass das OnPaint-Ereignis in .Net einfach übersteuert wird.

Bevor Sie es wissen, fangen Sie noch einmal NC_PAINT und NC_BACKGROERTERASE und all diese kleinen Tricks ab, um es so schnell wie die eingebauten Kontrollen zu machen.

Ich stimme hier anderen zu - besonders Soraz und Smaci.

Eine Sache, die ich hinzufügen werde, obwohl. Wenn Sie das Gefühl haben, dass das OS L & amp; F zu einschränkend ist, und Sie gute Gründe haben, darüber hinauszugehen, würde ich mich bemühen, dem Prinzip von "Pacing and Leading" zu folgen (das ich hier aus einem NLP-Kontext entleife) .

Die Idee ist, dass Sie immer noch so viel wie möglich mit der beabsichtigten Vertrautheit mit dem Host-Betriebssystem ausnutzen wollen (es wird seltene Ausnahmen geben, wie Smaci bereits berichtet hat). Sie verwenden also so viel wie möglich der "Standard" -Steuerelemente und -Verhaltensweisen (dies ist das "Pacing") - aber erweitern Sie es, wo es notwendig ist, auf eine Weise, die immer noch so weit wie möglich "hineinpasst" (voreilend).

Sie haben bereits einige gute Beispiele dieses Prinzips bei der Arbeit erwähnt - Visual Studio, sogar Office in gewissem Umfang (Office ist "besonders", da neue UI-Stile, die hier ihre Zähne schneiden, oft in zukünftige OS-Versionen zurückfinden - oder De-facto-Standards).

Ich führe das auf den Kontrast der Art von Apps, die "nur ihren Weg gehen" - normalerweise, weil sie von einer anderen Plattform portiert wurden oder plattformübergreifend sowohl in GUI als auch in Core geschrieben wurden . Java-Apps fallen oft in diese Kategorie, aber sie sind nicht die einzigen. Es ist nicht mehr so ​​schlecht wie früher, aber selbst heute haben die meisten professionellen Audio-Apps Mongrel-UIs, die ihre Herkunft zeigen, da sie im Laufe der Jahre von einer Plattform zur anderen portiert wurden. Während es für diese Beispiele gute geschäftliche Gründe geben könnte, bleibt es, dass ihre UIs dazu neigen, zu saugen und diese Route sollte vermieden werden, wenn es irgendwie möglich ist!

Das vorrangige Prinzip ist immer noch, dem Pfad der geringsten Überraschung zu folgen und die Vertrautheit Ihres Benutzers mit dem Betriebssystem sowie das Verhältnis seiner Zeit mit Ihrer App zu anderen Betriebssystemen zu berücksichtigen.

Ja, schon allein deshalb, weil es dem Betriebssystem ermöglicht, beliebige Funktionen für den Zugriff zu verwenden, die wie Text-to-Speech eingebaut sind. Es gibt niemanden mehr, der jemanden nervt, der Zugriffsmöglichkeiten benötigt, um eine andere Benutzeroberfläche zu haben, die alle Werkzeuge zerstört, die sie gewohnt sind.

Es hängt davon ab, wie weit Sie system look'n feel definieren würden ... Aber im Allgemeinen sollten Sie es behalten.

Überraschen Sie den Benutzer nicht mit der Unterscheidung von dem, was er gewohnt ist. Das ist einer der Gründe, warum wir ihn user nennen; -)

Firefox und Adobe-Produkte tun dies normalerweise nicht, weil sie auf mehrere Plattformen abzielen, die alle ihre eigenen L & amp; F haben. Aber Visual Studio behält die typischen Windows L & amp; F. Solange Sie nur für Windows arbeiten, sollten Sie das auch tun.

Abgesehen von der Tatsache, dass es unter Windows kein gut definiertes Look-n-Feel gibt, sollten Sie immer versuchen, dem Host-Plattform-nativen L & amp; F zu folgen. Beachten Sie jedoch, dass Look-n-Feel genau so viel darüber aussagt, wie sich ein Programm verhält und wie es aussieht. Programme, die sich kontraintuitiv verhalten, sind genauso lästig wie Programme mit eigenen hässlichen Widgets.

Fraps ist ein gutes Beispiel (IMHO) für ein Programm, das tatsächlich sehr nützlich ist, aber einige Benutzeroberflächenrichtlinien bricht und wirklich hässlich aussieht.

Wenn Sie für Mac OS X oder Microsoft Windows von Apple entwickeln, geben die Anbieter Schnittstellenrichtlinien vor, denen folgen sollte, damit jede Anwendung "nativ" ist.

Siehe Gibt es Welche Standards müssen bei der Festlegung der Menüpunkte beachtet werden? für weitere Informationen.

Im Allgemeinen ja. Aber es gibt das gelegentliche Programm, das gut funktioniert, obwohl es nicht für alle Betriebssysteme formatiert ist, auf denen es läuft. Zum Beispiel läuft Emacs ziemlich gegen jede Schnittstellenrichtlinie auf OS X oder Windows (und wahrscheinlich sogar gnome / KDE) und es wird nicht so bald verschwinden.

Ich stark empfehle, dass Ihre Anwendung nativ aussieht.

Ein häufiger Fehler, den Entwickler, die eine Anwendung auf eine neue Plattform portieren, zu machen scheinen, ist, dass die neue Anwendung wie auf der alten Plattform aussieht und aussieht.

Nein, die neue Anwendung sollte aussehen und sich anfühlen wie alle anderen Anwendungen, die der Benutzer auf der neuen Plattform verwendet.

Sonst bekommst du Gräuel wie iTunes unter Windows. Das gleiche UI-Design kann auf einer Plattform genau richtig und auf der nächsten sehr falsch sein.

Sie werden feststellen, dass Ihre Benutzer möglicherweise nicht genau feststellen können, warum sie Ihre Anwendung nicht mögen, aber sie fühlen sich nur schwer zu bedienen.

Ja, es gibt gültige Ausnahmen, aber sie sind selten (und tatsächlich sind sie eher die Hauptanwendungen wie Office und Firefox als die Kleinen). Wenn Sie unsicher sind, ob Sie bei StackOverflow nachfragen müssen, gehört Ihre Anwendung nicht dazu.