Web engineering & Arabic UX
Building an Arabic directory around local tasks
A local directory brings together information people describe in different ways: a business name, a village, a service or a landmark. In Naqada Directory, I organize that knowledge into routes people can search and revisit while keeping provenance and review state part of the experience.
Start with the task before the taxonomy
One visitor needs a nearby tradesperson; another wants to learn about a village or read a community story. The interface therefore needs distinct entry points. Each record needs a defined type and an understandable relationship to its category and location. A long undifferentiated list with a search box does not resolve that structure.
I review a short sequence: identify the task, narrow its scope, inspect the record, then choose an available action. Section names should help the visitor make those choices without requiring knowledge of the underlying data model.
Publication eligibility comes before presentation
The repository documentation separates ready records from review states and excludes manual_review, official_review, research_only and grade C from publication. This prevents an unresolved item from acquiring the appearance of a confirmed fact merely because it has a polished card and a shareable URL.
Historical material does not infer lineage from similar names. Business records do not present the directory as government accreditation or a service guarantee. The source type and its limits determine what the page can responsibly say.
Normalize search while preserving displayed names
Arabic search needs to accommodate common spelling variations without rewriting the published name. I separate matching text from display labels and connect results to explicit categories and locations. An empty search state should offer a clear next step instead of a blank screen.
Mixed-direction content also needs attention. Arabic names read right to left, while phone numbers and URLs need suitable isolation. Icon order, touch targets and filter placement are considered in relation to the task being completed on a phone.
Give important content its own address
The project uses Next.js with independent business, category and location routes, metadata, internal links, Sitemap and Robots outputs. That makes it possible to share a particular record and its context instead of forcing every visitor to restart the search.
A generated page or sitemap entry does not establish indexing. A published record, a crawlable page and a page actually present in a search index are different states. The final state needs indexing evidence; build output counts cannot substitute for it.
Design for correction after launch
Phone numbers, names and service descriptions change. I treat the directory as a reviewable record, attaching a source and date where available. A testable publication rule and stable identifiers are more useful than expanding the collection without a way to manage change.
This note describes technical and content decisions documented in the project. It makes no claim about audience size or traffic growth without a separate measurement record.