Note: Throwaway since this conversation happened at a well-known company.
Back Story: This conversation consists of only engineers and touches on a pull request that was submitted regarding a scroll-to-top React component where when routing from one React page to another, the window scrolls to top.
Allen:
What if for whatever reason a user is navigating to a new React page with a hash?
Bill:
I’m not sure I understand exactly what you mean, but based on my testing this work allows the app to work as expected. If you mean something like /login#login-form, and we don’t currently intend for users to do anything like that in the application today, I wouldn’t want to bloat the scope of this particular ticket in anticipation for something that we might do.
Allen:
@Bill Your comments make complete sense based off of what I initially commented. Allow me to explain in more detail...
Jump to anchor example: [link-with-hash-was-here]
Would a similar link such as the sample link above work in the same fashion in our React pages with this component, or will it always scroll to the top while disregarding a URL that included a hash? This seems like expected behavior from a browser, and if so, equates to this consideration being within scope, not so much an anticipation.
Also, if we do not include this behavior (assuming the app does not behave as such already with this component), would we be going against web accessibility best practices, one example being “Skip Navigation Links”?
Bill:
@Allen my response still wouldn’t change.
To answer your question, a hash link wouldn’t work -- could you point me to an example in the app where we use them currently? If we don’t utilize them, then building the ability to handle them would be based on anticipation of us utilizing that browser behavior in our app. Based solely on the scope of the bug, this addresses the issues we were seeing with the browser not scrolling to the top of the page as expected when navigating between two pages in the SPA. In relation to what you said about expected browser behavior, this is in any case a step closer to proper handling of links between pages in our app.
I appreciate the snippet that addresses this functionality, but I believe that as a team we need to do more to prevent the scope of tickets growing and changing based on requirements discovered during development and QA. When we’re in refinement and planning sessions, we spend time making sure that we understand and estimate the requirements of tickets we’re given properly, and ideally we plan the scope of our sprints based off of what we know. It’s always going to happen, we’ll always find new things and discover requirements, but those should be filed as new tickets (be it tech debt, bugs, or stories) and prioritized accordingly by the team and the product owner in future sessions.
Allen:
[quote-start] could you point me to an example in the app where we use them currently? [quote-end]
Can you help me understand why this is scoped to “we” rather than the end user? Leaving out small details such as this over time is what directly led to [company] getting sued, did it not? If this was not considered “expected behavior”, would an organization have the power to legally sue over such an example?
Carl:
I’ve been watching all this traffic come through am I’m a little confused on what the request is here.
@Allen Do we currently have any links that do what you’re describing in the application? I’m getting the impression that we don’t. If we don’t have any, then I’m not sure why we would try to handle that scenario right now. If we do add that functionality in the future then the router would also be updated at that time to complete the ticket wouldn’t it?
Dale:
If there is a hash in the URL, don’t scroll to top. It’s a simple if statement. We should add it in so as to not overwrite something that will most likely confuse us in the future. That’s my 2 cents.
Good catch, @Allen.
Allen:
@Carl My comments relate to default browser behavior, in which we are taking control over. The concern is that we are taking on the responsibility of default browser behavior (due to SPA), while not maintaining the integrity of browser behavior with the added responsibility.
Do we all agree that there is a difference between browser expectations and feature business logic expectations?
@Bill Your scope concerns relating to sprints is great. This, however, is not to be confused with such scope concerns or business logic errors.
Look at it in another way....
Navigate to Button Component
Would the product team have to tell us to include a URL and navigate to it when in anchor form, considering the component acceptance criteria is to “allow for button or anchor usage”, given this component is brand new and being used as a button at first?
Ethan:
Adding my two cents: currently we do use a hash on PDP page. It is linking the reviews at the top to the reviews at the bottom [link-here]
Bill:
@Ethan I tested the link you just provided on this branch, and it works as expected.
Bill:
This PR was just discussed at our team refinement session. The outcome was that since no existing functionality is impacted by this change (which includes the example that @Ethan provided) this will be filed and addressed by our team separately.
I want to re-iterate one last time that the point of this discussion from my end isn’t that this work is hard/time consuming or that I don’t believe we should do it -- in fact in this case the fix is easy and I very much believe we should. Its that as an organization, we gotta get better at not scope creeping requirements. This time the request is easy, in the future it may be something that turns into a 2 day fix or an ongoing discussion of the way things “should be”. These things can spiral very quickly as @Carl was saying. @Ethan provided an existing hash link, I verified that it works, and this PR still fulfills its underlying ticket’s requirements without introducing unwanted behavior to existing functionality.
Allen:
Please take another look at my previous comment.
[quote-start] Do we all agree that there is a difference between browser expectations and feature business logic expectations?
@Bill Your scope concerns relating to sprints is great. This, however, is not to be confused with such scope concerns or business logic errors. [quote-end]
I pulled this branch and it does not display expected browser behavior, in such a scenario as I am referencing (routing to a different URL with hash). If you have a link with hash (e.g. QuickView with a review link within it) on a page that will reroute you to another, it will not currently scroll you to the proper anchor. We now have a problem in regards to expected browser behavior.
Product would not be creating acceptance criteria for this type of expected behavior, so who would? Who does it fall under? How would this be scope creep when this is part of the scope?
Is there anything I can do to help you understand what I am communicating on here?
Allen:
@Bill You know, this is exactly the same problem we as a team are trying to solve.
Since this conversation has yielded a friction point, lets take the opportunity to slot time to sit down and lay out what is considered scope creep and what is considered accountability of the developer.
Now we have the first step in the right direction as a team and are getting real work done.
End of conversation at this time.