3 ms·

> Look at what Lotus Notes accomplished in the 1990s Could you please develop your idea?:)

PaulHoule 5y ago
Lotus Notes was based around a document database, long before document databases were cool. Patents concerned many things, but the most valuable of which was that the system could merge changes to the documents made by different users and even had a system for manual exception handling when the automated algorithm didn't work. Notes was oriented towards workflows where several users might need to contribute actions towards completing a ticket. In 2021 some of parts of the workflow might be completed by an A.I. or might involve an IoT system that takes measurements or physical actions. With websockets and similar tech, the UI ought to update automatically when the state of the system changes. You might not even notice that steps in a workflow happened if they happened quickly enough. One feature of Lotus Notes that nobody would try today (email software is mostly about resilience to cyberattacks today) was that Lotus Notes had an integrated email client. That would be helpful if the application is "an email gets sent to the company and several people coordinate in replying to it", The core concept I want to push is that the real area where applications get in trouble is with the back end database. If you made a bad decision five years ago you might be living with it for the next twenty years or if you are lucky your product will EOL soon because of it. To take one example, in one month I worked on two legacy systems that had database tables with twelve or so datetime fields to keep track of important events in the history of a student (from pre-application to alumni) or a shipping pallet. Turned out that some of these objects didn't take straight line trajectories through the system (data was wrong and corrupted) and it's a bear to write queries to ask things like "where was Pallet X on April 9, 2004?" A single database structure (object id, state, start_time, end_time) works to keep track of a changing state. If you ask developers to reinvent the wheel they'll probably do it wrong. A true "low code" system would have schemas built in that represent things like this the right way... So the easy way, the default way, is the right way.

Lotus Notes was based around a document database, long before document databases were cool. Patents concerned many things, but the most valuable of which was that the system could merge changes to the documents made by different users and even had a system for manual exception handling when the automated algorithm didn't work. Notes was oriented towards workflows where several users might need to contribute actions towards completing a ticket. In 2021 some of parts of the workflow might be completed by an A.I. or might involve an IoT system that takes measurements or physical actions. With websockets and similar tech, the UI ought to update automatically when the state of the system changes. You might not even notice that steps in a workflow happened if they happened quickly enough. One feature of Lotus Notes that nobody would try today (email software is mostly about resilience to cyberattacks today) was that Lotus Notes had an integrated email client. That would be helpful if the application is "an email gets sent to the company and several people coordinate in replying to it", The core concept I want to push is that the real area where applications get in trouble is with the back end database. If you made a bad decision five years ago you might be living with it for the next twenty years or if you are lucky your product will EOL soon because of it. To take one example, in one month I worked on two legacy systems that had database tables with twelve or so datetime fields to keep track of important events in the history of a student (from pre-application to alumni) or a shipping pallet. Turned out that some of these objects didn't take straight line trajectories through the system (data was wrong and corrupted) and it's a bear to write queries to ask things like "where was Pallet X on April 9, 2004?" A single database structure (object id, state, start_time, end_time) works to keep track of a changing state. If you ask developers to reinvent the wheel they'll probably do it wrong. A true "low code" system would have schemas built in that represent things like this the right way... So the easy way, the default way, is the right way.