Skip to content

Conversation

@daniloargentiero
Copy link

@daniloargentiero daniloargentiero commented Mar 8, 2018

With this pull request the "Report an Issue" link will open in a new tab instead of the current page.
This is useful because in this way you don't loose your currently opened admin page.

Description

Added attribute target

Fixed Issues (if relevant)

  1. Why Report Bugs link not open in new tab? #14010 Why Report Bugs link not open in new tab? Why Report Bugs link not open in new tab? #14010

Manual testing scenarios

  1. Go to the admin panel
  2. Click on the footer link "Report an Issue"

Contribution checklist

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds on Travis CI are green)

@miguelbalparda miguelbalparda self-assigned this Mar 8, 2018
@miguelbalparda
Copy link
Contributor

Asked the UX team, will report back.

@orlangur
Copy link
Contributor

orlangur commented Mar 9, 2018

@miguelbalparda please note that proposed behavior change goes against modern UX recommendations (#14010 (comment)).

@miguelbalparda
Copy link
Contributor

@DMMundle anything to add here?

@miguelbalparda miguelbalparda removed the request for review from davidalger March 12, 2018 15:09
@mikemyles-magento
Copy link

In this case, opening a new tab is the right path. General best practice is to stay in the same tab, however exceptions include:

  1. Link provides assistance.
  2. Link may interrupt an ongoing process.
  3. Link leads to a non-html-document.
  4. Link leads to a large file which takes time to load.

The bug report link falls squarely under the second case. There is a potential for loss of data. Protecting against this unintended consequence (error prevention) outweighs the user control UX guideline.

@DMMundle
Copy link
Contributor

Thanks for the heads-up, Miguel. I've asked the others on UX team at Magento, and our newest team member, @mikemyles-magento explains it clearly above. We recommend opening the link in a new tab. Apologies for the response delay!

@miguelbalparda
Copy link
Contributor

All good, thanks for the reply!

@magento-engcom-team
Copy link
Contributor

Hi @miguelbalparda, thank you for the review.
ENGCOM-870 has been created to process this Pull Request

@magento-engcom-team
Copy link
Contributor

@DaniloEmpire thank you for contributing. Please accept Community Contributors team invitation here to gain extended permissions for this repository.

@daniloargentiero
Copy link
Author

@magento-engcom-team Thank you for the link, I am a member of @magento/magespecialist
I added "partner contribution" label.

@orlangur
Copy link
Contributor

Hi @mikemyles-magento, could you please evaluate my following suggestion

Click on browser's "Back button"

In most cases you will see nonempty form (some data could be missed in tabs loaded via AJAX). Also, some modern browsers ask if user really wants to leave page as form data entered may be lost. A generic cross-browser mechanism could be implemented on Magento side to avoid data loss (show confirmation dialog when there is some unsaved form data).
Placing target=blank in random places is not a right way to improve user experience in 2k18.

to decide if it makes sense to put different browsers in line in terms of data loss.

Link may interrupt an ongoing process.

SImply means that every single link in Admin UI on the page containing form should be forced to open in a new tab. Well, quite awkward as to me.

@orlangur
Copy link
Contributor

@slackerzz, @giacmir it would be more constructive to add some thoughts instead of silent downvoting 😉

@mikemyles-magento
Copy link

mikemyles-magento commented Mar 13, 2018

@orlangur - User control is certainly an important usability guideline to consider, but there are also issues of error prevention, and data/work loss here.

Let's consider the user flow...

I'm in a form and discover a bug. I want to report it now, while it's fresh in my mind. May even want to attach screen shots (not sure if that capability is supported in this specific instance, but bear with me - this is my second week, and lack product knowledge).

Refresh current page flow options

  1. R-Click bug report link "open in new tab" > record bug in form on new tab - Done
  2. Click bug report link > form is clean/empty - no warning > record bug in form - Done
  3. Click bug report link > form is dirty - get warning > I don't care, OK out of warning >> record bug in form - Done
  4. Click bug report link > form is dirty - get warning > I care - close warning, return to bug report >> R-Click bug report link "open in new tab" > record bug in form on new tab - Done

Now consider when a user is likely to encounter a bug to report: On a blank form? On a form with entries that are unimportant? Probably not. It will be while entering valid information, information they do not want to loose. This means option 1 and 4 are probably correct in the majority of cases.

Opening a new tab eliminates option 3 & 4, and the potential for error in option 4, by clicking through the warning without realizing the consequences. What's the negative outcome of removing option 4? An new browser tab, which I can exercise my user control over, by acting on it (filling out the bug form), or just closing the tab (or copy and paste the URL into tab 1, if I really don't want another tab).

Between the 2 cases - same tab, or new - a new tab is simpler, because it reduces user flow options by two; and safer, since it cannot affect the calling page.

Any interruption of a modal form operation will raise similar considerations. You must either catch, and warn users of a potentially unintended action, or eliminate (minimize) the opportunities for unintended actions to occur. In this case, the cost of error prevention feels quite low.

@slackerzz
Copy link
Member

@orlangur down-voting your comment was only a quick way to say "i do not agree" simply because your proposal seemed a little over engineered to me.
@mikemyles-magento explained very well why a simple target="_blank" is the way to go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants