Am I the only one who finds the error list in Visual Studio a little awkward to use? Can anyone explain why it behaves the way it does? When clicking on the Warnings tab or the Errors tab or the Messages tab you don't always get the errors, warning or messages. Insead, the view remains as it was already.
This may be an observation you already made but the Error, Warning and Info "buttons" in the error view are TOGGLE BUTTONS and show/hide the respective class of output message, which when I first came across them was not what I expected and did seem rather confusing.
Now I know they toggle the display of the correspondingly captioned output type on/off I find it quite sensible. It also behaves as expected; when you know what to expect!
It only make sense once you learned how it works. But, still this UI could confuse a lot of people when they have seen it the first time.
The Error/Warning/Message buttons look like Tabs but work like Checkboxes. It can be very confusing if a first time user clicks on them and execpts the behavior of Tab buttons.
Related
Every other time I select some code with my marker for copy/paste reasons, a popup message is shown which prevents me from copying the selected code. It seems completely random when it appears and what type of popup appear - sometimes it shows, other times it doesn't. Sometimes it says something about quick help and other times it's a summary description of framework code. Can I disable these messages somehow? I can't show an image here because my reputation is too low.
I've added some code as found here Big problems with MFC/WinAPI to colour tab titles the same as the reset of the dialog, which works, but unfortunately all the tabs end up with the same name. This doesn't surprise me all that much as GetCurSel() is used to grab the text to use, and only one tab can currently be selected, but I'm struggling to see how you access the correct tab index from OnDrawItem().
I've googled and had a look on MSDN but don't see how anything passed to OnDrawItem lets you know which tab is currently being drawn, rather all the examples I've seen assume you're only interested in the one currently selected. All I want to do is something along the lines of GetWindowText() on the child window and redraw with that. I'm also unsure of the parent/child/sibling relationship between the sheet, tab control and page - it depends who you listen to.
I should probably add that I'm also unsure why all the tabs are redrawn when I select one. I don't know if this is normal or something specific to this implementation (that's something I'm looking at, but like seemingly everything else in this code base it's multiply inherited several times over ...).
Cheers for any help.
Not to worry, I now realise lpDrawItemStruct->itemID holds the tab index so I can get a handle to the tab using that.
I am writing an app with raw windows API (opensource Win32++) where I have a ListView.
The problem I have now is that whenever an item in the ListView is clicked, the system/app will generate a warning tone/sound "ding". Furthermore, I noticed I cannot get the LVN_ITEMACTIVATE through item-dbl-click or item-keypress-enter, which would normally work if this problem had not occur.
Would anyone have any idea how this might be happening?
I believe there is nothing wrong with Win32++, it just could be one of the things I do is causing this. But my program has become quite big to dissect plus I have no idea where to start looking.
Thanks.
PS: I had my computer muted for the longest time, hence, I don't know when this started eventhough I had the listview since a long time ago. T_T
Start looking with a tool that can show you the Windows messages that the control generates and receives. Like Microsoft's Spy++. Compare it with a working list view to have an idea what might be amiss. Also check the parent window. I haven't otherwise heard of listviews that dingaling, the LVN_ACTIVATEITEM should fire the first WM_LBUTTONDOWN, no double-click necessary.
For tasks that will take more than a few seconds, a good user interface, in my opinion, should provide a progress bar along with appropriate information on the progress of the operation. (Microsoft kindly provide User Interface Guidelines on this topic, but I want a status panel that is a bit more advanced.)
The "task" class I am using is able to log messages, and if the messages are important enough (warning or error), I would like to display them on the progress panel. It would also be nice with a graphical indication when warnings or errors have occured (a warning or error icon perhaps). If there are many such messages, a text box, a list view or perhaps some report control could be appropriate here.
There could be a cancel button while the task is running, and after the task has been completed, a "View log" button would also be nice.
To summarise, I have a good idea how to implement my status panel, but I would really like some input on this. Did I miss something important? Am I going overboard on this? Are there perhaps any components like this already available out there?
For logging, you should probably actually have another higher level of error. These are the levels I usually implement (as swiped from DEC back in the 80's).
DEBUG - a very low-prioity message that the developer just put in to help diagnose what's going on in the event something goes awry.
INFORMATIONAL - No problem, just reporting progress the user might be interested in.
WARNING - Something that could possibly be an issue in some situations, but may also be just fine.
ERROR - A definite problem. The user must be informed, but the program will try to keep going.
FATAL - A problem so bad that the program can't go on.
The second is, since you are calling this a "progress panel", I assume you are planning on implementing some kind of progress bar. There has actually been a fair bit of research into progress bars. The main thing is that, whatever you do, don't let the bar get slower as it progresses. That makes it seem to drag on forever.
Lastly, it sounds like you are considering some sort of status message line. If you are looking for some good status messages, I suggest you use some of these. :-)
You have here a similar Status Panel specifications which can give you some ideas on what could be included into this kind of GUI:
In sort, define your goals and scope of this Status Panel before listing the design details.
Note: with too much options on it, you will evolve it into a "Control Panel" ;-)
You'll want to view log messages while in progress, not just at the end. If a bug occurs, it'll often be before the task is done, and the UI thinks everything is still chugging along. It can be really annoying to find this is happening, and yet the only visible log message (without going to some external file somewhere) is some random informational message far removed from the actual problem.
(I don't know whether you're already doing this, as it's not clear from your question. If you are, hats off.)
I think it's important that your main progress bar fill up exactly once, and there is always indication of progress.
I've just recently done something very similar at work. The tasks were long, with many subtasks. The interface I ended up with was a double progress bar, which were actually the first and last of a stack of progress bars.
The API is something like
StartNewTask(Caption,NumberOfSubtasks)
EndTask
SetProgress(Caption,NumberOfSubtasksFinished)
StartNewTask pushes a new bar on the stack, and EndTask pops one.
SetProgress sets the progress of the most-recently-pushed progress bar, and ripples up the changes to parent bars. For example:
StartNewTask('Doing 2 things',2)
SetProgress('Done 1 now',1)
StartNewTask('Big Subtask',40)
...
SetProgress('Done some subtasks',10)
Now, there are 2 progress bars shown, the second at 25% (10/40) and the first at 62.5% (1/2 + 10/40*2)
Like I said above, if you've got >2 tasks in the stack, I only show the first and last (first gives overall progress and never goes backwards, second gives indication of current activity)
You could extend this by giving a weighting to each subtask, i.e.
StartNewTask(Caption,[ListOfSubTaskWeightings])
To make the top progress bar smoother.
Additionally, developers can show all progress bars to see why it takes ages, and I think you could make decent logs out of it.
I'm currently working on a program that has many of those "the user SHOULD read it but he'll click OK like a stupid monkey" dialogs... So I was thinking of adding something like a captcha in order to avoid click-without thinking...
My ideas were:
Randomly change buttons
Randomly position buttons somewhere on the form
The user must click on a randomly colored word within the text he should read
add captcha
add captcha that includes the message for the user
Has anybody made any experience with such a situation. What would you suggest to do?
Well, you asked for opinions and here goes mine, but I don't think this is what you would like to hear...
Users like programs that they can depend on. They don't like when things change and they don't like to do extra work.
Randomly change buttons and Randomly position buttons somewhere on the form will only make them either press the wrong button or become annoyed with your application, because as you say, they don't read the text, and if you think about it, neither do we. As an example think of an Ok/Cancel dialog, you allways expect the ok button to be on the left, and most times i press it without reading it. It Will happen exactly the same with your users.
The user must click on a randomly colored word within the text he should read
add captcha
add captcha that includes the message for the user
With these 3 option you will add extra work to your application, your users will curse you for that. Just think of something that you would have to do 10x per day, let's say check in your code to source safe. How would you feel if your boss told you that from now on you will have to fill a captcha for each file you try to check in?
I think it's our jobs to make the lives of the people that use our software easier. If they must read some kind of text and they don't want to, there is absolutely no way you can make them do it.
You can´t make people work right, all you can do is provide them with the best possible tools and hope that they are professional enough to do their jobs.
So basically all i'm saying is, do your best to ease their work. If this is really important than you(or whoever is in charge) should talk to them and EXPLAIN WHY this is important.
You would be surprised on how people commit to things they understand.
I suggest that you don't; and that, unless you know better, you emulate respectable well-known, well-tested UIs like <big online retailer's> or <online banking site>.
Playing games with the user in order to get them to read messages is doomed. Users will focus mental resources on completing your game, rather than understanding the message. Your users may be less likely to actually understand the important part of the message if you have things like moved buttons, relabeling, scavenger hunts, captchas, or delays. They’ll focus on the instructions for the game, not on the real issue. Errors are likely to increase.
Users’ refusal to read message boxes is due to users wanting to get things done quickly rather than take the time to read stuff, and it is also due to message boxes being overused and misused so badly in so many apps. Including silly games in message boxes will just make users resent them all the more, compounding the problem.
Here’s what you can do:
Rule 1. Don’t use messages boxes. They should only appear for exceptional circumstances. An app should not have “many” message boxes. It should not be necessary to read a whole lot of documentation each time the user uses an app. If normal use of your app results in a message box, then your UI is wrong. Find another way.
Instead of verification messages, show clearly in the main window what has happened and provide a clear way to Undo it.
Use auto-correction, pictured/masked fields, and disabling rather than error messages.
Use good defaults and automation to avoid messages. For example, rather than showing an error message saying the user can’t upload because they’re not connected to the server, simply reconnect automatically.
Break commands along options. Rather that a message box to ask if the user wants paste with or without format, provide two different commands in the menu.
Don’t have information messages spontaneously popping up telling the user everything worked fine (e.g., “Preferences Saved!”)
Don’t have pop-ups providing helpful hints or documentation. Provide a tutorial or balloon help if you can’t make your UI self-documenting.
Don’t have nagging “upgrade me” messages.
Consider providing message text in the main window rather than in a separate message box (e.g., “Page may not look or act right because ActiveX is off for security.”). Pop-ups from web surfing have conditioned users to automatically dismiss anything that pops up as irrelevant.
Rule 2. If you have to use a message:
Make the text as brief as possible to get the key information across. More text is not equivalent to more helpful. Use “No match to [filemask] in [path].” Don’t use “Nonfatal Error 307: Search action aborted. [Appname] is unable to complete your string search for the regular expression you provided because the file mask you gave, namely [filemask], does not result in any matching files in the directory that you specified (which was [path]). Please check your filemask or path selection and again re-enter it or them in the Files to Search dialog box. Click the OK button below on this message box to return to the Files to Search dialog box. Click the Cancel Button on the Files to Search dialog when you get there to cancel your search for strings.” If there are some users who will need more explanation than can be achieved in a brief message, provide a Help button or a “How do I…” link in the message box.
Use plain language and no jargon in the message. That includes “innocent” words like “dialog,” “database,” and “toner.” Do not take raw exception text and throw it in a error message. Do not include any error numbers or dumps; log these instead. Purge your app of any debugging message boxes left by developers. Better to simply let the app disappear on a fatal error than to put up a message full of jargon and then the app disappears.
Label the buttons of a message box with what the action does, not “OK.” At the very least, the users have to focus on the activating button to dismiss a message box. If that button is labeled something like “Delete” or “Install,” it should give them pause. You should never have to explain in your message text what each button does. BTW, such labeling is a GUI standard on most platforms.
Redesign your application so that it does not use message boxes.
My suggestion, live with it or redesign your dialogs/interface. Do not add randomness to dialogs or otherwise treat the user like an idiot, even though you may think most are :-).
I just recently read a Joel on Software article, Designing for People Who Have Better Things To Do With Their Lives. It makes the point that most people won't read anything and discusses ways to work around that or at least not make it worse.
You could try with a timer which waits for the "supposed reading time" before enabling the submit button. You can even calculate the supposed reading time from the number of words.
I think that subtle ways to force the user to read your text (like moving around buttons or asking them to read a captcha) can make them feel like stupid monkeys.
You could use a choice question based on what the user should read.