What is this article about?

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

I apologize to sophisticated readers, this opus does not pretend to be a serious article, is written in a frivolous and somewhat profane manner, but still, I want to share some thoughts and, perhaps, arrange a discussion about this. Also, unfortunately, while there is no possibility to draw a couple of human schemes, it will be necessary in the evening!
')

Preamble (you can skip)

The main disadvantage of multi-touch technology (except for price and reliability, of course) is the lack of feedback. If for small devices like PDAs or smartphones, the problem is not very serious (although it does exist: let's imagine how convenient it is to dial a phone number in the bright sun from a mechanical keyboard), then for large devices like tables and panels it is quite relevant, and I I will try to explain why.

I tried to reflect on the reverse response on the example of the everyday routine of a simple programmer from two thousand @ $ @ # th year.

So, in the yard there are two thousand @ $ @ # y year. Evil corporation N bought all the patents for multitouch (there will be many more words in the article, I apologize) and reasonably decided to receive money by actively introducing the concept of multitouch into all the UIs that can reach. And even in the line of their IDE, Casual Studio, the designers of the evil corporation have introduced innovative management. And so, before the average programmer Rovshan, the task is to retrain an edge in a new way (or switch to vim :) Rovshan buys a sensor board in the nearest store and starts the learning process.

And here Rovshan understands that writing code is unpleasant! How often our hero kept his fingers on the keys in a fit of architectural thoughtfulness, listening to the thoughts in his head, gently pressing down, but not pressing them. And how did he like to stroke the keyboard in reflections on the code, gently moving his hand over it and feeling its elastic keys with the pads of his fingers ... hum, sorry. Now you need to hold your hands over the sensors, and God forbid you accidentally press something! And how hard it became to write with the blind four-finger method, all the time you have to look where you press.

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

We catch up with the keyboard.

Tasks:

1. get a tactile sensation of pressing a key from the multitouch area;
2. at the same time it is necessary to give the multi-touch multitouch section a certain margin of elasticity in order to at least slightly reduce the number of random presses;
3. Considering that we are developing not a fashionable keyboard, but a completely universal device.

Let's ponder. It is clear that it is necessary to divide the working surface into a number of areas / 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 )

Conditional diagram of the tactile matrix, a pair of brackets symbolizes the cell

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


Suppose we have an elastic coating material on which the image is directly displayed. I propose to think about the options for implementing tactile sensations. I see such a scheme ( side view in section ):

Resting state

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


The state of excitation of some area

_____ [-][-][-][-]
[][][]___________ [][][][][][][][][][][][][]
[][][][+][+][+][+][][][][][][][][][][][][][]


So, the thought is clear, what about the implementation. There are several approaches: classical mechanical - each cell is lifted by mechanics in any form, for example, by means of a relay; electromagnetic - we lift the cell with a magnetic field; pervertical esoteric - we raise with compressed air / vacuum, we raise with the help of expansion of a certain body under the influence of temperature, etc. In general, as can be seen, the main difficulty lies precisely in the output of the image on some elastic material.

multitouch API.

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

I want to summarize the above and draw some conclusions:

• There is a very real opportunity to create a multitouch device with a tactile response right now.
• in the same way, the problem of blind control and random presses is solved to some extent.
• for a user programmer, it is sufficient to simply implement an API for managing at the OS level or individual libraries

What problems may await:

• image distortion on the device: in the excited state of the cells, a part of the image may be distorted, or when displaying the image there will be empty areas at the places of 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 have to be standardized.
• the speed of transition between states of the cell: should be quick enough, why - read on.
• with a matrix form factor, it is important to have a high vacuum of the “tactics” of the cells, otherwise tricks with the rotation of square protruding areas, say 30 degrees, will not really please the device owner.

Overtake the keyboard. Flight of fancy.

I will restrain myself with the framework of brevity, otherwise I will have a fantastic novel :) I quote as far as interest is concerned:

One table for 10 people: in addition to the size of the device, no one limits us, we can "bulge" at least 10 keyboards - enough for everyone.

OS widgets library: now your favorite OS message boxes with a fatal error message will contain a convex OK button :) You will finally be able to touch the menu of your OS literally.

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 prevents you from making your own remote control?

And now, please, imagine it all in motion.

Thank you for your attention.