people will refer to documentation a lot so it should be easily accessible and searchable.
each method should clearly document the data types of its inputs and outputs
some users may be completely unfamiliar with python data types so explanations in the documentation could be useful. (One user was confused by how we check if a contact is in a list)
An alternative would be to write messier rules that may be easier to understand. For example convert a list comprehension into a bunch of if statements.
people are unclear if message.content also contains input from past emails
Debugging
simulating on n-latest emails is not always useful. Sometimes these emails won't trigger the rule in which case there is no debugging feedback.
it would be useful to see exactly which emails are being affected by a rule across the entire inbox or the selected folders.
the difference between simulating and production is not obvious to people and leads them to being scared to implement rules.
make setting flags obvious. In general changes should be displayed obviously and things that don't change should be hidden. Think how useful git Diff is.
Class Structure
getting all emails from a list of contacts would be useful (unclear if the user wanted an AND or an OR across the list)
get all emails of a certain priority would be useful.
filter emails based on the mailing list they are sent to
reply_all is confusing
people want aggregate methods so number of emails from a specific contact for example
people mostly use message arrival
Modes
people are not using modes. This is probably a UI or length of survey issue since there is not much incentive to use modes for simple examples
people do not find much use for a trigger to switch modes
Future Work
people have an initial inclination to start treating the robot like a system that understands structured data. They want to be able to put in subjects and have the robot perform tasks.
Documentation
Debugging
Class Structure
Modes
Future Work