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

[Daniele Albrizio <albrizio AT units.it>]

On 25/02/21 14:13, Paul Dekkers wrote:

    Hi,
      
      
      On 25/02/2021 11:06, Daniele Albrizio wrote:
      
      
> I agree on almost anything you (Stefan
>         Winter) pinpointed in your analysis. And I thank you for the
>         quite exhaustive essay that is very useful for us, local
>         administrators, to understand the vision of the project and the
>         choices taken.
>         
>         
>         I'm indeed glad to evolve to geteduroam.
>         
>       
      
      I'm happy to hear that. (We've been working on geteduroam for over
      a year, given our diverse community and ecosystem and the strong
      will to make an eduroam client for all and not just a few
      use-cases or institutions (as you see more of in the stores). And
      fully aligned with CAT, but with an additional feature of the
      pseudo-accounts that helps so many institutions with eg. Cloud
      IdPs.)
      
      
> I'm also strongly convinced that eduroam
>         is not a monolithic private project, but is backed and used by a
>         huge scientific and education community. The list of names
>         inside geteduroam effort (NORDUnet, DeiC, SURF, Uninett) is a
>         vigorous evidence of this.
>         
>         
>         That said, I'm a bit less in line with the observations of Paul
>         Dekkers about the minor issue of changing icons visible inside
>         phonebook.
>         
>         
>         It's normal that this is seen as a minor issue by developers and
>         NRENs just because they do not have or have few END USERS.
>         
>       
      
      Maybe you didn't mean to, but I feel offended by the implication
      we didn't consider end users. (The capitalization didn't help.)

No, it's not my intention to offend anybody, especially those who work hard for eduroam. I agree, the capitalization didn't help. I should have been more careful about that.

    We
      carefully included end-users in testing the Apps and workflow;
      with a couple of institutions in (at least 3) different countries,
      where we studied the way they used apps (without
      interfering/instructions), and get their feedback about usability
      (some also with questionnaires).
      
      
      But also outside of these structured tests, we received feedback
      from a few institutions that they had a significant reduction in
      helpdesk calls in contrast to their previous workflow. (This is
      actually with users also using geteduroam for eg. iPhones, but
      also with geteduroam as Android app replacement.) That really made
      us confident.
      
      
      And for instance the feedback on older and slower devices, as Guy
      mentioned, we needed to consider devices in developing economies
      too. I really appreciated Guy testing this with us, and it
      improved the clients I think as much as we could - back in
      September 2020.
      
      
      We learn every time we get feedback from users, and we definitely
      considered this during the development process. And this feedback
      came from various angles.
      
    
    I'm glad of all this work you carried out, I was not aware of this.
    But still I can't explain myself how the issue of changing icons did
    not arise strongly as a problem.
    
      At this stage, I'm wondering why you apparently stumbled upon some
      issues with the Android App, but didn't help us with this
      feedback. We were aware of this issue, and changed strategies in
      late November for future releases. (As Stefan explained, not for
      Android <=10.)

This is easily explained, even if it's not a valid excuse to my ignorance. I did subscribe the developers mailinglist, not suggested by my NREN but as a personal effort at the beginnings of CAT developement. Then I quit reading as I tought that strong operative changes like this one should be pushed down by my NREN and the vast majority of threads on that ml were of scarse interest to me. Our NREN did not notice us about this change this time. I heard about geteduroam from discussions between institutions but for some reason I wrongly considered geteduroam as a third party effort yet to be considered by GEANT. This obviously happened for lack of information search by my side and heavy work duties on other tasks. So I suddenly opened my eyes when the news hit the users mailing list.

    ...
    
    This
      change affects user's workflow towards several different
      applications. Usually when I have to communicate with a contact of
      mine, I start from phonebook, I rapidly scroll which is the best
      method to use that is available also to the other side and I
      choose this to communicate.
      
> It's part of the main communication
>         workflow when we use a smartphone.
>         
>         The list of channels is growing rapidly with technology
>         including fast payments, different level of privacy chats,
>         video, file sending, etc.....
>         
>         
>         I don't see this as a minor problem. It's indeed not a bug, is a
>         bad choice. Normally we don't share eduroam profiles using
>         whatsapp or Signal, but we publish them on well known websites.
>         
>       
      
      I believe it was also with some OEM-based browsers. It was an
      example.
      
      
      There is an upside and downside to a lot of decisions. And some
      users / institutions do A, other do B.
      
      
      This is in part what you get with software that is being
      developed, sometimes you make a good choice sometimes you don't.
      
      
> So, even knowing we are late with Android
>         10 and 11 support, would it be possible to DELAY geteduroam
>         adoption after the removal of the responsible mime type?
>         
>         
>         User complaints on this general and widely adopted things has to
>         be handled with a certain helpdesk effort and if "glitches" can
>         be avoided it should be done in advance.
>         
>       
      
      I equally have users that I had to explain to "why geteduroam
      still wasn't suggested from CAT". And helpdesks that tell me about
      their reduced load since they suggest geteduroam.
      
      
> Sorry for complicating your already hard
>         work, I'm open to discussion or adverse opinions.
>         
>       
      
      I'm glad you share it, but also I hope you understand why I feel a
      bit sad now. The reply from Stefan is already very complete, but
      this made me feel I had to reply myself, also since you mentioned
      me.
      
      
      Paul
      
    
    Sure, I learned about the huge backstage interesting work you
    carried on from your post so I thank you for having found time to
    write that to me and us.

I understand you may feel sad about some of my ignorance driven rants (I was meant to let some silent problem to arise and to get solved for all of us), but don't mind too much, collect what can be useful to you and carry on with geteduroam process.

I thing that eduroam can be  great as long as it's easy to get, and this is what you are doing for the vast community.

Daniele

-- 
-------------------------------------------
Daniele Albrizio
Università degli Studi di Trieste | University of Trieste
Ufficio Reti di Ateneo | University Networks Office
Via Alfonso Valerio 12 - 34127 Trieste (Italy)
daniele.albrizio AT units.it
Tel. | Ph. +39 040 558 3319

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature