I have a help file for my program and was asked to add a description of the menus in a toolbar as the user browses them. So I thought I could just use the beginning of the menu's description of the help but just cant find how to access the contents of it.
I saw WinHelp has a macro language, so I figured maybe through this, but I couldnt find any references on this around.
Anybody now some pointers or examples of hot to do this?
the winhelpcgi utility contains library code that can read .hlp files. The source is here: link
I haven't used it so I can't vouch for its usage.
First, your help system should have an Index on each topic that permits you to open help and have that topic appear (if not, then check out Help & Manual - it'll help you build more complete help files). However, this doesn't directly solve your problem since, as I understand it, you want this to pop up in a toolhelp Window.
Thus, you'll need to go under the surface and figure out how the Help system uses the key to pull the appropriate information. However, it is not a trivial undertaking (as far as I can tell) to directly access a specific, indexed chunk of text in a WinHelp file. You may find some information here that is of use. You might also want to browse the forums on the Help and Manual web site.
Here's a bigger question though: does it really make sense to pop up an entire help topic (even if short) when a user just hovers over a menu item or button? It doesn't to me and I spent years in a UI design group at Bell Labs. It is A) simply too much information and B) going to be visually distracting (and thus incredibly irritating) to experienced users. The accepted practice here is to pop up a toolhelp window with a very short (1-4 words) descriptor of the button ("Open" or "Open File").
If you want the help to be available for each menu item or button, I would suggest one of two alternatives.
First, consider having a "Help Cursor mode" where the cursor uses the help icon (an arrow with a question mark). The user accesses it via a Help button on the button bar. When in Help Cursor mode, a user click on any item will take them to the help topic for that item. I'm kind of lukewarm to this approach since it is modal but I've certainly seen it done.
Second, you might simply beef up your help system a bit. That is, create a topic in your Help system that features a screen shot of your application. On this screenshot, create hot spots for each menu item and/or button and permit the user to go to the appropriate topic by clicking on it. Done right, this gives the user a visual key to the topics they wish to learn about without interfering with the normal operation of your program.
Most importantly: before doing all of the work necessary to implement your current plan, be sure it is the right plan!
Related
I want to be open up chrome, go to a webpage, and the check that a specific content ie, title, subtitle... is there, and then give me a notification if the content is present, ideally on a loop until it has found it. What is the best way to do that?
I have done a fair amount of this a few years ago, but now I have completely forgotten it all, and I just need help starting up again.
I don't have any software install, (in pretty sure with how basic this is I wont need any).
I have saved a bash file on notepad which I wrote " start www.bbc.com ". This will open up the bbc website, but I don't know how to check for example the title says "Welcome to the BBC". This is just an example, I want to try it on different website, but if I know how to do this then I can change the rest myself. I know how to use inspect element, I just don't know how to implement it in a script.
If there is another software/language thats easier than bash im happy to change over.
I know this sound very trivial and easy, I just want to start off and any help is much appreciated.
Thank you very much
Back when I was a kid, we used an old MS-dos system to navigate programs, menus and games. All I can seem to remember is that we started the program by typing "menu" (or it was in the autoexec). I can't recall further about the name.
This was back in the beginning of the 90'es, but the system could have been developed earlier, but I recall using the cd and cd.. to navigate earlier than that.
I also remember that you could edit the menus by adding/removing items by pressing SHIFT-F[x] (I could be wrong about the shift, but it was an modifier and an F-key), and an item was added by modifying a number of batch-commands. This could either be a new page of menues or a command to a program.
My memory tells me that it looks something like this;
Can anyone tell me more about what this program was called and maybe even if it is available as download somewhere?
(Edit: Updated title)
I remember DrMenu and Fixed Disk Organizer (from IBM) but I don't remember their appearance.
I remember a similar program on my fathers PC (or rather AT) back in the late 80's/early 90's. I think it was made by Scandinavian PC Systems, or SPCS for short. I doubt Visma (that now own the brand SPCS) have it for download somewhere, and my answer is not a complete answer but I can not add a comment so I hope you excuse me for trying to help out in this way.
I'm confusing how to write good messages for my SW. like this below:
"To Save the project, click on the 'Save' button. To Cancel it, please click on the 'Cancel' button."
But I think it's really useless, Do you have any comment about how to write meaningful messages?
Personally I like messages that don't have to explain much. Number one mistake on windows applications is having buttons with standard texts instead of the operation that is performed when pressing it.
Example: Instead of this:
Do you want to save the changes before closing?
- To save the changes press Yes
- To discard the changes press No
- To cancel and keep the application open press Cancel
[Yes] [No] [Cancel]
I like
Do you want to save the changes before closing?
[Save] [Discard] [Cancel]
If this is a prompt, then I would use a question and answer style:
Save changes to this project?
[Yes] [No]
Don't state the obvious
But don't assume that what's obvious to you is obvious to the user.
Link to help topics explaining what the terms used by your message mean
Emulate the Mac: Many prompts have a "Huh?" link that leads to further help.
When in doupt, add a help option.
So instead of:
"Enter S for save of C for Cancel"
use
"Enter S for Save, C for Cancel or H for help"
Another big feature is if your application is consistent, particulary with it's operating environment. For example for virtually all Windows applications pressing the F1 key brings up a help screen. Similarly pressing F5 usually causes the current view to be refreshed.
What really drives users crazy is an inconstinent interface. Think about an application wehere sometimes pressing F1 would bring up help while in other parts of the application pressing F1 would mean "delete this document"
For this reason vendors (Apple, Microsoft) often publish style guides on how an application should interface with the user on their platform. For example Microsoft has the Windows User Experience Interaction Guidelines which:
"The goals for these official Windows User Experience Interaction Guidelines (or "UX Guide" for short) are to:
Establish a high quality and consistency baseline for all Windows-based applications.
Answer your specific user experience questions.
Make your job easier!"
If you are talking about error messages then it would be great when you let user know why this error occured.
For example if user see page 404 then you don't need to write a whole article for him BUT you should make reference "Why I see this page?"
If user made simple mistake in URL then he wouldn't open that reference but if your project changed its structure and a week ago it was correct URL and now it's not then user will certainly open reference and read nessecary information. It's a good style.
Describe the choices in terms of the user's actions. Be terse. "Omit needless words." Ideally, the buttons will describe the actions, and you don't need text to slow down the user. Assume that the user hates to read anything on the screen; even if the user is highly literate, and using your application to write deathless prose, the user is interested in what he or she has written, and not verbose text about what the system is doing.
If you're really helping them understand what the buttons do, tell them what will happen after they click them.
So don't say "click save to save" because they might not know what "save" means. Say "click save and your information will be stored for later" or "if you click cancel all the information you put in will be lost".
Keep it short!
Users will not read a paragraph that explains all the ins and outs of which button to press. You only get about 2 sentences max that the user will read. How many people actually read this second paragraph?
What is your biggest pet peeve related to the windbg debugger from microsoft?
(note: I actually really like windbg if I ignore the unpolished UI.)
Attempting to dock a window is almost always the wrong kind of dock the first time until :I move the mouse just right. Why can't it have the docking cues that VS2008 has?
The ridiculous behavior when you attempt to use click-drag to select text on a line that is wider than its physical window.
The pieces of the history window that I need to copy/paste into bug reports are frequently wider than the physical window. I've gotten so used to the triple-click workaround that I find myself attempting to misuse triple click in other (well behaved) applications.
Key presses are ignored while the focus is in a source window. It's not like you can edit the source code from inside windbg. At least there's the Alt-1 workaround.
How insanely slow .kdfiles copies new binaries across the 1394 connection. It can take up to one minute for a large dll.
Not being able to switch from output window to command window using a key press, I read that 'Alt+1' should work but it doesn't always so I always have to resort to using the mouse. Also sometimes it doesn't remember when I tell it not to ask me everytime if I want to save the workspace when I quit.
We're using the file picker dialog to allow users to add documents into our application. The word 'Open' doesn't make a lot of sense in this case.
Thanks.
I would browse the code found here, which shows how someone extended the OpenFileDialog. Admittedly, this is overkill for you. But I think there is code within to change the button label.
Not really no.
Given the standardization of this dialog it's extremely likely that your users will have used it many times in the past to "add" files to applications. The chances are they will be quite familiar with the implications of the word, changing it may be more confusing to them.
The standardness of the dialog is why it's called a "Common File Dialog". If you want to change it for your app, you'll have to write your own dialog.
Having said that, there are apps out there that can pull a form out of a DLL, modify it, and stick it back in. However, this is a per-machine hack and downright bad form.