Navigating between Prev/Next rows + loops and forks

[Tamara_Didenko]

Hello, community!

As it often happens when you test your apps in the real world, I keep finding new use cases for my crochet pattern tracker app. The idea of the app is that it shows step-by-step instructions to crocheters working through patterns, one step with instructions per screen. I hope this community can give me ideas for how to solve this next set of challenges =)

Background

I’ve asked for advice regarding this functionality a couple of times before:

• Change back button action?
• Load limited rows based on chosen parameter

Here’s a prototype that roughly shows the structure of the data that’s in my app currently:

Rows as unique Ids prototype

---

The current setup

Each pattern is essentially a collection of steps to complete. There are various pieces of information related to each step. There is more than this, but it outlines the idea:

Now, there are different kinds of patterns that I’m encountering in the wild. For the most part, the difference is in which steps to load and when.

The most basic patterns
This one is the most straightforward way to show the pattern. Each step takes its own row in a table. When a step is selected, it opens a Detail screen from the [working_row] table. [working_row] table has increment_number column, which relates to the step sequence number in [instructions] table. The step instructions/metadata are loaded through lookups.

Patterns with a defined number of repeats
This kind was what I’d seen the most so far. At the end of the day, it’s the same model as the most basic pattern structure, except I had to hardcode those repeats into [pattern_instructions]. I made it a bit more practical while solving the sizing challenges here..

• The array of unique_step_ids is stored in a column in [patterns] table
• When pattern is selected, that array is transposed into dynamic [current_instructions] table using the Miracle method
• increment_number from [working_row] table is related to index in [current_instructions] table, and returns unique_step_id via lookup
• unique_step_id then relates to [unique_instructions] table that contains only unique rows and returns step name, instructions, and stitch count via lookup.

---

The problem

I’ve just encountered two new pattern types and can’t figure out how to deal with them yet :-/

Patterns with loops
This type of pattern doesn’t define how many times you need to repeat a specific sequence of steps, but rather allows the user to use physical measurements to determine when to stop/move to the next step. For example:

Repeat steps 2-4 until the piece measures 18"

A couple of issues with that:

• Those steps can still be quite complex, so it would be desirable to allow users to be able to view them without needing to go all over the pattern to find instructions
• Those steps are not always preceding the current step directly (again, would be nice to prevent from going all over the pattern, if possible)
• (less priority, but would be nice to solve) “Step name” currently looks for the most part like Row 24 and not only indicates the name of the current step, but also gives the user the number of rows they’ve crocheted so far. This is valuable if they are trying to crochet two item piece (socks, gloves) to measurements, or if front and back of the pattern call to match the length (i.e., for a sweater): "I know I’ve made 24 rows for the front, now I need to make 24 rows for the back)

Looking for ideas on how to show the contents of related steps without leaving the current step screen/overriding [working_row]?

The best I’ve been able to think of is to use the inline list and relation to only load that step name/instructions as a card, but I’m wondering if there’s a more clever solution?

---

Patterns with forks
The second kind of patterns that just stumbled me is one with a fork in it. Essentially, the user should have an ability to do one set of rows, but not the other. Regardless of what they choose though, after they complete the designated rows, they still need to continue to the same step.

This presents the problem mostly because my current setup relies on sequential numbers for the increment_number to load the correct step. I suppose, I could do a custom action that overrides the increment_number based on some conditions… but, once again, wondering if there are other clever ways I’m not aware of =)

How can I give my users the ability to “jump around” the pattern without leaving the same screen/loosing their place in pattern?

Would love me some ideas/suggestions! Thank you!