Vous et la couleur.

Pyroh · mai 2014

TL;DR : Je veux faire une sorte de color schemer vraiment utile dans plain de situations, dites moi une feature que vous aimeriez voir dedans, une seule celle que vous voulez le plus ! Merci !

---

En tant que développeur ou graphiste, on est à un moment ou un autre, confronté à la couleur. Personnellement c'est un sujet qui m'a toujours fasciné, la correspondance, l'harmonisation, l'impact que ça a sur notre manière d'appréhender une interface, etc, etc...

Seulement, je ne sais pas vous, mais moi je me suis toujours retrouvé dans l'impasse quand il s'agissait de mettre tout ça en forme. J'ai toujours été embêté pour définir facilement quelles couleurs j'allais utiliser. J'ai toujours plus ou moins réussi mais le temps que j'ai passé à le faire était souvent perdu parce que je n'avait pas une manière rapide et efficace de le faire.

Je veux dire, il y a quelques logiciels qui permettent de faire des color shemes, mais aucun n'est suffisamment complet ou ne s'intègre facilement dans un workflow. Il y a possibilité de s'arranger de bidouiller, de copier, de coller, de retranscrire, de convertir, de s'arracher les cheveux... Si une seule couleur s'avère être mauvaise il faut recommencer, une partie certes mais c'est reparti pour s'amuser et au final perdre un temps qui aurait pu servir à autre chose.

Si je vous en parle c'est parce que c'est une situation qui m'est bien trop souvent arrivée et que j'ai décidé de développer un outil pour répondre à cette problématique... J'ai une idée assez claire de ce que je veux obtenir mais j'ai peur de ne faire plaisir qu'à une seule personne : moi...

C'est pour ça que je voudrai votre avis, connaà®tre LA feature que vous aimeriez voir dans ce genre de logiciels. Pas une liste, je n'attends pas de vous que vous me filiez les idées pour faire mon soft (je les ai déjà en plus), une seule, petite, de rien du tout...

Je veux juste savoir si ce que j'ai comme vision de la chose trouve un écho chez les gens qui sont confrontés à la même problématique. Un plus serait de me dire ce que vous utilisez comme logiciel dans votre workflow pour pouvoir coller au mieux à la réalité non pas de ce qui se passe dans mon bureau mais dans un maximum de bureau.

Votre aide sera grandement appréciée et je vous remercie d'avance

Larme · mai 2014

J'ai pas compris tout à fait ce que tu voulais.

Mais un designer que j'ai rencontré m'a dit un jour :

On commence toujours en noir et blanc côté design. Et ensuite, on réfléchi à quelles couleurs on mettra (notamment pour les nuances, même si on a la couleur générale).

Après pour la feature, je sais pas. Je ne sais pas vers quoi tu te tournes réellement. Tu voudrais modifier des visuels ?

Pyroh · mai 2014

Ouille on dirait que ma prose n'est pas très compréhensible

En fait je veux développer un logiciel pour construire des palettes graphiques. Une sélection de couleurs qui vont bien ensemble et qu'il est assez facile d'harmoniser automatiquement (la théorie sur la couleur est largement consensuelle).

Il y a déjà des logiciels qui permettent de faire ça mais aucun ne me convient parfaitement et aucun ne permet de faire réellement du cross-software facilement.

Ce que je veux faire (et vais faire, je m'attaque en ce moment aux classes métier) c'est un soft OSX qui permet de répondre à une problématique assez répandue (enfin je pense).

Pour expliquer plus dev-way, tu as une belle couleur pour un bouton, tu veux définir la couleur qui va le mieux faire ressortir le texte, le logiciel te le fait et t'exporte facilement les 2 couleurs au format NSColor à utiliser dans le code. (ou UIColor, ou css, ou hexa, ou...). Finalement la couleur te vas pas, tu retourne dans le soft tu change à ta convenance et hop ré-export. Facile et sans douleur.

C'est le "facile et sans douleur" qui est vraiment intéressant ici. Parce que bon, un soft qui t'accorde 3 couleurs t'en as 10000 sur le MAS + le net.

Pour répondre à ma question, le plus simple est de donner la plus grosse problématique que tu rencontre en voulant faire ce genre de choses

@Ali : Merci pour le tuyau + edit

AliGator · mai 2014

@Larme Voilà un exemple d'outil en ligne qui fait juste un peu ça (en moins poussé que ce que veux faire Pyroh mais pour te donner une idée) : http://colorschemedesigner.com/

En gros un outil où tu lui donnes une teinte globale pour ton "thème" (plutôt jaune, plutôt vert, plutôt bleu, ...) et il te sort un ensemble de variantes de couleur qui vont bien avec cette teinte là . Des variantes de vert qui se marient bien ensemble, des couleurs de texte qui iraient bien si tes fonds sont vert, etc.

Bref, te générer un jeu de couleurs qui vont bien ensemble.

Après il y a plein d'options dans ce genre d'outils, genre est-ce que tu veux un jeu de 5 couleurs qui sont dans les mêmes tons (variantes de jaune), ou un jeu de couleurs qui s'opposent ou quoi.

Mais le but c'est, pour ceux qui ne sont pas à l'aise pour faire un bon mariage de couleurs qui va bien (ou pour ceux qui ont la sensibilité pour ces choses là mais ne veulent pas trouver les couleurs à la main), de trouver les couleurs qui se marient bien ensemble et éviter des associations de couleurs qui ne vont pas du tout par exemple.

Céroce · mai 2014

@pyroh: je pense que le soucis est que nous ne sommes pas le bon public. On est rarement programmeur et graphiste à la fois. Donc, là , si tu me demandes de quel outil j'ai besoin en tant que développeur pour gérer la couleur, j'ai besoin d'un outil qui me permette de récupérer facilement ce qu'a défini le graphiste !

Pyroh · mai 2014

Alors je serai le seul ici qui porte les 2 casquettes ? ça confirme bien la crainte que j'avais, ce n'est pas une problématique propre aux dev mais plutôt aux graphistes...

@Céroce je pense que tu as mis le doigt sur un truc important, il faut que le dev puisse récupérer facilement les couleurs mises en place par le graphiste. Si il ont accès au même outil qui s'occupe de les cataloguer ça va être plus simple.

Mais alors qui ici utilise des outils comme PaintCode ?

Larme · mai 2014

@Pyroh & Ali :

Oui, sur la première explication, j'ai eu du mal. Sur la seconde, j'ai compris directement que c'était le truc qu'a linké Ali.

Sinon, je rejoins Céroce.

En général, un dév'/designer, ça ne court pas les rues. Ce sont deux métiers différents. Maintenant, rien n'empêche l'un de tomber un peu dans le domaine de l'autre, par curiosité, passion, ou juste parce qu'on a pas les moyens d'embaucher quelqu'un sur un projet perso.

Le design, personnellement, ça m'intéresse. J'ai relativement pas mal joué avec Photoshop, du coup.

Sinon pour les couleurs, soit j'utilise la pipette car c'est ponctuel, soit je demande au graphiste les couleurs qu'il utilise. En général, il me fait une p'tite palette avec les codes hexa, la couleur à côté et le context (au cas où y'a plusieurs nuances d'une couleur par exemple, m'indiquant que c'est pour le background, que c'est cette ligne là , sur tel écran/menu, etc.)

Pyroh · mai 2014

Ok donc dès lors qu'il y a un consensus sur le nom des couleurs on peut se dire qu'une application qui renvoie un .h avec du genre :



#define kUIColorBackground [NSColor colorWithCalibratedRed:0.0000 green:0.5831 blue:0.9907 alpha:1.0000]

#define kUIColorForeground [NSColor colorWithCalibratedRed:0.4235 green:0.6000 blue:0.7333 alpha:1.0000]

ça aiderai pas mal de monde ?

Larme · mai 2014

Je préfèrerais une Category sur NSColor plutôt qu'un #define perso.

AliGator · mai 2014

Pareil. (#define for constants are evil)

Une autre solution pourrait être de définir une classe ColorTheme, avec des propriétés de type UIColor.
Avantage, dans la plupart des cas on pourrait avoir une sharedInstance "[ColorTheme sharedTheme]", et ça permettrait plus tard d'ajouter d'autres sharedInstance à la même classe "[ColorTheme darkTheme]", "[ColorTheme lightTheme]" pour ceux qui voudraient faire supporter plusieurs thèmes de couleurs à leur application.

@interface ColorTheme

+(instancetype)darkTheme;

+(instancetype)lightTheme;

@property(strong, readonly) UIColor* backgroundColor;

@property(strong, readonly) UIColor* foregroundColor;

@property(strong, readonly) UIColor* fontColor;

@end

@implementation ColorTheme

+(instancetype)darkTheme

{

static ColorTheme darkTheme;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

darkTheme = [ColorTheme new];

darkTheme.backgroundColor = ...

darkTheme.foregroundColor = ...

darkTheme.fontColor = ...

});

return darkTheme;

}



+(instancetype)lightTheme

{

static ColorTheme lightTheme;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

lightTheme = [ColorTheme new];

lightTheme.backgroundColor = ...

lightTheme.foregroundColor = ...

lightTheme.fontColor = ...

});

return lightTheme;

}

@end

- (void)applyTheme

{

ColorTheme* theme;

if ([[NSUserDefaults standardUserDefaults] boolForKey:@useDarkColors]) {

theme = [ColorTheme darkTheme];

} else {

theme = [ColorTheme lightTheme];

}



mylabel.fontColor = theme.fontColor;

myView.backgroundColor = theme.backgroundColor;

...

}

Après ce ne sont que des idées en vrac pour alimenter le débat, mais pour être honnête en général dans la plupart de mes applis je fais une catégorie sur UIColor comme Larme. Et du coup une catégorie sur UIColor me conviendrait parfaitement (par contre par pitié pas de #define pour des constantes !)

Pyroh · mai 2014

Ah je savais pas que les constantes en define c'était pas bien en Obj-c (j'ai toujours fait ça en C et j'ai continué en Obj-c.

Quoi qu'il en soit ça me permet de pas partir dans le mauvais sens et ça c'est une bonne chose. Je vais partir sur la classe dédiée, j'aime pas trop travailler comme ça avec les catégories (j'aime bien les catégories mais plus pour étendre sans dériver une classe).

Merci à vous

AliGator · mai 2014

Les #define sont à éviter en C aussi quand il s'agit de déclarer des constantes.

Les #define, c'est bien pour définir des macros, ou pour définir des variables préprocessor qui te permettront de faire des #if/#endif.
Pour les constantes, mieux vaut toujours utiliser "const" quand tu peux. Dans un langage non POO comme le C, tu peux toujours le faire :

"extern const int kMyConstant;" dans le .h + "const int kMyConstant = 5;" dans le .c/.m pour les constantes qui doivent être visibles par les autres fichiers donc déclarées dans le .h
"static const int kMyConstant = 5;" directement dans le .c/.m (et rien dans le .h) pour les constantes qui n'ont besoin d'être déclarées/accessibles qu'à l'intérieur du fichier concerné et n'ont pas à être exposées à l'extérieur

Cette règle marche aussi en Objective-C pour tous les types scalaires (les types non-objet).
Elle est aussi applicable pour les NSString* qui sont un cas particulier puisque les "string literals" en Objective-C (@xxx) ne sont pas alloués au runtime mais stockés directement dans le binaire compilé donc ils peuvent être utilisés comme constantes sans avoir besoin d'un alloc/init.

// FooClass.h

// Constante rendue visible pour toutes les autres classes qui vont #import "FooClass.h"

extern NSString* const FooClassErrorDomain;



// FooClass.m

// On donne ici la valeur à  cette constante "publique"

NSString* const FooClassErrorDomain = @FooErrorDomain;

// Une constante "privée", visible uniquement dans FooClass.m et pas à  l'extérieur

static NSString* const kInternalKey = @my-internal-key;

Par contre pour tout autre objet, qui nécessite du coup forcément une allocation (alloc/init ou constructeur de commodité ou autre), tu ne peux PAS écrire :

UIColor* const kConstColor = [UIColor blueColor];

Car [UIColor blueColor] est du code dont le compilateur ne va connaà®tre la valeur de retour qu'à l'exécution. Au moment de la compilation il ne sait pas ce que va retourner blueColor. Ce n'est pas une valeur statique qui peut être évaluée à la compilation, c'est un truc qui nécessite une allocation d'un objet UIColor etc.

Donc pour les constantes qui ne sont ni de type scalaire ni de type NSString, comme tu ne peux pas utiliser "const" et que les #define c'est le mal pour les constantes (entre autres car cela crée autant d'instances que le nombre de fois que tu appelles la "constante"/macro, que cela passe au travers des mailles du filet du type-checking du compilateur parfois, et j'en passe), le mieux est du coup de prévoir des méthodes de classe.

AliGator · mai 2014

En complément, note que dans le cas d'une UIColor, on peut se contenter d'implémenter la méthode de classe pour qu'elle retourne [UIColor colorWithRed:... green:... blue:... alpha:] à chaque fois, c'est suffisant (certes elle va réallouer une UIColor à chaque appel, mais c'est pas non plus la mort, c'est pas un objet qui prend trop de place).
Mais dans le cas où tu as des constantes d'un type potentiellement un peu plus volumineux, où qui vont être plus coûteux à créer (par exemple si la valeur de ta constante est donnée par un PLIST, etc) tu peux utiliser dispatch_once pour n'initialiser ta constante qu'au premier appel et ne faire que retourner la constante déjà initialisée aux appels suivants.

Par exemple, tu pourrais imaginer que toutes tes couleurs sont en fait fournies dans un PLIST "ColorTheme.plist". Tu iras lire ce PLIST soit uniquement la première fois qu'une couleur t'es demandée, soit au chargement de l'application, ou lors de la construction de ta sharedInstance :



// .h

@interface ColorTheme

+(instancetype)sharedTheme;

-(UIColor*)backgroundColor;

-(UIColor*)foregroundColor;

...

@end



// .m

@interface ColorTheme()

@property(strong) UIColor* backgroundColor;

@property(strong) UIColor* foregroundColor;

@end



@implementation ColorTheme

+(instancetype)sharedTheme

{

static ColorTheme* theme;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

theme = [ColorTheme new];

NSString* plist = [[NSBundle mainBundle] pathForResource:@ColorTheme ofType:@plist];

NSDictionary* colors = [NSDictionary dictionaryWithContentsOfFile:plist];

theme.backgroundColor = [self colorFromFragment:colors[@bg]];

theme.foregroundColor = [self colorFromFragment:colors[@fg]];

}

return theme;

}



+(UIColor*)colorFromFragment:(id)fragment

{

// ... code pour transformer ta représentation PLIST d'une couleur en UIColor

// Car on ne peut pas stocker d'objet UIColor dans un PLIST donc tu vas sans doute

// représenter tes couleurs sous forme d'un dictionnaire ayant pour clés "red", "green", "blue", "alpha".

// Ou encore d'un NSArray ayant 4 valeurs. Ou encore d'un entier correspondant à  la représentation

// hexa 0xRRGGBBAA. Ou que sais-je encore

}



@end

Et du coup la première fois que tu vas appeler [ColorTheme sharedTheme] ça va charger le dictionnaire de couleurs et initialiser les propriétés d'après ce contenu une fois pour toutes. Les fois suivantes les couleurs seront déjà chargées donc pas besoin d'aller relire et parser le PLIST à chaque fois.

Voilà , c'est une méthode comme une autre, pas forcément la solution que tu vas devoir adopter, ça dépend de ton approche et de ce que tu veux faire. C'est juste pour te donner les clés pour avoir connaissances des différentes possibilités.

Pyroh · mai 2014

Merci pour toutes ces précisons !

Je ne m'étais jamais posé la question de savoir quel impact avait un define sur un code. Je connaissais le principe des constantes parce que j'ai fait un peu d'assembleur mais le reste non.

J'ai décidé d'utiliser la classe avec avec le singleton (du moins ça ressemble fameusement à un singleton). J'ai commencé à implémenter tout ça.

ça fait plaisir d'apprendre des trucs de cette façon, sincèrement merci

Mala · mai 2014

Mais alors qui ici utilise des outils comme PaintCode ?

Je l'utilise pour du maquettage de vues avec Sketch en complément pour des dessins plus complexes.

colas_ · juin 2014

@Mala : que fais-tu de tes dessins vectoriels ? Tu les bitmapises avant de les importer ?

Merci

Vous et la couleur.

Réponses