WordPress.org

Making WordPress.org

#3450 closed enhancement (maybelater)

browsehappy.com – user's browser first

Reported by: retrovertigo Owned by:
Milestone: Priority: normal
Component: Browse Happy Keywords: close
Cc:

Description

Instead of a static order I think it would make sense from a user perspective to have the currently used browser - which should be updated - as the first browser in the list, maybe even highlighted. All others follow as possible alternatives.

As a user I see the warning on a page, follow the link and might not want to have to identify my browser, but just follow the update suggestion.

An exception might be IE, where Edge might be the first browser instead - TBD.

---
from: https://wordpress.org/support/topic/browsehappy-com-randomised-browser-order/

Change History (2)

#1 in reply to: ↑ description @obenland
22 months ago

  • Keywords close added

Replying to retrovertigo:

As a user I […] might not want to have to identify my browser, but just follow the update suggestion.

Hm, I think it is not unreasonable to expect someone to pick out their favorite browser from a list of six.

If it was a scrollable list, I could see how it would be beneficial to highlight or order a certain browser, but with the very limited number of available options I'm not sure I see a significant user experience enhancement here.

@coffee2code, what do you think?

#2 @coffee2code
22 months ago

  • Resolution set to maybelater
  • Status changed from new to closed

I'm actually not against this, but not necessarily for the reasons cited in the ticket. As @obenland said, I don't think simply pointing out the user's current browser in the list is itself all that beneficial. However, coupled with some information to indicate that the browser is or is not current would be helpful.

It's the sort of change that we'd probably implement while doing a bit of redesign for the page. I'd like to see the content area laid out with three sections instead of the current single section:

  1. For the user's current browser, show the browser along with a message indicating if the browser is current or not. For known but un-featured browsers, list the name sans icon. For unknown browsers, omit the section. This section would also indicate if their current browser is marked as insecure.
  2. Browsers supported by the user's OS (equivalent in appearance to the current row of browsers, but minus browsers not supported on their OS and not their current browser). See #github-36. Perhaps also randomize the order of browsers listed here so as not to give the impression of endorsed browser preferences.
  3. Browsers not supported by the visitor's OS. These would be de-emphasized (e.g. grayed out) with a section description explaining that the following browsers are not supported. See #github-36.

As part of that design change I'd also like to:

  • Remove browser version numbers (see #github-29).
    Browser versions are an insignificant attribute of browsers nowadays and not helpful to show to other browser users. A version number would only be helpful when referencing the visitor's current browser (e.g. "Your version of Mozilla Firefox is out of date. Version 58 is the latest; you are using version 56.")
  • Remove browser descriptions.
    The descriptions are basically cribbed single-line pseudo-descriptions taken from some sort of official marketing copy. All are variations of saying they are fast, secure, easy, and/or powerful. Nothing too helpful. Also, they require translations to other languages, which can introduce a hesitancy to update the strings and could lead to newly-changed strings appearing in English while other descriptions appear translated (at least until a translation is made, if ever).
  • Drop IE from being a recommendation, unless we know the visitor's machine is a pre-Windows 10 machine (in which case Edge is not supported and IE 11 is viable).

The Browse Happy site would need to make use of the Browse Happy API in order to get information from the visitor's user-agent string.

That all said, the systems team would like the site to be more cache-friendly, which the above changes don't exactly work towards.

Strictly addressing the proposal in the original ticket, I'm going ahead with closing this as something that would potentially be addressed for completely different reasons in a future redesign.

Note: See TracTickets for help on using tickets.