Pith. sign in

REVIEW 4 major objections 6 minor 27 references

SnapNCode: An Integrated Development Environment for Programming Physical Objects Interactions

T0 review · 4 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read SnapNCode turns physical objects into visual, code-embedded state values.

desk verdict A legitimately novel IDE prototype for spatial programming, but the unmeasured detection reliability leaves the central functional claim only half-supported — deserves peer review with required revisions. read the letter →

arxiv 2505.09882 v1 pith:MMBZM5DG submitted 2025-05-15 cs.HC

Xiaoyan Wei , Zijian Yue , Hsiang-Ting Chen This is my paper · ORCID
classification cs.HC
keywords spatialcomputingintegrateddevelopmentenvironmentphysicalobject-orientedprogrammingvisualcomputervisionobjectdetectionevent-drivenuserstudy
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

SnapNCode is an IDE prototype whose central claim is that physical objects should appear in programs as images, not just as text variables. The paper argues that by letting programmers capture an object's state from a live camera and insert that image directly into Python code, the gap between code and the real world shrinks, making spatial-computing applications easier to write. It also proposes attaching code snippets to physical objects so that the code runs when a camera observes the object, turning everyday things into event sources. A usability study with 12 programmers reports that participants found the system easy to use, completed tasks with only a few lines of code, and could quickly iterate on triggers. If the approach holds beyond the prototype, it points toward IDEs that treat the physical environment as part of the programming language.

What carries the argument

The central mechanism is the object-state image treated as a first-class value inside a text editor. A custom-trained YOLOv8 object-detection model, combined with the COCO128 model, detects objects in live video frames; snapshots of detected states are stored in a database and displayed in the Object State Panel. Clicking a snapshot inserts it into the CodeMirror-based editor, and the same detection pipeline runs while the program is live, matching stored objects against incoming frames and executing attached code on a Python virtual machine in the backend. The spatial functions On(), In(), and Distance() reduce to geometric checks on 2D bounding boxes.

What would settle it

Run a controlled test with one object carrying attached code: vary lighting, viewing angle, and background over 100 trials, and count how often the code triggers when a state change actually occurs and how often it triggers spuriously; a high false-positive or false-negative rate would settle that the opportunistic triggering claim does not hold.

Watch

Extended reading notes

Core claim

The paper introduces SnapNCode, a browser-based IDE in which a real-world object's state, such as an apple on a plate or an open door, is captured as an image and inserted directly into a text Python program as a variable value. The underlying code remains text, preserving compatibility with familiar workflows, but the visible representation is the photograph. The system also lets a user attach a code snippet to an object; when a mobile or headset camera detects that object in a video frame, the snippet executes. Spatial helper functions On(), In(), and Distance() encode positional relations between detected objects using 2D bounding boxes. The paper's finding is that this hybrid representation is usable: 12 programmers completed predefined and open-ended tasks, and interview feedback supported the idea that images reduce the mental distance between code and physical objects.

Load-bearing premise

The whole system rests on the assumption that a custom-trained YOLOv8 detector will recognize the same physical object instances and their state changes reliably enough in live camera frames for attached code to fire when intended.

Editorial extensions

If this is right

  • A programmer can write event-driven programs such as 'play a ringtone when a door opens' without modeling the door as a 3D asset or wiring it to a sensor.
  • Because the code underneath is ordinary Python in a text editor, programming skills and workflows from conventional IDEs carry over.
  • Attached code travels with the object: any camera running SnapNCode can later trigger it, so programs are tied to physical context rather than to a fixed device.
  • The user study suggests the interaction model is learnable for programmers; pairs completed tasks with 3 to 16 lines of code and iterated on trigger conditions during the session.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If detection accuracy improves, the same snapshot-and-attach pattern could generalize beyond objects to faces, gestures, or scenes, making a trigger condition a visual predicate rather than a hard-coded sensor event.
  • The prototype's 2D bounding-box spatial functions cannot distinguish 'on top of' from 'in front of'; a natural next test is whether depth cameras or segmentation masks preserve the reported usability gains.
  • The attach-code-to-object model implies a security and privacy surface: any camera with access to the object database can execute code, so future versions would need access control and code verification.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. SnapNCode is a prototype IDE for spatial programming in which physical object states are captured through live video and inserted into Python code as images, and in which code snippets can be attached to physical objects and triggered by camera-based detection. The paper describes the system architecture (CodeMirror-based editor, Flask backend, YOLOv8-based detection, Firestore storage), custom spatial functions On()/In()/Distance(), and a usability study with 12 participants performing two predefined tasks and one open-ended collaborative task. The reported results are mostly qualitative: SUS average 66.5, TAM subscale averages, task completion times, and interview feedback. The paper claims that participants found the system easy to use, that it reduces the perceptual distance between physical objects and code, and that it could integrate into existing workflows.

Significance. If the system works as described, the contribution is meaningful for HCI and spatial-computing authoring: it offers a concrete prototype that makes physical-object states first-class visual values in a text-based IDE and enables object-attached, camera-triggered code. The paper reports a nontrivial user study with realistic tasks and an unusually candid Limitations section that concedes the main technical constraints. The core weakness is that the central behavior—reliable detection and triggering of object states—is never quantitatively evaluated; the paper reports no detector accuracy, trigger correctness, or spatial-function accuracy. The user study supports only modest usability claims, and even those are weakened by the absence of variance reporting and by an SUS score that is near the conventional benchmark. With the missing reliability measurements supplied or the claims appropriately narrowed, the paper could be a useful system contribution to the spatial-programming IDE literature.

major comments (4)
  1. [§4, 'Code Triggering'; §6.1] The central event-driven behavior of SnapNCode rests entirely on the detection/matching step, which is described in one sentence in Section 4: "If a match is found between the detected object and those stored in the database, the corresponding code is executed on a Python virtual machine in the backend." No detector precision/recall, confidence threshold, matching metric, or state-transition semantics are reported anywhere, and the user study reports no objective trigger-correctness data. The only reliability incident described in Section 6.1 (participants P5 and P6) is a spurious repeated trigger caused by frame-level matching logic. Because the paper's central claim is that SnapNCode enables programming physical object interactions, the absence of any false-positive/false-negative measurement at the trigger level is load-bearing. The paper should either report such measurements (e.g., detection accuracy, trigger precision/recall over the study sessions) or substantially narrow the central claim.
  2. [§8, Limitations; §5.4] Section 8 concedes that the custom-trained YOLOv8 model "does not always cover the specific objects or states that users intend to incorporate into their code" and that tracking a particular object instance requires retraining. This is not a peripheral implementation detail: Section 3.1 invites users to snap arbitrary physical objects and states into code, but the system can only handle pre-trained categories and instances. The user study used only 10 pre-trained objects (§5.4) and reports no detection success/failure rates across sessions. The paper should state the supported object/state coverage precisely and report per-object detection success rates or an equivalent measure, otherwise the generality of the proposed workflow is not established.
  3. [§6.1, Results (SUS/TAM, Fig. 8 and Fig. 9)] The usability claim is based on an average SUS score of 66.5, which the text interprets as indicating that participants "are satisfied," but no variance, individual-score distribution, or statistical comparison is reported. This value is near or below the conventional 68-point benchmark for acceptable usability, so the optimistic interpretation is not justified as presented. TAM subscale averages are also reported without standard deviations, making agreement levels impossible to assess. In addition, the predefined-task results report only completion times and lines of code, not task success/failure counts. Please report distributions, per-task success rates, and a more conservative interpretation of the SUS score.
  4. [§3.1, §4, 'Spatial Functions'; Fig. 4] The motivating example in Figure 4b uses the On()/In() and Distance() spatial functions to determine, for instance, when a mouse is removed from a book. Section 4 states that these functions are computed from 2D bounding-box coordinates, and Section 8 correctly concedes that this "does not capture the 3D spatial relationship between objects." However, the paper reports no controlled evaluation of these spatial functions—no accuracy data for on/in/contained relationships under varied camera angles, distances, or occlusions. Since the example programs and the predefined tasks depend on these functions for correct triggering, the paper should include a controlled evaluation or explicitly delimit which spatial relationships are and are not supported.
minor comments (6)
  1. [§4 and throughout] There are several typos and incomplete sentences that should be corrected, including "virtula machine" in Section 4, "enviornment" in Related Work, "particiates" in Section 6.1, and the incomplete clause "thus offer [1]" in Related Work.
  2. [Fig. 8 and Fig. 9] The SUS and TAM figures show average item scores but the axes and item labels are ambiguous; please clarify which items are negatively worded/reverse-scored, add the number of participants, and indicate whether error bars or distributions are available.
  3. [§5.4] The sentence "We pre-trained our model on 10 physical objects, including various stationery items and fruits like apples, bananas, and oranges" is vague; please list the exact object categories and note whether any objects in the study area were not among the pre-trained classes.
  4. [Table 10 (Fig. 10)] The column header "Num of codes per object" is not defined, and entries such as "apple(2), bowl(4), book(3)" are not explained; please clarify how these counts were computed and what they represent.
  5. [§3.1 and §4] The term "states" is used for examples like "an open door" or "an empty fruit bowl," but Section 4 describes only object detection, not a separate state-classification capability; please clarify whether state recognition is implemented and, if so, how state labels are trained and associated with triggers.
  6. [§6.1, P5/P6 example] The description of the P5/P6 iteration is grammatically unclear ("the command was triggered too frequently, for the mouse was moved frequently by other purposes"); please rewrite this passage and, more importantly, report it as a false-trigger incident that motivated the users' workaround.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: SnapNCode is presented as a system artifact with a user study, and no claimed derivation reduces to its own inputs.

full rationale

SnapNCode is an HCI systems paper, not a derivation paper. Its central claim—that an IDE can let programmers insert camera-captured physical object states into code and attach code to objects—is supported by a described implementation (Section 4) and a usability study (Sections 5-6), not by a mathematical derivation. The triggering mechanism is given as a direct operational rule: 'If a match is found between the detected object and those stored in the database, the corresponding code is executed' (Section 4). The spatial functions In() and On() are defined straightforwardly from YOLOv8 bounding-box coordinates and are explicitly limited to 2D distance between bounding-box centers (Sections 3.1, 4, and 8); the definition does not assume the effect it is used to explain. The authors cite their own prior work ([3], [14], [15], [16]) only as related work and future-directions context, not as load-bearing evidence for SnapNCode's functionality. The limitation that the custom-trained YOLOv8 model 'does not always cover the specific objects or states that users intend' (Section 8) weakens empirical generality but is a stated limitation of the artifact, not a circular step. No fitted parameter is renamed as a prediction, no uniqueness theorem is imported from the authors' own prior work, and no equation equates the output to the input. The honest finding is therefore no significant circularity.

Assumptions & free parameters 0 free parameters · 1 assumptions · 0 invented entities

This is a systems and usability paper, not a mathematical derivation. No free parameters are fitted to data. The system behavior rests on implementation choices described in Section 4 and the paper's own limitations, not on axioms invoked in a proof. The detection reliability assumption is the main domain assumption and is explicitly acknowledged as a limitation.

assumptions (1)
  • domain assumption YOLOv8 bounding boxes identify object instances and their spatial relationships well enough to drive event triggering.
    The system's attached-code triggering and On/In/Distance functions use YOLO detections as ground truth (Section 4); the paper limits this to 2D and says retraining is needed for new objects (Section 8).

how reviews work

0 comments
Cite this review

Pith. "Pith review of SnapNCode: An Integrated Development Environment for Programming Physical Objects Interactions." pith.science (2026). https://pith.science/paper/MMBZM5DG

@misc{pith2026250509882,
  author       = {Pith},
  title        = {Pith review of: SnapNCode: An Integrated Development Environment for Programming Physical Objects Interactions},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MMBZM5DG}},
  note         = {Machine review of arXiv:2505.09882}
}
read the original abstract

Spatial computing technologies have the potential to revolutionize how we interact with the world around us. However, most modern integrated development environments (IDEs) have not fully adapted to this paradigm shift. For example, physical 3D objects in the real world are still represented as 2D text variables in code, creating a significant perceptual distance between these representations. In response to this challenge, we introduce SnapNCode, a novel IDE for spatial programming. SnapNCode enables programmers to capture various states of physical objects through live video streams from cameras and directly insert these visual representations into their code. Moreover, users can augment physical objects by attaching code snippets onto objects, which are opportunistically triggered when observed by cameras. We conducted a user study (N=12) to assess the usability of SnapNCode. Feedback from participants indicates that the system is easy-to-use and holds promise for daily casual uses and integration into a broader range of workflows.

Figures

Figures reproduced from arXiv: 2505.09882 by the authors.

Figure 1
Figure 1. SnapNCode is an IDE facilitating the development of spatial computing applications. (a) captures the images of an apple and send capture object to the system by using SnapNCode mo￾bile application (b) developing a notification program advising users after fruit was removed, by SnapNCode pc application (c) checking existed code attached to an apple by using SnapNCode mobile application. Abstract. Spatial computing te… view at source ↗
Figure 2
Figure 2. User Interface tential applicability of our system across various fields, including medicine, chemistry, and architecture, in the future. The contributions of this paper are as follows: – We introduce a novel IDE prototype that allows the representation of variables corresponding to physical object states as images, while preserving the underlying text structure for easy integration into existing workflow. – We prop… view at source ↗
Figure 3
Figure 3. Four main components of SnapNCode [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Workflow of SnapNCode: Program the different states of the objects: a. Taking the photos and upload by mobile. The photos will automatically appear in the object states panel on PC b. Program Scripting with Python. c. Program set up. Attachment to the Object. d. Trigge…
Figure 5
Figure 5. Figure 5: The function of converting embedded images into text descriptors Snap physical objects into code Our IDE enables users to capture physical object states using a web camera or a mobile phone. For instance, a user can take photos of "an open door" or "an empty fruit bowl…
Figure 6
Figure 6. Figure 6: The function of variable highlighting the physical object (Figure 3d). When a video device running the SnapNCode appli￾cation detects the attached code, the code will be triggered and executed (refer to the Implementation section for details). The code attachment inter…
Figure 7
Figure 7. Figure 7: System Design Diagram Objects Detection The SnapNCode backend uses a custom-trained YOLOv8 model in conjunction with the official YOLOv8 COCO128 model for instance and object de￾tection. The former handles the instance tracking and the object categories that are not pr…
Figure 8
Figure 8. Figure 8: SUS Average Score with scores showing that participants found the system easy to learn. Attitude towards using the system (ATT), as shown from ATT1 to ATT3, shows a positive trend, with an average score above 3.5, indicating support and satisfaction with the system. Th…
Figure 9
Figure 9. Figure 9: TAM Average Score SMTP library in Python to enable the sending and receiving of emails directly from the program. However, others(P1,P2,P8,P10) are exploring how to get the job done with minimalist code possible. These attempts show a high degree of user involvement in…
Figure 10
Figure 10. Figure 10: Descriptions of the open-ended prototyping results programming process, potentially leading to inadvertent activation of each other’s code, thereby increasing the time spent on debugging. 6.2 Interview User interface design and experience During the interviews, our pa…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

27 extracted references · 19 canonical work pages

  1. [1]

    Bau, D., Gray, J., Kelleher, C., Sheldon, J., Turbak, F.: Learnable programming: blocks and beyond. Commun. ACM 60(6), 72–80 (May 2017)

    work page 2017

  2. [2]

    Cho, H., Komar, M.L., Lindlbauer, D.: Realityreplay: Detecting and replaying temporal changes in situ using mixed reality. Proc. ACM Interact. Mob. Wearable Ubiquitous Technol. 7(3) (sep 2023). https://doi.org/10.1145/3610888, https://doi.org/10.1145/3610888

    doi:10.1145/3610888 2023

  3. [3]

    IEEE Transactions on Visualization and Computer Graphics 27(1), 204–215 (2019)

    Cortes, C.A.T., Chen, H.T., Sturnieks, D.L., Garcia, J., Lord, S.R., Lin, C.T.: Evaluating bal- ance recovery techniques for users wearing head-mounted display in vr. IEEE Transactions on Visualization and Computer Graphics 27(1), 204–215 (2019)

    work page 2019

  4. [4]

    In: Proceedings of the 43rd Graphics Interface Conference

    Ens, B., Anderson, F., Grossman, T., Annett, M., Irani, P., Fitzmaurice, G.: Ivy: Exploring spatially situated visual programming for authoring and understanding intelligent environ- ments. In: Proceedings of the 43rd Graphics Interface Conference. pp. 156–162. GI ’17, Canadian Human-Computer Communications Society, Waterloo, CAN (Jan 2017)

    work page 2017

  5. [5]

    Frau, V ., Spano, L.D., Artizzu, V ., Nebeling, M.: Xrspotlight: Example-based programming of xr interactions using a rule-based approach. Proc. ACM Hum.-Comput. Interact. 7(EICS) (jun 2023). https://doi.org/10.1145/3593237, https://doi.org/10.1145/3593237

    work page doi:10.1145/3593237 2023

  6. [6]

    CRC Press (1996)

    Jordan, P.W., Thomas, B., McClelland, I.L., Weerdmeester, B.: Usability evaluation in in- dustry. CRC Press (1996)

    work page 1996

  7. [7]

    In: Proceedings of the IEEE/CVF International Conference on Computer Vision

    Kirillov, A., Mintun, E., Ravi, N., Mao, H., Rolland, C., Gustafson, L., Xiao, T., White- head, S., Berg, A.C., Lo, W.Y ., et al.: Segment anything. In: Proceedings of the IEEE/CVF International Conference on Computer Vision. pp. 4015–4026 (2023)

    work page 2023

  8. [8]

    In: Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems

    Leiva, G., Nguyen, C., Kazi, R.H., Asente, P.: Pronto: Rapid augmented reality video proto- typing using sketches and enaction. In: Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems. pp. 1–13 (2020)

    work page 2020

Show all 27 references
  1. [9]

    In: Proceedings of the 2023 CHI Conference on Human Factors in Comput- ing Systems

    Monteiro, K., Vatsal, R., Chulpongsatorn, N., Parnami, A., Suzuki, R.: Teachable reality: Prototyping tangible augmented reality with everyday objects by leveraging interactive ma- chine teaching. In: Proceedings of the 2023 CHI Conference on Human Factors in Comput- ing Syste...

    2023

  2. [10]

    In: Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems

    Nebeling, M., Rajaram, S., Wu, L., Cheng, Y ., Herskovitz, J.: Xrstudio: A virtual production and live streaming system for immersive instructional experiences. In: Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems. pp. 1–12 (2021) SnapNCode 17

    2021

  3. [11]

    In: Proceedings of the INTERACT’93 and CHI’93 conference on Human factors in computing systems

    Nielsen, J., Landauer, T.K.: A mathematical model of the finding of usability problems. In: Proceedings of the INTERACT’93 and CHI’93 conference on Human factors in computing systems. pp. 206–213 (1993)

    1993

  4. [12]

    In: Proceedings of the 8th In- ternational Conference on Interaction Design and Children

    Radu, I., MacIntyre, B.: Augmented-reality scratch: a children’s authoring en- vironment for augmented-reality experiences. In: Proceedings of the 8th In- ternational Conference on Interaction Design and Children. p. 210–213. ACM, Como Italy (Jun 2009). https://doi.org/10.1145...

    2009

  5. [13]

    Resnick, M., Maloney, J., Monroy-Hernández, A., Rusk, N., Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., Kafai, Y .: Scratch: programming for all. Commun. ACM 52(11), 60–67 (Nov 2009)

    2009

  6. [14]

    In: Proceedings of the 19th ACM Symposium on Virtual Reality Software and Technology

    Sasaki, N., Chen, H.T., Sakamoto, D., Igarashi, T.: Facetons: face primitives with adaptive bounds for building 3d architectural models in virtual environment. In: Proceedings of the 19th ACM Symposium on Virtual Reality Software and Technology. pp. 77–82 (2013)

    2013

  7. [15]

    Frontiers in Virtual Reality 2, 597487 (2021)

    Shen, S., Chen, H.T., Raffe, W., Leong, T.W.: Effects of level of immersion on virtual training transfer of bimanual assembly tasks. Frontiers in Virtual Reality 2, 597487 (2021)

    2021

  8. [16]

    NeuroImage226, 117578 (2021)

    Singh, A.K., Gramann, K., Chen, H.T., Lin, C.T.: The impact of hand movement velocity on cognitive conflict processing in a 3d object selection task in virtual reality. NeuroImage226, 117578 (2021)

    2021

  9. [17]

    In: Proceedings of the 2nd International Workshop on Interactive EXtended Real- ity

    Van Damme, S., Van de Velde, F., Sameri, M.J., De Turck, F., Vega, M.T.: A haptic- enabled, distributed and networked immersive system for multi-user collaborative virtual reality. In: Proceedings of the 2nd International Workshop on Interactive EXtended Real- ity. p. 11–19. I...

    2023

  10. [18]

    International Journal of Human–Computer Interac- tion 36(13), 1242–1257 (Aug 2020)

    Wang, P., Bai, X., Billinghurst, M., Zhang, S., Han, D., Sun, M., Wang, Z., Lv, H., Han, S.: Haptic feedback helps me? a vr-sar remote collaborative sys- tem with tangible interaction. International Journal of Human–Computer Interac- tion 36(13), 1242–1257 (Aug 2020). https://...

    2020

  11. [19]

    In: Proceed- ings of the 33rd Annual ACM Symposium on User Interface Software and Technology

    Wang, T., Qian, X., He, F., Hu, X., Huo, K., Cao, Y ., Ramani, K.: Capturar: An aug- mented reality tool for authoring human-involved context-aware applications. In: Proceed- ings of the 33rd Annual ACM Symposium on User Interface Software and Technology. p. 328–341. UIST ’20,...

    2020

  12. [20]

    arXiv preprint arXiv:2304.11968 (2023)

    Yang, J., Gao, M., Li, Z., Gao, S., Wang, F., Zheng, F.: Track anything: Segment anything meets videos. arXiv preprint arXiv:2304.11968 (2023)

    2023 arXiv

  13. [21]

    CHI ’22, Association for Comput- ing Machinery, New York, NY , USA (2022)

    Ye, H., Fu, H.: Progesar: Mobile ar prototyping for proxemic and gestural in- teractions with real-world iot enhanced spaces. CHI ’22, Association for Comput- ing Machinery, New York, NY , USA (2022). https://doi.org/10.1145/3491102.3517689, https://doi.org/10.1145/3491102.3517689

    2022

  14. [22]

    In: Proceedings of the 2023 CHI Confer- ence on Human Factors in Computing Systems

    Ye, H., Leng, J., Xiao, C., Wang, L., Fu, H.: Proobjar: Prototyping spatially-aware interactions of smart objects with ar-hmd. In: Proceedings of the 2023 CHI Confer- ence on Human Factors in Computing Systems. CHI ’23, Association for Comput- ing Machinery, New York, NY , USA...

    2023

  15. [23]

    In: Proceedings of the 22nd annual ACM symposium on User interface software and technology

    Yeh, T., Chang, T.H., Miller, R.C.: Sikuli: using GUI screenshots for search and automa- tion. In: Proceedings of the 22nd annual ACM symposium on User interface software and technology. pp. 183–192. UIST ’09, Association for Computing Machinery, New York, NY , USA (Oct 2009) ...

    2009

  16. [24]

    In: Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems

    Zhang, L., Agrawal, A., Oney, S., Guo, A.: Vrgit: A version control system for collaborative content creation in virtual reality. In: Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems. pp. 1–14 (2023)

    2023

  17. [25]

    In: Proceedings of the 33rd Annual ACM Symposium on User Interface Software and Technology

    Zhang, L., Oney, S.: Flowmatic: An immersive authoring tool for creating interactive scenes in virtual reality. In: Proceedings of the 33rd Annual ACM Symposium on User Interface Software and Technology. pp. 342–353 (2020)

    2020

  18. [26]

    In: Proceedings of the 35th Annual ACM Symposium on User In- terface Software and Technology

    Zhu, Z., Liu, Z., Wang, T., Zhang, Y ., Qian, X., Raja, P.F., Villanueva, A., Ramani, K.: MechARspace: An authoring system enabling bidirectional binding of augmented reality with toys in real-time. In: Proceedings of the 35th Annual ACM Symposium on User In- terface Software ...

    2022

  19. [27]

    In: Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems

    Zhu, Z., Liu, Z., Zhang, Y ., Zhu, L., Huang, J., Villanueva, A.M., Qian, X., Peppler, K., Ramani, K.: LearnIoTVR: An End-to-End virtual reality environment providing authentic learning experiences for internet of things. In: Proceedings of the 2023 CHI Conference on Human Fac...

    2023

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.