[AlternC-dev] Devcamp 3.3 - J-20

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Alban Crommer alban at octopuce.fr
Mer 12 Mar 10:59:14 CET 2014


OK. Donc sur des questions qu'on va se poser sur un ou 2 ans là :)

En l'état je pense 

----- Original Message -----
> From: "Remi" <remi+tech at b6.be>
> To: "Liste de Développement de nouvelles fonctionnalités pour AlternC" <dev at alternc.org>
> Sent: Tuesday, March 11, 2014 1:19:38 PM
> Subject: Re: [AlternC-dev] Devcamp 3.3 - J-20
> 
> On Tue, 11 Mar 2014, Alban Crommer wrote:
> |>     - ergonomie/toussa. Alban, j'ai besoin d'un retour rapide de
> |>     savoir
> |> si tu as ton pote ergonome qui peut venir, parce qu'il faut que je
> |> sache
> |> si je "monopolise" mes deux devs web pour qu'ils viennent. Si le
> |> 14/03
> |> c'est toujours flou, je risque de pas pouvoir les kidnapper.
> |
> |Aucun ergonome qu'on connaît ne peut venir en semaine, WE only.
> |Mais. Sur quels points veux-tu les interroger ?
> |Entre maintenant et le début du devcamp, on peut leur demander de
> |nous répondre.
> |Ce qui fait qu'on aurait leur retour comme base de discussion le
> |jour du camp.
> 
> Salut,
> 
> Au niveau de l'ergonomie, ça mériterait presque une liste dédiée pour
> se
> poser les questions pour la V4.
> 
> Il faut repenser en profondeur les scénarios utilisateurs.
> 
> Quelques pistes:
> * niveau d'entrée par site ("pack hébergement") plutôt que par
> fonctionnalité:
> 	- je clique d'abord sur le nom de mon site puis je peux gérer ses
> domaines, bdd, listes, statistiques et mails associés
> 	- je crée un pack avec domaine, ça me crée également BDD, ftp, ...
> 
> Ca permet également de regrouper le .com, .net, et .org d'un même
> site, ne
> gérer qu'une seule fois les redirections vers le site principal,
> éventuellement pouvoir migrer un site sans migrer tout le compte.
> 
> Niveau utilisateur, ça aiderait à s'orienter quand on gère différents
> sites au sein d'un même compte.
> 
> Ca permettrait evéntuellement de déléguer la gestion d'un site à un
> autre
> utilisateur.
> 
> * interaction plus fortes entre les différentes fonctionnalités :
> 	visualiser les domaines, comptes ftp liés à un répertoire
> 	faire apparaitre les listes de discussion dans la liste des mails
> existants
> 	
> * identifier les retours d'expérience:
> 	exemple : pouvoir supprimer une adresse de toutes les redirections
> existantes si cette personne quitte l'entreprise,
> 	
> * assistance javascript (autocomplétion, ...)
> 
> * possibilité de personnalisation avancée pour une utilisation en
> marque
> blanche (skin, API, ...)
> 
> * niveau design, il faudrait se baser sur des structurations standard
>> la manière de bootstrap) pour pouvoir avoir une cohérence dans les
> différents styles utilisés, et permettre une meilleure surcharge CSS
> pour
> ceux qui veulent pouvoir personnaliser la mise en page. Ca
> permettrait
> également des approches de design adaptatif (utilisation depuis les
> tablettes, smartphones, ...). Ca nécessite de revoir tout le code
> déjà en
> place.
> Je ne dis pas non plus qu'il faut utiliser bootstrap car c'est assez
> lourd
> de kilooctets.
> 
> * rester simple:
> je n'aime pas trop la gestion DNS de Gandi/Plesk/... où on n'est
> jamais
> sûr d'avoir bien appliqué les changements...
> 
> Il faudrait au niveau de chaque fonctionnalité étudier le scénario
> précis:
> que veut-on faire? que fait-on en réalité?
> 
> Exemple : Je veux rajouter le domaine example.net AlternC détecte que
> example.com existe déjà : "voulez-vous associer ce domaine en alias
> de
> example.com?" : hip hop, redirections 301, ajout dans le pack.
> "Voulez-vous également rediriger les mails @example.net vers
> @example.com?" etc.
> 
> Il faut également réfléchir à la gestion DNS de celle des
> virtualhosts
> (séparer ces 2 fonctions?) afin de simplifier ces fonctions et éviter
> les
> mauvaises manip ("oups je viens de supprimer tous mes mails")
> 
> De manière générale, il faudrait s'inspirer de qui se fait chez
> webmin ou
> plesk pour voir les erreurs à ne pas répéter (liens cachés et
> difficiles
> d'accès) tout en regardant ce qu'il pourrait nous manquer
> fonctionnellement.
> 
> Au niveau design pur (je ne parle plus d'ergonomie), il faut arriver
> à
> donner à AlternC un peu plus de gueule, mais c'est une autre
> question.
> 
> Remi
> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://lists.alternc.org/listinfo/dev
> 


Plus d'informations sur la liste de diffusion Dev