I couldn't disagree more. Connect is written in Flash and has serious stability issues. For better or for worse Zoom is stable and intuitive for adult learning.
I don't care to weigh in on any questions about how it's built. I also didn't experience any stability problems, but this was admittedly a while ago now, and the product may have subsequently taken a turn for the worse.
As far as the user experience goes, though, I would say that Adobe Connect makes it possible to create an online classroom in a way that just isn't possible in Zoom.
Which is in no way contradictory to the idea that Zoom is stable and intuitive for adult learning. "Adult learning" is a wide net that covers a lot of learning situations that do not necessarily involve or benefit from a classroom environment. YouTube and printed books are also stable and intuitive for adult learning.
But, for educators who are scrambling to adapt their pre-existing curricula to distance learning, I would argue that preserving as many elements as possible from the working environment that they're used to is pretty key to giving them the best chance possible at a successful transition.
Not that the authors would claim any differently, but I am going to go out on a limb and state that RDBMS Horror Stories are more frequent, and with higher overall impact.
"I used a series of articles from various online media. I don't have copyrights to provide them with this project, so you will have to use your own source."
and
"Create the text folder and fill it in with *.txt files which you'd like to use as the test data source. "
It would be interesting to see what a layout full of source code/terminal history would generate - although you'd have to take into consideration all variety of autocomplete functionality (tab key usage) in text editors to get accurate input data, not to mention window switching shortcuts etc.
Yes, would be very keen to see what sort of result you'd get if (say) you captured keystrokes directly from a collection of engineers (or indeed a broad variety of individuals)
Might be trickier though, as I anticipate you'd need to somehow semantically separate the keystrokes into logical units. Maybe just a time-between-strokes threshold would be enough?
You are confusing E2EE encryption with encryption in transit/rest in the commerce example. The majority of transactions today are encrypted in transit and (you would hope) encrypted at rest so that the bank and selected parties can access the data (including the customer). There is no bank that would encrypt financial data using E2EE so that only the customer and merchant could access it, which is the analogy here on E2EE with messaging.
Sure, now we are looking at tokenization which reduces the risk merchants store your details insecurely, but commerce will always require a bank to store your information and share it with legislators for anti money laundering purposes etc.
> You are confusing E2E encryption with encryption in transit in the commerce example
I think he meant to do that. E2EE between two people has the same kind of requirements as E2EE between a person and a server. If you're trying to say point-to-point encryption, where the server is just a relay between the points, and it handles the data unencrypted, then I think all the arguments for E2EE apply here as well.
I think it would be entirely reasonable to have communications between a person and their bank end-to-end encrypted (isn't that the goal of SSL?) as well as communications between a person and a vendor or a vendor and their bank. Wouldn't this cut down on the instances of credit card information and other data being intercepted while in transit?
