Clearly communicate about which browser we support

What is the need / problem

Some users report that they can’t access the OFN and shop on their tablet / mobile / etc. After investigation it seems related to the fact they use an old version of Android. But it’s still very disturbing for them as they have the impression the site is not working and this is our fault…

Who does it impact

Some customers and the associated instances as they get complains from hubs facing those customers complains.

What is the current impact of this problem

Some customers and hubs are annoyed and think the OFN is bugging.

What is the benefit in focusing on this

Reinforce our hubs and customers satisfaction and the quality impression of OFN.

Links to more details

Potential solutions that will solve this problem

  • Include a tool that detect browser used by the customer and if not supported redirect to some “support” page telling this browser is not supported and what they should do to access the service.
  • That implies we are able to define which browsers we support.

Hey @MyriamBoure have we determined which browsers we actually support? Is it written somewhere?

@danielle we don’t, we need to prioritize that work but I think it’s hard to do until all instances have connected Matomo and have data to know which browsers and versions are used… I would plan this somehow as a feature as there is some spike to do on it, but we need to make instances connect with matomo and wait for some weeks to investigate… and then when we decide what we support we need to plan some communication globally and locally.
I had some other issue reported with old version of phones so will add them to the thread. I had another one with SSL issue as well on some Samsung phones but also recent ones so I guess it’s not related to versions…

Hey, I am not sure we need matomo for this.
We could consider this a testing task.
We need to install old versions of the browsers and give it a try and see if OFN is compatible or not. We can use market data
On mobile it’s mostly chrome and safari (opera and firefox are below 2% market share)
On desktop it’s Chrome, ie, firefox and safari.
If we can build a basic map with these browsers and what’s the (lower) version of them OFN works. That would be a very good start.
For this test, I’d also separate “the frontoffice works” and “the backoffice works”. I assume frontoffice will work in more browsers than the more complex backoffice.


I would start with market data and then slowly make progress on what you suggest @MyriamBoure. I think it’s easier this way.

I would suggest that we use a tool like this:

It comes with a 7 day free trial so a tester could just crack on with the free trial.

In particular, once the testing guide is completed this could be a great way to onboard new testers. If their first task was to spend a day playing with OFN on all the browsers they would be very ready to spot issues afterwards.

What do you think @Rachel @sstead @CathyP @SineadOFNUK?


I’ve never used CrossBrowserTesting so can’t comment on how easy it would be for first time testers to play with. Would need to experiment with using it first to see how it works. Is the general idea that you can see which browsers we have issues on and use this to create a ‘this browser is not supported’ list?

hey @lin_d_hop sorry for getting back so late but I think that we could definitely use a tool! For example I never manage to set up a corect VM for Safari so I’ve never tested the OFN with Safari… And I guess we cannot say we don’t support Safari, right ?

For another project someone suggested me also because it has unlimited and free access for open source projects:

EDIT : okay crowwbrowsertesting is free for opensource as well! Let’s just test both?
btw it can be interesting for developers as well :slight_smile: