This is a single-file HTML app designed to fetch a remote JSON file (structured in the MediaWiki API format) and render its contents as a clean, magazine-style Wikipedia article viewer. The app has a dark-themed UI with blue accents and a neon-tinged aesthetic.
The interface is split into three areas. At the top is a hero section labeled “SINGLE-FILE HTML APP” with a URL input field pre-populated with a placeholder URL (https://producingtechnology.com/a1/15-json/yourname.json), a primary “Load JSON” button, and a secondary “Use Demo JSON” button. Below that, the main content area is divided into a Remote JSON Viewer panel on the left (which renders the article) and an Article Snapshot sidebar on the right with metadata fields: Title, Sections, Paragraphs, Images, and Source JSON URL.
The app explains that it expects a JSON structure with parse.title and parse.text["*"] fields—the standard response format from the MediaWiki API’s parse endpoint. It then transforms the raw HTML content from that field into a restyled reading experience.
On initial load, the app attempts to fetch the placeholder URL, which returns a 404 error with a red banner: “Request failed with status 404. Replace ‘yourname.json’ with your actual file name if needed.”
Clicking “Use Demo JSON” loads a built-in article about Nigiri (sushi). This works well: the article renders with a bold title, subtitle line (“2 section headings · 4 paragraphs · 0 images”), two styled section badges (“OVERVIEW” and “PRESENTATION”), body paragraphs, and a formatted data table (Element/Description for Rice and Topping). The Article Snapshot sidebar correctly populates with Title: Nigiri, Sections: 2, Paragraphs: 4, Images: 0, and Source JSON URL: “Built-in demo JSON.”
Things That Didn’t Work as Expected
User JSON files are rejected: When loading a valid JSON file hosted on producingtechnology.com (i.e., an actual student-uploaded JSON from the course), the app rejects it with the error: “This JSON does not match the expected Wikipedia-style structure.” This means the app’s core intended use case—loading remote JSON files from the class—does not work. The parser is hardcoded to expect the specific MediaWiki parse.title / parse.text["*"] schema, and course-uploaded JSON files apparently use a different structure.
Broken on first load: The app auto-fetches the placeholder URL on page load, which immediately 404s. The first thing a user sees is an error. It should either auto-load the demo JSON or simply wait for user input without pre-fetching a URL guaranteed to fail.
Demo is hidden behind the error: The “Use Demo JSON” button works perfectly and shows a polished result, but it is visually secondary (outlined style) and only discoverable after the user encounters and reads past the 404 error. The working demo should be the default experience.
No schema flexibility: The app only handles one rigid JSON format. It does not attempt to detect or adapt to other common JSON article structures (e.g., { title, body, sections } or { heading, content }). A more robust parser could try multiple schemas or let the user map JSON fields to article components.
No images in the demo: The Article Snapshot shows “Images: 0” for the Nigiri demo. A Wikipedia-style reader would benefit from at least one image to demonstrate that the image-rendering pipeline works. Without it, there’s no proof the app can handle images at all.
Error messages are generic: Both failure modes (“404” and “does not match expected structure”) give the same advice: replace “yourname.json.” The schema-mismatch error should instead show what fields the app expected versus what it received, so the user can understand and fix the issue.
Prompt to Improve the App
Below is a prompt to generate an improved version that addresses the issues above:
You are improving a single-file HTML app called "Remote JSON Wikipedia
Mock" that fetches a remote JSON file and renders it as a styled
Wikipedia-style article viewer. Keep the dark theme with blue accents.
The app already has a URL input, Load/Demo buttons, an article viewer,
and an Article Snapshot metadata sidebar. The demo JSON (a Nigiri
article) works well.
Fix and add the following:
1. DEFAULT TO DEMO: On page load, auto-load the built-in demo JSON so
users see a working article immediately. Do NOT auto-fetch the
placeholder URL. Show a subtle banner: "Viewing demo article. Paste
a URL above to load your own JSON." The URL input should start
empty with a placeholder hint, not a fake URL.
2. FLEXIBLE JSON PARSING: Instead of only accepting MediaWiki's
parse.title / parse.text["*"] schema, support multiple common
structures:
- MediaWiki: parse.title + parse.text["*"]
- Simple: { title, body } or { title, content }
- Sectioned: { title, sections: [{ heading, body }] }
- Array: [{ title, text }]
Try each schema in order and use the first that matches. If none
match, show a detailed error: "Expected one of these JSON formats:"
followed by a mini example of each schema, plus a raw JSON preview
of what was actually received (first 500 chars, syntax-highlighted).
3. FIELD MAPPER FALLBACK: If auto-detection fails, show a simple UI
where the user can manually map JSON keys to article fields:
"Which field is the title?" (dropdown of top-level keys), "Which
field contains the body/content?" This makes the app usable with
ANY JSON structure.
4. BETTER ERROR UX: Differentiate between network errors (404, CORS,
timeout) and schema errors (JSON loaded but wrong format). For
network errors, show the HTTP status and a retry button. For
schema errors, show the raw JSON preview and the field mapper.
5. DEMO WITH IMAGES: Update the built-in demo JSON to include at
least one image URL so the article viewer demonstrates its full
rendering capability, including image layout and the Images count
in the Article Snapshot sidebar.
6. ARTICLE SEARCH: Add a search input above the URL field where users
can type a Wikipedia article title (e.g., "Nigiri"). The app
constructs the MediaWiki API URL automatically and fetches it.
This makes the app useful as a standalone Wikipedia reader without
requiring users to construct API URLs manually.
Keep everything in a single HTML file.