Packprogramm

[michanismus]

Du darfst gerne weiter den langsamen und stressreichen Weg über die Kontextmenüs gehen, wenn Du darauf beharrst, dass dieser schneller ist.
Ich jedenfalls weiß aus Erfahrung durch Beobachten anderer Leute, dass jede Benutzung des Kontextmenüs eine Unterbrechung im Arbeitsfluss darstellt (die der Benutzer selber vielleicht gar nicht bemerkt, das Bewusstsein arbeitet bei solchen Sachen ja immer nur nachgeschaltet).
Probier doch mal mit TheGIMP 1.x (nicht 2.x, da haben sie das korrigiert) zu arbeiten, dann verstehst Du vielleicht wie ungeeignet Kontextmenüs sind.

also ich bin für ferien anstatt mir gedanken zu arbeit zu machen

 

[lengsel]

Probier doch mal mit TheGIMP 1.x (nicht 2.x, da haben sie das korrigiert) zu arbeiten, dann verstehst Du vielleicht wie ungeeignet Kontextmenüs sind.

Ich bin ja durchaus für Gegenargumente zugänglich, aber so ein "Worst-Case-Scenario" in Sachen Usability wie Gimp 1.x als Beispiel anzuführen ist schon ein bisschen billig. Wenn Du sonst nichts anzubieten hast...
Schönes Gegenbeispiel ist Qcad. Hier ist der ständige Wechsel von Rechts und Linksklick absolut intuitiv und wesentlicher Bestandteil der Bedienideologie. Ich kenne wenig Programme mit denen sich schneller arbeiten lässt.
Ich denke wir kommen bei dem Thema eh auf keinen gemeinsamen Nenner, lassen wirs bevor wir hier weiter die Leute mit nem OT-Thema verwirren.

Grüße,
Flo

 

[PealEagel]

Ich merk gerade das das ein heißes Thema ist

 

[t_h_o_m_a_s]

Ich merk gerade das das ein heißes Thema ist

...ach was, da musst du mal im Forum nach "Partitionieren" suchen
Gruß h.

Ich habe übrigens aus diesen Diskussionen schon sehr viel gelernt.

 

[PealEagel]

stimmt nach und nach versteht man das so langsam

 

[two42two]

...
bitte vergiß stuffit gleich wieder, wenn was gescheites dann unrar x ...
da ist das interne zip von X noch besser als stuffit ...

grüsse

two42two

 

[PealEagel]

habe ich mir auch jetzt besorgt

 

[Ulfrinn]

...
bitte vergiß stuffit gleich wieder, wenn was gescheites dann unrar x ...
da ist das interne zip von X noch besser als stuffit ...

grüsse

two42two

Ein Vorzug von StuffIt ist, daß man den Ressourcenzweig mit verpacken und komprimieren kann. Außerdem erzielt StuffIt höhere Kompressionsraten als Zip. Ergo sollte man es besser nicht „gleich vergessen“ …

 

[abgemeldeter Benutzer]

@ Ulfrinn
Die interne Packfunktion von Mac OS X packt auch den Resourcen-Zweig und die Metadaten des Dateisystems. Jedoch in einer AppleDouble-Codierung (als ._-Dateien in einen Unterordner __MACOSX).
Das Problem dabei ist, dass ältere Stuffit-Versionen die beim Auspacken nicht wieder richtig zusammenfügen.
Die Komprimierungsrate ist nach dem, was ich getestet habe, in etwa gleich.

 

[Mitraix]

Ot

@._ut: Leider hat Apple jetzt selbst die PDF-Steuerung (vergrößern, verkleinern, in Vorschau öffnen) für Safari nur in einem Kontextmenü verpackt, über die Menüleiste kommt man gar nicht ran...

 

[mkninc]

Näher vielleicht nicht, aber dafür besser und schneller erreichbar.

Hast du eine spezielle Mac OS Version, bei der das Ablage-Menu in einer der Bildschirmecken liegt?

Von einem beliebiegen Punkt auf dem Bildschirm, kommt man per "motorischem Gedächtnis" mit Sicherheit nicht ins Ablage-Menu. Nur die Ecken kann man wirklich schnell erreichen.

 

[abgemeldeter Benutzer]

@ Mitraix
Ja, ich weiß. Ich halte es sowieso für einen großen Fehler, dass Apple in Safari das Mosaic-Bedienkonzept beibehalten hat und Safari nicht zu einem richtigen Mac-Programm gemacht hat. Das habe ich schon mehrfach in diesem Forum kritisiert.

Der allererste Internetbrowser "WWW" vom Cern (welcher auf NeXTStep lief) hatte ein besseres Bedienkonzept, als Mosaic (nämlich doppelklickbare Links und Manipulation über Menübefehle). Das Bedienkonzept von Mosaic (einfachklickbare Links und Kontextmenüs; lief zuerst auf X11) wurde dann mit der Verbreitung von Netscape (vom gleichen Programmier) zum Quasi-Standard. Apple hätte die Gelegenheit nutzen sollen, mit Safari ein besseres (mehr Maclike) Konzept einzuführen. Das haben sie aber verpasst. Schade.

@ mkninc
Doch, da der Mauszeiger in der horizontalen vom Bildschirmrand geführt wird. Nur die Ecken sind noch besser und schneller zu erreichen.

 

[Ulfrinn]

@ Ulfrinn
Die interne Packfunktion von Mac OS X packt auch den Resourcen-Zweig und die Metadaten des Dateisystems. Jedoch in einer AppleDouble-Codierung (als ._-Dateien in einen Unterordner __MACOSX).
Das Problem dabei ist, dass ältere Stuffit-Versionen die beim Auspacken nicht wieder richtig zusammenfügen.
Die Komprimierungsrate ist nach dem, was ich getestet habe, in etwa gleich.

Das die integrierte Zip-Funktion ebenfalls die AD-Kodierung anwendet war mir bisher nicht bekannt – Danke für den Hinweis!
Bzgl. der Kompressionsrate muß ich allerdings sagen, daß ich da andere Ergebnisse bei mir gesehen habe. Das waren schon teilweise gute 5 - 7 % Unterschied.

Leider hat Apple jetzt selbst die PDF-Steuerung (vergrößern, verkleinern, in Vorschau öffnen) für Safari nur in einem Kontextmenü verpackt, über die Menüleiste kommt man gar nicht ran...

Das kann ich auch nachvollziehen – Ich würde nämlich nicht wollen, daß ein Plug-In die Menüleiste des Programms, in das es eingebunden ist, übernimmt.

 

[abgemeldeter Benutzer]

@ Ulfrinn
5-7% fallen für mich noch unter statistische Unschärfe.
Außerdem hat die integrierte Funktion den Vorteil, dass sie sehr schnell ist und kostenlos. (DropStuff ist ja Shareware im Gegensatz zum Expander.)

Was die PDF-Steuerung betrifft: Dann hätten sie wenigstens ein kleines Zahnrad-Button-Menü in die Ecke setzten sollen. (Speziell, da PDFs gar nicht mehr über ein Plugin angezeigt werden.)

 

[mkninc]

Doch, da der Mauszeiger in der horizontalen vom Bildschirmrand geführt wird. Nur die Ecken sind noch besser und schneller zu erreichen.

Aber wenn es nicht in einer Ecke liegt, sondern nur an einem Bildschirmrand, ist der Geschwindigkeitsvorteil gegenüber eines Kontextmenüs dahin.

Der allererste Internetbrowser "WWW" vom Cern (welcher auf NeXTStep lief) hatte ein besseres Bedienkonzept, als Mosaic (nämlich doppelklickbare Links und Manipulation über Menübefehle).

Doppelklicks sind unter Usability-Gesichtspunkten aber auch nicht sonderlich intuitiv.

 

[Ulfrinn]

@ Ulfrinn
5-7% fallen für mich noch unter statistische Unschärfe.
Außerdem hat die integrierte Funktion den Vorteil, dass sie sehr schnell ist und kostenlos. (DropStuff ist ja Shareware im Gegensatz zum Expander.)

Naja, wenn man aus Faulheit mal grössere Datenmengen durch’s WLAN quetschen will, kann diese „statistische Unschärfe“ sehr nützlich sein.
Aber das Shareware-Argument lasse ich voll gelten. Wenn man nur gelegentlich packt oder es auf die Grösse nicht so exakt ankommt, ist die integrierte Funktion sicherlich die bessere!

Was die PDF-Steuerung betrifft: Dann hätten sie wenigstens ein kleines Zahnrad-Button-Menü in die Ecke setzten sollen. (Speziell, da PDFs gar nicht mehr über ein Plugin angezeigt werden.)

Jein, wenn ich bei mir Plugins deaktiviere, geht auch die PDF-Anzeige nicht mehr – Sie bleibt grau. Insofern scheint dieser Teil von Cocoa von Safari wie ein Plugin behandelt zu werden. So eine Zanradschaltfäche, wie sie ja auch das Schubert-IT-Plugin bietet (wenn ich mich richtig erinnere – das ist schon so lange her ), ist durchaus praktisch. Vielleicht folgt das ja in einer der nächsten Versionen.

 

[abgemeldeter Benutzer]

Naja, wenn man aus Faulheit mal grössere Datenmengen durch’s WLAN quetschen will, kann diese „statistische Unschärfe“ sehr nützlich sein.

Dabei kommt es aber wohl auch auf die zu komprimierenden Daten an. Bei meinen Tests hat die ZIP-Funktion des Finders besser komprimiert, als Stuffit: https://www.macuser.de/threads/kleine-dmg-erzeugen.61540/#post-509431

Jein, wenn ich bei mir Plugins deaktiviere, geht auch die PDF-Anzeige nicht mehr – Sie bleibt grau. Insofern scheint dieser Teil von Cocoa von Safari wie ein Plugin behandelt zu werden.

Nicht so bei Tiger/Safari 2.0. Hier werden PDFs in Safari angezeigt, auch wenn die Plugins deaktiviert sind.

 

[abgemeldeter Benutzer]

Aber wenn es nicht in einer Ecke liegt, sondern nur an einem Bildschirmrand, ist der Geschwindigkeitsvorteil gegenüber eines Kontextmenüs dahin.

Da tauscht Du Dich.
Die Position bestimmt nur die Größe des Klickpunktes (unendlich hoch und endlich breit vs. unendlich hoch und breit). Sobald der Klickpunkt in einer Richtung unendlich groß ist, gibt es den Geschwindigkeitsvorteil (davon auszugehen, dass der Klickpunkt eine gewisse Größe in der anderen Richtung hat. Daher ist die Lösung mit der horizontalen Menüleiste in Mac OS auch besser, als die Lösung in NeXTStep mit der vertikalen Menüleiste, bei der die Klickpunkte nur 16 Pixel hoch sind.)
Das Ganze hat allerdings direkt nichts mit dem "motorischen Gedächtnis" zu tun. Das funktioniert in beiden Fällen, das Menü wandert weder, wenn es am Rand liegt, noch wenn es in der Ecke liegt auf dem Bildschirm herum, noch ändern sich die Positionen der Menüpunkte.
Das Kontextmenü hätte einen Geschwindigkeitsvorteil gegenüber beiden (denn es ist ja ganz ohne Mausbewegung erreichbar), wenn sich die Menüpunkte nicht kontextbezogen verändern würden und wenn es nur möglich wäre, 20, 50 oder 100 Menüpunkte dort sortiert unterzubringen.
Das weiter oben erwähnte TheGIMP 1.x setzt Kontextmenüs nur konsequent ein. Das lengsel so genannte Worst-Case-Szenario ergibt sich aus der Natur des Kontextmenüs.

Doppelklicks sind unter Usability-Gesichtspunkten aber auch nicht sonderlich intuitiv.

Einfachklicks, die direkt einen Link öffnen aber noch weniger.

 

[Ulfrinn]

Dabei kommt es aber wohl auch auf die zu komprimierenden Daten an. Bei meinen Tests hat die ZIP-Funktion des Finders besser komprimiert, als Stuffit: https://www.macuser.de/threads/kleine-dmg-erzeugen.61540/#post-509431

Das ist eine grundlegende Eigenschaft eines jeden Kompressionsalgorithmusses.

Nicht so bei Tiger/Safari 2.0. Hier werden PDFs in Safari angezeigt, auch wenn die Plugins deaktiviert sind.

Hm, doch war bei mir unter Tiger so. Konnte es aber jetzt bei der Probe auf’s Exempel nicht mehr feststellen. Jedenfalls wurden bei mir nach der Umstellung auf Tiger keine PDFs mehr angezeigt. Ich habe dann in den Voreinstellungen gesehen, daß Plugins deaktiviert waren. Ich habe sie folglich aktiviert und Safari neugestartet. Danach klappte die Anzeige wieder. Aber andererseits hatte ich Plugins auch nie deaktiviert … – Oder sind die das standardmäßig? kopfkratz

 

[mkninc]

Das Ganze hat allerdings direkt nichts mit dem "motorischen Gedächtnis" zu tun. Das funktioniert in beiden Fällen, das Menü wandert weder, wenn es am Rand liegt, noch wenn es in der Ecke liegt auf dem Bildschirm herum, noch ändern sich die Positionen der Menüpunkte.Das Kontextmenü hätte einen Geschwindigkeitsvorteil gegenüber beiden (denn es ist ja ganz ohne Mausbewegung erreichbar), wenn sich die Menüpunkte nicht kontextbezogen verändern würden und wenn es nur möglich wäre, 20, 50 oder 100 Menüpunkte dort sortiert unterzubringen.

Die absolute Position der Menüpunkt ist nicht so entscheidend, denn mit verbundenen Augen kann man keine Variante zuverlässig bedienen. Die einzelnen Menüpunkte müssen nur in einer vorhersagbaren "Erwartungszone" auftauchen. Beim Kontextmenü ist diese "Erwartungszone" genauso vorhanden, wie bei der Menüzeile. Denn das Kontextmenu zeigt, wenn es im selben Kontext aufgerufen wird, ja auch die gleichen Befehle. Das heißt bei häufiger Nutzung, entwickelt man diese "Erwartungszone", wo der Befehl auftauchen wird. Für Gelegenheitsnutzer ist diese Sache sowieso egal, die müssen so oder so, genau schauen wo ein Befehl steht.

Das weiter oben erwähnte TheGIMP 1.x setzt Kontextmenüs nur konsequent ein. Das lengsel so genannte Worst-Case-Szenario ergibt sich aus der Natur des Kontextmenüs.

Bei TheGimp 1.x sind es technisch gesehen Kontextmenüs, inhaltlich sind sie völlig überladen, weil eben nicht nur kontextbezogene Sachen darin enthalten sind, bzw. der Kontext viel zu gross gewählt ist. Deshalb hat es ja auch 2-3, und mehr Ebenen.

Wenn Kontextmenüs sinnvoll eingesetzt werden, nur eine Ebene und nur die am häufigsten benutzten und kontextbezogene Befehle, ist es jedenfalls schneller, als wenn man die Befehle nur über die Menüzeile erreicht. Es sind weniger Mausbewegungen nötig, und innerhalb des Menüs navigiert man bei beiden Varianten über die "Erwartungszonen".

Einfachklicks, die direkt einen Link öffnen aber noch weniger.

Vielleicht sollte eine Maus auch einfach mehr Tasten haben, ein zum "Selektieren", eine zum "Ausführen/Aktivieren".