bonjour,
J'aimerais votre avis (plutôt sur l'ergonomie) d'une application que je développe.
Un ami restaurateur m'a demandé un logiciel de caisse, comme c'est le seul langage que je 'maîtrise' a peu prêt, je l'ai fait en php. Et donc je me suis dit  « pourquoi pas la mettre en ligne et proposer a d'autre restaurant de l'utiliser...»
 
Rendez-vous sur http://www.eresto.net :
Vous pouvez lancer la demo ou bien créer un compte.
 
C'est encore en dév !  
Venez nombreux, Faites péter le serveur  

Il y a un problème de temps de session pour la partie tableau de bord. Je ne sais pas si c'est un problème de script ou de ton hebergeur mais il y a parfois un problème de temps de réponse.

Mais dans le cas présent et de ce que je vois cela a l'air pas mal, peut être qu'il y a des petites chose a voir mais ça a l'air d'être bien penser.

 
Pour la démo ou avec un compte?  
En fait tableau de bord n'existe pas encore c'est juste la page d'accueil apres un login.  

Juste pour la demo j'ai été deco au bout de 30sec et je pense que tu dois lancer un script qui mouline. Il fais quoi a ce moment la lorsque l'ont clique sur "demonstration"?

 
arg tu as raison, j'ai oublié de le remetre sur 2h ... quel con ... je fais la modif.
merci
 
[edit] le temp limite était de 20sec    maintenant c'est 2h
 
[edit2]

le script regarde les session demo, efface celle qui sont perimées puis création des tables mysql.

tu as fais cela juste pour la demo ou un utilisateur normal peut travailler au temps maximum de 2h?

Pour un compte c'est 12h.
 

La prise de commande est 10 000 fois trop lente.
 
Dans un restaurant, chaque 'item' a un numéro que le serveur tappe, puis il valide en appuyant sur une touche (entrée) dans le pire des cas.
 
Pour le reste, ya pas mal de bonnes idées.
 
Je vais mettre en ligne ma propre application dans peu de temps. Elle est finie, mais est encore en phase de test chez l'ami restaurateur chez qui je l'ai installée.

Tien je confirme.
Chaque table à un numéro, il y a un truc aussi c'est que cette application est bien lorsqu'il y a qu'un seul utilisateur mais lorsqu'il y en a plusieurs ça peut poser problèmes. Il faudrait une liste directe des serveurs et pour chaque serveur il y a déjà les tables associé à lui. Le serveur clique directemement sur son nom et il voit les tables qui lui a été attribué et préconfigurer.

 
trop lente ? tu parle du temp de latence d'affichage ou bien de la recherche d'un plat ?
 

 
Tout ça en même temps...
 
Pour prendre une commande, il faut que le restaurateur puisse tapper un bête numéro correspondant à l'Item en question puis appuyer sur entrée. Il faut aussi qu'il puisse choisir 10 fois le même item en faisant : N° de l'item, puis, nombre de fois, puis entrée...
 
Tu aurais du travailler un jour dans un bar ou un restau avant de faire cette application (ou au moins aller voir sur le terrain pour voir comment ça se passe...)
 
Ceci dit, c'est pas perdu hein. Tu peux juste modifier tout ce qui concerne les commandes. Le reste est pas mal du tout.    

 
ca c'est prevu, (identifiant en haut a droite) avec comptes serveurs et compte admin.  

 
lol, j'ai bossé dans la restauration pendant quelque temps...  
C'est le restaurateur qui m'a demandé ca comme ca, lui il trouve cette methode plus rapide (en local) et claire que celle du logiciel Billpro (qu'il utilise).
 

merci  
 
 

mmhh trop long de mettre son login/pass je pense que le pass serait le mieux.
Mais en tous cas cette application est tres bien, tu peux même faire un tour dans des restaurants et le proposer

 
Ben ton restaurateur, il a pas intérêt à avoir bcp de client en même temps

 
Voila ce que je prevoi : l'admin rentre des comptes serveurs -> les comptes serveur apparaissent en menu deroulant (en haut) -> lorsque un  serveurs ce log (avec ou sans pass) ses tables apparaissent.  
 

merci ca fait plaisir

ouais c'est un petit resto (60 places, 100 clients max/services), je vais essayer de trouver une methode plus rapide...

Tiens, un bout de rendu HTML de mon application PHP :
 
http://tousleschats.free.fr/hermes [...] /test.html
 
Tu peux t'en inspirer, mais pas copier
 
Merci...
 
Edit : Appuie sur imprimer ensuite, tu vas avoir une surprise.

ca va que c'est pour un resto, mais personnellement le controle de saisie coté javascript c'est synonyme de travail fait à l'arrache

 
Réfléchis deux secondes avant de parler, tu seras gentil. C'est une APPLICATION client. ça n'a RIEN A VOIR avec un site web.    
 
De plus, tout est controlé ensuite par le serveur.
 
Ce que tu vois là n'est qu'une génération de HTML à partir de mon application en PHP. Tu n'as AUCUNE idée des controls en aval...  

En tous cas c'est sur avec js l'affichage est instantané. Mais moi js... j'y comprend rien...
 
Hermes > Je crois que pour la selection des plats je vais garder mes menus (en plus je me suis bien fait chier pour générer l'affichage EN JS   ), mais je vais ajouter la possibilité, d'une sélection en tapant l'id et la Qté du produit.
 
merci pour vos remarques
 
ps: j'ai vu que certain avez utilisé Opera -> ya pas mal de problème avec .
Qui c'est qui est en israel ?  
 

 
Ben mon code est compatible IE 5.5+ Mozilla 1+ et Opera 7+    
 
Sinon, si tu veux vendre ton applie à d'autres personnes que ton restaurateur, tu as en effet tout intérêt à introduire le système d'ID pour les items.

 
Dès que ca passe sur IE et Moz : pour moi c'est bon  . En fait Opera n'affiche pas mes boutons et ya des problemes avec les liens dans le menu.
Ca me fatigue ces comportements different entre navigateur   ...

T'inquiette pas tu n'es pas le seul.

 
C'est vrai que pour produire des JS compatibles, j'ai du bataillé sévèrement pendant un bon bout de temps, mais à force de persévérer et SURTOUT de ne JAMAIS copier un script mais d'être sûr de tout faire soi-même, on finit par comprendre.
 
Du reste, au niveau du menu par exemple, il n'y a que les CSS qui entrent en compte. Le JS entre moz et opera n'est pratiquement jamais différent.  
 
Sur cette applie, j'ai pu utiliser exactement le même JS pour IE, moz et opera. Dans certains cas très particulier (insert de smiley à la place du curseur dans un forum par exemple), ce n'est pas possible.

 
Au fait, tu as vu pour l'impression dans mon exemple ?  

Que pensez-vous du fait de proposer l'appli uniquement via internet ?
y'a des inconvénients :  
-connections internet (connections down)
-server down  
-latence
-sécu
 
mais y'a aussi des avantages:
-sauvegarde des données
-mis a jours instantané
-support efficace car on peu intervenir sur les databases

 
Tu ne peux pas la proposer UNIQUEMENT via internet. Surtout pour les connections down et/ou la latence (surtout dans ton cas. )
 
Par contre, tu peux installer ton applie sur un serveur CHEZ LE RESTAURATEUR et connecter celle-ci à internet pour que ton ami restaurateur puisse gérer son restau à distance ou encore plus tard, mettre un module pour que les clients eux-mêmes puissent commander ou réserver une table.

 
tu as interet de dire que tu n'es pas responsable de ce qu'il se passe s'il y a une embrouille.

typiquement ce genre d'application de fonctionne pas via internet. c'est quand même quelque chose à installer en local.  
 
Utiliserais-tu un programme de compta via le web ? moi pas. Pas pour des raisons de sécurité, mais je veux avoir la maitrise totale

Tu veux maitriser quoi?
Il y a plus de chance que ton HD crash que celui de l'hebergeur pro.

 
C'est évident. Et puis de toutes manières, le restaurateur va pas dire à son client : Ah ben vous me payerez la prochaine fois, internet est down aujourd'hui

 
Ya ni plus ni moins de chance.  
 
De toutes manières, l'hébergeur pro n'est pas responsable du fait qu'un jour ton FAI te lâche.

- Désolé mais nous avons perdu notre connexion internet parce qu'il y a un virus dans notre machine. Mon petit neveux travail sur l'ordinateur. Vous pouvez revenir payer demain?
- Ben oui oui il y a pas de probleme.

 
je veux être indépendant totalement (du réseau électrique si je pouvais)

tu ve dire quoi ? je comprends pas.  
 

pourquoi faire ?
 
 

Et pour payer en CB ca passe comment ? par le telephone je crois.
 
Consernant, les HD c'est clair que c'est plus sécurisé sur mon serveur ( un VPS au USA (ping ) :
-RAID, Sauvegardes journalières de tout le système.
 
Pour la connection internet du restaurateur : ADSL + backup 56k  (9online, free) ben ya trés peu de chance d'etre down.
 
Et consernant le serveur down: il peu y avoir un serveur de secour qui serait mis a jour journalierement au cas ou.
   
 

propose les deux

 
 
A partir du moment ou ton logiciel va facturer les clients, il faut qu'il soit installé chez lui.  
 
Tant qu'il s'agit de gestion on peut discuter, mais s'il s'agit de facturation, oublie la délocalisation du serveur.  

Aimerais tu que quelqu'un étrangé à ta boite puisse changer l'ensemble des tarifs que tu proposes comme ça le chante?
 

pour ça, il y a des solutions alternatives : une dynamo dans un moulin à vent ou à eau, des paneaux solaires, des générateurs ... En plus, si tu produis plus que ce que tu consomes, tu peux revendre le surplus à EDF. Mais attention, si on produit plus qu'un certain seuil, c'est EDF qui récupére tout et alors tu te retrouves à payer EDF pour l'électricité que tu consomes même si elle fait partie de ta propre production. Les boules, non? Du moins, à ma conaissance, ce réglement là est encore en vigueur et le restera jusqu'à la libéralisation du marché.
Bon, évidement, on reste encore dépendant des cables électriques.