Which approach do you all think is better?
Next to each field, highlighting each field in a distinctive color or with an easily distinguishable mark, so it's self evident where the problems are, especially on a long form. Also place a help icon next to each failure providing more information in case it's needed by some users. In addition, do not forget to preserve the data that's correct in between failures.
I put a summary of the errors at the top of the form that gives details as to why a field value is incorrect such as "Field1 is Required and must be an integer". I also add visual indicators on the field that errored, typically an asterisk next to the field or changing the color of the input area.
It will always depend on the situation, but...
I prefer to do a non-obtrusive indicator (* perhaps) beside each field and show more detailed messages or a summary message at the top (or bottom) of the form with longer forms.
If the form is shorter, you can probably get away without providing a "summary". I changed my mind on this, you should probably provide a summary.
Identifying the field with an error is important, definitely. However, a summary at the top letting the user know that there are errors below can be helpful for a long form. Additionally, you can put more details in the top summary section that you might not have room for below.
We supply a small indicator next to each field with an error. When you roll over the indicator a tool tip gives you what needs to be fixed. We then also give a summary at the smae time so they can see all of the errors they need to fix.
Related
Alright, in my web application there's a dropdown that UFT picks up as a 'WebElement' instead of a 'WebList'. The options available in this dropdown are all just 'divs' and the data within the div is dynamic. Has anyone had to deal with this before? I even tried using the absolute xpath within the object repository, but that seems to be inconsistent. Whenever I run my test the first time it interacts with the dropdown it will wait the entire object sync timeout before selecting the element. Then I have it going back to select another item from the dropdown and it goes instantly. This isn't the approach I want to take with this as the abs xpath could break at any time. I've been reading blog posts etc from as far back as 2008, and tried every person's suggestion but I can't reliably click a dropdown and select something. I can give more detail if needed, but any help here would be appreciated.
When UFT waits the object synchronization timeout and then succeeds to perform the action it's usually because it has been using smart identification. Look in the report to see if this is the case (or just disable smart identification and see what happens).
If this is the case, you should try to fine-tune the description to succeed on the description and not resort to smart identification.
I got it! This behaviour was being caused by the 'browser' being different in that part of my code. I think this happened due to some of the same items being added into the OR from different pages.
Instead of having:
Browser("Browser1").Page("Page1").WebElement("Element I want").
It was:
Browser("Browser2").Page("Page1").WebElement("Element I want").
Once this was corrected in the OR everything worked as expected.
I've got an ActiveReport which has a textbox populated at run time. The "cangrow" and "multiline" properties are both set to "true".
When I run the report on my machine, the report prints out fine with all of the text set at run time. IE: "Dear John, hello -- how are you..." There's only about 250 characters for this textbox.
However, one of the machines downstairs will only print the name of the textbox. IE: "txtVerbage". A blank report with "txtVerbage" in the middle of it, where the body (see above) should be.
Has anyone else had this experience? I've been banging my head against the wall for days now.
Thanks,
Jason
Its probably the timing of when you're setting the Field/TextBox value. Make sure you set it in the Format event of the section containing the control (e.g. Detail_Format). Using the BeforePrint or AfterPrint or one of the Report events can yield unpredictable results like this.
Also be sure you set the Field.DataValue property and not the Text property.
Some background information on this is in the articles below:
ActiveReports Architecture: Report Processing
ActiveReports Architecture: Events
Navigable documentation w/ TOC
Hope this helps!
Scott Willeke
GrapeCity
The data you access from downstairs is not there. That is why when you bind the data to the report, nothing appears. The reason you see txtVerbage is because that is what you called the text control and that was the default text there.
So you need to make sure that you are actually getting data.
Currently, HTML5's new input types,
<input type="number"...>
<input type="email"...>
<input type="url"...>
simply focus on any offending text-boxes with mismatching user input upon form submission.
Problem: Focusing is fine. However it's a very subtle way of telling the user why the form is not submitting.
Which of these is the better solution to let the user know what's wrong:
Add css on a focused textbox by
adding a background color. It's still
slightly subtle and the user might
not immediately understand why a
particular textbox is focused.
Javascript validation (jQuery
validation plugin) for displaying error messages. In which case, I might as well use ordinary input types, and do everything here.
Suggestions are welcome!
According to good old usability heuristics:
Error prevention:
Even better than good error messages
is a careful design which prevents a
problem from occurring in the first
place. Either eliminate error-prone
conditions or check for them and
present users with a confirmation
option before they commit to the
action.
Help users recognize,
diagnose, and recover from
errors: Error messages should
be expressed in plain language (no
codes), precisely indicate the
problem, and constructively suggest a
solution.
http://www.useit.com/papers/heuristic/heuristic_list.html
The best choice is to clearly notify the user about the error (not only where has happened, but also why...). Above that the UI should be clear enough to prevent the user from unallowed input.
IMHO you can use JQuery for error handling, still leaving html5 types, which are "semantically" better than ordinary input types.
Make them go red.
I wanted to open up the topic to discuss ways to encourage or incentivize users to fill in information in a user profile on a website, such as skills, location, organization, etc. More information in a user profile can give a website an improved capability for its users to search, network, and collaborate.
Without bugging users to fill in their profiles (ie - via annoying e-mail reminders), what other ways have you come up with to encourage user input?
I have noticed that a simple graphic image (showing percentage complete..some thing like a battery icon on the cell) next to the username ( to the user) with a hover text (your profile is x% complete - click here) works.
I find the Stack Overflow concept of badges or some other kind of reward hook very useful for this kind of thing. You could of course limit access to features also based on information in the profile.
Make filling in this information a benefit for the users. For example, "if you fill in your location, we can filter search results based on that information."
It's all about making the user get perceived benefit from doing an action.
Linking to a privacy policy that is devoid of legalese and doesn't cause the user to navigate away from the forms to fill out their profile usually helps. Additionally, marking any field that will be public with "Viewable to everyone" in addition to marking the rest with "Private" will also help. Whenever possible, make the private fields optional.
E.g for every field, let them expand a container that explains how the data in that field will be used, in plain language.
A quick search will turn up a ton of controversy surrounding Facebook, Google and more regarding privacy. Make sure the form adequately puts out fear fires.
Additionally, limit the number of questions, make sure the tab key works as expected, etc, etc.. but that's all general usability.
Exposing the benefit, in some form of feedback is a really good way to go - show your users that they have gotten something out of it.
Trophies, or some sort of social effect ("45 users have filled in their profile, will you?") are good ideas.
Another option is to show the user a "percentage completed" bar of their profile (like LinkedIn does, called "Profile Completeness"). Many people will feel the need to get that bar up to 100%.
We have a long for which has 3 sections:
requester, shipping and billing
each section screen or more long so the form is 3+ screens long. From usability perspective what is the best way to display messages on the form.
Grouped list of error messages at the top of the form.
Grouped messages for each section at the top of the section
Error messages near to the form field which actually has the error.
Personally, I would like, at the top of the page before the form headers, to have something like:
There was an error with your form submission in the following section(s):
Shipping, Billing
Where Shipping and Billing are anchors that will take me down to that section of the form.
Then, above that section, have the relevant messages to that section:
Shipping
- You need to fill in an address
[rest of form here]
Billing
- You need to fill in a name
[rest of form here]
Grouped messages for each section at the top of the section
with a visual change to the form field which actually has the error.
I find it most usable if there is a generic error at the top of the form saying something like "There were errors submitting your information, please correct the fields in red" then show the more specific error messages next to each form field that had an error.
Roger Hudson has a very good article on writing accessible forms
and an example on error handling.
I like to have a dialogue that shows the type of effected fields, let's them click okay, then scrolls them to the first error in the form.
The affected field is then indicated with a flag/border/marker of some kind and a message letting them know the type of problem.
So, if they entered a malformed email address like "me#me'com" if would let them know the email address is malformed. The exact wording is really dependent on the type of user you are targeting.
I HATE forms that tell you there are errors at the top, then have tiny little asterisks by the fields.... ugh.
P.S. It also drives me nuts when a form has a "password" or other sensitive field and it gets emptied without marking it as a required, corrected field as well.