You want to show how an interface should behave before anyone builds the full product. OGAD (Off Grid AI Desktop) can turn that idea into an interactive HTML prototype on your Mac. Describe one screen and its actions, open the preview beside the conversation, then revise it with a local model.
| Download OGAD for Mac or Windows | Desktop releases |
What would you like to do with Off Grid AI?
Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.
Write to support@offgridmobileai.co, join our Slack community, or talk to us on Reddit.
Use it for a booking form, filterable list, or a small settings screen. A clickable prototype helps you discuss what should happen when someone uses the controls instead of describing everything in words.
What makes a useful first prototype?
Choose one screen and one user task. Define the starting state, the main action, and the result. Use sample data so the prototype does not need a live service.
For example:
Build a workshop booking prototype as one self-contained HTML file. Show four sample workshops, let me select one and enter a name, then show a confirmation panel. Clearly label it as a demo: do not send a booking anywhere. Include empty-field validation and a Back button. Use inline CSS and JavaScript, no external libraries or network calls. Return one fenced html code block.
This creates something you can discuss and test without implying that a real booking system exists.
What do you need on the Mac?
Use an Apple Silicon Mac with macOS 13 or later, OGAD, and a downloaded local model suited to code. HTML artifacts are a free core feature. Complete the model setup before disconnecting.
A generated prototype is a starting point. The model can make mistakes in code or behavior, so check the user journey before showing it as a working example.
Getting started
- Open Models > Text and select the downloaded local model.
- Create a project through Projects > New project if you want the prototype grouped with related conversations.
- Start Chats > New chat in the project and send the request.
- Open the artifact card, or select Open canvas from the assistant reply menu.
- Use Preview to click through the flow and Code to inspect the source.
The expected result is a page that responds to your input in the canvas. The released canvas implementation supports local HTML previews and downloads.
How do you review the prototype without leaving the chat?
Try the main action, an incomplete form, and the Back button. Check that sample data is labeled and that no control claims to submit to a real service.
Give focused feedback in the same conversation:
Keep the current layout. When I return from confirmation, preserve the entered name and selected workshop. Return the full updated HTML.
After each change, repeat the earlier checks. A new layout or state change can break a control that worked before.
Use the prototype to answer one design question
For the workshop example, the question might be: can someone choose a workshop and understand the confirmation without help? That is specific enough to learn from a short review.
Give a colleague the downloaded demo and ask them to choose a workshop. Watch where they hesitate before explaining the interface. Do they recognize the selected item? Do they understand why a blank name was rejected? Can they return and change the selection?
These observations are more useful than asking whether the screen looks good. You are testing the flow that the prototype makes visible, not collecting a score for its colors.
Keep notes in terms of behavior:
| Observation | Focused revision to request |
|---|---|
| The selected workshop is unclear | Add an obvious selected state and repeat its title in confirmation |
| A blank field appears to do nothing | Show a nearby error that names the missing value |
| Back loses the entered details | Preserve the current form values when returning |
| The demo looks like a real booking | Make the sample-only label visible on both screens |
Record the issues you observe.
Keep the demo honest about what it does
A confirmation panel in a local prototype means its code changed state. It does not mean a seat was reserved or an email was sent. Make that distinction visible to the person reviewing it so they can judge the interaction without mistaking it for a live service.
Use made-up names and sample workshops for the review. If the idea eventually needs real availability, accounts, or payments, capture that as later implementation work. The prototype can settle the sequence and wording first.
When you request a revision, include the observed problem and the expected behavior. One focused change followed by another review is easier to interpret than replacing the whole screen after each comment.
How do you continue later?
Return to the project and open Artifacts to find saved outputs, or reopen the original conversation and its artifact. Ask for the next change in the conversation that contains the relevant code and instructions.
If the model no longer has the version you want in context, paste that version’s code with your change request. Reopening a saved preview does not automatically make every line of it part of a new chat’s prompt.
How do you share a reviewable copy?
Use Download to save the HTML file. Open it outside OGAD and test the same flow. Keep the code self-contained if the reviewer needs to open it offline.
The export is a prototype file, not a deployed website or backend. Review the code before using it as a base for production work. Accounts, payments, and server data require separate implementation.
Get OGAD for Mac, describe one screen, and test its main journey. Download the working prototype so someone else can try it.