GNOME Bugzilla – Bug 729250
Colored numbers
Last modified: 2015-01-13 13:03:19 UTC
Initial community feedback to the new design is that it's an improvement indeed, however all the comments have mentioned that they miss the colors for the numbers, maybe that is something we should do.
Colored numbers was something that I (and I think also Mario) requested when looking at the designs as well. After actually playing with the new version, I'm no longer sure -- the lack of colors doesn't seem to slow me down at all, and I don't really miss them. Also, Allan says he doesn't think colors can be made to look good.
I was hoping that Allan could try a symbolic design with pips instead of colors. Or we have it (daft looking colors) as an option (not cool).
I know we've discussed this before, but I'm not sure what the resolution was. To me it isn't clear what benefit the colours have - the number already communicates how many adjacent mines there are. What other information is needed?
The issue is that the current design communicates with less clues that the previous one. I'd speculate that the color differences were probably the primary clue for the majority of players of Minesweeper. The numbers were there just that your brain could initially logically connect them to the colors.
For me the colours used to show the level of danger visually. That somehow seemed to reduce the attention needed without having th really read/understand the numbers.
I thought that a field of similarily shaped and coloured numbers would be not so nice to play. That's why we looked into keeping the colour. And as an alternative I thought iconography could be nice. Just to help distinguish the shapes.
Honestly, I don't think that the colours are really necessary. The numbers are the key piece of information, and are pretty easy to pick out without additional visual guidance. The other issue is doing it nicely. Adding other visual elements to the grid cells is difficult to do effectively, particularly when the cells get small. Changing the text colour isn't a great idea if you want to maintain legibility. The one thing you could try is to subtly change the background colour of the cells depending on the number, but this would need input from a visual designer (not me!) (Again, I'm not sure how necessary this is.)
(In reply to comment #7) > The one thing you could try is to subtly change the background colour of the > cells depending on the number, but this would need input from a visual designer > (not me!) (Again, I'm not sure how necessary this is.) A subtle background colour change would indeed solve this, I absolutely support it. Yes, the colours should not be very vivid, but "pale" colours, and that would help indeed. I will experiment with some colours and post screenshots, and if they're ok on the idea level, we'll need the input of the visual designer.
Created attachment 277700 [details] Screenshot with background colors Here's a screenshot with some experiments for some colorful backgrounds for the numbers. The colors surely could use some fine-tuning from a visual designer, but I still think this could be useful. Maybe we could have colorful/monochrome as an option in the app menu.
I think this looks fine and I would think that there is not much harm in having colors as an (non-default?) option.
@Allan Day: any objections against adding an option (in the appmenu) (off by default) for colored backgrounds like in the screenshot from comment 9? If you have no objections, we would need some visual designer input on better colors for that.
Could you post a patch? The colors look good to me from the screenshot (and I'm sure Jakub will tweak them if he likes; he's already CCed to this bug) but it'd be nice to try them out.
Created attachment 284329 [details] Random Mockup Just a random suggestion: see attachment. Explanation: - Not clicked square --> light gray (unknown danger). - Clicked square - Without number --> invisible (no danger). - With number - 1 --> "go green" (little danger). - 2 --> green + bit of yellow (little danger). - 3 --> yellow + bit of green (medium danger). - 4 --> "caution yellow" (medium danger). - 5 --> yellow + bit of orange (medium danger). - 6 --> red + bit of orange (high danger). - 7 --> "stop red" (high danger). - 8 --> "blood red" (deadly danger). - Number --> same color as the background of the window. Optional: color transitions. Everywhere. First note: I have no opinion on whether colors should be used or not. Last note: the colors in my mockup MUST be fine-tuned, of course.
Here are some more requests for colored numbers (or backgrounds): http://blogs.gnome.org/mcatanzaro/2014/10/18/3-14-games-updates/#comments Personally, I still stand by my comment #1.
Created attachment 288997 [details] [review] Colored numbers (bgo #729250)
Created attachment 288998 [details] Mines palette to tweak Attaching the Inkscape/GIMP color palette I have used in my previous patchfor further tweaking and previewing.
Review of attachment 288997 [details] [review]: I like the color scheme.
Mines is actually a lot harder to play at a higher level without the aid of colors. When I play Mines, I play really fast and try to beat my own high score, and I use the colors to play using knee-jerk reaction type decisions instead of thinking about the numbers. Not having colors really makes it that much more difficult and I think that's a step backward in usability. Colors might not help beginners, but it surely wouldn't harm. But colors *really* help me in my playing. It is also a step backward in accessibility for players who have problems reading numbers. So, even though the game might not look as minimalistic with colors, it can still look good with them, and it helps greatly with gameplay. I basically don't play with numbers, I play with the colors as an aid to decide where to click. Please reconsider this design; thank you dearly.
I would, again, mention the idea of (optionally) having same-color iconography for the amount of surrounding mines instead of numbers that are inherently similarily-shaped. That way we might get the best of all the worlds. Also, we make it universal in that it doesn't depend on arabic numerals.
Created attachment 289228 [details] Mines Dice-Like Mockup
Hi, I liked the idea of same-color iconography and gimped a dice-like mockup. I'm not sure the idea of using dice-like dots is gonna fly. But maybe there's another idea for same-color iconography which is better. The background-colour mockup of Robert does provide good visual cues, but it is definitely not as slick as the current design. Maybe shades of gray would work better? Cheers, Mika
They'd need to form circles instead of being taken from dice in order to be visually separated, I'd think. I'll try creating a mockup in the next day or so.
Created attachment 289279 [details] Mines with iconography I thought small and subtle and evenly spaced around an imaginary center-circle.
I like the digits...
I think I got it! ;) How about a number surrounded by (1/8 * number) full circle of yet to be determined width
and maybe to add to the symbolic value, make the circle line thickness relative to (number). the squishing effect of the circle might be emphasized by drawing the number itself smaller and smaller. I'll probably never code any of it so please take this as you may :)
I think Robert Roth's pale colors from comment #9 look good and make the game more lively. White text on colorful BG from comment #13 also looks nice.
Created attachment 293647 [details] Screenshot with coloring (almost) as in the old version
Created attachment 293648 [details] Color selection for all counts
Created attachment 293649 [details] [review] Patch for counter svg images
First of all I think the new design is good and fits well to the rest of gnome. However I also agree with a lot of others here that colors is the thing experienced players look for. There are some really innovative proposals. But why change something which worked out for decades? Also if you look for other platform - the great majority of them uses the traditional colors (one - blue, two - green, three - red, ...). So I think we should also use them. I took the colors from the gnome 32-color palette for my own interpretation of the 'traditional style'. (Took eight - white instead of gray for better readability and seven - yellow because I was not sure if it's really dark magenta).
@Sebastian Poehn: thanks for taking the time to work on this. Unfortunately, as you can see from the history on the bug, we already have several patches, mockups, and options on how to represent danger in various visual ways, and I feel we won't have a consensus (users, designers, developers, minesweeper-junkies, a.s.o. ) on which option to choose. Based on this I'm leaning towards implementing theme support in minesweeper, just like some other gnome games have options to customize appearance. That way any user will be able to change the theme if he's not completely happy with the default one, which seems to be the case for a significant part of our users. So my plan is to implement theming support: * for theming grid colors, borders, etc in the grid, by including a CSS file in the theme * for theming images used (that will give a possibility to create numbers colored as you wish, or implementing dots, or countless other possiblities) * no more than 5 themes will be included in the default package, but anyone will be able to copy his/her own theme into a given directory. I consider this is required to avoid having too many options/themes, just like the other gnome games have a limited number of appearance options/themes (e.g. quadrapassel has 3 themes, five-or-more has 4 themes, swell-foop has 2 themes) * two theme slots are already reserved: one for the current default, and another one for the classic theme using the images created by Sebastian Poehn, which are pretty close to the old look. The next three will be the result of user contributions and experiments.
Sounds great! Do you already have release plans on this?
@Sebastian Poehn: no, I don't have a concrete release plan on this. I have already started implementing this, will work on a new branch called "theming-support", and looking at the code, it should be fairly simple to get it working, but if you want, you can also help. As this is simple, I might have a chance to get it in the next unstable release, with tarballs due on 19th of January.
For anyone interested: the theme selector is implemented (with a classic and a default theme) on the wip/theming-support branch. I'm interested in any kind of feedback. After compiling it, you can find Preferences in the AppMenu, which brings up the theme selector with a live preview (a playable board). Ideas, suggestions are welcome, new themes are also welcome (along with the SVG images and theme.css - see the existing ones, tried to comment them well enough - if possible).
It crashes when I click one of the arrows: Program received signal SIGSEGV, Segmentation fault. minefield_view_refresh (self=0x8c3150) at /home/mcatanzaro/jhbuild/checkout/gnome-mines/src/minefield-view.vala:595 595 for (int i = 0; i < _minefield.width; i++) (gdb) bt full
+ Trace 234527
Crash should be fixed , thanks for the heads-up. I have always started a game by selecting a game size and opened preferences only afterwards, so I didn't see this so far.
Merged theme selection branch into master. Default theme didn't change at all. Classic theme has been added, along with the default icons+colored backgrounds theme. Feel free to suggest improvements to the themes or the theme selection dialog in separate bugs, and I am marking this as fixed. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.