[rohrpost] Reminder: 1st Bachelors? Prize for Net-Literature // deadline 30. September 05

[sascha brossmann]

on 9/1/05 12:05 AM, Florian Cramer wrote:
> Nicht mal damit wäre ich einverstanden, weil es "computer interface"
> unzulässig aufs Nutzerinterface reduziert. Tatsächlich umfaßt der
> Begriff "Interface" aber noch viel mehr:

ja und nein, denn dabei orientierst du dich praktisch ausschliesslich
am ingenieurwissenschaftlichen gebrauch, der zwar momentan für alles
was mit rechnern zu tun hat, vermutlich die grösste definitionsmacht
besitzt, m.e. aber etwas unglücklich ist, nicht zuletzt auch mangels
trennschärfe. das ist ein ähnliches problem wie beim gekidnappten ;-)
begriff 'interaktion'. der ingenieurwissenschaftliche, technische
interfacebegriff ist maschinen- oder vielleicht besser artefakt-
zentriert. durchaus nachvollziehbarerweise, denn das ist deren
eigentliche domäne. der von mir ins spiel gebrachte *zweite*
interfacebegriff ist menschenzentriert. ich bin der meinung, dass man
hier differenzieren muss, beides führt in der betrachtung zu recht
unterschiedlichen qualitäten und die beiden termini sind nicht in
jeder hinsicht kompatibel, wie sich auch hier in der diskussion zeigt.

> Ein Kriterium eines guten Nutzerinterfaces ist dabei - wenn Du mich
> fragst -, daß es auch als API taugt und umgekehrt.

diskord: ein gutes API ist zwar automatisch auch ein gutes
benutzerinterface, denn der benutzer ist i.d.r. programmierer (im
herkömmlichen sinn) und ein gutes API hilft ihm, die intendierte
handlung (i.d.r. programmierung von anwendungssoftware) 'besser' zu
erreichen, salopp: macht ihm das leben leichter.

der umkehrschluss ist aber nicht gerade belastbar:

ich habe durchaus einige kritik am GUI in seiner derzeitigen variante
und seinen metafern, dennoch kann man imnsho behaupten, dass es
innerhalb der jeweiligen rahmenbedingungen gelungene visuelle
nutzerinterfaces gibt, die dennoch, bzw. *gerade deswegen* ganz und
gar nicht als API geeignet sind.

ebenfalls ein wohl unbestritten exzellentes nutzerinterface (mit z.t.
unterschiedlichen spezialisierungen bezüglich der intendierten
handlung) sind stiel und kopf eines hammers. schon von 'code' zu
sprechen dürfte aber in diesem fall schwierig werden, es sei denn, man
gräbt die zu recht wieder ad acta gelegte und iirc primär im
strukturalismus wurzelnde idee, alles als 'text' zu'lesen' wieder aus.
ansonsten: ein hammer mit API? <g>

> Ein API muß nicht zur Laufzeit zugänglich sein und sich auch nicht
> sinnlich direkt mitteilen.

somit erfüllt es auch nicht alle kriterien für den 'anderen'
interfacebegriff. :-p

> soziale Handlung äußert sich zwar in der symbolischen Codierung und
> kulturellen Nutzung des Interfaces, aber das Interface modelliert
> apparative Steuerung.

einwand: nicht jeder kommunikationsakt erfordert apparative steuerung.
allerdings fehlt dann in der tat vielleicht auch ein interface.

> Für soziale Handlungen selbst gibt es kein Interface, bzw. wäre dies
> eine fragwürdige Metaphorisierung des Begriffs (also z.B. E-Mail ein
> "Interface" zweier Korrespondent/inn/en zu nennen).

'email' an sich wäre auch ein wenig abstrakt dafür, aber z.b. eine
email-anwendung (genauso wie ein telefon, ein telegraf etc.)
beinhaltet ein interface für eine kommunikationsinfrastruktur, mit
deren hilfe mithin eine soziale handlung ausgeführt wird.

der wesentliche punkt ist (ich beziehe mich nochmal auf das modell von
bonsiepe), interface nicht als die verbindung zwischen zwei objekten
zu begreifen, sondern als den bereich zwischen einem artefakt, einem
sozialem agenten (i.d.r. mensch) und einer _handlung_, der ebenjene
_durch_ das artefakt ermöglicht.

es lässt sich darüber streiten [man sollte das vielleicht auch ;-)],
ob selbst rein symbolische handlungen (à la kommunikation) auch schon
den begriff 'interface' rechtfertigen. ich würde es allerdings nicht
grundsätzlich ausschliessen.

> Einspruch, auch der Code mißt sich an Kriterien wie Lesbarkeit,
> "Wartbarkeit" und Eleganz, die immer auch an menschlicher
> Wahrnehmung und damit am menschlichen Körper ausgerichtet sind.

das kriterium der lesbarkeit gilt aber z.b. nicht für kryptografischen
code. und weder sender noch empfänger (im sinn von shannon/weaver) von
code müssen notwendigerweise zur automatenklasse homo sapiens sapiens
gehören... ;-)

es sei denn, man schränkt code wieder auf programmcode ein, aber dann
wären wir wieder bei einem punkt angelangt, den du meinem verständnis
und meiner erinnerung nach anfangs ja m.e. zu recht _kritisiert_
hattest.

> Die Frage ist, ob man beide tatsächlich kategorisch differenzieren
> kann oder man nicht schon auf der Funktionsebene ständig auf
> kulturelle Semantiken bzw. symbolische "handles" stößt, die Du unter
> "Interface" verbuchen würdest. Das fängt schon beim Binärcode an,
> der auf Shannons Idee gegründet ist, die Boolsche Logik zum
> Interface maschineller Informationsverarbeitung zu machen.

vorschlag: CODE dient zur übermittlung von information. INTERFACE
ermöglicht das ausführen einer handlung. bezieht sich die handlung auf
information, sind überschneidungen nicht zu vermeiden, da
kommunikation und handlung jenseits der mechanischen manipulation
(sic!) von eingabe-/ausgabegeräten zusammenfallen. ich schlage
deswegen des weiteren vor, einen kleinen schritt zurückzutreten und
als betrachtungsrahmen erst einmal von einem *mechanischen*
auszugehen, dann werden die differenzen deutlicher. die anwendung der
begriffe/konzepte im bereich der informationstechnologie ist ein
sonderfall, allerdings ein höchst interessanter, gerade durch die
teilweise (weitestgehende?) konvergenz von handlung und kommunikation.

> z.B. ein piktographisches Nutzerinterface jedoch nur ungleich
> schwerer - und ohne künstliche Intelligenz nicht automatisiert - in
> ein sprachlich-alphanumerisches.

wenn dein interface aus materie besteht, ist das ohne zusätzliche
mechanik aber unmöglich (und dann gäbe es ein anderes interface für
ebendiese, die das vorherige gewissermassen überdeckt).

> meiner Meinung nach sinnvoller wäre, eine zweidimensionale Matrix
> von (a) verschiedenen Ausprägungen von Semantik bzw. kultureller
> Aufladung von Symbolen und (b) verschiedenen Restriktionsgraden von
> Codes zu definieren, anstatt starr von "Code" und "Interface" zu
> sprechen.

das bäte sich vielleicht an, allerdings sähe ich als voraussetzung
eine allgemeinere betrachtung an, die nicht nur auf dem sonderfall
(der allerdings hier natürlich auslösend war) fusst.

> Das funktioniert nicht, rein abstrakte Codes gibt es deshalb nicht,
> weil man Codes nur mit Symbolen ausdrücken kann, die ihrerseits
> semantisch geprägt sind, sowie in Logiken (wie binär oder dezimal),
> die ebenfalls nicht kulturell referenzfrei sind.

darüber muss ich nochmal nachdenken, vielleicht war meine these etwas
zu voreilig. ich vermute aber, du hast recht, denn code != inhalt,
zumindest wenn man shannon/weaver/hamming/... zu grunde legt, und
dieser rein abstrakte code kommt 'inhalt' äusserst verdächtig nahe.
inhalt?! ups... vade retro, satanas! >;->

> (...) wenn man das Wort "Programmierung" nicht durch ein hartes
> Kriterium wie Turing-Vollständigkeit auf elaborierte Steuerungen
> beschränkt.

wobei sich durchaus über die turing-vollständigkeit jedweder
implementierung streiten liesse, was 'natürlich' an der diskrepanz
zwischen mathematischem modell und der endlichkeit der ressourcen
liegt. allerdings ist das erbsenzählerei, ich weiss. ;-) computer in
von-neumann-architektur sind dagegen keine turing-maschinen, auch wenn
dieser irrtum gerne geäussert wird, sondern nur äquivalent. aber ich
schweife ab... eine beschränkung von 'programmierung' mittels
turing-vollständigkeit halte ich für nicht sinnvoll: damit wären
nämlich auch schon einige äusserst nützliche automatenklassen nicht
mehr programmierbar. ich befürchte, das setzt dresche von seiten der
informatiker, und zwar zurecht. <g> zur not muss halt die sprachklasse
deutlich gemacht werden, auf die man sich bezieht.

herzlich


sascha