Next Article in Journal
Contact Resistance Sensing for Touch and Squeeze Interactions
Previous Article in Journal
Asymmetric VR Game Subgenres: Implications for Analysis and Design
 
 
Article
Peer-Review Record

HoberUI: An Exploration of Kinematic Structures as Interactive Input Devices

Multimodal Technol. Interact. 2024, 8(2), 13; https://doi.org/10.3390/mti8020013
by Gvidas Razevicius 1, Anne Roudaut 2 and Abhijit Karnik 1,*
Reviewer 1:
Reviewer 2:
Multimodal Technol. Interact. 2024, 8(2), 13; https://doi.org/10.3390/mti8020013
Submission received: 4 January 2024 / Revised: 30 January 2024 / Accepted: 6 February 2024 / Published: 13 February 2024

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

TITLE

HoberUI: An Exploration of Kinematic Structures as Interactive Input Devices.

 

SUMMARY OF CONTRIBUTION

The paper describes the development and UX testing of a symmetrical spherical kinematic structure for controlling 3D environments.

 

FINAL EVALUATION

The research, despite presenting some methodological flaws and questionable choices, is quite interesting and valuable, as are the results and possible further activities it suggests. However, the paper could/should describe them much better. The following comments should help the authors to improve the paper, to obtain a version worthy of publication. For these considerations, I think the correct assessment of the paper is “major revisions needed”.

 

COMMENTS

General considerations: please note that I wrote my comments as the reading of the paper went by, not at the end of it. Moreover, English requires a double check. There are glitches here and there.

 

Title

The paper describes the development and UX testing of HoberUI. Period. The “exploration of kinematic structures as interactive input devices” could be possibly found in the related work section only. So… the title, to me, is quite misleading. HoberUI is not an exploration of something; it is a device. One device, not many, explored. Please reformulate.

 

1. Introduction

Figure 1: it is referred in the text… at page 8! This has no sense.

Line 41: it seems that you mean HoberUI as some sort of haptic device, simulating force feedback thanks to its own physical properties. Are you sure that this is good from the UX point of view? You cannot (at least, not easily) control physical properties; therefore, to me, this is a very inappropriate feature to focus on when talking about UI devices…

Line 52: the Introduction section should close by summarizing the document structure.

 

3. HoberUI implementation

Lines 136-154: these lines do not mention the other six DOFs other than the diameter of the sphere. They should.

Line 196: there is no mention about the precision of the device in its current version. No ranges, no tolerances… something about this would be appreciated.

Lines 197-222: I can understand the choice to place the HW in the center of the sphere but that required the addition of structures to hold it (and weight, complications, rigidity, etc.). Placing the HW on the surface of the sphere would have avoided everything, it would not have compromised the handling (consider that you have also the data cable, as visible in Figure 4; it is already a major obstacle to free handling), it would have allowed installing a button… and a simple transformation matrix in the software would have still returned the center of the sphere (in case it should be that important, since the device must detect relative movements, not absolute ones).

Figure 5: a nightmare. This figure is completely unusable. First, the top and bottom should be reversed (real up, virtual down). Furthermore, “Real” should become “Physical”, as reported in the text of the paper. Finally, the three rightmost cubes in the (current) top part of the figure are the same. This does not provide information (or perhaps the information is represented by the eight - incomprehensible - circles under the first two of them?).

Line 253: usually, DOFs are rotational and translational, not “directional”.

 

4. Interacting with HoberUI

Section 4.1.: everything described in this paragraph is counterintuitive to me. Are you sure that your mapping is a winning approach? Please consider the tradeoff in accepting the limitations of the HW to have a more natural interaction. Think we are dealing with UX, not with simple usability…

Figure 6: other than this figure, the paper should offer a link to a video showing the use of HoberUI.

Line 286: being a sphere (infinite symmetries), talking about the “best orientation for the user” is senseless.

Lines 300-313: everything described here sounds not so usable, user friendly, affordable… Also, a context menu navigable with a spherical, shrinkable device? Dunno…

 

5. User study

Lines 328-329: why? Did the affordance concept get unknown?

Line 333-336: usually, a UX test should represent reality as best as possible. You have four tasks; unfortunately, two of them are senseless (they do not have correspondences with reality): shrink a planet relative to a star and arbitrarily move a planet. Was this necessary? Could you have avoided it?

Lines 344-346: good idea to record times. It added some sort of quantification to the evaluation. Unfortunately, you got only the total times instead of recording each task duration of each participant. Moreover, you never refer to these times in the last part of the paper.

Line 355: “usability” should be “UX” here. The use of “frustrating” in line 361 demonstrates this.

Line 359 (and followings): P12… referring precisely to whoever said or did what makes no sense unless you provide any information allowing to characterize the who in some way (always respecting privacy, of course).

Line 366: please uniform this heading with the next one (line 400). “UX considerations related to physical properties” and “UX considerations about mapping” could be a good start.

Lines 375-376: as said before in another comment, this is very questionable.

Lines 408-409: first example of poor UX: very bad affordance…

Lines 412-414: second example of poor UX: slow learnability…

Figure 7: trendlines are useless.

Paragraph 5.4.4.: what emerges here is that the results of the UX evaluation are trivial. The required button, the addition of controllable force feedback that would make the device truly haptic, etc., were clearly foreseen (I mentioned them in my previous comments, written without peeking further into the paper).

 

6. Discussion

Line 472: “absolute”… never taken into consideration.

Paragraph 6.2.1.: this is interesting. But it is unclear if the steady position of the device would be as “fully opened”, “half opened” or “completely closed”. With the related handling problems, in the three cases.

Comments on the Quality of English Language

English requires a double check. There are glitches here and there.

Author Response

We thank both the reviewers for their detailed comments. Reflecting on these comments and suggestions has helped us refine the narrative of the paper. We are pleased to say that the paper has improved based on the suggestions. To help the reviewers quickly identify the changes, we have provided two PDFs in the rebuttal upload. The one with tracked changes will show wherever substantial rewrites have been done to address specific comments. Minor typographical changes have not been highlighted as such. If the raw .tex file is made available to the reviewers, they can toggle the change highlighting by replacing the term ‘false’ with ‘true’ on line66 of the LaTeX file.

The attachment with this response also includes a detailed discussion of every point raised by Reviewer 1 where applicable.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

This is a great and novel work that extends the state of the art in the domain of tangible interfaces. My recommendations aim to improve the presentation of the proposed work and to increase the impact of the (I hope accepted) publication.

 

The command of the English language is fine.

 

The literature is appropriately reviewed.

 

Please define the terms “deployable structures” and “kinematic structures”.

 

Some acronyms are defined (e.g. TUI, SCI) while others are not (HCI).

 

Section 2 would benefit from an introduction that guides the reader through the reviewed literature.

 

Inconsistency in spelling “bi-manual” and “bimanual”.

 

Define acronyms in the first usage of the term. E.g. kinematic degree of freedom (line 16 and line 93) is first used and the (KDOF) 

 

I think I understand that the 7th degree of freedom in the proposed system is size. But, I think that it would be better to explicitly mention them to avoid reader ambiguity.

 

The SLE acronym is defined twice.

 

Could you please explain the term “structure-based”? I get the notion, but it would be better if it were defined.

 

The term heave gesture is used multiple times before eventually being defined in Section 4.1. I think that it would help the reader if it was defined earlier on. Also, there is the use of the heave action, which I cannot understand in which way it differs from the heave gesture.

 

The caption of Figure 1 has a period at its end but the other figure captions do not.

 

If possible, it would be nice to provide the design or 3D model of the scissor-like elements so that others can reproduce the proposed work.

 

How was the size of the proposed user interface device determined? Was it intuitively or based on a human factor study?

 

The term sensed is used for sensor measurements, however the term estimated might be more appropriate. Could you comment on the accuracy of sensory measurements and whether sensor noise is an issue in the proposed system?

 

The term 2-dimensional is used while at the same time, the term 3D is used as well. It would be better if a consistent use of the terms 2D/3D was adopted.

Author Response

We thank both the reviewers for their detailed comments. Reflecting on these comments and suggestions has helped us refine the narrative of the paper. We are pleased to say that the paper has improved based on the suggestions. To help the reviewers quickly identify the changes, we have provided two PDFs in the rebuttal upload. The one with tracked changes will show wherever substantial rewrites have been done to address specific comments. Minor typographical changes have not been highlighted as such. If the raw .tex file is made available to the reviewers, they can toggle the change highlighting by replacing the term ‘false’ with ‘true’ on line66 of the LaTeX file.

The attachment with this response also includes a detailed discussion of every point raised by Reviewer 2 where applicable.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

Most of my recommendations were accepted by the authors and they modified the paper accordingly. Other recommendations have not been reflected in the paper; nevertheless, I consider the authors' discussions convincing. To me, the article has gained clarity and effectiveness and can now be published as it is.

Back to TopTop