Scenario modifications for assessing API viscosity

InMatrix commented 3 years ago

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. This issue is created to discuss those modifications. Here are some preliminary thoughts:

Scenario: Deep linking by path parameter

Adding a new route (e.g., settings)
Changing the path pattern (i.g., change ‘/books/’ to ‘/items/’ )

Scneario: Login

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 #35)
Unnesting a route (i.e. promoting a secondary section to a primary section)

idkq commented 3 years ago

Few more:

Deleting/removing route
Adding data parameters to the route (i.e. book/id:001)
Adding routes to the navigation stack (example: when tap back, go back two screens)
Changing variables that control stateful navigation when using declarative (see https://github.com/flutter/uxr/issues/15)

xuanswe commented 3 years ago

I think, we need a scenario to migrate a non-web version to web version. For example, if I have an app running on mobile using Navigator, what must I do to support also web environment?

lulupointu commented 3 years ago

@nguyenxndaidev agreed! That might be very important, even if this is not a migration but just a dev wanting to jump into web. The need to learn a lot of new ways to handle a package just to support web could be a pain.

slovnicki commented 3 years ago

@nguyenxndaidev agreed! This might be out of scope for viscosity per se, so I suggest we open another issue for exploring the migration from "Navigator 1.0" to some package enabling "Navigator 2.0" (as most of them are supporing web by default already).

We could explore factors like:

how much time a migration takes
how natural it feels
...

xuanswe commented 3 years ago

@slovnicki I don't think it's out of scope of viscosity. The measuring of modifications should start from a code which doesn't use the package, not just after using it.

But I agree with you that we can also split into 2 isolated sub-domains to measure.

InMatrix commented 3 years ago

@nguyenxndaidev Migrating from a mobile-only implementation to web is an important consideration. For the purpose of this study, we're going to limit the scope to changes in app behavior and leave changes in platforms as a separate factor. In future work, we should probably consider changes in form factors as well, e.g., adapting an app from mobile to desktop.

InMatrix commented 3 years ago

I moved this thread to the newly created Discussions section: https://github.com/flutter/uxr/discussions/51. Please continue the conversation there. Thank you.

flutter / uxr