Background info: we use RTM in our business and we often have (large) predictable sets of tasks anchored on specific business processes. For example: hiring and setting up new staff members (all the way through to setting reminders to evaluate their contracts near the end, 7 months into the future), enrolling new customers, product or service changes that have 6 related tasks, etc.

I have clever spreadsheets that can produce these sets of tasks with very rich metadata (such as parameterised URLs that link into our web based systems as near to the task as I can programmatically predict), so that our administrative staff can blast through their tasks in a predefined optimal order (two or three Smart Lists) and with minimal friction, because Shift+U takes them to the task screen and the specific info is already captured in a note field. Note: this is an absolute game changer in team productivity; wel worth years of multiple Pro accounts.

The difficult bit is always finding a way to allow end users (i.e. non-tech wizards) use basic software (i.e. spreadsheets, but not custom code) to 'pump' these task sets into RTM.

I recently found this tool / site: http://files.alnorth.com/rtm/index.html

It is essentially a multi-line version of the Smart Add field in the web app. Although the service works great and it is available for self-hosting, etc, the feature to have the Smart Add field in the web site accept more than one line would be a great addition and open up a slew of additional integration options. (because an external tool would only have to output a set of lines).

I realise that you would have to think about protection against flooding, but the very same problem already exists for the API, so this is really just more of the same.

This could be done without breaking existing UI by just having the existing field in the Web App UI accepting and parsing multiple lines as if they were multiple calls to the single line processing.

I did some research into existing suggestions:

https://www.rememberthemilk.com/forums/ideas/260/ --> it references the e-mail list feature, which is essentially useless for list of tasks that have any sort of metadata, because you hit line length limits in the email world at around 50 chars. Try it -- that is not very much.

It also suggests some sort of wildcard / pattern parsing, so that

buy bread|milk|eggs #groceries ^today

becomes

buy bread #groceries ^today
buy milk #groceries ^today
buy eggs #groceries ^today

I call this "wildcard parsing" and I think it is extremely complicated to correctly implement and only useful to a very small number of people that are comfortable with such syntax. (it is also wildy error prone on both user and programmer side)

https://www.rememberthemilk.com/forums/ideas/9137/ --> this suggests a character to separate multiple tasks, so that more than one task can still go on one line.

This could be a possible implementation, but I have these reservations:
1) if '|' can be used as a separator, why not the newline character? Technically (for the parsing) this is equivalent.
2) manually typing multiple tasks on one line becomes very cluttered in the UI, because the already annoying little bit of sideways scrolling becomes a LOT of sideways scrolling.

NB: that post title suggests a task delimiter as I described but the explanation is actually more like wildcard parsing.

UI suggestions:
* until a newline character is input, retain behaviour as is. This will not disturb the many users that will not need nor use this feature. Only when a newline is noticed, swap the (visible) single line element for a multiline text field and grab the existing content of the single line field (i.e. the first task that was entered).
* The current Smart Add field turns ^ # * etc into coloured blobs for parsed data. As a tech-savvy pro user, I would be fine with a UI 'downgrade' at the switch point from single to multiple lines: single line gets coloured blobs and suggestions in a dropdown, etc and multiline just becomes a multiline text element (you could make it bigger at that point) but without adaptive assistance.

Note to fellow users interested in this: please indicate which details of this suggestion you like and agree or not; there are several ways this could be implemented and some may be more useful to people than others.