Making a better interface for palettes
Printed From: Pixel Joint
Category: The Lounge
Forum Name: Resources and Support
Forum Discription: Help your fellow pixel artists out with links to good tutorials, other forums, software, fonts, etc. Bugs and support issues should go here as well.
URL: https://pixeljoint.com/forum/forum_posts.asp?TID=24880
Printed Date: 13 September 2025 at 11:11am
Topic: Making a better interface for palettes
Posted By: rizer
Subject: Making a better interface for palettes
Date Posted: 05 February 2016 at 6:53am
|
I'm working on a big update to my app http://pixaki.com - Pixaki , and I'm trying to work out how I can make the palette UI a lot better. I've learnt a lot more about pixel art since I designed the current version of the app, which just has all the colours in the palette on a two wide grid.
From reading up on the forums (especially the http://pixeljoint.com/forum/forum_posts.asp?TID=10695 - COLORING "I dont get it" topic), it seems that this kind of thing is the ideal way to organise colours: 
Now I'm trying to think how I could do something like that for a tiny screen with big hit targets like the iPad — not easy! I'd love to hear any suggestions anyone has. How do you work at the moment? Is there any software that lets you organise colours really well? Would it be so bad to have a 4-wide or 8-wide grid? Thanks for your help! Luke |
Replies:
Posted By: jalonso
Date Posted: 05 February 2016 at 7:46am
|
The 'organic' palettes you see many use here are almost always hand made as you work and I would say almost impossible to pre design without as you show having a huge panel. There is nothing wrong with linear ramps in apps. Those that use the more organic method are able to roughly see where a shade is shared or shareable. I wouldn't worry too much about this, imo. ps: seems like the palette you show has many wasted shades with far too many 'whites' and not enough neutralizer shades. ------------- |
Posted By: rizer
Date Posted: 05 February 2016 at 7:53am
| Thanks jalonso — that's really helpful :) |
Posted By: neota
Date Posted: 11 February 2016 at 1:45am
|
I've put some thought into this problem in the past. Your post prompted me to rethink it a bit.. First off, one of the main obstacles that such an interface faces is complexity. If you give the user too much control, then they need to.. remember too many controls ;). So, with a few things in mind, I'll suggest some limitations on the problem: * Users cannot reposition colors in a 2d way, only in a 1d way (A color has an index / indices within one or more ramps; it doesn't, in a user-facing sense, have an X and Y coordinate.). This reduces the number of different actions needed. * A given color can only be connected to a maximum of 4 other colors. This is connected with the need to 'pack' ramps into a grid -- 8 way connectedness might be possible but AFAICS could not be as clearly shown as 4-way connectedness. The visual representation I am thinking of here is a 'maze', with 'walls' representing cells that are NOT connected (cells that *are* connected can have a 'wall' that is colored a mix of the two colors that are connected. Cells that *aren't* can just be represented as a color that contrasts both colors reasonably well -- probably a grey) . The problem of packing the graph into 'maze' format can be viewed as a variant of a 'Box Packing' problem , which is a well known type of problem with a range of implementations already out there. The palette you show above could probably be packed into about 10x10 cells using this method. A nice way of visualizing how it would work might be to imagine a bunch of connected Nibbler-style "snakes", that can 'turn' as many times as necessary to fit into the available space, and are only constrained by the need for all 2-or-3-ramp 'junctions' to be located in a way that maintains the entire 'maze' as a single contiguous shape. Or not -- that explanation got away from me. Supposing you went with the above basis. This would mean the following user interaction methods would be needed * add a new color * edit a color * remove a color altogether * "extract" a color. That is, given a ramp ABCD, remove C from the ramp, resulting in a ramp ABD (with C being either in a new ramp, if it wasn't part of any other ramps, or connected only to the colors in those other ramps). Not very simple UI-wise -- best choice might involve offering a menu of ramps to remove the color from, with a checkbox for each. * Connect two/three colors (eg. given existing ramp ABD and other ramp including C, insert C next to B). Probably needs to be some kind of drag operation. There is the question of insertion order (if you drag C -> B, does that mean you want C between B and D or between A and B?). It might work best to use a mostly automatic ordering (if you drop on the centre of B, the brightnesses (LAB L value) of A B C D should be compared to determine insertion location; if you drop near the B D border, it is inserted after B; if you drop near the A B border, it is inserted before B. Behaviour at ramp ends would be variants of these cases. In the case where any of the colors involved are already 4-connected, the operation is automatically canceled with an appropriate error report. * Move a color within a ramp. The simplest approach may be to consider this as a case of 'connect two/three colors' where the color in question is already within the ramp, and is just disconnected from its old location before performing the connection. The chief disadvantage of this approach, AFAICS, is instability. When you add a new color to the palette, or change connections, the palette needs to be automatically repacked, and it may not be possible to guarantee preservation of most of the old layout. That said, this isn't much worse than a typical Photoshop or GIMP palette setup, where inserting colors shoves the following colors forward. ------------- absolutely. |