[graycat]

> plain English

Gads. That's tough to do well, and as a user I'd always wonder if the software got it right unless I just kept checking.

And why try with plain English? Heck, long ago I commonly wrote Fortran programs with very easy to use input: Start with a file that asks for all the data. Each line of that file starts with some character to indicate that the line is such a request and with, say, a number, to indicate what request it is. Then a user just types in their data after each such request. It's dirt simple to implement and for users to use. So, for human readable input, just do it that way. Natural language understanding -- f'get about it.

Once I programmed something where the human input was a lot like XML -- really simple to use.

[dmortensen]

I agree and I could easily see myself use something like that. However, I want something (naively perhaps) which my Mom can use. My worst nightmare is one where early users inadvertently create some sort of "syntax" which my mom use to discard this as a service for her. Like she discarded the idea of twitter, because people created a RT, MT $bla #bla etc. "syntax".

[graycat]

Your goal is fine, fully appropriate. Of course your mom should be able to use it; anyone who can type and read should be able to use it. Fine. And there is no need for any nonsense gibberish such as "RT, MT".

But, I believe you are over estimating the importance of having some natural language understanding, under estimating the difficulty of achieving that understanding reliably in software, and are very much under estimating how easy to use, even for your mother, for anyone who can type, something like I outlined can be.

E.g., when I was in grad school, I took out some time to earn some money so that my wife and I could complete our Ph.D. degrees. For the money, I worked as an applied mathematician, computer guy in a research shop doing work mostly for the US Navy. So, yes, we had secretaries who did a lot of typing but had no word processing.

As part of my work in applied math, I ended up as system administrator of a super-mini computer. Of course, for programming, it had a text editor. If only for writing the computer manuals, it had a simple text formatting program, call it a member of the family of Runoff programs. And I'd gotten a daisy wheel printer nicely driven -- asynchronous serial communications with ASCII characters and the XON/XOFF handshaking (pacing) protocol -- by the computer. So, we were GO to do a LOT of typing.

Soon enough the secretaries wanted to get on board with this new stuff. So, for them, one at a time, we pulled some 5 conductor, general purpose signal cable with a 25 pin plug at each end (we only connected the pins for the signals SEND, RECEIVE, and SIGNAL GROUND), and a dumb terminal.

Bottom line: All the secretaries got on board right away. The ones without a terminal begged for one. No one ever gave one of the secretaries more than a few minutes of 'training'. They all caught on right away, to logon, files, the hierarchical file system, the text editor, the runoff program, the daisy wheel printer, etc. Right away.

Later as a college prof, I did the same for the business school, and again the secretaries 'got it' right away.

Gee, we weren't asking them to write macros in TeX!

So, back to my suggestion:

You want an appointment. So, you send something like

     === May we meet?  Let's pick a time and place.

     === My name

     === My job

     === My e-mail address

     === My phone number

     === Subject of meeting

     === When to meet

     === Where to meet

or some such. Then you use just typing to insert data under each of these or some such, likely need something better, but you get the idea, and send your e-mail.

A human, including your mother, can read it and respond. And they can respond with a similar e-mail.

If either end of the communications is using your software, then the software can read that data and make sense of it much easier than for natural language processing.

Or, send the person some e-mail with a URL to a server with a Web page with a form and some JavaScript to help the person fill out the form. Then we're into just a Web form solution that we know very well how to handle.

Forms work great; people are really good at entering data into forms.

For people who have your app, it can replace the Web site.

No way do you have to use gibberish such as "RT, MT". Instead, everything a user reads can be in complete English sentences with a button with Help for more explanations, etc. It can be easier to use than most Web forms, and 1+ billion people use those. It can be easier to use than Google, e.g., where Google has those little horizontal bars to indicate (I never got that memo or read any explanation in a help message) for more options. Last I checked, Google had a lot of users. It can be easier to use than the Amazon Web site, easier to use than Facebook.

You are underestimating the ability of your target users to make use of simple computer user interfaces.

My guess is that there is no way natural language processing can be good enough that, net, it is easier to use than just some simple forms or something like I outlined above.

Gibberish like "RT, MT" is really a straw man to knock down. Instead, never but never should there ever be any gibberish or undefined terminology or undefined acronyms in any user interface. That rule is easy to obey, and natural language processing is a very hard way to obey it.

The real business need and opportunity is meeting scheduling, not finding work for natural language processing.

[xerophyte12932]

Well the scheduling program works as your PA, and is expected to deal with other humans who want to schedule meetings with you. So not only does it have to understand their correspondence, it also has to negotiate with them. This requires NLP

[graycat]

I can't agree. In short, the communications can be done with forms, on a smartphone, Web site, or similar.

[xerophyte12932]

As someone else mentioned, that would require the other party to click a link and be directed to some webpage for said form. I agree, that's not too much of a hassle and in my instances can be far more effective than setting up a meeting on email (for example if it displays the free slots of all involved parties like doodle.com), but that's what x.ai is offering: letting people scedule the way they already do