App erstellen für wbb 4.1

    Ich für meinen Teil würde immer eine App dem reponsiven Design vorziehen, sofern ich die Seite öfters besuche.
    Reponsive Desings sind zwar schon super, aber Apps sind halt nochmal einen ordentlichen Ticken optimierter und vorallem schlanker. Nebenbei hat man halt noch den dicken Pluspunkt der Pushnotifications und ggfs der live tiles.


    Sicherlich stampft man eine App nicht aus dem Boden, aber - hier spreche ich für mich - ist diese relativ simpel mit Angular und Cordova umzusetzen. Den WCF-Teil sehe ich hier - aus meiner Perspektive - als größeres Problem. Nicht nur weil ich mit dem WCF nicht warm werden will (Laravel <3), sondern weil eine solche API schon recht mächtig sein sollte.

    Sagen wir es mal so:
    Im Prinzip brauchst du alle Daten, die der Benutzer hier im Frontend sieht ;) Vom Login, über Profile, Accountverwaltung, Boards, Beiträgen, (dis)likes usw :D Natürlich muss alles auch an die entsprechenden Rechte gekoppelt sein.
    Da kommt schon ein ordentlicher Batzen an Quellcode zusammen :D

    Das da ein ordentlicher Batzen zusammenkommt ist mir schon bewusst, es ist aber keine schwere Arbeit und man kann das ganze relativ gut abstraktieren :)


    Also wenn du mal irgendwann Bock hast sowas umzusetzen und eine API brauchst, melde dich ^^

    Naja, prinzipiell auch alle DatabaseObjects, die Actions muss man triggern können und so weiter. ^^
    Dann muss man teilweise noch auf die Utils zugreifen können. Alles bestenfalls performant und nicht gecached.
    Eine Schnittstelle um an alle Dateien ran zu kommen zwecks Avatar, Attachments, anderweitige Bilder und Downloads...

    Das wäre definitiv ein sehr sehr interessantes Projekt. ;) Jedoch für "nebenbei" ist es mMn zu komplex und als Serienproduktion nicht effektiv. Jede App müsste individuell gepflegt, designed und vorallem erstellt werden. Ich befürchte, dass man hier leider sehr schnell auf den Boden derTatsachen zurückgeholt wird.

    Exakt. In meiner Version arbeite ich direkt mit DB-Queries, da ich dafür keine Anbindung ans WCF brauche. ^^
    Anmelden und Datensätze ändern geht damit. Ist zwar unschöner Code, aber ohne Ressourcen geht's leider nicht besser.

    Sobald man eine API hat kann man eben open-source dran arbeiten, was ich auch bevorzugen würde, dann muss sich das halt jeder selbst zusammen bauen und sich mit den Stores rumschlagen. Evtl. findet sich ja dann eine Firma (cls-design, DevLabor, MysteryCode, what ever), die einem dass dann gegen Geld abnehmen. Und man müsste noch einen Push-Server betreiben, Authentifizierung und so einen Kram. Das sollte man dann zumindest zentral haben, ich greife da auf PushBots zurück und eine selbstentwickelte Analysis-Engine ANAL (Automatic Notification Analysis Layer) zurück, gibt mittlerweile aber auch schon deutlich bessere und einfachere Lösungen.


    Alles in allem nicht nur Aufwand zur Entwicklung, sondern auch die Infrastruktur dahinter.



    Zitat von Josh

    Und dort habe ich vorhin mal xCode angeworfen (damit entwickelt man die Apps für iOS) und war schlicht überfordert. Eine kleine Spiele-App würde ich da wahrscheinlich auch nach ein paar Stunden Tagen hier und da mal rumprobieren hinbekommen, allerdings nichts worauf ich stolz wäre. Also nichts sauberes, sondern wahrscheinlich nur gepfusche, wie es richtige iOS-Entwickler nennen würden.

    Tja, das mag beim ersten Mal so sein, aber die IDE ist perfekt auf diesen Zweck abgestimmt und anders als Eclipse, das ist universal. Beim ersten Mal gings mir aber auch so, kann ich nachvollziehen.

    Wow, ihr seid super, auch wenn ich innerlich drei Kreuze gemacht habe, dass ich zum Glück nie darüber nachdenken muss, ob ich etwas entwickeln könnte/müsste oder nicht. :whistling: :D


    Wenn wir schon hier sind, kann ich euch noch ein wenig weiter belagern und ihr wärt so nett bei Gelegenheit wieder eure Einschätzung zu formulieren? Das Thema ist ja nicht unattraktiv und ich könnte mir vorstellen, es gibt genug Mitleser, die von fachlicher Meinung profitieren können. :)


    @dannyfilth: Knuff mich sofort, wenn ich zu viel frage, ja? :) Es ist dein Thema und soll es auch bleiben, aber ich überlege, ob wir nicht die Rückmeldungen hier nehmen und unverbindlich Marcel Werk bzw. Alexander Ebert ansprechen sollten. Wir sagen nicht, sie sollen das mal flott basteln, am Besten gestern, sondern wir fragen einfach nach ihrer Haltung zu einer App, ob sie das Thema nicht komplett unnötig finden und es Chancen hätte auf ihre To-Do-Liste zu kommen? Nur, ohne Argumente können wir dort nicht hingehen, das muss Hand und Fuß haben, also hören wir erst mal noch hier den Fachlern zu, ich notiere mögliche Argumente und wenn es schlüssig ist, würdest du hingehen und fragen wollen? :blume:





    Ich stelle zuerst einige Fragen, dann liste ich mögliche Argumente auf, die für eine WCf/WSC-basierte App sprechen, ihr kommentiert, zerpflückt bzw. sagt, wo es haken könnte, in Ordnung? :)




    1. Wir müssten für die App an die WCF/WSC API herankommen und brauchen dazu, wie Flo sagte, den ganzen Frontend-"Kram". Ist das im Wesentlichen das, was in der technischen Dokumentation auf den 122 Seiten steht, ohne die Erklärungen dazu, wie man ein eigenes Paket schnürt? Für WSC holt man sich das über Github, dort steht alles und man muss es nur irgendwie bündeln, fertig?



    2. So, wie ihr das erklärt habt, so funktionieren auch diese DiY-App-Baukästen? Ich habe hier nachgeschaut http://www.websitetooltester.com/blog/app-baukasten/ und natürlich heißt es stets, es wäre sehr einfach, die Preise im Monat moderat usw. Nur, die Beispiele gehen von Websites aus, wir haben Community Software, also passt das schon einmal gar nicht für den Anwendungsfall hier? Auch wenn man es selber macht, ohne API muss man sich keinen der Baukästen ansehen?



    3. Das http://www.forumrunner.net/ funktioniert auch für phpBB, bringt uns aber auch nichts, weil WCF anders gebaut ist, das sind zwei unterschiedliche "Baustellen"?



    4. Für mich zum Verständnis: xenForo hat das hier https://xenforo.com/community/…xenforo-php-rest-api.902/, was also bedeuten würde, damit könnte man eine xf-App bauen? Wenn ihr dort auf die Inhalte klickt https://github.com/Contex/XenA…/REST-API-Actions#actions, könnt ihr daraus ablesen, ob es das ist, was Flo mit den sichtbaren Frontend-Inhalten meinte? Ich sehe schon die Erklärungen, aber mehr auch nicht, mir sagt die Liste also nicht, ob das reicht, nicht reicht und wenn etwas fehlt, was es wäre. :blush:






    Ich hatte ja gefragt, ob wir eigentlich eine App brauchen, wenn wir responsives Webdesign haben. Flo hatte geantwortet, also macht es einen Unterschied und daher können wir es nicht ignorieren. Jetzt nehmen wir hypothetisch an, trotz deines berechtigten Einwandes, Josh (dass eine App nicht billig wäre und das Klientel nicht allzu groß sei), wir wollten die Woltis von der Umsetzung überzeugen. Folglich brauchen wir Argumente und ich habe versucht erste Punkte zu notieren. Ihr seid die Fachler, also taugen die Argumente etwas oder nicht (seid bitte sehr kritisch, im Ernstfall müssen sie vielleicht wirklich der Überprüfung von Marcel Werk und Alex Ebert standhalten) bzw. wie würdet ihr die App positiv bewerben? Halten wir fest, was uns einfällt:



    1. Eine App ist schlanker bzw. spezifisch konstruiert, um optimal der Smartphone-Nutzung entgegenzukommen (das waren Flo's Argumente)


    2. Push-Nachrichten sind möglich, erlauben zielgerechte Ansprache, Werbung usw. (ebenfalls Flo's Argument)


    3. "Live Tile"-Funktion ist möglich, erlaubt so die individuelle und interaktive Zusammenstellung (noch einmal Flo's Argument)


    4. Klientelgewinnung (Generation Smartphone versus reine Desktop-Nutzer/Tablet-Nutzer)


    5. Effektive/Schnelle Erreichbarkeit (Argument: Smartphone ist i.d.R länger/dauerhaft an, im Gegensatz zu einem Desktop-Rechner)


    6. Kundenbindung über individuelle App-Module und/oder spezielle Angebote (QR-Code zum Einscannen, z.B. dann darüber Rabatte im Shop)


    7. (In-)direkte Werbung auch für WoltLab (App aus dem eigenen Haus plus sichtbares Logo = bleibt im Blick und Hinterkopf)


    8. Zeitfaktor (das Smartphone ist länger an als ein Rechner, also schnellere Nutzung = schnellerer/häufigerer Besuch = Zeitersparnis als Argument zur Nutzung, vgl. mit "Zeit ist Geld")


    9. Kein "Umweg" über einen App-Store (direkter "Vertrieb")


    10. Keine Betriebssystem-Begrenzung und/oder Beschränkung auf einzelne mobile Endgerätes (Argument: Gleiche Optik und Funktionalität für alle)


    11. "State of the art"-Charakter (Argument: Apps sind heute normal, gehören regelrecht dazu, also gehört es quasi zum guten Ton und um sich gegenüber Konkurrenzanbietern abzuheben, dass man eben auch eine WoltLab-App anbietet)


    12. Individualisierung möglich (zielgenau definieren, was Besucher/Kunden sehen, was neu ist bzw. nicht erst lange manuell updaten müssen)







    Das wären dann meine Vorschläge, ihr seid dran. :)

    • Im Prinzip müsstest du das WCF/WBB nachbauen - mit dem Unterschied, dass du bei dem Aufruf einer URL z.B. kein Userprofil angezeigt bekommst, sondern nur die "Rohdaten".
      Diese Rohdaten werden dann von der App verarbeitet und entsprechend angezeigt.
      Gleiches gilt natürlich auch für Aktionen wie "likes", "reports", "comments" und sämtlichen anderen Features. Auch hier muss eine Schnittstelle erstellt werden. Wie du merkst, ist das nicht wenig.
      Woltlab müsste nichtmal eine App zur Verfügung stellen.. ich denke, dass sie da ganz andere Baustellen haben und die Ressourcen anders besser genutzt wären.
      Mit einer hauseigenen API würde ich da schon mehr liebäugeln. Ich denke, dass sich mit einem solchen Schritt viele neue Wege/Märkte eröffnen.
    • Aus Prinzip:
      Ist ein Baukasten => ist Schmu! ;) Und vollkommen korrekt:
      Keine API = keine App
    • Auch hier korrekt. Jede Software ist individuell zu behandeln.
    • Auf den ersten Blick sieht die API wie etwas aus, was wir hier bräuchten. Allerdings halt nur für die falsche Software. :P