Spray on liquid glass is flexible and will revolutionize the touch screen

I hope some of you are as excited as I am about this recent discovery.

This is spray on liquid glass on a microfibre. They caused this fissure to demonstrate the properties.

One of the biggest drawbacks to a public mounted touch screen is the transfer of germs from bystander to bystander. This is not as much as real as it is a psychological boundary we have encountered. In exit interviews from User Experience tests we consistently get feedback about the cleanliness of the surface and the other participants hands. We had to put antiseptic baby wipes near the Surface units to help alleviate this problem.

Cleaning touch screens is an odd process. Depending on the material used, be it a rough or smooth material, it usually had special instructions about cleaning. The typical monitor has a special non-glare coating and recommends using soap and a damp cloth. Using non-glare finishes on touch screens have similar recommendations. Do not use cleaners or antiseptic solutions because they will damage the finish and possibly remove the protective coating.

What this amazing discovery gives us is something that will innovate the market in the eyes of the public.

Here is the main article about the glass.

Spray-on liquid glass is transparent, non-toxic, and can protect virtually any surface against almost any damage from hazards such as water, UV radiation, dirt, heat, and bacterial infections. The coating is also flexible and breathable, which makes it suitable for use on an enormous array of products. (via physorg)

This is amazing. This gives us the ability to spray a coating on a touch screen and then the ability to clean it with antiseptic germ killing chemicals without the harmful side effects of destroying the surface or the experience. It is also so thin it allows the transference of touch to the unit.

Long live physics!

Gesturcons: an icon language to describe natural user interface gestures

One of the prevailing themes of my writing is the ability for everyone to gain common grounds when discussing interactions. I believe one of the keys to this is a common metaphor, OCGM (Objects, Containers, Gestures, and Manipulations) as well as a set of icons for use in design. When sketching out the user experience it’s important to note the interactions. This is especially true in state diagrams, specs, and other interaction design documents. In my first installment of Gesturcons, I present to you the Gesturcons : Touch Pack 1.0. These are being released under the Creative Commons License and I hope that you all find some good use for them in your designs and experiences.

This is the first batch, for touch. I also have Spatial, Voice, and a few others in the works.

Updates

I’m using a simplistic graphic design language to represent the actions by a user. If we use OCGM to boil down each action, we get just a few basic actions that all can be constructed from. To combine these actions together I use only two different states. They either happen at the same time, or they happen consecutively.

After we have established exactly when the action takes place, we can then talk about the specific actions. I use only a few different types of basic actions as well. The only addition you see here is the Location Specific Icon. That means that the exact placing of that particular input is predetermined by the system for the manipulation or the gesture to be successful. As an example, the Red X at the top right of Windows is a location specific manipulation.

The path icon is pretty straightforward. It means that the path the user has to take to accomplish the goal is specific and is going to be bound by guidelines. Those rules are what you have devised, but the path is specific.

The rotation icons are dual purpose. They can mean an actual spin of the input or a spin of the action. This could be boiled down to a Path, because they have to follow a certain pathway to achieve success. I find it easy, but others find it difficult to also put a rotation as a simple path. So I added it here for ease of use. Notice the use of Twin when its dual simultaneous inputs.

To sum up the use of the Gesturcons, I present an example of how you could build your own gestures using this language. In this example I demonstrate the visual identifiers to show a gesture of the question mark.

I’ve also updated the Zip file with all these new gestures. Enjoy and happy designing.

Here is the ZIP, which contains all the PNGs, the Illustrator File and an EPS as well. These are being released under the Creative Commons, which means you can use them internally as much as you want but you cannot package them, redistribute them, or include them in any professional product.

License here

Gesturcons by Ron George is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.
Based on a work at blog.rongeorge.com. Permissions beyond the scope of this license may be available at http://blog.rongeorge.com/design/gesturcons/.

Welcome to the OCGM Generation! Part 2

In this post I’m going to explain some of the concepts and give a few examples of each. For the most part I will be responding to other posts I have seen on the issue. I will not be explaining it 100% because I want you to let your mind roam and explore this area. Think of this as the Socratic Method for promoting and understanding this concept.

OCGM

This concept for promoting the design and development of modern interfaces is not an end all, be all solution. This is just another step in the discussion of design.

When discussing interface or system design we need a way to discuss it to the non-design person so they understand the general concepts. This would be a way to use it when discussing what type of interface you are going to have on your system. It bolts out the quick cornerstones of development and will encompass the general ‘feel’ of the end result. Typically when you hear what type of interface you are going to design, you hear “WIMP,” which stands for Windows, Icons, Menus, and Pointing Devices. This tells the developers in short and quick fashion exactly what to expect. This is still being used to this day.

In our generation, systems and interfaces are growing by leaps and bounds. The easiest way to communicate that to a developer, stakeholder, or another designer is by using the new acronym, OCGM.

“What type of interface is it going to be Ron? WIMP?”

“Actually, No, its going to be OCGM!”

“Ummm, huh? Like… we already have these templates made out with buttons and sizes… wait.. what the hell is OCGM?”

OCGM breaks down the basis of all future interfaces into two categories and those are broken down into two subcategories. One for items and one for Actions. Everything on an interface that you will be interacting with is going to be one or the other. Of those two categories, they are then broken down even further, by saying, we have a base unit and then we have a complex unit of each. With those 4 items, you can begin to discuss exactly how those will come into play into your future interface.

OBJECTS – Objects are any type of unit or part of a unit on your interface. This is just a way to define your smallest quantifiable bit. This could take the shape of a piece of album art, a picture, an icon, a ball, or an aura of some kind. The importance of this is that each of these objects represent something or some action in the system. This is meant to be all encompassing because we do not want to limit designers or developers when they sit down to brainstorm ideas. If you tell them Icons and Windows… they will design Icons and Windows. Let them think outside the box when they develop.

CONTAINERS - Containers are a way to discuss the relationship of objects. Containers do not have to take the form of an actual physical box or window. They take the shape of a relationship between objects that you manage through your interface in whatever means you see fit. They could be 5 balls circled around a larger ball which forms a sort of a menu. They could be a simple tagging system. Then by the use of a gesture you reveal the tagged objects and therefore reveal the container. Relationships are key to managing objects and understanding how they will interact with each other is key to your design.

MANIPULATIONS and GESTURES are absolutely crucial in their significance from each other and their significance when designing the user experience. Understanding the difference between these two interactions will make or break the user experience. Manipulations are direct action and reaction on your interface. The user manipulates something, gets immediate feedback, and understands the result of their action. These are simple, easy to understand, somewhat intuitive, and graceful. Gestures are complex actions that are indirect. They can be harmful (format a drive), they are usually not intuitive (draw a ? for help), and are not geared towards the first user experience. So let’s break this down a step further.

Why does the designer or developer need to understand the difference and design accordingly? Because manipulations are the easy way out. They can be your absolute best friend and they can perform most of the common daily user tasks that the user will need. They are designed for beginners, medium users, and for accidental activations. Accidental Activations!! When designing your interface, always design for accidental activations and always gear them towards a Manipulation. Never allow them to be a gesture on accident! While using a Surface Unit, when I brush my sleeve across the screen (which happens significantly) you should never design a “left swipe” to delete a file. This is the core of understanding the difference.

If you want to start the self destruct on a ship, you don’t merely have to press a button. You have to perform a gesture, several manipulations in a sequence that are recognized at the end of the sequence. Only then, after the order is maintained and accomplished does a gesture get recognized and then the action is performed.

Ok, that’s enough explaining for now. Let me answer a few blog posts about the subject. I will dissect the arguments a little to pull out points.

Some great critical thinking over at the clevermonkey. (we need more of this)

… I’m sorry to say that OCGM fails both of my tests. It is at once non-inclusive of the three primary technologies I outlined as well as being to ambiguous to be useful. In addition, the terms used in the acronym overlap so much as to be redundant. ..

The first test is…

Touch UI

Voice UI

Gestural UI

Tangible UI

Organic UI

Augmented Reality

Automatic Identification [via clevermonkey]

Organic UI on the side of a Coke Can, but can it remove the sugar? That's my question.

Richard is saying that OCGM does not encompass the first three of his 7 technologies. I think the first problem I have with this, is the list is it is not a list of NUI devices. This is a mixture of interface types (OUI), interaction types (GUI), experience types (Augmented Reality), and Identification Methods (Automatic Identification). I don’t see a relationship between these devices other than they are new and could be perhaps governed by a non-standard UI. That is the case in most devices though, isn’t it? Let me give a quick sentence on some of the farther reaching devices.

OUI - is a non-symmetrical, bendable, or wearable interface. The determining factor is how its displayed to the user. The actual interface will take the shape of its viewable area, but it is just a way to describe non-Monitor types of interfaces. [Examples: bracelets that have an LCD around the band, shirts that tell your vital signs, a small LQD that bends around a table leg and gives you scores/radio for your favorite show or game].

Automatic Identification – This is a method to identify a user, an action, or another system by any means necessary. Could be authentication, recognition for home entertainment, DNA for weapons [District 9 killed!]

The F-35 Demon Helmet is Augmented Reality to the extreme

Augmented Reality – superimposing the results of a system onto your life through vision, motion, or some other means not developed yet. [Yelp on your phone while looking through the camera, a HUD on a fighter jet superimposing targets on the screen]

My Answer: The first 3 all fit very well into the OCGM acronym.

Voice - Voice is a complex system. Of the few dozen or so pure voice systems I have played with most of them. The latest and most advanced one that has come out, came from MSN Auto. It is a purely voice driven menu system for a car. It contains OBJECTS [people, phone numbers, favorites, places, presets], CONTAINERS [groups of contacts such as Work or Home, groups of places such as frequently shopped locations] Manipulations ["Volume Up!" "Call ..... "] and it contains Gestures ["Emergency!" automatically performs a complex manipulation {"dial.... 9.....1.......1....... "}, or presets, "Becky!" automatically performs whatever action you set for the Becky command].

The OCGM system works very well with most languages as well, and especially well with Bill Buxton’s paper on the 3 State Method. If anyone hasn’t read that, you should read it now or put down your pen forever!

Touch UI – This absolutely fits the model because it is inherently part of the birth of it. It contains OBJECTS [pictures, icons, floating buttons, small song notes that represent songs], CONTAINERS [groups of pictures in a Pod or Bar {PS: I was published on my creation of a selector system for the POD in Surface at the 2008 IEEE Tabletop Conference}, playlists of notes, tagging multiple photos], Manipulations [touch the ball and move it across the screen] and GESTURES [right now this is slim on the Surface, but there are several in the SDK, such as draw a ? for help, draw an X for delete].

Project Natal. "Falcon Punch! Body Blow! Body Blow! FINISH HIM!"

GESTURAL UI – I’m not sure what you mean by this one. Do you mean SPATIAL? If you mean spatial, I’m not really sure what I can disclose about NATAL, but I can assure you that all of the 4 items are covered.

The second point I see from Richard is this one

Windows, Icons, Menus, and Pointer are all pretty clear. An acronym for NUI should be equally as clear or its not useful. [via clevermonkey]

I wholeheartedly disagree with this. In fact, we want to go the opposite direction. We want to not spell out all the details for interfaces and we want to empower the designers to design for their experience. We want to arm the designers of the future with the cornerstones of good design and let them go wild! It’s no secret that I am not a big fan of UI DESIGN PATTERNS. I think that for the most part, they are a waste of talent. When designers could and should be thinking outside of the typical experience, they rely on a “crutch” called a UI pattern. Those patterns were developed by City Engineers because there were only so many different ways you can put 3 buildings on a city block. That’s where they came from and that’s where they need to stay!

This acronym is intentionally vague by only discussing the bare mechanics of a future driven interface. The reasoning for this is simple. It’s to empower the designers! Designers need that room to breathe when sitting down to solve their next problem. By only giving the mechanics we allow the designers to design the experience.

That’s all for round 1! I welcome emails or comments for tomorrow’s battle. With this, I leave you one last question:

WIMPy vs OCCAM. Is there really a choice? I mean, OCCAM got to wear a wreath on his head every day. That is awesome!

OCGM (pronounced Occam['s Razor]) is the replacement for WIMP

WIMP is the current acronym for the Windows User Experience. It stands for Windows Icons Menus Pointing Devices.

In human–computer interaction, WIMP stands for “window, icon, menu, pointing device“, denoting a style of interaction using these elements. It was coined by Merzouga Wilberts in 1980.^[1] Although its usage has fallen out of favor, it is often used as an approximate synonym of “GUI“. WIMP interaction was developed at Xerox PARC (see Xerox Alto, developed in 1973) and “popularized by the Macintosh computer in 1984″, where the concepts of the “menu bar” and extended window management were added. [2] [via Wikepedia]

The WIMP interface is a slow dying breed as our demands on user experience and the demands of user’s keep inflating. It’s time to start thinking in a new direction. A direction that sheds many of the harnesses of the old acronym and begins to explain the building blocks of the future. It will be simple, concise, and cover all of the bases we need. There is no need to rely on pointing devices, menus, or windows anymore. It’s time to let the experience be the interface, and the user to be in total control. The interface will begin to blend in with the experience and the experience will be the interface.

I have spent several months thinking about this and trying to solidify something presentable. This is the fruit of my labor. I present to you:

This acronym is short, concise, and to the point. It contains all the elements the modern designer will ever need. In discussing this acronym with someone yesterday, he asked “Why do you separate out manipulations and gestures?” This is a good question and lies at the very core of modern design. These are the two basic interactions needed for a NUI, Touch, or even a Windows based system. The first is easy, intuitive, usually engulfed in a metaphor of some sense. The second is complex, learned, non-physical, and super-natural. The understanding of these two types of interactions are core to designing something for the modern world.

We have objects, which can be grouped into containers. We have manipulations, which can be contained inside of a gesture. The simplicity is liberating.

By a lucky coincidence, the acronym also bears very similar pronunciation and essence to Occam’s Razor. The simplest answer tends to be the right one.

Occam’s razor (or Ockham’s razor^[1]), entia non sunt multiplicanda praeter necessitatem, is the principle that “entities must not be multiplied beyond necessity” and the conclusion thereof, that the simplest explanation or strategy tends to be the best one. The principle is attributed to 14th-century English logician, theologian and Franciscan friar, William of Ockham. Occam’s razor may be alternatively phrased as pluralitas non est ponenda sine necessitate (“plurality should not be posited without necessity”).[2] [via Wikepedia]

I hope you love this acronym as much as I do. Thanks for reading and feel free to comment.