Toolbar Tooltips v2.0

[SkyFrontier]

Considering the recent changes as

Code: Select all

v8.80.0103 - 2010-02-06 18:23
    + Toolbar: Added button "Find by Tag".

Code: Select all

v8.80.0101 - 2010-02-05 12:18
  %%% Fast Tag Search.

and

Code: Select all

v6.30.0012 - 2007-09-15 12:00
      I also plan to add a "find-the-setting"-tool in form of a find-as-
      you-type technology.

I envisioned the benefits of a new approach on Tooltips:

1) They could be user defined, leading each user to easily define localization and comments on tools's usage;

2) CTBs could benefit as one could do the following:

"Program 3.5|E:\Programs\Program.exe" open "E:\Programs\Program.exe"; "A longish comment to tell briefily what the program/script can do!";

3) They could take usage of the search facility as showed in Tags Finder (v8.80.0103).

What about...?

[zer0]

2) CTBs could benefit as one could do the following:

"Program 3.5|E:\Programs\Program.exe" open "E:\Programs\Program.exe"; "A longish comment to tell briefily what the program/script can do!";

At this point, tooltips stop being tooltips and become infotips. Besides, "long-ish" and "briefly" sort of contradict each other Also, one can already provide custom tooltips for CTBs. Not for drop down list from a CTB, but then a list's entries can be described in sufficient detail to make tooltip/infotip redundant.

[SkyFrontier]

"A longish comment to tell briefily what the program/script can do!"

That was the idea!!!
Long in terms of a tooltip. Brief in terms of what a program can do.

The problem with

Code: Select all

"Program 3.5|E:\Programs\Program.exe"

vs tooltips is that using the comment ("Program 3.5|" section) as a tooltip can lead to a less than ideal way to keep GUI organized. Tooltips only will be seen on mouse hover. A width long toolbar button will always be seen when clicking a single button which needs often to be clicked. Disgusting, I'd say.

[zer0]

Long in terms of a tooltip. Brief in terms of what a program can do.
The problem with

Code: Select all

"Program 3.5|E:\Programs\Program.exe"

vs tooltips is that using the comment ("Program 3.5|" section) as a tooltip can lead to a less than ideal way to keep GUI organized. Tooltips only will be seen on mouse hover. A width long toolbar button will always be seen when clicking a single button which needs often to be clicked. Disgusting, I'd say.

I'm still not with you How can a tooltip be long, but brief? Also, shouldn't the caption for main CTB & command name provide all the clarification necessary? Offering customizable infotips for drop down CTB menus that already provide 2-level description seems a bit excessive

[SkyFrontier]

...free your mind, my dear! lol
I think on those buttons as SINGLE buttons, while you seen to think on them as functions of the main CTB to which they belong.

Think on the real thing:

Code: Select all

[CTB 1]
"Program 3.5|E:\Programs\Program.exe" open "E:\Programs\Program.exe"; "A longish comment to tell briefly what the program/script can do!";
"ASTRA|E:\Programs\astra.exe" open "E:\Programs\astra.exe"; "Astra is designed to inform you on PC hardware";
"the GIMP|c:\Program Files\gimp.exe" open "c:\Program Files\gimp.exe"; "Use this as an alternative to Corel";
"CorelDRAW|c:\Program Files\Corel 9\draw.exe" open "c:\Program Files\Corel 9\draw.exe"; "Remember to save this files on your USB and print them right after";
"To-Do List|D:\Documents\To Do this Week.docx" open "D:\Documents\To Do this Week.docx"; "Print this when arriving home!!!"

Can't think quickly on a script example to add but you got the idea...
Those comments can act as little reminders for ongoing tasks.
For professionals who live in a hurry, this can be very useful - on another topic, I posted:

Code: Select all

Can the favorites folder/files be searched and displayed in Find results, so with little effort we could apply tags on them and later have them search-able by the new feature?

v8.80.0103 - 2010-02-06 18:23
    + Toolbar: Added button "Find by Tag".
v8.80.0101 - 2010-02-05 12:18
  %%% Fast Tag Search.


With further improvements, one could have sets of favorites and have them stored anywhere in XY folder - and easily switch between those sets according to a task being performed in a given time!

Now I see that this can be integrated with that, so when switching from a set of favorites to another, one can also have those little reminders that he could easily update accordingly - put in a thumb drive and continue his work in another computer or in a train from work to home on his laptop. And quickly locate any related programs/documents found via this new " Search tootips" function. And have XY "translated" to a work colleague who doesn't know a word in english. All easy, all quick.

How can a tooltip be long, but brief?

Think relative. lol
But I guess you can understand now.

[SkyFrontier]

self:
I think on those buttons as SINGLE buttons, while you seen to think on them as functions of the main CTB to which they belong.

-that's why they are ONE level of description, and not two. In fact, the "Button Name|" section still remain as a NAME and not a description. Also, consider the aforementioned matter of taste - it just doesn't look good using that NAME as a description as the button dropdown list turns really ugly. Reminds me the days I didn't know I could add icons and names (labels) to each command/button.

[zer0]

...Those comments can act as little reminders for ongoing tasks.
For professionals who live in a hurry, this can be very useful...

As a professional, and I do consider myself to be one, I do not feel that I need those little reminders. And if main CTB and menu captions aren't enough to tell me what that command is all about then I'd work on refining them instead of introducing another layer of complexity -- that is a more efficient approach. In addition, it's rather uncommon, in my experience, for drop-down menus to have captions. Don't get me wrong, I am not being a devil's advocate just trying to rationalise and provide another perspective

[SkyFrontier]

-not IT professionals. Consider the people migrating from Windows Explorer and you'll probably buy the entire idea. That's what I have in mind - broadening XYplorer potential audience with (I believe) small steps.

[zer0]

-not IT professionals. Consider the people migrating from Windows Explorer and you'll probably buy the entire idea. That's what I have in mind - broadening XYplorer potential audience with (I believe) small steps.

But it's an inefficient way to try to appeal to a wider audience. It is also not encouraging a good practice of being concise and succinct. Further, I doubt that such a functionality will be attractive to people migrating from Windows Explorer, since it's atypical for its menus to have additional info tips. Buttons? Sure. Menus stemming from buttons? Definitely not

[SkyFrontier]

They would not be MENUS, zer0. Just tooltips (infotips, doesn't matter), user define-able, just to not be an annoyance as the current "Name|" feature potentially turns out to be if used for describing what a button does.

[zer0]

They would not be MENUS, zer0...

You misread what I said. I didn't say that they would be menus, but rather info tips for menus triggered by clicking a CTB.

...Just tooltips (infotips, doesn't matter)...

With all due respect, a fact that you are so hasty in grouping two different, albeit similarly sounding, UI concepts together is somewhat indicative that you may not potentially be very well versed in matters of GUI design and elements. Therefore, it may potentially be more difficult for you to comprehend such intricacies and understand why info tips for those menus are unorthodox, uncommon and represent low value for migrating users.

...just to not be an annoyance as the current "Name|" feature potentially turns out to be if used for describing what a button does.

If worded concisely and succinctly the menus can be effective and would not need info tips. The first step should always be to make the most of the existing approach before introducing another layer.

[j_c_hallgren]

With all due respect, a fact that you are so hasty in grouping two different, albeit similarly sounding, UI concepts together is somewhat indicative that you may not potentially be very well versed in matters of GUI design and elements. Therefore, it may potentially be more difficult for you to comprehend such intricacies and understand why info tips for those menus are unorthodox, uncommon and represent low value for migrating users.

zer0, I know you've got a good amount of time here and have mostly dealt with a lot of people quite nicely...but...I believe you could have said the same thing without making what could appear to be condescending comments about his experience level...I may have done it also on occasion but I try to refrain from that style if at all possible...it makes the forum a bit unfriendly, ok? Just my $.02.

Having said that, I do agree with the basic stmt that these type of tips would be rather unusual and wouldn't likely be of that much use to migrating users especially those coming from other non-WE FM's.

[SkyFrontier]

Sorry if I was unable to translate what I have in my to describe it properly into your language.

Code: Select all

zer0:
...but rather info tips for menus triggered by clicking a CTB.

I'm just talking about a simple mouse hover tool/infotip.
Can't see how that would hurt rather I just see benefits on it, being:
-user define-able;
-can be used as a little and quick reminder on different sets of buttons when dealing with different tasks;
-can also be used as a translation tool aiming all those people out there who doesn't speak english. Or computing. They would just need to hover the buttons and see a little hint put there by another person who do.

As an image worth a thousand words, below there two thousand words which may convince you that the unorthodox method is the current one. Consider also that a clicked CTB that shows a list of CTBs still remains as an extension of the toolbar, thus being that info/tooltip the first layer of info while CTBs, despite hidden under another CTB, are nothing more than GUI elements, not info elements.

[TheQwerty]

So I understand the desire to have a small description for menu items (especially from scripts), but why reinvent the wheel by using a tooltip? It's standard behavior for the status bar to show a short description of the focused menu item, and I don't see any reason not to use it here.

XY already supports this method as is evidenced by the shell's context menu. I still think Don should take a week and add descriptions to the main menu as well, but it's clearly a low priority.


That said I'd rather we avoid adding more to the "Caption|Icon|State : Label" line.. A more appropriate syntax for scripting would be an additional commenting format ("///" or "//*" or similar) and then the comment immediately following the label string (it could start on the same line or the next non-empty one) is used as the description in the status bar.

So we could have:

Code: Select all

"Awesome Script" ///This script does awesome stuff.
   Sub("_doAwesome");
"Super Cool Script"
   //* This is super cool! *//
   Sub("_doSuperCool");
"Sucky Script" //* This script sucks! *// Sub("_doNothing");

Which would display the menu, and when you mouse over/focus an item the description comment would be shown in the status bar.

[PeterH]

Add a new comment that's not meant as a comment? Sounds a bit strange, I think.

Isn't this the place to use some kind of delimiter?