|
Funny you should post a song from this album...
Transgression is the album where I stopped listening to them.
Loved Archetype, the album before Transgression, and Demanufacture and Digimortal are straight up metal classics.
Their latest album, Aggression Continuum, is probably their best since Archetype (and maybe even better).
So those are my Fear Factory recommendations 
|
|
|
|
|
Greetings Kind Regards "...looking forward to their next album..." Surely you're joking Mr. Feynman Below is my Revenge of the Week I enjoyed the "un-twist" at 3m Thank You Kindly - Cheerio
11 Composers Enchanted by Space | WQXR Editorial | WQXR[^]
"I once put instant coffee into the microwave and went back in time." - Steven Wright
"Shut up and calculate" - apparently N. David Mermin possibly Richard Feynman
My sympathies to the SPAM moderator
|
|
|
|
|
I'm surprised Holst isn't at #1 
|
|
|
|
|
We have this large HMI application that splits into 3 distinct softwares. One is an editor which user uses to define the plant and other stuff related to it. Pretty big software!
We have pollshed it through the years and I'm sure we have little to zero bugs.
In it, users are informed about their input mistakes by message boxes and it's pretty common that a client calls and complains about the bugs the software has. When we ask them to whatsapp us an image of the bug they usally send an image of a messagebox. They don't event try reading the message it shows. Their first assumption is always is every messagebox shows a bug!
This has lead me to think about different way of showing user erros/mistakes.
Behzad
|
|
|
|
|
Whenever you post a dialog you should post all the needed information in the application's logs. You can then get them just to send you the logs which should contain all the information you need.
|
|
|
|
|
This, but even better: if you are showing an error dialog, include a button that will email the log to the development team.
I've still received mails with a screenshot of the error dialog where they did not bother clicking the "Send report" button 
It's quicker and simpler to click the button, it helps the devs get the full log and analyze the issue... but no, they would rather take a screenshot that has next to zero information, put it in an email and manually send it 
Cheers,
Vikram.
|
|
|
|
|
I think the replies you got to your question show what the problem is. Me, I read your question as being about message boxes generated by user error, not program bugs. The previous replies give you ideas how to improve your bug reporting! 
So the issue is that people don't read carefully or undertstand different things from what they read. Being a cynic, I don't think you can change human nature and you'll just have to live with it. Budget accordingly for customer support and include that cost in your product cost or support plan.
Mircea
|
|
|
|
|
Can you clearly explain to your users why they're getting those messages boxes? Do they understand the explanation? If so, why do they keep coming back?
If it's because they're simply not reading the messages, then eventually they'll have to realize they're wasting everybody's time, most importantly their own, when they become aware the same things are being explained to them over and over again.
And if they're simply not reading the messages, you might think there's no point adding more details or rewording things so they're clearer. But I'm a strong proponent of the "covering your own ass" principle...if the messages are as clear and concise as can be, and all the information is there, then the idea is to make a third-party arbitrator side with you. And it doesn't hurt to ask your users, how would you like it to work under those same circumstances?
Another consideration:
What's the nature of the errors? If users are expected to type in digits, and they type in letters, then you can mitigate that by limiting what can be entered as the user types things in character by character - make sure your form shows the expected format somewhere near the textbox taking the input. Or perhaps present a pick list, if that's an option. The point is, don't allow users to enter invalid values to begin with, so that you can avoid having to look at what was provided and report that the data's no good. (That's not to suggest you can then get rid of validation code by assuming it will always be valid)...
Some forms will display a message, in red, next to a textbox that's in an error state, rather than interrupt the flow with a message box. I'm not convinced your users will complain any less about that however than a message box showing the same content--especially if they're prone to not reading it anyway.
|
|
|
|
|
It amazes me that the longer society uses computers, the dumber and more impatient we (as a society) seem to become...to the point that messageboxes are an annoyance. Why do I need to be bothered to make a decision?...Can't the program just make the decision for me...you know like AI or in the movies? 
Seriously though, messasgeboxes and documentation while vastly underappreciated are still necessary evils. I suppose the only thing one can do is regarding messageboxes is to not overuse them to the point that they become an annoyance or just something the user regularly clicks through without reading.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
If it's a (simple) data entry error, these days I usually define a collapsed message line below each input field that shows the error message (in red), for that field, if there is one. (using WPF / UWP)
This way, it's easy to tell which field is in error (without having to border it, for example).
Also avoids having to constantly dismiss message boxes that only have an "OK" button.
Don't know if this is a "different way", or if your messages simply need to be "better".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Not one bit. People have never read message boxes.
|
|
|
|
|
Is it possible for the software to not permit invalid data being entered? Perhaps audio output "You made a boo-boo" Some sort of graphic to get their attention Dancing bunnies maybe A wagging finger seems most logical Best Wishes - Cheero
"I once put instant coffee into the microwave and went back in time." - Steven Wright
"Shut up and calculate" - apparently N. David Mermin possibly Richard Feynman
My sympathies to the SPAM moderator
|
|
|
|
|
Without some analysis of frequency and type of errors that trigger message boxes, and details about your app, I don't think we can be more specific than the 'improve bug reporting' ideas in this thread.
I would invert the question here, change it to:
"Why does our code allow the user to make these mistakes ?"
Specific techniques I use to prevent entry/response errors:
1) don't enable, or even make visible, a Control the user can click, or enter data into, unless using it is appropriate in the context of program-flow.
2) use sub-classed or modified Controls that only allow certain types of data to be entered ... like a TextBox that only accepts integer characters and back-space
3) validate entered data when the user signals they have completed the use of the Control; if validation fails, you might force re-entry.
4) use a formal validation strategy
The remarks above are meant to be "general:" you can ask questions here on a QA forum for a specific platform/language.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
A lot of our more complicated data entry screens include an error/warning tab. Final submission of data cannot occur until all errors are resolved and warnings acknowledged. Data can be saved as “Draft” with errors at any time. This allows support and/or devs to retrieve the draft and see what is going on without total frustration by the users.
Think about how a good IDE informs you of errors, but does not stop you from working.
|
|
|
|
|
englebart wrote: Think about how a good IDE informs you of errors, but does not stop you from working.
I'd rather think about how a good IDE logs errors, and stops you from continuing with code that won't build.
Or, a good app that (optionally) logs errors, and does not offer the user access to Controls that are irrelevant in the given context, and, clearly distinguishes required from optional data-entry fields.
And one, that lets the user cancel an operation, or exit some modal state, with appropriate warnings, and safe return to a ;"functioning" state, or mode. An app that does incremental validation.
cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Easy one to end the week
Five point clear (9)
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
Five V
point INDICATE
clear
VINDICATE
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
YAUM 👍
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
|
R.I.P. Those were the days.
Currently building a basic bare bones Z80 board.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
R.I.P.
Truly a man ahead of his time in many ways.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Yep. ZX81 was my first. RIP Sir Clive.
|
|
|
|
|
|
why would you refer to an 81 year old computer pioneer/inventor a who just died as "boy" ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
