터치 시대의 툴팁

터치 시대의 툴팁

---

툴팁은 애플리케이션을 알 수있는 매우 유용한 인터페이스 패러다임입니다. 시각적 컨트롤과 해당 컨트롤과 관련된 응용 프로그램 별 작업 간의 매핑입니다. 사용자는 마우스 포인터를 가져 가기 만하면 작업을 호출하지 않고 탐색 할 수 있습니다.

터치 장치는이 패러다임을 기본적으로 불가능하게 만듭니다. 이로 인해 앱의 사용성이 제한되어 경우에 따라 매우 신비하게됩니다.

터치 장치에 대한 툴팁 개념의 대체물이 있는지 알고 있습니까? UI 상호 작용에서 포인터 위치라는 자유도가 효과적으로 부족합니다. 이 커뮤니케이션 채널을 효과적으로 되 찾는 방법은 무엇입니까?

---

질문하는 사람에 따라 이해할 수있는 툴팁 이 필요한 인터페이스를 재 설계해야 한다고 말할 수도 있습니다 (참조 : Jef Raskin : The Humane Interface ).

사실, 도구 설명은 매우 구체적인 문제에 대한 해결책 입니다. 도구 모음에 표시되는 것과 같이 레이블이없는 아이콘 버튼입니다. 레이블이있을 때마다 사용하십시오. 특정 컨트롤이 수행 할 작업을 알려주 는 텍스트가 이미 있으므로 도구 설명을 제공 할 필요가 없습니다 .

더욱이 터치 인터페이스는 오늘날의 WIMP 인터페이스 모델에 잘 맞지 않습니다 . 많은 컨트롤이 마우스 포인터로 처리하는 것은 좋지만 손가락으로 사용하는 것은 불편합니다. 메뉴, 체크 박스, 라디오 버튼이 떠 오릅니다. 따라서 터치 인터페이스 의 인터페이스 패러다임 은 오늘날의 마우스 및 키보드 기반 인터페이스와 다소 다르게 보일 수 있습니다.

그래서 저는 여기에서 문제가되는 도구 팁의 부족이 아니라 지난 30 년 동안 컴퓨터와 상호 작용하는 새로운 방법을 많이 탐구하지 않았다고 생각합니다 (기본적으로 Doug Engelbart 와 Xerox PARC가 수행 한 연구 이후가 아닙니다). 60 년대와 70 년대).

터치 입력은 유사하다 충분히 이 것을 좀 대부분의 목적을 위해 사용할 수 있습니다. 그러나 터치없는 위치 구성 요소뿐만 아니라 정밀도도 부족합니다. 기본적으로 모든 터치 입력은 무언가를 터치하고 드래그하는 것입니다. 더블 탭조차도 어렵 기 때문에 우리에게 정말로 필요한 것은 터치 인터페이스를위한 UI를 디자인하고 만드는 방법에 대한 근본적인 변화입니다.

이 중 일부는 iPhone과 같은 전용 장치에서 볼 수 있습니다. 마우스 포인터도 키보드도없고 터치 만 있는 플랫폼이기 때문입니다 . 즉, 가능한 모든 상호 작용 방법과 함께 사용할 수 있어야하는 UI를 구축 할 필요가 없습니다 (현재 Windows의 전염병에 문제가 있습니다. 저는 멀티 터치 노트북을 가지고 있지만 많은 작업에서 터치가 작동하지 않습니다). 하지만 하나만. 그러나 "정상적인"소프트웨어와 컴퓨터를위한 범용 솔루션은 현재로서는 꽤 멀다고 생각합니다.

따라서 UI를 디자인 하는 방법 에 대해 조금 다르게 생각하는 것이 좋습니다. 앞서 말했듯이 (Alan Cooper의 About Face 에서 읽을 수 있음 ), 도구 설명은 레이블이 없거나 공간이 충분하지 않은 컨트롤에 레이블을 지정하기위한 것입니다. 여기서 주요 사용 시나리오는 도구 모음입니다. 그러나 터치 용으로 설계된 인터페이스는 어쨌든 모든 컨트롤을 더 크게 만들 것입니다. 밀접하게 함께 그룹화 많은 작은 아이콘, 심지어 터치 입력으로 사용할 수있는 통증이있는 경우 는 정밀도가 부족 간단하기 때문에, 당신은 도구 설명했다.

---

여기를 읽으면 생각이 생겼습니다. 툴팁은 일반적으로 텍스트가없는 버튼에 레이블 을 부여하는 데 사용 되지만 인터페이스에서 사용 가능한 공간이 축소되어 더 많은 정보를 제공하는 좋은 방법이기도합니다. 때로는 상황에 맞는 도움말이나 단일 위젯에 대한 자세한 설명을 제공하는 데 사용됩니다.

모든 GUI 요소에 한 번의 클릭 공통 동작을 제공하고 두 번 클릭에 대한 툴팁을 제공하는 Tchalvak 의 아이디어 는 장점 이 있으며 요소에 관계없이 많은 사람들이 보는 모든 것을 두 번 클릭하는 데 익숙하기 때문에 다소 발견 할 수 있습니다. .

하지만 ?몇 년 전 너무 인기가 많았던 이전 버튼을 떠올 렸습니다. 한 번 클릭하면 커서가 물음표로 바뀝니다. 위젯을 클릭하면 작은 도구 설명이나 정보 풍선이 표시됩니다. 터치 인터페이스에서 쉽게 사용할 수 있다고 생각합니다. 커서가 없기 때문에 사용자가 도움말 제공 모드 에 있음을 알리는 또 다른 시각적 신호를 사용자에게 제공해야 합니다. 화면의 색조를 변경하고 작은 텍스트를 제공 할 수 있습니다. ?툴팁을 가져 오기 위해 다른 위젯을 누른 상태 에서 버튼을 눌러야하는 멀티 터치로 수행 할 수도 있습니다 (손가락으로 너무 가려지지 않도록 약간 분리 된 위치에 표시되어야 함).

그러나 프로그래머가 툴팁을 가질 수 있도록 동일한 기술 기능을 유지할 수 있더라도 의도 에 대해 생각해야합니다 .

나는 당신이 작은 화면에 직면했을 때 확장 된 도움을주기 위해서만 그것을 사용할 것입니다. 그렇지 않으면, "창"의 맨 아래에 항상 도움말 영역을 보이게 할 것입니다 (모든 종류의 정사각형 모양의 io 인터페이스 참조). , 마우스 오버시 일부 환경 설정 창에서 수행되는 것처럼 선택한 위젯에 대한 자세한 설명 및 / 또는 도움말을 제공하기 위해 컨텐츠를 변경합니다.

결론적으로 우리는 사용하기 쉬운 툴팁을 제공 할 수 있다고하더라도 그 안에 무엇을 넣을 것인지 생각해야합니다. 터치 인터페이스에서는 이해하기 위해 툴팁 이 필요한 모호한 레이블 버튼을 넣지 않고 상황에 맞는 고급 도움말 및 문제 해결을 제공하는 데 사용합니다.

---

터치되는 문자를 반영하는 화면 키보드의 툴팁은 툴팁이 터치 인터페이스에서 매우 유용하다는 증거입니다. 모바일 웹 페이지에서 어떻게 구현할 수 있는지 알아보기 위해이 기사를 찾았습니다.

---

이 문제에 대한 몇 가지 해결책을 생각할 수 있습니다.

1) 툴팁이 필요하지 않도록 앱을 디자인하십시오. 버튼에 텍스트를 넣거나 (작지만) 간단한 아이콘을 사용하거나 "처음 버튼 사용"에 "도움말 풍선"표시 (사용자가 버튼의 용도를 알게되면 "다시 표시하지 않음"옵션 포함)

의 이벤트 2)에 응답 터치 업 , 터치 다운하지. "도움말"풍선을 표시하여 0.5-1 초 동안 누른 터치에 응답합니다. 도움말 풍선이 표시되면 버튼의 일반 이벤트가 터치 업시 실행되지 않습니다 (따라서 도움말을 찾는 사용자가 작업을 트리거하지 않음).

3) @voyager가 제안한 "물음표"드래그 앤 드롭 패러다임을 사용합니다 . 또는 사용자가 먼저 물음표를 "탭"한 다음 도움이 필요한 항목을 탭하도록합니다.

---

인터페이스에서 사용할 수있는 다소 "모호한"기능에 대한 간략한 설명을 제공하는 영구 레이블이 작업이 수행 될 때 상황 별 알림 메시지와 결합됩니다.-예 : 사용자가 데이터를 수정합니다 => 알림이 나타납니다. 이 알림 중에 잠시 강조 표시되는 버튼입니다.

---

내가 찾을 수 툴팁이 매우 도움이 와 나는 그들이 매우 제한이라고 판단하는 좋은 UI 디자인에 필요하지 않은 주장 모두를 생각한다.

당신에게 몇 가지 아이디어를 제공하기 위해 ...

일반적으로 좋은 UI 디자인은 (삶의 다른 많은 것들과 마찬가지로) 특정 사용 시간 동안 효과적이고 효율적인 디자인 입니다. 효과적이란 기대 하는 일을 할 수 있다는 뜻입니다 (예 : 휴대폰으로 전화 걸기 ). 효율적이라는 것은 최소한의 사용자 노력으로 수행 할 수 있다는 의미입니다 (예 : 숫자를 입력하고 일부 메뉴를 먼저 탐색 할 필요없이 "다이얼"버튼을 누르기 만하면 됨 ). 특정 기간이 지나면 처음 사용하는 경우 또는 그 반대의 경우에는 그와 그 사이의 모든 것을 알게 된 후 최적이 아닐 수 있음을 의미합니다 (예 :공항 터미널 화면은 Adobe Premiere와 같은 전문가 용 비디오 편집 소프트웨어보다 일회성 사용자 "더미"에 더 초점을 맞춰야 할 수 있습니다.

이것은 툴팁이 상황에서 매우 도움이된다고 말했습니다.

• 디자이너로서 특정 UI 영역 내에서 일부 GUI 기능에 대한 모든 세부 사항을 원하거나 설명 할 수 없습니다.
  • 유용성, 사용 가능한 전체 공간 등으로 인해
  • 예를 들어 위의 예를 들면 노인을위한 간단한 모바일 통화 시나리오 에서도 도움이 될 수 있습니다 .
    • 그것은 우리가 "괴상한";-) 사소하다고 생각하는 많은 것들에 익숙하지 않을 수 있습니다.
    • 그리고 그들은 우연히 쇼핑 핫라인에 전화를 걸고 마침내 1000 EUR 진공 청소기 없이는 살 수 없다는 것을 확신하게 될 두려움없이 주위를 클릭하도록 장려해야합니다.
    • 이 경우 원 클릭 툴팁 패러다임이 의미가 있습니다.
      • 일반적으로 나는 그것을 추천하지 않을 것입니다
• 사용자로서 제공된 일부 동작 / 버튼 등의 의미를 잘 모릅니다.
  • 다시 이전 예제를 고수하면 숙련 된 Adobe Premiere 사용자 라도 사용 가능한 모든 모듈 / 플러그인의 특정 기능 영역에 대한 모든 세부 정보를 기억하지 못할 수 있습니다.
    • 예 : 대부분의 경우 비디오를 자르고 오디오 설정을 거의 조정하지 않는 경우
    • 다른 사람들은 그 반대의 경우도 마찬가지입니다.

이제 터치 인터페이스의 한계와 가능성으로 돌아갑니다 ...

• :-) Hover: I recently saw somewhere, that some devices can recognize the finger before it actually touches the touchpad or it differentiates between the touch intensity (e.g. only very soft touch). This would seem the perfect pendant to the established tooltip functionality on WIMP interfaces to me
  • of course it would be dependent on the touch hardware capabilities
• :-) Zooming UI: I actually like the Zooming UI concept mentioned by Joey as well
  • the concept of using only two fingers is already quite common for zooming and the idea is quite intuitive, e.g. showing more details, like typical tooltip infos, on zooming on a button
  • but it admittedly introduces the problem of differentiating between I like to have a tooltip for this button and I like to zoom the whole area in/out, not having the button tooltip near my fingers in mind
    • although I would think that typical tooltip-enabled areas are quite different from zoomable areas in general
      • e.g. some PDF readers content area is generally visually quite separated from e.g. some toolbar (button)
    • tooltips for non-action areas, like some text area are again not trivial to handle or would require some more "gesture differentiation agreement"
  • from the development perspective it seems also quite robust
• :-) QM: the question mark click or drag'n drop feature solution could be a good alternative too
  • having a lot of these everywhere on the screen seems stupid, especially when they have to aquire a certain space to be clickable/draggable
  • having one to drag everywhere seems better, but again would require the space for it on the screen
  • from a development perspective I would find it at least a little difficult as a general solution because the drag'n drop is a common feature and differentiating in a UI between here comes some tooltip drop I have to handle and here comes some file drop I have to handle (e.g. on a file upload area) may not be easy or at least common ground to existing frameworks
• :-| Hold: the idea to trigger the tooltip if the user does not release the push after a certain period of time, e.g. 1s, seems to be a 2nd best solution to me
  • it is already a common feature in some scenarios, as the mentioned on-screen keyboard popups (e.g. resting on an "o" and getting a list of choosable alternatives like oóòô)
  • again it requires some trust from the user, that it won't execute the areas action on the release
  • on some buttons it may be difficult to differentiate what the user wants to do, e.g. clicking on a "+" sign/button to increase some number and holding it down to increase more or faster may contradict this tooltip functionality
  • for non-action areas a push-hold action may not seem intuitive
  • from a development perspective it could be rather easy although some behaviour contradictions like mentioned may exist
• :-| SCT/DCA: the solution single-click showing tooltip, double-click executing action I could imagine to be useful in limited scenarios
  • e.g. the mobile call for some elderly or dummy people mentioned above or where the action should be kind of protected from unconcious or unsure usage
  • again the development perspective looks robust again here
• :-/ SCA/DCT: the solution single-click executes action, double-click shows tooltip seems very strange to me
  • if you are not sure about some functionality you would hesitate to click a button at all, and surely not twice, especially if you cannot be sure if you can expect this behaviour
  • the development perspective could be problematic here:
    • after which time is a double-click two single-clicks?
    • what if the second click is not recognized or cannot be recognized, e.g. because some other popup comes up, the UI layout changes suddenly, the user did not carefully aim, ...
• :-/ Other Gestures: using other gestures mentioned or I could think of, like drawing a question mark over the to-be-tooltipped-area, swiping over the area in some way etc.
  • because this seems no common ground I wouldn't like it because it also may block other functionality otherwise available

---

Well, the benefit of the tooltip is that it adds an overlying stage of (very minor) information before an action occurs. So it seems to me that adding that layer back in via a "double click" to perform the action with a "single click" to display information would be an equivalent idea.

I think that we've all seen the movies with the future screen interfaces where someone touches the screen and it splays out a geometric shape of information around that touch. Why not use that concept, have the first touch expand the information about the action as a useful in-page tooltip, and then the second click on the same spot would confirm/perform the action.

If not "click-on-item-shows-tooltip-second-click-performs-action" how about proximity? If you want information about a UI widget, with enough spacing, you could touch next to the widget and receive information on it, touch -on- the widget and perform the action.

Tooltips provide so little information, generally (pointer vs. hand, text-tool-tip, hover bolding) that I think that you could also just duplicate the tooltip information by paying close attention to user action history. If they've been clicking on two thing more frequently than another thing recently, have the default tooltip & added value & emphasis appear for those few more frequently clicked things instead of others.

Edit: Also, thinking about it more, drag in a space that doesn't need scrolling or the like seems like an alright trigger for tooltip information. Take the iphone's keyboard, for example. Each letter has a tooltip while you drag it, whereas the letter itself is actually activated when you release. Aids in repositioning precision.

Beyond that, I think that specifics come into play. Are you talking laptop tablet? phone touch interface with very limited space? I think available space plays a large part in how you have to do things with a touch interface.

---

What about touch and hold? I think that would be a fairly simple interface rule in terms of both usability and implementation. Like a lot of things to do with usability though it will be hard to say until any one idea has been around for a bit of time to see it used in a bunch of different contexts...

---

My answer isn't perhaps so practical, but...

The problem would be solved if apps all supported undo functionality, and people got used to knowing that they could ALWAYS reverse any action.

As Andreas says, "if you are not sure about some functionality you would hesitate to click a button at all".

But with undo as the safety net, there can be more "doing", and less "hesitate, worry, find out what will happen before I tap... tap".

This is one of the reasons why the Back button is so popular, and Android even made it operating system-wide.

Unfortunately (here are the impracticalities...)

• building reliable pervasive undo is far harder than tooltips
• enough apps need to support it to change the mindset of all users (ha!)

---

This may be helpful:

Google Material Tooltips

They say tooltips are

Summoned by:

• Hovering over an element with a cursor
• Focusing on an element with a keyboard (usually the tab key)
• Upon touch

It doesn't have a lot of information about mobile only. About the only one you can meet is the on touch, which is frustrating if your button does something, you don't want to touch it before you know what it does. Long press may work but some apps require long press for other functions, it's a used UX path and a user would not expect long press tool tips unless you tell them.

I am thinking that tooltips may just not work the wonders on mobile that they do on desktop. Without hover, you need another reserved way to quickly remind or show a user what an icon or button does.

The best thing I can think of is the help mode. Pressing settings then 'help', displaying short card on the bottom saying something like 'click an element for help' and a 'dismiss' button. Then hitting tool tipped elements will show you a the extra information for them.

I see above this mentioned but another modern use case for this are games. They are often designed with a joystick in mind, which means they have roughly 14 buttons to work with, yet most are taken up by game functions.

In RPGs they typically have complex stat screens that are guaranteed to be unknown by the player (often they invent new systems for each game) full of numbers that are important, but players don't know. Many of them let you hit the select button to get into a tooltip/explanation mode.

This may well work in an app that is complex enough to require tooltips on mobile and is the only pattern I can see right now that isn't so far outside common ux designs.

---

To paraphrase Einstein, a touch should be as simple as it needs to be, but no simpler.

The underlying problem here is not touch, but state. What state is the object in when you touch it? Does touch change its state? How is the change in state reflected to the user?

From the design perspective, trying to encompass all actions in a single touch will work only in the simplest cases. For any more useful application, a first touch may change state, and that state can be reflected by changes in an object's image, by tooltops (even transient tooltips that go away after a set time), or by other means. Touching a selected object should have different meaning than touching a non-selected object. This needs to be a discoverable aspect of the interface.

---

Keeping in mind that hover tooltips are terrific help for beginners and they need no action to learn for them because beginners are always slow and they pop up while insecure moving the cursor. On the other hand, they are excellent because they do not slow down the power users.

For tablets I would pick up the idea of the question mark but add some more complexity:

1) 물음표를 탭하면 "도움말"모드로 전환됩니다. 2) 그런 다음 해당 컨트롤을 탭하면 도구 설명이 표시됩니다. 3) 같은 컨트롤을 다시 탭하면 도움말 모드가 종료되고 컨트롤이 수행해야하는 작업이 실행됩니다. 4) 다른 컨트롤을 탭하면 툴팁이 표시되고 도움말 모드가 계속 켜져 있습니다. 5) 물음표를 다시 탭하면 도움말 모드를 종료 할 수 있습니다.

참고 URL : https://stackoverflow.com/questions/1737773/tooltips-in-the-era-of-touch