Showing a small message to the user for browser incompatibility
Summary
=======
This blueprint targets to show an incompatible message on the login page of Horizon dashboard.
Motivation
========
When a user uses the Horizon dashboard with older browsers like IE < 10 or any other versions of firefox, chrome some of the features are broken and doesn’t work properly. Due to using older browsers rendering of css is also broken with may put a damper on the end-users experience with Horizon dashboard.
Description
=========
This new feature will detect which type and version of browser end-user is using and informs the user if it breaks any feature of the Horizon dashboard.
So, if a user is using let’s say IE8 then a warning message will be shown to the user on the login page of the Horizon dashboard. This message will be hidden once user logs-in into the Horizon dashboard.
The message will be simple enough and will also contain a link to the Horizon browser support matrix. So, users can follow that link and find out which browsers and their versions are supported by Horizon dashboard.
This feature can be implemented by two ways:
1) User-Agent Detection at the backend
In this approach the backend will parse the UA string and will check the browser and its version
against the fixed set of minimum requirements. After finding out that the current browser which user is using for Horizon is incompatible with Horizon, the backend will inject the warning message in the login template.
What do I mean by fixed set of minimum requirement??
We will maintain a mapping of browser type and their minimum version supported by Horizon and this will be used to check if the browser used by user is compatible with Horizon or not.
2) JavaScript based Browser Identification
In this approach we can use “Jquery-migrate” which is already present in the Horizon. With this JS library we can identify the browser type and version and show the warning message.
With these approaches we have some issues as following:
a) With approach (1) user can change its UA string and can send the wrong string to the backend but we should not be concerned about this problem because if user is changing the UA string then it is their choice.
b) Also with approach (1) UA parsing can be a difficult task but not an impossible one.
c) With approach (2), as told by the Horizon community members that “jquery-migrate” can be removed anytime from the Horizon. And if we implement this feature using this JS library and on later stages if it gets excluded from the horizon that will become a problem.
UX
===
In UX side of things for this feature, it will show a message on the top of the Horizon’s login page which will contain the simple message and a link to browser support matrix of Horizon.
Wireframes, Mocks, Videos and UI Markup
-------
Link: https:/
[IRC Discussion Logs with #openstack-horizon]
http://
[IRC Discussion Logs with #openstack-ux]
http://
Testing
======
This feature can be testing by using any older version of IE, chrome or firefox which Horizon browser support matrix doesn’t supports.
Outside Dependencies
==================
N/A
Requirements Update Required
=======
N/A
Doc Impact
=========
N/A
Blueprint information
- Status:
- Complete
- Approver:
- David Lyle
- Priority:
- Undefined
- Drafter:
- Nikunj Aggarwal
- Direction:
- Needs approval
- Assignee:
- Nikunj Aggarwal
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- David Lyle
Related branches
Related bugs
Sprints
Whiteboard
[Solly Ross]
I'm not sure User Agent detection is the best way to go.
Suppose you do UA sniffing and say "show the message unless the UA is one of X". Then, if there's a browser which fully supports your feature set, but doesn't have a known UA (or someone set a custom UA on their browser), the message will still show, which could be confusing to users.
On the other hand, if you do UA sniffing and say "show the message if the UA is one of X", then a browser that didn't support the features, but didn't have a matching User Agent, wouldn't show the message.
If you go with User Agent sniffing, I'd say the latter way (a blacklist) preferable, since it's probably easier to come up with currently unsupported browsers than it is to predict future browsers.
Have you identified which specific browser features are needed? You could use Modernizr and then warn if the requisite feature set it not implemented. This way, you simply check for the feature set required.
[Nikunj Aggarwal]
You are right with your questions about user setting custom UA on their browser. And during my discussion with other Horizon community members on IRC, we decided that Horizon should not care about user setting custom UA on for their browser because it is not our job to identify that and fix. If user is setting custom UA for their browser which means they want that irrespective of the outcome.
Also we discussed about using Modernizr and also implementing graceful degradation but this will work for bigger features like canvas or svg but smaller css feature where it is breaking in older versions of IE like IE <9, will be a huge change and I personally think will be waste of resources and will make the code more complicated.
Instead Horizon guys came to an conclusion that we will identify the browser type and version to deal with legacy browsers like older IE or firefox or any other browser and for other major features we can use feature detection with Modernizr.
We are targeting all major browsers which are listed in this page - https:/
And I also think by going with this approach we will minimize the code complexity and also this small feature will greatly improve the UX experience for the end-users.
[jpichon 2014.11.14]
* About 2) and jQuery migrate, could you clarify the issue? It seems to be it is already available as a xstatic dependency ( https:/
* I wonder if it may be good to also advise users to "either upgrade or download the latest version of a free browser instead such as Firefox or Chrome" (with links to both). That way the message would be translatable, while the wiki page is only available in English.
* I think you should clarify whether you plan to use a blacklist or whitelist approach. Personally I support blacklisting by keeping a short list of a few known and problematic old browsers (such as IE8 and before), but not the whitelisting approach (i.e. keeping a list of known "good" browsers), because there are many many browsers we don't and won't test with that likely work perfectly fine.
* I would mention that jQuery-migrate is already in our requirements list, for the "Requirements Update Required" field, with a link to the patch. If we don't use the JS approach I take it we should remove the xstatic dependency from the requirements repository, or was it added for something else?
* Would there be a requirement update if we use approach (1) or would we need to implement it ourselves?
* Optionally it'd be nice to offer a summary of the IRC discussions in addition to dumping long logs :)
[nikunj2512 2014.11.18]
* Julie if you see the chat logs there Radomir Dopieralski(
* i think it will be best to tell the users that their current browser is unsupported and then give the link of Horizon's browser support matrix page(There we can include the links also) for them to follow or download.
* You are right, i am planning to use the blacklist instead of whitelist because as you said it is easy to keep track of problematic old browsers.
* i think jQuery-migrate was added for something else. My best guess is we are using some of the deprecated features of Jquery which current version of jQuery doesn't support and those are moved into jQuery-migrate. But i will also suggest to use jQuery-migrate because it will be easier and faster and this requirement is already there in the horizon.
* In both cases there will not be any requirement update.
I will summarize the irc logs also. And as i mentioned earlier, i am in favor of approach (2).
[david-lyle | 2015-03-03] missing consensus on direction, moving out of Kilo.
