A cross-device revision test should compare completion of the same learning tasks, not simply screenshots of the same page. The important questions are whether a learner can answer, inspect the explanation, use the relevant tools and resume later without losing work. A product may be available on several devices without providing an identical experience on each.
This is a pre-results protocol prepared on 19 September 2026. No authenticated phone, tablet or desktop test has been completed for this article, and no timings, success rates or comparative scores are reported. A results article should be based on an actual documented run, not on the predictions below.
Define the task before choosing the devices
Use a bounded sequence: start an appropriate question session, answer a question, read its explanation, inspect an image where available, use a relevant learning function and leave the session before returning. Keep each step distinct so that a failure in one does not become a vague judgement that the whole product is poor.
For example, difficulty opening an explanation is different from a clinical explanation the learner finds unhelpful. The first is an interaction problem; the second concerns educational content. Both matter, but they need different evidence.
Do not require a product to perform a task it does not advertise and then count its absence as a malfunction. Record unsupported functionality as a scope difference. A separate judgement can address whether that scope suits the learner.
Record the environment at execution
The test record should identify the device model, operating system, browser or native-app version, input method, display settings, connection and account entitlement. Add the date and time of each run because a product can change between tests.
"Tested on mobile" is insufficient. A browser session on a phone and a native application on the same phone may follow different workflows. The report should also state whether the learner used a touch screen, keyboard, mouse or assistive technology.
Do not invent those values in advance. This protocol specifies the fields; it does not claim that particular hardware was used. A completed report should retain the actual values alongside its observations.
Keep the content comparison fair
Within one product, use permitted material that makes the task comparable across devices. When repeating a question would introduce familiarity, focus the measurement on interaction rather than educational performance, or use matched tasks and counterbalance their order.
Across competing products, do not copy protected questions into another service. Use each provider's permitted sample for its own workflow and acknowledge that item difficulty differs. Comparing the score from one sample with another is not a cross-device usability test.
The proposed primary outcome is whether the predefined task was completed independently. Secondary observations can include workarounds, lost context, unexpected navigation and time spent resolving the interface. These are proposed measures, not results or validated scales.
Observe the moments that screenshots miss
After selecting an answer, inspect what happens next. Does the view move to the explanation, remain at the options or open a separate panel? Can the learner distinguish their selection from the correct answer? Can they return to the stem while keeping the explanation available?
For an image, record whether the relevant content can be inspected and then connected back to the question. Do not mistake the ability to enlarge an image for the ability to compare it with the clinical information comfortably.
For a Tutor or similar feature, establish whether the attempted question remains in context. Record what the learner must re-enter and whether opening the feature changes the session state. No particular product behaviour is assumed here.
Test continuity as a separate task
Complete a defined step, leave the session using the normal supported route, and return on the same device. Then, where cross-device continuity is advertised, repeat the exercise on another device.
Record which information persists: answer, progress position, explanation access and relevant learning history. Distinguish a displayed answer from one confirmed as saved in the account. If the application gives no observable confirmation, report that limit rather than claiming either success or data loss.
As published in its September 2026 simulation launch, iatroX describes shared progress across web and native apps. This protocol would test specific instances of that claim; the published description is not an observed result from the proposed test.
Include access needs rather than treating them as an appendix
At least some runs should use the settings relevant to the intended participants. Record zoom, keyboard navigation and assistive technology where applicable. A task that works for the evaluator's default setup may not work for the learner purchasing the product.
The W3C's preliminary evaluation guidance, checked on 19 September 2026, provides useful initial checks while warning against treating them as a complete assessment. This proposed exercise is likewise not a certification of accessibility.
Where a participant encounters a barrier, describe the task consequence and the configuration. Avoid generalising a single observation to everyone with a particular disability or to every device sold by a manufacturer.
Report findings without manufacturing a winner
A future results record should separate published capability, observed behaviour and editorial interpretation. "The provider advertises cross-device progress" belongs in the first category. "This answer reappeared on the second device during this run" belongs in the second. "That workflow may suit a learner switching between home and work" is interpretation.
This article is published by iatroX, which must be included under the same protocol as other products. Its ownership is not a reason to overlook friction or give unsupported steps a more generous classification.
As checked on 19 September 2026, AMBOSS advertises mobile Library and Qbank access, including offline functions. Those may be important to some learners, but this article does not claim that the advertised functions were tested or that all AI tools work offline.
For someone studying mainly at a desk, an effective desktop workflow may be sufficient. For someone switching devices frequently, continuity is a separate purchasing requirement. For someone relying on a particular access configuration, successful task completion in that configuration matters more than a generic device count.
What remains before results can be published
The actual products, entitlements, devices, participants and permitted materials must be selected and recorded. Runs need to be completed, observations checked and any provider clarification distinguished from the original finding. Failures and missing data should remain in the report.
Until then, this is a reusable method and purchasing exercise, not a claim that one revision platform performs better on a phone, tablet or desktop.
Frequently asked questions
Have these cross-device tests already been run?
No. This article presents the protocol and contains no observed comparative results.
Can sample question scores be compared between providers?
Not as a fair performance comparison without addressing differences in content, difficulty and conditions. This protocol primarily evaluates task completion and workflow.
Does availability on an app store establish feature parity?
No. Check the specific functions and observed workflow for the device, version and entitlement being evaluated.
Inspect the iatroX question workflow on your preferred device →