User Feedback Summary — FLA-- (Turing Machine Editor)
Link to Survey
1. Overview
To evaluate the usability and feature completeness of FLA--, a formal feedback survey was distributed to users via a structured Google Forms questionnaire. The form asked three open-ended questions:
- What did you like about FLA--?
- What did you find unintuitive/difficult/inconvenient about FLA--?
- What features would you like us to add to FLA--?
8 responses were collected between 14–15 September 2026. Raw responses were exported as a CSV and reviewed by the team to identify recurring themes. This document summarises those themes and records which items were selected for the next sprint backlog, along with the reasoning behind each decision.
2. What Users Liked
| Theme | Representative feedback |
|---|---|
| Simplicity of the visual editor | "The visual editor was simple and easy to use." |
| Engaging, non-trivial learning experience | "It was challenging and fun and made me think outside the box... not a cram and pass type of module." |
| Visual design / theme | "Looks fire." / "The theme" |
| Time saved vs. manual diagramming | "Time is saved instead of physically drawing machines." |
| Fast automatic execution | "I am able to automatically run my machine given an input in a matter of seconds." |
| Intuitive controls | "Controls were intuitive." |
Takeaway: The core value proposition — a fast, visually appealing alternative to hand-drawing Turing machines — is landing well with users. The retro visual theme was called out positively more than once, validating that design direction.
3. Pain Points Identified
| Issue | Representative feedback | Severity |
|---|---|---|
| Multi-tape Turing machine testing crashes | "Testing does not work with multi-tape turing machines. If you try it will just crash." | High — bug |
| Default playback speed too fast | "The default speed of the playback is too fast." | Medium |
| Self-loop creation is inconvenient | "Making a self loop, I had to do it in the code editor or transition panel which was inconvenient." | Medium |
| Font size too small at times | "Fonts are too small at times." | Low |
| Initial learning curve / confusing at first | "Can be a bit confusing to use at first." | Medium |
| No onboarding for users unfamiliar with the code/TM syntax | "I don't know how to code your TMs." | Medium |
| Conceptual difficulty of Turing machines themselves | "Some of the concepts were a bit hard to grasp." | Low — inherent to subject matter, not the tool |
Note on outlier response: One response ("Nothing" / "Everything" / "nullify it") did not provide constructive or actionable feedback and has been excluded from thematic analysis and backlog decisions.
4. Requested Features
| Request | Frequency / notes |
|---|---|
| Ability to save test cases alongside a TM | Requested directly |
| Tutorial / onboarding flow | Requested directly; reinforced by the "don't know how to code your TMs" pain point |
| Dark mode | Requested directly |
| Easier self-loop creation (canvas-based, not just code/transition panel) | Requested directly; reinforced by the self-loop pain point above |
| Ability to share machines with colleagues | Requested directly |
| Quiz feature on Turing machine concepts | Requested directly |
| Ability to upload own documents | Requested directly; scope currently unclear |
5. Integration into Development — Sprint Backlog
Feedback was reviewed as a team and the most sensible and impactful items were pushed into the next sprint's backlog. Prioritisation was based on (a) whether the issue was a functional bug vs. a feature request, and (b) how many independent pieces of feedback pointed to the same underlying problem.
| Backlog Item | Priority | Justification |
|---|---|---|
| Fix multi-tape testing crash | High | Confirmed functional bug affecting core simulation functionality; only item classified as a defect rather than an enhancement request. |
| Add adjustable/slower default playback speed | Medium | Directly requested and independently reinforced by a related complaint about the tool feeling "confusing at first" — a slower default may ease initial comprehension. |
| Improve self-loop creation UX (canvas-based option) | Medium | Same issue was raised both as a pain point and as a feature request by different aspects of the feedback, indicating it's a genuine friction point rather than a one-off preference. |
| Add onboarding tutorial | Medium | Directly requested and reinforced by the "don't know how to code your TMs" comment — addresses a real barrier to entry for new users. |
| Add dark mode | Low–Medium | Popular, low-implementation-risk request; deferred behind functional fixes but retained for the sprint. |
| Save test cases with a TM | Medium | Directly requested; supports the testing workflow already highlighted as valuable by other respondents. |
| Increase base font sizes across the UI | Low | Small, low-effort accessibility fix. |
Deferred to a later backlog (not this sprint):
- Share machines with colleagues (requires backend/collaboration work beyond current scope)
- Quiz feature on TM concepts (educational content feature, lower priority than core tool stability)
- Upload own documents (scope not yet well-defined; needs further requirements gathering before estimation)
6. Conclusion
The feedback collection process surfaced one confirmed defect (multi-tape testing crash), several UX friction points with converging evidence across multiple respondents (self-loop creation, playback speed, onboarding), and a set of feature requests that have been triaged by priority and technical feasibility. The highest-priority and most broadly supported items have been added to the next sprint's backlog, with lower-priority or under-specified requests deferred pending further scoping. This provides a clear, evidence-based link between user feedback and planned development work.