Sudoku Solving Web App; Best Way To Get Input?

Question

I am making web application where users can enter a Sudoku puzzle (a puzzle that they have found somewhere else), and the solve it using the application.

I want to have two stages to the application:

1. Enter the given numbers (the setup).
2. Start solving the puzzle, with hints provided (the game).

I want to distinctively separate these two stages, so that I can separate functionality (i.e. there can't be any hints in the setup, and numbers entered in the setup stage will be locked in for the game stage), especially since the input method will be the same for each stage, I want users to know which stage they're at.

I am thinking about using something like this page on Apple's site. Basically intercepting the mouse scroll (or page scroll on touch), and scrolling them a predefined amount to the next stage.

Is this a good idea? Will the stages be to isolated? Not isolated enough? I'm just doing this for fun and looking for some constructive criticism.

Answer 1

Think more carefully about user interaction with your app. The mentioned Apple site assumes totally different user interaction style: although content is separated on several blocks, they are intentionally designed for easy switching back and forth, just with light scroll movements. All the blocks have same user interaction mode: exploring. So user doesn't change its mental model between blocks, he stays in same information consumption mode. So the scrolling is an appropriate mean, which supports this mode.

Your app contains two different modes: game construction and game playing. Moreover, there are constraints as user can't easy switch between modes: playing is not allowed before construction is finished, and construction is blocked while playing. As there is no easy switching, the appropriate (not so easy) mean for switching should be used. Again, scrolling assumes easy switching!

Moreover, each of the modes in your app is time consuming. And possible scenario is creating the game one day and playing it another day. So there is no sense of easy switching between "hard" modes. At least, probably, the cases of creating and playing the game within single flow will be rather unfrequent. Each mode has mental and cognitive load, so user requires to rest a bit between switching.

And last assumption, as the rules are initially hidden from user, it will be confusing to him when app allows to scroll down (switching between construction and playing), but doesn't allow to scroll up. "The app doesn't answer", or "Buggy app", etc. – are first reaction on such behavior.

I can only suggest one case when scrolling interaction could be fine in your app. The case is taking a photo of a ready Sudoku game and then sliding to play the game.

Answer 2

Since you mention hints, I guess the webpage will be calculating those and could actually solve the puzzle and present the solution to the user if requested.

If that is the case, use a single grid and allow the user to enter the fixed numbers. Have the page attempt to solve the puzzle at each stage. As soon as there is only one solution, lock the entered numbers, display the hints and switch modes to allow the user to solve the puzzle.

As well as switching modes when the user has reproduced a printed puzzle on the screen, it's possible that

• the puzzle is solvable and locked before the user has entered all the fixed numbers. This simply means that the puzzle-setter has been kind; the user can continue to enter the numbers he has.
• the puzzle is never solvable and you never fix the user's entries. This is good, because any mistake can be corrected and the puzzle can be locked as soon as it is solvable.

In any case, there is only one grid and the completion of it is a single process for the user.