Développement de l'App Market!

Ok alors ça va être un gros chantier mais il devient indispensable, cet App Market est quelque chose qui doit être implémenté dans YunoHost. Le but est de remplacer la liste d’application affichée lorsqu’on veut installer une nouvelle app et de fournir un outil simple, beau, efficace et moderne pour parcourir le catalogue d’applications, les officielles comme celles gérées par la communauté. Suite à la discussion sur ce post il est temps de commencer à réfléchir là dessus!

Le travail sera long et fastidieux car il s’agira d’éditer toutes les apps pour les rendre compatible avec ce nouveau market. Un long travail mais qui n’est pas compliqué, loin de là! Le développement de ce market est donc un moyen très facile de contribuer au projet. :wink:

Beaucoup de points sont à discuter / valider avant de ce lancer dans les travaux; c’est le but de ce topic. Une fois qu’une idée précise des fonctionnalités attendue sera faite une roadmap sera établie et le boulot pourra commencer.

On va donc maintenant discuter des fonctionnalités qu’on aimerait retrouver dans un tel outil, sans se soucier de la charge de travail à effectuer pour que le market voit le jour


Les tags

Pour naviguer dans les 80+ applications disponibles une manière de filtrer les applications dans le market est indispensable. Le filtrage sera effectuer à partir de tags, qui ont l’avantage de pouvoir facilement catégoriser une app selon toutes ses fonctionnalités, ce qui aurait été plus difficile avec des catégories.
Il faut donc établir une liste de tags (fermée car les traductions doivent être présentes) et ça se passe sur ce pad. La liste est déjà assez solide, et awesome-selfhosted est une très bonne source d’inspiration. On pourra aussi avoir des tags du genre Essentiels, Framasoft etc.
Les tags seront à rajouter dans le manifest.json de chaque app.

Les infos

Le market doit être en mesure d’informer le plus possible l’utilisateur sur l’app. Quelles informations sont à afficher ? Ces champs seront à remplir dans le manifest.json de chaque app.

  • Le site officiel de l’app
  • Le code source de l’app
  • L’adresse du package
  • Le mainteneur de l’app (avec le mail)
  • Le niveau de l’app
  • Démo de l’app ? Je pense que oui: la première chose que l’on fait quand on découvre une nouvelle app à rajouter à son serveur est d’aller voir la démo
  • Lien vers le post du forum concernant l’app ? Peut être utile lorsqu’on a une question ou un problème, aller voir s’il a déjà été résolu

Les images

Comme sur la maquette de @TomaKlod ici, ça serait bien de pouvoir visualiser des screenshots d’une app avant de l’installer. Il faudrait rajouter un dossier “screens” ou “images” sur le repo de l’app et adapter le code de list_builder en conséquence.

Il faut aussi ajouter un fichier icon au dépot, qui sera utilisé pour afficher l’app dans le market et pourquoi pas aussi dans le portail. J’avais comme idée d’afficher chaque app avec une “tuile”, avec simplement le nom, une petite description et le logo, comme ça:


Des guidelines pour les icones seraient sympas, au moins pour les officielles, comme par exemple le logo de l’app au centre avec une couleur unis autour, pour pas que ça rende trop moche sur le market / sso.
Puis lorsqu’on clique dessus un popup s’ouvre avec la gallerie de screenshot et toutes les infos définis plus haut.
N’hésitez pas à proposer des idées de design !

Le nom

Est-ce qu’on part sur le classique “App Market” comme nom ? Ou en trouve un à la YunoHost ? :wink:


Il faut donc se mettre d’accord sur tous ces points, avant qu’une roadmap soit établie et qu’on puisse commencer le chantier. Toutes propositions ou avis sont les bienvenus !

Cheers!

4 Likes

YunoMarket bien sûr :sunglasses:

Plus sérieusement, super post, très complet je trouve.
Concernant les démo, pour les apps officielles, on à la démo YunoHost éventuellement (ou à défaut).

Pas grand chose à ajouter sinon.

2 Likes

Salut, très bonne idée oui !

Pour le market, je pense qu’il faut le publier à deux endroits:

J’aime bien le Market de Jeedom qui est bien foutu : https://www.jeedom.com/market/index.php?v=d (et apparait à la fois dans le jeedom local et sur le oueb)

Ce market indique en plus de ce que tu proposes:

  • La comptabilité matérielle
  • Lien vers la doc
  • Lien vers le topic unique du forum (ou git chez nous par exemple)
  • Langues disponibles
  • Dates de mises à jour
  • Changelog

Certaines de ces choses (et de celles que tu proposes) peuvent en effet apparaitre dans le manifest, mais d’autres pourraient être récupérées via API autrement (niveau, date de maj, lien github, …). Pour les icones et screenshots on pourrait rajouter à la racine du repo ? icon.png (l’icone), screenshot1.png, screenshot2.png, … (avec un script qui parse tous les screenshots pour les afficher)

La démo de l’app je vois pas encore trop comment on pourrait faire ca …

2 Likes

Pour la demo, il faudrait que quelqu’un héberge(ou bien le mainteneur) une demo par app.

Ça serait lourd est peu stable/viable.

J’aurai tendance à dire que si une démo existe pour le logiciel, on renvoie vers le site. Sinon pas de démo, mais peut être un lien vers une vidéo de présentation ?
Après tout, c’est très utile pour se faire une idée du besoin, mais avoir des captures d’écrans, une vidéo de présentation, le site officiel, ça donne déjà beaucoup d’informations.

1 Like

+1

Même pas besoin, l’application pourrait ne simplement pas s’afficher si le matériel n’est pas compatible (ex: un logiciel sans paquet pour ARM).
Quoique, y’a peut-être le problème d’une dépendance type php à mettre à jour.

+1, dans une catégorie plus d’infos par exemple (ex: on clique sur l’app, esa page s’ouvre avec plus de détails).

Par contre, au lieu de devoir gérer le changelog (par exemple) côté mainteneur par exemple (ça fait du boulot en plus, donc une charge pour un bénévole, qui peut démotiver) pourquoi ne pas mettre un lien vers le github, quitte à intégrer directement un fichier changelog déjà présent ?
Idem pour la date de mise à jour, récupération automatique depuis le github (quoique, pas forcément aisé à devenir)

Quelques réactions en vrac:

Auquel cas, applications officielles plus celles considérées comme fonctionnelles ? Ou les expérimentales en plus, avec un signal visuel spécifique ?

  • Le code source: eu… pourquoi ? Le manifest serait différent de celui du github par exemple ?
  • Adresse du package: idem
  • Pour la démo, cf. mon post ci-dessus.

Par rapport aux images et plus particulièrement à la gestion de l’empaquetage pour cette fonctionnalité, pour moi le principal inconvénient se situera au niveau de la charge de travail pour intégrer un logiciel.
L’idée est excellente en terme d’accessibilité du logiciel, d’avoir des captures d’écrans et un lien vers le site c’est tellement plus parlant et rapide pour un utilisateur que de chercher sur le site pour sur les divers dépôts (qui ne sont pas harmonisés).
Cependant, une charge de travail trop importante augmenterait de facto la charge de travail du(des) mainteneur(s). Et contribuerai à renforcer le côté silo de Yunohost. Tant qu’il reste faible (genre une installation sans adaptation nécessaire, et une petite pour intégrer le SSO) ce n’est pas gênant, après ça devient bloquant pour l’ajout de nouveaux logiciels.
Plus c’est simple à intégrer/maintenir, plus il est attirant.

Donc avoir à créer une image (ok, c’est pas grand chose, mais ça reste une tâche de plus) gérer un json avec plusieurs spécificités à mettre à jour (ex: le changelog, c’est lourd de le faire plusieurs fois).
(par contre, si cette image existe ou si la génération peut être automatisée, ça serait joli sur la page d’acceuil de l’utilisateur :slight_smile: )
Pour les logiciels officiellement supportés, pourquoi pas, en les mettant en valeur dans les premiers résultats de la recherche/dans un espace séparé. (comme ça, on a directement la hiérarchie du support)

Coucou,

mes deux centimes, mais je pense qu’un point important est de faire en sorte que l’app soit retrocompabtile avec les manifestes existants, qui à pas afficher les infos si elles sont pas là. Ca me parraît pas jouable ni souhaitable de se dire qu’on releasera pas le market tant que toutes les apps connues n’ont pas toutes changer leur manifeste (ou bien de rendre obsolète les apps qui ne l’ont pas updaté)

2 Likes

Je valide entièrement le projet !

Concernant les îcones pour l’app, ne devraient-elles pas figurer aussi dans les app de l’interface utilisateur dans ce cas (à la place des deux premières lettres de l’app actuellement utilisées). On pourrait inclure un svg monochrome pour garder une cohérence dans l’experience utilisateur (et si c’est que pour les officielles, ça permettrait de les distinguer des non-officielles)

YunoHost Kiosk ?

Je pense que les mainteneur devraient eux-mêmes trouver les icônes pour leurs apps, incluses directement dans le repo de l’app sur github.

Bonjour, c’est beau projet !

Merci de penser aux traductions, cependant je ne comprends pas le lien entre le fait de la traduire et d’avoir une liste fermée. Il faut déterminer qui complète cette liste, comment c’est actualisé et comment ça s’intègre dans les traductions actuelles, mais ça ne sera pas obligatoirement une liste fermée.

Je suggère de dissocier le concept d’étiquette (tag) de celui de catégorie (category). L’étiquette est un élément thématique, tandis que la catégorie est une structure organisationnelle.

Comme on a Simone pour s’occuper de notre documentation, j’aimerais bien un mot français pour parler de ce “Apps Market”, et comme le terme marché c’est un peu trop propre et que ça fait référence à trop de termes économies, je suggère l’idée du bazar qui me semble mieux refléter l’aspect communautaire. Ça permet aussi une référence à un livre connu : La Cathédrale et le Bazar — Wikipédia

1 Like

@theodore : L’idée du Kiosk me fait un peu penser au défunt FramaKiosk (enfin, “défunt”, je sais pas trop, mais plus maintenu en tout cas). Du coup je préfère YunoMarket, même si ça fait un peu lourd à prononcer.

Je pense qu’il vaudrait mieux afficher les apps incompatibles (pour cause d’architecture processeur p.ex.), mais signalées d’une certaine manière – sinon l’utilisateur risque de ne pas comprendre pourquoi l’app n’apparait pas.
Et pour ce qui est de la démo, si on demande au mainteneur de l’héberger, par expérience on aura un 404 au bout de six mois – mieux vaut rediriger vers la démo officielle de l’app à mon avis.

EDIT :
@jibecfed : J’avais pas vu ton message, mais je suis tout à fait d’accord avec toi sur la connotation de “market”. Bazar c’est pas mal… mais ça fait désorganisé en même temps… quel casse-tête :slight_smile:

Et au final, pourquoi lui donner un nom type market alors que c’est juste une page référençant les logiciels (certes, en plus jolie :slight_smile: ) ?
Je veux dire, c’est quoi la différence fondamentale avec la page de la doc actuelle ? (ça et ça)
Les apps ne sont pas stockées quelques part, on va juste afficher ce type de liste directement dans l’interface d’administration.
Y’a-t-il un quelconque besoin d’un nom ? (à part en interne peut-être)

Je suis plutôt partant également pour le status quo de ne pas lui donner de nom, car ce n’est effectivement qu’un changement graphique de la liste des apps.
Mais je pense que tôt ou tard nous aurons le souhait de le nommer.

Toutefois, j’ai comme souvent une aversion pour le nom français :fr: bien de chez nous :fr: pour avoir une liste d’application française :fr: pour les amis francophones :fr: :fr: de la francophonie :fr: :fr: :fr: française :fr: :fr: :fr: :fr: :fr:

PS: :fr: :fr: :fr: :fr: :fr: :fr: :fr: :fr:

Eu… la proposition originale n’est-elle pas en anglais ?
Et Yunohost n’est-il pas traduit par soucis d’accessibilité ?

Une rivalité persistante avec jibecfed :wink:

J’ai une préférence pour les noms communément utilisés et connus.
J’aurais une préférence, le cas échéant, pour des noms de type market ou store, qui sont sans équivoque quand au contenu. Même si la popularité de ces noms est issue de grands acteurs qu’on cherche à éviter.

La francisation systématique est source de débats récurrents entre moi et jibecfed.

1 Like

Perso je suis pas non plus fan de la francisation systématique, après ca me choquerait pas d’apeller ca le “Kioske d’applications” (ca a ni la dimension économique de Marché, ni la dimension ‘bordelique’ de Bazar). Après en pratique, les gens y feront surement reference dans les discussions comme l’App Store ou App Market j’imagine :confused:

D’accord, mais qu’on utilise dans la version anglaise store, market ou quoique ce soit d’autre, quel impact sur la traduction ?
Je veux dire, ce n’est pas comme si on utilisait un nom français pour la version anglaise - qui ne serait pas forcément compris.
Traduit dans les deux (et autres) langues, c’est compris par tout le monde.

Bref, moi ce qui me gêne avec les nom de store, market et dans une moindre mesure kiosk (car on l’assimile moins vite à ça), c’est que ça fait magasin d’application, alors que c’est juste une présentation différente de ce qui existait déjà, et qui ne fait que référencer les logiciels disponibles sur github.
La liste des apps actuelle n’a pas de nom, pourquoi en mettre un dans ce cas ? On reste dans l’interface d’admin’ de Yunohost.

Oui et si le terme d’app store à toujours tendance à me hérisser le poil, car me rappelant toujours cette cale d’armoire avec une pomme croquée sur une face, force est de constater que le nom est dénué de toute référence au vilain démon blanc. Et donc tout à fait viable

Car je pense que tôt ou tard, à l’usage, il finira par hériter d’un nom.
Mais rester sur la liste des apps me convient très bien.

Il y a clairement un certain côté hype / swag / comm’ à appeller ca App Market (ou autre). Après, on peut quand meme argumenter que l’objectif est aussi de pouvoir chercher plus facilement (e.g. filtrer dynamiquement avec des tags j’ai l’impression ?) dans les apps plutôt qu’une bête liste à scroller. Dans ce sens là, tu peux argumenter que tu fais comme dans un marché où tu cherches / trie activement pour trouver ce qui te convient…