›

[Projects Tracker] Proposition de dialogues de saisie

deftones_chrixdeftones_chrix Membre
août 2006 modifié dans Vos applications #1
Bonjour  :)

Je continue dans mon projet Projects Tracker et je me suis penché sur la conception des fenêtres de saisie.

projectdialogscreenshottp0.th.png taskdialogscreenshotri3.th.png

Qu'en pensez-vous ? Sont elles bien conçues ? Intuitives ? Répondent-elles au look and feel d'OS X ?

Merci de votre participation  :o

PS: J'ai mis mes images sur le site ImageShack pour éviter de surcharger celui-ci.

Réponses

  • SystemSystem
    14:16 modifié #2
    Si je peux me permettre tu devrais plus te consacrer sur le fond que sur la forme dans un premier temps voir dans la majorité du temps...

    Sinon, je pense que le site peut supporter l'affichage de l'image sans claquer...
  • deftones_chrixdeftones_chrix Membre
    14:16 modifié #3
    dans 1154800547:

    Si je peux me permettre tu devrais plus te consacrer sur le fond que sur la forme dans un premier temps voir dans la majorité du temps...

    Sinon, je pense que le site peut supporter l'affichage de l'image sans claquer...


    Je travaille le fond et la forme en parallèle (voir mon message concernant le modéle de domaine pour ce projet). Je suis de ceux qui considèrent comme une erreur de ne pas considérer la GUI dès le début. En effet pour un utilisateur, la GUI <b>est</b> le système, autant s'appliquer dès le début et proposer diverse interface afin d'avoir un feedback rapidement des possibles utilisateurs.

    Et concernant les images, quand j'ai tenté de les envoyer j'ai eu une erreur.
  • BruBru Membre
    14:16 modifié #4
    dans 1155458292:

    Je travaille le fond et la forme en parallèle (voir mon message concernant le modéle de domaine pour ce projet). Je suis de ceux qui considèrent comme une erreur de ne pas considérer la GUI dès le début. En effet pour un utilisateur, la GUI <b>est</b> le système, autant s'appliquer dès le début et proposer diverse interface afin d'avoir un feedback rapidement des possibles utilisateurs.


    Ton cheminement n'est pas faux.
    Il est tout à  fait possible (et c'est bien souvent le cas) de construire le GUI (la forme) en même temps que le moteur (le fond).

    La seule chose dont il faut se garder, c'est de développer des portions de moteur qui s'adapte au GUI. Là , c'est mal.
    Le pourquoi est multiple :
    • tu lies fortement le code du moteur au GUI, ce qui rend plus difficile les évolutions de l'un ou de l'autre de manière indépendante.
    • tu te prives de la facilité à  réutiliser ou des moreceaux de code du moteur, ou des portions de GUI dans d'autres applis.
    • en liant fortement GUI et moteur, tu écartes la possibilité d'appeler ton logiciel en ligne de commande (sans GUI). Parfois, ça peut être utile de pouvoir appeler l'appli en ligne de commande pour réaliser certaines opérations. C'est très pratique pour intégrer ça dans des batchs ou dans des apple-scripts afin d'automatiser certaines opérations.


    Au boulot, je gère un projet de "webisation" d'applications Windows. Le but du jeu est de séparer le code moteur du GUI windows. C'est fait par 2 équipes qui travaillent en parallèle : l'une s'occupant du moteur, l'autre fabriquant l'interface HTML.
    D'ailleurs, c'est souvent les HTMListes qui demandent des améliorations de certaines fonctions du moteur, car ils "visualisent" plus facilement ce que doit donner/fournir l'application finale à  l'utilisateur.

    .
  • deftones_chrixdeftones_chrix Membre
    14:16 modifié #5
    dans 1155461326:

    Ton cheminement n'est pas faux.
    Il est tout à  fait possible (et c'est bien souvent le cas) de construire le GUI (la forme) en même temps que le moteur (le fond).

    La seule chose dont il faut se garder, c'est de développer des portions de moteur qui s'adapte au GUI. Là , c'est mal.
    Le pourquoi est multiple :
    • tu lies fortement le code du moteur au GUI, ce qui rend plus difficile les évolutions de l'un ou de l'autre de manière indépendante.
    • tu te prives de la facilité à  réutiliser ou des moreceaux de code du moteur, ou des portions de GUI dans d'autres applis.
    • en liant fortement GUI et moteur, tu écartes la possibilité d'appeler ton logiciel en ligne de commande (sans GUI). Parfois, ça peut être utile de pouvoir appeler l'appli en ligne de commande pour réaliser certaines opérations. C'est très pratique pour intégrer ça dans des batchs ou dans des apple-scripts afin d'automatiser certaines opérations.


    Au boulot, je gère un projet de "webisation" d'applications Windows. Le but du jeu est de séparer le code moteur du GUI windows. C'est fait par 2 équipes qui travaillent en parallèle : l'une s'occupant du moteur, l'autre fabriquant l'interface HTML.
    D'ailleurs, c'est souvent les HTMListes qui demandent des améliorations de certaines fonctions du moteur, car ils "visualisent" plus facilement ce que doit donner/fournir l'application finale à  l'utilisateur.

    .


    Tout à  fait d'accord avec toi :D
    Et t'inquiète, j'évite à  tout prix le mélange des genre: ma devise est le MVC ;)
    Pour moi la GUI et le modéle ne doivent surtout pas être liés et la communication entre les deux se fait par des classes de "communication".
  • deftones_chrixdeftones_chrix Membre
    août 2006 modifié #6
    Ayant changé certaines règles concernant les objets tâches et projets, voici une proposition de fenêtre de saisie pour ces derniers  :)beta:

    J'ai ajouté des checkbox pour que l'utilisateur informe le systéme que l'objet a une date de début et/ou une date d'échéance.

    N'hésitez pas à  me donner votre avis :)


    [Fichier joint supprimé par l'administrateur]
  • deftones_chrixdeftones_chrix Membre
    14:16 modifié #7
    J'ai repensé la saisie des dates de début et fin d'une tâche ou d'un projet.

    Qu'en pensez-vous ?  Quelle version est la "plus" mieux: celle de la fenêtre de saisie d'une tâche ou celle de la saisie d'un projet ?

    La saisie de tâches et de projet n'étant pas des opérations à  la chaà®ne, je pense qu'il est interressant de prendre du temps à  faire une interface la plus intuitive possible.


    [Fichier joint supprimé par l'administrateur]
Connectez-vous ou Inscrivez-vous pour répondre.