Layout-Editor für Objective C denkbar?

[macblum]

Moin,

eine Frage an die Programmierer/Developer:

ich erwarte eigentlich, dass es mittelfristig Editoren geben wird, mit denen man Apps für das iPhone, bzw. noch besser iPad generieren kann.

Ähnlich wie man das mit z.B. Dreamweaver oder Flash machen kann. Das sind ja letztlich auch nur Layoutprogramme für's Web.
Oder gibt es technische Gründe, warum das bei iApps nicht funktionieren sollte?

Oder konkreter: wird der Grafiker in Zukunft Zeilen programmieren müssen oder bekommt er ein vernünftiges Tool (z.B. ab der CS6 oder 7)

Ich bitte darum, die Frage ernst zu betrachten –*nicht philosophisch.

Danke für konstruktive Antworten.

Servus,

macblum

 

[miss.moxy]

Wenn du schon die Entwickler und Programmierer fragst, solltest du auch deren Forum aufsuchen, ich glaub nicht, dass die sich im DTP verirren

Konstruktiv verschubselt.

 

[bitcontroller]

Er wird auch in "Zukunft Zeilen programmieren müssen"...

 

[ildfar]

Um nicht nur Unsinn zu erzeugen, muss man doch auch im Flash und Dreamweaver "Zeilen programmieren"?

 

[macblum]

So, so ...

Aha,

das war mir nicht bewusst. Bin alter "Print-Designer" und meine Web-Erfahrung liegt schon lange zurück.

Ich hatte DW und FL mehr zugetraut.

Ich glaube nur nicht, dass zukünftige ePapers "programmiert" werden. Und ich glaube auch nicht an eine reine Content Management-Lösung. Das ist mir zu unkreativ ...

Danke für Eure Einschätzung und Gruß,

MacB

 

[iCode]

Suchst Du etwas um Klassendiagramme oder etwas um eBooks zu layouten?

 

[carstenj]

Hi,

Ich hatte DW und FL mehr zugetraut.

wieso "mehr" zugetraut? Wie komplex sollte denn deiner Meinung nach ein "Klick-meine-Applikation-zusammen"-Tool sein? Für richtig optimierte und individuelle Programme wird man wahrscheinlich auch in den nächsten 50 Jahren nicht drumherum kommen, die ein oder andere Zeile von Hand zu programmieren.

Es gibt heute schon etliche Werkzeuge und Standards, mit denen man ala Visio seine Applikation oder Geschäftsprozesse zusammenklickt. Je nach Wunsch kommt Java, C++ oder Objective-C heraus, aber für manche Routinen ist sowas einfach zu abstrakt.

 

[Darii]

Ich glaube nur nicht, dass zukünftige ePapers "programmiert" werden.

Naja werden sie ja jetzt auch nicht...das iPad benutzt wohl EPUB.

Oder meinst du generell Anwendungen. Da ist die Antwort wohl klar nein. Du könntest natürlich graphisch programmieren(so was gibt es ja schon, z.B. Labview), allerdings wird das ab einer gewissen Komplexität auch nicht gerade einfacher. Flash kommt übrigens auch nicht ohne Programmieren aus.

 

[yankadi]

Aha,

das war mir nicht bewusst. Bin alter "Print-Designer" und meine Web-Erfahrung liegt schon lange zurück.

Bin auch alter "Print-Designer" (schon fünf+ Jahrzehnte), habe mich allerdings immer weiter entwickelt. Ist ja inzwischen kein Problem mehr, sich selbst schlau zu machen.

Niemand muss "Zeilen" schreiben, um Oberflächen zu programmieren. Interface Builder sei Dank.

Das ist nichts Neues. Diese Technik gibt es schon seit Anfang der neunziger, und Jobs hat das mit NeXT erschaffen.

 

[_ebm_]

Sicherlich kann man heute schon sehr einfach grafische Oberflächen zusammenclicken. Das Hauptproblem ist das Verhalten der Oberfläche! Woher soll denn ein solcher Interfacedesigner wissen, was der geneigte "Programmierer" mit dem gerade abgelegten Button anfangen will? Die sogenannte Businesslogik wird sicherlich noch seeehr lange von Hand geschrieben werden! Einzig diverse Standard-Komponenten (wie zum Beispiel das File-Open-Widget) enthalten schon das Verhalten. Das hat aber irgendwann einer vom Apple programmiert und zur Verfügung gestellt.

Nichtsdestotrotz ein interessanter Exkurs!

 

[wegus]

Niemand muss "Zeilen" schreiben, um Oberflächen zu programmieren. Interface Builder sei Dank.

Das ist sicher so richtig und es macht auch Sinn Designer designen zu lassen und eben Programmierer programmieren zu lassen ( man sieht was herauskommt wenn beide das Andere versuchen ). Allerdings müssen sich an der Schnittstelle beide der Probleme des anderen bewußt sein. Man kann kein ProgrammGUI designen ohne nicht zumindest eine Ahnung von der Problematik dahinter zu haben und man kann auch keine GUI-Software schreiben ohne sich um deren Präsentation zu kümmern.

Der InterfaceBuilder ist ein gutes Beispiel, denn er macht weit mehr als nur das Aussehen eines Dialoges festzulegen. Er legt für den Programmierer bereits Actions und Outlets fest die zu realisieren sind.Er definiert Objekte die zu realisieren sind, greift auf Datenquellen zu u.s.w.

Kurzum: mit Design-only kommt man da nicht weit!

 

[macblum]

Moin,

ja, im weitesten Sinne geht es um ePapers*– oder wie auch immer man in Zukunft digitale Magazine/Broschüren/Kataloge/etc. nennen wird.

Wie oben schon erwähnt ist es ebenso wenig vorstellbar, dass der Programmierer "Seiten" (oder "Screens?") designt oder der Layouter/Designer Zeilen programmiert.

Das würde auch kaum in einen verlegerischen Workflow passen. Einige Tageszeitungen können natürlich ein programmiertes Gerüst mittels Content Management System mit Inhalten versorgen, aber wer möchte denn bitte so anspruchsvoll gestaltete Monatstitel wie die Vogue, GEO oder ähnliche "programmieren"???

Da sind doch Layout-Tools zu erwarten, mit denen Redaktionen arbeiten können ... und dafür sind – auf's Internet übertragen – Dreamweaver & Co sinnvolle Anwendungen, oder etwa nicht? Nur gibt es sowas noch nicht für iPad und Objective-C. Und es kann doch nicht das Ziel sein, jede Woche eine individuell gestaltete Spiegel-App zu programmieren ...

Gruß,
MacB

 

[wegus]

Das was Du meinst/suchst sind in der Tat Content-Management-Systeme

Das hat mit Programmierung wenig zu tun. Die werden installiert und betrieben von einem Admin. Ein Designer ( der zumindest der Gestaltungssprachen des Web mächtig sein muß) verpaßt dem einmal ein Design und der Rest sind Redakteure die die Dinger mit Online-Inhalten füllen. Genau so funktionieren spiegel/focus/sueddeutsche/zeit/...
Ein spiegel.de wird also eben genau nicht programmiert! Da sitzen nur n Redakteure und m Admins! Das liegt vor allem darin begründet das CMSe eben eher weniger Seitenorientiert sind (das gibt es auch ist aber nicht die Regel). Beim Print-Design denke ich gestaltet man jede Seite explizit ( so wie wir das als Schüler bei der Schülerzeitung früher mit Rubbelbuchstaben und mit Fixogum zusammengeklebten Seiten gemacht haben). Bei CMSen definiert man einfach Elemente (Überschriften, Tabellen, Teaser-texte, Bildrahmen, ...) die dann die Content-Redakteure nurmehr auswählen und verwenden. In der Regel haben die eben mit der Gestaltung überhaupt nichts mehr zu tun.

Was besondere Printmedien angeht die eben auch auf optische Wirkung hin produziert werden, so bin ich mir sicher das deren Klientel es auch in 10 Jahren schätzen wird eine Ausgabe auf Papier in den Händen zu halten.

Ich z.B. lerne lieber mit einem Buch das ich neben dem Rechner liegen habe und in dem ich blättern textmakern und kritzeln kann, statt mit einem e-Book!

 

[macblum]

Naja werden sie ja jetzt auch nicht...das iPad benutzt wohl EPUB.

Hi Darii,

ich halte epub für keine ernsthafte Variante mit ausreichenden Gestaltungsmöglichkeiten. Mehr als die Darstellung von Büchern wird damit (derzeit) kaum möglich sein. Aber vielleicht mit "epub 3.0"

Gruß,
MacB

 

[macblum]

Hallo Wegus,

deine Ausführungen über CMSe sind natürlich richtig. Und damit lassen sich auch durchaus Web-Seiten befüllen. Und deshalb sieht das alles auch so langweilig aus ...

MacB

 

[wegus]

ich weiß, aber bedenke: Programmierung macht man nur weil man mit einmal Aufwand n mal schnelle Resultate haben will! Das Verfahren Print-Layout wird sich also nicht so auf programmierte Layouts übertragen lassen. Da greifen andere Mechanismen ( wie XML,XSL,XSLT oder HTML/CSS).

Das klassische Printlayout wird niemand "programmieren" wollen weil der Kosten/Nutzen-Effekt sich nie einstellen wird. Da sind Tools wie Photoshop oder Animatoren ( mittels Flash, Shockwave oder was auch immer) das Mittel der Wahl.

 

[Darii]

ja, im weitesten Sinne geht es um ePapers*– oder wie auch immer man in Zukunft digitale Magazine/Broschüren/Kataloge/etc. nennen wird.

Was spricht jetzt gegen PDF + x-beliebiges schon existierendes Layoutprogramm?

 

[macblum]

Da sind Tools wie Photoshop oder Animatoren ( mittels Flash, Shockwave oder was auch immer) das Mittel der Wahl.

... wenn denn alle Tablets Flash darstellen könnten ...

Kann denn eine App so programmiert werden, dass sie einem Layouter verschiedene Darstellungsformen zur Verfügung stellt, die dieser mit Inhalten aus dem CMS füllt, dabei aber aus verschiedenen Vorlagen kombinieren kann?

"Textfeld 1" mit "Bildfläche 3" und "Bildunterschrift 7" ...

Also ein standardisiertes Layout, dass aus so vielen Kombinationsmöglichkeiten besteht, dass sich immer wieder neue Ergebnisse zusammenstellen lassen? ("so viele" und "immer wieder" mal relativ betrachtet.)

Gruß,
MacB

 

[macblum]

Was spricht jetzt gegen PDF + x-beliebiges schon existierendes Layoutprogramm?

Dass das altbacken aussähe, nicht auf die Form der Ausgabegeräte angepasst und unpraktisch in der Anwendung wäre ...

Die ständige rein und raus-Zoomerei macht ja nicht wirklich Spaß ... also auf Dauer!

Gruß,

MacB

 

[Darii]

... wenn denn alle Tablets Flash darstellen könnten ...

Zum Glück können sie es nicht. Sobald sich HTML5-Video erstmal durchgesetzt hat werde ich froh sein endlich Flash abschalten zu können…

Kann denn eine App so programmiert werden, dass sie einem Layouter verschiedene Darstellungsformen zur Verfügung stellt, die dieser mit Inhalten aus dem CMS füllt, dabei aber aus verschiedenen Vorlagen kombinieren kann?

Klar. Es ist wäre z.B. auch kein Problem eine Webseite so umzusetzten, dass sie sich automatisch an das iPad anpasst, da braucht man keine „App“ für.

Dass das altbacken aussähe, nicht auf die Form der Ausgabegeräte angepasst und unpraktisch in der Anwendung wäre ...

Die ständige rein und raus-Zoomerei macht ja nicht wirklich Spaß ... also auf Dauer!

Wo ist das Problem? Man kann die PDFs doch an die Größe der Anzeigegeräte anpassen. Da muss man nichts zoomen. Man kann auch innerhalb der PDFs Verweise haben also sollte es möglich sein per Klick auf ein Bild zum entsprechenden Artikel zu springen.