on a le projet de reproduire un grand tableau portrait de famille
grandeur nature (2m x 1.6m =E0 peu pr=E8s) et je me renseigne parce que
j'ignore tout sur la photo num=E9rique. J'ai trouv=E9 un imprimeur qui
peut le faire =E0 partir d'une photo num=E9rique. Il m'a dit qu'il faut la
meilleure d=E9finition possible mais il n'a pas su me dire plus. Quels
sont les appareils professionnels les plus performants actuellement ?
(d=E9finition, m=E9gapixels...)
Avant d'aller =E0 la recherche de photografes professionnels, je voulais
avoir une id=E9e de ce que je peux esp=E9rer de mieux en qualit=E9
num=E9rique.
Merci pour tous les renseignements que vous pouvez me donner
Mais ça, ce sont des ronds. Noëlle a parlé de spirales.
tu veux dire comme ça ?
www.cijoint.fr/cj200907/cijnv2YMdP.jpg
-- G.Ricco
YouDontNeedToKnowButItsNoëlle
Ofnuts a écrit :
À une époque où je faisais non un cours, mais un topo de dégrossissage sur l'utilisabilité du logiciel, je commençais par « L'ergonomie dans le logiciel, c'est ce qui ne soit voit pas. Le plus souvent, ça ne ce voit pas parce qu'il n'y en a pas ».
Je n'ai pas la même définition. Chez moi, c'est: "si tu la sens pas, c'est que c'est de la bonne". L'utilisateur est beaucoup plus sensible aux frustrations (càd aux trucs qui ne marchent pas dans l'appli alors qu'ils marchent ailleurs, genre copier/coller, ou qui marchent "différemment") qu'au reste.
En fait on est d'accord, mais c'était ma petite vannes :).
Il existe des techniques de conception, qui facilitent à la fois la maintenance du logiciel et la création d'interfaces utilisateur ergonomique.
Des noms!
Il y a du bon dans toutes ( même dans l'extreme programming dont je ne pense pas trop de bien ) mais déjà, tout simplement, faire une conception vraiment modulaire avec des boîtes noires aux interfaces correctement documentées au fur à mesure, employer les design patterns connus, séparer présentation/apparence/données/parties fonctionnelles, tester au fur à mesure aussi, en gros tout ce qui fait que le code n'est pas "jetable" fait aussi qu'il pourra être augmenté et modifié sans tout casser ou devenir bazar...La méthode de décomposition hiérarchique en revanche a du plomb dans l'aile, elle mène à refaire 36 fois la même chose à quelque chose près dans les différents coins du soft.
(en particulier sur les dates de livraison)
Pas toujours facile j'imagine.
J'ai écrit une interface sous les ordres d'un type qui avait la haute main sur le design de la chose, et qui était complètement daltonien... Notre interface utilisateur se reconnaissait de loin, tout en jaune et en violet... Pour la V2, sans lui dire, j'ai utilisé les "couleurs système". Sur son PC, c'était toujours en jaune et en violet... mais plus ailleurs.
:) Mais dans un sens il avait raison : un emballage doit pouvoir s'adapter aux daltoniens, qui sont une part non négligeable de la population.
Dejà, quand tu écris printf("Hello world!n"); le ver est dans le fruit. Ta chaîne de caractères est en dur dans le code ; le jour où tu veux faire une version française, tu cherches partout dans le code où tu a écrit hello world et bye bye darling, tu mets les variables chaînes que tu aurais du mettre, tu met une valeur genre "salut tout le monde" pour ta chaîne de caractères, tu mets ça dans un fichier externe, tu mets un flag quelque part dans un fichier, tu édites ton makefile parce que tu as ces fichiers en rab, tu recompiles partout où tu as tes printf, tu lies avec tes fichiers, et voilà tu as une version française, rajouter l'italien sera trivial. Sauf que le truc malin, ça aurait été de consulter une variable de localisation dès le départ. Comme tu as fait pour ton interface en couleurs :). Il a fallu un sacré bout de temps à Adobe pour réussir a changer la couleur du curseur de certains outils (il était gris ) pour qu'il constraste avec l'image. À mon humble avis, c'était bien enfoui.
Noëlle Adam
Ofnuts a écrit :
À une époque où je faisais non un cours, mais un topo de dégrossissage
sur l'utilisabilité du logiciel, je commençais par « L'ergonomie dans
le logiciel, c'est ce qui ne soit voit pas. Le plus souvent, ça ne ce
voit pas parce qu'il n'y en a pas ».
Je n'ai pas la même définition. Chez moi, c'est: "si tu la sens pas,
c'est que c'est de la bonne". L'utilisateur est beaucoup plus sensible
aux frustrations (càd aux trucs qui ne marchent pas dans l'appli alors
qu'ils marchent ailleurs, genre copier/coller, ou qui marchent
"différemment") qu'au reste.
En fait on est d'accord, mais c'était ma petite vannes :).
Il existe des techniques de conception, qui facilitent à la fois la
maintenance du logiciel et la création d'interfaces utilisateur
ergonomique.
Des noms!
Il y a du bon dans toutes ( même dans l'extreme programming dont je ne
pense pas trop de bien ) mais déjà, tout simplement, faire une
conception vraiment modulaire avec des boîtes noires aux interfaces
correctement documentées au fur à mesure, employer les design patterns
connus, séparer présentation/apparence/données/parties fonctionnelles,
tester au fur à mesure aussi, en gros tout ce qui fait que le code n'est
pas "jetable" fait aussi qu'il pourra être augmenté et modifié sans tout
casser ou devenir bazar...La méthode de décomposition hiérarchique en
revanche a du plomb dans l'aile, elle mène à refaire 36 fois la même
chose à quelque chose près dans les différents coins du soft.
(en particulier sur les dates de livraison)
Pas toujours facile j'imagine.
J'ai écrit une interface sous les ordres d'un type qui avait la haute
main sur le design de la chose, et qui était complètement daltonien...
Notre interface utilisateur se reconnaissait de loin, tout en jaune et
en violet... Pour la V2, sans lui dire, j'ai utilisé les "couleurs
système". Sur son PC, c'était toujours en jaune et en violet... mais
plus ailleurs.
:) Mais dans un sens il avait raison : un emballage doit pouvoir
s'adapter aux daltoniens, qui sont une part non négligeable de la
population.
Dejà, quand tu écris
printf("Hello world!n"); le ver est dans le fruit.
Ta chaîne de caractères est en dur dans le code ; le jour où tu veux
faire une version française, tu cherches partout dans le code où tu a
écrit hello world et bye bye darling, tu mets les variables chaînes que
tu aurais du mettre, tu met une valeur genre "salut tout le monde" pour
ta chaîne de caractères, tu mets ça dans un fichier externe, tu mets un
flag quelque part dans un fichier, tu édites ton makefile parce que tu
as ces fichiers en rab, tu recompiles partout où tu as tes printf, tu
lies avec tes fichiers, et voilà tu as une version française, rajouter
l'italien sera trivial. Sauf que le truc malin, ça aurait été de
consulter une variable de localisation dès le départ. Comme tu as fait
pour ton interface en couleurs :). Il a fallu un sacré bout de temps à
Adobe pour réussir a changer la couleur du curseur de certains outils
(il était gris ) pour qu'il constraste avec l'image. À mon humble avis,
c'était bien enfoui.
À une époque où je faisais non un cours, mais un topo de dégrossissage sur l'utilisabilité du logiciel, je commençais par « L'ergonomie dans le logiciel, c'est ce qui ne soit voit pas. Le plus souvent, ça ne ce voit pas parce qu'il n'y en a pas ».
Je n'ai pas la même définition. Chez moi, c'est: "si tu la sens pas, c'est que c'est de la bonne". L'utilisateur est beaucoup plus sensible aux frustrations (càd aux trucs qui ne marchent pas dans l'appli alors qu'ils marchent ailleurs, genre copier/coller, ou qui marchent "différemment") qu'au reste.
En fait on est d'accord, mais c'était ma petite vannes :).
Il existe des techniques de conception, qui facilitent à la fois la maintenance du logiciel et la création d'interfaces utilisateur ergonomique.
Des noms!
Il y a du bon dans toutes ( même dans l'extreme programming dont je ne pense pas trop de bien ) mais déjà, tout simplement, faire une conception vraiment modulaire avec des boîtes noires aux interfaces correctement documentées au fur à mesure, employer les design patterns connus, séparer présentation/apparence/données/parties fonctionnelles, tester au fur à mesure aussi, en gros tout ce qui fait que le code n'est pas "jetable" fait aussi qu'il pourra être augmenté et modifié sans tout casser ou devenir bazar...La méthode de décomposition hiérarchique en revanche a du plomb dans l'aile, elle mène à refaire 36 fois la même chose à quelque chose près dans les différents coins du soft.
(en particulier sur les dates de livraison)
Pas toujours facile j'imagine.
J'ai écrit une interface sous les ordres d'un type qui avait la haute main sur le design de la chose, et qui était complètement daltonien... Notre interface utilisateur se reconnaissait de loin, tout en jaune et en violet... Pour la V2, sans lui dire, j'ai utilisé les "couleurs système". Sur son PC, c'était toujours en jaune et en violet... mais plus ailleurs.
:) Mais dans un sens il avait raison : un emballage doit pouvoir s'adapter aux daltoniens, qui sont une part non négligeable de la population.
Dejà, quand tu écris printf("Hello world!n"); le ver est dans le fruit. Ta chaîne de caractères est en dur dans le code ; le jour où tu veux faire une version française, tu cherches partout dans le code où tu a écrit hello world et bye bye darling, tu mets les variables chaînes que tu aurais du mettre, tu met une valeur genre "salut tout le monde" pour ta chaîne de caractères, tu mets ça dans un fichier externe, tu mets un flag quelque part dans un fichier, tu édites ton makefile parce que tu as ces fichiers en rab, tu recompiles partout où tu as tes printf, tu lies avec tes fichiers, et voilà tu as une version française, rajouter l'italien sera trivial. Sauf que le truc malin, ça aurait été de consulter une variable de localisation dès le départ. Comme tu as fait pour ton interface en couleurs :). Il a fallu un sacré bout de temps à Adobe pour réussir a changer la couleur du curseur de certains outils (il était gris ) pour qu'il constraste avec l'image. À mon humble avis, c'était bien enfoui.
Noëlle Adam
TireLou
Delestaque a écrit :
Delestaque wrote:
Mais ça, ce sont des ronds. Noëlle a parlé de spirales.
tu veux dire comme ça ?
www.cijoint.fr/cj200907/cijnv2YMdP.jpg
Oui, qui s'enroule sur elle-même. Mais ce n'était pas moi qui en voulait une mais Noëlle. :-)
-- TireLou
Delestaque a écrit :
Delestaque wrote:
Mais ça, ce sont des ronds. Noëlle a parlé de spirales.
tu veux dire comme ça ?
www.cijoint.fr/cj200907/cijnv2YMdP.jpg
Oui, qui s'enroule sur elle-même. Mais ce n'était pas moi qui en voulait
une mais Noëlle. :-)
À une époque où je faisais non un cours, mais un topo de dégrossissage sur l'utilisabilité du logiciel, je commençais par « L'ergonomie dans le logiciel, c'est ce qui ne soit voit pas. Le plus souvent, ça ne ce voit pas parce qu'il n'y en a pas ».
Je n'ai pas la même définition. Chez moi, c'est: "si tu la sens pas, c'est que c'est de la bonne". L'utilisateur est beaucoup plus sensible aux frustrations (càd aux trucs qui ne marchent pas dans l'appli alors qu'ils marchent ailleurs, genre copier/coller, ou qui marchent "différemment") qu'au reste.
En fait on est d'accord, mais c'était ma petite vannes :).
Il existe des techniques de conception, qui facilitent à la fois la maintenance du logiciel et la création d'interfaces utilisateur ergonomique.
Des noms!
Il y a du bon dans toutes ( même dans l'extreme programming dont je ne pense pas trop de bien ) mais déjà, tout simplement, faire une conception vraiment modulaire avec des boîtes noires aux interfaces correctement documentées au fur à mesure, employer les design patterns connus, séparer présentation/apparence/données/parties fonctionnelles, tester au fur à mesure aussi, en gros tout ce qui fait que le code n'est pas "jetable" fait aussi qu'il pourra être augmenté et modifié sans tout casser ou devenir bazar...La méthode de décomposition hiérarchique en revanche a du plomb dans l'aile, elle mène à refaire 36 fois la même chose à quelque chose près dans les différents coins du soft.
(en particulier sur les dates de livraison)
Pas toujours facile j'imagine.
J'ai écrit une interface sous les ordres d'un type qui avait la haute main sur le design de la chose, et qui était complètement daltonien... Notre interface utilisateur se reconnaissait de loin, tout en jaune et en violet... Pour la V2, sans lui dire, j'ai utilisé les "couleurs système". Sur son PC, c'était toujours en jaune et en violet... mais plus ailleurs.
:) Mais dans un sens il avait raison : un emballage doit pouvoir s'adapter aux daltoniens, qui sont une part non négligeable de la population.
Dejà, quand tu écris printf("Hello world!n"); le ver est dans le fruit. Ta chaîne de caractères est en dur dans le code ; le jour où tu veux faire une version française, tu cherches partout dans le code où tu a écrit hello world et bye bye darling, tu mets les variables chaînes que tu aurais du mettre, tu met une valeur genre "salut tout le monde" pour ta chaîne de caractères, tu mets ça dans un fichier externe, tu mets un flag quelque part dans un fichier, tu édites ton makefile parce que tu as ces fichiers en rab, tu recompiles partout où tu as tes printf, tu lies avec tes fichiers, et voilà tu as une version française, rajouter l'italien sera trivial. Sauf que le truc malin, ça aurait été de consulter une variable de localisation dès le départ. Comme tu as fait pour ton interface en couleurs :). Il a fallu un sacré bout de temps à Adobe pour réussir a changer la couleur du curseur de certains outils (il était gris ) pour qu'il constraste avec l'image. À mon humble avis, c'était bien enfoui.
Noëlle Adam++
comme ça, c'est reparti sur l'informatique, il y a toujours une bonne raison HS
À une époque où je faisais non un cours, mais un topo de
dégrossissage sur l'utilisabilité du logiciel, je commençais par «
L'ergonomie dans le logiciel, c'est ce qui ne soit voit pas. Le
plus souvent, ça ne ce voit pas parce qu'il n'y en a pas ».
Je n'ai pas la même définition. Chez moi, c'est: "si tu la sens pas,
c'est que c'est de la bonne". L'utilisateur est beaucoup plus
sensible aux frustrations (càd aux trucs qui ne marchent pas dans
l'appli alors qu'ils marchent ailleurs, genre copier/coller, ou qui
marchent "différemment") qu'au reste.
En fait on est d'accord, mais c'était ma petite vannes :).
Il existe des techniques de conception, qui facilitent à la fois la
maintenance du logiciel et la création d'interfaces utilisateur
ergonomique.
Des noms!
Il y a du bon dans toutes ( même dans l'extreme programming dont je ne
pense pas trop de bien ) mais déjà, tout simplement, faire une
conception vraiment modulaire avec des boîtes noires aux interfaces
correctement documentées au fur à mesure, employer les design patterns
connus, séparer présentation/apparence/données/parties fonctionnelles,
tester au fur à mesure aussi, en gros tout ce qui fait que le code
n'est pas "jetable" fait aussi qu'il pourra être augmenté et modifié
sans tout casser ou devenir bazar...La méthode de décomposition
hiérarchique en revanche a du plomb dans l'aile, elle mène à refaire
36 fois la même chose à quelque chose près dans les différents coins
du soft.
(en particulier sur les dates de livraison)
Pas toujours facile j'imagine.
J'ai écrit une interface sous les ordres d'un type qui avait la haute
main sur le design de la chose, et qui était complètement
daltonien... Notre interface utilisateur se reconnaissait de loin,
tout en jaune et en violet... Pour la V2, sans lui dire, j'ai
utilisé les "couleurs système". Sur son PC, c'était toujours en
jaune et en violet... mais plus ailleurs.
:) Mais dans un sens il avait raison : un emballage doit pouvoir
s'adapter aux daltoniens, qui sont une part non négligeable de la
population.
Dejà, quand tu écris
printf("Hello world!n"); le ver est dans le fruit.
Ta chaîne de caractères est en dur dans le code ; le jour où tu veux
faire une version française, tu cherches partout dans le code où tu a
écrit hello world et bye bye darling, tu mets les variables chaînes
que tu aurais du mettre, tu met une valeur genre "salut tout le
monde" pour ta chaîne de caractères, tu mets ça dans un fichier
externe, tu mets un flag quelque part dans un fichier, tu édites ton
makefile parce que tu as ces fichiers en rab, tu recompiles partout
où tu as tes printf, tu lies avec tes fichiers, et voilà tu as une
version française, rajouter l'italien sera trivial. Sauf que le truc
malin, ça aurait été de consulter une variable de localisation dès le
départ. Comme tu as fait pour ton interface en couleurs :). Il a
fallu un sacré bout de temps à Adobe pour réussir a changer la
couleur du curseur de certains outils (il était gris ) pour qu'il
constraste avec l'image. À mon humble avis, c'était bien enfoui.
Noëlle Adam++
comme ça, c'est reparti sur l'informatique, il y a toujours une bonne raison
HS
À une époque où je faisais non un cours, mais un topo de dégrossissage sur l'utilisabilité du logiciel, je commençais par « L'ergonomie dans le logiciel, c'est ce qui ne soit voit pas. Le plus souvent, ça ne ce voit pas parce qu'il n'y en a pas ».
Je n'ai pas la même définition. Chez moi, c'est: "si tu la sens pas, c'est que c'est de la bonne". L'utilisateur est beaucoup plus sensible aux frustrations (càd aux trucs qui ne marchent pas dans l'appli alors qu'ils marchent ailleurs, genre copier/coller, ou qui marchent "différemment") qu'au reste.
En fait on est d'accord, mais c'était ma petite vannes :).
Il existe des techniques de conception, qui facilitent à la fois la maintenance du logiciel et la création d'interfaces utilisateur ergonomique.
Des noms!
Il y a du bon dans toutes ( même dans l'extreme programming dont je ne pense pas trop de bien ) mais déjà, tout simplement, faire une conception vraiment modulaire avec des boîtes noires aux interfaces correctement documentées au fur à mesure, employer les design patterns connus, séparer présentation/apparence/données/parties fonctionnelles, tester au fur à mesure aussi, en gros tout ce qui fait que le code n'est pas "jetable" fait aussi qu'il pourra être augmenté et modifié sans tout casser ou devenir bazar...La méthode de décomposition hiérarchique en revanche a du plomb dans l'aile, elle mène à refaire 36 fois la même chose à quelque chose près dans les différents coins du soft.
(en particulier sur les dates de livraison)
Pas toujours facile j'imagine.
J'ai écrit une interface sous les ordres d'un type qui avait la haute main sur le design de la chose, et qui était complètement daltonien... Notre interface utilisateur se reconnaissait de loin, tout en jaune et en violet... Pour la V2, sans lui dire, j'ai utilisé les "couleurs système". Sur son PC, c'était toujours en jaune et en violet... mais plus ailleurs.
:) Mais dans un sens il avait raison : un emballage doit pouvoir s'adapter aux daltoniens, qui sont une part non négligeable de la population.
Dejà, quand tu écris printf("Hello world!n"); le ver est dans le fruit. Ta chaîne de caractères est en dur dans le code ; le jour où tu veux faire une version française, tu cherches partout dans le code où tu a écrit hello world et bye bye darling, tu mets les variables chaînes que tu aurais du mettre, tu met une valeur genre "salut tout le monde" pour ta chaîne de caractères, tu mets ça dans un fichier externe, tu mets un flag quelque part dans un fichier, tu édites ton makefile parce que tu as ces fichiers en rab, tu recompiles partout où tu as tes printf, tu lies avec tes fichiers, et voilà tu as une version française, rajouter l'italien sera trivial. Sauf que le truc malin, ça aurait été de consulter une variable de localisation dès le départ. Comme tu as fait pour ton interface en couleurs :). Il a fallu un sacré bout de temps à Adobe pour réussir a changer la couleur du curseur de certains outils (il était gris ) pour qu'il constraste avec l'image. À mon humble avis, c'était bien enfoui.
Noëlle Adam++
comme ça, c'est reparti sur l'informatique, il y a toujours une bonne raison HS
-- G.Ricco
Delestaque
TireLou wrote:
Delestaque a écrit :
Delestaque wrote:
Mais ça, ce sont des ronds. Noëlle a parlé de spirales.
tu veux dire comme ça ?
www.cijoint.fr/cj200907/cijnv2YMdP.jpg
Oui, qui s'enroule sur elle-même. Mais ce n'était pas moi qui en voulait une mais Noëlle. :-)
ben c'est quand même pas difficile, suffit de progammer un ordinateur.
-- G.Ricco
TireLou wrote:
Delestaque a écrit :
Delestaque wrote:
Mais ça, ce sont des ronds. Noëlle a parlé de spirales.
tu veux dire comme ça ?
www.cijoint.fr/cj200907/cijnv2YMdP.jpg
Oui, qui s'enroule sur elle-même. Mais ce n'était pas moi qui en
voulait une mais Noëlle. :-)
ben c'est quand même pas difficile, suffit de progammer un ordinateur.
