Survey Takeaways #164
Description
-
Documentation
- 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.