Technical Requirements for Engineering & Physics Conference Apps

A specification guide for programme chairs and technical leads at physics, instrumentation, and engineering events — covering what the app must handle and how to verify each requirement before going live.

HEPCon web and mobile interface preview

Physics and engineering conferences are the hardest test for a conference app. They have the densest programmes, the most technically demanding abstract content, the largest author lists, and the most hostile venues for network connectivity. A product that works for a 200-person corporate event will fail silently at ICHEP or CHEP.

This guide is a technical requirements specification — not a vendor comparison process. It covers what the app must be able to handle, why each requirement exists, and how to verify it isn't just claimed but actually delivered.

Looking for the vendor evaluation process — how to run demos, what questions to ask, red flags? That's a separate guide: Conference App Vendor Evaluation Process →

Requirement 1: LaTeX Rendering in Abstract Content

What is required

Inline and display LaTeX equations must render correctly in abstract text, session descriptions, and contribution titles. This includes: Greek letters (α, β, μ, Σ), subscripts and superscripts (pT, E2), common physics notation (→, ⊗, ∫), and standard macros (\sqrt, \frac, \vec, \hat).

Why it matters

Physics and engineering abstracts are written in LaTeX as a matter of discipline convention. An abstract that reads $p_T > 20~\text{GeV}$ as plain text rather than rendering the equation is not a cosmetic issue — it makes the abstract unreadable for the audience and signals that the vendor has no experience with scientific events.

How to verify

Export 10 abstracts from your actual programme — include ones with inline equations, display equations, and any custom macros your community uses. Ask the vendor to render these in their app before the demo. Partial rendering (titles display correctly but inline equations don't) is a common failure mode that's only visible with real content.

Requirement 2: Large Collaboration Author Lists

What is required

Contributions from large HEP collaborations — ATLAS, CMS, LHCb, Belle II, ALICE — may list hundreds to thousands of authors. The app must:

  • Load and display these contributions without crashing or timing out
  • Render all author names without silent truncation
  • Maintain acceptable performance when the contribution list includes many large-author papers
  • Allow author-based search that works across collaboration papers

Why it matters

Most consumer event apps are built around individual speakers with one or two co-authors. Rendering a 3,000-author collaboration list requires explicit engineering decisions that a generic app has no reason to have made. Silent truncation is the most common failure — the UI appears to work but cuts off after 50 or 100 authors without any indication.

How to verify

Take a contribution from a large collaboration in your programme and ask the vendor to import it. Confirm the full author list is present (count the names displayed against the source). Then navigate to that contribution from the session view and confirm load time is acceptable on a mid-range Android device.

Requirement 3: True Offline in Hostile Venues

What is required

The following must work with zero network connectivity — in airplane mode, in a Faraday cage, underground with no cellular signal:

  • Full programme navigation: day → track → session → contribution
  • Contribution detail pages including full abstract text
  • Personal schedule (bookmarks set before losing network must persist)
  • Full-text search across all abstract content
  • Venue maps and room assignments
  • Speaker and author profiles

Why it matters

Engineering and physics conferences are disproportionately likely to include underground or shielded venues: CERN underground areas, detector halls at DESY, SLAC, Fermilab, INFN, JINR, and similar facilities. These venues have no cellular signal and often no Wi-Fi. A conference app that requires network is useless in these spaces.

Additionally, even above-ground venues fail under load. A 1,000-person plenary session means 1,000 devices competing for Wi-Fi at the same time. Offline-first architecture — where all content is cached at first launch — eliminates this problem entirely rather than managing it.

How to verify

During the vendor demo: install the app, sync it to the event, then enable airplane mode. Navigate to three random contributions, search for a term that only appears in abstract text, check a bookmarked session, and open the venue map. Every one of these should work without any loading spinner or error message.

Requirement 4: Navigation at Programme Scale

What is required

The navigation model must support the following hierarchy without performance degradation: Event → Day → Track → Session → Contribution. At scale (400–1,500 contributions across 6–12 parallel tracks over 4–7 days), the following must remain fast:

  • Track and day switching: under 0.5 seconds
  • Full-text search result return: under 2 seconds offline
  • Contribution detail load: under 1 second
  • Personal schedule display: instant (locally stored)

Why it matters

A conference with 8 parallel tracks and 500 contributions is not a larger version of a 50-contribution event — it is a structurally different navigation problem. Apps that load all contributions into a flat list, or that fetch contribution details on-demand rather than pre-caching them, produce navigation that is slow to unusable at this scale.

How to verify

Ask for access to the vendor's largest current event, measured by contribution count. Test navigation, search, and contribution detail loading on that event on a mid-range Android phone — not on a laptop, not on a flagship device. If the vendor doesn't have a reference event with 300+ contributions, this is itself a data point.

Requirement 5: Indico and OpenConf Integration Fidelity

What is required

For Indico-based events, the integration must:

  • Read the full timetable via Indico's REST API or XML export without manual reformatting
  • Preserve the session/contribution hierarchy (not flatten to a list of talks)
  • Import speaker affiliations, abstract text, and attachment links
  • Sync automatically when the Indico timetable is updated (API) or accept a re-export (XML)
  • Support API token authentication for private or institutional Indico instances

For OpenConf and EDAS events, the integration must accept the platform's CSV/XML schedule export and preserve the session/paper hierarchy without requiring manual column mapping.

Why it matters

HEP and instrumentation conferences almost universally use Indico. IEEE/ACM technical symposiums typically use OpenConf or EDAS. An integration that requires manual copy-paste or spreadsheet reformatting reintroduces exactly the data duplication problem you're trying to avoid.

How to verify

Share your Indico event URL (or OpenConf export) and ask for a preview within 48 hours — with your actual data, not a synthetic dataset. The preview should show your tracks, sessions, contributions, author lists, and abstract text as imported. Any structural discrepancy between Indico and the preview (missing tracks, flattened hierarchy, truncated abstracts) indicates integration gaps.

Platform-specific detail: Indico integration guide / OpenConf integration guide

Requirement 6: Device Diversity

What is required

The app must perform acceptably on Android devices that are 2–4 years old and mid-range (e.g. Samsung Galaxy A-series, Xiaomi Redmi, Google Pixel 6a or equivalent). Physics and engineering audiences are globally distributed; device demographics skew significantly toward mid-range Android, particularly among researchers from Eastern Europe, Asia, and Latin America.

How to verify

Run the navigation and search tests above on a mid-range Android, not a flagship device. Ask the vendor specifically: "What is your minimum supported Android version and what is your target performance on mid-range hardware?" A vendor who only tests on flagship devices has not tested for your actual user population.

Summary: Verification Checklist

Run each of these before committing to a vendor.

RequirementHow to testPass condition
LaTeX rendering Export 10 real abstracts, ask vendor to render before demo All equations display correctly, no raw LaTeX visible
Large author lists Import a large-collaboration contribution, count authors displayed Full author list present, loads in <1s on mid-range Android
True offline Enable airplane mode, test all navigation/search/maps All functions work with zero network, no error states
Navigation at scale Test on vendor's largest reference event on mid-range Android Track switching <0.5s, search <2s, contribution load <1s
Indico/OpenConf integration Share your event URL, request preview within 48h Hierarchy preserved, abstracts complete, no manual reformatting required
Device diversity Run all tests on 2–4 year old mid-range Android No significant performance difference vs flagship

Ready to test these requirements with your real data?

Share your Indico event URL or schedule export. We'll generate a preview with your real abstracts, author lists, and parallel tracks in 48 hours — so you can run the verification checklist above against actual output.

Preview With My Programme View Engineering Symposium Solution