Redesign and refine ScheduleMaker as a real, production-quality university scheduling utility.
This is not a cosmetic reskin. Inspect the existing repository first. Preserve working functionality and improve the product end-to-end: correctness, solver behavior, parser reliability, UX, accessibility, performance, and visual design.
A Pinterest/reference image may be provided separately. Use it as visual inspiration only. Extract its principles (depth, lighting, materials, composition, geometry, atmosphere) and create an original ScheduleMaker design. Do not copy its exact composition, artwork, branding, or layout.
Import your university timetable → choose your courses → get the best valid timetable.
Optimize for:
Speed → simplicity → clarity → control
A new student should reach a useful timetable in roughly four meaningful interactions. Advanced preferences must not block the first result.
Before coding:
- Inspect the entire repository.
- Inspect recent commits and open PRs.
- Understand the parser, normalized data model, solver, Web Worker, ranking, constraints, state, calendar, table, filters, exports, storage, i18n, and tests.
- Identify what is already good.
- Identify real bugs and friction.
- Make a prioritized plan.
- Do not rewrite working systems merely for style.
The existing code is the source of truth for implementation details. This document is the product/design/engineering direction.
Preserve:
- 100% client-side/private operation
- no backend required
- no telemetry or unnecessary tracking
- Web Worker scheduling
- Arabic/English parity and RTL/LTR correctness
- PNG timetable export
- ICS calendar export
- local persistence
- demo mode
- existing parser capabilities
- existing solver capabilities
Do not add accounts, university passwords, chatbot features, unnecessary backend services, social features, gamification, or fake AI functionality.
Do not claim "Best Schedule" if the implementation only takes the first N valid schedules and ranks those afterward.
The search must preserve the best candidates across the valid search space, using an appropriate bounded top-K strategy and stronger pruning where useful.
The final result should be defensible as the best according to the active preferences.
Hard constraints determine validity:
- selected courses
- no time conflicts
- locked sections
- excluded sections
Preferences determine ranking:
- fewer university days
- fewer gaps
- preferred start time
- preferred finish time
- available seats
- preferred instructor
- preferred time range
Never silently turn a preference into a hard constraint.
A locked section must be included.
An excluded section must never be used.
An impossible/invalid lock must produce a clear no-solution state. Never silently ignore a lock.
Prefer:
semantic/header detection
↓
normalized columns
↓
validation
↓
positional fallback only when necessary
Do not silently produce incorrect schedules when a portal layout changes.
Add representative Taibah HTML fixtures and regression tests for parser behavior.
Never stop at:
No schedules found.
Explain likely conflicts when possible and give useful actions.
Example:
No valid timetable exists with these courses.
CS301 conflicts with MATH202 in every available combination.
[Inspect conflict] [Change courses]
Prefer identifying a small conflicting set rather than dumping every failed combination.
After import, automatically discover courses.
Preferred flow:
23 courses found
Search courses...
CS301
Operating Systems
5 sections
NET302
Computer Networks
4 sections
SEC401
Security
3 sections
Manual course-code/number entry may remain as an advanced fallback.
The normal student should not need to understand internal identifiers.
Validate courses with zero usable sections before solving and explain the problem.
Use progressive disclosure.
Defaults should be sensible.
Advanced preferences can include:
- prefer fewer days
- minimize gaps
- avoid early classes
- avoid late classes
- prefer available seats
- preferred instructor
- preferred time range
Preferences should affect ranking, not validity, unless the user explicitly chooses a hard constraint.
The first result must be the strongest valid candidate.
Make the reason obvious:
BEST MATCH
3 university days
1h 30m total gaps
Starts 9:00 AM
Finishes 2:00 PM
No conflicts
All sections available
Do not use mysterious AI-style scoring.
Alternatives must be easy to scan without clicking through hundreds of results one-by-one.
Example:
#1 3 days · 1h gaps · 9:00 start
#2 3 days · 1h 30m gaps · 8:00 start
#3 4 days · 30m gaps · 9:00 start
Preserve canonical overall ranking when filters are applied. If useful, expose both overall rank and filtered rank.
Deduplicate schedules using a canonical section identity.
Useful metrics include:
- days off
- active days
- total gaps
- longest individual gap
- earliest start
- latest finish
- total on-campus span
- total class time
- instructor count
- available seats
- full-section presence
Prefer metrics that help a student make an actual decision.
Treat seat availability as useful ranking information, not automatically as a hard exclusion.
Clearly distinguish:
- available
- almost full
- full
A full section can remain as a fallback when no alternative exists, unless the user explicitly chooses to exclude full sections.
The solver must not freeze the main UI.
Use the Worker correctly.
Support cancellation when a new solve supersedes an old solve.
Prefer cancellation/abort signaling over arbitrary timeouts.
Optimize with:
- precomputed section conflicts where worthwhile
- course/section ordering by constraint tightness
- early pruning
- bounded top-K retention
- avoiding repeated time parsing
- avoiding unnecessary object cloning
Do not sacrifice correctness for a superficial benchmark.
Add solver tests for:
- exact overlap
- partial overlap
- adjacent classes
- multiple meeting slots
- multiple days
- locks
- invalid locks
- exclusions
- lock + exclusion interactions
- full sections
- no solution
- duplicate schedules
- ranking
- cancellation
- large search spaces
Verify ICS correctness including:
- timezone behavior
- multiple meetings
- Arabic text
- special characters
- correct start/end times
Verify PNG export on desktop and mobile.
Version local storage schemas so future data-model changes do not break old cached data.
Support:
- keyboard navigation
- visible focus
- semantic controls
- sufficient contrast
- screen-reader labels
- information not conveyed by color alone
- touch-friendly mobile targets
- reduced motion
- correct Arabic RTL behavior
- correct English LTR behavior
Arabic should feel native, not like mechanically mirrored English.
The product should feel like a serious, premium academic utility.
Desired qualities:
- calm
- precise
- editorial
- tactile but restrained
- information-dense without clutter
- excellent typography
- strong alignment
- clear hierarchy
- subtle depth
- useful motion only
Avoid generic AI/SaaS aesthetics.
Do not use:
- AI-purple/violet glow gradients
- excessive glassmorphism
- glowing borders everywhere
- huge rounded cards
- excessive shadows
- excessive pill buttons
- decorative badges with no meaning
- cartoon mascots
- fake dashboard mockups
- giant marketing hero sections
- meaningless animations
- fake AI terminology
- visual noise
Use course colors sparingly and keep them harmonious/desaturated enough that the timetable remains readable.
Use the existing brand direction when appropriate, but improve it if the current implementation creates usability problems.
A 3D background is allowed and may be a major visual element if the reference image supports it.
However:
The 3D environment is atmosphere around the product, not the product itself.
If using 3D:
- keep the actual scheduling UI dominant
- maintain strong text/readability contrast
- use depth and lighting intentionally
- avoid decorative objects that compete with the calendar
- avoid constant expensive animation
- respect prefers-reduced-motion
- lazy-load or progressively initialize the 3D layer
- keep geometry and draw calls reasonable
- disable/reduce 3D on low-power/mobile devices where appropriate
- do not delay the useful UI because of 3D
- the application must remain excellent with 3D disabled
If the reference image is visually dramatic, translate its visual principles rather than copying it.
Mobile is not a shrunken desktop.
The timetable must remain genuinely usable on an iPhone.
Possible mobile patterns:
- day-by-day navigation
- horizontal day tabs
- vertical schedule cards
- bottom sheets for section details
- sticky essential actions
Do not sacrifice schedule readability for decorative design.
Use motion to communicate state:
Good:
- schedule switching
- selection feedback
- import completion
- modal transitions
- subtle result transitions
Avoid:
- perpetual floating
- bouncing
- pulsing
- animated gradients
- excessive parallax
- animation for its own sake
Support prefers-reduced-motion.
Keep clear boundaries between:
parser
solver
constraints
ranking
state
UI
storage
export
Avoid turning the application controller into an unmaintainable monolith.
Do not over-engineer. Use the simplest architecture that keeps responsibilities clear.
Do not add a dependency unless it solves a real problem.
Prefer platform APIs for small functionality.
Performance is a product feature.
Audit:
- initial load
- bundle size
- JavaScript execution
- unnecessary re-renders
- Worker lifecycle
- solver runtime
- parser runtime
- localStorage usage
- export performance
- 3D rendering
- asset loading
Local filtering should not rerun the solver.
The UI should remain responsive while solving.
Do not add heavy libraries merely for visual effects.
Every important bug discovered during the redesign should receive a regression test.
At minimum, cover:
- representative Taibah HTML
- changed column ordering
- Arabic data
- multiple meeting times
- malformed/empty input
- invalid rows
- overlap
- adjacent times
- multi-slot sections
- locks
- invalid locks
- exclusions
- no solution
- duplicates
- ranking
- cancellation
- large search spaces
- ICS timezone
- Arabic text
- multiple meetings
- special characters
Run tests and production build after implementation.
Do not add:
- chatbot
- AI assistant
- AI-generated explanations where deterministic logic is sufficient
- account system
- backend
- university authentication
- social platform
- gamification
- notification infrastructure
- unnecessary analytics
- feature-heavy dashboards
ScheduleMaker should become exceptionally good at scheduling, not become a general student platform.
Follow this order:
Inspect repository, architecture, commits, PRs, tests, and current behavior.
Fix ranking, constraints, deduplication, parser reliability, and solver cancellation.
Improve course discovery, preferences, no-solution explanations, result browsing, and metrics.
Apply the new visual language and Pinterest-inspired 3D direction without compromising usability.
Measure and optimize real bottlenecks.
Run:
- all tests
- production build
- mobile verification
- Arabic/RTL verification
- dark/light verification
- reduced-motion verification
- import verification
- solver verification
- ranking verification
- export verification
- no-solution verification
- 3D-disabled verification
- console/error audit
Do not stop at mockups. Implement the actual product.
A student can:
- Open ScheduleMaker.
- Understand what to do immediately.
- Import a timetable without technical knowledge.
- See courses automatically discovered.
- Select courses quickly.
- Generate without configuring a complicated form.
- Receive a genuinely strong ranked schedule.
- Understand why it is recommended.
- Browse alternatives quickly.
- Lock or exclude sections predictably.
- Understand conflicts when no solution exists.
- Read the calendar comfortably on mobile.
- Save, share, or export the result.
- Use Arabic or English naturally.
- Experience no UI freeze during solving.
The visual design should remain excellent even if the 3D layer is removed.
If the product only looks impressive but requires too much thinking, the redesign has failed.
Do not imitate the reference image literally.
Do not produce an AI-looking template.
Do not optimize for screenshots or Dribbble-style presentation.
Design for the real student using the real scheduling workflow.
Make the product feel inevitable: the simplest, fastest, clearest way to turn a university timetable into a good schedule.