Cooking mode: preserve the cook’s place

Show a place people can return to

Yoomla displays Step 1 of 6 above a large instruction and a prominent Next action. Daily Bite retains the recipe title, two servings and Step 1 of 5 alongside the task. The additional identity matters if someone switches recipes or returns from another part of the app. A bare progress bar cannot answer which recipe or which instruction it belongs to.

Persist the recipe revision and step identifier, not only an array index. If an imported recipe is edited while a session is open, index four may point somewhere else. Decide whether an active session keeps its original snapshot or asks to adopt the new version. Restore the same instruction after an interruption rather than reopening the top of a long recipe and forcing the cook to search.

Provide a direct way to inspect the whole method, then return to the same step. Forward navigation should not erase access to earlier quantities or preparation notes. Test a person who skips ahead to preheat an oven and then goes back to prepare ingredients. A linear progress indicator can remain helpful without pretending the actual kitchen work is perfectly linear.

Bring the relevant quantity into the instruction

Crouton shows a tomato quantity in a contextual callout while keeping All Ingredients available. Pestle highlights ingredient references and exposes a hot-chilli-sauce quantity without leaving its step. These approaches reduce the need to jump between a method and a distant list, but the displayed amount still needs a clear scope.

Model an ingredient reference as a connection to a specific ingredient entry, not merely a word match. If the recipe uses oil twice, distinguish the amount for this step from the total. Carry the selected serving scale into the session consistently, while keeping preparation descriptions legible. A displayed quantity must not change halfway through a step because a different recipe was scaled elsewhere.

Make contextual help dismissible without moving the reading position. Large text, long ingredient names and a visible keyboard can all crowd a phone. A callout should not cover the words that explain when to use the ingredient. Include the quantity in an accessible reading order and give people a straightforward route to the full list when the automatic reference is wrong or incomplete.

A duration in a sentence is not a running timer

Pick Up Limes shows Set 5 minutes timer beneath the instruction. A second recorded state adds 04:59 at the top while retaining the same 1/7 step and instruction. This is a useful pair for comparing a suggested duration with a visible countdown. The continued start label also raises a design question worth testing: can it create another timer, or does it reopen the one already running?

Define timer identity by session, recipe and originating step. A control can then say Start, View timer or Add another, depending on the actual action. Record a deadline rather than decrementing a counter only while the screen is visible. Specify what happens during backgrounding, device sleep and app restart, then communicate only the reliability your implementation actually supports.

Do not silently scale time because servings changed. Ingredient quantities and cooking durations are not interchangeable parameters. If a recipe offers a range, let the cook understand the chosen duration before starting it. Offer an edit or cancel action on the active timer, and make a finished alert distinguishable from a paused timer or an expired session that could not be restored.

Keep timers discoverable beyond their source step

SideChef presents Start Timer inside Step 6 of 8. Another state shows a running countdown and a callout pointing to the place for all active timers. Together they expose the important separation: a cook can leave an instruction while its timing still matters. A timer hidden on an earlier page is easy to forget.

Give every timer a readable name and its source recipe. A list containing only three identical countdowns requires memory at exactly the wrong moment. Opening a timer should preserve the current instruction, and opening its source step should be an intentional navigation action. If two timers finish together, keep both identifiable instead of replacing the first notification with the second.

Plan for a phone in a noisy room and for someone who cannot hear a sound alert. Use complementary status text and supported notification behavior. Do not promise that an in-app timer will alert after the operating system stops the process unless that behavior is actually implemented and tested. If alerts are unavailable, explain the limitation when the timer starts, not after it should have rung.

Switch recipes without ending the wrong session

Deglaze’s recorded feature tutorial demonstrates highlighted durations and a running countdown. A separate tutorial state presents Switch Recipe and End Cooking together. These are educational demonstrations, not proof of background persistence, but they reveal useful product concepts: choosing another recipe and ending a session should not be the same operation.

When a cook exits, distinguish leaving the surface from clearing session state or cancelling active timers. If ending cooking stops timers, say which ones. If it does not, keep a route back to them. Persist the last step for each active recipe, and show enough title or image context to avoid opening an indistinguishable second session.

Interrupted and failed restoration deserve the same care as other mobile error states. Test a two-recipe session, an incoming call, an expired timer and a full app restart. Ask the cook to identify the current instruction and every running timer. Measure lost-place recovery and accidental resets rather than treating recipe completion as proof that the interface improved cooking outcomes.

Test a return after a real interruption

Set up a session with two recipes, different current steps and at least one active timer in each. Leave the cooking surface, lock the device, reopen the app and switch recipes. Check the saved recipe identity, step, ingredient scale and timer labels at every return. The person should not need to reconstruct the state from memory or infer which countdown belongs to which pan.

Keep the expected session state separate from a recipe’s saved content. A change to a recipe note should not reset active timing, and a switch to a grocery list should not mark cooking complete. If the product cannot restore one part of the session, retain the rest and identify the missing state specifically. Do not replace a failed restoration with a cheerful fresh start.

For evaluation, distinguish intentional browsing from lost-place navigation. Several back taps may be a cook checking an earlier instruction, not evidence that the design is broken. Pair interaction logs with a short observed task: ask someone to resume the second recipe while naming the timer that is about to finish. The answer tests context, not merely the visibility of a progress bar.

Review cooking mode in a real kitchen scenario

Use these checks on a working build, not only on the polished reference state.

• ✓Restore the correct recipe revision and step after leaving or restarting.
• ✓Let people inspect earlier instructions and the ingredient list without erasing their place.
• ✓Distinguish step quantities from recipe totals and preserve the chosen serving scale.
• ✓Separate a suggested duration, a running timer, a paused timer and a finished timer.
• ✓Name timers by recipe and task; test two active recipes and simultaneous completion.
• ✓Verify large text, readable contrast, reachable navigation and accessible instruction order.
• ✓Explain whether End Cooking clears progress, cancels timers, both or neither.