GNOME Bugzilla – Bug 710616
Implement new design
Last modified: 2014-05-12 13:07:32 UTC
Toolbars don't seem like a good fit for games - games don't have "tools"; they're not editors or browsers. It's better to have the game itself towards the top of the window with any ancillary controls below. I'd suggest moving the existing controls to the side of the game area: https://raw.github.com/gnome-design-team/gnome-mockups/master/games/mines/mines2.png There are some changes from the existing design here: * There is a new Flag button - this toggles, changing the mode from clear to place flag. This allows playing the game with a single button input device. * The time has been incorporated into the pause button. * The new game button (the refresh icon) is only shown after the resolve button (the question mark) is pressed. * The hint button has been removed; it doesn't seem like a good thing to have in the game by default - there's a risk that it can be an unwelcome temptation.
Looks great. The Hint button does currently add a time penalty, but I have no issues with removing it since I don't think it benefits gameplay in the slightest. I don't really see the need for a Resolve button, though. Resolve makes sense for puzzle games where you can get stuck and want to see the solution, but with Mines it's not really possible to get stuck: you can get to a situation where you have to guess which square to click on, but guessing wrong leads to the same result that a resolve button does. P.S. Your last design was recently implemented in master, so the toolbar's already gone!
(In reply to comment #1) ... > I don't really see the need for a Resolve button, though. Resolve makes sense > for puzzle games where you can get stuck and want to see the solution, but with > Mines it's not really possible to get stuck: you can get to a situation where > you have to guess which square to click on, but guessing wrong leads to the > same result that a resolve button does. Fair enough. We could just swap the resolve button for new game. > P.S. Your last design was recently implemented in master, so the toolbar's > already gone! Fantastic! I'll build it later. :)
Created attachment 258323 [details] [review] Patch to move the buttons to the side This patch moves the status controls from the bottom to the side of the minefield, as seen on the mockup.
Review of attachment 258323 [details] [review]: Everything seems fine to me. Thanks!
I just had a fresh look at the mockups (as a part of bug ), and was hit with the realisation that some parts of the original design might be confusing. Specifically: * The purpose of the flag button isn't clear. My original motivation here was to allow touch screen users a way to place flags and clear squares. This might be better achieved by using long press to place a flag though. * The meaning of the icon for the resolve button wasn't clear. I've done a quick mockup to try and resolve these issues: https://raw.github.com/gnome-design-team/gnome-mockups/master/games/mines/mines2-new.png The flag counter is no longer a button, and a stop icon is used to resolve the game. Sorry about these amendments... let me know what you think.
Looks nice. I think having separate Pause and Stop buttons might be slightly confusing. I would probably drop the Stop button and go straight to (New Game, Select Difficulty, High Scores) when the game is complete. We don't really need Resolve because there's never incentive to use it: > I don't really see the need for a Resolve button, though. Resolve makes sense > for puzzle games where you can get stuck and want to see the solution, but with > Mines it's not really possible to get stuck: you can get to a situation where > you have to guess which square to click on, but guessing wrong leads to the > same result that a resolve button does.
*** Bug 664981 has been marked as a duplicate of this bug. ***
Bryan Quigley notes that using green for the unexploded mines might be confusing to colorblind users (since red = the exploded mine). But I see on the mockup that when you lose, there is only one other mine, and it's white rather than green... is that the one you successfully flagged? If we don't show all the mines when you lose, I think it's not a problem (since only the exploded mine would be colored, and that's the square you just clicked on anyway...), but that is the traditional Minesweeper behavior.
You'd want to see all mines to check whether you identified the other ones correctly and how many were remaining.
Is there anything else to do on this bug? The new design is implemented (even though not matching the mockup 100%) in git.
Created attachment 276378 [details] symbolic icon version of the flag (In reply to comment #10) > Is there anything else to do on this bug? The new design is implemented (even > though not matching the mockup 100%) in git. I think the one remaining thing is to replace the use of preferences-desktop-locale-symbolic with the same flag we're using in the game grid. I've attached a symbolic icon version of the flag image. Let me know if that is sufficient.
(In reply to comment #11) > Created an attachment (id=276378) [details] > symbolic icon version of the flag > > (In reply to comment #10) > > Is there anything else to do on this bug? The new design is implemented (even > > though not matching the mockup 100%) in git. > > I think the one remaining thing is to replace the use of > preferences-desktop-locale-symbolic with the same flag we're using in the game > grid. > > I've attached a symbolic icon version of the flag image. Let me know if that is > sufficient. Thanks, that is enough. Pushed the change to add the symbolic icon and use it in the application, so I am marking this as fixed.