Toolbar Event

[utopiomania]

I finished a toolbar in an app a few days ago and used imageToolbarButtons with toolbarTooltips
on them.

You can see what most the buttons is supposed to do right away, and usually click them
before the tooltip appears, but they're a nice addition if someone wonders what a button is for
anyway.

You could also use images with both a nice icon and text on them too of course.

[r_hyde]

milan1612 wrote:
That's Microsofts opinion

It's their operating system...

Excellent. We should all just give up and let Microsoft write all the software too, then. After all, they're the only ones with the right idea on how to do things :roll:

Microsoft has but given us a palette and canvas; it is up to us designers to decide what picture to paint. Sure, there are preconceived notions about what makes "good" art, but many of the greatest artists of all time are the ones who willfully, skillfully went against those notions. I've seen FANTASTIC interfaces that use tool help messages on the statusbar. I'm sorry that you haven't.

if you can't see what the toolbar buttons does from their image, then the image is not good enough and might as well be replaced with a text-only button.

Haven't you just made the argument against tooltips, then? You must think that any UI designer who provides those is a lazy hack for falling back on that useless crutch. But wait! Almighty Microsoft says tooltips are OK...what a conundrum!

I'm having a bit of fun at your expense, Trond, so I'm sorry if this has rubbed you the wrong way, but I do wish some of the folks around here would try to keep a bit more of an open mind and not be so preachy about the "right way" to do things, especially very subjective things like interface design.

I've spoken my piece, I thank you for participating in the discussion. The OP's question is answered and I'll not hijack this thread any longer

[Trond]

I'm having a bit of fun at your expense, Trond, so I'm sorry if this has rubbed you the wrong way, but I do wish some of the folks around here would try to keep a bit more of an open mind and not be so preachy about the "right way" to do things, especially very subjective things like interface design.

Interface design is not subjective. Interface design decisions should be made by knowledge of how users act in response to specific user interfaces, not what you think is a "good idea".

UI blooper 47:

Engineers often assume that if a device or software program displays information, users will see it and act
accordingly. Or they assume that even if users miss the information initially, they will eventually learn to
notice it. For example, developers of GUI-based software for personal computers often assume that all
they need to do to ensure that users see a status indicator, warning message, input field, or computed
result is put it somewhere on the computer screen. Such assumptions are just plain wrong. They reflect a
lack of knowledge about how people perceive and think.
...

When you place the description of what a command does on the other edge of the monitor most people won't notice. It's as simple as that. I notice it, and I think those people are stupid who don't, but as a matter fact, they don't. And the user interface is for the users, not for the programmers.

If you rely on statusbar text to tell what a toolbar button does it's a simple fact that people simply don't notice the statusbar text. They just don't, even though it's right in front of their eyes. So, if you rely on statusbar text for it, then the user interface won't be usable for many users but me and you. So better make these statusbar texts unnecessary for normal users to use and understand the applications. And if normal users can understand the application then we should too.

Tooltips are different because they appear at the correct place. People actually notice them.

On the Mac there's a nice feature called balloon tooltips or something. They look like the Windows XP ones, but behave differently. When you turn them on, they act like tooltips, but shows up without a delay. Then you turn them off again when you've learned the interface. (Of course the normal tooltips continues to appear after a delay.) This is a much better solution.

Now, don't be so open minded that your brain falls out.

[r_hyde]

Darn, I was hoping I could get by without adding more to this, but I can't resist

I think you've got this wrong, and I think the source you've quoted doesn't disagree with me (though on its face it does seem to do so). Interface design is a bit subjective, though there are sensible guidelines. It's true that a designer should not assume the user will notice a status message, and that's why one must use them correctly*. If you just throw them out entirely on some ill-conceived principle you're missing out on a potentially useful design tool because you couldn't bother to learn how to use it effectively. And, as the UI blooper article points out, you can't just throw them in willy-nilly because you think they look nice--there has to be a well-thought-out design behind it. The article is not a condemnation of any UI design element, it is a caution to be aware of why you should use certain things, and also when and why not to do so.

If user interface design were totally objective, there would be no use for UI designers. We exist because it's as much an art form as it is a science. If you're wondering why I say 'we', it's because interface design happens to be how I earn my living. If you don't think I know what I'm talking about, that's fine, but please don't tell my boss


*by correctly, I mean as a seamless and well-conceived part of the application's design paradigm.

[Trond]

If user interface design were totally objective, there would be no use for UI designers.

It is almost totally objective, but to find out what works you need to test it on users. Knowing the result of previous research and doing testing should be the job of UI designers. And using a message on the other side of of the screen has been tested and it does not work.

[Dare]

This is actually very interesting.

Keep the debate going!


And perhaps tackle the issue of too much user interface. Screens so "noisy" that you run away screaming. (Designers making sure you see everything even if it means you don't see much of anything as they cram it all in. MS is good at that.)

[milan1612]

Screens so "noisy" that you run away screaming. (Designers making sure you see everything even if it means you don't see much of anything as they cram it all in. MS is good at that.)

That's another thing I love PB for. Look at the IDE, it's so beautiful
but also very tidy and work-oriented. I just enjoy using it

[Dare]

Your avatar tells a story ..

[r_hyde]

...using a message on the other side of of the screen has been tested and it does not work.

I recall this being the conclusion that Microsoft designers came to, and a few non-Microsoft applications picked up on. However, it's my considered opinion that the jury is (or should be) still out on this. I contend that designers in this camp simply haven't experienced or tested with a design that uses it well. Microsoft has made notoriously inane use of their statusbar control, and it is no wonder that their usability testing confimed its uselessness.

I think it's important that we dispatch what may be a misconception in this dialogue--that is, what we are referring to when we say something like "status message" or "statusbar". Microsoft provided us with the statusbar common control in Windows 95 (iirc). Most of the time, when we talk about a statusbar, this is what we're probably referring to; it's almost certainly what the OP was referring to. I'm not that rigid in my definition, though, and I think a statusbar can be integrated into an interface in different ways. In other words, it need not be miles away from the toolbar, down on the edge of the screen, if you don't want it to be. If you use it for status messages and the like, it's still a statusbar, innit? Integrating it in a way that makes sense to the application is what I mean by using it properly, as a concept.

That out of the way, I can cite examples of award-winning software, which are regarded as highly usable and which make heavy, heavy use of the concept of flyby help. All Avid products are a fine example of this, but in particular I point to Softimage XSI (I betray a bit of my history in 3D animation here). It's prohibitively expensive and not appropriate for the casual user, but I believe there's a demo you can download if you really want to get an idea of what I mean. Also, there's the Opera browser, which in its default configuration integrates the statusbar into the toolbar area, making for an elegant user experience.

Another fine example is a product for which development and sales now unfortunately seem to be discontinued: Nichimen/Izware's Mirai. Also a 3D animation and rendering package, it made novel use of context-sensitive right-click menus which would display statusbar messages indicating the different actions if the user left-, right-, or middle-clicked the menu item. Everybody who used this software could not help but be impressed with its ultra-elegant design (in fact it had a cult-like following), and its use of statusbar messages was an important part of that experience. You can't download a demo of it, but if you want to see something that approaches its style, there's a free 3D modeler called Wings3D that you can check out. It's not quite as good, but it conveys the idea.

Finally, I should perhaps note that as a professional I have yet to design an application that even uses the Windows common statusbar control, let alone for the (in your opinion) deprecated usage we're discussing here. I haven't used it because I haven't yet designed an application which justified or required its use. I'm willing to keep an open mind about it, though, and I think my brain will remain safely in place

[Trond]

...using a message on the other side of of the screen has been tested and it does not work.

I recall this being the conclusion that Microsoft designers came to, and a few non-Microsoft applications picked up on. However, it's my considered opinion that the jury is (or should be) still out on this. I contend that designers in this camp simply haven't experienced or tested with a design that uses it well. Microsoft has made notoriously inane use of their statusbar control, and it is no wonder that their usability testing confimed its uselessness.

It's not Microsoft who have tested it (they probably have too) (they do insane things all the time, as you point out), it's Jeff Johnson ("Over 28 years experience in computer industry designing, implementing, evaluating, and testing user interfaces at Cromemco, Xerox, US West, Hewlett-Packard, and Sun Microsystems before becoming a consultant.") http://www.uiwizards.com/aboutUs.html

I think it's important that we dispatch what may be a misconception in this dialogue--that is, what we are referring to when we say something like "status message" or "statusbar". Microsoft provided us with the statusbar common control in Windows 95 (iirc). Most of the time, when we talk about a statusbar, this is what we're probably referring to; it's almost certainly what the OP was referring to. I'm not that rigid in my definition, though, and I think a statusbar can be integrated into an interface in different ways. In other words, it need not be miles away from the toolbar, down on the edge of the screen, if you don't want it to be. If you use it for status messages and the like, it's still a statusbar, innit? Integrating it in a way that makes sense to the application is what I mean by using it properly, as a concept.

In one way I agree. Placing a "status bar" so that it is just beside the toolbar and using it for this purpose is actually a great idea, better than tooltips and anything else. However,:

If you use it for status messages and the like, it's still a statusbar, innit?

Outside of Windows, yes. However, a status bar in windows is defined to be at the bottom of the window, else it's not a status bar (according to Microsoft documentation).

So then we sort of agree, except you were talking about status bars as a bar that shows status and I as a horizontal window at the bottom of a parent window in which an application can display various kinds of status information.

[Trond]

Here it is:

Code: Select all

; License: BSD + Do not put statusbar at bottom hehe

Global Dim ToolBarTexts.s(7)
ToolBarTexts.s(1) = "New document"
ToolBarTexts.s(2) = "Open document"
ToolBarTexts.s(3) = "Save"
ToolBarTexts.s(4) = "Print"
ToolBarTexts.s(5) = "-"
ToolBarTexts.s(6) = "Find"
ToolBarTexts.s(7) = "Replace"

Procedure Callback(WindowID, Message, wParam, lParam)
  Protected Result = #PB_ProcessPureBasicEvents
  If Message = #WM_NOTIFY
    StatusBarText(0, 0, ToolBarTexts(SendMessage_(ToolBarID(0), #TB_GETHOTITEM, 0, 0)+1))
  EndIf
  ProcedureReturn Result
EndProcedure

OpenWindow(0, 0, 0, 512, 384, "", #PB_Window_ScreenCentered | #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_MaximizeGadget)
OpenWindow(1, 0, 0, 10, 10, "", #WS_CHILD, WindowID(0))
CreateStatusBar(0, WindowID(1))
CreateGadgetList(WindowID(0))
CreateToolBar(0, WindowID(0))
  ToolBarStandardButton(0, #PB_ToolBarIcon_New)
  ToolBarStandardButton(1, #PB_ToolBarIcon_Open)
  ToolBarStandardButton(2, #PB_ToolBarIcon_Save)
  ToolBarStandardButton(3, #PB_ToolBarIcon_Print)
  ToolBarSeparator()
  ToolBarStandardButton(4, #PB_ToolBarIcon_Find)
  ToolBarStandardButton(5, #PB_ToolBarIcon_Replace)
SetWindowCallback(@Callback())

Repeat
  Event = WaitWindowEvent()
  Select Event
    Case #PB_Event_SizeWindow
      If EventWindow() = 0
        ResizeWindow(1, 0, ToolBarHeight(0), WindowWidth(0), StatusBarHeight(0))
      EndIf
    Case #PB_Event_CloseWindow
      Break
    Case 675
      StatusBarText(0, 0, "")
  EndSelect
ForEver

[r_hyde]

[edit in response to your latest]
Hehe, that puts the idea across nicely! I'm tempted to break your imposed license out of spite, though

I think we are somewhat in agreement, though there is still one little bone of contention: I still don't think the Microsoft common statusbar control (the one at the bottom of the window) is a bad thing in and of itself, and I still maintain that it can be used well. I just think it's probably the exception and not the rule. I wouldn't discourage anyone from experimenting with it, for sure.

I feel like we can politely agree to semi-disagree on this issue, no?

[Trond]

I feel like we can politely agree to semi-disagree on this issue, no?

Yes.

BSD license allows you relicense it also.

[Kai]

Code: Select all

EnableExplicit

If OpenWindow(0, 0, 0, 250, 120, "ToolBar mit Hilfe in StatusBar", #PB_Window_Invisible|#PB_Window_SystemMenu|#PB_Window_ScreenCentered) <> 0
 If CreateToolBar(0, WindowID(0)) <> 0
  ToolBarStandardButton(0, #PB_ToolBarIcon_New)
  ToolBarStandardButton(1, #PB_ToolBarIcon_Open)
  ToolBarStandardButton(2, #PB_ToolBarIcon_Save)
  ToolBarStandardButton(3, #PB_ToolBarIcon_Properties)
 EndIf
 If CreateStatusBar(0, WindowID(0)) <> 0
  AddStatusBarField(250)
 EndIf
EndIf

Global L_TB_Hot.l
Global L_TB_HotOld.l

HideWindow(0, 0)
Repeat
 Select WindowEvent()
  
  Case #PB_Event_CloseWindow: End  
  
  Case 0
   L_TB_Hot = SendMessage_(ToolBarID(0), #TB_GETHOTITEM, 0, 0)
   If L_TB_Hot <> L_TB_HotOld
    L_TB_HotOld = L_TB_Hot
    If L_TB_Hot <> -1
     Select L_TB_Hot
      Case 0: StatusBarText(0, 0, "Erstellt eine neue Datei")
      Case 1: StatusBarText(0, 0, "Öffnet eine Datei")
      Case 2: StatusBarText(0, 0, "Speichert eine Datei")
      Case 3: StatusBarText(0, 0, "Einstellungen")
     EndSelect
    Else
     StatusBarText(0, 0, "")
    EndIf
   EndIf
   
   Delay(2)
 EndSelect
ForEver

[milan1612]

Thanks for the codes. I'll implement this feature in my current project.
Look at the first reply:

Toolbat buttons can't receive focus.

Once again something "impossible" has been solved