Bonjour,
Aspectize est une startup qui propose une nouvelle approche de développement d’applications web html5.
L’architecture et l’approche de développement sont assez différentes de ce qui se fait par ailleurs (état et production de Html dans le client, serveur stateless, binding déclaratif,…).
J’aimerais avoir vos avis:
Merci pour vos retours,
Bonjour.
J’ai parcouru (je l’avoue, rapidement) la documentation du site et j’avoue avoir peu compris de choses.
Tout d’abord, il y a tout un bloc de documentation (Read about Aspectize) qui n’explique nullement le comment faire une application (aussi simple soit-elle). C’est pour moi un gros défaut, car la plupart des personnes vont commencer à se faire une idée sur le produit par ces pages. Grosso-modo, l’idée que ça donne est : « Oui, il y a plein de texte qui montre que le produit est le meilleur qu’il soit, etc., mais où est la preuve ? »
De plus, on ne connait pas le produit et peut-être pas le fonctionnement (architecture) qu’il y a derrière. Dans ce cas, mettre plus de schémas expliquant le pourquoi du comment. Une bonne solution est d’ajouter un exemple concret (même si c’est la todo-list classique) où chaque étape (architecture, binding, etc.) est expliquée.
Pour la partie tutoriel, je n’ai pas été très loin, car là on va directement dans l’implémentation avec l’IDE. Cette partie me semble bien, mais les « testeurs » jugeront mieux de la pertinence.
Sinon, donner les prérequis à avoir pour développer sur ce système (au moins C#, JS, il me semble). Sinon, on pourrait se perdre.
Enfin, j’ai deux questions sur le système lui-même, ça dépasse un peu la question initiale du sujet, mais pourrait peut-être aider dans la réalisation de la documentation.
Pour répondre à la deuxième question : non, ça ne me donne pas envie d’essayer pour les raisons expliquée ci-dessus.
Désolé de ce commentaire peu mélioratif, mais je préfère être franc. La technologie pourrait peut-être m’intéresser, mais la partie la plus compliquée à faire (=la doc ;)) n’est pas au point.
Si je ne suis pas clair sur des propos ou pas assez spécifique, je pourrais (encore) détailler.
Bonne chance.
Merci pour ce commentaire, c’est tout à fait dans l’esprit de ce que j’attendais; ce n’est pas évident quand on est dedans de savoir où ça pêche, et c’est pour avoir des pistes d’améliorations comme celles énoncées que j’attends du feedback.
Alors pour répondre un peu aux différents points;
Et mes réponses aux 2 questions;
Je suis content de lire que la partie la plus compliquée à faire est la doc, je m’en doutais un petit peu;-).
Du coup, quel serait un bon exemple à suivre, en matière de doc ?
je pense qu’il faut simplifier le “Get started” à l’extrême comme ceci par exemple : http://ionicframework.com/getting-started/ Après une fois que le gars la installer tu peux mettre de la documentation (c’est très bien) . Mais l’ordre c’est attrapé les gens , convertir puis ensuite mettre la documentation.
Parce que le public au dela des intégrateurs et des décideurs c’est le développeur; Si la promesse produit est la simplicité et avec cela la productivité. Il faut que cela puisse être perçu dans la présentation du produit.
Il faut a tout prix éviter le mur de la complexité même si le produit me semble énorme et très bien abouti il faut simplifier je pense et la documentation “complexe” doit être visible plus loin dans le site.
Super exemple, très inspirant, merci !
Effectivement, on a pris un peu trop le parti de s’adresser à des décideurs et ou architectes (c’est sans doute notre culture qui veut cela), et à la réflexion, cela vaudrait le coup de séparer les choses: un parcours décideur (bénéfices business), un parcours architecte (tous les liens actuels du GetStarted), et un parcours développeur (avec un truc super simple à la ionic). Puis les tuto plus complets. Il y a presque toute la matière, je vais réorganiser ça dans ce sens.
Merci pour le “même si le produit me semble énorme et très bien abouti”, ca fait plaisir, et c’est très encourageant !
:) je suis sincère on voit qu’il y a beaucoup de travail derrière beaucoup de texte et tout. Maintenant il faut rendre tout cela vendable et sexy . Donc effectivement je pense que ce qu’il manque c’est rendre cela simple.
Scénario : “un développeur à testé rapidement un hello world/ get started” il envois un mail à un pote .
Forcément il veut pas que son pote se prennent trop la tête. Il faut un lien qu’il puisse balancer et installer rapidement le truc (si possible) et ensuite tester deux trois trucs “wow effect” qui accroche le gars et la tu as une “boucle viral” au niveau dévelopeur.
Pour le niveau “B2B” Décisionnaire je m’y connais moins dans le processus mais même pour eux il faudrait une page dédié. Et à la limite les atteindre par LinkedIn et voilà envoyé les liens par ce biais.
Avec Rapportive envoyé des liens directement chez les SSII genre Cap etc. la ou les gens pourrait intégré. Bref il faut bien identifié les cibles et ensuite leur parler et simplifié pour créer une boucle viral.
La rétention se fera par la qualité du produit ou l’avantage concurrentiel.
Je te fais un retour en mode candide, j’ai parcouru ta home page et j’ai pas lu la discussion de ce thread pour pas être influencé :
A ta place je partirais vraiment de cette question :
Imagine une discussion avec un dev à un meetup, tu lui explique ta solution en 2 mots. Il te répond un truc du genre "Ha, donc c’est un genre de Heroku ?"
Probablement que c’est à coté de la plaque, poses par écrit comment tu lui expliquerais la différence avec ton outil. Ensuite essayes d’identifier quel est le bénéfice numéro 1 de ta plateforme. L’idée c’est d’accrocher mon attention avec ça dès la première page.
“Developers and architects, discover how to create valuable software within minutes and bring your projects to the next level of agility”
Quand je lis ça je m’ennuie et je n’apprend rien : cette même phrase pourrait se trouver aussi bien sur le site d’IBM, de Ionic, de Clever Cloud, etc
Dis moi précisément pourquoi ta solution est géniale :
exemple de description dont tu devrais t’inspirer
Ionic :
The beautiful, open source front-end SDK for developing hybrid mobile apps with HTML5.
Bootstrap :
the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web.
Exoscale :
The best cloud hosting platform for SaaS companies, developers and sysadmins.
Bref tu vois l’idée.
Tu as de très bonnes remarques dans les messages précédents, je complète ma réponse en fonction de la tienne.
Conseil qu’on m’a donné quand on essaye de faire une documentation :
Encore un pavé à lire, désolé et bonne chance. ;)
Je ne pense pas que les startup ont un problème avec l’architecture de leur code, et j’ai du mal a comprendre le principe du framework avec le site.
Si j’avais a lancer un nouveau projet, en tant que développeur, je choisirai tout sauf ce genre de produit.
Dans une startup, il n’y a pas d’architecte. Il n’y a que des développeurs qui baignent dans l’opensource. A ma connaissance, très peu partent sur des technologies microsoft …
Quel est le véritable objectif pour ce framework ? Et a qui t’adresse tu réellement ? Est-ce que tu dois vraiment cibler les startup et les développeurs ? Peut-être que le produit est plus adapté à des opérationnels métier qui veulent passer de la feuille Excel a une vraie application construite par eux-mêmes ?
Merci pour ton feedback.
Je réponds tout de suite à ta dernière remarque, car notre plate-forme s’adresse bien à des développeurs, qui savent coder, et qui comprennent le html/css, et pas des opérationnels métiers.
En ce qui concerne les startups, ce qu’elles recherchent;
Les entrepreneurs qui ont déjà des développeurs sous la main, vont utiliser les techno que leurs développeurs connaissent, et ils auront raison de valoriser la personne plutôt que la techno (ta remarque comme quoi tu choisirais tout sauf notre produit si tu avais lancer un nouveau projet va bien dans ce sens; tu vas privilégier ce que tu connais).
Pour les entrepreneurs qui n’ont pas de développeurs sous la main, ce n’est pas tout à fait la même chose, et on fait beaucoup de services en étant pour eux leur “Technical Angel”. C’est vrai que ça peut prêter à confusion sur le site, il se trouve que nous avons beaucoup de références dans les startups à ce jour (mais pas seulement, nous travaillons aussi avec des éditeurs et des grands comptes), car nous avons une vraie proposition de valeur sur les points mentionnés précédemment.
Concernant Microsoft et les startup, il y en a, il suffit de regarder le programme Bizspark.
L’objectif du framework est de délivrer vite des applications web et mobile, avec une architecture dans les règles de l’art, ce qui s’adresse à beaucoup de monde… effectivement, ce n’est pas facile.
Suite à vos feedback, nous avons fait une petite page supplémentaire qui montre la mise en oeuvre sur un exemple simple (la même todo-list qu’Angular, je pense que la comparaison est intéressante):
http://www.aspectize.com/AzureHostManager/site=the-beginning
Ok, la je comprends beaucoup mieux et c’est très clair pour un développeur !
Et du coup nouvelle question : pourquoi utiliser ce produit par rapport à AngularJS ? Le code m’a l’air plus verbeux, et a première vue je ne trouve pas d’avantages par rapport à AngularJS (mais je suis sûr qu’il y en a :p)
Comme dit ci-dessus, c’est bien plus clair et agréable à lire.
Et comme dit ci-dessus: quel est l’avantage par rapport à AngularJS, car la logique, l’objectif et le rendu m’ont l’air d’être les mêmes, mais plus compliqué. D’ailleurs, mets tes services dans une variable, car voir aas.Services.Browser.xxxService à chaque appel de service complique la lecture à mon goût.
Enfin: j’ai cru que Aspectize permettait de faire du serveur et client, mais ici, on n’a que le client, non ? Car ça pourrait être le plus vis-à-vis d’AngularJS.
Bonne continuation.
Merci pour vos retours.
Donc, effectivement, on rentre bien en concurrence avec Angular…
Et on a quelques avantages:
Pour ce qui est de la complexité, je pense que nous sommes beaucoup, mais beaucoup plus simple; j’entends bien vos feedback, qui me disent que ça a l’air plus compliqué, et j’aimerais bien creuser ce point un peu plus avec vous, car, cela devient un problème pour moi si je pense une chose, et que les feedbacks me disent le contraire (et cela veut dire que je dois continuer à améliorer le site et mon discours). J’ai repris le même exemple de la todolist, pour que justement, la comparaison puisse se faire de façon claire, donc pouvez-vous me dire de façon plus précise en quoi est ce plus compliqué ?
@kneelnrise: concernent les aas.Services.Browser.xxxService, tu touches exactement le point disruptif de notre approche; il s’agit bien de configuration, et non de code, et même si ça peut paraitre un peu verbeux au premier coup d’oeil (je reconnais que les retours à la ligne dans la page web gachent un peu le plaisir), je te garantie que c’est beaucoup facile à maintenir que du code javascript (Angular ou n’importe quel techno MVC client). Le coté répétitif vient du fait que c’est l’intellisense de Visual Studio qui a permis d’écrire cette configuration en 2 secondes, et il faut voir l’expérience dans Visual Studio pour s’en rendre compte (on a aussi le projet d’intégrer l’intellisense dans Ace pour avoir la même expérience online, et peut être qu’une petite vidéo montrant le travail dans Visual Studio aiderait sur ce point).
Si d’ailleurs certains sont intéressés, nous organisons un Meetup sur Paris la semaine prochaine, l’occasion de voir la techno en live: http://www.meetup.com/fr/Aspectize-Paris-Meetup/events/223436554/
Je veux bien te croire sur le facteur 50, mais le problème, c’est qu’ici, on voit l’inverse. Le facteur 50 est surement vrai à partir d’un certain volume.
Puis, pour le côté serveur, je veux juste dire qu’ici, on ne le voit pas, et donc on se dit qu’on n’a aucun intérêt vis-à-vis de Angular (je pense notamment à AngularDart ou Angular2 qui ont vraiment améliorer leurs architectures). Et malheureusement, je trouve qu’utiliser 5 fichiers pour une todo list, c’est beaucoup (dans ce cas précis, peut-être pas dans une application complexe).
Par contre, pour le système de configuration, j’ai un peu de mal à voir l’intérêt, car manque de recul sur la technologie, et si je suis dans ce cas, je pense que plusieurs développeurs vont aussi prendre peur.
Super pour le meetup, mais étant Nantais et en semaine, je ne pourrai pas y aller. Par contre, s’il y a des vidéos, je suis preneur. ;) D’ailleurs, je pense que discuter avec des nouveaux et plus anciens sur la technologie et leur demander comment ils la décriraient, enseigneraient pourrait aider à améliorer ces docs.
PS: je ne sais pas si je suis clair quand je critique les documentations, mais tout ce que je dis est à prendre comme « Quel est mon ressenti lorsque je lis la doc ? » et non « Est-ce que cette technologie est réellement bien ? ». Je ne peux pas critiquer ce que je ne connais pas.
Merci beaucoup,
c’est exactement ce que j’attends de nos échanges, et ça m’aide beaucoup, merci encore.
pour le 5 fichiers pour un todolist, ça fait beaucoup, oui, je suis d’accord. Et comparons avec Angular qui en a 3:
Et ce qui est plus intéressant à comparer:
Notre fichier controls est totalement agnostique des binding (data et behavior), je fais du html standard, je n’ai pas apprendre des conventions d’attributs ng-click, ng-repeat, ng-model (que je trouve compliqués), et je ne pollue pas mon UI avec des choses, qui pour moi, n’ont rien à y faire, donc je peux la réutiliser dans d’autres contextes (principe du contrôle, avec la souplesse du layout déclaratif). De plus, en regardant d’un peu plus près, je ne comprends pas comment le remaining() et le todos.length sont mis à jour coté Angular, ce n’est pas clair pour moi, je ne comprends pas les dépendances qui sont créées ici, ni la mécanique d’appel de mon code; à quel moment mon code va t il être appelé ?
service.js est du code javascript standard, qui traite des données en mémoire et uniquement des données (ou des éléments du DOM si j’en ai besoin), je maîtrise ce qui rentre et ce qui ressort de mes fonctions, je n’ai pas de @Controller (que je ne comprends pas non plus dans Angular, mais je reconnais que j’ai toujours eu du mal à comprendre les contrôleurs dans les techno MVC).
view.js est purement déclaratif, cela m’intéresserait de comprendre pourquoi ça peut faire peur (sans doute parce que c’est nouveau ? Le déclaratif est quelque chose qui est souvent recherché dans les techniques informatique, car c’est source de beaucoup moins de problèmes que le code). On y voit exactement l’association des Data et des propriétés, d’une part, et l’association des Command et des événements d’autre part. C’est explicite et sous contrôle, et tout est fait comme ça dans l’appli, d’un bout à l’autre (et je n’ai pas à rentrer dans une dimension de $scope, qui, bien que non présente dans l’exemple de la todolist, arrive très vite, et qui, pour le coup, me fait vraiment peur dans Angular).
Voilà, c’est extrêmement difficile de se faire une idée d’une techno, qu’elle quelle soit, en très peu de temps. Moi-même, je n’ai pas fait cet effort jusqu’au bout pour Angular, j’ai essayé mais j’ai très rapidement buté, je ne comprenais pas en le faisant, pourquoi je devais mettre telle chose à tel endroit, et comment ça fonctionnait. Il y a une courbe d’apprentissage pour n’importe quel sujet, et mon objectif est bien d’essayer d’améliorer la notre. Et ça m’intéresserait beaucoup d’avoir du feedback de personnes qui connaissent bien Angular (on en a eu certains à nos derniers Meetup, et leurs retours étaient très enthousiastes, mais online, c’est une autre histoire :-) ).