Skip to Content.
Sympa Menu

cat-users - Re: [[cat-users]] Redesign cat.eduroam.org to solve bad user experience?

cat-users AT lists.geant.org

Subject: The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

List archive

Re: [[cat-users]] Redesign cat.eduroam.org to solve bad user experience?


Chronological Thread 
  • From: Zenon Mousmoulas <zmousm AT noc.grnet.gr>
  • To: Paul Menzel <pmenzel AT molgen.mpg.de>
  • Cc: Tomasz Wolniewicz <twoln AT umk.pl>, cat-users AT lists.geant.org
  • Subject: Re: [[cat-users]] Redesign cat.eduroam.org to solve bad user experience?
  • Date: Thu, 3 Aug 2023 23:18:03 +0300

Hello.

On 24 Jul 2023, at 8:07 PM, Paul Menzel (via cat-users Mailing List) <cat-users AT lists.geant.org> wrote:

Am 18.07.23 um 21:39 schrieb Tomasz Wolniewicz:

[...]

W dniu 14.07.2023 o 15:31, Paul Menzel (via cat-users Mailing List) pisze:

Due to the DFN PKI abandonment, my organization’s Radius server certificate expired and needed to be replaced. (We started to use our own Eduroam CA [1].) Therefore, all user devices needed to be updated.

Unfortunately, it wasn’t smooth sailing in several cases. The institute specific cat.eduroam.org URL for our institute [2] is shared with the users, but my expectation, that the page contains all necessary information, is not met, and additional documentation in different languages has to be written. My institute instructions are at the end.

If my expectation is not unreasonable, I see the following pain points with the Web page.

1.  The wording is confusing. For Android users it’s not clear, they need to install the “app” first. The small infobox is often overlooked.
You must realize that we have a uniform design for downloads. Android is a special case. The info box pops up and has the Continue button at the bottom. If the users are not willing to read the info then I do not know how we can make them by changing the layout. You can force the redirect to a local page if you like to provide more detailed info. This can be done for a specific device only.

The font is too small and there is too much text. If the uniform design doesn’t fit the requirements, it should be changed. For four or five different options it could be customized for each choice.

2.  The instructions on the Web page also sound like, you get the program from the Web page, but it’s only a configuration file.
The message says:
"Before you proceed with installation on Android systems, please make sure that you have installed the geteduroam application. This application is available from these sites: Google Play, as local download and will use the configuration file downloaded from CAT to create all necessary settings."
This gives clear instructions where to get the app from.

The font is too small in my opinion, and if you say, it should work with just with *geteduroam*, it should only be written to install the app without having to click on “Download your program …”.

Laden Sie Ihr Installationsprogramm herunter für Chrome OS

Laden Sie Ihr Installationsprogramm herunter für Apple Gerät

Laden Sie Ihr Installationsprogramm herunter für Android 8 und höher

The wording is confusing, as it’s a configuration file for the first two, and for Android users seem to have to install an App from the app store first, which is only shown in the infobox.
One could argue that we should display the information about downloading the app ABOVE the button, however I am quite sure that people would read this even less. I believe that the popup draws more attention. To be sure we would need to test this with actual users.

I can only share my experience.

In my opinion you only need:

Please install [geteduroam]() from your app store, and follow the instructions there. Should you be unable to find your organization in the app’s dialog, please try the [configuration file]() directly.

Without meaning to add to the discussion about the usability of static/dynamic web pages, native apps or native OS/device facilities for prospective eduroam users, I just want to make a point about something more subtle in relation to Android and the helper apps.

CAT was built with a user API that supports all actions a user can take through the web site:

https://github.com/GEANT/CAT/blob/master/tutorials/UserAPI.md

A user journey typically goes through these steps:

1. institution/IdP selection
2. profile selection, if more than one are available
3. device selection, either automatically detected from the UA or manually selected
4. configuration artifact generation and downloading

After the second step the “profileAttributes” API action may be used to return a list of supported devices for the respective profile.
https://github.com/GEANT/CAT/blob/master/core/UserAPI.php#L270
Each device of which may have a “message” property.
https://github.com/GEANT/CAT/blob/master/core/AbstractProfile.php#L621
This corresponds to a generic device attribute. Per the definition:
https://github.com/GEANT/CAT/blob/master/devices/Devices-template.php#L67

'message' if defined will cause a display of the contents of this option as an additional warning

If set, this message should thus be shown as a warning to the user, irrespective of the particular platform.

This is what the CAT web site does, before letting the user proceed with the download (in the last step), hence the “continue” button there.

As you can see in the same file, this message, which may include HTML, provides the inline links to the helper apps for Android:
https://github.com/GEANT/CAT/blob/master/devices/Devices-template.php#L412

There are other implementations hooking into the CAT user API, on the web — besides the native apps, where this issue is obviously moot. Namely:

* A _javascript_ client, integrated in the DjNRO “connect” app. This follows the exact same approach as the CAT web site, for example:
https://eduroam.gr/connect#!cidp=1565&cprof=2791&cdev=android_recent

* A PHP client, as part of the “eduroam configurator” app. This follows a somewhat different approach: it never shows a download widget for Android (all versions) while it shows an image link to the (old) eduroam CAT app on Google Play store. For example:
https://eduroam.no/connect/download/?idp=5438;profile="5741;os=android_recent

The point is that this is a generic “warning” mechanism, employed for pointing Android users to the helper applications they should (first) install. Being generic has the benefit that implementations (CAT user API clients/consumers) can handle this without any special care for Android, or any other particular platform. I think this is inline with one of the basic goals for CAT: abstracting device (platform) peculiarities from users.

Improving the UX for Android should also consider and perhaps try not to break the semantics for this mechanism, IMHO. In this respect, perhaps a new device attribute could be introduced to hint that the user could be discouraged (or prevented) from downloading directly, and they would rather use a helper app. And then text/link/graphics for such apps might be provided through a different attribute, or the presence of the latter could hint to the former. This would require some consideration, however.

6.  The download URL for files is not visible, hovering over the buttons.
Again, could you provide some screens? On my devices the download links are clearly visible in the download confirmation page.

```
<div class="button_wrapper">            <button name="linux" class="guess_os" id="g_linux" style="display: inline-block;">   <div class="download_button_text_1" id="download_button_header_linux">eduroam</div></button>          </div>
```

has no link (href) besides the cursor changes. Users should not click on things, without knowing what is (probably) going to happen.

The “generateInstaller” API action generates (and caches or retrieves from the cache) the configuration artifact and returns a download link (that is not fully qualified) among other things. The CAT web site takes this route and then navigates to the download URL. Same with the DjNRO “connect" app. The "eduroam configurator” app OTOH renders the respective button with a download link, after calling this API action and caching the response.
As Stefan Winter noted it is trivial to derive the download link. The “downloadInstaller” API action also takes care of generation/caching, so there is no practical difference.
If for any reason the implementation takes the 2-step approach, for example as a means for a cross-origin web app to count downloads served from cat.eduroam.org, then it may not be sensible to call the “generateInstaller” API action before a download is requested by the user, therefore it will not be able to show the download link to the user in such a case.

Kind regards,
Zenon Mousmoulas


  • Re: [[cat-users]] Redesign cat.eduroam.org to solve bad user experience?, Zenon Mousmoulas, 08/03/2023

Archive powered by MHonArc 2.6.24.

Top of Page