A multi-touch with tactile sensations - is it real? Reflections on the topic



    What is this note about.


    In this note, you will not find arguments about the advisability of replacing mechanical input devices (keyboard, mouse, tablets, in the future, possibly scanners) and output (monitors) to some universal multi-touch device. Also, I'm not going to consider the evolutionary-revolutionary change in user interfaces. I think much more competent people have written more than one article on these issues.

    I apologize to sophisticated readers, this opus does not pretend to be a serious article, it is written frivolously and somewhat profanely, but nevertheless, I want to share some thoughts and possibly arrange a discussion about this. Also, unfortunately, while there is no way to draw a couple of human schemes, in the evening they will be mandatory!



    Preamble (skip)



    The main disadvantage of multitouch technology (except for price and reliability, of course) is the lack of feedback. If for small devices such as PDAs or smartphones, the problem is not very acute (although it exists: imagine how convenient it is to dial a phone number in bright sunshine from a mechanical keyboard), then for large devices, such as tables and panels, it is quite relevant, and I I will try to explain why.

    I tried to reflect on the topic of feedback back on the example of the everyday routine of a simple programmer from two thousand @ $ @ # year.

    So, in the yard two thousand @ $ @ #th year. The evil corporation N bought all the patents for multi-touch (there will be many more words in this article, I apologize) and reasonably decided to get money by actively introducing multi-touch concepts into all UIs that they can reach. And even in the line of their IDEs, Casual Studio, the designers of the evil corporation introduced innovative management. And so, before the average programmer Rovshan, the task is to retrain edge-by-edge in a new way (or switch to vim :) Rovshan buys himself a touch board in the nearest store and starts the learning process.

    And then Rovshan realizes that writing code is unpleasant! How often our hero, in a fit of architectural thoughtfulness, kept his fingers on the keys, listening to thoughts in his head, gently crushing, but not pressing them. But how did he like to stroke the keyboard while thinking about the code, gently moving his hand over it and feeling its elastic keys with his fingertips ... ahem, excuse me. Now you need to keep your hands above the sensors, and God forbid you accidentally press something! And how hard it became to write with the blind four-finger method, you have to look where you press all the time.

    How to be I have thoughts. I will divide them into parts.

    Catch up with the keyboard.



    Tasks:
    1. get a tactile sensation of pressing a key from the multitouch section;
    2. thus it is necessary to give the site mnogotyka multitouch certain reserve of elasticity that would even slightly reduce the amount of accidental clicks;
    3. Considering that we are developing not a fashionable keyboard, but a completely universal device.


    Let's reflect. It is clear that it is necessary to divide the working surface into a number of regions / cells, each of which can take at least 2 states: the state of excitation and the state of rest. It is clear that the simplest scheme is a two-dimensional matrix of a large number of square cells ( top view )

    The conditional diagram of the tactile matrix, a pair of brackets symbolizes a cell

    [][][][][][][][][][]
    [][][][][][][][][][]
    [][][][][][][][][][]
    [][][][][][][][][][]
    [][][][][][][][][][]
    [][][][][][][][][][]
    [][][][][][][][][][]


    Suppose we have an elastic coating material that directly displays the image. I suggest thinking about options for implementing tactile sensations. I see such a scheme ( side view in section ):

    Dormancy

    [][][][][][][][][][][][][][][][][][][][][][] эластичный слой с изображением в состоянии покоя
    [][][][][][][][][][][][][][][][][][][][][][] управляющий слой


    The excitation state of a certain section

    _____ [-][-][-][-]
    [][][]___________ [][][][][][][][][][][][][] эластичный слой с возбужденным участком
    [][][][+][+][+][+][][][][][][][][][][][][][] управляющий слой


    So, the idea is clear, what about implementation. There are several approaches: classic mechanical - each cell rises with the help of mechanics in some form, for example, using a relay; electromagnetic - raise the cell with a magnetic field; perverse esoteric - we lift it with compressed air / vacuum, we lift it by expanding a certain body under the influence of temperature, etc. In general, as you can see, the main difficulty consists precisely in displaying the image on some elastic material.

    multitouch API.



    It seems to me that from the point of view of the user programmer, there is nothing complicated here, everyone knows how to work with matrices. In addition, the standard library of widgets can relatively transparently support tactile multitouch by default without unnecessary gestures of the programmer. I will explain later with an example.

    I want to summarize the above and draw some conclusions:
    • there is a very real opportunity right now to create a multitouch device with a tactile response.
    • also, to some extent, the problem of blind control and accidental clicks is solved
    • for a user programmer, it’s enough to simply implement an API for operating at the OS or individual library level


    What problems may await:
    • distortion of the image on the device: in the excited state of the cells, part of the image may be distorted, or when the image is displayed, there will be empty areas at the bends of the elastic layer.
    • standardization and resolution problem for the cellular method: the physical cell size and their total number per square unit of the device will most likely need to be put into the standard.
    • transition speed between cell states: it should be fast enough, why - read on.
    • with the matrix form factor, it is important to have a high dilution of the “clocks” of the cells, otherwise tricks with the rotation of square protruding areas, say 30 degrees, will not please the device owner very much.


    We overtake the keyboard. Flight of fancy.


    I will keep myself within the scope of brevity, otherwise it will turn out a fantastic novel :) I will cite as much as I like:

    One table for 10 people: besides the size of the device, nobody limits us, we can “bulge” at least 10 keyboards - that's enough for everyone.

    OS widget library: now the message boxes of your favorite OS with a fatal error message will contain a convex OK button :) You can finally feel the menu of your OS in the literal sense.

    Unimaginable controls for the application - no external devices: your favorite strategy can now display its own unimaginable keyboard for the game, why not? And who is stopping you from making your own remote control yourself?

    Now, please imagine this all in motion.



    Thank you for your attention.

    Also popular now: