Fadel

Travelers enter one home screen and choose buses, flights, hotels, rental cars or ferries. Each service has its own fields and in-memory draft, so exploring flights does not overwrite a hotel room allocation. Selected criteria follow the traveler into results and checkout. Draft retention covers navigation within the session, not cloud storage or recovery after the process closes.

Travelers select origin, destination, date and passenger count, then compare operators, departure and arrival times, journey duration and sample fare. Dates can be changed directly in results or through search. Booking expands the cabin inside the selected result, keeping the itinerary visible while seats are chosen before checkout. Schedules, fares and availability are interactive sample data.

Airport-aware search accepts Arabic and English destination names and IATA codes. Travelers choose one-way or return travel, adults, children, infants and cabin class. The criteria remain visible in results and checkout for review. Choosing a cabin is an implemented search control; it neither reprices sample inventory nor confirms that a real airline can supply that cabin.

Up to four flight legs can be prepared, each with its own airports and date. Dates must follow a chronological sequence. Results let the traveler select a leg for independent comparison and demo checkout. This illustrates multi-stop business or family travel without claiming a combined ticket, protected connection or integrated multi-airline reservation.

Users choose a destination and check-in/out dates, then configure up to six rooms with adults and the age of every child assigned to each room. Room and guest totals carry through results and checkout, preserving the needs of families or groups. Checkout must follow check-in by at least one day. Displayed room inventory, pricing and stay conditions remain illustrative.

Drivers provide pickup and return locations, dates, times and age. They can return to the same location or select a different one; same-location mode keeps the return location aligned with pickup. These details appear in results and checkout, and return time must follow pickup. The current app does not reserve a live fleet or perform operational driver-eligibility checks.

Travelers select an available demo port route, one-way or return travel and passenger categories. An optional vehicle has a type, length and height, with positive-dimension validation and a visible request summary. This distinguishes foot passengers from travelers carrying a car. The limited sample port inventory does not establish carrier acceptance, a real timetable or vehicle pricing.

Results show the available sample count and offer recommended, cheapest and fastest sorting plus a provider filter. Fastest sorting uses elapsed duration instead of alphabetic duration text. An explicit empty state appears when a destination has no demo inventory. Previous/next-day controls and search editing let users refine a comparison before entering passenger details.

An offer card exposes provider, itinerary, price, amenities and sample conditions during comparison. Provider names, times and feature text are localized. Icons clarify USB charging, Wi-Fi, water, baggage, air conditioning and seating when present in the offer data. This makes the selection understandable without presenting fixture amenities or policies as verified supplier commitments.

The bus cabin displays driver, doors and available, occupied and selected seats with distinct recorded states. Travelers can scroll horizontally, select the required quantity and confirm. Physical positions remain stable between Arabic and English. TV and refrigerator fixtures appear when supplied by the example layout; neither company-specific fleet layouts nor live availability are verified.

Checkout combines offer summary, seats, itinerary, traveler fields, contact details, payment choice and terms acceptance. Traveler forms and sample price quantities depend on service type, including room quantities for hotels. An expandable summary and return-to-booking action keep choices reviewable. Progress indicators connect comparison, seats and checkout, while one clear final action completes the demonstration.

Checkout validates names, phone, optional email, seat selection, payment choice, terms and search criteria. Failed submission scrolls to the relevant section, focuses the field and announces the error for assistive technology. Local busy state prevents repeated confirmation. These are input and interaction safeguards, not server-side identity verification or payment processing.

Checkout presents Syriatel Cash, MTN Cash, Sham Cash and Syrian bank options with recognizable identities. Users select one method and continue to demo success. No transfer or provider call occurs and no payment partnership is asserted. The account payment-method screen contains a sample card presentation rather than a wallet or a production card vault.

Completing the form leads to a success state and access to trips. The ticket presents provider, route, times, date, passenger or room count, seats, amenities, total and reference. A QR encodes structured sample booking information to demonstrate presentation at travel time. The example reference and QR are not a valid carrier reservation or boarding authorization.

Upcoming and past tabs separate the trip experience. Upcoming travel uses a compact card that opens the full ticket; the past tab supplies an empty state and a route back to search. Trip details retain the main navigation and a reliable return path. This currently illustrates a sample booking rather than a cloud history or operational cancellation/refund service.

The account supports a guest view and demo session with phone or email sign-in/registration. Syrian numbers are normalized across Arabic digits and local/international forms. Password length and registration confirmation are checked. Credentials are neither transmitted nor persisted; the flow demonstrates account usability ahead of a real authentication integration.

The phone flow models a verification code, resend countdown, expiry, attempt limits, errors and a completion state that opens a demo session. Users can return to input, exit the flow and sign out. These interaction states help review a future account experience, but no SMS is sent and phone ownership is not verified.

The account brings together travelers, payment methods, notifications, language, help and settings. The traveler screen shows a sample profile and an add-name form with basic validation, illustrating faster family bookings. The current form does not create a persistent traveler directory, and its edit affordance is not a complete profile-management implementation.

Campaign cards present selectable codes that users can copy or share through the device share interface. A fallback message handles unavailable sharing. The flow demonstrates saving and sharing an offer, while explicitly identifying the campaigns as illustrative. No active coupon engine or financial booking discount is implemented.

The notification center illustrates a promotion, trip reminder and booking confirmation, each with its own icon, time and message. Settings expose session-local switches for price alerts and marketing, plus language and introduction replay. These are modeled UI states rather than a functioning push-delivery service or scheduled reminder engine.

Travelers can filter frequently asked questions, expand answers or open the chat preview. Chat supplies a greeting and accepts locally rendered messages so the conversation and keyboard layout can be reviewed. Phone and email actions disclose that support is not connected. Messages do not reach an agent, and the sample availability copy does not establish a real service-level commitment.

Three illustrated screens introduce comparison, seat choice and the five services with previous, next, skip and start actions. Completion is stored locally to avoid repeating the introduction, and settings can replay it. Storage failure does not block entry. Arabic and English copy and descriptive image labels support the same onboarding journey.

A crimson opening uses ticket perforations, staggered Fadel letter pivots and the apricot circle before resolving to the original wordmark. Local Reanimated/SVG motion replays after more than five continuous background minutes while keeping the route and forms mounted. Reduced motion uses a static alternative, and asset waiting is bounded. Compilation is not a substitute for final physical-device performance testing.

Arabic RTL and English LTR include saved language choice, Tajawal typography and system-based light/dark appearance. Destination search uses service-appropriate names/codes; the calendar handles month lengths, leap dates and past-date rejection. Checkout adapts to small widths and enlarged text, with screen-reader labels, safe areas and Android back behavior while preserving the physical cabin orientation.

The work extends beyond app screens into a public guide covering the selected wordmark, crimson/apricot/graphite/ivory palette, typography, voice, spacing and states. Correspondence, print, apparel, environmental and digital applications form one coherent package. Representative scenes demonstrate the identity; they are not evidence of an operating fleet or branches.

The package includes Arabic/English correspondence, email and Word templates, visual assets, app-icon exports and designed screen/notification/loading/empty/error/offline states. Hugeicons coverage distinguishes runtime symbols from additional design assets, alongside reusable color and measurement references. Store mockups and designed screens are explicitly distinct from runtime screenshots and implemented software behavior.

A 48-page strategic and operating study defines a Syrian ecosystem comprising the traveler app, ticket office, QR validation, hotel reception, room management and an independent local guide. It identifies each audience, workflow, dependencies and data boundaries. The study and design are delivered artifacts; the five operational applications are not a released software suite in the current version.

The proposed desktop/tablet workflow serves ticket sellers: choose a departure, inspect seats, capture essential traveler information, price, issue and deliver a paper ticket or link. It covers staff accounts, branches, cash desks, permissions, discount/cancellation approval and shift reconciliation. The study also specifies duplicate-seat prevention and limits on selling without live inventory; these operations are not implemented in the current prototype.

The study specifies a boarding tool for transport staff: scan, read an unambiguous booking state and perform only the authorized action. Validity, cancellation, repeat use and auditability are considered without embedding the full traveler profile in the QR. Offline verification limits and freshness are addressed. This is proposed passenger-booking validation, not cargo tracking or an already connected scanner in the current app.

The proposed reception workflow locates a booking, matches authorized guest/booking data and arrival status, then handles arrival or exceptions according to role. It can connect to an authorized hotel system or controlled reservation source with clear provenance. Its intended value is faster, less ambiguous reception; connected hotel front-desk operations are not part of the current mobile prototype.

The study describes room calendars, availability, rates and selling restrictions with approval and review permissions. It calls for a single inventory source, night-level reservations and stale-data disclosure to reduce overselling. The unit could operate independently and connect distribution channels under later agreements. This is a proposed operating design, not an implemented channel manager.

The project proposes discovery of hotels, restaurants and destinations after arrival, supported by place records, verified information, updates and editorial ownership. It can run without booking or mandatory accounts or connect to a journey when useful. The study separates editorial content from traveler identity data and specifies content governance rather than merely listing static places.

The study separates contracts, pricing, releases, support and data by product so units can be purchased independently or connected gradually. It covers partner onboarding, organization permissions, sensitive-action separation, support escalation, data minimization, retention and recovery. Government identity integration and national hosting remain conditional on legal authority, agreements and acceptance testing; no established official partnership or access is claimed.

The study covers distribution through offices, stations, hotels and arrival points, geographic priorities and phased launches with decision gates. It distinguishes booking value from platform revenue, contribution margin and operating costs. Traveler, carrier and hotel interview questions and operating-quality measures support evidence-based decisions. Proposed targets and assumptions are not presented as achieved revenue, users or commercial results.