“Ketabi Ke Khandeam” — کتابی که خواندهام
Public Participation · Personal Reading Records · Competition Management · Jury Evaluation
Project positioning
This project was developed for the Libraries, Museums and Documents Center of Astan Quds Razavi as an online platform for organizing book-reading competitions and managing participant submissions.
The system combined three ideas in one application:
- a public user portal for readers,
- a competition-management system,
- and a jury/reviewer workflow for evaluating submissions.
In addition to the web application, a mobile application was delivered using a WebView-based approach, allowing the same system to be accessed conveniently from mobile devices without maintaining a separate native application codebase.
The historical Persian title of the system was:
کتابی که خواندهام
A suitable English portfolio title is:
Online Reading Competition & Book Review Platform
Classification
- Project Type: Public-Facing Web Application / Competition Platform
- Client Context: Libraries, Museums and Documents Center of Astan Quds Razavi
- Primary Domain: Reading Competitions / Cultural Participation
- User Model: Public Users, Jury/Reviewers, Administrators
- Delivery: Web Application + Mobile WebView Application
- Core Functions: Registration, Personal Book Records, Competition Participation, Written Submissions, Question Responses, Jury Evaluation, Competition Administration
- Portfolio Relevance: High
- Suggested CV Relevance: Tier B/A — Public Platform, Role-Based Workflow, Evaluation System
Website Card
Title:
Online Reading Competition & Book Review Platform
Historical Name:
Ketabi Ke Khandeam — کتابی که خواندهام
One-line Description:
A public reading platform for online book competitions, reader submissions, personal reading records, jury evaluation, competition management, and mobile access through a WebView-based application.
Categories:
- Web Application
- Cultural Platform
- Competition Management
- Book Review
- Public Participation
- Jury Workflow
- Role-Based Access
- Mobile WebView
- Education / Culture
Concept Tags:Public Registration · Role-Based Access · Competition Workflow · Book Reviews · Jury Evaluation · Reader Portal · WebView App · Admin Dashboard
Executive Summary
The platform was designed to support recurring reading competitions organized around different occasions, events, or themes.
The general workflow was:
Competition Announced
↓
Books / Reading Topic Published
↓
Public User Registration
↓
Reading
↓
Summary / Review Submission
↓
Competition Questions
↓
Jury Evaluation
↓
Results
The system therefore went beyond a simple online questionnaire.
It managed the complete participation lifecycle from registration to evaluation.
Project Context
The application was commissioned as part of a library-related project for the Libraries, Museums and Documents Center of Astan Quds Razavi.
The objective was to provide a digital platform for book-reading competitions that could be accessed online by the public.
Instead of requiring participants to submit paper forms or attend a single physical location, the system allowed users to:
- register,
- participate remotely,
- record what they had read,
- submit written summaries,
- answer competition questions,
- and receive results through the platform.
Product Concept
The platform combined three main product dimensions:
Personal Reading Record
+
Competition Participation
+
Jury Evaluation
This made the application more than a one-time competition form.
It was designed as an ongoing reading environment that could support multiple competitions over time.
User Roles
The system had three main access levels:
- Public User
- Jury / Reviewer
- Administrator
Each role had a clearly different responsibility.
1. Public User
The public-user role was designed for ordinary participants.
A person could register using a mobile number and create an account.
After registration, the user could interact with the reading and competition features.
Public Registration
The login screen visibly separated:
Existing User
→ Login
New User
→ Registration
This confirms that the platform supported self-service public registration rather than being restricted to pre-created organizational accounts.
Mobile Number Registration
The user described mobile-number-based registration as the main public onboarding mechanism.
A modern implementation could evolve this toward:
Mobile Number
↓
OTP Verification
↓
Account
but OTP should be described as a V2 recommendation unless separately evidenced in the historical implementation.
My Books
Public users could maintain a list of books they had read.
This created a personal reading record.
The concept was not limited to competition-only participation.
A user could keep a history of books and related notes or summaries.
Personal Reading Record
Conceptually:
User
↓
Book
↓
Reading Record
↓
Summary / Notes
This makes the platform partly a lightweight personal reading journal.
Book Summary Submission
For each relevant book, the user could write a summary or personal understanding of the book.
The key point is that the submission was not simply a multiple-choice answer.
The system collected written content.
This written content could later be evaluated by assigned reviewers.
Competition Questions
In addition to the written summary, participants could answer competition-related questions.
This created a mixed evaluation model:
Written Submission
+
Question Responses
Depending on the competition, both could contribute to evaluation.
Participation Flow
A typical user journey can be represented as:
Register
↓
View Competition
↓
View Book / Topic
↓
Read
↓
Write Summary
↓
Answer Questions
↓
Submit
↓
Wait for Evaluation
↓
View Result
Public Dashboard
The historical dashboard includes quick-access sections such as:
- My Books
- Competition Results
- Announcements
- Help
and also displays recent books.
This indicates that the participant portal was designed as a persistent user workspace rather than a single form.
Dashboard Evidence
The historical screenshot shows summary cards containing counts for areas such as:
- user books,
- competition results,
- announcements,
- help/reference content.
This is strong evidence of an actual user dashboard.
Announcements
The platform included announcements.
This was useful for:
- competition announcements,
- deadlines,
- instructions,
- result publication,
- general cultural information.
Help / Guidance
A Help section was included to explain how the system or competitions worked.
This is especially important in public-facing applications because users cannot be assumed to have prior system training.
Results
Users could access competition results from their dashboard.
This provided a complete participation loop:
Participation
→ Evaluation
→ Result
2. Jury / Reviewer
The second access level belonged to judges, reviewers, or supervisors assigned to competitions.
These users did not need full administrative access.
Their role was focused on evaluation.
Jury Assignment
Different reviewers could be selected for different events or competitions.
This means reviewer access could be temporary or competition-specific.
Conceptually:
Competition
↓
Assigned Jury
↓
Permitted Submissions
Jury Responsibilities
The reviewer role could access user submissions relevant to the competition and evaluate them.
The evaluation target included at minimum:
- submitted book summaries / written responses.
The user also described reviewers as judges and supervisors associated with specific occasions.
Jury Workflow
A useful conceptual flow:
Submission Received
↓
Assigned to Jury
↓
Review
↓
Evaluation
↓
Result
Separation from Administration
This is an important architectural distinction.
A reviewer could evaluate submissions without needing permissions to:
- create users,
- configure the system,
- manage all competitions,
- change administrative settings.
This supports the principle of least privilege.
3. Administration
Administrators had the broadest system access.
Their responsibilities included:
- creating new competitions,
- managing users,
- assigning reviewers,
- managing books,
- publishing announcements,
- supervising results,
- monitoring system activity.
Competition Management
The administration layer could create and manage competitions around different occasions.
Each competition could conceptually define:
Competition
├── Title
├── Theme
├── Books
├── Questions
├── Start Date
├── End Date
├── Jury
└── Status
The exact historical field set should be documented only where evidence exists, but this represents the natural domain model implied by the described workflow.
Multiple Competitions
The system was designed for repeated use.
It was not a one-off landing page.
Different competitions could be created at different times for different themes or occasions.
This is a major architectural difference.
Competition Lifecycle
A competition can be modeled as:
Draft
↓
Published
↓
Open for Participation
↓
Closed
↓
Under Evaluation
↓
Results Published
For V2, these states should be explicit.
Book Management
The platform included book-related administration.
Books could be associated with competitions or made visible to users.
The dashboard’s “latest books” section supports the presence of a book catalog/listing concept.
User Management
Administrators could supervise registered public users.
The system needed user identity not only for login but also for associating:
- books,
- submissions,
- results,
- participation history.
Jury Management
Administrators could decide who was allowed to act as reviewer or judge.
This supports competition-specific role assignment.
Result Management
After evaluation, results could be published or made available to users.
A modern design should preserve the distinction between:
Evaluation Result
and:
Public Result Publication
so that results can be finalized before being shown publicly.
Role-Based Access Control
The historical system had three clear role groups:
Public User
Jury
Administrator
A modern version should formalize this with RBAC.
Example permissions:
competition.view
competition.participate
submission.create
submission.review
competition.manage
jury.assign
result.publish
Access Matrix
Conceptually:
| Capability | Public User | Jury | Administrator |
|---|---|---|---|
| Register / Login | ✓ | ✓ | ✓ |
| View Competitions | ✓ | ✓ | ✓ |
| Submit Summary | ✓ | — | — |
| Answer Questions | ✓ | — | — |
| Review Submissions | — | ✓ | ✓ |
| Create Competition | — | — | ✓ |
| Assign Jury | — | — | ✓ |
| Publish Results | — | — | ✓ |
Submission Model
The central content object is the participant submission.
A modern model could include:
Submission
├── user_id
├── competition_id
├── book_id
├── summary
├── submitted_at
├── status
└── answers
Submission Status
Recommended states:
Draft
Submitted
Under Review
Reviewed
Finalized
This prevents accidental edits after evaluation begins.
Question Model
Competition questions should be independent records.
Possible question types:
- multiple choice,
- text,
- short answer.
Only include historically verified types when presenting the old version.
For V2, a flexible question engine is a reasonable architectural direction.
Evaluation Model
The reviewer should evaluate a submitted record rather than edit the participant’s original content.
Modern separation:
Submission
↓
Evaluation
where:
Evaluation
├── reviewer_id
├── score
├── comment
├── status
└── evaluated_at
Scoring should be described only if historical evidence confirms numerical scoring.
If not, use the broader term evaluation.
Multiple Reviewers
If future competitions require more than one reviewer, V2 can support:
Submission
├── Evaluation A
├── Evaluation B
└── Evaluation C
and then calculate or finalize the result according to competition rules.
This is a V2 design direction.
Mobile Application
A mobile application was also delivered.
The implementation approach was based on WebView.
This means the core web application remained the primary product.
The mobile package presented the web system inside a mobile application shell.
Why WebView Was Appropriate
For this project, WebView offered practical advantages:
- one primary codebase,
- faster delivery,
- lower maintenance,
- consistent web/mobile behavior,
- easy content updates.
This was appropriate for a form- and content-driven application.
Important Portfolio Accuracy
The application should be described as:
Web Application + Mobile WebView Application
not as a fully native mobile application unless a separate native implementation existed.
Web Application Architecture
The logical structure can be represented as:
Web Application
├── Authentication
├── Reader Portal
├── Book Records
├── Competitions
├── Questions
├── Submissions
├── Jury
├── Results
├── Announcements
└── Administration
Domain Model
A modern reconstruction can use the following core entities:
User
Book
ReadingRecord
Competition
CompetitionBook
Question
Submission
Answer
JuryAssignment
Evaluation
Result
Announcement
User
Represents:
- participant,
- reviewer,
- administrator.
Role/permission determines capabilities.
Book
Represents a book available in the system.
Possible fields:
Book
├── Title
├── Author
├── Description
├── Cover
└── Status
Only historically verified metadata should be shown in the historical feature list.
Reading Record
Represents a user’s personal relationship with a book.
ReadingRecord
├── user_id
├── book_id
├── notes
└── created_at
This separates personal reading history from competition submissions.
Competition
Represents a reading event.
Competition
├── Title
├── Description
├── Start
├── End
├── Status
└── Rules
CompetitionBook
A many-to-many relation allows a competition to involve one or more books.
Competition
↕
Books
Question
Questions belong to a competition.
Competition
↓
Question
Submission
A participant’s formal entry into a competition.
User
+
Competition
+
Book
↓
Submission
JuryAssignment
Defines who may evaluate which competition.
Reviewer
↓
JuryAssignment
↓
Competition
Evaluation
Stores the reviewer’s judgment separately from the participant’s submitted content.
Result
Stores or derives the final competition outcome.
Announcements
The system included announcements as a first-class user-facing area.
Modern design should allow:
- publish date,
- expiration date,
- audience,
- priority.
Historical UI Evidence
Two historical screenshots currently provide useful evidence.
Evidence 1 — Login & Registration
The login page shows:
- login form,
- registration entry point,
- public-facing branding.
Suggested caption:
Historical login and public-registration interface for the reading competition platform.
Evidence 2 — Participant Dashboard
The dashboard shows:
- My Books,
- Competition Results,
- Announcements,
- Help,
- Latest Books,
- profile and password options.
Suggested caption:
Participant dashboard combining personal reading records, competition results, announcements, and recently published books.
User Experience Characteristics
The application used a simple dashboard-oriented interface.
This made sense because the target audience was public users with varying levels of technical experience.
The UX priority was:
Simple Registration
↓
Clear Navigation
↓
Easy Submission
↓
Easy Result Access
Public-Facing Design Considerations
Unlike internal enterprise applications, public systems must assume:
- no training,
- different devices,
- different user skill levels,
- higher risk of incomplete forms.
Therefore the modern version should prioritize:
- clear instructions,
- simple forms,
- progressive validation,
- responsive design,
- accessibility.
Persian / RTL Interface
The historical application was Persian and therefore required right-to-left layout.
A modern implementation should treat RTL as a first-class requirement.
Example:
fa → RTL
If expanded later:
en → LTR
de → LTR
Accessibility
A modern cultural/public platform should consider:
- keyboard navigation,
- sufficient contrast,
- semantic labels,
- readable typography,
- mobile accessibility.
This is particularly relevant for public library users.
Security Considerations
Public registration changes the threat model.
A modern version should include:
- rate limiting,
- secure password hashing,
- CSRF protection,
- input validation,
- XSS protection,
- secure session handling,
- reviewer/admin authorization,
- file-upload restrictions if attachments exist.
Abuse Prevention
A public platform should also protect against:
- automated account creation,
- spam submissions,
- duplicate competition entries,
- brute-force login attempts.
Possible mechanisms:
- rate limiting,
- CAPTCHA where appropriate,
- email/mobile verification,
- duplicate-entry constraints.
Competition Integrity
The system should protect the evaluation process.
A participant should not be able to:
- modify a finalized submission,
- see reviewer-only notes,
- assign themselves as reviewer,
- access another user’s private submission.
Privacy
The platform handles participant information.
A modern implementation should minimize collection and clearly define:
- identity data,
- contact data,
- reading history,
- competition submissions,
- retention.
Audit Trail
For competition integrity, key administrative and jury actions should be logged.
Examples:
CompetitionCreated
CompetitionPublished
SubmissionSubmitted
ReviewerAssigned
EvaluationSaved
ResultPublished
V2 — Modern Reconstruction
A modern rebuild should preserve the original product concept but improve its architecture significantly.
Recommended title remains:
Online Reading Competition & Book Review Platform
Recommended V2 Stack
A robust modern implementation could use:
- Laravel
- PostgreSQL
- Redis
- queues
- object storage
- responsive web frontend
- PWA or mobile wrapper if needed
- Docker
- CI/CD
- automated tests
Modular Architecture
Recommended modules:
Identity
Books
Reading Records
Competitions
Questions
Submissions
Jury
Evaluation
Results
Announcements
Notifications
Administration
Competition State Machine
A modern version should enforce valid transitions.
Draft
↓
Published
↓
Open
↓
Closed
↓
Evaluation
↓
Finalized
↓
Results Published
Invalid transitions should be rejected.
Submission State Machine
Draft
↓
Submitted
↓
Under Review
↓
Reviewed
↓
Finalized
This protects historical integrity.
Jury Assignment Rules
A reviewer should only see:
- competitions assigned to them,
- submissions inside those competitions.
This should be enforced at policy/query level, not only hidden in the UI.
Result Publication
Separate evaluation from publication.
Evaluation Complete
↓
Administrative Verification
↓
Result Publication
This gives management a controlled release process.
Notifications
Useful notification events include:
- new competition,
- competition deadline,
- submission received,
- evaluation completed,
- results published.
Delivery channels could include:
- in-app,
- email,
- SMS.
Mobile Strategy V2
The original WebView approach was efficient for its time and use case.
For a modern version, options include:
Responsive Web / PWA
Best if the application is primarily:
- forms,
- reading content,
- dashboards.
WebView Wrapper
Still valid if an app-store package is required quickly.
Native / Cross-Platform App
Only justified if future features require:
- offline mode,
- push notifications with deeper integration,
- device APIs,
- richer mobile UX.
Search & Discovery
A modern reader portal can add:
- book search,
- author search,
- competition filtering,
- reading history filtering.
These are V2 enhancements, not historical claims unless separately evidenced.
Reporting
Administrators could benefit from reports such as:
- number of participants,
- number of submissions,
- active competitions,
- evaluation progress,
- result distribution.
Again, these should be described as V2 extensions unless historical evidence exists.
Performance
For public competitions, traffic may peak near deadlines.
V2 should support:
- caching,
- queue-based notifications,
- indexed queries,
- paginated submissions,
- scalable session storage.
Backup & Recovery
Competition submissions are important user-generated content.
Recommended:
- database backups,
- tested restore procedures,
- retention policy,
- attachment backup if files exist.
Automated Testing
Authentication Tests
- registration,
- login,
- role access.
Competition Tests
- participate only while open,
- reject submission after deadline,
- prevent duplicate invalid submission.
Jury Tests
- reviewer sees only assigned competitions,
- participant cannot access evaluation area.
Result Tests
- unpublished result remains private,
- published result is visible to participant.
Authorization Tests
Critical examples:
Public user cannot create competition
Public user cannot review submissions
Reviewer cannot manage unrelated competition
Admin can assign jury
Data Integrity
Important constraints:
Unique user participation per competition
Valid jury assignment
Submission belongs to valid competition
Evaluation belongs to reviewer assignment
Exact uniqueness rules depend on competition policy.
Observability
A production V2 should monitor:
- registration failures,
- submission errors,
- queue failures,
- deadline load,
- evaluation backlog.
Historical-to-Modern Migration Strategy
Do not port old code line by line.
Recommended:
Historical Feature
↓
Extract Business Rule
↓
Define Domain Model
↓
Implement Clean Architecture
↓
Migrate Data if Required
What Should Be Preserved
Preserve:
- public registration concept,
- personal reading records,
- recurring competitions,
- written submissions,
- jury role,
- admin role,
- competition results,
- announcements.
Do not preserve automatically:
- historical UI layout,
- old coupling,
- WebView requirement,
- historical database schema.
My Role
My role covered the design and implementation of the application, including:
- public registration,
- user portal,
- reading records,
- competition workflow,
- written submissions,
- competition questions,
- role-based access,
- jury/reviewer workflow,
- administrative competition management,
- results access,
- announcements,
- mobile WebView delivery.
Engineering Highlights
- Built a public-facing reading competition platform.
- Implemented public account registration.
- Separated public, jury, and administrator roles.
- Created persistent personal reading/book records.
- Supported written book-summary submissions.
- Combined free-text submissions with competition questions.
- Designed reusable competition workflows for different occasions.
- Added jury-based submission review.
- Added participant result access.
- Added announcements and help sections.
- Delivered mobile access using a WebView application.
- Designed the system for repeated competitions rather than a one-time event.
Career Evidence
This project demonstrates:
- Public Web Application Development
- Role-Based Access Control
- Competition Workflow
- Content Submission Systems
- Jury / Review Workflow
- User Dashboards
- Public Registration
- Persian RTL UI
- Mobile WebView Delivery
- Cultural / Educational Software
CV Relevance
Tier B/A — Public Workflow Platform
This project is valuable because it differs significantly from the enterprise/industrial systems.
It demonstrates the ability to design software for:
- public users,
- untrained users,
- recurring events,
- written content,
- evaluation,
- role separation.
It adds useful diversity to a technical portfolio.
Interview Story
Situation
A library and cultural organization needed a digital way to organize recurring reading competitions and collect participant responses online.
Task
The platform needed to support public registration, book-related submissions, competition questions, jury review, result management, and mobile access.
Action
I developed a role-based web application with three access levels: public participant, jury/reviewer, and administrator.
Participants could maintain their book records, submit summaries and competition answers, while assigned reviewers evaluated submissions and administrators created and managed competitions.
A WebView-based mobile application was also provided to make the same platform accessible through mobile devices.
Result
The system replaced a simple one-time competition form with a reusable digital competition platform supporting multiple reading events and a complete submission-to-evaluation workflow.
Suggested Website Full Description
Overview
Online Reading Competition & Book Review Platform was developed for the Libraries, Museums and Documents Center of Astan Quds Razavi.
The platform supported recurring book-reading competitions while also giving users a personal space to record books they had read.
Public Participation
Users could register using their mobile number, view available competitions, record books, submit written summaries, answer competition questions, and access results.
Jury Workflow
Selected reviewers could evaluate participant submissions for competitions to which they had been assigned.
This separated evaluation responsibilities from ordinary administration.
Administration
Administrators could create competitions, manage books and users, assign reviewers, publish announcements, supervise evaluation, and manage results.
Mobile Access
The system was also delivered as a mobile WebView application, allowing the web platform to be used from mobile devices without maintaining a separate native application codebase.
Short Website Card Copy
Online Reading Competition & Book Review Platform
A public platform for reading competitions, personal book records, written submissions, jury evaluation, results, and mobile WebView access.
Alternative One-Liners
Product-oriented
Developed a reusable public platform for recurring reading competitions, combining participant registration, book-summary submissions, jury review, and result publication.
Workflow-oriented
Built a complete reading-competition workflow from public registration and written submission through reviewer evaluation and results.
Architecture-oriented
Designed a three-role cultural platform separating participant, jury, and administrator workflows around books, competitions, submissions, and results.
Mobile-oriented
Delivered a public reading-competition web platform together with a lightweight mobile WebView application.
Suggested Website Slug
/projects/online-reading-competition-platform
Alternative:
/projects/ketabi-ke-khandeam
Relationship to Other Portfolio Projects
This project should remain independent.
It is not part of the industrial-management platform family.
Its value is precisely that it demonstrates a different problem space:
Enterprise / Industrial
vs.
Public / Cultural / Competition
Do not merge it with the administrative or industrial automation posts.
Evidence Gallery Recommendation
Image 1 — Public Login / Registration
Use as evidence of:
- public access,
- account registration,
- Persian RTL interface.
Caption:
Historical login and registration interface for public participants.
Image 2 — Participant Dashboard
Use as evidence of:
- My Books,
- competition results,
- announcements,
- help,
- latest books.
Caption:
Historical participant dashboard combining personal reading activity and competition information.
If later screenshots of jury or administration are found, add them as separate evidence sections rather than replacing these.
Cover Direction
Title
Online Reading Competition & Book Review Platform
Subtitle
Public Participation · Book Reviews · Jury Evaluation
Supporting Line
Readers · Competitions · Submissions · Reviewers · Results
Visual Direction
A premium square cover showing:
- open book,
- reader profile,
- book cards,
- competition trophy or medal,
- written submission/document,
- jury/reviewer panel,
- result/checkmark,
- mobile phone with WebView interface.
The visual should communicate:
READ
→ SUBMIT
→ REVIEW
→ RESULT
The design should feel cultural and digital, not corporate-industrial.
Recommended visual tone:
- clean,
- modern,
- literary,
- technology-enabled,
- accessible.
Avoid making the cover look like an e-commerce bookstore.
Historical vs V2 Boundary
Historical Implementation
Confirmed from the project description and screenshots:
- public login/registration,
- mobile-number-based membership concept,
- participant dashboard,
- My Books,
- competition results,
- announcements,
- help,
- latest books,
- public written book summaries,
- competition questions,
- jury/reviewer role,
- administrator role,
- recurring competitions,
- mobile WebView application.
V2 Recommendations
Proposed modernization:
- OTP,
- explicit state machines,
- granular RBAC,
- audit events,
- PWA,
- richer notification channels,
- flexible question engine,
- multi-reviewer evaluation,
- stronger accessibility.
These should be presented as modernization ideas, not historical claims.
Final Portfolio Statement
The project transformed a traditional reading competition into a reusable digital participation platform.
Its architecture connected:
READERS
+
BOOKS
+
COMPETITIONS
+
WRITTEN SUBMISSIONS
+
QUESTIONS
+
JURY
+
RESULTS
through a role-based web application.
The combination of public registration, personal reading records, recurring competitions, jury evaluation, and mobile WebView delivery made the system substantially more than a simple online questionnaire.
It was a reusable digital workflow for reading, participation, evaluation, and results.