It is popular to use this sort of model in certain industries; the training matrix. Its nonetheless a huge table of data. Are there any possible alternatives to replacing the training matrix? Or another way to display a huge amount of data on desktop and mobile?
This situation comes up all the time, i.e. You have a complex table in a web application, but because the business decides it should be jumping on the mobile revolution, and that it heard about responsive design and thinks it will save them money if they only have to work from one code line.
The bottom line here is the goals of a mobile user on the go, will be very different to the goals of the web user set at a desk with a large resolution monitor. As others here have said, a mobile device is way too small, and the one thing a mobile device can't do is make use of lots of tabular data.
So if you want a mobile solution you really need to understand what you want your users to do on a mobile device on the go, because it is way different to using a web application displayed on a large monitor from your desk.
So now that I have told what you can't do, here is something you can do. Consider the card UI metaphor for mobile. This will allow you to chunk the table data in small discrete blocks of information.
This article introduces you to the card UI metaphor: https://blog.intercom.com/why-cards-are-the-future-of-the-web/
Cards give bursts of information
Cards as an information dissemination medium have been around for a very long time. Imperial China used them in the 9th century for games. Trade cards in 17th century London helped people find businesses. In 18th century Europe footmen of aristocrats used cards to introduce the impending arrival of the distinguished guest. For hundreds of years people have handed around business cards.
Cards can be manipulated
In addition to their reputable past as an information medium, the most important thing about cards is that they are almost infinitely manipulative.
However, everything starts by working out what you want someone to do on a mobile device, and validating this with the real people who you are expecting to use this.
Since you have a limited amount of space, the question that you need to ask yourself (and the client) is what the minimum or useful 'section' of information would be, and build the user interface around that. This is one of the reason that a listview or card/tile view of information has been adopted and popularised in the mobile view of website design.
The mobile view doesn't lend it self to comparisons of large amounts of information very well, so the best you can do is to try and present slices or pieces of information that is meaningful enough for the user to make a decision or to take action. For anything more complicated it is still better to push them back to the desktop environment.
But rather than trying to argue with them over requirements, just show them the difference between the table matrix design versus one of the suggested alternate design strategies and see which is more user-friendly/usable.
Supplement by reformation and condensing data while keeping the original matrix:
Here is one way, it entails finding the main question the table answers, along with the minimum options you can offer and formatting it for mobile, in this case with a couple of select options and a list. Note that although this might work for most,in this particular case you loose the global perspective a reference table offers, so you might still want to offer it as a separate download, or recombine the data for a different user.
As most of us agree that displaying huge data is not a good UX, especially for the small devices and resolutions. I recommend doing a usability testing to provide some evidence to convince the Client about drawbacks. We need to delight the customers as well as clients. As a best practice, we do usability testing throughout any app development.
- Try to host this matrix in a server (if you don't have a server and if you are using Axure, you can do it by 'share').
- Ask/request the client and other users (or some of your colleagues) to look at the prototype and provide their feedback.
- You may want to prepare script for conducting the usability testing and get the numbers (pros and cons).
This is a great example of why you need to know who the users are and what they need.
I’m going to go out on a limb and say no one user needs to see all this information in this one place all the time.
For example, if the user is an employee who wants to see what training she needs to complete:
1. Choose job title: Field supervisor 2. Display required courses: • Once Quality Core • Once PEC/Safegulf • Every 4 years Crane operator ...
If the user is HR staff who is scheduling training sessions and wants to know which employees to notify:
1. Choose company: QPM 2. Display required attendees Quality Core: • Field supervisor • Lead operator • A operator PEC/SafeGulf: • Field supervisor • Lead operator • A operator
There may be other users who need the information provided according to their own needs.
Also, freed from the table, the data can be smart. You have the scheduling data here, why not show the employee only the courses that still need to be taken, or only those that need to be taken this year, based on data of which courses he has already taken?