Thank you, Marek. We were aware of the php requirement. Sorry, perhaps I should have added that I was looking for functional impact after the upgrade.
So we are now in T11, and here are the main things I took away from the change:
- Loss of TinyMCE. This may have been well advertised and I am sure there are very good, valid reasons for dropping it. However, the loss of the more powerful TinyMCE editor has been devastating for us. We make heavy use of forums, but also books, where we want presentation to be as polished as possible. TinyMCE allowed us to create tables, manipulate fonts beyond what's offered by the theme (for instance, to quote computer code, screen output, or otherwise emulate what users may see in other screens or printed matter outside the LMS, and therefore, outside our usual theme styles). That capability is now gone, as is the full-screen editing mode. We now have to resort to external editors, then "plant" the resulting HTML in the native editor. This was a substantial loss for us.
- Changes in report file names and some outputs. Again, this may have been documented somewhere. When downloading scheduled reports (something we have automated for a good while now) the file names will differ from 2.9. For example, downloading a scheduled feedback activity report would give "feedback", while now it is "feedback [name of feedback activity]", and some existing reports changed the way they output data. In general, the reporting capabilities of T11 are great, we just had to tweak the Big Data cruncher in a couple of places.
- Better usability for seminars. The way seminar/session information is presented reduced the number of clicks to sign up. This was a nice improvement.
- Better calendar. The improvements here are welcome. I think we hit a glitch with how certain seminar changes, such as cancellations, are captured by the calendar immediately after upgrade. We had users reporting "ghost" seminar bookings for sessions booked pre-upgrade but that were no longer there. We have been unable to repro, and I'm sure it was a rare occurrence.
- Limited menu options. In 2.9, we had a navbar drop-down menu showing users all courses they were enrolled in, one click away from any screen. We are told that type of menu is not possible in T11, and that has increased the number of clicks to course.
- Limited email options. Again possibly well documented, but it seems T11 only sends email out through the specified noreply account. In T2.9, we had a form that sent email to a case management system on behalf of the user. Maintaining this ability in T11 required tweaking the codebase, something we'd rather not do.
- Completion boxes are not boxes. Back to UX, I wonder what prompted the change from boxes to circles for non-manual completion checkboxes. Circles are not a common user interface paradigm. Actually, they are, most users would think of them as radio buttons, but in this context, the circles have nothing to do with selecting one of various possible options - in fact, they are not clickable. To make matters worse (on the UX front), the help text still refers to them as "completion tick boxes", and continues to describe dotted-line boxes and solid line boxes. Yes, I know we can go to the language pack and correct the help text for completion (I would expect help text to move at same pace as the code though). But when the user sees a succession of activities where completion is tracked in differing ways, how do they make sense of that random sequence of shapes borrowed from familiar interfaces, but whose paradigms do not apply?