Support for interactive CAD drawing projects
DWG Hotspots is a demonstration of a larger idea: a drawing becomes more useful when people can select a visible area and reach the information connected to it. Support for this kind of project begins with understanding the drawing, the users, and the result that must be delivered. This page gives a practical route from an initial question to a stable browser experience.
Use the guidance below when you are preparing a plot plan, floor plan, equipment layout, campus map, or another drawing for the web. It is written for project owners, CAD technicians, developers, and content teams who need a shared vocabulary before implementation begins.
1. Describe the user task
Start with one clear task. A visitor may need to find a room, identify an asset, check a parcel, follow a route, open a maintenance record, or understand a drawing without CAD software. Write the task in one sentence and identify what should happen after a region is selected. The answer affects the image scale, labels, hotspot size, panel design, and data that must be available.
A useful task description also names the audience. A facilities technician may prefer exact asset identifiers and links to work orders. A tenant may need a room name, availability, and contact action. A public visitor may need a simple map legend and accessible text. Designing for a specific audience makes the first version easier to test and prevents unnecessary controls from hiding the important information.
2. Prepare the source drawing
Before conversion, remove information that does not help the task and preserve information that identifies an object. Check units, extents, rotation, line visibility, layer names, block attributes, text styles, and external references. A drawing that looks correct in desktop CAD can still produce a confusing web image if important layers are frozen, line weights are too light, or the visible area includes a large empty border.
Keep an untouched source copy and create a documented preparation copy. Record the drawing date, coordinate assumptions, file format, visible layers, and any cleanup commands. This record helps a second person repeat the conversion and gives developers a reliable explanation when an object is missing from the result.
3. Define hotspot rules
Hotspots work best when their rules are predictable. Decide whether an area is identified by a layer, a block, a text value, a closed polyline, or a combination. Choose a stable identifier and decide what happens when the identifier is empty or duplicated. A small rule table can list source object, identifier, display name, action, and owner.
Do not make every visible mark interactive. Too many targets create visual noise and make selection difficult on a phone. Group related objects when the user needs a category view, and keep a detailed view available when a technician needs precise selection. Use a clear hover, focus, or selected state so users know that an area can be activated.
4. Choose the output
A bitmap is often a practical choice for a fixed drawing image, a lightweight demo, or a page where hotspot regions are managed separately. Vector output is useful when users need sharp zooming, selectable geometry, layer control, or a drawing that must remain legible at different scales. The correct choice depends on file complexity, device performance, accessibility needs, and how much interaction the application must provide.
Consider responsive behaviour before choosing dimensions. A very large bitmap can look excellent on a desktop but load slowly on a phone. A small bitmap may be fast but become unreadable when zoomed. Test a realistic representative drawing rather than a simple sample, and measure load time, memory use, and selection accuracy on the devices your audience uses.
5. Connect content responsibly
The image is only one part of an interactive drawing. A hotspot may connect to a room record, equipment document, inspection history, tenant profile, or route instruction. Keep descriptive content in a maintainable data source where possible instead of embedding long text into generated markup. Use identifiers that remain stable when the drawing receives minor geometry edits.
Show the user enough context to make a decision. A title, identifier, short description, status, and next action are often more useful than a large panel filled with fields. When content is unavailable, show a helpful empty state. Do not expose confidential records simply because a shape is visible on a public drawing.
6. Make the interface accessible
Provide text equivalents for important drawing information. A user who cannot distinguish thin lines or operate a mouse should still be able to understand the page structure and reach the same destination. Use meaningful image alternative text, visible focus states, keyboard controls, sufficient colour contrast, and a list or search method for important areas.
Do not communicate status through colour alone. A selected room can use colour, a border, and a text label. Route colours should also be explained by a legend. Test at increased browser zoom and with a keyboard-only workflow. Accessibility improvements usually make the interface clearer for everyone, especially on small screens and in bright environments.
7. Test before publishing
Check every local image, script, stylesheet, and document path in a clean browser session. Test both a local preview and the intended server because rewrite rules, MIME types, caching, and case sensitivity can change behaviour. Open every menu item, select representative hotspots, resize the viewport, and test a slow network connection.
Keep a short acceptance list: the page title is correct, the main image loads, the first interaction is understandable, keyboard focus is visible, the selected state is clear, links open the expected destination, and no private data appears in the browser source. Save screenshots of the approved state so later changes can be compared.
8. Maintain the project
Assign ownership for drawings, data, content, and deployment. A drawing may change without the related room records changing, or a record may change while the drawing remains the same. Use version names or dates, keep a change log, and decide how old links behave when an object is removed. A small maintenance process prevents a successful demo from becoming an inaccurate reference.
Review external dependencies periodically and keep local paths consistent. When a library or asset changes, update the page in a controlled branch and check all demos. The sitemap should contain only pages that are live and useful. Remove obsolete URLs or provide a clear redirect rather than leaving search engines and users with dead ends.
Recommended next step
Choose one representative drawing and one user task. Prepare the source, define five to ten hotspot rules, create a small content set, and test the result with people who did not build it. Record the questions they ask and the places where they hesitate. Those observations are more valuable than adding a large number of features before the basic interaction is clear.
For product, licensing, or implementation questions, use the Contact Us page. For common project questions, read the FAQ and explore the available News articles.
Troubleshooting checklist
When a drawing does not behave as expected, begin with the browser developer tools and inspect the first failed request. A missing image usually points to a relative path, filename case, or URL encoding problem. A missing script may prevent hotspot creation even though the base image appears correctly. Record the exact request and compare it with the folder structure on disk. Spaces and punctuation in filenames deserve special attention because a server and a local file preview may encode them differently.
If hotspots appear shifted, check image dimensions, scaling rules, and the coordinate system used when regions were created. The overlay and the image must use the same origin, aspect ratio, and visible crop. Test at the original image size before adding responsive scaling. If the alignment is correct at one size but not another, inspect the CSS width, height, and positioning rules rather than moving individual hotspot coordinates by hand.
When a page is slow, measure each large image and script separately. Resize images that contain more detail than the user needs, defer optional content, and avoid loading every high-resolution asset before the first interaction. A clear loading state is better than an empty page. Repeat the test on a mobile connection and on a device with limited memory, because a desktop workstation can hide problems that users experience immediately.
When a link works in a hosted preview but fails in VS Code, check whether the target uses a server rewrite. A clean URL such as /support/ may be rewritten to an index file by Apache or another server, while a local preview may require support/index.html. Keep explicit relative links in source files when portability matters, and verify the final clean URLs separately in the deployment environment.
Support handover notes
A good handover package includes the source drawing, the prepared drawing, conversion settings, a list of expected hotspots, a content sample, screenshots, and the known limitations. Name the person responsible for approving geometry and the person responsible for approving wording. Include a short release checklist so future updates do not depend on the memory of the original developer.