Scenario modifications for assessing API viscosity

[InMatrix]

This thread is migrated from #41.

Viscosity is a dimension of API usability we try to assess in this research. Simply put, viscosity measures the ease of modifying code when the requirements have changed. Is the amount of code change out of proportion to the requirements change? Is there a “domino effect” when refactoring code for a seemingly small change in the app's routing behavior?

To assess viscosity, we need to define a few modifications to our navigation scenarios. These modifications need to represent the kinds of changes developers would often run into when iterating on their apps. Here are some preliminary thoughts:

Deep linking by path parameter

• Adding a new route (e.g., settings)
• Deleting a route
• Changing the destination of a route
• Changing the path pattern (i.g., change ‘/books/’ to ‘/items/’ )
• Adding a query parameter to the route

Sign-in

• Splitting the sign-in screen into two steps, username and password.
• Adding a two-factor verification screen

Nested routing

• Changing page transition animations between views in an inner route
• Moving code of an inner route to a separate library, so a separate team can work on it (discussed in Clarify Nested Routing scenario #35)
• Unnesting a route (i.e. promoting a secondary section to a primary section)

Additional ideas from @idkq:

• Adding routes to the navigation stack (example: when tap back, go back two screens)
• Changing variables that control stateful navigation when using declarative (see Declarative vs. imperative routing API  #15)